One of the problems the ReactOS project continually has to deal with is that Windows is, of course, an evolving, moving target. Trying to be a Windows-compatible operating system means you’re going to have to tie that moving target down, and for ReactOS, the current focus is on being compatible with Windows Server 2003 “or later”. This “or later” part is getting a major boost in a very crucial area.
The history of ReactOS spans a wider range than the lives of many of the people who work on it today. Incredible individuals have come and gone from the project with vastly different goals for what they want to see developed. In recent years, better hardware support has emerged as one of those goals. As ReactOS gazes towards the world of Vista and beyond, a few questions about how hardware works emerge. Vista introduced massive overhauls to how hardware drivers are written and maintained. Gradually we’re trying to handle many of these overhauls with great success. Today we talk about WDDM, or the Windows Display Driver Model.
An initial investigation into WDDM on ReactOS
There’s a ton of technical details in the blog post, but the end result is that ReactOS can now tentatively load some WDDM drivers. For instance, ReactOS can run NVIDIA’s Windows 7 driver now, and the example used an NVIDIA GTX 1070. Of course, we’re looking at basic 2D display output only and no 3D acceleration, so don’t expect to be running any 3D games on ReactOS any time soon.
Still, this is a pretty massive step forward for ReactOS, but of course, a ton more work remains to be done, as is always the case for ReactOS. I do have to say – the fact that WDDM support is now on the table and progress is being made here is great news. ReactOS is not even remotely close to being an alternative to Windows, but even if it never gets there, it’s a great showcase for what talented, determined developers can do, and they deserve recognition for that.
I want ReactOS to succeed. I really do. But Windows Server 2003 is basically retro software at this point, and ReactOS is still not there. I mean, the only hope for the project at this point is for Windows itself to become abandonware, so ReactOS can ultimately replace it in an ATM, or on a machine at some random factory floor.
i always tell myself if i won the lottery i would funnel money into this effort.
With all the crap we have to deal with for the average small business customer, we just want the OS to do its job. Be there and be stable.
The thing is most users don’t *need* to keep innovating but companies do, to survive in the current economic model, and that’s not compatible.
@babblo
I more agree than not. However, I would say that most Open Source projects are driven to keep innovating as well. And not just because they have corporate sponsors. I think we users drive them to evolve.
However, individual users DO NOT need to evolve. So the great strength of Open Source is that you can get off the train if you want. GNOME can keep evolving but you can stick with MATE (GNOME 2) or create Cinnamon and let GNOME leave you behind. Or you can still be using FVWM and seeing even MATE and Trinity as innovation you do not need.
The problem with proprietary software is that I cannot just stick with Windows 7 if I want. I cannot evolve it just enough to remain relevant. If Windows 7 were Open Source, about a third of the Windows user base would still be using a version of it that had better unicode and a few other things but that is otherwise the same as it always was.
ReactOS is coming along well in the last few years. That long slow foundational work seems to be paying off now they’re able to do more surface level work to close bugs or adapt driver APIs.
With Windows 10 EOL hopefully we’ll see even more attention and work coming to the project too.
I keep a Windows VM around, primarily because my printer doesn’t have Linux drivers. I’ve often wondered if ReactOS would work instead. Sounds like they’re making progress in that direction 🙂
“Windows is, of course, an evolving, moving target”
IMHO that may not be entirely true. Now Windows10 is a fixed target, there won’t be any more changes to Windows10.
IMHO ReactOS and WINE should make their goal “100% compatibility with 64bit Windows10 / Directx12.2”.
You could have argued the same for Windows XP 15 years ago
@The123king
Indeed. You are correct.
I suppose one way that Windows 10 really is the terminal version of Windows is that it is the last 32 bit version. If you are going to pick a point in Windows evolution to take as a static target for development, this may be a sensible point to pick.
Obviously Windows Server 2003 (Windows XP) was chosen as a target because Windows XP was still immensely popular at the point they made that choice. But one of the reasons they have clung to it is no doubt that it was a far simpler target. Windows Vista added many APIs WDDM itself is a really good example.
Much of the evolution of Windows has not been about API changes that would impact regular applications. ReactOS would be a lot more useful if they let themselves offer more modern APIs so that things like current web browsers and office suites work. ReactOS does not have to support all Windows APIs just to be useful. I was ReactOS has a more “application” driven view of what Windows features are most required. DIrectX 12 requires WDDM 2.0 that first appeared with Windows 10.
To be really useful these days though, ReactOS has to offer a 64 bit version. Many Windows applications stopped supporting 32 bit. But a 64 bit ReactOS is going to require Wow64 which is likely a lot of work.
I don’t think it’s useful changing the kernel target to something else. user mode etc is fine (and indeed NT6+ user mode stuff is already supported in ReactOS) but the focus on the kernel should still be NT5, maybe with NT6 features (like WDDM) given more priority where it makes sense
@The123king
We basically agree and I was trying to say something similar above. What matters most is the API that applications and drivers see. We only need enough kernel to support that.
I imagine there are kernel changes required to support some of the newer APIs though. There were a lot of changes to kernel32 in Vista including threading and memory management that I would think would require lower level support. Implementing Wow64 will require support in the kernel as well I would think. Then there are KernelBase and ntdll. Required security oriented behaviour may also require kernel changes.
So keeping the overall design of the NT 5.2 kernel but running more modern apps and drivers is going to result in a ReactOS kernel that does not really match any specific version of Windows. I think that is ok. It is harder in some ways though to verify that such a kernel is “correct”. At some point, compatibility will demand greater alignment. At that point, what kernel defines the “correct” behaviour? When they finally decided to move on from Server 2003, I think Windows 10 is the best choice. Vista is not only old but some of its concepts have been abandoned so it seems like a bad choice. Windows 7 is a pretty good candidate as well and perhaps a more achievable target. Much of what is missing in Windows 7 from an application perspective (eg. Unicode) can be handled entirely in userland.
A “stripped down” Windows 10 may make the most sense as a target. By that, I mean that the kernel does not have to implement every feature and even not all the userland capabilities have to be there but, for the stuff that is supported, the “correct” behaviour maps to Windows 10. And if this the route they take, getting to a fully Windows compatible OS means just layering on more and more and not having to switch architectures again (at least, not for a long while). Since Windows 10 was around for so long, you could even re-trace its evolution in terms of feature development while releasing more and more advanced versions of ReactOS (eg. you could implement WDDL 2.0 first and slowly add more and more to get to the equivalent of WDDL 2.8 and it would all be “Windows 10”).
I guess Microsoft will invent some stupid new API that requires Windows11 or higher to work.
Then apps start using the new API and ReactOS / WINE can’t keep up.
But really what new API can Microsoft invent now? Curious to know what gimmicks they can come up with.
Will Microsoft make a “Copilot API” so that 3rd party apps can use Copilot AI???
I’m guessing ReactOS / WINE will never be able to emulate AI, so it seems Microsoft could make Windows “unclonable”….
tom9876543,
Microsoft have been doing it with visual studio runtime libraries for decades now. Their strategy doesn’t require new APIs at all, just windows version checks. Whenever developers upgrade their visual studio projects to the latest runtime, which happens by default on upgrade, these DLLs have code in them which explicitly blocks the application from running on versions of windows that microsoft deems unsupported. This happens regardless of whether the application is actually compatible with older versions of windows or not. Even ancient software, when recompiled using newer tools, will stop working on older operating systems (ask me how I know). Other windows compilers like mingw don’t suffer from this. Microsoft did this on purpose to exploit 3rd party software in their planned obsolescence scheme.
I agree this could be a problem for a project like ReactOS, and I don’t know how they solve it. It’s possible it just reports the version that the software wants to see so that it won’t get blocked. This may run fine until the software actually requests a new API (which most software does not). I don’t ever recall seeing the “wrong windows version” message under WINE so my guess is WINE always reports itself as a current version of windows and lets incompatibilities play out as a crash or broken functionality with unhandled errors.
Interesting question. As far as I know microsoft’s AI does not require win32 to change and in fact much of it doesn’t even run on the local machine but rather microsoft’s servers. Executing AI models, while computationally intensive, doesn’t typically require the OS to do anything special. In theory AI software could continue running on reactos and wine because it doesn’t require anything special of win32. However if there are dependencies on cuda, opengl, or things of this nature, they’re probably not going to work.
However it’s probably worth pointing out that most users of WINE (and maybe reactos too?) look to it to run non-microsoft software, the vast majority of which doesn’t depend on AI and never will. Even if microsoft were to try and hammer it into the VC runtime, WINE and ReactOS could no-op it and the majority of software wouldn’t care.