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?
I think reactos is just in a weird space of semi uselessness like haiku. It’s not good enough to use daily and doesn’t have as much retro appeal as game emulators so not enough work is done to it.
Also building reactos is terrible, or at least was years ago (it’s a whole os and userland after all, I know it won’t be simple). If the development workflow improves the project could get off the ground.
As far as posix support goes I would love to see reactos get to the point where a posix nt personality could be real again, but really I think humanity has learned enough about operating systems to build a new one from scratch instead of liberating proprietary tech at great cost.
Mainly because Reactos only runs windows XP apps in this current state (Maybe we can trick apps into thinking its a windows 11 pc using winecfg??)
- 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.
Regardless of how “clean” ReactOS is they cannot legally reverse engineer Win10 or Win11 due to the EULA (which Microsoft would enforce in court)
Its possible for them to clean room reverse engineer Windows 10 or 11 it minimizes the risk down to only patents.
Regardless of how “clean” ReactOS is they cannot legally reverse engineer Win10 or Win11 due to the EULA (which Microsoft would enforce in court)
How would they prove the developer signed an EULA? I know I haven’t been made to use Windows since the Vista era. And even then, that was a work computer so I never agreed to anything.
The rest I agree with. Windows is trash, why bother cloning it? Wine exists to run applications that are desired but don’t have Linux equivalents.
If any of the developers have a Microsoft account with their legal name and have used that to set up a Windows 10 computer (highly likley) they can be sued. Also my point is not only is Windows trash the fundamental technologies its based on are trash too, Unix Based systems will always be superior to NT/DOS based systems.
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.
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. 🙂
