Hi!

I found NDISWrapper on sourceforge, but it is only meant for network cards. After seeing it, I wondered, why can't there be something like this for ALL windows device drivers. Then, there would be nothing stopping people from switching to linux. Isn't this a good idea. Maybe we could get some emulation layer going that implements the windows device driver api's on top of the linux kernel in the form of a kernel module. Is anyone else interested in starting some sort of Open Source Project which does this? If you are, e-mail me at iammisc@gmail.com. If about 3 people are willing to help, then maybe we can get something going.

Thanks.

A good idea, but ndiswrapper is generally only aimed at a very particular area of wireless networking cards, and will not work on all chipsets. Other wrappers exist for other wireless network cards. It exists due to closed specfications as much as my understanding lets me grasp. In general, other hardware is pretty well supported under Linux, wouldn't you say? Native drivers will generally be better for Linux that trying to run Windows emulation, and I think you'd struggle to cover so many types of hardware. I'm sure projects such as ALSA, for example, could do with your kind of enthusiasm and support to help improve a hardware support base for an exising project aimed at delivering Linux drivers.

I have had much trouble getting some devices to work on Linux such as the actiontec 802uat1 AND the gigafast wf741uic. I have tried NDISWrapper and he native linux drivers but still, none work. I try to ping another computer and it says host unreachable.

this is a question i have asked myself before.
windows offers a general API, the platform SDK, the "top side", and an interface for drivers, the DDK, one could call this the "bottom side". so, in order to allow developers to make apps and drivers for windows, it must expose sufficient information about the two interfaces. in theory, it should be possible to infer from the two specifications what's in between, or rather, what could be. the limited success of ndiswrapper and wine show that it's not that easy in practical, unfortunately.
but why is it, that we cannot simply go and buy some device and take it for granted that a working linux driver is included on the cd? why is only windows supported?
i think that each individual distribution of linux is superior to microsoft windows, but linux has two problems: a) poor documentation. why isnt there something like the msdn library for linux? b) no actual inter-distro compatibility. there is no binary compatibility between different linux distributions. different linux distributions use completely different packaging and software installation constructs. the different window managers use different api's. etc, etc.
on windows, it is possible to make a program, just like that. you get a castrated documentation that hides from you what's beneath the hood, but it's enough to create working software. if an executable runs on one windows, it will most likely run on every other, because they're all alike.
so i think the most sensible solution to the lack drivers, and in part also software programs, for linux, would be to define an unambiguous software and driver API for linux that all distro's will follow. kde and gnome must implement the same api, and also a uniform packaging/software installation system must be specified. (just like ISO have already suggested, but it must be done seriously) once that is up and running, maybe fewer manufacturers will hesitate to make their devices linux-compatible.

this is my opinion. think about it what you please, and post it.

I agree, why can't hardware manufacturers include a Linux driver in their software package. If you ask me, there should be a cross-platform library for device drivers, something like wxWidgets for GUI. Then, creating a Linux driver will be as simple as creating a Windows one. I think the problem with one binary working on all computers in Linux is kind of hard because of the different architectures. Something for i386 won't work on Power PC or a SPARC processor.

If you are really keen on cross-platform, then why not a java like device driver language?

exactly, that's a great idea!
well, the performance of a gfx written in java, for example, would be SHIT! but for these ones there could still be a uniform interface for all linuces that run on i386 processors, and, in theory, the same interface would be applicable to windows.
on the other hand, a driver for devices such as network cards, would work perfectly on any platform, and they would also be easy to write.

