ReactOS is celebrating its 30th birthday.
Happy Birthday ReactOS! Today marks 30 years since the first commit to the ReactOS source tree. It’s been such a long journey that many of our contributors today, including myself, were not alive during this event. Yet our mission to deliver “your favorite Windows apps and drivers in an open-source environment you can trust” continues to bring people together. Let’s take a brief look at some of the high and low points throughout our history.
↫ Carl Bialorucki at the ReactOS website
OSNews has been following ReactOS since about 2002 or so (the oldest reference I could find, but note that our 1997-2001 content isn’t available online, so we may have mentioned it earlier), so you can definitely say we all grew up alongside ReactOS’ growth and development. All of the events the team mentions in their retrospective on 30 years of ReactOS were covered here on OSNews as well, which is wild to think about.
Personally, I don’t really know how to feel about the project. On the one hand, I absolutely adore that dedicated, skilled, and talented individuals dedicate their precious free time to something as ambitious as creating a Windows NT-compatible operating system, and there’s no denying they’ve achieved incredible feats of engineering few people in the world are capable of. ReactOS is a hobby operating system that survived the test of time where few others have – AtheOS, Syllable, SkyOS , and so many others mentioned in that oldest reference I linked to are long dead and gone – and that alone makes it a massively successful project.
On the other hand, its sheer ambition is also what holds the project down. If you say you’re going to offer a Windows NT-compatible operating system, you set expectations so insanely high you’ll never even come close to meeting them. Every time I’ve seen someone try ReactOS, either in writing or on YouTube, they always seem to come away disappointed – not because ReactOS isn’t impressive, but because it’s inevitably so far removed from its ambitious goals.
And that’s a real shame. If you take away that ambitious goal of being Windows NT-compatible, and just focus on what they’ve already achieved as it stands now, there’s a really impressive and fun alternative operating system here. I really hope the next 30 years will be kind to ReactOS.
I absolutely love ReactOS. The project fills a dream of “running legacy Windows software” (especially “released once” software for closed-source engineering hardware) , but in a minimal slimmed down open-source environment.
The problem is, every single time I try to shove it in as a solution… it fails me. Either application incompatibility (Not ReactOS’s fault), or hardware incompatibility/instability (Still not ReactOS’s fault.. hardware support is a difficult beast to conquer.) I’ve spent around 15 years professionally trying to use it for random legacy stuff… I haven’t been able to make it work in a viable way as a solution (even stop-gap) a single time..
I wish an angel investor with more money than they need would step in and fund some full-time developers for this.
A few years ago they approached the Russian government for funding, but I don’t think that ever came through. Putin had less humanitarian priorities…
Pretty sure they randomly met Putin at a convention and he asked them how much it would cost to complete it. They said 2 million, and that was largely the end of it. Seems some Russian universities have their students work on it a bit, but nothing more came of it.
The usual reason for an application incompatibility in this situation would be some incomplete/inaccurate reimplementation of Windows functionality in ReactOS. So I’m puzzled why anyone would think that the majority of application incompatibilities aren’t ReactOS’s fault.
Because a lot of old Windows applications violate the API contract, this is the reason they have trouble running on modern versions of Windows. They don’t use the official APIs instead rely on internal (API meant to be used only by Windows), private (meant to be used only by Microsoft), and side effects of how Windows was implemented (meant to be used by no one). Microsoft used to bend over backwards to cater to these applications at the expense of a ever increasing engineering debt. The reason why it isn’t ReactOS fault is these applications were never valid Windows applications in the first place (just because it works for you doesn’t mean that it isn’t broken).
There are reference books specifically about undocumented Windows functions, and those functions were/are used by applications such as Microsoft Word, which I don’t think have ever been characterized as not being valid Windows applications.
You can think of Win32/Windows as a superset of Win32. Just like POSIX/Linux is a superset of POSIX. Not all Linux software is portable and transferrable between other UNIX likes, and it shouldn’t be surprising that Windows has the same problem. Even if ReactOS was 100% compatible with all of NT5’s publicly available APIs, there will always be software that uses undocumented quirks or other “hackery”, just like a 100% POSIX compatible OS isn’t going to run every available piece of software available for Linux.
Exactly.,
There is a great blog on this (the old new thing)
People wrote broken applications all the time. And dedicated teams at Microsoft wrote “patches” to fix them at runtime.
The most famous one is SimCity. It was crashing on Windows 95 when upgraded from Windows 3.1. Turns out it had a use after free bug, and Windows 95 had a better memory manager, catching the issue (and of course crashing the binary)
Solution?
They had a copy of Windows 3.1 memory manager, and loaded that when SimCity was detected.
There are many, many, many more stories like that. And that is why Windows comes with gigabytes of “app compatibility” shims.
People don’t say “thank you Microsoft for checking things better, and finding a bug in the software I have. Now Fraxis has to give me a patch”
But they say “hey, Windows 95 broke my game! It was working perfectly fine before!”
I love ReactOS and what they are trying to do is certainly very difficult but it is hard not see the slow pace as a failure on their part as well. I used to watch the project very closely and was often dismayed at how hostile the project seemed to be to newcomers or outsiders. Compare that to something like Haiku and the difference in progress did not seem accidental. Even the development target, Windows Server 20023 32 bit, felt like a project not listening to its community. They would come down hard on even a suggestion that this was something to think about.
That said, the last couple of years have felt a bit different. There seems to be some fresh blood and it feels like more progress. Not only did they ship 0.4.15, unlocking literally years of development but they are starting to open up to being something people would actually use. There is a 64 bit port, there are NT6 APIs being added, they are syncing with the latest Wine, there is UEFI, and there is even some work towards WDDM. They just announced a significant performance boost just days ago. Crazy stuff.
If ReactOS was able to release a 64 bit system that could even run modern web browses and a half-way modern Office suite, it would go a long way to convincing people it could be viable again. There is a lot of ill will towards modern Windows. Who knows, maybe ReactOS still has time to provide an alternative that a reasonably large audience wants.
Not that there are not challenges. I have no idea how hard WoW64 is going to be given what Wine has done.
Anyway, I wish them luck.
While UEFI, NT6, WDDM would be nice, past experience tells me these things are years off from being finalized and merged into the main repository, especially WDDM.
Unfortunately I will also state the ReactOS project is a failure.
If you want to run Windows software in an alternate OS, may as well run Linux with Wine.
For ReactOS to be successful, it must offer something that Linux doesn’t have. That means ReactOS has work with all 3rd party Window10 64 drivers. Person should be able to buy USB device with Windows drivers and be absolutely 100% confident it will work with ReactOS. With Linux there is usually some doubt if a device will work. Please correct me if I’m wrong but I don’t think any Linux distribution has a clear Hardware Compatibility List.
ReactOS doesn’t seem to have a Hardware Compatibility List. Especially for graphics cards, it would be nice if they clearly listed what they actually support. If ReactOS is only running in emulators and not real hardware, that is a failure unfortunately.
That’s because the idea is that it’s Windows. The target was that you just can install a closed source Windows driver.
AnAmigian,
Yes, the binary driver support in ReactOS was the main differentiator. And I think it is still valid for some industry / embedded use cases.
However for regular hardware, I would say Linux has better support than Windows. At least it would not download a 1GB “driver” with electron embedded and opens a rootkit to the internet.
From the download page: “Please note, that ReactOS is still in alpha and gives no guarantee of stability, safety of your files or working at all.” Wow! 30 years and still in alpha… what piece of shit!
I see the Microsoft shills are out in force.
Currently I only see 2 feasible uses for ReactOS. One if replacing aging computers that control things like that 100.000$ medical appliance that runs Windows XP or Vista and that is no longer supported. The other something like Docker but for single Windows apps.