4.4 User Mode and Kernel Mode

Table 4,5 Kernel Module Imports

Component

Imparts

hal�dll

Nt*.exe, kdcom.dll, pshed.dll

BOOTVID.DLL

Nt*.exe, har.dii

Nt*.exe

haT.dll, pshed.dll, bootvid.dll, kdcom.dll, clfs.sys, ci.dll

Win32k.svs

Nt*.exe, msrpc.sys, watchdog.sys, hai.dll, dxapi.sys

Using dumpb1n.exe, you can glean what sort of services a given binary of¬

fers its kernel-mode brethren. For the sake of keeping Figure 4.6 relatively

simple, I displayed only a limited subset of the Windows API DLLs. This

explains why you'll see files referenced in Table 4.5 that you won't see in

Figure 4.6.

Note: For our purposes, most of the interesting stuff goes on in the executive, and this

will be the kernel-mode component that we set our sights on. The remaining characters

in kernel mode are really just supporting actors in the grand sclieme of things.

User-Mode Components

An environmental subsystem is a set of binaries running in user mode that

allow applications, written to utilize a particular environment/API, to run.

Using the subsystem paradigm, a program built to run under another operat¬

ing system (like OS/2) can be executed on a subsystem without significant

alteration.

Understanding the motivation behind this idea will require a trip down

memory lane. When Windows NT 4.0 was released in 1996, it supported five

different environmental subsystems: the Win32 Subsystem, the Windows

on Windows (WOW) Subsystem, the NT Virtual DOS Machine (NTVDM)

Subsystem, the OS/2 Subsystem, and the POSIX Subsystem. At the time, you

sec, the market had a lot more players, and competition was sdll very real. By

providing a variety of environments, Microsoft was hoping to lure users over

to the NT camp.

The Win32 Subsystem supported applications conforming to the Win32

API, which was an interface used by applications that targeted Windows

95 and Windows NT. The WOW Subsystem provided an environment for

older 16-bit Windows applications that were originally designed to run on

Parti I 141