Slashdot Mirror
ReactOS 0.4 Brings Open Source Windows Closer To Reality (techrepublic.com)
jeditobe was one of several readers to point out the newest major release of Windows NT-inspired ReactOS, which has just hit version 0.4, brings open source Windows compatibility a little bit closer. The new release includes out-of-the-box support for ext2, ext3, and ext4, as well as (remember, it is NT based) read-only support for NTFS. What else? Support was generally improved for third-party device drivers, making it substantially easier to install and use real hardware, as opposed to just virtual machines like VirtualBox. The internal WINE library was updated to improve support for Win32 programs. Support for Python 2.7 was added, making it possible to use python scripts in ReactOS. A substantial number of visual changes were added, with a vastly improved shell and file explorer, newer icons throughout ReactOS, improved support for fonts, and customizable visual themes. Even with these improvements, ReactOS 0.4 is still generally considered alpha-level software, though Alexander Rechitskiy, the innovation manager for ReactOS, notes that 0.4.1 may be almost beta-level software.
This version contains improved compatibility for most major rootkits and boot sector viruses, as well as emulation for most security vulerabilities all the way through NT4.0 SP2.
I'm glad to see progress on ReactOS. Good job!
ReactOS reimplements the NT flavor Installable File System (IFS) driver model. This model is very.... complicated. There is a reason why read-write EXT mounting is not a thing on windows systems, despite there being vastly more developers working on that filesystem.
ReactOS SHARES code with WINE. Patches move both directions through both codebases. As such, the libraries used by ReactOS *ARE* WINE libraries. It is not based on WINE, it literally *IS* the usermode components of WINE. They did this, because WINE project is focusing already on a compatible win32 (and win64) user mode.
What ReactOS works on, is the reimplemented NT kernel underneath. Unlike the Wine package for Linux, it does not use wrappers to call POSIX kernel features. It recreates actual NT kernel interfaces, the way NT kernel does on windows. THAT IS WHY NT DRIVERS CAN LOAD AND RUN.
It is theoretically possible that an intrepid person could hack on REAL windows' NTFS.SYS driver, and have real read-write NTFS support. In fact, I expect that this has already been done when testing the read-only driver through debugging, to better know how and what that driver does, so that it can be reimplemented.
Please stop spreading ignorant FUD.
By the time this is stable, no one will write programs using those Windows APIs anymore anyway.
> They say it has a WINE implementation, but they don't call it "WINE-based".
Right. It's an operating system, including a kernel, init system, etc. About 9 million lines of code in total.
Wine is a library which provides some of the API functions which are exposed to userland. Wine is about 2.8 million lines of code. Not that Wine is much smaller than operating system it runs on. ReactOS uses the Wine for many functions, Windows Vista uses the IE library for many functions. ReactOS isn't Wine-based any more than Windows is IE-based.
> And what's the point of including a variation of Python 1.7
You mean 2.7. Python is useful for scripting all sorts of things. As you may have noticed, Microsoft comes out with a completely new scripting environment every few years; apparently they don't think they got it right and they ned to start over from scratch. Some people agree, and Python is a very reasonable way to script things.
> And why only a read-only NTFS implementation?
Because safely writing to NTFS is hard. The damn thing was designed by /Microsoft/. Until the code for writing is safe (as safe as NTFS can be), read-only is better than nothing, and much safer than a buggy read-write implementation.
Alas, the TechRepublic article is rather inaccurate. Please read the official news on our website about ReactOS 0.4.
It seems to me that read-write ext filesystem support on Windows would be a more important accomplishment - enabling ext-formatted SD cards to be used on mobile devices and eliminating one of the more egregious bits of Microsoft patent blackmail. Obviously, nobody uses FAT for any other reason than Windows compatibility. Besides the silliness of allowing a patent on what is essentially a kludgy workaround for an ancient filesystem, the thing is a de-facto standard (see above - nobody would use it on the merits). If it must be patentable, then if ever there were a case for a FRAND licensing requirement, this is it. It boggles the mind that the license paid by the SD card manufacturer isn't enough to cover actually using the card - but our patent system boggles the mind in many ways...
In any case, a reliable ext driver for Windows would make it practical for device manufacturers to use the free ext filesystems.
Posted from my Android phone. Oh, I can change this? There, that's better...
Someday they will copy in the NTFS read-write support from GNU Hurd to solve the problem.
I remember when Wine was such a joke that many people including myself saw it as unnecessary and going nowhere useful. You could run things like notepad.exe and calc.exe. It was for many an intriguing passing interest and likely an impossibility as far as ever being really useful. A few months ago I found myself in a real pinch. I absolutely had to install and use some Windows software (a very, very rare event). Yet, I am not running a single instance of Windows nor do I have a copy or interest in pirating it. So, not expecting much, I installed Wine for the first time in many years. Well shit. The software installed and ran flawlessly. Kind of amazed, I spent a good day throwing a ton of Windows software of varying complexity at it. Roughly 80% installed and worked perfectly. More recently I found myself staring down a badly and rapidly decaying Ubuntu system (you know what I mean). It also just so happened that there was a DVD burning imperative. The whole dependency subsystem for burning was shot to hell. Brasero, k3b, command line, it didn't matter, nothing was going to work. This was also the worst dependency hell I have ever seen. There was no uninstalling and reinstalling of anything, and I mean anything at all. It wasn't my system and I was soon to nuke it anyway so I wasn't about to take extreme measures. Fortunately I had previously installed Wine on this system. Downloaded and installed... whatever popular Windows DVD burning software. Worked fine. Nuked the system and gave a lecture on how to not blow up Ubuntu.
So that is my Linux\Wine anecdote
I am not about to ditch Linux, but I am going to give the almost beta ReactOS a fair try with a Windows app by app comparison against Linux. Might even be worth writing an article over.
Brought to you by Carl's Junior.