hey whaddya know! i just got an idea.
why don't some open source developers go ahead and specify a new api? i mean such a thing as the windows api; it should include all neccessary sorts of interfaces: thread and process management (as far as this can be abstracted), an interface to the window manager, networking stuff, filesystem access, etc. framebuffer/opengl support would also be good, but need not be included in the very first release.
right now, i'm talking about i386 only. so, the specification should also include its own .o/.obj and .a/.lib file formats, and, of course one for executables. this specification should be abstract enough to allow it to be implemented on all linuces, but concrete enough to allow it to exploit the advantage of knowing the underlying hardware architecture.
ok, then, given the api, one could write an implementation for each linux system, and even one for windows. this would be somewhat like wine, but with the big difference that this api is not closed source and does not contain undocumented parts, which has always been one of the big difficulties with wine.
now, imagine a program compiled for the specification. it would run as fast as a natively compiled binary, most api calls will simply forward their parameters to the api of the underlying system. at the same time, it would run on windows and all linuces without the need to be recompiled. 80-90% of all general-purpose software, such as office suites, photo editors, etc., could be compiled for our on-top interface, and would suffer no penalties, only gain the advantage of portability.
a group of developers would maintain the project and release installable packages for most os'es, along with the source code. people would only need to download and install the appropriate packages and here you go, perfect portability.

NOW WHERE IS THAT GROUP OF DEVELOPERS? GET MOVING, THIS TASK IS LONG OVERDUE!

Is there some place to suggest these things? As I said before, if two or three people volunteer to help, we can really get something going. What a wonderful day, every device that works on Windows works on Linux too. Then, everyone will want to switch to Linux with the proper marketing on Linux's part.

[edit] For the binary, use a windows PE binary because it works with Windows and it would be easy to use on Linux. Wine links PE binaries and can't run them perfectly but this driver API thing would link the PE binary where it already knows all the functions that could possibly be in the driver( because it can't use the standard library). So, it wouldn't really be like wine, even if it uses the same binary format. Darn, if we do this for drivers, why not for real software too. Add an API for the standard library, GUI, threads, etc. And then, instead of using Java for cross-platform, just use a native binary, for i386 only of course, which would run just as well as anything.

Cool!

in fact i was talking about real software when i talked about the wine-like interface, but, of course, about drivers, too.

although i was thinking of something similar to PE, i would rather not use PE especially, since it comes from Microsoft. but it would be easy to specify our own, similar file format. and in doing that, we would simply leave out some deprecated stuff, which is still part of PE, such as relocations for 16Bit code.

hell bite my ass! if it really came to that a unique driver-and-application interface existed for all i386 operating systems, windows would be completely exposed to the competition with linux. it would no longer be the no.1 choice just because noone wants to write linux software because the linux distros are too distinct. this would mean fair competition, allowing linux to show off its brawns! iammisc, we really got to get this show on the road!

Hello,

well some time ago I have als thougt about captive drivers (similar for writing to NTFS). But this will be a bad solution:

1.) Driver do a lot of things on a low level with interaction with the kernel. So using windows driver means implementing the APIs from windows which rely on the behaviour of the windows kernel. I think it will be a uggly system with a tainted kernel to get it compatible with the Windows driver model.

2.) The perfprmance ans stability will be not good

3.) And the most important: It is not needed! Why? You can manage all hardware (I say ALL) with Linux! The only problem is that manufacturers keep important information secret, so it is hard (and some times impossible) to build a driver. So the goal should be that manufacturers make Linux drivers (e.g. NVIDIA for graphic cards) and/or give at least the informations that other people can do it.

