Linux

48668 readers

427 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
No misinformation
No NSFW content
No hate speech, bigotry, etc

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago

MODERATORS

[email protected]

Wouldn't development of ReactOS from a larger community ultimately help ALL OS's? (lemmy.world)

submitted 1 week ago by [email protected] to c/[email protected]

43 comments fedilink hide all child comments

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?

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 10 points 1 week ago

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.