Forgot your password?
typodupeerror
Operating Systems Open Source

Intel, NVIDIA, AMD GPU Drivers Finally Play Nice With ReactOS (x.com) 21

ReactOS aims to be compatible with programs and drivers developed for Windows Server 2003 and later versions of Microsoft Windows. And Slashdot reader jeditobe reports that the project has now "announced significant progress in achieving compatibility with proprietary graphics drivers." ReactOS now supports roughly 90% of GPU drivers for Windows XP and Windows Server 2003, thanks to a series of fixes and the implementation of the KMDF (Kernel-Mode Driver Framework) and WDDM (Windows Display Driver Model) subsystems. Prior to these changes, many proprietary drivers either failed to launch or exhibited unstable behavior. In the latest nightly builds of the 0.4.16 branch, drivers from a variety of manufacturers — including Intel, NVIDIA, and AMD — are running reliably.

The project demonstrated ReactOS running on real hardware, including booting with installed drivers for graphics cards such as Intel GMA 945, NVIDIA GeForce 8800 GTS and GTX 750 Ti, and AMD Radeon HD 7530G. They also highlighted successful operation on mobile GPUs like the NVIDIA Quadro 1000M, with 2D/3D acceleration, audio, and network connectivity all functioning correctly. Further tests confirmed support on less common or older configurations, including a laptop with a Radeon Xpress 1100, as well as high-performance cards like the NVIDIA GTX Titan X.

A key contribution came from a patch merged into the main branch for the memory management subsystem, which improved driver stability and reduced crashes during graphics adapter initialization.

Intel, NVIDIA, AMD GPU Drivers Finally Play Nice With ReactOS

Comments Filter:
  • by HiThere ( 15173 ) <<ten.knilhtrae> <ta> <nsxihselrahc>> on Saturday March 21, 2026 @03:08PM (#66053546)

    When I switched off MSWindows, what I wanted was Windows 95b compatibility. It never showed up. It still hasn't. I've intentionally avoided later versions because of terms in the licensing.

    These days the only things that haven't showed up on Linux, or had better replacements are a few music programs (more my wife's field than mine) and a few games...that I may have lost the CDs for.

  • At this point.... (Score:4, Interesting)

    by unixisc ( 2429386 ) on Saturday March 21, 2026 @06:01PM (#66053750)

    I just wish a team would come together, fork ReactOS and work on a fixed target of creating an FOSS version of Windows 7! Not XP, not 8, not 2000.... In fact, make it two projects:

    1. 1. A 32-bit version of NT, which seeks to support the entire win32 API, and maintain compatibility w/ everything from Windows 95 to 10. That one can be x86-only, and would top off its RAM support at 4GB
    2. 2. A 64-bit version of NT, which would support the win64API, but do nothing in terms of backwards 32-bit support. For this OS, make its upper memory limit 2^48, or 64TB of RAM (Microsoft only supports up to 6TB on Windows 10/11). This OS should be done w/ no x86 assembly underpinnings, and should be ported to RISC-V and Arm. If possible, also try to test it on legacy Alphastations and MIPS workstations that previously ran NT

    In that project, have full support of NTFS: Microsoft's patent on that filesystem should be dead, given that it's way beyond 10 years since NTFS was first devised. If they like, they can have an extension of NTFS that is fully backwards compatible w/ Microsoft's implementation of it.

    • Sorry, I meant 256TB of RAM, not 64TB
    • by CAIMLAS ( 41445 )

      Yeah, I don't really get it's trajectory. I'd have thought that by 2005/2010 or so they'd have pivoted to W7 workalike compatibility, due to it being vastly superior in literally every way.

      At that point, you could conceivably implement W10+ compatibility at a much lower effort, making it a realistic bridge for people to stand on for modern hardware.

      A focus on supporting newer hardware, with a newer architecture, would go a long way to bridging the "I can do windows things not on Windows".

      At this point we're

      • Yeah, that's why I suggested 2 versions - a compatible 32-bit version, that aims to preserve such compatibility, and a brand new 64-bit version, which like AMD64 did back 20 years ago, just take the win64 API, but have all the code written around it portable, but w/ no 32-bit backward compatibility baggage. Unlike Microsoft, strive to make it compatible, so that even if it's not one's first choice on an x86-based workstation, it could be on an Arm or a RISC-V box

        From what I understand, that project, like

        • by CAIMLAS ( 41445 )

          Perhaps if the political climate had been different for the past 30 odd years (until recently), yes...

          At this point the hardware support is so negligible that it's a fanciful idea - it hasn't really progressed at all from the last time I tried using it a decade ago, from what I can tell.

  • Years ago, when Windows 9x was in the field and ReactOS was starting out, the concept made sense: a compatible, open source Windows work-alike.

    Today, Windows can't even run Windows apps, and ReactOS doesn't have a meaningful footprint beyond what WINE can provide. Hardware has far eclipsed Windows 2003/XP/7 compatibility (which is again, each of which are further beyond what ReactOS can provide); most of this same hardware works on Linux.

    What value does ReactOS have, beyond providing a(n insecure by defaul

    • Not in its current form, which is why I suggested a fork above
    • by tlhIngan ( 30335 )

      ReactOS's main claim to fame is not application compatibility, but kernel compatibility. It's akin more to FreeDOS - to be compatible with Windows drivers and such.

      In an ideal world, it would let you run hardware devices that Windows no longer runs on. If your expensive CNC machine can't work because the PC hardware crapped out, you could theoretically put a modern PC in its place, stick the control card in the slot, put ReactOS on it and get your machine working again. Otherwise you might be stuck trying t

      • Otherwise you might be stuck trying to find a way to run Windows 98 on a modern PC.

        No problem. You install it in qemu/kvm, you passthrough the PCI bridge that your ISA controller is hung off of or whatever you need to get your hardware attached to it, bing bang bong done. What's a problem is doing it with Windows 95, which still doesn't run well in any virtualized environment I've seen except sadly vmware... and older vmware at that. If your software or driver is bitchy enough to run on 95 but not 98, which is infrequently but still occasionally a thing, you're going to need to hack somet

      • Not getting it. What good exactly is kernel compatibility, as opposed to application compatibility? Or supporting the win32 API?

        The whole idea was being able to get off the Windows upgrade treadmill, but continue to effectively run Wintel applications. One argument against them was that they would be perennially behind Microsoft, but given that most Windows users believe that Windows 7 was the best Windows version to date, ReactOS could have simply anchored to that

        For specialized uses like the ones y

      • by CAIMLAS ( 41445 )

        Well that's not quite a substantial claim. They've not really implemented any added compatibility in years, very negligible support (eg. no AHCI support at all).

        Considering its a 16/32 bit system, and most of the Windows apps from that era run under Wine without problems from what I've seen, I struggle to see the point.

  • Why should someone have to wipe their system and reinstall with each update? If there was a path forward for updating a system in place then they would likely get more buy-in from the Open Source community. At least that way missing features would just show up one day and people might take fixing broken stuff more seriously.

It is impossible to travel faster than light, and certainly not desirable, as one's hat keeps blowing off. -- Woody Allen

Working...