Hello everybody. ReactOS project is devoted to making an OS kernel binary compatible with NT kernel. In their official FAQ it is written that they cannot be replaced with GNU/Linux + Wine because of drivers which cannot be run in Wine. I'm a bit sceptical about their OS, so I wonder why cannot drivers be run in wine?
Drivers are run in ring 0 or 1, right? Why it is impossible/too complicated to a) expose some privileged instructions into userland through API; b) expose IO space using IOPL; c) make a mock of NT kernel to allow the drivers use its ABI; d) patch the binaries automatically to use API instead of privileged instructions; e) if a driver doesn't works well enough in userland, create a micro-VM using VT-x and VT-d and put there NT kernel mock and the driver?
Hi,
Wine itself implements a minimal NT driver layer, with the main goal currently to run copy protection drivers and later on HID and USB drivers that operate on top of the NT HID and USB core drivers.
So Wine implements some bits of ntoskrnl.exe, doing (c).
So far I have not heard of anyone planning to do the other parts, and I can not realistically evaluate the scope.
Ciao, Marcus On Fri, Oct 07, 2016 at 06:10:15PM +0300, KOLANICH wrote:
Hello everybody. ReactOS project is devoted to making an OS kernel binary compatible with NT kernel. In their official FAQ it is written that they cannot be replaced with GNU/Linux + Wine because of drivers which cannot be run in Wine. I'm a bit sceptical about their OS, so I wonder why cannot drivers be run in wine?
Drivers are run in ring 0 or 1, right? Why it is impossible/too complicated to a) expose some privileged instructions into userland through API; b) expose IO space using IOPL; c) make a mock of NT kernel to allow the drivers use its ABI; d) patch the binaries automatically to use API instead of privileged instructions; e) if a driver doesn't works well enough in userland, create a micro-VM using VT-x and VT-d and put there NT kernel mock and the driver?
Hello, I'd like to chime in into that interesting discussion.
What address space do these drivers run in? Is it a shared ntoskrnl.exe process for all processes ran by Wine or does Wine spawn a new ntoskrnl.exe per each new process?
Regards, Aleksey Bragin
On 09.10.2016 13:40, Marcus Meissner wrote:
Hi,
Wine itself implements a minimal NT driver layer, with the main goal currently to run copy protection drivers and later on HID and USB drivers that operate on top of the NT HID and USB core drivers.
So Wine implements some bits of ntoskrnl.exe, doing (c).
So far I have not heard of anyone planning to do the other parts, and I can not realistically evaluate the scope.
Ciao, Marcus On Fri, Oct 07, 2016 at 06:10:15PM +0300, KOLANICH wrote:
Hello everybody. ReactOS project is devoted to making an OS kernel binary compatible with NT kernel. In their official FAQ it is written that they cannot be replaced with GNU/Linux + Wine because of drivers which cannot be run in Wine. I'm a bit sceptical about their OS, so I wonder why cannot drivers be run in wine?
Drivers are run in ring 0 or 1, right? Why it is impossible/too complicated to a) expose some privileged instructions into userland through API; b) expose IO space using IOPL; c) make a mock of NT kernel to allow the drivers use its ABI; d) patch the binaries automatically to use API instead of privileged instructions; e) if a driver doesn't works well enough in userland, create a micro-VM using VT-x and VT-d and put there NT kernel mock and the driver?