# Suggestion: Windows hardware drivers in Linux kernel

## M.D.

Warning: This is just a vague suggestion, not a howto nor anything that already works.

As many other Linux users I would appreciate if the Linux kernel had support for various hardware components at least in the time when the appropriate Windows drivers are released. Recently there is a discussion about the Intel PRO/Wireless 2100 WiFi adapter and Intel's willingness (or unwillingness) of releasing drivers for Linux.

And there is a plenty of other hardware which is more or less well supported in Windows (via supplied and ready to use driver), but without any support in Linux.

However in other areas it is already possible to use Windows binary code in Linux enviroment. Remember MPlayer (http://www.mplayerhq.hu/) which supports (among others) many DirectShow and QuickTime (for Windows) codecs using a Wine-derived loader/wrapper (emulating a few necessary Windows functions and translating the codec specific API to MPlayer's API).

If there is some kernel hacker out there, please consider my suggestion: Would it be possible to make some kind of loader/wrapper for using Windows hardware drivers in the Linux kernel (you know, loading the driver, emulating a minimal necessary environment and bridging the Windows specific API [like the network adapter API] to Linux API)?

Before you reply something like "That is totally impossible, do you imagine the complexity..." -- stop!

I can well see all the obstacles. Making such wrapper to work in kernel space is much more complicated than in user space, every little bug can be fatal. Microsoft's documentation of the internal NT kernel to driver API is undoubtedly difficult/expensive to get. Running strange binary code in the kernel probably violates GPL and is generally a security risk.

But as we consider the cons, we should also consider the pros. Thanks for comments.

----------

## MorphiusFaydal

i have an unsupported network card, and i think it would be great if someone could do this...

yeah..

chris

----------

## zhenlin

Writing Windows drivers is like Magic. Finding them Driver API Specs is going to be hard, as you said.

WINE for drivers? No. libwine for drivers? Maybe. 

Creating all these compatibility packages reduces incentive to write an open-source Linux driver.

Also, I'd like to scream... DUP! But I can't find the previous topic.

----------

## TenPin

I think this would be a very bad idea simply for the reason that it would disuade manufacturers to write native linux drivers.

I also think most linux developers would either chuckle or groan at the thought. Any time that could be spent doing this would be infinitely better spent writing real linux drivers by reverse engineering windows ones to get the specs.

I would be a fairly interesting project/achievement but in doing so be a monumental waste of time.

----------

## someguy

i agree with the coments that would state that this is a VERRY bad idea first we have compatibility problems betweem the two osses ( can we say stability issues)??

----------

## BradN

Not only the stability issues, but I'd imagine it would require writing some sort of wrapper for each different driver type - ie, specific extra code needed for network cards (this might be one of the easier things to support), extra support for sound, etc.  The overhead of emulating the windows interface would almost assuredly slow down the driver a lot too.  Also, this might lead to a situation where some devices work only on x86 where they could (if they had a proper driver) work on other architectures as well.

----------

## Weejoker

A good idea (which I have considered before), but as stated above, creating a wrapper around each driver could be troublesome, possibly even requiring VXD/SYS files from other locations (usually from a Windows installation). This is a potential dependency problem, which could lead to legal issues regarding methods to obtain such files. Also, I'd say that using a "hack" around a hardware windows driver could perhaps be suboptimal in terms of performance. 

I think there are two options to getting a driver produced: 

1) Notify the hardware manufacturer of your desire for a driver, perhaps as a group and see if you can make them sway their decision.

2) Reverse engineer the windows driver to uncover the inner workings and produce a driver from that.

I've seen the latter work on the Epson EPL printer driver (http://epsonepl.sourceforge.net). Two people essentially reverse-engineered the compression and the protocol seperately. Once these two people got in contact they essentially built the driver in a matter of days.

Now I need to wait for someone to reverse-engineer the ESS Tech 1989 modem...  :Smile: 

----------

## ferringb

While I realize you're not after the "this is impossible", there is a pretty major difference in interfaces.  The level of wrappers required (one for irc, one for making vfs appear windows native, buffering/signaling) is mind boggling.

Basically, reverse engineering the device (or better yet digging up the chipset specs) would be quicker then writing the wrappers needed, plus they'd not run dog slow due to layers upon layers of wrappers.

----------

## M.D.

Hello, after several weeks I'm back to this old topic.

Yes, I totally agree that the time spent on programming driver wrapper and emulation layer is wasted when you have the possibility/knowledge/patience to reverse-engineer the Windows driver and write a Linux-native one.

But have you seen some of the Windows drivers? Like that from Intel PRO/2100 Wreless (Centrino)? That .sys has more that 2 MB and I don't really believe that 90 % of it is just junk to fool the hackers.

A native driver is always the best solution and a GPL'ed driver is nirvana. But if there is no real chance to get the driver and you would really like to have the damned piece of hardware working, why not use an emulator/wrapper?

