# Why there is not Wine like software for Windows drivers?



## vasili111 (Sep 12, 2015)

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?


----------



## tobik@ (Sep 12, 2015)

There is. You can use Windows XP network drivers on FreeBSD with ndis(4). For Linux there is something similar called NDISwrapper.


----------



## vasili111 (Sep 12, 2015)

tobik said:


> There is. You can use Windows XP network drivers on FreeBSD with ndis(4). For Linux there is something similar called NDISwrapper.


But what about other hardware? Graphic cards, sound cards, there are also lots of drivers for notebook hardware.


----------



## Oko (Sep 12, 2015)

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?


Because the drivers are part of the kernel and Windows and FreeBSD kernel have nothing in common.


----------



## vasili111 (Sep 12, 2015)

Oko said:


> Because the drivers are part of the kernel and Windows and FreeBSD kernel have nothing in common.


Why not to create something like compatibility layer for Windows drivers then?


----------



## kpa (Sep 12, 2015)

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.


----------



## Oko (Sep 12, 2015)

vasili111 said:


> Why not to create something like compatibility layer for Windows drivers then?


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.


----------



## wblock@ (Sep 12, 2015)

vasili111 said:


> Why not to create something like compatibility layer for Windows drivers then?


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.


----------



## troublemaker (Sep 12, 2015)

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.


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


----------



## SirDice (Sep 14, 2015)

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).


----------



## Crivens (Sep 14, 2015)

Oko said:


> Because the drivers are part of the kernel and Windows and FreeBSD kernel have nothing in common.


... 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/...


----------



## Oko (Sep 14, 2015)

Crivens said:


> ... or at least Microsoft claims that (after consulting it's lawyers)


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. 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


----------



## protocelt (Sep 14, 2015)

Oko said:


> Damn no wonder Microsoft is using code and contributing financially to some other less relevant BSDs


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.


----------



## Oko (Sep 15, 2015)

protocelt said:


> Microsoft is contributing financially because it's 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.


And who demanded Windows Services for UNIX to be based on that less relevant BSD?


----------



## protocelt (Sep 15, 2015)

Oko said:


> And who demanded Windows Services for UNIX to be based on that less relevant BSD?


Windows Services for UNIX is/was a mix of BSD and GNU libraries, utilities, and applications that has since been discontinued.


----------



## Oko (Sep 15, 2015)

protocelt said:


> Windows Services for UNIX is/was a mix of BSD and GNU libraries, utilities, and applications that has since been discontinued.


Because as anyone familiar with GNU/Linux will tell you BSDs are dying and they are irrelevant


----------



## vasili111 (Sep 16, 2015)

wblock@ said:


> 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.


What about using part of the code that is created by ReactOS?


----------



## wblock@ (Sep 16, 2015)

It's possible.  The effort of getting it to run and working out the dependency and security issues are open questions.


----------

