It’s been over three years since the last ReactOS release, but today, in honour of the first commit to the project by the oldest, still active contributor, the project released ReactOS 0.4.15. Of course, there’s been a steady stream of nightly releases, so it’s not like the project stalled or anything, but having a proper release is always nice to have.
We are pleased to announce the release of ReactOS 0.4.15! This release offers Plug and Play fixes, audio fixes, memory management fixes, registry healing, improvements to accessories and system tools including Notepad, Paint, RAPPS, the Input Method Editor, and shell improvements.
↫ ReactOS 0.14.5 release announcement
There’s a lot in this one, as the long gap between releases indicates. Thanks to the major changes in the plug and play subsystem of the kernel, ReactOS now supports more third party drivers, and it can now boot from USB and chipsets with EHCI, OHCI, and UHCI controllers. The open source AC’97 driver from the Windows Driver Kit has also been ported to ReactOS to enable sound on VirtualBox and old motherboards. The open source FAT driver from the same WDK has also been ported, which is a massive improvement over the old one. ReactOS can now also make use of custom IMEs, ZIP archive support has been integrated into the shell, and a new default visual style has been chosen.
There’s a lot more in this release, though, and since it was branched over six months ago, there are a lot of improvements from since that time that are not yet part of this release, like a graphical installers, UEFI and SMP support, new NTFS driver, and a ton more. In other words – don’t let the long time between releases fool you; there’s a lot going on in the ReactOS world.
The install is blazingly fast and a fresh system is both snappy and attractive. I just don’t expect ReactOS to ever become truly usable as a fully compatible, stable operating system, at least not in my lifetime, so I’ve pretty much given up on it and written it off years ago. The included themes are nice though, especially the one they now use by default, and in my opinion the classic Windows theme/look is a timeless classic.
UltraZelda64,
I’d love for react os to work for gaming and other windows applications I can’t avoid. I am still very supportive of the idea of reactos, but in practical terms it’s a perpetual alpha and every time I test it I quickly shelve the idea again over crashes and compatibility.
My son has been asking to play some windows only games, no they don’t work with wine/proton I might give reactos a shot again although I don’t know what to expect especially if DRM/”anticheats” are involved.
I totally agree, after having been watching the project since the early 2000s. Although since I have been using Linux exclusively for over two decades now there are no Windows applications I truly can’t avoid; for me it’s more along the lines of Windows applications I’d like to be able to use for nostalgia purposes. But even a lot of Windows applications from the 90s and early 2000s can’t run on ReactOS without bringing the entire OS down, and often run better in Wine on a standard Linux distribution. I don’t dare try running something more complex like games–many basic ones which can actually run in Wine pretty decently.
Honestly, your best bet is to just keep checking Wine support for the games you’re interested in. They’re much more likely to start working there before ReactOS, and without bringing your entire system down in the process. ReactOS is such a great idea, but at this point it feels like it’s always been just too good to be true.
UltraZelda64,
Unfortunately modern games would be a forever fleeting target for Wine, let alone ReactOS.
As mentioned, the competitive ones depend on kernel “anti-cheat” (read: remote rootkits that monitor the system). And most popular ones are in this category.
For newer games, they want modern APIs, which may or may not have a fallback.
Yes, Proton is a great step forward. But unless more developers take Linux seriously, it would still be playing catchup.
(To be fair it runs many older games better than Windows. Backwards compatibility was a cornerstone of Microsoft, but they have been regressing a lot lately).
This is simply not true – not some future thing, modern games run great on Proton (Wine), and that includes with modern APIs. I run brand new games regularly on Steam Deck and Bazzite – and they mostly run BETTER than they do on Windows. Valve is now successfully selling it’s Steam OS to third party hardware vendors, and there’s more than a few rumors about new hardware coming from them. I’d wager, the more popular these platforms become, the more likely you are to see at least native Vulcan support in games, in the near future (Vulcan is plenty “modern”), if not native Linux support.
Even when there is some catch up to do with some new release (some stuttering in FF7 Rebirth for example), we are talking weeks, not the traditional years we used to see, for updates.
I will acknowledge that there are issues on Linux – things like AMD’s inability to support HDMI 2.1, or the general nvidia problem – but there are also clear advantages – sleep on Bazzite, compared with Windows, for one big example. It’s night and day. Also, Linux subsystems and software distribution models, are LIGHTYEARS beyond Windows at this point. It’s not even close.
And then there’s the curve argument. You gotta look at the right part of the curve. Microsoft can add new APIs to its stagnant Windows platforms (the new RTX thing), but that’s not going to matter much if they can’t ship it in the modern multi-platform world. People game on too many different devices to use a Windows (and XBox) only API. That world where Windows is on top because of its innovation – Microsoft killed that more than a decade ago. It’s over.
CaptainN-,
Obviously many games do work since wine/proton mostly support the APIs most games need, but as sukru points out those with DRM/anticheats are particularly troublesome. Take roblox as a popular example, which even has a project dedicated to trying to get the game working on linux. If you actually install and run it, it pops up an error saying that it’s currently broken.
https://sober.vinegarhq.org/
It’s not that the game is genuinely incompatible, it’s the DRM and anticheat mechanisms that are incompatible. This is, and probably will remain, one of the bigger obstacles.for the foreseeable future.
I would agree with you that getting official support is a matter of OS popularity, however the majority of studios don’t care about officially supporting linux gamers at current levels. This link goes into detail how the game has gone from working to broken several times and includes statements from the developers that they could support linux if it became popular but there are no plans currently.
https://roblox.fandom.com/wiki/Roblox_on_Linux
Gaming on linux has improved dramatically thanks to steam’s efforts, however linux still gets treated like a second class citizen in the industry. I’d like to put more pressure on publishers to support linux, but it’s just one of those things where the user base may not carry enough weight to demand it.
I mean, this is technically correct, if you pretend Proton doesn’t exist.
Kernel level anticheat is a big issue with multiplayer games, 100% true. Not everyone plays multi-player games, although most do I suspect.
if you consider Proton – AAA single player games are regularly supported day 1 on Proton/Linux/Steam Deck.
Yes,
Looking at the top-10 most played Steam games right now.
Playable: 4 (including Counter-Strike and DOTA, both of which owned by Valve)
Unsupported: 5
Verified: 1
That is not a very good outlook. Granted one of the unsupported “games” is a Windows utility (Wallpaper Engine), however being a top title on Steam, it, too might have benefited from better Wine support.
At the end of the day, protobdb itself gives similar statistics.
And my personal library is cited to be 28% supported only.
Don’t get me wrong, it is a great achievement compared to what we had before. It used to be close to zero percent, except open source ports like Quake and Doom.
But we still have a long way to go.
Congrats to Eric, but imagine working 26 years on project, that still is unusable and in alpha stage. That’s a real dedication
It’s a matter of scope. Linux is only a kernel, but ReactOS has to be a desktop and a kernel, with binary compatibility. Much more work, but would eventually be a realistic open source alternative desktop.
Haiku also has to be a desktop and kernel, and Haiku has long been in much better shape than ReactOS. To be fair, small parts of the system were open sourced like the tracker, but still, the kernel and other large aspects had to be redone from scratch.
And it’s not like ReactOS has to implement literally everything themselves either. They have been fortunate to be able to piggyback on Wine’s success, for example. And yet, when it comes down to it, I’d say that Haiku has long been in a much more usable condition than ReactOS.
I like what they do, but after a quarter of a decade, when you’re better off just running Wine in Linux because the OS itself (ReactOS) so quickly becomes unusably unstable, I can’t help but think something is up.
Wow, quarter of a decade? Big mistake of words! I meant quarter of a century. Oh well, too late to fix now.
Haiku and ReactOS are two completely different OSes though. Haiku was trying to clone BeOS, which was quite well documented, and also a BeOS kernel developer developed the NewOS kernel, which Haiku was based on. Haiku had a lot of fortune in that BeOS developers banded round the project and made it the success it currently is.
ReactOS on the other hand, has none of these things. The NT kernel itself is notoriously badly documented, and Microsoft developers are expressly forbidden from working on the OS due to copyright issues.
I have to support a lot of legacy devices / hardware that has drivers developed and targeted for MS-DOS, Win 95, 98, NT or XP, etc., etc.. The current solution to keeping these systems functioning and safe is to air gap legacy installs on vintage hardware, but the vintage hardware itself is becoming harder and harder to find.
If ReactOS can achieve it’s goal that will be a huge step up, Wine on Linux is not and never will be the answer to some problems.
cpcf,
ReactOS is currently more of “FreeDOS” of Windows compatibility. So I would give it a try.
Even though it does not run the latest applications with modern APIs as well, it has native support for NT drivers and filesystems.
https://reactos.org/wiki/Install_a_driver
Windows XP ones would be a good starting point.
@sukru, I have give it run before and had some limited or intermittent success, much of the time I have to combine some hardware hacking with legacy installs, sometimes it works sometimes it won’t. While most sites are busy discussing overclocking, I’m often investigating a slowdown.
In fairness it’s rarely just an OS issue, hard coded timing bugs in drivers are probably our biggest unsolvable problem, because even though we need to slow the clocks / bus we still need accurate time / timing for many systems.
If hardware devs want a gadget to live a long and healthy life, even perhaps a museum retirement, think in cycles not milliseconds!
I think ReactOS is considered to have a simpler starting point than other alternative operating systems, because it can benefit from the drivers and software of MS Windows.
In practice, it is the opposite. ReactOS is considered useful if one can run software designed for another operating system that changes constantly. Drivers and software for XP was not compatible with 8 and much less with 11.
Compatibility is a hindrance that prevents ReactOS from focusing on system development itself. At the same time, if it is not compatible with Windows, what’s the point of ReactOS?
It is not really a moving target for them. ReactOS targets compatibility with Windows Server 2003 which I think you will agree is not changing much these days. The software that will still run on Windows Server 2003 is not changing much either. For example, ReactOS is still 32 bit.
There is a 64 bit port in the works. However, ReactOS lacks Wow64 and so the number of things that will run on that is similar to Windows XP 64 bit (so nothing). There is also experimental support for some NT6 APIs. At some point, I imagine they will shift the target to something more modern. The problem of having to “keep up” is probably still years away.
At this point, ReactOS is a lot like ArcaOS is to OS/2. It is a way to keep your really old stuff going. Still cool though.
Good on them, this is a giant and enormous technical challenge.