Windows Drivers Under Linux?

sniggly writes "The Inquirer has an article about how Montreal, CA based Linuxant has created a 'compatibility wrapper' allowing standard Windows NDIS 5.0 drivers to work on linux. After pointing to another project allowing windows printer drivers to work on OS/2 the author asks 'Are printer and network card drivers going to become, over time, a commodity with Win32 drivers one day the 'de-facto standard' run via wrappers?"

Comments

Instability

[Anonymous Coward]

Most of the BSOD in Windows 2K/XP are caused by unstable drivers. Will using these drivers in these wrappers destabilize Linux as well?

Re:Instability

[mausmalone]

If there's one thing you can definitely hand to the Linux development community, its error handling. I bet if the driver dies, the wrapper will tell you something like "______________ Win32 driver has crashed. Restarting driver in 5..4..3..2..1"

Re:Instability

[AKnightCowboy]

Most of the BSOD in Windows 2K/XP are caused by unstable drivers.

That's true. Unstable drivers and faulty hardware. People always complain about BSOD under Windows, but since Win2k you should never get a BSOD anymore unless your hardware is broken somehow. For example, I kept getting lockups and blue screens but I traced it down to faulty memory. Another time it was an overheating video card because the fan on it died. Win2k is actually one of the most stable operating systems I've ever run.

Re:Instability

[Lothsahn]

Erm, sorta.

You shouldn't get a BSOD often unless:

a) Your hardware is broken
b) Your hardware's drivers have bugs in them

I have also had windows BSOD once or twice in my usage because of actual bugs in windows.

I did get BSOD's fairly often, which traced to a memory controller. That of course was fixed with a replacement board, but I still get them.

For instance, until 44.03, Nvidia's drivers had some funky bugs in them for the Geforce DDR and the Geforce FX 4600... on both cards my systems would crash with errors in nv4.dll. The cards are not faulty. I have 3 Geforce DDR's and there is no reason to believe that they are all broken in the same way.

Matter of fact, WinXP BSOD'ed 5 minutes after I finished the install with a nv4.dll problem.

Also, many Dell systems have faulty USB drivers. Plugging in a USB disk can BSOD the entire system.

Now, you may say that this is not Microsoft's fault, but I would argue that it is at least partially their fault. For instance, the Nvidia drivers were WHQL certified. Microsoft stated that they were acceptable drivers for their windows system. I hold them partially responsible for certifying faulty drivers... you know darn well that if Nvidia relies on their drivers getting certified... Microsoft does have power here and I suspect that if they had not certified the drivers Nvidia would have fixed them. The problem is that the WHQL certification team probably has the usual Microsoft quality control standards.

As for faulty memory, you should run memtest86 (www.memtest86.com) It'll let you know right away if your memory (and memory controller) are working correctly, as well as testing the memory interface on the CPU.

For the record, I primarily use Windows. Linux doesn't play many of my online games, such as DAOC. I'm not bashing windows for the sake of bashing windows. I'm just stating that to say that it should never BSOD is incorrect.

Funny windows drivers

[bobthemuse]

What about all the windows drivers which have a 'light' NDIS layer solely to establish a communications channel with the hardware and assignment of resources. They then rely on more complex programs to do what should happen in the driver.

I'm thinking of several printers, including the new MFDs, not to mention the separate mess called 'WinModems'.

Native Drivers, Please

[nurb432]

No thanks, id rather have native drivers for my hardware. Not some sort of kludgy hack to make windows drivers work..

Even if it worked well, there is no guarantee that Microsoft wouldn't make it impossible to keep doing this, leaving us out in the cold.

+ you cant honestly think performance and stability would be the same as a true, well written, native driver for your chosen OS ( regardless of what that OS is )

Re:Native Drivers, Please

[loucura!]

Even if it worked well, there is no guarantee that Microsoft wouldn't make it impossible to keep doing this, leaving us out in the cold.

The thing is, though, that Microsoft's driver APIs have to remain stable if they're going to get hardware manufacturers to write drivers for them. If they start making changes that break this driver compatibility layer, then they also break current drivers. There's no way to make the layer break without breaking backwards compatibility, and that still won't prevent you from using pre-break drivers.

Ultimate Lock In

[Crashmarik]

Not a good thing. If Drivers are written for windows and then emulated to other OS's it will give Windows a permanent performance advantage.

Re:Ultimate Lock In

[Hard_Code]

"If Drivers are written for windows and then emulated to other OS's it will give Windows a permanent performance advantage."

If drivers are written for windows and then "emulated" (not really emulated, just run through an abstraction API), it will render windows IRRELEVANT. Slow drivers run infinitely faster than NO DRIVERS. Once the drivers become commoditized a HUGE reason is eliminated for keeping Windows around (the current main reasons being ubiquity of 1) applications 2) drivers; we have already achieved #1).

