Page 341 - DCAP103_Principle of operating system

Principles of Operating Systems

Notes At boot time, Windows 2000 is loaded into memory as a collection of files. The main part of
the operating system, consisting of the kernel and executive, is located in the file ntoskrnl.exe.
The HAL is a shared library located in a separate file, hal.dll. The Win32 and graphics device
interface are together in a third file, win32k.sys. Finally, many device drivers are also loaded.
Most of these have extension .sys.

Actually, the ntoskrnl.exe file comes in uniprocessor and multiprocessor versions. Also, there
are versions for the Xeon processor, which can have more than 4 GB of physical memory and
the Pentium, which cannot. Finally, versions can consist of a free build (sold in stores and
preinstalled by computer manufacturers) or a checked build (for debugging purposes). together
there could be eight combinations, although two pairs were combined leaving only six. One of
these is copied to ntoskrnl.exe when the system is installed.
The checked builds are worth a few words. When a new I/O device is installed on a PC, there
is invariably a manufacturer-supplied driver that has to be installed to make it work. Suppose
that an IEEE 1394 card is installed on a computer and appears to work fine. Two weeks later
the system suddenly crashes. To whom does the owner blame? Microsoft?
The bug may indeed be Microsoft’s, but some bugs are actually due to flakey drivers, over
which Microsoft has no control and which are installed in kernel memory and have full access
to all kernel tables as well as the entire hardware. In an attempt to reduce the number of irate
customers on the phone, Microsoft tries to help driver writers debug their code by putting
statements of the form. ASSERT(some condition) throughout the code. These statements make
sanity checks on all parameters to internal kernel procedures (which may be freely called by
drivers) and make many other checks as well. The free builds have ASSERT defined as a macro
that does nothing, removing all the checks. The checked builds have defined it as:
#define ASSERT(a) if (!(a)) error(…)

causing all the checks to appear in the ntoskrnl.exe executable code and be carried out at run
time. While this slows down the system enormously, it helps driver writers debug their drivers
before they ship them to customers. The checked builds also have numerous other debugging
features turned on.

A kernel can be contrasted with a shell, which is the outermost part of an
operating system and a program that interacts with user commands.

11.1.4 Device Drivers

The last part of Figure 11.1 consists of the device drivers. Each device driver can control one or
more I/O devices, but a device driver can also do things not related to a specific device, such as
encrypting a data stream or even just providing access to kernel data structures. Device drivers
are not part of the ntoskrnl.exe binary. The advantage of this approach is that once a driver
has been installed on a system, it is added to a list in the registry and is loaded dynamically
when the system boots. In this way, ntoskrnl.exe is the same for everyone, but every system is
configured precisely for those devices it contains.

There are device drivers for macroscopically visible I/O devices such as disks and printers, but
also for many internal devices and chips that practically no one has ever heard of. In addition,
the file systems are also present as device drivers, as mentioned above. The largest device
driver, the one for Win32, GDI, and video, is shown on the far right of Figure 11.1. It handles

334 LOVELY PROFESSIONAL UNIVERSITY