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