ReactOS Being Rewritten, Gets Wine Infusion 387
xlotlu writes "ReactOS was meant as a free and open-source operating system, binary-compatible with Microsoft Windows. But after 11 years in development it never reached a satisfactory level of usability. Due to lack of developers, reimplementing the Win32 subsystem proved to be a much too complex task, holding the project back. Given the deficiencies of the current implementation, developer Aleksey Bragin decided to rewrite it from scratch, drawing heavily from the Wine project. Bragin's announcement on the ReactOS mailing list makes a compelling argument for this decision."
Re:Ummm... (Score:5, Informative)
Actually, it does put energy into Wine. Reading quickly, it appears that it implements a shim underneath the win32 support in Wine, bypassing the usual Wine requirement for an X-Server. So they can work on the Wine APIs and both projects benefit.
Re:No interest (Score:2, Informative)
Legality? Adaptability to new hardware? Free virtualisation of a windows hosting environment? Tracking new features as and when required, rather than needing to upgrade that (illegal) torrent XP? Offering an alternative to users of older hardware? The thrill of actually doing it? Just to piss you off?
Re:Ummm... (Score:5, Informative)
Re:Ummm... (Score:3, Informative)
As I understand it from the presentation, ReactOS would be able to do some things on the hardware level that Wine, by design, cannot do.
Re:Rewritten? (Score:5, Informative)
I don't know if you've heard or not, but two of those "embedded, server, desktop." Linux is not just mainstream, but dominates.
Re:Misleading summary (Score:2, Informative)
From the powerpoint presentation linked by TFA, Wine keeps all their X11-specific code in a module that is accessed by wrapper functions. The guy wrote his own module to make the wrapper functions work with ReactOS instead.
Re:No interest (Score:5, Informative)
Or as it says on http://www.reactos.org/en/about_whyreactos.html [reactos.org]
"ReactOS offers a third alternative, for people who are fed up with Microsoft's policies but do not want to give up the familiar environment, architectural design, and millions of existing software applications and thousands of hardware drivers."
This is exactly why ReactOS interests me.
Re:Ummm... (Score:5, Informative)
What killed OS/2 was IBM basically blowing a 1-2 year lead on Chicago, not anything to do with Windows compatibility. IBM simply did not know how to market OS/2 Warp, bumbled around for over a year while Microsoft basically convinced developers to hang on for an operating system that didn't even exist (all those early "screenshots" of Chicago that first showed up in 1993-1994 were in fact artists' renderings). Even Microsoft wasn't really all that ready, as Office 95 was simply a variant of the 16-bit suite with a 32 bit wrapper. What's more, Windows 95 was an absolute horror story reliability-wise compared to OS/2. It was a piece of garbage. But Microsoft won because Microsoft understood the PC marketplace, and IBM had little or no understanding.
I know some of this because I was working for an IBM VAR at the time, and we saw just how inept IBM was, despite having what was, at the time, an extraordinarily powerful OS, with a powerful scripting language (Rexx), pretty good networking that included a full TCP/IP port, a fast and reliable file system and even it's own GCC port in the EMX system. I've told the story here before, but IBM was so bizarre that when they launched Warp 4, they didn't hand us VARs out OS/2 Warp 4 install CDs, they gave us a fucking movie that you played in a Windows machine. It was pretty much at that point that we figured out IBM had lost the thread of the conversation, and we pretty much abandoned selling OS/2.
Re:Rewritten? (Score:3, Informative)
OS X (NeXTStep) has always been built on Mach. It is not like they took classic MacOS and gave it a new UNIX kernel/subsystem.
What Apple did would be more like Microsoft buying out RedHat, giving Gnome a facelift to look more like Windows 7, and adding in some compatibility layers to make the transition from Windows to Linux easier for developers.
Re:Ummm... (Score:3, Informative)
I started working with Linux in 1995 and have almost completely abandoned Windows since 2000 or so. However, I still have to do some occasional work in Windows, and I always feel how painful and difficult it is compared to a Unix-like system.
Too bad you left Windows just when it got good.
And how about filesystems? The simple fact that the directory separator is the backslash, which is used as the escape sequence initiator in C-like languages, is a PITA. Plus you are limited to 26 different filesystems, one for each alphabet letter. And you cannot use a name for mount points, just one letter.
Actually, NTFS has allowed you to mount to directories for a decade or so now. That provides for more than 26 filesystems and also for nice names. As for backslash, yes it's an escape character in C languages. Linux uses forward slash, which is the default delimiter for regular expressions. Which gets used more often?
I could go on and on, for any professional systems administrator, Unix is far superior to Windows, there is no doubt about that. It's only for home computers that familiarity is a convenience, professionals can be readily trained to use a system that's intrinsically easier to use.
Wait, you're a professional system administrator? Maybe you should learn something about the systems you administer. As it is, I can't imagine you do a very good job.
According to the manufacturer, it's by customer demand that they use Windows for the workstations.
I'm sure you never stopped to consider that there might be a reason for that other than stupidity. Windows can be far, far more productive than Linux for anything other than running a server or using the command shell. Two strengths do not victory make.
Re:Rewritten? (Score:2, Informative)
but that doesn't rule out linux from running on all the other devices that make up the remaining 90%.
No, that statement in and of itself wouldn't rule it out. But what does rule that out is the actual facts themselves which are that VxWorks is the most widely deployed embedded OS.
Re:Ummm... (Score:5, Informative)
The command interpreter that was command.com from the DOS era was integrated into NT5+ as cmd.exe, which many of us know, love, hate, and have thanked for allowing us to continue to run
The primary method to access a partition in windows is certainly via a drive letter, but if you do manage to go past 26 partitions, you'll get "A-A:," A-B:," and so on. Still, you can actually access these volumes in a more "modern" fashion by using their volume names directly (e.g. \\?\Volume{volume-guid-goes-here}) and not just the mount points they've been exposed on, or you could always expose the same volumes as a folder on an already mounted NTFS volume as well.
The thing is that many of the gripes more technical folks have had about Windows over the last decade have been solved in one way or another, but the problem is that since all of the old methods continue to work, there's little to no incentive for users (including systems admins, IT pros, programmers, and so on) to change our behavior, especially when we already know how to solve a given problem, irrespective of whether or not our chosen method is actually the most elegant solution.
I have to admit though, if I hadn't been forced to manipulate Linux based OS's in the ways that are required to get work done, particularly with respect to volume management, I probably wouldn't know about any of this stuff in Windows in the first place
Re:Ummm... (Score:5, Informative)
Plus you are limited to 26 different filesystems, one for each alphabet letter. And you cannot use a name for mount points, just one letter.
This hasn't been true since Windows 2000 (due to changes introduced in NTFS 5.0). You can mount a drive to a folder on an existing mounted file system through a process called Volume Mount Point [wikipedia.org].
Works just like Linux. Granted it's a little more buried to find out how to do it than in Linux, but not that much.
Re:Ummm... (Score:5, Informative)
Let me take a shot at it.
The question was: Why wouldn't Aleksey Bragin put his energies into working on Wine instead of ReactOS?
I would suggest that what Bragin has in mind, as described by the summary and article, is a full open source operating system that would be "binary compatible" with Windows. He is "drawing heavily from Wine" in re-writing ReactOS, which had never reached fruition in the past.
There's a big difference between an Windows-compatible opensource OS and Wine. I can imagine a lot of people who have rejected the notion of installing another open source OS and then installing Wine in order to run Windows programs would be more interested in an OS that just ran Windows programs. For the casual user, installing Linux and then configuring Wine in order to run their Windows programs is not trivial. Imagine just having to install Ubuntu and then being able to install and run your Windows programs on top of it. That would seriously shake up the OS landscape, no?
I have no idea whether or not Bragin will be able to pull this off. I can imagine the obstacles are nearly insurmountable. But if he manages to do it, it'll change the world for a lot of personal computer users who are not fully satisfied with the current OS offerings.
I wish Aleksey Bragin the best of luck. I hope he pulls it off.
ReactOS already shares code with Wine (Score:3, Informative)
At some point a group of developers working on the Wine project decided to toss the old Win32 implementation and properly implement it abstracting out the interfaces to X. Since Wine has more developers, they were able to find more that were willing to work on the Wine32 subsystem and it is now a lot better than ReactOS's. Basically they've taken a look, saw how much better Wine's implementation is now and decided to switch to it.
As for the already shares code part, ReactOS from the start used as many wine components as possible to give them a good start on their implementation. Every once in a while on the updates you'd see listed that the wine components had been synced back into the project. It comes down to that in ReactOS they need to talk to actual hardware, where Wine talks to X and POSIX.
Re:Ummm... (Score:3, Informative)
$ sed -e 's,\\,/,'
You don't have to use / when defining a regular expression in sed or perl (and maybe others as well), but you do have to escape \ in C/C++, perl, bash, make, python (unless using raw string literals) and others.
Re:Ummm... (Score:3, Informative)
Having read the summary, said a massive WTF, and then read the presentation, I can only conclude that the submitter did not RTFA. The story is not about rewriting ReactOS. It is not about abandoning ReactOS. It is about replacing a crufty subsystem in ReactOS that all of the ReactOS developers hate with one that is simpler, does more, and is easier to maintain. To which the general response is 'well, duh.'
Basically, the problem is that ReactOS tries to look like the bottom of the Win32 stack and then put WINE on top to implement the rest. Unfortunately, the bottom of WINE doesn't really look like the bottom of Microsoft's Win32 stack, so you need horrible code to join the two together. This code is ditching the old interfaces and replacing them with something designed to run WINE fast, not something designed to run bits of Windows fast. Given that the ReactOS kernel does run WINE, and not parts of Windows, this is an entirely sensible thing to do.
Most of the ReactOS code remains and is used by this new subsystem. Using WINE is not a new thing for ReactOS; it always got a big chunk of the userland from WINE. Think of the relationship between WINE and ReactOS as being similar to the relationship between GNU and Linux in terms of the final product.
Re:Ummm... (Score:1, Informative)
When was the last time you tried installing software to a mount point where the mounted volume had sufficient space yet the drive/volume where the mount resided did not? I'll bet you were really successful with that.
e.g. C:\ 50GB size with 1GB free space
C:\MountedVolume 1TB in size with 900GB free space
Installing to C:\MountedVolume\SomePath will typically fail because the application you are installing requires 2GB of space. Try it some time. :)
Re:Windows Driver Compatibility layer... (Score:3, Informative)
They already have this, partially, with "ndiswrapper".
Re:Ummm... (Score:2, Informative)
For anyone curious about real world practical usage:
H:\>mountvol
Creates, deletes, or lists a volume mount point.
MOUNTVOL [drive:]path VolumeName /D /L /P /R /N /E
MOUNTVOL [drive:]path
MOUNTVOL [drive:]path
MOUNTVOL [drive:]path
MOUNTVOL
MOUNTVOL
MOUNTVOL
Re:Ummm... (Score:3, Informative)
In the "underdeveloped world", where people struggle to find water, they certainly don't give two shits about copyrights or IP laws. That's why Windows is so popular in China and India: they don't pay for it there! They just buy it on DVD for $1 (obviously not an official copy), or download it. That's why FOSS and especially Linux haven't caught on in developing countries the way many advocates thought they would.
Only in America do you have to worry about the BSA busting into your business and auditing all your computers, and giving you a $500,000 fine. Elsewhere, especially in Africa, that's simply not a concern. People like that will have even less appreciation for a Windows clone, or any FOSS, than anyone here on Slashdot.