6 ms·

I'm quite impressed that they can load graphics drivers now. Those generally seem to be arcane as heck, delving deeply into the internals of not just the applic

by mhd 11y ago

I'm quite impressed that they can load graphics drivers now. Those generally seem to be arcane as heck, delving deeply into the internals of not just the applications they support (e.g. games), but the operating system itself. Although I guess this is a more basic level, i.e. not using Nvidia drivers to run 3DMark...

m45t3r 11y ago
AFAIK, Windows has a very defined model for display drivers (WDDM: https://en.wikipedia.org/wiki/Windows_Display_Driver_Model https://en.wikipedia.org/wiki/Windows_Display_Driver_Model) so it should be a matter of implementing the WDDM specification + bugs.
creshal 11y ago
Stable driver APIs (WDDM for graphics, IFS for in-kernel file systems, and others for other areas) are one of the big differences between NT's (micro-)kernel and Linux' (rather monolithic) kernel with no API commitment. Of course, "stable" may vary. Microsoft introduced a new kernel graphics API with every OS after NT4 (XDDM, XPDM, WDDM 1.0, 1.1, 1.2, 1.3, 2.0; I wonder which ReactOS uses?) because of how significantly GPU capabilities changed over the years; while Linux changes its APIs more often than that, the changes are usually minimal enough that neither Nvidia nor AMD are complaining significantly about it. (The X¹¹ API, on the other hand…)
- gh02t 11y ago
  My understanding is that NT is more of a hybrid kernel than a true microkernel. Is that still true or has it moved more towards a micro kernel in recent years? I remember reading an interesting article about the influence of Mach on NT, but that they ended up having to put a lot of stuff (including the Executive) into kernel space for performance.
  - userulluipeste 11y ago
    It's hybrid indeed, but far more modular. The driver code is running in kernel mode to avoid costly switching from kernel to user mode and back. This imposed requirements on driver code quality as it is critical for the entire system, but it can be replaced (with another version) as a component. For a monolithic kernel like Linux changing a driver like the one for video card means recompiling the entire thing.
    - gh02t 11y ago
      > For a monolithic kernel like Linux changing a driver like the one for video card means recompiling the entire thing. Not necessarily, Linux has loadable kernel modules as well and most drivers are built that way and loaded on demand. The Nvidia proprietary drivers for instance are a loadable kernel module, though they are tied to a specific kernel version. BSD does basically the same thing.
      - creshal 11y ago
        There are somewhat more subtle differences: Not only are modules not tied to a particular kernel, they are also (to varying degrees) isolated against the rest of the kernel. WDDM in particular can recover from a driver crash and restart hardware and driver (which you can trivially demonstrate on an AMD card by waiting for an hour or two…), while Linux (and Windows XP with its older driver model, and probably BSDs) will panic the entire kernel on problems like this.
        gh02t 11y ago
        Yeah, that's what I thought with NT, which is that drivers are much more isolated. If I understand it correctly drivers can still cause a kernel panic, but Microsoft requires that signed drivers pass a formal verification, which has greatly cut down on blue screens. I'm just an armchair observer though, so I'm not an expert. I was always greatly impressed by Windows' recent ability to recover from something like a display driver crash with hardly a hiccup. That's pretty impressive voodoo.
adam12 11y ago
I've got a bunch of old games that I can no longer run on Windows 8/10. If they can get some of those running smoothly, ReactOS will see a surge in new users.
- TazeTSchnitzel 11y ago
  With its NTVDM, ReactOS can actually play DOS games out-of-the-box, which is something modern (64-bit) Windows releases can't do.
  - chungy 11y ago
    Even though ReactOS' current main architecture is 32-bit x86, I would hope that the NTVDM gets ported over to the 64-bit version, which would be quite awesome. Something I rather enjoy about Wine is that it supports 16-, 32-, and 64-bit applications all from the same prefix. Quite a nice advantage over Windows :)
    - jeditobe 11y ago
      You can copy ntvdm.exe from reactos ro windows and start using it right now. Even in 64 bit system.
      - vcrkoio 11y ago
        This doesn't work for me (Windows 7 x64). Am I supposed to do something else besides copying the file?
    - TazeTSchnitzel 11y ago
      The OP says that it works on x64 too.
  - speeder 11y ago
    As a hardcore gamer, gamedev and old games lover, I am finding sadder and sadder that certain games are getting increasingly forgotten by everyone, and noone even remember they are in dire need of tools to make them work. It is the games from Windows 98 and XP era, many used some combination of GDI and DDraw that doesn't work at all on new Windows versions, DDraw emulation is mostly broken, and pity you if the game used DDrawEx (it was to mix DDraw with D3D). For example I am currently trying to figure a way to play SimCity 4 properly, the game is too demanding to run in an emulator, so some kind of native implementation is needed, but it also uses DDrawEx, that is very poorly supported in all OSes except Windows 98, ME and XP (it doesn't work in XP contemporary NTs either). I think this is the kind of games the OP is happy ReactOS maybe will implement... because for DOS games, DosBox is more than enough already in most cases (there are some exceptions, like Noctis that is incredibly CPU-intensive and runs at 3 FPS in DosBox).

