So, if you’ve never heard of ReactOS, it’s an alternative to Windows, except it’s open source, and reverse engineered.
The end result is, if it works on Windows, it works on ReactOS natively.
Now, as you might imagine, there are some issues with this. The most glaring one being that they’re currently in the year 2003. That’s the level they’re at with software. It’s not even emulation. It’s running the software natively, and it’s written from scratch.
But my takeaway is that Linux running windows apps natively would improve people’s hesitation to running linux.
Now since ReactOS is FOSS, any improvements made upon it could then be forked over to Linux. And if someone made a ReactOS fork, that isn’t linux, that’s good too (as long as it stays open source). Any advancements made by this new theoretical fork of ReactOS could ALSO be forked into linux.
Right now, development is slow, because it’s a community driven effort without much of a community. If it had a large and engaged community, all legally reverse engeneering the ways of windows? That would allow basically EVERY OS to have FOSS unofficial native windows support.
So I guess my question is, for an OS that’s been in development since 1998, why doesn’t the linux community embrace ReactOS?
- Microsoft hasnt sued ReactOS only because its not significant enough for them to care about (a few Windows devs have confirmed that some ReactOS code looks stolen)
- Companies have no reason to fund it, wine does everything they need plus enterprise software is being produced for Linux
- Regardless of how “clean” ReactOS is they cannot legally reverse engineer Win10 or Win11 due to the EULA (which Microsoft would enforce in court)
- Even if ReactOS has 100% compatibility (highly unlikley) it doesn’t means Linux will as well. In addition companies would add checks to drm to ensure a legitimate Windows kernel is used so we would just end up where we started.
- The only thing we would gain is an open source nt-based system, this would be immediately rejected by the POSIX purists if anyone tried to add it to Linux. Linux isn’t Unix based because NT is proprietary, people like the Unix standard.
- Not only is the means flawed the ends are arguably worse. Linux does not need to be like Windows/MacOS, Linux does not need complete compatibility Windows/MacOS software, and tbh Linux doesn’t need more Windows/MacOS users because objectively Linux is not Windows/MacOS. We arent helping older users bg watering down Linux, we arent helping new users by tricking them, and we arent helping future users by convincing them on lies.
I think, your expectations are off for what a native integration would achieve. A kernel which has both a Linux API and a Windows API would be an insane maintenance effort. You’d naturally want the Windows APIs to simply be translated to the respective Linux API calls. This is what WINE does.
In theory, if it’s directly integrated, you could do some dirtier stuff, i.e. call kernel-internal APIs, but you want to avoid that as much as possible, since those kernel-internal APIs are not nearly as stable as the public APIs.
It should also be said that writing kernel-level code is hard. You cannot ever crash, you cannot ever make mistakes when managing memory, you cannot allow yourself any vulnerabilities. Again, you want to avoid writing kernel-level code, if you can.WINE has some additional ugly workarounds, like a virtualized filesystem. There’s not terribly much you can do about that. Windows applications may simply expect certain folders to be in certain paths. You can’t directly map that to a UNIX filesystem.
As far as I can tell, pretty much the only advantage of natively integrating it, would be that it’s installed by default, which can be achieved in other ways (distros), and due to those ugly workarounds will not be popular at all. As much as I’m touting its horn right now, I do not want WINE on my system, unless I need it.
It’s easy to be frustrated with WINE, because it does not handle all applications perfectly, and then think that the approach is just wrong. But yeah, no, some really smart folks came up with that approach. It’s just insanely hard to get the exact (undocumented) behavior of the Windows kernel APIs correct, whether you do a mapping or implement them natively.
You ever heard of Wine? The majority of work to make Windows apps work on Linux is not with ReactOS. Last time I tried ReactOS it was more like a nostalgic OS for people to remember the good ole days of minesweeper. It wasn’t a serious project to actually become compatible with modern Windows. Even if it was, I wouldn’t trust the authors to do so. Wine however has made serious progress and there are multiple Windows apps that now run on Linux as a result. The Linux community should not embrace Windows. Microsoft needs to embrace the Linux community & make their source code open enough and documentation good enough to run Windows software on Linux natively. Otherwise you’re doing free work for a company that will be acting hostile towards you, and it just isn’t worth it. You’d be better off at that point at convincing software makers to make their apps compatible with Linux or using a hypervisor.
Wine already exists and can run pretty new Windows software. A fork also exists for MacOS and the other BSDs can also run Wine.
Running Windows apps on Linux natively seems impractical to me, the OSes are structured very differently and I’m fairly sure this would introduce many hard to fix CVEs.
ReactOS does actually submit patches to wine sometimes because they use parts of wine! But they have their own windows-like kernel so they only need wine for userland, not the whole thing
WINE does run wiindows apps natively on linux.
I don’t have a substantial opinion about ReactOS. I’m aware of it, but that’s as far as I’ve ever gone.
However, I wanted to compliment you because that was a great opener to this discussion. 🙂
Probably because they’re afraid Microsoft would sue to shut it down. As you said, right now they’re nowhere near competitive with Windows.
Yes but it’s so easy to run most Windows workloads on a VM that most people would just do that instead of doing the work to implement the needed APIs in Wine (ReactOS). I’m capable of doing such work. I can’t be bothered since everything I need runs alright in KVM. Valve takes care of games via their work on Proton (Wine). We often do this in the Linux world - reach for imperfect, easier solutions, then stack em on top of each other to form not that pretty yet stable Jenga towers. 😂
Running Windows on a VM requires significant RAM & usually an extra GPU to make both operating systems work anywhere close to equivalent in terms of performance. Even then, the hypervisor can still cause issues with enterprise software and licensing.
Yes but most machines these days have a ton of RAM and 4-8 CPUs. GPU is only required for 3D accelerated work. I think the standard QXL virtual GPU works fine for non-accelerated purposes. No idea how often licensing could be a problem. Haven’t had issues myself but I don’t use much proprietary stuff. Your standard MS Office, Adobe, AutoCAD stuff works fine to me.
What’s the point to reactos? I don’t want to just run windows applications, I want to run Linux. WINE is the better approach. I can run windows applications and still run Linux.
