To read all comments associated with this story, please click here.
I was post a quick one-liner about "can directly use" followed bu "with Ndiswrapper" but I'd rather help clarify.
- If you are using the driver inside a wrapper then the OS kernel is not using the driver directly. The wrapper is translating between the Windows driver and host OS.
- With Ndiswrapper specifically, one should get basic NIC functions from the Windows driver however it may not provide more advanced functions beyond the basic connection (no packet injection or other fun).
- How easily you'll be configuring the driver inside ndiswrapper inside the OS driver framework depends on the distribution. Mandriva manages it well including a "would you like to use a Windows driver for your NIC" during the installation wizard.
The solution to all of this is convincing NIC (and other hardware manufacturers) that drivers and/or driver interface specs are part of public documentation that increases there potential customer base. If they want to make utilities closed source and "value add" bits of the hardware product then fine but closed drivers from a vendor deciding what limited OS I can run there hardware under is madness. I've yet to hear a rational reason that drivers or driver interface specs should be hidden away like they are. (Broadcom, your "but people will change the power output" excuse doesn't fly either.)




Member since:
2006-08-18
Does ReactOS have a more complete Win32 and Direct3D implementation than the newest Wine and Crossover releases?
How complete is Windows driver ABI support? For example, could someone install video drivers designed for Windows XP and play Modern Warfare 2 on ReactOS like you can with Wine on Linux?
Supporting Windows drivers is neat, but only if it really works. Linux has drivers for devices across multiple architectures--although some are half-baked. However, Linux can directly use some Windows network device drivers using NDISWrapper.