In Windows NT and Windows 95, 32-bit functions never access hardware directly. In every case, there is a driver or API (application programming interface) that actually communicates with the hardware. Microsoft provides the APIs, or hooks, to make the process easier for the software vendor, and distributes the technical information through the Software Developer's Kit (SDK). With that information, the programmer need only connect to the hook, and Microsoft will do the rest. NT or 95 will then make the procedure call, utilize the system resources, and communicate with the hardware device.
In DOS and 16-bit operating systems, programmers could bypass the operating system and write information directly to the hardware. The hardware would have to be very specific, and different routines would have to be written for each type of hardware.
Windows 95 allows
both types of hardware access and control. Programmers can choose
which type of function they will use. Windows NT does not allow any direct hardware
access because any access may open the door for security challenges and instability.
In Windows NT,
every
16-bit function is translated (or "thunked") into a 32-bit request, and
then used by NT. NT then sends 32-bit code to control access to the device.
The downside of the NT approach is the problem that Windows NT has with some Windows 95 and DOS applications. Certain applications, like fax and backup applications, try to work directly with the hardware in the system. There are a great number of 95 applications that use fax cards and tape drives, and a very small number for Windows NT. Those written for 95 will not work at all in NT.
In order for all the communication to happen between the hardware and the OS,
the Registry needs
to provide the information to the operating system. The Registry
holds, at a minimum, basic settings that allow communication. Some of those settings
are described in Table 12.1.
Table 12.1. Hardware settings controlled by the Registry.
| Setting | Description |
| IRQ (interrupt request) | Alerts the CPU to request CPU intervention |
| I/O port address | Indicates which device is sending information (stored in RAM in first 4KB) |
| RAM address | Where the device's BIOS information is to be stored in system RAM |
| DMA channel | Used to transfer information directly to RAM |
Figure 12.1. Windows 95 hardware settings resolution process.
Windows NT does not
have the same level of Plug and Play that is available in Windows
95. With the exception of PCI devices, all hardware settings on devices must match
the settings in the Registry. If the settings are not the same, the device driver
will not load, and
the device will not work. Figure 12.2 shows the startup process
for hardware and its settings resolution in Windows NT.
The Registry plays a key role in making all the devices work. If the Registry is corrupted, and the settings are not available, the device will not work.
Figure 12.2. Windows NT hardware settings resolution process.
SOLUTIONS: Why doesn't Windows NT support Plug and Play? Windows NT does support Plug and Play, but it is very limited. All devices that use the PCI bus are automatically configured at startup. Characteristically, they use an IRQ in a completely separate range (32-36), and the IRQ, I/O port address, and other settings are set automatically. Once the device is configured, it will normally not change those settings, unless there is a specific change to devices on the PCI bus. Even then, new devices introduced to the bus will normally choose a different setting than that of the cards already present. If there is a change to the setting on the card, Windows NT may not recognize the card, and any devices attached to it will not work. The only time NT will adjust the settings in the Registry is when there is a difference in the number or type of cards on the PCI bus. Although dynamic addressing of devices would be handy, and might reduce setup and configuration challenges, Microsoft engineers sacrificed it for stability. In order to allow dynamic addressing, the driver software would have to have direct access to the hardware. Then, if the driver had a significant problem, it could crash the hardware and bring down the entire system. To protect the stability of the system, Microsoft chose to limit the degree of Plug and Play support.
All the settings and controls for hardware for Windows NT are in HKEY_LOCAL_MACHINE. There are several subkeys that hold the information required by Windows NT for operations.
NOTE: Windows NT reads BIOS information and other information from devices in the system only one time. After startup, all device control is done through the drivers and the Registry. NT never makes a BIOS call again.
Figure 12.3 shows a cascading view of HKEY_LOCAL_MACHINE with DESCRIPTION, DEVICEMAP, and RESOURCEMAP open. These three subkeys hold the settings and control information for the hardware. DESCRIPTION supplies data to NT about the system board, the processors, and the bus. DEVICEMAP either directly holds data and settings about the devices connected to the bus or supplies a description and location of a driver. RESOURCEMAP holds settings for many of the drivers for the devices.
Seldom would you ever make settings here. Instead, you would make all the settings in Control Panel, and then Control Panel would store them in these keys for use by Windows NT, and for viewing by Windows NT Diagnostics.
Figure 12.3. HKEY_LOCAL_MACHINE in the NT Registry controls all hardware.
All the settings and controls for hardware in
Windows 95 are in HKEY_LOCAL_MACHINE.
The Enum key holds information on every BIOS-supported device that is used
in the system, as shown in Figure 12.4.
Figure
12.4.
The HKEY_LOCAL_MACHINE\Enum key in Windows
95.
Non-BIOS-supported devices have their own key under HKEY_LOCAL_MACHINE that
allows for setup and
support. There are three types of settings in the Registry for
devices:
When Plug and Play sets the configuration, it is stored in HKEY_DYN_DATA and then copied to HKEY_LOCAL_MACHINE as a backup. In HKEY_LOCAL_MACHINE, the configuration information is held in HKEY_LOCAL_MACHINE\Enum\Root for most devices. Figure 12.5 shows the binary Settings value, indicating that it has been set through Plug and Play.
Figure 12.5. Binary Settings information for COM3.
The SCSI adapter in my system has a forced configuration, ensuring that the configuration
used in Device Manager is the same
as the hardware configuration. Figure 12.6 shows
a ForcedConfig setting that cannot be changed at startup.
Figure 12.6. Binary ForcedConfig information for the Adaptec 1542C SCSI Host Adapter.
My sound card uses a driver in CONFIG.SYS for its initial support. The entry
in the Registry, BootConfig, ensures that
the system will point to the 16-bit
driver for its configuration settings, as shown in Figure 12.7. It actually loads
a 32-bit driver after Windows 95 starts, and uses it for all the rest of the sound
during the session.
Figure 12.7. Binary BootConfig information for the SoundBlaster Sound Card.
With all the settings and configuration information in the Registry, hardware in Windows 95 and NT can be controlled easily. The Registry also contains the location of each of the drivers used for control, and any information specific to the use of the hardware by the operating system.
© Copyright, Macmillan Computer Publishing. All rights reserved.