And they did it. Have a look at http://www.linuxant.com/ and enjoy your Centrino WiFi working in Linux. I know, it's not GPL, it's "for free" just for one month, but it works.

----------

## ferringb

 *M.D. wrote:*   

> And they did it. Have a look at http://www.linuxant.com/ and enjoy your Centrino WiFi working in Linux. I know, it's not GPL, it's "for free" just for one month, but it works.

 

Yeah, I'd noticed that... definitely proved me wrong on that one... heh heh...

Back to the thread topic, I'd be curious how well they behave?  Have you tried out the linuxant drivers?

----------

## M.D.

 *ferringb wrote:*   

> Back to the thread topic, I'd be curious how well they behave?  Have you tried out the linuxant drivers?

 

Well, first you have to ignore some strange things about the driver. Like that the kernel module starts a Perl script (in user land) which binds the TCP port 18020 on local loop - this is for the web configuration interface. After supplying the root password to this interface you upload the Windows' NDIS driver and configure the kernel module. I believe that a simple ncurses interface (or even a simple Perl script in console) would have been a better solution. I don't like to meddle with my kernel from a web browser, but perhaps I'm just too much behind the times...

Second strange moment is then you have to obtain a license key from the Linuxant web site (it's generated from your email and MAC address). I deeply hope this is just a temporal solution, because having a license key for 30 days is the right opposite to >free< (as speech).

But let's repeat the idea that a native Linux driver is always the best solution and this driver emulator is just a last resort.

The driver successfully detects and initializes my Intel PRO/2100 Wireless (Centrino) MiniPCI card and probably works (I can tell just from the flashing LED on my notebook, because I'm currently not in a range of some WiFi network).

A more or less major bug is that the WiFi card gets detected just for the first time after reboot, when you try to rmmod and insmod the module again, it fails. Good news on the other hand is that there are no lockups or other problems with the stability of the driver module (I'm using xfs-sources).

I going to do some real tests later this afternoon.

----------

## yemu

i don't really like idea because it discourage manufactures from producing native linux drivers. other thing is that buying drivers from linuxant you pay twice - first time for equipment and second for drivers - and lazy producers earn twice - first time when thay sell you the product, and second time when they sell product specs to linuxant.

best regards

yemu

----------

## M.D.

 *yemu wrote:*   

> i don't really like idea because it discourage manufactures from producing native linux drivers. other thing is that buying drivers from linuxant you pay twice - first time for equipment and second for drivers - and lazy producers earn twice - first time when thay sell you the product, and second time when they sell product specs to linuxant.

 

Yes, I can see your point and I understand. But I think that the relationship between native and emulated drivers is just the same as the relationship between native user-space programs and Windows programs emulated in Wine. No one is willing to sacrifice Linux software and just use Linux as a very stable kernel for running Windows programs in Wine. And almost nobody sees Wine as a threat to native Linux programs, rather as a possibility to use Windows binaries in the case when you simply don't have any other option (except using real MS Windows).

The driver issue is very similar: Sooner or later every piece of hardware will eventually have native support in Linux -- either by the work of the community or from the manufacturer. But sometimes it takes too long (especially when the manufacturer doesn't even release technical specifications and the driver must be reverse-engineered) and the DriverLoader wrapper can bridge this period.

Please note that the DriverLoader is a general wrapper/emulator. It is not a special commercial driver for a single WiFi card. With little luck you can use it to run any NDIS driver for any network interface (at least you have the chance).

If the manufacturer is unable or unwilling to release their own driver with the GPL license or give the community sufficient specifications, then I don't really care if their (in fact crippled) Linux driver is "just" binary-only, commissioned by someone else (but still for free) or an emulated Windows driver. All these "solutions" are equally bad -- you have a working driver though, but it's not free (as speech).

I won't stop demainding a native Centrino driver from Intel. On the contrary, now I can say: "Hey, did you notice that Centrino driver works even emulated? So writing a native driver shouldn't be so hard." But until the release I will be using DriverLoader, because it makes my hardware working. Period.

----------

## M.D.

Finally I had a chance to test DriverLoader with my Intel PRO/2100 Wireless (Centrino) in both managed and unmanaged mode. My kernel is xfs-sources-2.4.20-r3.

The emulated driver is perfectly stable in 2.4.20 (except the rmmod+insmod bug, see my post above), the performance is no issue, too. The power management is not working well yet. I'm not an expert in WiFi technology, so please don't ask we which features are actually supported and which are not, but from an advanced user point of view the wrapper works.

----------

## deviljelly

try this it is GPL

http://ndiswrapper.sourceforge.net/

----------

## incubator

I understand very well it isnt advisable to make such wrappers, but then there should be an increased production, either by manufacturers or by other persons, of linux-drivers for hardware.

I mean, just now I did so much trouble to get me a printer that should work well under linux but still doesnt. And it makes me feel like I wasted my money big time  :Sad: 

----------