by mhd 11y ago

m45t3r 11y ago

AFAIK, Windows has a very defined model for display drivers (WDDM: https://en.wikipedia.org/wiki/Windows_Display_Driver_Model https://en.wikipedia.org/wiki/Windows_Display_Driver_Model) so it should be a matter of implementing the WDDM specification + bugs.

creshal 11y ago

Stable driver APIs (WDDM for graphics, IFS for in-kernel file systems, and others for other areas) are one of the big differences between NT's (micro-)kernel and Linux' (rather monolithic) kernel with no API commitment. Of course, "stable" may vary. Microsoft introduced a new kernel graphics API with every OS after NT4 (XDDM, XPDM, WDDM 1.0, 1.1, 1.2, 1.3, 2.0; I wonder which ReactOS uses?) because of how significantly GPU capabilities changed over the years; while Linux changes its APIs more often than that, the changes are usually minimal enough that neither Nvidia nor AMD are complaining significantly about it. (The X¹¹ API, on the other hand…)

gh02t 11y ago
My understanding is that NT is more of a hybrid kernel than a true microkernel. Is that still true or has it moved more towards a micro kernel in recent years? I remember reading an interesting article about the influence of Mach on NT, but that they ended up having to put a lot of stuff (including the Executive) into kernel space for performance.
- userulluipeste 11y ago
  It's hybrid indeed, but far more modular. The driver code is running in kernel mode to avoid costly switching from kernel to user mode and back. This imposed requirements on driver code quality as it is critical for the entire system, but it can be replaced (with another version) as a component. For a monolithic kernel like Linux changing a driver like the one for video card means recompiling the entire thing.
  - gh02t 11y ago
    > For a monolithic kernel like Linux changing a driver like the one for video card means recompiling the entire thing. Not necessarily, Linux has loadable kernel modules as well and most drivers are built that way and loaded on demand. The Nvidia proprietary drivers for instance are a loadable kernel module, though they are tied to a specific kernel version. BSD does basically the same thing.
    - creshal 11y ago
      There are somewhat more subtle differences: Not only are modules not tied to a particular kernel, they are also (to varying degrees) isolated against the rest of the kernel. WDDM in particular can recover from a driver crash and restart hardware and driver (which you can trivially demonstrate on an AMD card by waiting for an hour or two…), while Linux (and Windows XP with its older driver model, and probably BSDs) will panic the entire kernel on problems like this.
      - gh02t 11y ago
        Yeah, that's what I thought with NT, which is that drivers are much more isolated. If I understand it correctly drivers can still cause a kernel panic, but Microsoft requires that signed drivers pass a formal verification, which has greatly cut down on blue screens. I'm just an armchair observer though, so I'm not an expert. I was always greatly impressed by Windows' recent ability to recover from something like a display driver crash with hardly a hiccup. That's pretty impressive voodoo.

adam12 11y ago

I've got a bunch of old games that I can no longer run on Windows 8/10. If they can get some of those running smoothly, ReactOS will see a surge in new users.

TazeTSchnitzel 11y ago
With its NTVDM, ReactOS can actually play DOS games out-of-the-box, which is something modern (64-bit) Windows releases can't do.
- chungy 11y ago
  Even though ReactOS' current main architecture is 32-bit x86, I would hope that the NTVDM gets ported over to the 64-bit version, which would be quite awesome. Something I rather enjoy about Wine is that it supports 16-, 32-, and 64-bit applications all from the same prefix. Quite a nice advantage over Windows :)
  - jeditobe 11y ago
    You can copy ntvdm.exe from reactos ro windows and start using it right now. Even in 64 bit system.
    - vcrkoio 11y ago
      This doesn't work for me (Windows 7 x64). Am I supposed to do something else besides copying the file?
  - TazeTSchnitzel 11y ago
    The OP says that it works on x64 too.
- speeder 11y ago
  As a hardcore gamer, gamedev and old games lover, I am finding sadder and sadder that certain games are getting increasingly forgotten by everyone, and noone even remember they are in dire need of tools to make them work. It is the games from Windows 98 and XP era, many used some combination of GDI and DDraw that doesn't work at all on new Windows versions, DDraw emulation is mostly broken, and pity you if the game used DDrawEx (it was to mix DDraw with D3D). For example I am currently trying to figure a way to play SimCity 4 properly, the game is too demanding to run in an emulator, so some kind of native implementation is needed, but it also uses DDrawEx, that is very poorly supported in all OSes except Windows 98, ME and XP (it doesn't work in XP contemporary NTs either). I think this is the kind of games the OP is happy ReactOS maybe will implement... because for DOS games, DosBox is more than enough already in most cases (there are some exceptions, like Noctis that is incredibly CPU-intensive and runs at 3 FPS in DosBox).