> relatively little investment compared to migrating to an OS on another kernel
One of the more beautiful aspects of Windows is you actually rarely interact with the kernel at all. That portion of the OS could (and in practice often is) switched out and replaced without the user-facing portions being aware.
If you look at the list of NT system calls [0] you can see how frequently they've changed. The only programs that can safely talk to the kernel are core OS components, which in turn provide a user-facing stable ABI through the use of DLLs.
The fact Wine is running on a separate kernel is essentially 100% transparent to all but a handful of programs that intentionally poke the kernel, either for undocumented functionality or to e.g. detect tampering.
This is why IMO for running application software, Wine will always be superior. Linux is a really good kernel for almost everything, and with io_uring the last big deficit (async i/o) may be fixed.
ReactOS's remaining advantages are driver support for Win2k, and the whole explorer shell and start menu environment. If someone really wanted to, I bet you could run ReactOS's shell on top of Wine, fullscreened on Linux...
A thought I had after finishing this. Another benefit of ReactOS's architecture vs Wine is you could, in principle, directly copy at least some system-level DLLs/software from Windows (2000/XP) and get something akin to Windows 2003/XP running on a modern and up-to-date kernel, possibility with much newer hardware support.
I doubt the ReactOS devs themselves would want to get that close to even just binary blobs from Microsoft, but if it gets far enough along, I could see users scrapping together systems like this, maybe for retro games or something.
One of the more beautiful aspects of Windows is you actually rarely interact with the kernel at all. That portion of the OS could (and in practice often is) switched out and replaced without the user-facing portions being aware.
If you look at the list of NT system calls [0] you can see how frequently they've changed. The only programs that can safely talk to the kernel are core OS components, which in turn provide a user-facing stable ABI through the use of DLLs.
The fact Wine is running on a separate kernel is essentially 100% transparent to all but a handful of programs that intentionally poke the kernel, either for undocumented functionality or to e.g. detect tampering.
This is why IMO for running application software, Wine will always be superior. Linux is a really good kernel for almost everything, and with io_uring the last big deficit (async i/o) may be fixed.
ReactOS's remaining advantages are driver support for Win2k, and the whole explorer shell and start menu environment. If someone really wanted to, I bet you could run ReactOS's shell on top of Wine, fullscreened on Linux...
[0] https://j00ru.vexillium.org/syscalls/nt/32/
EDIT:
A thought I had after finishing this. Another benefit of ReactOS's architecture vs Wine is you could, in principle, directly copy at least some system-level DLLs/software from Windows (2000/XP) and get something akin to Windows 2003/XP running on a modern and up-to-date kernel, possibility with much newer hardware support.
I doubt the ReactOS devs themselves would want to get that close to even just binary blobs from Microsoft, but if it gets far enough along, I could see users scrapping together systems like this, maybe for retro games or something.