Conclusion:
Ask hardware manufacturers if they supporet Linux (even if you know that they don't). I think if the support teams get enough requests concerning Linux the guys from the marketing well be informed that there is something missing, and some days there will be Linux drivers! It's sure that we only buy hardware which is supported under Linux. Let the Windows only hardware in the store!

PS: Do the same for software. Ask commercial manufacturers "is thre a Linux version available?" There will be a moment where they cn no longer ignore Linux!

Solution for drivers:
Often manufacturers do not wan't to give the source code or informations away, ok. The problem with Linux is that there are a lot of different configurations available and some code must be compiled against the actual kernel. So my idea is that the source code rest by the manufacturers and there is a script collecting all informations needed for correct compiling the modules. These informations are send to the manufacture where the modules are compiled for the customer and send back via download / email. So the customer has a fine working binary and the manufacturer keep there secrets secret.

Does anyone know if such a solution already exists or is used by a manufacture?

RGummi

"Maybe we could get some emulation layer going that implements the windows device driver api's on top of the linux kernel in the form of a kernel module."

1. Microsoft has begun work on a new operating system called Singularity. Singularity contains several peculiar features. One of the wierd features is that the various components of the Singularity kernel are strongly seperated from each other is a way that kills performance. Microsoft's explanation of this extreme protection of the Singularity kernel from itself is that 85% of Windows crashes are caused by buggy hardware drivers written by the hardware vendors. By extreme seperation of the kernel components a buggy driver cannot crash Singularity.

2. When hardware vendors began writing Linux drivers for their hardware they split into two camps. One group of hardware vendors wrote open source hardware drivers for Linux. Another group insisted on donating proprietary binary drivers to Linux. Linus Torvalds relunctently accepted some of the proprietary binary drivers. After a year or so Linus issued an edict that hardware drivers would only be accepted if they were open source. It was impossible for the kernel developers to clean the bugs out of the closed source drivers.

So from these two points I reach the conclusion that if you succeed in writting an interface between the kernel and binary drivers written to Microsoft's interface specifications you will either greatly reduce Linux stability or you will have to greatly reduce Linux performance to maintain the current level of stability. I also seriously doubt that the kernel developers would accept such a monstrosity.

---------------------------
Steve Stites

Please note, we are no longer talking about emulation. This is a i386 native binary which does not rely on the Windows OR Linux kernel API's but rather on a generic API which could be supported by either operating system. So all the talk about windows driver emulation shouldn't be put in this thread.

"Please note, we are no longer talking about emulation."

I agree. I wasn't talking about emulation either. I assumed that the person using the word "emulation" was thinking of a wrapper. My comments also apply if you want to call it a generic API.

--------------------------
Steve Stites

1) although emulating windows on top of linux, and implementing our own on-top interface, are technically the same thing, there is still one big difference: with our own interface, we know ALL aspects of it, and there is NO possibility of undocumented portions. so, if our specification is unambiguous, ALL drivers that are correctly written according to the specification, will run on EVERY operating system that correctly implements the specification. the only requirement for perfect compatibility is that both sides (system and driver) perfectly obey the specification. concerning compatibility, this does not differ in any way from the java virtual machine.

2) i completely agree with the performance issues concerning such drivers. as i said, i was hardly thinking about a graphics driver or so to be implemented using our interface, because a graphics driver really needs performance. they still need to be written for each kernel individually. but drivers for wireless lan adapters, linmodems, etc, could as well be written in java. for them, compiled c/c++ code is performant enough. also, the existence of such an interface, is exactly what would encourage manufacturers to include linux drivers in the package. also, there is no reason to fear for stability. why should a driver implemented in a high-level interface be less stable than one running in real mode, where it can screw up a lot without getting caught?

3) the second thing we were talking about, was a similar interface for APPLICATIONS. this would not differ in any way from what wine is doing today, except for one thing: the lack of documentation and the closed-source implementation. this is also the reason why wine is functioning so poorly. by specifiying our own api, we will (a) break down these walls that wine is facing, and (b) take away the monopoly of specification from microsoft.

4) specifying a low-performance, high-compatibility interface for drivers will not forbid anyone to continue writing high-performance, distribution-specific drivers. besides, any poorly performing driver is way better than no driver at all. whenever a device works plug-and-play in windows, and in linux only after hours of googling around, downloading, compiling, patching, and compiling again, that's one for microsoft dictatorship, nil for the open source community.
just let us first make sure that there is a linux driver for every device at all, no matter the performance. let us then continue to optimize exactly those drivers that need optimization.

Correct me if i am wrong, we are talking only about i386 drivers that are written in native i386 assembler, right? So the binaries are linked at run-time, right? Then why should there be any performance problem.

the precious cpu time is not lost in the execution of the native assembler instruction the driver is composed of. it is lost in our compatibility layer. we will, in general, not be able to simply link a driver to functions already present in the system, since these functions will be different in each one. for each system, we will have to write wrapper functions that forwards the parameters it gets passed to the corresponding system call in a way that fits. with drivers that really depend on speed, this can potentially turn out to be a problem.
nevertheless, the performance impact caused by such a wrapping-mechanism if far less than that caused by interpreted code, such as java. so, the interface we're speaking of is exactly what the linux community needs today.

in history, the great ideas of ingenious men have always been doubted, until they were realized.