Slashdot Mirror
Windows Drivers Under Linux?
sniggly writes "The Inquirer has an article about how Montreal, CA based Linuxant
has created a 'compatibility wrapper' allowing standard Windows NDIS 5.0 drivers to work on linux. After pointing to another project allowing windows printer drivers to work on OS/2 the author asks 'Are printer and network card drivers going to become, over time, a commodity with Win32 drivers one day the 'de-facto standard' run via wrappers?"
I doubt most printers have an NDIS layer. That is, unless the printer comes as an ISA, PCI, or PCMCIA card, and doubles as a networking card.
ATAPI (the protocol IDE CD-RW drives speak), is SCSI commands sent over an IDE interface. Think "code re-use".
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
IBM strangled the baby in the cradel with 10k per user tcpip stacks, 10k per user dev kits, 20 disk installs that you had to turn the cpu cache off to get it to install (8 hour installs), buuuuuuuuuuuugy ass drivers. 50 meg (at the time of 9600 baud modem) patches.
Once you finaly went through all that pain you could get the thing to work. Most people were not that masochistic.
Oh no doubt it was cool and could have STOMPED windows. It didnt because IBM was a hardware company that suddenly was selling software. They treated it like little black boxes you could sell. They didnt want to support it.
Also the gui LOOKED dated. Not to say it was, it just looked that way. 95 LOOKED cooler. Eye candy can sell alot of units. Plus you could buy 95 for 40-60 bucks while OS2 costed 150 and UP.
That's true. Unstable drivers and faulty hardware. People always complain about BSOD under Windows, but since Win2k you should never get a BSOD anymore unless your hardware is broken somehow. For example, I kept getting lockups and blue screens but I traced it down to faulty memory. Another time it was an overheating video card because the fan on it died. Win2k is actually one of the most stable operating systems I've ever run.
WxWindows appears to be the solution, yet it is "is a free C++ framework that facilitates cross platform software development, including GUIs, threads, sockets, database, file system access, etc." I remember of a sourceforge-hosted project that dealt specifically with cross-platform driver development, but the memory evades me at the moment. After a quick-search of google, appears Jungo WinDriver, but that wasn't the one I was thinking of.
Erm, sorta.
You shouldn't get a BSOD often unless:
a) Your hardware is broken
b) Your hardware's drivers have bugs in them
I have also had windows BSOD once or twice in my usage because of actual bugs in windows.
I did get BSOD's fairly often, which traced to a memory controller. That of course was fixed with a replacement board, but I still get them.
For instance, until 44.03, Nvidia's drivers had some funky bugs in them for the Geforce DDR and the Geforce FX 4600... on both cards my systems would crash with errors in nv4.dll. The cards are not faulty. I have 3 Geforce DDR's and there is no reason to believe that they are all broken in the same way.
Matter of fact, WinXP BSOD'ed 5 minutes after I finished the install with a nv4.dll problem.
Also, many Dell systems have faulty USB drivers. Plugging in a USB disk can BSOD the entire system.
Now, you may say that this is not Microsoft's fault, but I would argue that it is at least partially their fault. For instance, the Nvidia drivers were WHQL certified. Microsoft stated that they were acceptable drivers for their windows system. I hold them partially responsible for certifying faulty drivers... you know darn well that if Nvidia relies on their drivers getting certified... Microsoft does have power here and I suspect that if they had not certified the drivers Nvidia would have fixed them. The problem is that the WHQL certification team probably has the usual Microsoft quality control standards.
As for faulty memory, you should run memtest86 (www.memtest86.com) It'll let you know right away if your memory (and memory controller) are working correctly, as well as testing the memory interface on the CPU.
For the record, I primarily use Windows. Linux doesn't play many of my online games, such as DAOC. I'm not bashing windows for the sake of bashing windows. I'm just stating that to say that it should never BSOD is incorrect.
-=Lothsahn=-
You fucking fool.
The CSRSS bug of about a year ago totally disproves your theory. In that bug, any user could BSOD the system by sending a few backspaces followed by a ton of TAB characters in a console window. Apparently this caused some buffer pointer to go off in the weeds and since CSRSS is a critical system process when it dies the whole system dies. This bug could be triggered from batch file let alone a DLL you fuckwit.
Impossible? That is a very strong word and one you can't backup.
An adminstrator can install a service with SYSTEM priveleges. Now, with these priveleges one can basically do whatever they want. One can enter kernel mode, they can trash memory and DoS the system. Depending on how you do it you can simply lock the system up, or actually get a coveted BSOD.
This is no different than saying that with a setuid program in Linux one can get an oops, by walking over kernel memory (/dev/kmem).
Never? Really....
Run 'RhymBox' on your system for a while... then start up NetMeeting under a pre sp4 Win2k install. Crashed on me, my manager's machine, and numerous other people. Once sp4 came out that seemed to fix the problem though.
I'll let the rest of slashdot argue (mostly uselessly in the first 262 posts!) about whether its the right future direction or not... I'll try to do something more constructive like seeing if the darn thing actually works or not!!
</rant>
That out of my system...
Executive Summary: Yeah it works... I'm writing this over a fairly fast (2.6 mbps) 802.11g+cable connection. One big gotcha as of right now (version 1.05 of the driver) -- no WPA support. I had to drop my router to 128 bit WEP instead.
My setup:
Steps:
- Get the Windows driver from Dell [ http://www.linuxant.com/drivers_bcmwl/compatibili
t y.php ] and extract it under winxp. Copy the TMSetup subdirectory to a partition that is accessible to redhat (or at least the two files bcmwl5.inf and bcmwl5.sys)
- Get the rpm (follow the instructions [ http://www.linuxant.com/drivers_bcmwl/bcmwl5/inst
a ll.php ] on the Linuxant drivers page to make sure you get the right iX86 rpm -- mine was i686)
- Install the rpm -- notice it says you need to connect to http://localhost:18020 to finish the install. When I tried it it was asking for my root password... I'm not a fan of providing my root pwd to strange apps so here's what I did:
- Went as root in a terminal and killed the process titled bcmwl5webconfd.
- cd to
/usr/lib/bcmwl5driverloader and edited the file bcmwl5driverloader.conf and changed $UseAuth=0 (it was 1).
- Restarted bcmwl5webconfd again and followed the instructions to point it to the
.inf and the .sys file. Followed the instructions on the lunxiant site to get the driver license (30 days... yeah I know THAT sucks... especially now that I know it works!). Plug in the license key and email address you use (use a real one... you need to confirm receipt of email and confirmation key) into the setup and you are all set as far the install is concerned.
- Kill the bcmwl5webconfd daemon now.
- Start->System Tools->Network Device Control and add the device. I added it as eth1. My setting in the wireless settings tab are
- Mode is Auto
- I specified my SSID (its not broadcast on my network)
- Fixed the channel
- Entered the WEP hex key (stupid note: when it says hex keys should be prefixed by 0x -- please do it!)
- That was pretty much it... Activated the driver and it worked just fine. Checked stats using ipconfig -a... tested it by disabling (and removing the cable from) my lan connection. Tested the speeds for just the wireless and then with both interfaces up...
- Enjoy Wireless 802.11g freedom!
:)
Its up two hours and counting...