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 HTMLA 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.