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.
You are incorrect.
ReactOS shares code with the WINE foundation for usermode libraries and programs, because there is no need to reinvent the wheel. The kernel mode goodies that run underneath are genuine NT flavor kernel. Remember kids, NT is a modular kernel with more than one subsystem type that it can service. While not given much love over the years, one of those is the posix subsystem. ReactOS supplies real NT surrogates wherever and whenever possible to provide the NT kernel services that user mode WINE libraries link to, instead of the wine surrogates used by the wine foundation. When that is not possible, it can use the posix flavor subsystem to provide glue. It is still NT.
ReactoOS is not a fork of wine. It is a sister project, that shares code with wine.
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.
https://www.reactos.org/project-news/reactos-040-released
I don't understand why slashdot didn't link to the actual news article on the reactos website?
> 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.
Hopefully this release will actually boot on real hardware. The last 0.3 release wouldn't even boot on circa 2007 Core2Duo hardware! This isn't cutting edge stuff as far as drivers are concerned.
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...