4 ms·

I wonder if there are any workarounds to this, such as some compatibility layer that allows a new OS to reuse Mac or Windows drivers. I have no experience in o

I wonder if there are any workarounds to this, such as some compatibility layer that allows a new OS to reuse Mac or Windows drivers. I have no experience in operating systems, so may be proposing a naive solution. Anyone here with more experience that could share some ideas?

JPLeRouzic 5y ago
I am not an expert at all, but such compatibility layers exist. For example Captive [0] was able to reuse Windows XP binary NTFS drivers on Linux. At that time there was no Linux NTFS driver with writing capability. As Linux's driver model is incompatible with Windows XP's driver model, Jan Kratochvil has to code a Linux driver implementing a Corba interface [1] to dialog with a remote piece of code implementing the other end of Corba. This remote code itself was in two parts, one was a driver sub-system borrowed from Reactos 2.3 (its kernel was similar to Windows 3.51 kernel at the time) that piloted a binary Microsoft native NTFS driver. [0] https://www.jankratochvil.net/project/captive/doc/Details.pm https://www.jankratochvil.net/project/captive/doc/Details.pm [1] https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...
AnIdiotOnTheNet 5y ago
We already see this to a certain extent, Linux has NDISWrapper to use some Windows drivers, but my understanding is that it isn't so straightforward for most other classes of driver because the way they work has a lot to do with the way the target OS kernel works and it's hard to map from one to the other.
- JPLeRouzic 5y ago
  Windows XP drivers used messages for communication between the kernel and the drivers, so it was quite straightforward. A driver has to filter the messages it receives, process the one that were addressed to itself and pass on the other messages to the next driver.

JPLeRouzic 5y ago

I am not an expert at all, but such compatibility layers exist. For example Captive [0] was able to reuse Windows XP binary NTFS drivers on Linux. At that time there was no Linux NTFS driver with writing capability. As Linux's driver model is incompatible with Windows XP's driver model, Jan Kratochvil has to code a Linux driver implementing a Corba interface [1] to dialog with a remote piece of code implementing the other end of Corba. This remote code itself was in two parts, one was a driver sub-system borrowed from Reactos 2.3 (its kernel was similar to Windows 3.51 kernel at the time) that piloted a binary Microsoft native NTFS driver. [0] https://www.jankratochvil.net/project/captive/doc/Details.pm https://www.jankratochvil.net/project/captive/doc/Details.pm [1] https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

AnIdiotOnTheNet 5y ago

We already see this to a certain extent, Linux has NDISWrapper to use some Windows drivers, but my understanding is that it isn't so straightforward for most other classes of driver because the way they work has a lot to do with the way the target OS kernel works and it's hard to map from one to the other.

JPLeRouzic 5y ago
Windows XP drivers used messages for communication between the kernel and the drivers, so it was quite straightforward. A driver has to filter the messages it receives, process the one that were addressed to itself and pass on the other messages to the next driver.