Why there is not Wine like software for Windows drivers?

V

vasili111

Why there is no Wine like software for Windows drivers? So we can use Windows drivers for other operating systems too. What are the reasons that such software does not exist?
 
vasili111 said:
Why there is no Wine like software for Windows drivers? So we can use Windows drivers for other operating systems too. What are the reasons that such software does not exist?
Click to expand...
Because the drivers are part of the kernel and Windows and FreeBSD kernel have nothing in common.
 
Someone correct me if I'm wrong but I've been under impression that sole reason ndisgen(8) exists is that MS were kind enough to develop a hardware agnostic public API for network card drivers that was easy enough to port to other operating systems. For the other types of hardware the situation is much more complex. For example with graphic card drivers there's no way to map all the directx/direct3d specific driver calls to equivalent driver calls in FreeBSD because the kernel has nothing that implements anything equivalent.
 
vasili111 said:
Why not to create something like compatibility layer for Windows drivers then?
Click to expand...
Because that would mean reimplementing large part of Windows kernel which is circa 100 million lines of code and closed source. We are talking about 80 000 human developer years.

On another hand I have a question for you. Why don't you use Windows OS if you have close hardware which requires that particular OS? The choice of open hardware is rich enough that one needs never to use close hardware or particular OS. You see I grow up in late 80s using Amiga and switched quickly to UNIX. 30+ years later I still use UNIX. Admittedly I have switched few flavours along the way (in chronological order) Tru64, Solaris, Irix, Solaris, FreeBSD and then finally OpenBSD for the past 10 years but I have never had the reason to use MS-DOS, Windows and bother Microsoft users why their beloved system can't work in multi user mode or doesn't have a native scripting language which render their OS useless to me.
 
vasili111 said:
Why not to create something like compatibility layer for Windows drivers then?
Click to expand...
It is technically possible, just very difficult. It took a long, long time for Wine to get where it is now, and there is not a similar level of demand for a Windows driver emulation layer.

There are hacky ways this could be done. Run Windows in a VM that gives it direct access to the hardware, then develop a way for the host to talk to it. Essentially, run Windows as a big device driver host. Of course that needs RAM and disk space, and adds all the security implications of running Windows.

Another way is to run Windows as the host, with other operating systems in VMs. In some cases, this gives the VMs access to network and disk hardware without doing anything more. Otherwise, a way for the VM to use the hardware through the host has to be developed. And it still has the RAM, disk space, and security overhead of running Windows. Often, it is easier and less expensive to just find compatible hardware.
 
Oko said:
Because that would mean reimplementing large part of Windows kernel which is circa 100 million lines of code and closed source. We are talking about 80 000 human developer years.
Click to expand...
From what I understand what you need is the Windows DDK. That's what you want to emulate with an extra layer. Maybe not as big as the Windows kernel, but some work nonetheless
 
Please note that even though FreeBSD has its Linux Compatibility Layer it still doesn't provide a way to load Linux drivers on FreeBSD. Drivers simply work on an entirely different level (for lack of a better word).
 
Oko said:
Because the drivers are part of the kernel and Windows and FreeBSD kernel have nothing in common.
Click to expand...
... or at least Microsoft claims that (after consulting it's lawyers) ;)

OT: The drivers need a lot of infrastructure from the kernel (memory management, for example) and they only provide other services for the kernel or user code. The problem is that you need lots and LOTS of glue code to let your kernel look like the Windows kernel so the driver can connect to it and not crash on sight. Then you need more glue code to make other stuff native on your system talk to that driver - I would wager that there would be more glue code than actual driver code, thus a no-gain situation. And with the next revolution of the Microsoft Standard Interfaces wheel you may need to start a lot of the work again.

The point where this is viable is (as explained above) the network "ndis" wrapper and on an other level the fuse file systems which pretty much work the same on *BSD/OS-X/Linux/...
 
Crivens said:
... or at least Microsoft claims that (after consulting it's lawyers) ;)
Click to expand...
They have nothing to fear of. The kernel is BSD licensed which is business friendly:). Nobody will sue them. Oh wait a minute! Large parts of FreeBSD kernel are now licensed under CDDL:eek:. You know all that ZFS and DTrace cool stuff SUN engineers wrote. Damn no wonder Microsoft is using code and contributing financially to some other less relevant BSDs;)
 
Oko said:
Damn no wonder Microsoft is using code and contributing financially to some other less relevant BSDs;)
Click to expand...
Microsoft is contributing financially because its users of Powershell are demanding OpenSSH integration. It has nothing to do with the license. It's a business decision, nothing more, nothing less. If OpenSSH was under the CDDL license, the outcome would be the same. ;)
 
You must log in or register to reply here.
Back
Top