Try reporting a crash to the kernel guys with a tainted kernel...

If I worked for Creative I wouldn't

a) Have the cheapest card ever with CMSS-3D

b) Complain of the situation it is working only on windows

:-)

PS. Have you tried CMSS-3D?

What technologies do others have that beat CMSS-3D?

Well, I heard of some solutions of external devices that just bypass the OS completely, though that sounds expensive (compared to just running Windows, if the choice isn't hard between the OSes).

In fact, at one point I think this was specifically mentioned by AMD on their website as to why their Linux drivers lag so far behind when a new piece of hardware is offered.

a- nope, there are cheaper cardfs that support CMSS-3D. Of course those are really cards not USB however....

b- really? Asking why you cant use windows drivers with linux does seem an easy and lazy way to get hardware working with linux. Just creatives style.

Yes, I have tired CMSS-3D. I dont like it at all. If you really want 5.1/7.1 sound from headphones, get a set of 5.1/7.1 headhpones....

Beat? Depends on who you talk to, what music you play etc. Dolby headphone is at least comparable.

I start suspecting a JIT compilation of a windows driver to a linux driver that is done in such a low level might be possible, and not even expose that much from an engineering standpoint. Though I've no way of knowing if it's actually possible.

Is there a good reason Linus et al. *should* support windows drivers in the kernel?

I'm a bit confused about it: why should any os support drivers written to another os?

There is absolutely no reason for this. Not to mention that the kernels are completely different i.e. microkernel vs monolithic. I won't even mention the difference in licensing (proprietary vs FLOSS).

Linus may have a good laugh at the suggestion.

A little bit off topic but it reminds me of a hot discussion on the kernel mailing list when some guy happened to ask him if there was a good reason for not using c++. The answer was *colorful* indeed... :D

The difference though is that I'm not saying something totally stupid.

C is a systems language. A kernel is the de facto project it should be used on. Tons of people in fact use it for the totally wrong projects.

But a wrapper for windows drivers (that works) isn't a horrible idea. In fact, it would bring tons of people to the linux desktop.

Let's be honest here, linux kernel has the smartest people on the community, the rest are nothing compared to them, not by a long shot, by a monumentally large shot. If they want to do it they will do it.

They could make a wrapper that works _perfectly_, let alone I suspect they could make perfect wrapping of executables if they wanted to. I suspect it's politics more than technicalities after a point.

As to the technical reasons, consider that the Windows drivers are written to run on a Windows OS. Almost every one of those drivers, in order to run fast enough to work properly, uses hidden calls to the Windows kernel. Those call protocols and results of using them are NOT documented in public, and companies (and programmers) that write windows drivers must sign non-disclosure agreements before they can see any documentation about those "propitiatory" system calls.

In the driver's binary code (which, if you have a copy, you are not licensed to decompile) such calls are implemented as branches to some location in the kernel (which you are also not licensed to decompile). What the ndiswrapper does is to use the Wine project's simulation of the Windows OS (created by examination of the interprocess communication in a Windows system, not a decompilation) to run the driver.

Note that Microsoft deliberately changes the "hidden" system calls with every new OS release, and, sometimes, new "service pack." That forces the Wine project people to play "catch up" and results in a non-functioning ndiswrapper for most new hardware drivers.

Bottom line: The only way that the Linux kernel could support a (propitiatory) Windows driver would require that it support the same (undocumented and unknown) processing after a branch to the same (undocumented and unknown) location the the kernel. This, to put it mildly, would be a "bad idea." And it would probably require that all the kernel developers sign the non-disclosure agreements and pay the (massive) fees to MS. That, again, to put it mildly, is not very likely.

I didn't say it was stupid. It's just that you asked your question in a way suggesting that windows drivers support is a 'normal' thing.

This may apply to MS who tries everything so that hardware vendors provide only Windows drivers.

Not stupid, but a little foolish, because
Yes it is. As several people have pointed out, making one OS's kernel compatible with another does not make sense. The goal is to make an OS function as well as it can. That goal is impossible if the OS must include foreign code in order to run foreign programmes.

Nonsense.

Just like Toyota using Toyota engines and refusing to use Ford engines is political. Different operating systems means different. I did not think it was such a difficult concept to understand.


@PTrenholme
Nice post.

Windows or Ford doing politics doesn't negate Linux(kernel) having politics so why bring it up? Of course they have politics.