|
The Early Days
The year is 1981 and the world
is in the midst of a severe re-session. IBM's main frame business has slowed and
the company is losing money. Up until now they had been laughing at the array of
microcomputers on the market: Atari, Commodore, sinclair. Toys really, mostly
used to play computer games.
The problem was, these "toys"
were selling like hot cakes. IBM had to get into that market and get into it
fast. They didn't have time to design and build a computer complete enough to
compete in the market, so they built an "open system". They used commonly
available electronic components and they published every design detail
(including the code), and they even provided plug in slots so that others could
build components for their computer.
And people did provide
components for the IBM PC. They provided video cards, memory expansion cards,
input-output port cards, game port cards, hard disk interface cards, and much
more. How were all these various devices able to interface with the PC's
operating system? That's where a "driver" comes in.
A hardware device is
constructed with various electronic components using various control signals,
but the software interface to the operating system is standardized. A device's
interface to the operating system must follow the interface specification. A
driver is a piece of software that translates the hardware's control signals to
signals that the operating system expects, and translates signals from the
operating system to the hardware's control signals.
When the computer is started
up, it would look in the "system" directory for files with the extension ".drv"
and load them into memory. Specific files like autoexec.bat, config.sys, and
win.ini were used to inform the operating system about drivers. Hardware would
be configured through these files, or through jumpers located on the device
itself.
The driver specification
evolved along with the PC. Today when a PC starts, it executes the program ntdetect.com which queries the
hardware components and builds the registery key
HKEY_LOCAL_MACHINEHARDWARESYSTEMCurrentControlSet. This key exists only in
memory and is created each time the computer boots. If all the drivers are
loaded successfully, a copy of the key is saved as ControlSet00X.
Under the registery key
CurrentControlSet, the subkey "Enum" contains a subkey for each harware device
on the computer. Each device key contains fields for Hardware ID, Driver ID,
Device Parameters, and other configuration data. The 32-bit drivers are files
with the extension ".sys" and can be found in the folder C:/winnt/system32.
Driver Signing
Microsoft has been the brunt of
much criticism because of the poor reliability of the Windows Operating System.
I feel that much of this criticism is justified. On the other hand, as I
described in part 1 of this article, the PC was designed by IBM as an "open"
system. Anyone can sell a hardware device (or software) for the PC. Should
Microsoft be held responsible for the quality from a third-party?
As I described in Part 1 of
this article, the operating system doesn't interface directly to a hardware
device. There is a piece of software called a "driver" that translates the
hardware's control signals to signals that the operating system expects, and
translates signals from operating system to the hardware's control signals.
Obviously, the hardware manufacturer provides the driver.
Because the driver works
between the operating system and the hardware, a bug in the driver can cause a
serious problem. Many of the problems with Windows have come from bugs in
third-party drivers that Microsoft had nothing to do with. For this reason,
Microsoft created a Hardware Quality Lab to test drivers. A hardware
manufacturer can submit their driver for testing, and if it is passes rigorous
compatibility testing, it receives Microsoft's digital signature.
You may have received a message
during the installation of a hardware device warning that the driver was not
signed. Why would a hardware manufacturer fail to have their driver certified by
Microsoft? The computer hardware market is very competitive and the manufacturer
might want to bring a new product to market before thorough testing can be
completed. Or maybe they don't want to or can't afford to pay Microsoft for
certification. The question is, should you click on the "Continue" button to
install the unsigned driver?
In my experience, I have never
been able to trace a problem to an unsigned driver. If it's your home computer
and you performed a back-up recently, go ahead and install the unsigned driver.
If it's a computer on a corporate network, you may want to back-out of the
installation and see if you can locate a signed driver first. Many times a
manufacturer will release a product with an unsigned driver, then later provide
a signed driver as a free download from their website.
If you decide to go ahead and
install an unsigned driver, you can always update the driver later. If your
computer works with the unsigned driver, I would not update the driver. When it
comes to updating drivers (or the computers BIOS) I go by the old saying, "if it
ain't broke don't fix it".
To update a driver, select
Start | Settings | Control Panel and double-click on the "System Properties"
Utility. In the "System Properties" Utility, select the "Hardware" tab and click
on the "Device Manager" button. In the "Device Manager" window, right-click on
the device in the list and select "Properties" in the popup menu. In the
"Properties" dialog box, select the driver tab and click on the "Update
Driver..." button.
In the "Properties" dialog box
driver tab, you may have noticed the "Roll Back Driver" button. If your computer
has problems with the new drive, you can click on the "Roll Back Driver" button
to roll back to the previous the driver. Driver roll back saves only one
previous driver, so if you update a driver, then update it again, the original
driver is gone. If the computer has problems with the new driver, always roll
back to the original driver before trying a different one. That way you'll
always have the original driver to roll back to.
Copyright(C) Bucaro TecHelp.
|
