A fairly big moment for the ReactOS project: it has just received its very first system call from NT6.
The system call that has been added is NtGetCurrentProcessorNumberEx, which is used for returning the processor number of the logical processor that a caller is running on. It’s unclear how long it will take ReactOS to become compatible with Windows Vista software, but it took Microsoft around half a decade to develop Vista after the release of XP and marked a major upgrade, even if it didn’t land well with users at the time.
↫ Paul Hill at Neowin
It’s a milestone for sure, but not one that’s going to make a huge difference for ReactOS at this moment in time. Still, it’s a sign of things to come, even if the very nature of the ReactOS project means that whatever things are coming tend to take a while to arrive.
I love the idea of Reactos but theyre continously at least 10 years behind where they need to be. By the time they get all the NT 6 stuff together windows 7 will likely have been out for over 20 years and obsolete for at least 10. With Wine having gotten very good there are vanishingly small amounts of users that can be served practically by this anymore, except maybe as a learning tool about how to create a non unix system.
Theres also a thing i thought of while writing this comment. That article about sloperating systems aside if ReactOS started generating code to bring their compliance up quickly would Mi rosoft sue then considering they have a big vested interest in ai code not being found to be copyright breaching?
Using AI is unlikely to help at all as OS development requires actual understanding that it doesn’t have. Plus there isn’t any legitimate Windows code to train said AI on.
You are probably right, anything more advanced that the L4 standard made by slopcoding is just bad and slow.
dark2,
AI will have access to several high quality open source operating systems, including Linux, BSD, and Solaris. Not to mention the entirety of Microsoft developer documentation.
I don’t think an ReactOS improvement project would be restricted by knowledge, but only the actual humans that will test and verify its output.
(The common pitfall is blindly accepting LLM suggestions, while maybe they are at best 50% correct)
“Human in the loop”
“I need NtCreateUserProcess, it has to be atomic, and should not require multiple steps like older NtCreateProcess or NtCreateProcessEx. Here is the documentation and use case [ insert URL ]”
Likely it would accelerate things significantly, I think the fear would be that it would compromise the ReactOS ‘clean-room’ approach. You can prompt an LLM to high heaven, but you cannot get it to ignore its training data, which could include leaked sources, coding examples, and other copyrighted sources.
jvanderberg,
That is why you use “clean” LLMs only with publicly disclosed source heritage.
For example,
SmolLM by Hugging Face:
https://huggingface.co/blog/smollm
It of course won’t be as powerful or versatile as commercial ones, And that is where RAG and “prompt engineering” comes in.
If your goal is a clean room implementation, there are still ways to use LLMs with ease of mind.
@jvanderberg
The “clean room” bit is my point, if Microsoft sue them or cause problems because the generated code isnt clean enough then then have to admit in court that its trained on copyrighted code and that breaks open all AIs to lawsuits that no one wants. Its a catch 22 for them
I don’t know if you’ve been following the US justice system lately, but MS will 100% feed the court unchecked lies and then the court will rule in their favor because “big corporation.” The Supreme Court isn’t even bothering explaining a lot of their rulings anymore.
Shugo,
People may not remember this, but ReactOS already had allegations of using private microsoft code in the past whereby ReactOS was accused of distributing non-public information from microsoft’s source code.
https://prohoster.info/en/blog/novosti-interneta/odin-iz-razrabotchikov-microsoft-schitaet-chto-reactos-ne-mog-obojtis-bez-zaimstvovaniya-koda-windows
I don’t know the merit of the allegations, but I do know reactos responded by instituting a policy of scrutinizing submissions more meticulously. Ironically ReactOS actually needs to possess microsoft’s private code in order to help them judge whether FOSS submissions are based on it.
Realistically, regardless of whether it’s humans or LLMs writing the code, educated guesses are the best that any project can do. In principal this applies to 100% of projects where many devs come and go. It applies to both proprietary as well as FOSS projects, going forward they will all experience factual uncertainty as to the origins of code. Unless source code gets reused verbatim, one is forced to apply subjective heuristics with false positives and false negatives.
Unfortunately I think ReactOS developers are wasting their time.
What does ReactOS offer that Linux+Wine doesn’t have?
The only reason to build ReactOS is if it can be reliably used with Windows drivers.
If people aren’t confident their USB device with Windows drivers will work with ReactOS, it is a useless operating system. Then after that they would need to get all the graphics cards and other PCI-Express device Windows drivers working with ReactOS.
ReactOS developers should give up and dedicate their time to Wine / Linux.
Hate to say it, but that’s the exact point of ReactOS
Yes, for the user side, Wine and Linux might be a better, and more compatible pairing. But ReactOS’s approach is to clone the kernel too. This would give ReactOS binary compatibility with Windows drivers.
The issue currently is “reliably”. but ReactOS is still missing a LOT of critical Windows APIs, so a lot still doesn’t work.
The123king,
Yes. I believe there are many who could use ReactOS at one point or another. – it would probably even be preferable to windows itself given the direction that’s going in. But excellent reliability and compatibility are imperative. Unfortunately these are difficult to achieve, more so given limited resources of a small team without a cash cow.
Alfman,
I’d say the issue with ReactOS is not backwards compatibility, but rather forwards compatibility instead.
They can run pretty much most Windows NT 4.0 and many Windows XP software pretty well. But they will choke on supporting your recent printer, nvidia graphics card, or even your NUMA Threadripper CPU.
sukru,
Sure. I used to look forward to trying to see if ReactOS would run the software I require…but progress has been so slow that I’ve mostly given up. Not completely but maybe I check in every five years.
I have a bit of buyers remorse with an osciliscope I bought that requires windows. I took a gamble when I bought it that it would work under wine or at least a VM, but I struck out. I’d really love for this to work under reactos.
I have great resentment towards the industry for being so biased in only supporting the windows monopoly (and the IOS/android duopoly on mobile).
“What does ReactOS offer that Linux+Wine doesn’t have?”
A stable and feature complete userland, something Linux will never have. Trying to brute force that through immutable distros is still problematic.
This is why i will always standby my claim that the only FOSS operating system that has a hope in hell of competing toe to toe with Windows and Mac, is Haiku.
Stability and consistency are key for the majority of casual computer users. No-one but nerds care about the difference between KDE and GNOME, or the intricacies of x.org vs wayland. All they want is a computer that doesn’t crash all the time, can load up Facebook and their email, and can be troubleshooting with a simple “why does my email not work on Haiku”, without having to know every application and subsystem name of their specific linux distro version
“Stability and consistency are key for the majority of casual computer users.”
Stability maybe, consistency though i think history has shown is wrong. I hardly feel i have two Windows applications that work and look the same. Even simple things like menus that used to be kinda standardized vary so much between applications. Don’t get me wrong, i actually believe consistency is a good thing when done right, but it is not a deal breaker.
“No-one but nerds care about the difference between KDE and GNOME”
Just like no-one but nerds care about win32 and whatever the modern ui is called today, or if an application is native or a wrapped web application.
“or the intricacies of x.org vs wayland”
I am a nerd, and i only care about this because wayland is a huge regression, after many years where i exactly didn’t need to worry about details as X just worked out of the box, with lots of features still not possible in wayland, and suddenly i now have to care about the compositor, since core features are there instead of in wayland.
“why does my email not work on Haiku”
Yeah, because for such users they would totally need to know the components, and not just say “why does my email not work on ubuntu”?? If they use something not standard on Windows or Mac they would need to know the name of the application as well.
In my opionion, what prevents linux to take over the desktop is hardware just working without fiddling, software, software distribution, and upgrades. But those can’t easily be fixed, and requires buy in from a ton of partners, and this is why i don’t believe it ever will happen. But this is also why i’m sure it is even less realistic that Haiku or ReactOS could take over.
If Google plays it right and get enough partners onboard, which is a huge if, i do think Aluminium OS could be the thing that eats into the Windows marketshare.
By consistency, i mean platform consistency.
Linux has none of that. Multiple audio subsystems. Dozens of desktop environments, Two completely different display APIs. Dozens of different file managers.
Linux does not have platform consistency. Yes, Linux might have 3% total desktop marketshare, but split up into separate distros, i expect it’s 1% for Ubuntu and 0.x% for all the rest.
And you need to know what distro you’re using, and what version it is, before you can start troubleshooting it. No point following a guide on following a guide configuring initd if your distro uses systemd
(GNU)Linux, by design, is an incoherent and inconsistent mess, and that’s why it’ll never succeed.
“A stable and feature complete userland”
What the????
Are you telling me the ReactOS reliably works with ALL Windows Software?
Can you provide a web link to back this statement up?
I think you are totally wrong. Yes ReactOS is aiming to provide a Windows feature complete userland, but I believe they are nowhere near achieving it.
And which version of Windows are you talking about for this “feature complete userland”? Windows98???
The Wine project should have goal of 100% compatibility with Windows10. This would work assuming Microsoft doesn’t invent some gimmicky new APIs in Windows12 just to encourage incompatibility between Windows Software and Win10/11.
He’s talking about Win32, not ReactOS. ReactOS is /targeting/ a stable and feature complete userland. It hasn’t implemented it all yet.