Slashdot Mirror
Steven Edwards On The Future Of ReactOS And Wine
Alex_Ionescu writes "WineHQ brings us the scoop on the latest developments in ReactOS, as well as on Steven Edward's excellent job on porting Wine to MingGW and linking the two platforms together. This is an interesting insight into the WINE and ReactOS project, and a must-read for anyone interested into the future of Windows-replacement projects like these."
I've been surprised how far ReactOS has come along. I didn't expect them to progress this much by now. I could actually install the last release on real hardware and it installed and ran AbiWord just fine! BTW a lot of people seem to have problems with the install CD .iso based installation of ReactOS. There is a simpler way to run it if you have a FAT16 or FAT32 C:\ boot partition, just download the binaries and unzip them to C:\ReactOS\. Then just boot from a DOS floppy and run aboot.bat within C:\ReactOS. Works like a charm everytime (for the past half dozen releases anyway). BTW if you insatall the VESA mode VBE driver (search the kernel mailing list) then you can get AbiWord working in true color. Its impressive to see it working considering how far ReactOS has yet to go.
SuSE (7.0, manually upgraded lots of stuff from source since then), Wine CVS, StarCraft/Brood War and Red Alert 2 running perfectly in single player (forget IPX unless you're Novell certified, and Battle.NET doesn't work yet).
It's a fast cpu-emulator with JIT compilation and such. About 100 times faster than bochs.
QEMU
Consider ReactOS to be methadone to Microsoft's smack. If this project can provide a free, open source replacement for Microsoft products reaching the end of their supported life, it will provide a natural migration path away from MS. Hey kids, here's your choice - spend $$$ buying Longhorn ( and a monstrous PC to run it on ), or install ReactOS for free and keep running the all the software you know and love, on the same knackered old hardware.
Once that upgrade addiction cycle is broken, can you see users going back to MS products? Or are they likely to move onto another free OS if they feel the need? You tell me.
My only concern would be that, somehow, as soon as the project looks like being a serious threat, Billy Gates and his merry crew of pirates will f*ck it over.
"Buy 'em out, boys!"
Also Microsoft wrote code in thier apps that generated false error messages in some dos replacements, giving the false illusion that the dos replacement was buggy or incompatable. FUD wasn't used because microsoft was feeling sadistic, it was used because it worked.
The message was only present in *beta* versions of Windows 3.0, and was non-fatal. It was not present in the released version.
DR-DOS 6 actually did not emulate some internal data structures Windows 3.1 used, and would cause Win3.1 to crash under certain conditions. These problems were corrected in a patch which was released ~6 weeks after Win3.1 came out.
This is just NOT true. It's revisionist history. However, the nice thing about the web, is that the original article written by the first person outside MS to discover the code is still online.
This is what's known by historians as a primary source.
/usr/games/fortune > ~/.signature
Since we are mostly the topic of Wine, on the WineHQ screen shots page http://www.winehq.com/site?ss=1 they have an old link to my site ("Nathan Lineback's Wine Screen Shots") If they want to keep linking to it, It needs to be updated to point to http://toastytech.com/guis/wine.html The current link points to my very old pla-netx address that stopped redirecting to my new site recently.
I had tried e-mailing some contacts listed on the site, but there has been no responce. Who should I contact? Thanks.
Actually, it didn't. It started in 1988 when Microsoft wooed Dave Cutler from DEC. You might be confusing it with OS/2 v1, which indeed was started in 1985.
And IIRC, NT didn't support DHCP until 3.5 (nov 1994?), but I could be very wrong about that. My memories of NT's early days are getting hazier and hazier.
I think you miss the point. By using ReactOS, you cut out the software bloat that MS throws in, and you can pare down the kernel to the bare elements. ReactOS allows you to work at a command-prompt only level, so if you have an application like a server or embedded controller that doesn't need a GUI, ReactOS is perfect. While I don't think this is a deliberate goal of this project, it would not be all that difficult to make a single floppy version of ReactOS, like QNX has done.
The really nice thing about this is if you have components you are adding to an embedded system, and the manufacturer has Windows device drivers, ReactOS will recognize them and they don't even need to be recompiled. This opens up a whole range of equipment options that would not normally be available under embedded Linux (although most embedded equipment companies are supporting Linux now... this wasn't always the case).
I don't know what is cheaper than free software, and the point here is that this increases flexability. I don't know about what you mean with hardware requirement, but I don't see too many 386 CPUs anymore, even among embedded systems. ReactOS will run on most of the common CPU systems found in embedded systems, particularly if you are already looking at a Linux-based system as well. This is an option, not a requirement.
If you are talking about using the Microsoft version of the NT 4.0 kernel in an embedded system, I would have to totally agree it is a mistake. I would still be careful about the "uneducated developers" you are thowing stones at, because there is a huge difference between the NT kernel and Windows CE (which truly is for the clueless developers). On raw technical merits, I would stand behind an NT-based kernel as much if not more than a unix-based kernel (like Linux).
This is a legitamate question. First of all, please visit the ReactOS website (not in the parent news story), as this an many other FAQs are answered there. (Sorry, it got slashdotted apparently even without the link, but the FAQs are there, really.)
/. hasn't generated more responses. ReactOS is on the side of Free Software, and everything in it can be compiled and used with exclusively open source tools. As was pointed out in the interview, ReactOS can compile and develop ReactOS (it is self-hosting), but all of the little annoying things that a typical developer doesn't likes havn't been worked out yet.
This is more of a case of options, rather than why one is better than the other. As was mentioned clearly in the interview, ReactOS and Wine are working together, and there is quite a bit of mutual support they can give each other. It is not one or the other, but rather many efforts can help both projects at the same time. In fact, as Wine is moving to support more Windows applications, it is necessary to work with even more kernel services.
These two projects are attacking the same problem, but from different directions. This is why the cross-pollenation efforts are even more valuable, because each group sees a different set of problems and finds good solutions often when the other group isn't quite looking there yet.
In terms of re-inventing Windows, this is the only group that I've seen that has succeeded. There have been other groups in the past that have tried, but almost all of their efforts have been folded into ReactOS in terms of active developers and design ideas. The unsung hero with all of this is Jason Filby, who has done a remarkable job of keeping this project going through litterally years of effort when even a command prompt was not available. He is the driving force that is keeping everything together, and a very approachable person as well. When this project succeeds, he is certainly somebody who deserves strong kudos from the open source community.
Why a free software version of Windows? I think this will be very important to think about when Longhorn comes out, but Microsoft show little to no support for legacy applications, and is more than willing to abandon platforms when it serves their purposes. This is a matter choice, and this project will give more options, not fewer.
If you are not familiar with the NT kernel, there really is some amazing architecture that from an OS viewpoint should be studied. It is more like the difference between a GM engine and a Ford engine (for those few amature auto mechanics out there who know what I'm talking about). Each has it own fans and critics, but comparing Unix to NT shows some significant design choices in the basic fundimentals of the operating system. Microsoft has muddied up the picture in part because there hasn't been (until ReactOS) an independent implementation of the NT kernel or with the exception of Wine an implementation of the Win32 API library.
This really is more the debate of propritary vs. open source, which is probably why this news posting on
If you want to see something really neat, try and get ReactOS running with Mono. Mono is aiming more for Linux compatability right now, but with ReactOS handling some of the Windows API issues, ReactOS+Mono will run many of dotNET applications that won't run under Linux. All of the command-line Mono development tools will currently run in ReactOS, and I think this is another untapped combination that hasn't really been followed.