You are here

A reaction to ReactOS

Among the many free software projects out there, I think ReactOS is particularly worth some discussion. This is an effort to create a complete, clean room re-implementation of the entire Microsoft Windows NT operating system. Here is why I think this project is important:

First, we do have lots of free software today that is either written for, or has been ported to, Microsoft Windows. For those who wish to write such software, or to create portable applications that they may wish to later migrate to other platforms, it is essential to be able to target a clean and generic reference implementation of the Microsoft framework, freed from secret and undocumented behaviors.

Microsoft offers no such thing today—besides the lack of proper interface documentation, many of their own development tools depend on and offer libraries which use undocumented or secret API calls that are then built into applications. This is well illustrated in the difficulty Wine has with running applications, even those that were created purely within “standard” Microsoft development tools and not using odd behaviors or undocumented functions on their own.

We can think of ReactOS, then, as the “Microsoft Windows documentation project”. But, more importantly, for those who do wish to write portable applications, or those that do write free software for Microsoft Windows users, ReactOS will eventually give them an entirely free software solution to write and test their applications with, rather than having to depend on developing and testing under proprietary software.

Wine of course tries to offer a Microsoft Windows SDK on top of a Posix platform (such as GNU/Linux, xBSD, and I think it is being ported to MacOS/X). However, Wine cannot execute or be used to develop or use drivers or write low level free software for those familiar with Microsoft Windows. Wine also depends on translation, and so has the difficult problem that many of the underlying services and libraries it depends on were designed and behave very differently, and may well introduce new and different undocumented behaviors. This is part of why Wine still at most only supports well a specific subset of applications written for Microsoft Windows.

ReactOS offers the same underlying functions and behaviors. In fact, they are using Wine to support the upper level interfaces, so their efforts and Wine’s now do cooperatively overlap, for the benefit of both projects.

Finally, I imagine there are people out there who have software purchased for older releases of Microsoft Windows that no longer run on current versions. I have seen this phenomena with my neighbors children, where they have old educational games which will not run on the latest version of Microsoft Windows. The software certainly did not stop working, it is as functional as the day it was purchased. The platform it originally ran on is no longer available, deliberately removed from the marketplace, and the replacement will not run it.

What ReactOS has to offer in this situation is, oddly enough, greater compatibility. Even for those that write proprietary software, writing and testing it in the future using ReactOS will mean for them that they will be able to write and test software that works on the largest range of versions of Microsoft Windows as a result.

It will also mean that when or if Microsoft chooses to change or deliberately break interfaces to force software to migrate to their newest operating system release and also deliberately break their own development environments and platform sdk’s to force software built from them to require the same, while removing the older ones from the marketplace, these same companies will not be forced to follow this and have Microsoft dictate and control where their software will run or what market their software can be sold into. So ReactOS is important even to proprietary software developers today.

Some say ReactOS may slow GNU/Linux adoption, or development of pure GNU/Linux applications. This may be true, but I look at the question differently. Rather, I think it will further expand the total deployed base of free software as a whole. And this, I think, is a good thing.

Comments

