Slashdot Mirror
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?"
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'.
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 )
---- Booth was a patriot ----
Not a snowball's chance in Hell. A large part of Microsoft's power rests in limited device support for other OS's. They will keep the OS-specific requirements alive. This whole thing is a cool trick, but it's in the "why bother" class, along with NetBEUI for Linux.
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.
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?
It costs $15 to use the modem driver which is more money than I paid for my network card and modem combined.
Unless of course you only need to access your modem for 30 days.
The store can be found Here
Thank you Mario! But our princess is in another castle!
Yes, you too can have compatability with Windows crashes!
I realize that I'm sounding a bit sarcastic here, but it's a known fact that a lot of the issues with Windows stability are driver-related issues. I for one am not keen on running the graphics driver within ring 0 (which Microsoft does in NT at least) to speed up video performance. If the video driver runs in ring 0, a problem with the video card can bring down the whole system.
-- Joe
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.
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.
Do you care about the security of your wireless mouse?
Great, now Linux can be Windows compatible and crash just as much as Windows does! The most common cause for Windows crashes these days, I'm told, is bad drivers, not Windows itself. Do we really want to use such drivers?
Also, a driver might typically be running 24/7 on a server, managing hundreds of packets per seconds, so stability and performance are of utmost importance.
A wrapper is a nice idea, but definitely adds overhead, and probably makes the system less stable.
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.
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.
The Raven
Actually, network cards, modems and printers aren't really that interesting. There are usually choices (except if it's a laptop), and so you can always just buy something compatible. The real place this would be useful is in the case of "weird" hardware where it would be wonderful to be able to have WINE work with the driver. For example, the Psion Wavefinder (USB Digital radio receiver) which at the time was $60, and the only way to get digital radio for less than $450. There is often no alternative to "weird" hardware - anothe brand with similar function may not exist.
The reliability aspects of this are indeed dreadful, but could possibly be overcome if each driver ran in its own individual MMU-protected virtual machine. User-space module and driver mechanisms already exist, so this wouldn't be such a huge leap.
That could ensure that diver code never tramples on any other code and only communicates with the rest of the O/S via fixed interfaces. It could still hang of course, but dealing with that would be no different to dealing with other misbehaving user processes, and if the problem is severe enough to lock up the hardware under the driver's control then it'll do so regardless of the implementation.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
"Why can't devices provide java- or other-based interfaces..."
That would be a driver, then.
OpenFirmware's got forth-based drivers that are OS and platform/architecture agnostic.
There's no reason to require OS-specific drivers, other than performance.
Personally, I would love this, but I can't see it happening, if for no other reason, the Windows crowd - by far and away the majority - would complain about the performance hit.
This is wonderful news. Hardware compatability is Microsoft's edge. With driver compatability layers others operatings systems will break Microsoft's influence on hardware developers and even give an edge to Free OS's as they will be able to wrap drivers from abandoned platforms as well. Performance will NOT be impared that much until wrapers are available for video drivers. A user first wants it to work, then he wants it to perform better. One step at a time. With an emulation layer on linux, OS driver developers will be able to work from their prefered OS to analyze what the drivers are doing. It's easier to spy on hardware from Linux and other open operating systems. The technique will be ported to Freebsd and then to OSX. I would expect analysis tools to be co developed along with wrapper layers eventually. We will finally have a practical way to find out how hardware works and be able to document it. Wrappers are a tool, not the end goal.
Precisely. Just today, I was having numerous BSODs, but luckily the screens mentioned "multiple IRQ" problems. I traced it to an option in my sound driver control panel that was checked and shouldn't have been.
Voila, no more BSODs. And I even saw lessened choppiness in sound-heavy programs like Sonar.
Aside from those specific instances of hardware and driver issues, I have not seen a single BSOD since late 1999. Windows 2000 and XP are really incredibly stable operating systems, and I don't feel ashamed saying that on Slashdot (in fact, it needs to be said more often...if people were more calmly rational around here, it would help the Linux cause a lot more).
"Sufferin' succotash."
As for your system wide locks, I do know how the NT kernel works for locks, and let me tell you I've never heard of what you talk of, unless you have a link where I could read up, I don't think they exist either.
If the system ever appears to hang, it's because the IRQL has been raised: the IRQL is the *only* way you can mask interruptions in NT. In that respect, it is the only way you can mask pre-emption too, because the scheduler runs at DISPATCH_IRQL (that is PASSIVE_IRQL < APC_IRQL < DISPATCH_IRQL < AnyHardware_IRQL).
The only issue I know of that has always been annoying is the way NT deals with CD-ROM drives - but I don't see how that has anything to do with VS.net"
Enlighten us please. Oh, and please, I'm also curious, what does "more so preemtable" mean?
This is a trojan horse that will have two immediate consequences: 1) Manufacturers will just tell users and Linux kernel driver developers that they do not need drivers or specs. Just use the wrapper. 2) A new host of difficult to debug problems will creep in putting a blemish on the wonderful stability provided by Linux. Say no to this nonsense and demand native drivers.
Pragmatism as an ideology is not particularly pragmatic in the long term. Keep it in mind when you dismiss Free Software