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

[cl333r]

There is a part of me that finds it somewhat comical, also a little sad, that ReactOS makes progress faster than HURD.

I think they both need to get morphologically more modular. Rewrite them in Rust, put them down in a Node.js container and smash them hard with a big rock.

[Ironmask]

Looks like he used stable which hasnt been updated in years, very much not indicative of reactOS' current development state.

Well, is it? He says exactly what hardware is and is not supported and uses a website to track which hardware is supported, does that differ from the current dev build?
No trying to be accusatory or confrontational, just letting you know that if there is that much of a gap between stable and dev, his video has plenty of receipts.
In my experience, ReactOS doesn't evolve that much between the two anymore. A couple years back, yeah, stable was way off from dev, but now it seems development between stable releases is less "radical", not stagnated, just, there's less obvious things for the team to solve that appear as notable changes in stability now.

[woddy]

I've been reading about this operating system for years, however I still read on their download page "Please note, that ReactOS is still in alpha and gives no guarantee of stability, safety of your files or working at all." they will make it to release a stable version this century ?

[Quackdoc]

Well, is it? He says exactly what hardware is and is not supported and uses a website to track which hardware is supported, does that differ from the current dev build?
No trying to be accusatory or confrontational, just letting you know that if there is that much of a gap between stable and dev, his video has plenty of receipts.
In my experience, ReactOS doesn't evolve that much between the two anymore. A couple years back, yeah, stable was way off from dev, but now it seems development between stable releases is less "radical", not stagnated, just, there's less obvious things for the team to solve that appear as notable changes in stability now.

That info hasnt been updated in a long time https://reactos.org/project-news/reactos-0414-released/ 2021, things have changed massively since then, both my ATI HD6000 series card and vmware sVGA drivers work. Application and game support has increased greatly their twitter has a lot of showcasing this https://twitter.com/reactos/

you should always be trying the nightlies. there have been massive changes since the last stable

[Developer12]

I love seeing ReactOS make progress. I wish them nothing but luck, as it would be extremely beneficial to have an open source Windows compatible OS. That being said, even with the progress they've made, they're still only really targeting Windows 95/2000 compatibility which is just kinda useless.

I wonder if somebody will start a new project targeting Windows 10 compatibility. It might pop off, with it's upcoming demise and all that. I wonder how hard it would be to use the Linux kernel, but write an ecosystem on top of it that provides Windows compatibility?

That idea for compatibility on top of linux is literally the WINE project. That's it.

The point of reactos is to have driver compatibility, and compatibility with the sorts of deep kernel APIs that WINE can't emulate in userspace. There's LOTS of old industrial equipment running on windows 2000 out there that could stand to move to something maintained like reactos. Industrial hardware drivers can't run on bare linux or WINE.

Trying to jump to windows 10 would be stupid. Totally unworkable. Windows is fanatical about backwards compatibility and carries forward APIs from every previous version. There are APIs in win10 from all the way back in the 2000 and XP days. You can't "just implement the latest ones" any more than you can implement x86_64 without x86. They build on and extend each other. The only way to get there is to gradually implement each and every API one by one along the way.

[mrg666]

Linux+Wine is almost at the finish line in the race for replacing Windows. But I am most probably missing something. And I am sure all their effort is creating better understanding of Windows internals for Wine as well. Good luck to the project. They are tackling an immense challenge.

[ayumu]

There is a part of me that finds it somewhat comical, also a little sad, that ReactOS makes progress faster than HURD.

HURD's design is a dead end. It failed to address the flaws in the HURD critique paper, or move to L4.

Look elsewhere for microkernel multiserver designs not stuck in the 80s. Genode and Managarm a good start.

[Daktyl198]

That idea for compatibility on top of linux is literally the WINE project. That's it.

The point of reactos is to have driver compatibility, and compatibility with the sorts of deep kernel APIs that WINE can't emulate in userspace. There's LOTS of old industrial equipment running on windows 2000 out there that could stand to move to something maintained like reactos. Industrial hardware drivers can't run on bare linux or WINE.

Trying to jump to windows 10 would be stupid. Totally unworkable. Windows is fanatical about backwards compatibility and carries forward APIs from every previous version. There are APIs in win10 from all the way back in the 2000 and XP days. You can't "just implement the latest ones" any more than you can implement x86_64 without x86. They build on and extend each other. The only way to get there is to gradually implement each and every API one by one along the way.

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.

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.

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.

[schmidtbag]

I love seeing ReactOS make progress. I wish them nothing but luck, as it would be extremely beneficial to have an open source Windows compatible OS. That being said, even with the progress they've made, they're still only really targeting Windows 95/2000 compatibility which is just kinda useless.

Tell that to those who think it's necessary for Wine to be able to run Office 97...

[Ironmask]

HURD's design is a dead end. It failed to address the flaws in the HURD critique paper, or move to L4.

Look elsewhere for microkernel multiserver designs not stuck in the 80s. Genode and Managarm a good start.

Even then, I feel like microkernels are the wrong solution.
The problem is about stability and security. Microkernels are not a solution to OSes being inherently unstable and insecure, they are a solution to C's lack of compile-time and runtime checking, it's a wheelchair for a language designed before the internet was even invented, probably before memory controllers were even invented. It's a barely-portable assembly language made for 1970s dinosaurs, back when people were pretty much just figuring out how to even craft the languages we use to talk to computers.
A better solution is a language-based OS. Rust is an obvious choice, but there are good examples of Java and C# OSes that are secure simply because the language doesn't let you do certain things C does (intentionally or by accident).
You don't need to make laws if there's nothing to break. Microkernels are about designing a prison for people's mistakes, not faults in the machine. Good languages prevent mistakes altogether. I mean, you can still go with a microkernel to protect against machine faults, but at that stage you're working with stuff like avionics. Consumer systems (even servers) can and should crash as soon as a hardware fault is detected so it can be repaired, in fact, server hardware is designed to specifically do this, consumer-grade hardware likes to hide things like memory faults as much as it can to artificially extend the hardware lifetime and to cover up manufacturing flaws. Microkernels are a niche that work in places where you can't repair the hardware.