The Holy Grail.... using Win32 drivers in other x86 OS's

[Floid]

lorddef wrote:
nice, but I only see it as something to make do, no matter what they say surely performance goes out the window?

Consider an X client on *NIX to an X server on Windows over Myrinet or some other ridiculous-throughput link.

That said, yeah, there will be overheads, but we're to the point where we can afford to run software again.  (The early OS/2/'9x/Linux era had us straining to run the OSes themselves, though most of the bloat was/is, as always, in the UI.)

CPU time and RAM space are like air these days, so the only real problem is keeping the latencies down.  (No idea how possible that is, of course, but both Windows and Linux run their drivers with 'kernel-land' permissions.  NDIS is an extra-special case, because it really /was/ designed for interoperability to some extent... This isn't Bochs, VICE, snes9x, VMWare, or really even WINE; this is taking what are basically prewritten chunks of assembler that do exactly what you want to do, and creating a 'wrapping' pretty equivalent to what Windows had to implement anyway.  Of course, if the code relies on really specific ideas of Windows' timings to perform properly, then you'll see a big hit, but PCI is PCI and much of the point of complex MAC* designs is to offload that sort of timing determinism from the host.)

Background on NDIS from FOLDOC...
NDIS 2.01 spec in PDF ... And Googled into HTML
A page with more links than you'd ever want...

*Hrm, 'MAC' is what I'm looking for, right?  'Ethernet chipset'... and the features in question are things like interrupt coalescing, receive filtering, checksum offloading and so on, that make using hardware more complex to support than an NE2000 worthwhile.  AFAIK, given the nature of PCI... either it's going to work well or not at all.

[Floid]

Wishmaster wrote:
Would it even make sense to emulate the drivers on the other different CPUs too?

I'm going to take a stab at "not really."  They're x86 binaries; they still had to be rebuilt for Alpha (and the never-released? PowerPC ports of OS/2 and NT).  Throwing in an x86 emulator might be 'affordable' someday (see the side of the fence that figures x86 is the 'real world''s VP/Java/CLR abstraction), but what makes it performant (and relatively 'clean,' considering what's involved) right now is the fact that you don't have to.

"Philosophically"/"Politically," if you deathly need a particular peripheral, and can't convince the manufacturer to target the platform you want to run it on... a) why are you on that platform? and/or b) why are you struggling to use a peripheral from someone who can't give two shakes about you?  There are always special cases (HomePNA 2.0 cards being a personally galling one), but it's almost lucky that this didn't crop up before Linux grew strong driver/manufacturer support of its own.

Now, some sort of API/ABI wrapper to grind BSD driver sources/modules (Linux modules might be a little gray-to-unpossible as far as the GPL is concerned?) into something any of 'our' OSes could use would be [good | not so self-destructive]... In that case, even if people aren't targeting 'us' specifically, they'd be targeting something that guarantees our access to their work.  The BSD API(s) would make a much safer "lingua franca" from a legal perspective than some spec MS is free to break, EULA, NDA, or patent out from under folk. ... Though they're prone to break enough on their own that it might be smart to see if DragonFly stabilizes/better modularizes of that structure.  (As it stands, I think you'd end up having to emulate giant swaths of kernel, at which point it'd be more expedient just to write your own drivers working from the reference -- which smart people do today, though they don't always get it right.)