Skip Navigation
Linux @lemmy.ml
Lost_My_Mind @lemmy.world

Wouldn't development of ReactOS from a larger community ultimately help ALL OS's?

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?

43 comments
    1. 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)
    2. Companies have no reason to fund it, wine does everything they need plus enterprise software is being produced for Linux
    3. Regardless of how "clean" ReactOS is they cannot legally reverse engineer Win10 or Win11 due to the EULA (which Microsoft would enforce in court)
    4. 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.
    5. 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.
    6. 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.

  • The question is, what applications would run in ReactOS that wouldn't run through Proton/Wine? Some applications require relatively obscure userspace quirks and tricks, in which case it doesn't matter if they're running through Linux+Wine or ReactOS+Wine if Wine doesn't implement them.

    Other than that, the rootkit anticheat that makes so many games not run on Linux are written by companies that have a near hostility towards Linux and open computing in general. If some version of their anticheat happened to work in ReactOS, they'd patch that out super fast. Same with DRM stuff.

    Linux and Windows are, I think, too different conceptually to copy things from one to another. And I'm not sure what Linux-compatible innovation that ReactOS would have that hasn't already been thought of. Performance of the Windows kernel is, at best, average.

    • Linux and Windows are, I think, too different conceptually

      That is correct. Linux is a UNIX variant/clone, one of many. UNIX isn't just an OS, it's an entire concept on how to build and organize an OS. People keep wanting it to be Windows, but it will never be Windows. I wish it could just stand on its own as a flexible, open, UNIX-like system with its own strengths, not just be a drop-in replacement for Windows on the desktop. Let's make the UNIX way of doing things the normal, everyday way of doing things.

    • Some applications require relatively obscure userspace quirks and tricks, in which case it doesn’t matter if they’re running through Linux+Wine or ReactOS+Wine if Wine doesn’t implement them.

      I thought the whole goal of ReactOS was to get to a point where wine isn't needed at all. You just take the .exe installer, and install it. Just like windows.

      The issue is that they're so poorly staffed that they're waaaaaay behind on what Windows considers modern. They're doing an impressive job reverse engeneering, but it's still a 20 year old system. They partially rely on wine currently because of how unfinished THEIR work is.

      But my vision is that thousands of people each contributing small little bits here and there, all contributing to the code of ReactOS. Eventually they could move beyond XP, into Windows & era, and Windows 8 era, and Windows 10 era, and Windows 11 era. But since it's NOT microsoft, and since it's NOT windows, it wouldn't come with any of the stuff people hate about those versions. It would come with the compatibility, but not the forced spying, or the bloat, or the forced subscriptions.

      The thing I read is that Windows 95 was composed of around 1000 people all working towards the same goal, with the same tools, at the same time. All getting paid as their full time job. ReactOS has about 30 people, who are all fighting with each other. Their last stable release was 2021, but they do have nightly builds that are "current". But with so much infighting, and so few people, and not being a full time priority, it doesn't get the support it should.

      As far as what linux would gain by ReactOS reverse engeneering modern day OS's? It would mean ANY program that was originally intended for windows could be installed via the .exe file, on ANY linux distro. Using the same gui setup that windows users know how to do. Which in turn would make it 1000% easier to convince a new user to switch from Windows to Linux, if you could say "You can run all the same programs, you already know how to use it, and it's free." THAT would be the game changer.

    • what applications would run in ReactOS that wouldn’t run through Proton/Wine?

      Drivers and usb hardware support are the main things ReactOS currently are better positioned to support that I know of.

  • 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.

43 comments