Drivers are only really a performance concern (as far as an abstraction layer is concerned) for things like graphics card drivers, which are already woefully absent in Linux (and of course they change frequently as the technology is updated). I'd wager most "desktop" users of Linux don't even have kernels recompiled for their specific CPU, so I think an abstraction layer isn't going to make much of a difference.

Intel should sponsor this

[chevybowtie]

The way I see it, all of these layers of software are what are going to require faster processors. What exactly will you not be able to do next year with the 3Ghz processor you bought this year? Then again, are these layers going to cause bugs that can never be found?

Bad idea

[Simon Lyngshede]

This is an even worse idea than WINE. The only thing we'll gain from this is even fewer native Linux drivers. Im sure that if this works, many hardware companies won't even consider making native Linux drivers, because users can just use DriverLoader.

Things like DriverLoader and WINE are and will be misused by companies to claim Linux compatability or make quick and low quality Linux solutions. It would be great if it where to be used only as a last resort, not as a permanent solution.

We should kill of Linuxant before they hurt anyone.

Re:Bad idea

[IamTheRealMike]

I don't think you can draw comparisons.

Firstly, writing a new driver for Linux is several orders of magnitude easier than rewriting an entire application for portability. A program like MS Office will never, ever be a "native" app, say that uses GTK, Qt, whatever - it's far too huge to ever rewrite in that way.

A driver, on the other hand, is not so complex, and can be more easily developed independantly, especially by the community.

Really, Wine is useful primarily for apps that will never, ever be ported. I've seen little evidence that it discourages companies from doing native ports. I've seen quite a few companies do native ports even when their programs worked just fine in Wine. Only time will tell if this has bad effects or not.

Re:wow

[kasperd]

I've actually wondered about this before and if it was possible

In general it is not possible to use drivers under any other OS than the one it was developed for. And any kernel developer will tell you it is not a good idea. A driver needs to interface not only with the device, but also the OS. No matter how well it works with the device, it doesn't help making it work with another OS. Expecting a Windows driver to work with Linux is like expecting an SCSI driver to work with an IDE harddisk (maybe not the best anology, but it was the best I could come up with, and they have certainly been seen worse). In some cases you might be able to provide a wrapper, that makes it work, but it requires good knowledge about the interface in both directions, and the end result certainly isn't going to be as good as a native driver. If hardware vendors want a wide range of compatibility, they can easilly achieve it, it just takes a few steps.

• Use open standards whenever possible
• Provide sufficient documentation
• Provide an open source driver

Cross Platform Driver Standards

[hillct]

While on one level it's great to see this sort of standardization, one has to ask whether standardization on the WIndows driver architecture is the best choice. This is what standards organizations are for. While I like OSS as much as the next guy, and things like Wine, or other compatibility layers such as those mentioned in the article are certainly valuable in their own right, They shouldn't be seen as a mechanism for promoting standards. This just promotes adoption of proprietary mechanisms as de-facto standards, which is seldom a good thing.

I'm just waiting for Microsoft alter their EULA to disallow software written using their (presumably patented) driver architecture and copyrighted APIs on competing platforms, in a bid to deter hardware manufacturers from providing linux support by increasing the development costs for linux support through preventing unified cross-platform driver development.

--CTH

Do we need this? No today, less tomorrow...

[jurgen]

Are printer and network card drivers going to become, over time, a commodity with Win32 drivers one day the 'de-facto standard' run via wrappers?

First off as we all know from painful experience, a lot of windows drivers quite buggy. Since we have zero chance at fixing them (closed source), the only time anyone will use them is if they absolutely have to. Even with Windows drivers available and sort-of-linux-compatible, most people will continue to buy hardware that's directly supported under Linux... they will rightly expect it to work better.

Secondly, this is becoming less and less of an issue. More and more add-on hardware is built on standardized models of hardware interaction, such as the USB driver classes, and thus works with the generic drivers in the Linux kernel. Of the remainder, more and more hardware companies are seeing the value in cooperating with Open Source and opening up their specs. The probability that a random piece of peripheral hardware you bought at CompUSA or some such will work with Linux out of the box has been steadily increasing and is now quite high.

In short, this is a non-issue.

RE: native drivers

[vlad_petric]

Native drivers are obviously the right choice in the long term, but emulation is something that can break the vicious adoption cycle (hardware manufacturers aren't going to provide drivers until there is enough demand, while demand is small because of lack of drivers).

Take a look at the linux games area - Loki is dead, Transgaming is alive and well ... Loki's approach was technically superior (very stable ports as opposed to games which play ok, but only ok), but the economics were not.

Emulation is good for creating a market; when the market is big enough, native ports and drivers will arrive as well.