01/31/06 @ 16:14
Very good article.
There are sensible reasons why ReactOS is vital,but there is also many more reasons.
My personal reason would be i have used windows for many years and know it well,i can fix every problem i`ve had,i have everything customised to how i want and most importantly i have all the software i wish to use (even better is 90% of it is open source/freeware).

Comment from: boohoo [Visitor]

01/31/06 @ 16:37
Instead of blaming microsoft for breaking old apps and demanding unconditional compatibility you could have just pointed to another instance of the evils closed source software presents - the provider goes out of business, no source==no updates==breakage, sooner or later. What kind of mess would any OS's kernel be if no stuff ever gets cleaned out? For an example where not enough stuff gets thrown out just look at the recent wmf disaster, all happening in the name of compatibility with ye olde win3.1...
(linux guy btw :)

Comment from: Allan [Visitor]

01/31/06 @ 16:40
Would someone please disclose a report on exactly what APIs are secret in the windows OS. I work on C windows software day in and out and have for 10 years and I don't seem to have issues finding information on MSDN for just about anything they have on their OS. To be successful Microsoft needs apps on their platform to make it popular so it will sell so why in the world would they hold back APIs we need to build apps with?

Comment from: David Sugar [Member] Ã‚Â· http://www.gnutelephony.org

01/31/06 @ 16:56
"...My personal reason would be i have used windows for many years and know it well..."

This is also a sensible argument. Free Unixes came out of proprietary ones in part because people already knew and understood Unix well from an educational background. Free software, however, is about a fundamental idea, and not about a specific platform.

"...you could have just pointed to another instance of the evils closed source software presents..."

It is true, I could have made the point more broadly, or used a different example, and maybe I should have. Because ReactOS specifically deals with the question of Microsoft Windows, I had chose to do so more narrowly and specific to that.

"...disclose a report on exactly what APIs are secret in the windows OS..."

There are apparently published books on this topic, as well as quite a number of articles. Just do a search for "undocumented windows api" and browse some of the 230,000 hits.

Comment from: Ged [Visitor] Ã‚Â· http://www.reactos.org

01/31/06 @ 20:59
Many of the undocumented API's aren't even listed on the internet, so a search will not find these.

Reversing the Windows infrastructure is the only way to uncover them. Consider the the number of undocumented API's in the kernel for instance.

Comment from: David Sugar [Member] Ã‚Â· http://www.gnutelephony.org

01/31/06 @ 21:49
"...Many of the undocumented API's aren't even listed on the internet, so a search will not find these..."

My impression was that he was trying to claim there were none at all, rather than actually seeking a single true and authoritative list of them. That's why I made the point of answering the way I did. Yes, you will not find a (complete) list that way, but you will get a good and honest idea of the magnitude of the issue.

Comment from: Howard Thomson [Visitor]

02/01/06 @ 00:46
Does anyone know why the sources for ReactOS are currently (apparently) unavailable ?

BC, and this is posted on the ROS website, it became known that some of the developers working on the project were privy to the leaked Windows 2K code that was on the WWW a while back.

Although all of those developers deny making use of that code in ROS, now a complete audit of the code must be done - which could take a year or more...

Once the portions of the code that are in question have been removed, what is left will be put into CVS.

As I agree that this could have been a very important project, as far as I can see, without a massive and herculean response and effort to save this project, the news is for all intents and purposes a bullet in the head for ROS.

Sorry if that sounds defeatist, but the reality is that ROS simply doesn't have the manpower or enough support to survive a year or even several years set back.

It's a crying shame.

Comment from: David Sugar [Member] Ã‚Â· http://www.gnutelephony.org

02/01/06 @ 16:30
"...but the reality is that ROS simply doesn't have the manpower or enough support to survive a year..."

This was one reason I thought it a good time to discuss ReactOS and why it is an important project. I happen to think they did the right thing, and clearly it was the harder choice, to go forward. It also demonstrates well the unique and viral risk of proprietary source code contaminating other people's work, whether accidental or through sabotage.

Comment from: StolenNomenclature [Visitor]

02/01/06 @ 22:33
The lack of resources and the magnitude of the task ahead for ROS (leaked Windows code aside) suggest it will be a very long time before a fully useable product is available. By then Linux will probably be so well established and Windows well into its decendency that I wonder will anyone really care.

I tend to feel that the window of opportunity for ROS is very small, and that they need to produce a useable near-final product within the next year or two at most. From what I know of the project, which I admit is not much, this does not look like an achievable time frame. Perhaps someone can put me right on this issue.

I tend to think that either the project acquires much larger resources or it might all end up being rather irrelevant.

Comment from: Jastiv [Visitor] Ã‚Â· http://www.jastiv.com

02/02/06 @ 04:16
I'm a bit of a dork, so I think better late than never with the ReactOS project. I don't care if the software no longer serves any useful purpose, nostelgia is fun. I'm a little disappointed it is windows NT rather than 98. 98 has way more software that can run on it. I wish I knew how to write code, then maybe I would help out, but since I havn't progressed much beyond "Hello World" that is a moot point.

Comment from: Marcus [Visitor] Ã‚Â· http://marcusvorwaller.com

02/02/06 @ 21:27
Jastiv,
The point isn't that they're going to be late, it's that they're behind a piece of software that's being actively developed and has more resources than they do. It's like they're on a bicycle trying to catch a bullet train--it doesn't matter when they start, they'll never catch up.

I also disagree with the author--ReactOS will never be a good testing platform for Windows applications because you can't reliably test something for Windows unless you're actually on Windows. Almost Windows or Windows compatible still isn't Windows.

I don't think they're either helping or hindering OSS. It's an interesting hobbby project that is probably teaching some very smart people some useful programming skills. The software probably won't ever be used by a large audience, but the developers will probably take a lot away from the experience and be able to better contribute to other OSS.

Comment from: dugg [Visitor]

02/02/06 @ 23:01
though riding a bike and moving to a motor bike are not the same though they both use the same skill set that you would need to compliment the set no? similar and alomst are not quite it but does make something useable and easier to guess where things are going wrong...

Comment from: um [Visitor] Ã‚Â· http://hmm.com

02/03/06 @ 02:28
and search online for "linux error" and you'll find even more hits.

this is just petty and childish.

Comment from: Anon [Visitor]

02/03/06 @ 04:17
Comparing a search for "Hidden API" with a search for "Linux Error" is a petty and childish comparison itself.

If you look at 99% of the hits you get with Linux errors, you will find that it is a new user trying the OS for the first time, and they have configured something wrong. Yes, Linux can be more complicated, but simplicity does not equal functionality.

Here's the real search you should do - compare which OS has a solution of "restart the computer" more often (though I dare not think of that as a solution).

Comment from: David Sugar [Member] Ã‚Â· http://www.gnutelephony.org

02/03/06 @ 12:03
"...Comparing a search for "Hidden API" with a search for "Linux Error" is a petty and childish comparison itself..."

I agree. The point of the search I originally suggested is that even on the very first page you got references to published books and other immediately useful references to a topic the original poster seemed to claim did not exist at all. Of course, if someone said like that there is no such thing as Linux "errors" at all, maybe that would be an appropriate search to suggest.

"...Almost Windows or Windows compatible still isn't Windows..."

Microsoft Windows is not generically compatible with itself from one major release to another. Wine, by contrast, and for this reason, both targets and allows switching to directly emulate different effective versions of Microsoft Windows. Combining this with a base platform (like ReactOS) that is not a "specific" version Microsoft Windows, but that if one writes to and tests under and it forces one to use documented or documentable functions also assures a program will run on most or all Microsoft releases and can then more easily be ported or converted later to another platform since it has no undocumented behavior, is very useful, because Microsoft itself does not offer such a platform. Hence "almost" Microsoft Windows I think is actually better.

"...I'm a little disappointed it is windows NT rather than 98..."

Hmm, maybe by using freedos at the bottom, and wine for the application facing api's at the top, one could write the remaining pieces in between and actually accomplish this. Is this a worthwhile project? Some may think it is a horrible idea, but I think what is important is having the basic human freedom to do this.

Old thread ... but ... I'm with Allan here. I've been coding on Windows platform since Win3.1 days and I've not had a moment where there are some hidden APIs that my app require and this lack of access caused a stop or delay in my development.

While I've not done a comprehensive test, I would think that the so-called "hidden" APIs would be system library calls that is meant to be called *only* by other system / kernel components. Applications are meant to be developed against a set of APIs instead of talking to the lower layer or hardware directly. Like it or not, that is the architectural design that Microsoft adopted for Windows. One can dislike it, but to say that its hidden and hence wrong, is really ... unreasonable.

If however, a non system app (eg, Microsoft Office) written by Microsoft accesses such system library calls that is not part of the API set released to 3rd party developers via SDKs, then this is not right. We can argue till Windows is superseded by some OS in future that Internet Explorer is not a system app, but the way Windows is structured, it is quite a part of the GUI shell, which in the Windows architecture, is part of the system. Again, we can dislike such a design, but if we use our design philosophy and start accusing them of having hidden APIs because of that, then we are arguing on a wrong premise.

Having said that, I would be happy to see a list of *hidden* system library call that is made by a non system app written by Microsoft.

This would mean that Microsoft Word is indeed having access to hidden APIs that is not released to 3rd party developers. This would in fact not just be a case of hidden APIs, but can be used as proof for further case of Anti-Trust infringements.

Point in case, PalmOS also have a set of hidden, or not so hidden calls, system traps (interrupts) that is not officially released, but are utilized by the series of Hacks apps that extend the functionality of Palm apps. Later versions of PalmOS changed the lower layer kernel to a large extent, and a large part, if not all, of these system traps disappeared. Some of these changes were due in part to the migration of Palm pdas to ARM processor from the DragonBall processor, others were due to architectural changes. As a result, many of these hacks broke and would not run on the newer PalmOS.

Under the Palm OS SDK, one would find a list of such system traps that are *undocumented* and declared 'for-system-use-only'. Microsoft may have chosen not to expose any such list. But as mentioned, if anyone can prove that Microsoft non-system applications are accessing such APIs, then there is a case for not just blog accusation, but an Anti-Trust lawsuit.

Until then, I see it pointless to keep harping that there are some hidden APIs.

Actually, if GNU/Linux becomes the dominant platform (and I think it's optimistic to think this will happen in just 2 or 3 years -- I suspect it will take anywhere from 5 to 20 years, depending on your definition of "dominant"), and Windows itself is effectively dead, then ReactOS will be even more relevant, because it will be the only consistently maintained way to run old Windows applications (well, unless they run in Wine on top of Linux, but that is nearly the same thing, and some apps will likely require ReactOS).

I like your point about the "viral threat" of proprietary code. It's absolutely true that proprietary code is every bit (or more) devastatingly "viral" than any free-licensed code.

Recently We are doing a migration project from windows environment to linux or Open Source environemtn as Microsoft licenced software are much priced
Would any body please inform me other projects like Wine and ReacOS that does not require a microsoft license to run windows based local applications ...

With the upcoming V*sta bloatware, I think that ReactOS may have some small window of opportunity to progress. And since it is open source (I hope they will *publish* the source code), it may well exist when M* W*ndows will have been diminished by the Open Source Ecosystem (GNU/Linux etc) - M* W*ndows stands no chance with Open Source, because it is a stand-alone product, against an ecosystem that never ceases to develop and extend.

Consider how M* W*ndows is surrounded by open source: GNU/Linux on OS-level, OpenOffice.Org on the Office application suite level, Firefox on the browser application level, etc. That is, open source is beginning to "struggle" W*ndows. And it has no chance to survive, because the open source ecosystem pool, will continue to fill.

Author information

Biography

David Sugar is an active maintainer for a number of packages that are part of the GNU project, including GNU Bayonne. He has served as the voluntary chairman of the FSF’s DotGNU steering committee, as a founder and CTO for Open Source Telecomm Corporation, and currently owns and operates Tycho Softworks.