|
|
|
| Device Driver Development Tips
|
 | Windows 95/Windows 98 |
| Windows 98 SE |
| Windows Millennium |
| Windows NT |
| Windows 2000 |
| Linux? |
Some of the drives carry multiple versions of closely-related OS versions or Service Packs. There are extra's for Beta versions of Microsoft products.
Each machine also has a second fixed disk that has files (e.g., source files) that need to be accessible from any OS.
Since boot drives are usually large enough, we install development tools (compilers, SoftIce) on each boot drive. There is redundancy, but also simplicity in this approach.
DDK (all versions) are placed on the fixed disk - usually on a FAT partition - where they can be accessed from any booted OS.
(Ok. I'll be honest. I have additional dedicated single-processor workstations/servers and notebooks in my office as well. However, they are primarily dedicated to non-developmental tasks like documentation, e-mail, newsreader, SourceSafe, etc.)
You need to prepare for the occasion when an automatically-loaded driver that you are developing has a fatal bug that always occurs as the system is starting up. You can't do anything about the bug until the system is restarted. However, the system can't restart because of your driver's bug.
A nickname for this recursive problem is "Catch-22".
There are several ways to deal with this, including:
| Install multiple OS versions on each boot disk (e.g., Free and Checked build) |
| Boot to Safe Mode. |
| Have Recommended Startup/Recovery Floppies |
| Have a Hardware Profile (e.g., "No Network) where your test driver is disabled. |
We recommend that you plan for and support as many safe startup mechanisms that are available available to you.
If you want to restart and get back to work fixing the bug as quickly as possible, then the Hardware Profile method may be the technique that you will use more often. It has the following virtues:
| Faster boot then Safe Mode. |
| Much faster then booting from floppies. |
| You boot to OS with all your tools. |
The proliferation of broadband Internet access has brought with it the added benefit of inexpensive gateway routers - some costing less than $150.00. Take advantage of these tools.
We suggest that instead of providing each network driver developer with a traditional hub in the work area, provide a broadband gateway router instead. One of the developer's workstations can be in the "DMZ" (actually, your corporate Intranet) for e-mail and other traditional uses.
However, the addition of the router provides each developer with their own Class C network that is isolated from the rest of the Intranet/Internet. A perfect sub network for testing.
PCAUSA uses Netopia R9100 and R3100 routers at the actual Internet gateway. However, less expensive gateway routers from LinkSys and D-Link are suitable for individual developer's private networks.
... and NIC drivers. Manufacturer-provided drivers and Microsoft-provided NIC drivers often behave differently.
...Keep notes about peculiar behaviors of NICs and their drivers.
Some potential problems don't surface until one tests on a workstation with multiple NICs installed. Some of these are superficially simple.
For example, development of the PCASIM NDIS Intermediate driver was pretty far along before we installed an Intel PRO/100+ Dual Port Server Adapter for testing. We had to extensively revise our virtual adapter naming conventions to allow us to answer the simple question:
Which Intel EtherExpress PRO Adapter is which???
Here PCAUSA extends the "Routers Are Cheap These Days..." idea. We actually have multiple private networks per developer so their multi-homed workstations actually have multiple networks to talk to.
We expect that you are already aware of the essential need to archive source code at important milestones during development and product release.
However, at PCAUSA we have found it equally important to make private backups often - perhaps several times a day - during development. The reason for this is that often (in our experience) one will start the day with a working version of a driver and, by the end of the day, have reached an impasse that may not work at all or is too buggy or complex to continue.
One may desperately say:
I wish I could get back to where I was at this morning!!!
Prepare for this. Make frequent informal backups or "snapshots" of work-in-progress.
You can use any technique that you wish to do your private backups. If you are using SourceSafe or another archive tool, create an informal backup project that can be used without too much administration. Simply copying the files to a local subdirectory will also work for this purpose.
Each time you get to a point where you have code that "is working" in some aspect, back it up.
This one just bit me...
My primary development system is a dual-processor PII that has removable boot drives as described above. It has served me well since it was purchased a year and a half ago, and has cheerfully hosted all Windows platforms from Windows 95 Gold through Windows 2000.
When I finally got around to testing USB Ethernet adapters I started with a D-Link DSB 650.
It "worked" with Rawether for Windows with a few minor peculiarities - like it apparently taking a long time to complete a NdisRequest call.
Then I started using it for testing of a product enhancement for Windows Me. That development did not go smoothly.
Although the enhancement worked flawlessly on PCI adapters, there were random crashes when using the D-Link USB adapter. After some additional tests it was clear that the crashes were specifically correlated to whether the D-Link USB adapter was installed.
Getting rather "tired" of the problem, I desperately wanted to point fingers at the D-Link USB adapter and get on with release of the product. That really wasn't acceptable, however.
It finally dawned on me that just because the workstation's USB ports had been there for over a year, that didn't mean that they actually worked correctly.
A quick check with the motherboard vendor revealed that the BIOS revision had gone from 1.5 (in my system) to 3.1. I downloaded and flashed the latest BIOS, and the problem with the D-Link USB adapter is finally history.
The product release is only a month and a half late because of this...
Let this situation be a reminder to occasionally check on BIOS updates for your development workstations. Don't be paranoid, but do consider an outdated BIOS to be a possible (but low-priority) cause of unexplainable problems when using features of a workstation (e.g., USB, FireWire) that haven't successfully been exercised before.
|
PCAUSA Home ·
Privacy Statement ·
Products ·
Ordering ·
Support ·
Utilities ·
Resources
|