![Software Software](http://a.fsdn.com/sd/topics/software_64.png)
![Operating Systems Operating Systems](http://a.fsdn.com/sd/topics/os_64.png)
![Windows Windows](http://a.fsdn.com/sd/topics/windows_64.png)
![Linux Linux](http://a.fsdn.com/sd/topics/linux_64.png)
Windows Drivers Under Linux? 474
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?"
Instability (Score:5, Interesting)
Re:Instability (Score:2)
I imagine this wrapper as a kernel module (i.e. it gets part of the kernel) which itself loads the windows drivers. I.e. the windows driver it more or less part of the kernel and as such can bring the kernel down if it acts stupid.
Re:Instability (Score:3, Interesting)
Re:Instability (Score:4, Interesting)
Re:Instability (Score:4, Informative)
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 (Score:3, Informative)
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 w
Informative??? It must be either troll or funny!!! (Score:3, Interesting)
Another several lockups with BSOD were caused by unstable NTFS. I wonder how many more decades Microsoft will deliver that must-already-be-dead filesystem?
Somebody, fix the moderation of the parent properly!
Re:Instability (Score:3, Informative)
Never? Really....
Run 'RhymBox' on your system for a while... then start up Net
Re:Instability (Score:3, Interesting)
I wrote a Java program that would BSOD XP after about 20 minutes of running. The online crash analysis told me that Microsoft were aware of the problem and looking into it.
I tried the same program on Linux and found that I had a file descriptor leak (through Runtime.exec() calls), it would throw an exception citing "Too many open files" after around 20 minutes. The box stayed up just fine though...
Still seems like there are some bugs in XP that are not driver or HW related...
Thanks
Re:Instability (Score:3, Interesting)
You do realise you just proved the point, don't you?
Let's see:
Now what system handles this better? Regardless how badly the app is programmed, no way a userspace application should cause a kernel panic. The fact that it can do so on Win2k is testament to Win2k'
Re:Instability (Score:2)
Re:Instability (Score:3, Insightful)
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
Re:Instability (Score:2)
Cool (Score:3, Interesting)
Re:Cool (Score:2)
My own rights of possession supercede any contracts that I might sign, any EULA, or the letter of any law. If I have to be an outlaw to fully use something that I own, c'est la vie.
Of course, the definition of "ownership" can be problematic for some people, but if I paid
Re:Cool (Score:2)
the current "kernel driver modules that break or have to be recompiled for every kernel update or option change" totally sucks. the GPL ideology hasn't worked f
Funny windows drivers (Score:5, Insightful)
I'm thinking of several printers, including the new MFDs, not to mention the separate mess called 'WinModems'.
Re:Funny windows drivers (Score:3, Informative)
Native Drivers, Please (Score:5, Insightful)
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 (Score:2)
Parrot and the JVM are of course, more current. Your OS runs your programs on your behalf too.
All this thing is, is a consistent layer that interprets something. Hardly a cludge.
Much lower level.. (Score:2)
Application virtualization is bad enough as far as im concerned, but its hard to avoid 100%.
Actally, I prefer to compile even my java and python, when possible, and dump the VM layer.
Re:Much lower level.. (Score:2)
Re:Native Drivers, Please (Score:2)
Well, if you are saying that the driver-wrapper actually reads the x86 binary, and interprets that, then you really have a marvel of engineering.
But what makes sense, and would probably be possible to do is to just create a wrapper. The driver expects certain "hooks" to be able to talk to Windows. The wrapper provides them, and
Re:Native Drivers, Please (Score:2)
Re:Native Drivers, Please (Score:4, Insightful)
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.
Re:Native Drivers, Please (Score:3, Interesting)
Well, Apple has done this regularly, so I don't see why Microsoft wouldn't. I think it was the release of Mac OS X 10.2 ("Jaguar") that broke everybody's printer drivers ... printers that used to work with the earlier versions. Apple works with the ma
Re:Native Drivers, Please (Score:2)
Re:Native Drivers, Please (Score:2)
Re:Native Drivers, Please (Score:3, Insightful)
Are you going to write those native drivers? Many of them do not exist today.
I'd rather have a kludgy hack then no drivers.
Re:Native Drivers, Please (Score:2)
Now, on the other hand, if hardware manufacturers want to do this, write a common binary and provide wrappers for various platforms, I'm all for it. After all, it's better than nothing.
Give each driver an MMU-protected VM? (Score:3, Insightful)
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,
Re:Native Drivers, Please (Score:2)
This remind me I2O. If I remember corectly, I2O idea is to have OS-indepedent drivers supplied and connected to real OS via think I2O layer. This idea seems dead, althrough.
Not likely. (Score:2, Insightful)
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.
Ultimate Lock In (Score:5, Insightful)
Re:Ultimate Lock In (Score:5, Insightful)
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.
Re:Ultimate Lock In (Score:2)
Re:Ultimate Lock In (Score:2)
Graphics cards
Storage Devices
Network Cards
Data Acquisition Devices
Serial Ports
Manufacturing Equipment
Oh well just off the top of my head. The above are all things where people get very upset about performance hits. Believe me when you have 64 serial ports serving terminals on a system you feel the pain of interrupt latency.
Rendering Windows Irrelevant are you ev
Re:Ultimate Lock In (Score:2)
Oh just a note the windows thunking layer has a horrible performance hit and its not doing much at all.
Re:Ultimate Lock In (Score:2)
Providing a compatible interface isn't necessarily "emulation".
Consider WINE: Its implimentation of some parts of the win32 API is faster than the Microsoft implementation of those same functions; for that reason, apps running against WINE are sometimes faster than their native equivalents.
Re:Ultimate Lock In (Score:2)
Re:Ultimate Lock In (Score:2)
Do you even understand what you are talking about ? Or how little relevance it has to the topic. What I said was in effect if you put chains on your wheels to make them work on snowy roads your performance will go down. What you said is no these people rebuild the car and it works fine. Or to put it another way, I said adding layers to code incurs a performance hit, you said this can rewrite bad code so its better. Dynamo is essentially hotspot compiler dynamicall
Intel should sponsor this (Score:3, Insightful)
Too bad it costs money (Score:2, Insightful)
Unless of course you only need to access your modem for 30 days.
The store can be found Here [linuxant.com]
Re:Too bad it costs money (Score:2)
Re:Too bad it costs money (Score:2)
It's kind of like MPlayer (Score:2, Troll)
Re:It's kind of like MPlayer (Score:2)
If the 1% of proprietary crap on your system makes it usable, with the option being a 100% proprietary environment, I'm all for the little bit of proprietary crap. If proprietary stuff brings more users, more and better Free Software will be developed.
Comment removed (Score:5, Insightful)
Re:Bad idea (Score:2)
OS/2 advocates often point the fact that OS/2 being a "better Windows than Windows" strangled the OS/2 application development industry in it's cradle.
Who would write applications for OS/2 when you could just write them for Windows and they would run on OS/2 without problems?
Similarly, who would want to develop drivers for Linux when Linux runs Windows drivers without problems? Devices on Linux would always be subjected to extra layers that may or may not allow access to all of the device featur
Re:Bad idea (Score:2)
The main thing to consider is that very few companies make native Linux drivers for their products (well, consumer products anyway). So in that aspect, we're already getting zero support from them. I don't see any reason f
Re:Bad idea (Score:4, Interesting)
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:Bad idea (Score:2)
We should kill of Linuxant before they hurt anyone.
I hope this was written in jest. Otherwise, we'd be stooping to some of the same tactics that made Microsoft so infamous. Let people
Re:Bad idea (Score:2)
Yes.. that is an actual card.. may have gotten the first two digits wrong
Re:Bad idea (Score:2)
But, they are also making native Linux drivers for Conexant Win-modems. This is a good thing for those who are unfortunate enough to be stuck with one.
Re:Bad idea (Score:2)
DriverLoader is not GPL, but now that someone has thought of the idea, how long until someone writes a GPL clone? Is the open source community just "causing the tail lights of commercial innovation" again?
Cross Platform Driver Standards (Score:5, Interesting)
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
That's nice, but ... (Score:3, Insightful)
Re:That's nice, but ... (Score:2)
The bad drivers may trigger the crash, but the crash itself is still due to a flaw in the OS. In Windows everything is tightly tied to everything else making the whole structure brittle.
In UNIX and Unix alikes things are more modular with every function keeping its own place and continuing to chug along when something else goes screwy.
It's the prime reason that DARPA ended up giving Unix favored status for internet infrastructure. The core
Re:That's nice, but ... (Score:2)
Uh. *glances at his Powerbook running Mac OS X* *glances at Mach microkernel*
The Windows Standard (Score:2)
If only Microsoft could be so smart. I have an old sound card that still works, but the company went under so there are no new drivers for XP and it won't work.
Now should we use ECMA, ISO or some other standards body? Is it possible for windows to be defined as
WinPrinters/WinModems (Score:3, Interesting)
Rus
Re:WinPrinters/WinModems (Score:2)
Ok for short term (Score:2)
If this product could solve the problem of 2D hardwar
performance and stability (Score:3, Insightful)
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.
Re:performance and stability (Score:2, Interesting)
P
Do we need this? No today, less tomorrow... (Score:3, Insightful)
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:Do we need this? No today, less tomorrow... (Score:2)
On the other hand, I tried it on my evil twin pc running XP (it's for my wife and roommate). After
RE: native drivers (Score:4, Insightful)
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.
C128 (Score:2)
Commodore Business Machines tried this with the Commodore 128. It was completely backward compatible with the Commodore 64, You would hold down a key on boot and it would boot into C64 mode. This actually kept the C128 from catching on - every C128 sold was just another C64 in the market so network effects simply strengthened the C64 software base and little C128 software was written beca
Re:C128 (Score:2)
PS2 runs PS1 games, but you also get so much more from a PS2 game.
Loki = Bad Business model.. (Score:2)
Besides, lets not write off companies like Linux Game Publishing [linuxgamepublishing.com] (or ID Software [idsoftware.com] or Epic Games [epicgames.com] or
Funny that you mention ID & Epic (Score:2)
Neither of these 2 companies actually make money with Linux sales (I believe that they do cover porting costs, but nothing more than that)
Yes, LGP is great - my heart is with them. When a good game (that I also like) comes from them, my money will be with them, too ...
In a way this is good. (Score:2)
usb hardware? (Score:2, Insightful)
Re:usb hardware? (Score:2)
Re:usb hardware? (Score:2)
64, I would hope... (Score:2)
If this is done, I'd hope it would be for Win64 drivers. Why spend good effort on what (we hope) will soon be an obsolete standard?
This only works for x86 (Score:2)
A native Linux driver would be much more preferable since you could use it on all platforms supported by Linux.This would also be an advantage for the hardware manufacturers because they would get instantly (maybe not instantly but soon) support for those platforms and increase their customer base.
Working with an adaptation layer seems great in the short run, but hurts a lot in the
Um, wow... (Score:2)
Of course, we mustn't blame Linuxant for being forced to "play the money game."
There is a Fly in this Ointment (Score:2)
Also expect them to pressure any other driver writers who what the
Too little, too late? (Score:2)
proprietary drivers hide stability and security (Score:2)
We verify the stability of such drivers?
And if bugs are found, we cannot do anything about them until our driver providers decides to fix them.
How could we check what else it might be doing?
If we grow to depend on these proprietary additions, how will we fight overactive-DRM?
I think it is short-sighted to see this as a solution.
Re: (Score:2)
don't think so (Score:2)
And why would you want to? I have generally found Windows drivers to be junk; they usually look like they are produced by minimum wage programmers. Most vendors probably don't produce open source drivers because they are too embarrassed to share their code and because they don't have the engineering documentation to share
GREAT idea, but.... (Score:2)
This would be GREAT for the linmodem project.
I can see where this would work for miniport (Score:2)
Please god no. (Score:2)
Linux compatability + Better branding... (Score:2)
We have never had some much potential interest as now.
Re:wow (Score:3, Insightful)
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
Re:wow (Score:2)
So what, if the video driver has a problem you can't see the screen to anything anyway and will eventually have to restart. Sure you could ssh telnet etc etc ad naseum, but you are still going to have to restart to have your system be totally usable again.
Re:wow (Score:2)
Also, remember: On Linux your "video driver" is running inside a separate program (the X server); forcefully restarting that program will very, very frequently fix involved problems.
This is part of why I think it would be interesting to port DriverLoader's technology to a microkernel OS (such that they can be Just Another Process, like any other, instead of running the ported driver in kernel space).
BTW, if lookin
Re:wow (Score:2)
Even here at home, having X in user-space as opposed to kernel-space is quite handy. If X becomes unresponsi
Re:wow (Score:5, Insightful)
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.
Re:wow (Score:2, Troll)
expecting an SCSI driver to work with an IDE harddisk
you mean like how Linux IDE code and CD-ROM burning require Linux's SCSI support? talk about a hacked up system with broken modularity..
Re:wow (Score:2)
Re:wow (Score:2)
Well.. in theory
Re:wow (Score:2, Informative)
Re:wow (Score:2)
...and yet, it does seem to be possible for Windows NDIS drivers running under Linux. Keep in mind that NDIS drivers are, for the most part, not direct-hardware drivers. Many NDIS drivers' only interface is via an API, which could be implemented on any platform (though it is an ugly API so it can be painful).
This kernel developer will tell you th
Re:Mac OS X??? (Score:2)
for those not in the loop, UMAX decided that a lot of their scanners weren't worth writing drivers for for OS X. Also, they've started charging for copies of their drivers if they're available. If you complain, they tell you "well, buy a new scanner and you won't have that problem." Canon CanoScan 6500u is like $25 now, gets decent images, and runs in both Windows and Mac. DIE UMAX DIE
Re:Mac OS X??? (Score:2)