ReactOS "Open-Source Windows" Making Good Strides On SMP CPU Support

[jindam]

i am wondering, whether project is receiving funds from US corporations

[Quackdoc]

i am wondering, whether project is receiving funds from US corporations

they should be, considering how many people are still relying on windows xp era stuff, a drop in replacement should be highly desirable

[Ironmask]

i am wondering, whether project is receiving funds from US corporations

It's kind of a hard pitch. "Hey boss, check this OS out, after two decades of development it only crashes most of the time instead of immediately at boot!"
It's much cheaper and more sane to just port old systems to modern platforms, since if your infrastructure is based on Windows XP, it's probably modern enough to be ported. Or better yet, just rewrite it all since if your infrastructure is 20 years old it's either probably isolated enough to be a timeless black box, or already the victim of an attack due to security vulnerabilities.
If I were running a company and I looked at my aging infrastructure and my dwindling venture capitalist funds, I would rather just port it or emulate it, but definitely not pour it into what only appears to be some esoteric bottomless pit of a hobby project. The other big tech companies don't need it, because: Google has Linux, Meta has Linux, Microsoft is Microsoft, Apple has macOS, Oracle has Linux. And the US government doesn't need it because they just pay Microsoft to keep supporting Windows XP anyway.
It would help if ReactOS has a Red Hat of it's own to be it's business and support, that's how Linux became usable in the business world. But it doesn't have that. And one of the biggest reasons companies use software is for it's support. Windows XP may be out of support, but it's not like ReactOS simply existing while it also has no support makes it any more attractive.

[Developer12]

Wine is purely userspace, and is designed to work with a linux core. That includes things like systemd, and other linux alternatives to Windows processes. There are hundreds if not thousands of Windows OS components that live below userspace, but not in kernel space, that Windows applications rely on just like Linux. My idea was to have the Linux Kernel, with maybe an out-of-tree patchset that implements Windows kernel APIs using existing Linux codepaths as best you can, then re-make all of the "OS layer" tools as well. Wine libraries can be used for userspace, just like ReactOS is doing it, but not Wine itself. Otherwise, there'd be no reason for ReactOS.

Do you have any idea how wine even works? Wine already emulates everything from the application down to and including the kernel itself, the entire windows stack, in userspace. It's not hard. Windows applications never invoke the kernel directly but instead use a DLL that wine provides a replacement for.

Nothing you have suggested will ever allow you to run windows drivers, a core advantage of reactos. The linux kernel has a very, very strong policy of NEVER EVER exposing a stable driver interface, rendering the loading of windows drivers categorically disallowed. This is still true even if someone was willing to put in the legwork to implement the windows driver interface.

And "jumping" to Windows 10 is not stupid. The most popular apps on the platform do not utilize older APIs, or at the very least do not utilize APIs as old as what ReactOS is targeting. If they did, then newer applications would still work on Windows XP (and ReactOS). While implementing older APIs would be necessary for 100% compatibility, most actively updated apps use modern APIs introduced to Windows in the Windows 8/8.1 era for interacting with the OS, with the exception of a few key Win32 APIs that are more performant than their modern counterparts.

What you have totally, utterly failed to comprehend is that THEY'RE THE SAME APIs. Microsoft often hasn't completely replaced APIs, merely extended them. That's what they do. They rarely introduce new APIs and instead massage existing ones by adding new arguments and additional calls that operate on the same objects. That means you have zero choice but to implement the whole API every time. You can't get away with "just implementing the latest ones" because 90% of the APIs currently in use started life in win2000.

As for Window's "fanatical" backwards compatibility, it's just not true. The vast majority of Windows XP software will not work on Windows 10 without tweaks, even with it's "compatibility tools". Even Windows 7 applications don't work most of the time. Microsoft implements the minimum compatibility that is necessary for some enterprise customers, and that's it. Hell, they've been publicly trying to kill the Win32 API in Windows since Windows 8.

700 pages of blog posts on dumb shit microsoft has done to preserve backwards compatibility disagree.

https://devblogs.microsoft.com/oldnewthing/

Did you know that every time you start an application, windows checks if it's adobe acrobat 2013? If it is, it inserts a shim that lies about the color of the text in the title bar and says it's white, even when it isn't. Otherwise, every page in the PDFs you open will be black.