© 1997 The McGraw-Hill Companies, Inc. All rights reserved. Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Chapter 1

The Windows NT Registry

This section serves as an introduction to the configuration database of pointers known as the Registry. This section examines the internal structure of the registry beginning with the major partitions of the registry known as Hive Keys (HKEYS). A further examination of the registry includes the different keys and subkeys available. The purpose of these keys is to ultimately order the thousands of registry values into a hierarchical order.

Understanding the Registry

Windows NT and the Win32 API uses a system component called the Registry to provide a database that stores data about the system configuration in a hierarchical form. The information stored in the Registry is comparable to the information stored in initialization files in Windows 3.1 or Windows for Workgroups 3.11. For native NT applications, the Registry takes the place of .INI files, storing all configuration information in its database.

Each registry key is similar to a bracketed heading in an .INI file. Changes made to the system configuration that are made through administrative tools such as the Control Panel and User Manager are applied to the Registry database.

Some important Registry characteristics are listed below:

Registry keys can contain subkeys while .INI files cannot contain nested headings.

• Registry values can also be executable code in addition to strings.
• The Registry is organized as a set of four subtrees that contain per-computer and per-user databases.
• Per-computer information is about its hardware and software.
• Per-user information includes user profiles-e.g., desktop settings, software preferences, printer and network settings.
• Each key contains data items called value entries and/or subkeys.
• Key names begin with HKEY_ and are handles used to uniquely identify resources for application access.
• Keys are analogous to directories.
• Values are analogous to files.

Registry Hives

The Four Registry Keys are explained below:

HKEY_LOCAL_MACHINE

HKEY_LOCAL_MACHINE contains information such as bus type, system memory, device drivers, and startup control data.

Below is an illustration of the HKEY_LOCAL_MACHINE window in the Registry Editor:

Figure 1-1: Using the Registry Editor to view HKEY_LOCAL_MACHINE
HKEY_CURRENT_USER

HKEY_CURRENT_USER contains the user profile for the user who is currently logged in. It includes environment variables, personal program groups, desktop settings, network connections, printers, and application preferences. The following are the default subkeys for HKEY_CURRENT_USER:

• \Console - contains subkeys that specify the window size and options for the Windows NT command prompt.
• \Control Panel - contains the subkeys that hold the configuration information for the Control Panel applets.
• \Environment - contains entries for the current user's environment variables.
• \Keyboard Layout - contains an entry for the current active keyboard layout.
• \Printers - contains the current default printer name
• \Program Groups - contains subkeys with the names and settings of the current user's program groups.
• \Software - contains subkeys that describe the user configurable settings of any installed software.

The entries under HKEY_CURRENT_USER are mapped directly to HKEY_USERS\<SID of currently logged on user> . Therefore, if an entry is added under one of these, it will automatically be added to the other. This ensures that both keys contain identical entries.

Below is an illustration of the HKEY_CURRENT_USER window in the Registry Editor:

Figure 1-2: Using the Registry Editor to view HKEY_CURRENT_USER HKEY_CLASSES_ROOT

The HKEY_CLASSES_ROOT window is an alias subkey of HKEY_LOCAL_MACHINE\Software. It serves as an alias to HKEY_LOCAL_MACHINE\Software\Classes. The information stored here is used to open the right application when a file is opened from File Manager (file association) and for Object Linking & Embedding (OLE).

Figure 1-3: The Registry Editor view of HKEY_CLASSES_ROOT HKEY_USERS

The HKEY_USERS window is the root of all user profiles on the computer. HKEY_CURRENT_USER is a subkey of HKEY_USERS. This predefined handle contains the default system profile, and the profile of the currently logged on user. HKEY_USERS\<SID for currently logged on user> contains the same information as HKEY_CURRENT_USER, and as noted above they are mapped to each other. Currently, HKEY_USERS has the following two subkeys, each of which have the same subkeys as HKEY_CURRENT_USER:

HKEY_USERS\.DEFAULT is the profile that is used while the Windows NT CTRL+ALT+DEL logon message is displayed. Therefore, changing the color scheme under this key will change the color scheme used for the logon screens. It will not be necessary to modify the Registry for a screen saver to be enabled when the CTRL+ALT+DEL logon message is on the screen. By default, the logon screen will use the blank screen saver.

Figure 1-4:HKEY_USERS as seen through the Registry Editor HKEY_CURRENT_CONFIG

The HKEY_CURRENT_CONFIG window contains information about the hardware profile used by the local computer at system startup.

Figure 1-5: The Registry Editor view of HKEY_CURRENT_CONFIG.

The HKEY_CURRENT_CONFIG subtree, new to Windows NT 4.0, contains configuration data for the hardware profile currently in use on the computer. This subtree is actually an alias pointing to

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Hardware Profiles\Current. 

The contents of the Hardware Profiles\Current subkey appear in this subtree.

HKEY_CURRENT_CONFIG was added to the Windows NT 4.0 Registry to be compatible with the HKEY_CURRENT_CONFIG subtree in the Windows 95 Registry. Because it was added to Windows NT, applications that use the HKEY_CURRENT_CONFIG subtree can run on both Windows 95 and Windows NT. HKEY_CURRENT_CONFIG contains data that describes the current hardware profile.

A hardware profile is a set of changes to the standard configuration of devices and services (including drivers and Win32 services) loaded by Windows NT when the system starts. For example, a hardware profile can include an instruction to disable (that is, not load) a driver, or an instruction to Windows NT to not connect an undocked laptop computer to the network. Because of the instructions in this subkey, users can modify the service configuration for a particular use while preserving the standard configuration unchanged for more general uses.

The current hardware profile is the one used to start Windows NT. Users can create multiple hardware profiles and, when Windows NT starts, select from them the settings they want. To create hardware profiles, use the System, Services, and Device options in Control Panel. For more information on creating hardware profiles, double-click System in Control Panel, click the Hardware Profiles tab and open Help.

In the Registry, hardware profiles are stored in the Hardware Profiles subkey in all control sets under HKEY_LOCAL_MACHINE\System. The current hardware profile appears in the Current subkey under each Hardware Profiles subkey, and the subkey under CurrentControlSet appears in HKEY_CURRENT_CONFIG.

The data in HKEY_CURRENT_CONFIG consists of profile-specific modifications to the standard service configuration. This standard configuration is defined by data stored throughout the Software and System subkeys of HKEY_LOCAL_MACHINE. Hence, the structure of HKEY_CURRENT_CONFIG is modeled on the structure of HKEY_LOCAL_MACHINE and can be thought of as a limited or condensed version of HKEY_LOCAL_MACHINE.

When the current hardware profile specifies a change to a value entry in the Software or System subkeys of HKEY_LOCAL_MACHINE, the original value in the Software or System subkey is not changed; instead that change is stored in the analogous subkey of HKEY_CURRENT_CONFIG.

Registry Value Types

Value types (or classes) fall into four categories, each having its own special editor:

REG_BINARY

The REG_BINARY prefix identifies a value entry as binary. If a value entry is preceded by the prefix REG_BINARY, the value entry is written as binary data, and you must use the Binary Editor to edit this value entry. However, if you want to do so, you can use the Binary Editor in Registry Editor to edit any value entry, regardless of the format in which the entry is written.

Figure 1-6: The Binary Editor dialog box in the Registry Editor

You have your choice of entering the format in which you want your data to appear:

The Binary option will represent your data as binary numbers.

The Hex option will represent your data as hexadecimal numbers.

REG_SZ

The REG_SZ prefix identifies a value entry as a data string. A String is a sequence of characters usually representing human readable text. An Expandable String usually consists of human readable text also, but contains a variable that will be replaced by something else when it is called by an application. For example, in the value entry %SystemRoot%\system32\bootok.exe, %SystemRoot% is the expandable portion of the variable, and will be replaced by the actual location of the directory that contains the Windows NT system files. If a value entry in Registry Editor has a REG_SZ or a REG_EXPAND_SZ prefix, you can edit the value entry by using the String Editor.

Figure 1-7: The String Editor windows in the Registry Editor

REG_DWORD

The REG_DWORD prefix identifies a value entry as a DWORD entry. DWORD refers to data that is represented by a number that is 4 bytes long. If a value entry contains the prefix REG_DWORD, the entry is written in the DWORD format. To edit this data, you need to use the DWORD Editor.

Figure 1-8: The DWORD Editor window in the Registry Editor

When you assign data for REG_DWORD, you have three numerical representation options that appears in the Radix box.

The Binary option will display your data as a binary (base-2) number.

The Decimal option will display your data as a decimal (base-10) number.

The Hexadecimal option will display your data as a hexadecimal (base-16) number.

REG_MULTI_SZ

The REG_MULTI_SZ prefix identifies a value entry as a multiple string. Invokes the Multi String Editor, in which you can edit multiple strings of data. If the value entry selected in the right pane of the Registry Editor window is designated by the value type REG_MULTI_SZ, you need only to double-click the value entry to invoke the String Editor.

REG_EXPAND_SZ

The REG_EXPAND_SZ prefix indicates that a value entry is an expandable string.

Table 1-1: Registry Value Types:

Value Type	Description
REG_NONE	This has no value type or it is unknown due to encryption.
REG_SZ	A Unicode String (CHAR or Null-Terminated)
REG_EXPAND_SZ	An Expandable String that can have embedded environment variables.
REG_BINARY	Binary Data edited/displayed in bit or binary form.
REG_DWORD	A 32-bit Number (Word, not byte) that can be expressed in HEX, OCTAL, or decimal data.
REG_DWORD_BIG_ENDIAN	32-bit number, high byte first.
REG_LINK	This is a Symbolic Link in Unicode Format
REG_MULTI_SZ	This is an array of Strings
REG_RESOURCE_LIST	Hardware Resource Lists found only in the \HARDWARE subkey of HKEY_LOCAL_MACHINE
REG_FULL_RESOURCE_DESCRIPTOR	Hardware Resource Description found only in the \HARDWARE subkey of HKEY_LOCAL_MACHINE
REG_RESOURCE_REQUIREMENTS_LIST	Resource Requirements

The Evolution from .INI files

The Registry has addressed many design issues relating to configuration. It eliminates many of the burdens placed on system administrators and users during software and hardware installations. Earlier implementations of Windows Operating Systems used .INI files to hold system configuration. This information included software environment parameters, desktop parameters, and device driver and hardware configuration. Many problems arose from this method which would later be fixed by the registry.

Registry Configuration Options not previously Available in .INI files include:

Standardization of Hardware Configuration

Multiple Levels of Configuration

User-Specific Configuration

Multiple Data Types

Windows 3.1 *.INI entries in the Registry

Entries that deal with .INI file correlation are found in the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping

These are the keys for each of the standard Windows 3.x *.INI files. Under each of the keys for the *.INI files are entries for each of the standard headings in these files. These heading entries each contain a string that points to the location in the Windows NT Registry where the items that were under these headings in Windows 3.x can be found. Each of these entries begin with either SYS or USR. SYS can be found under HKEY_LOCAL_MACHINE\SOFTWARE while USR can be found under HKEY_CURRENT_USER. Based on this, to find the Patterns entry that was in the CONTROL.INI under Windows 3.x, look in the Registry under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\control.ini

In the Registry, this key has a Value for Patterns of: USR:Contol Panel\Patterns. This translates into a location of:HKEY_CURRENT_USER\Control Panel\Patterns, for determining what the current, and possible, patterns are on the system.

It is important to be aware that many entries can be found in more than one location within the Registry. However, when there are entries in multiple locations, the keys are "mapped" to one another. This means that when one key is changed, any keys "mapped" to it will automatically be updated as well, and vice versa.

Registry File Locations

Physically, the Registry exists as a set of files, with the Registry being divided into sections referred to as hives. When Windows NT boots, the majority of the registry is constructed from these files. All of what is used at bootup builds HKEY_LOCAL_MACHINE. The various profiles will control the rest of the registry construction. The following table shows the different Registry hives, and their corresponding files.

Table 1-2: Major Registry Hives and their origins.

Hive Physical File

HKEY_LOCAL_MACHINE\SYSTEM \%systemroot%\system32\config\SYSTEM

HKEY_LOCAL_MACHINE\SAM \%systemroot%\system32\config\SAM

HKEY_LOCAL_MACHINE\SECURITY \%systemroot%\system32\config\SECURITY

HKEY_LOCAL_MACHINE\SOFTWARE \%systemroot%\system32\config\SOFTWARE

HKEY_USERS\.DEFAULT \%systemroot%\profiles\Default User\ntuser.dat

HKEY_USERS\<Admin's SID> \%systemroot%\profiles\Administrator\ntuser.dat

HKEY_USERS\<User's SID> \%systemroot%\profiles\%user%\ntuser.dat

The above table shows the hives that are created when Windows NT is first installed. Each time a new user logs onto a system, additional profiles are created for each user, therefore additional HKEY_USERS hives will be created for that user. These files are all located in \%systemroot%\profiles\username. The files in this subdirectory with the extensions of .ALT and .LOG are backups of the hive files. Should the system fail to load because the system hive has a bad sector, Windows NT will automatically switch to the SYSTEM.ALT.

The information regarding the hive files and what they map to, can also be found in the Registry under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
\hivelist

Subtree Reference

HKEY_LOCAL_MACHINE\SECURITY

HKEY_LOCAL_MACHINE\SECURITY

This key holds all of the security information for the local computer. By default, it is NOT possible to modify any of the \SECURITY subkeys, even if logged on as Administrator. Modifying the default registry key permissions can change this. However, it is not recommended to do this unless you are manually saving these subtree for backup purposes. Only in the utmost rarest of circumstances an administrator will need to manually edit this subkey.

HKEY_LOCAL_MACHINE\SOFTWARE

This key contains the per-machine software data. In other words, this key contains the configuration information about the software installed on the local system. This information applies to all users of the system and is written to the Registry when a piece of software is installed on the system. The software then can use this key to store environment parameters. By querying this key, it is possible to determine what software is installed on a system. Microsoft even prescribes a convention for how information should be stored under this key:

\SOFTWARE\<Company Name>\<Product Name>\<Version Number>

For example, when you install Microsoft Word 7.0, Word would create the following:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Word\7.0

Preferences and other user iInformation regarding the configuration of the application is stored on a per-user basis the user's profile which is constructed as:

HKEY_CURRENT_USER\Software\<Company Name>\<Product Name>\<Version Number>

This information is written to the Registry at application runtime, since the user who installed the software may not necessarily be the user of the application.

HKEY_LOCAL_MACHINE\SOFTWARE\Description

This subkey also contains description information about the installed applications, as mentioned in the preceding paragraph.

HKEY_LOCAL_MACHINE\SOFTWARE\Program Groups

The Program Groups subkey under HKEY_LOCAL_MACHINE\Software is redefined in Windows NT 4.0. In previous versions of Windows NT, it contained a list of the program groups used by all users of the local computer. In Windows NT 4.0, program groups have been replaced by the Windows NT Explorer directory structure. Now, this subkey is used only to record-as a yes/no, 0x1/0x0 value-whether all former program groups have been converted to the new directory structure.

The ConvertedToLinks value entry indicates whether the program groups were converted. A value of 1 (0x1) indicates that the conversion is complete.

When Windows NT 4.0 is installed on a computer that has never run Windows NT, there are no subkeys under the Program Groups subkey. However, upgraded versions can still contain binary data for common program groups that appear as Program Groups subkeys.

HKEY_LOCAL_MACHINE\Software\Classes

HKEY_LOCAL_MACHINE\Software\Classes contains data to associate applications with file types (by filename extension). It also includes Registry information associated with COM objects. The data under the Classes subkey is also reflected in HKEY_CLASSES_ROOT.

The Classes subkey contains two types of subkeys:

Filename-extension subkeys: These associate applications with file types by their filename extension. These subkeys contain information you add by using the File Types tab in Windows NT Explorer, information that is added during installation of Windows-based applications, and information about applications installed by Windows NT.

Figure 1-9: Example of filename extensions

Class-definition subkeys: Class-definition subkeys contain Registry information associated with Component Object Model (COM) objects. The data in these subkeys specifies the shell and OLE (COM) properties of an object. If an application supports dynamic data exchange (DDE), the Shell subkey can contain Open and Print subkeys that define DDE commands for opening and printing files, similar to the information stored in the Registry database under Windows 3.x..

Figure 1-10: Example of Class Definitions.

HKEY_LOCAL_MACHINE\Software\Microsoft

The HKEY_LOCAL_MACHINE\Software\Microsoft subkey contains configuration settings for all of the Microsoft software installed on the computer.

The Windows NT\CurrentVersion subkey is of particular interest. This subkey contains information about software that supports services built into Windows NT, as well as data about the version and type of the current release (multiprocessor versus uniprocessor). For example, it is possible to run a Windows NT uniprocessor kernel on a multiprocessor computer, but you do not get any multiprocessor benefits by doing so.

HKEY_LOCAL_MACHINE\Software\Secure

The Secure subkey provides a convenient place for applications to store configuration information that should be changed only by an administrator.

HKEY_LOCAL_MACHINE\Software\Windows 3.1 Migration Status

The Windows 3.1 Migration Status subkey contains data if the computer has been upgraded from Windows 3.x to Windows NT 4.0. The values in this subkey indicate whether upgradable parameters in Windows 3.x .INI and REG.DAT files have migrated successfully to the Windows NT 4.0 format. If this subkey is deleted, Windows NT will again attempt to migrate the files when the system is restarted. There is also a Windows 3.1 Migration Status subkey under HKEY_CURRENT_USER. It tracks the migration of Program Group (.GRP) files to the Windows NT Explorer format.

HKEY_LOCAL_MACHINE\HARDWARE

HKEY_LOCAL_MACHINE\HARDWARE

This key is essentially the installed hardware database and represents the physical configuration of the machine. This includes such data as the processor type, bus type, video adapter type, which interrupts are being used, etc. This data is volatile and is re-computed each time the system is booted.

HKEY_LOCAL_MACHINE\HARDWARE\Description

This subkey refers to the root of the hardware database built by the operating system loader during the boot process. On ARC compliant systems, this is a copy of the ARC configuration database which is extracted from the system's firmware. On x86 based systems, it is a subkey in the same format as the ARC tree, but it contains whatever data NT DETECT.COM could recognize.

When Windows NT is selected from the OSLOADER menu, NTDETECT.COM will scan hardware and abstract values that will then be placed into the HARDWARE subtree. The Windows NT Hardware Abstraction Layer (HAL.DLL) will then use these parameters for hardware access.

Each hardware component that is detected has a set of values associated with it that store configuration data for that component:

Component Information: contains binary data that identifies among other things, version information.

Identifier: contains the identifier of a component, if specified.

Configuration Data: contains the component specific information, such as I/O port addresses, IRQ number, etc. This entry will not be present if the data is not available for a particular component.

HKEY_LOCAL_MACHINE\HARDWARE\Devicemap

This subkey contains additional subkeys that list the device drivers which need to communicate the names of the device objects they have created, along with certain properties of those device objects to other device drivers, and to user mode code. For example, video drivers need to communicate to the Windows NT USER mode subsystems which type of video hardware is associated with which device object, and what user-mode display DLL should be bound to it. The \Devicemap subkey offers a solution to this problem. \Devicemap contains the device class specific data used by user-mode software that needs to communicate with the device.

HKEY_LOCAL_MACHINE\HARDWARE\Resourcemap

This key is used to track which hardware resources are in use, and by which drivers. The data stored under this key is volatile and is therefore recreated each time the system is booted. All device drivers are expected to report their use of I/O ports, memory addresses, interrupt vectors, and statically allocated DMA channels. This allows Windows NT to detect and report conflicts, in order to guide the installation and configuration of new devices and drivers.

HKEY_LOCAL_MACHINE\SAM

This key contains the Security Account Manager database, which contains user and group account information for the local system if it is a Windows NT system. On the other hand, if the system is using Windows NT Advanced Server, this key contains information for the domain. Currently, this key is mapped to HKEY_LOCAL_MACHINE\SECURITY\SAM.

HKEY_LOCAL_MACHINE\SYSTEM

The most important section of the Registry for the boot process is the HKEY_LOCAL_MACHINE\SYSTEM section. The data stored under this key is organized into what are called control sets.

Control Sets

A control set can be thought of simply as an instance of system parameters. Under HKEY_LOCAL_MACHINE\SYSTEM there will be four ControlSets:

HKEY_LOCAL_MACHINE\SYSTEM\Clone

This is a volatile copy of the ControlSet the system booted from (CurrentControlSet). This key is made during the Kernel Initialization phase (discussed in detail later in this module) of the boot sequence and is used by the Service Controller (SCREG.EXE).

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001

This is the primary ControlSet and is used, by default, to boot Windows NT from.

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002

This is a backup ControlSet that can be used in the case of ...\ControlSet001 failing to boot the system.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet

This is the ControlSet that Windows NT is booting from. Typically it will be mapped to HKEY_LOCAL_MACHINE\SYSTEM\ControlSet0001.

Each of these ControlSets consists of two subkeys: \Control and \Services.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control

This subkey holds all of the miscellaneous information necessary to boot Windows NT, such as paging file size, location, etc.

HKEY_LOCAL_MACHINE\System\Control\ServiceGroupOrder

This subkey contains a value called "list", which is a list of groups in the order in which they are to be loaded. For example, we have to load the disk driver before we can load the file system

HKEY_LOCAL_MACHINE\System\Control\GroupOrderList

This subkey contains one value entry per load Group specified, each of which list the Tag values (discussed more below) in the order they are to be loaded.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Select

The Select subkey contains the following named values:

Value Name:Current
Data Type: REG_DWORD
Range: 0xN, where N identifies a control set

This registry key identifies the control set from which the CurrentControlSet subkey is derived. If this value is 0x1, for example, the subkey producing the CurrentControlSet is ControlSet001.

Value Name: Default
Data Type: REG_DWORD
Range: 0xN, where N identifies a control set

Identifies the default control set. If this value is 0x1, for example, the default control set is ControlSet001.

Value name: Failed
Data Type: REG_DWORD 
Range: 0xN, where N identifies a control set

Identifies the control set number of the control set that was last rejected and replaced with a LastKnownGood control set.

Value Name: LastKnownGood
Data Type: REG_DWORD
Range: 0xN, where N identifies a control set

Identifies the last control set that successfully started the system. If this value is 0x1, for example, the last control set known to be good is ControlSet001.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control

The Control subkey itself can contain the following named values:

Value name: Current User
Data Type: REG_SZ
Range: Username

Specifies the user name for the currently logged-on user.

Value Name: RegistrySizeLimit
Data Type: REG_DWORD
Range:	0  -or-  Megabytes: 4 - 0xFFFFFFFF  (Actual range: 4MB - 80% of paged pool)
Default: 	25% of the size of the paged pool  

Establishes the maximum amount of paged pool space (and disk paging file space) that can be consumed by Registry data from all applications. (It does not allocate space in the paged pool, nor does it assure that the space will be available if needed.) If the value of this entry is 0, the system adjusts the RegistrySizeLimit dynamically based on the size of the paged pool.. If both RegistrySizeLimit and PagedPoolSize are set to 0, PagedPoolSize is set approximately equal to the amount of physical random access memory on the computer, and RegistrySizeLimit is set to approximately 25% of PagedPoolSize. If the value of this entry is 0xFFFFFFFF, the system sets RegistrySizeLimit to 80% of the size of the paged pool.

Value Name: SystemStartOptions
Data Type: REG_SZ 
Range: String

Contains the text of system arguments passed to the system by the firmware in RISC systems or by Boot.Ini in Intel-based computers. These values can be used to determine whether the debugger is enabled, the options set for ports and speed, and so on. For example, the following value could be defined for SystemStartOptions:

c:\winnt="WindowsNT" /DebugPort=com1 /DebugBaudRate=56000

In this example, "WindowsNT" in the first part of the string indicates the Systemroot value specified under the WindowsNT\CurrentVersion subkey in the Software area of the Registry. The remaining portion of this string is interpreted by the system to define the COM port and baud rate for debugging.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BootVerificationProgram

The BootVerificationProgram key is used to update the last known good configuration during system startup. This entry describes a program that will be called by the service controller to establish the last known good configuration.

The BootVerificationProgram Key can have the following named values:

Value Name: ImagePath
Data Type: REG_SZ or REG_EXPAND_SZ     
Range: Filename
Default: (no entry)

Specifies the filename for a startup verification program.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

This subkey contains all of the kernel device drivers, file system drivers, and Win32 service drivers that can be loaded, as well as if and when they are to be loaded. These entries control the behavior of the service:

Value entries identify either a service or a device driver with the following values:

Type: This parameter is a DWORD value and can have one of the following settings:

0x1: Kernel drivers
0x2: File System drivers
0x4: Adapters
0x10: Win32 Services (that do NOT share processes)
0x20: Win32 Services (that do share processes)
Subkeys with a Type of 0x4 (Adapter) contain a set of arguments for a piece of hardware.

Start: This parameter can have one of the following settings:

0: Boot - Kernel load
0x1: System - Kernel initialization
0x2: Auto - Win32 subsystem start
0x3: Demand - can be loaded by user
0x4: Disabled - never loaded

ErrorControl: This value determines what happens if the driver being loaded, does not load or initialize properly. There are three different ErrorControl levels:

This parameter can have one of the following settings:

0x1 - "Normal". If this occurs, the boot process should ignore the error and proceed.

0x2 - "Severe". If the current boot is not based on the LastKnownGood, the boot process should fail and restart using the LastKnownGood. If the boot process is using the LastKnownGood, the error should be ignored and the boot process should continue.

0x3 - "Critical". A "critical" error is very much like a "severe", in that it switches to the LastKnownGood if not using it. However, if the LastKnownGood is being used, the boot process will fail and an error message will be displayed.

Group: Group values allow services to be loaded in an order related to the type of service that they are.

Tag: This value specifies an explicit load order for the services, within a group.

ImagePath: This value entry specifies the items path name. The default for a driver is <winnt root>\System32 \Drivers\<drivername>.SYS and for a service is <winnt root>\System32\<servicename>.EXE. This entry is ignored for items of the adapters type.

ObjectName: This value entry specifies an object name. If the service type is a Win32 Service, then this is the account name the service will use to log itself on when the service is run. If the service type is Kernel or file system driver, this name is the Windows NT driver object name, which the I/O Manager uses to load the device driver. The default for this key is <subkeyname>.

DependOnService and DependOnGroup value: This value entry specifies zero or more service value entries (DependOnService) or group names (DependOnGroup), the default being empty. Dependencies all subkeys to be loaded in an order related to other particular subkeys they are closely associated with. For example, the NetBEUI transport depends on an NDIS driver being loaded. That is, in order for the NetBEUI protocol stack to load successfully, an NDIS network card driver must have first been loaded.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\<ServiceName>\Parameters

These value entries contain any arbitrary data the driver writer wants to store

HKEY_LOCAL_MACHINE\SYSTEM\Select

Under this subkey, there are four entries that tell the boot process which ControlSet of drivers and services should be loaded.

The four entries are:

Current: This is the value of the ControlSet that Windows NT is currently using.

Default: Unless told otherwise, NTOSKRNL.EXE uses the ControlSet pointed to by the Default value.

LastKnownGood: This is the value of the ControlSet that last successfully booted Windows NT.

Failed: This is the value of the last ControlSet that was unable to boot Windows NT. This value will be 0 (zero) if Windows NT has never failed during the boot sequence.

HKEY_LOCAL_MACHINE\SYSTEM\Setup

This subkey contains information used by the Windows NT Setup program.

Subkeys of HKEY_LOCAL_MACHINE\System\CurrentControlSet
\Control for All Control Sets

BootVerificationProgram: A value that can be set to define a nonstandard mechanism to declare system startup as "good."

ComputerName: The names of the default and active computers stored in two subkeys, ComputerName and ActiveComputerName. To set the computer name, use the Network option in Control Panel.

GroupOrderList: Specifies the order in which to load services for all groups that have one, used in combination with Tags. ServiceGroupOrder specifies the order for loading groups.

ServiceGroupOrder: Specifies the order in which to load various groups of services. Using the Tags and GroupOrderList entries specifies the order within groups.

HiveList: The location of the files that contain Registry information. This value should be maintained only by the system.

Keyboard Layout: The DLLs for the keyboard language used as the default layout, plus a subkey named DosKeybCodes that lists the other available keyboard layouts. To set keyboard layout, use the Input Locales tab under the Keyboard option in Control Panel.

Lsa: The authentication package for the local security authority. This value should be maintained only by the system-errors can prevent anyone from being able to log on to the computer.

NetworkProvider: Can contain two subkeys, Active and Order, that specify the network provider and the order in which to load providers. Control settings for network providers by using the Network option in Control Panel.

Nls: Information on national language support in three subkeys: CodePage, Language, and OEMLocale. Set preferences about language and locale in Windows NT by using the Regional Settings option in Control Panel.

Print: Information about the current printers and printing environment contained in several subkeys:

Environments - which contains subkeys defining drivers and print processors for system environments such as Windows NT on Digital Alpha, Windows NT on MIPS Rx4000, and Windows NT on Intel-based computers.

Monitors - which can contain subkeys with data for specific network printing monitors.

Printers, which can contain subkeys describing printer parameters for each installed printer.

Providers, which can contain subkeys describing DLLs for network print services. To change printing parameters, click the Start button, point to Settings, then point to the Printers folder.

PriorityControl: The Win32 priority separation. Set this value only by using the System option in Control Panel.

ProductOptions: The product type, such as Windows NT. These values should initially be maintained only by the system. We will discuss controversy revolving this and other registry entries a little bit later in the book.

Session Manager: Global variables used by Session Manager and these subkeys:

DOSDevices - which defines the MS-DOS devices AUX, MAILSLOT, NUL, PIPE, PRN, and UNC.

Environment - which defines the ComSpec, Path, Os2LibPath, and WinDir variables. To set user environment variables, in Control Panel double-click System. To change or add to the computer's default path, or add default system environment variables, change the values in this subkey.

FileRename - Operations, which is used during startup to rename certain files so that they can be replaced. These values should be maintained only by the system.

KnownDLLs - which defines the directories and filenames for the Session Manager DLLs. These values should be maintained only by the system.

MemoryManagement - which defines paging options. Define the paging file by using the System option in Control Panel.

SubSystems - which defines information for the subsystems installed on the system.

HKEY_CURRENT_CONFIG

The current hardware profile in the CurrentControlSet subkey also appears in HKEY_CURRENT_CONFIG.

Enum:

The Enum subkey contains hardware configuration data for devices and drivers loaded by Windows NT.

Hardware Profiles:

The Hardware Profiles subkey contains configuration data for drivers and devices specific to a hardware profile. Users can create multiple hardware profiles for each control set. Data appears under the Hardware Profiles subkey only when it differs from the standard settings for drivers and devices.

System Environment Variables

System environment variables are used by Windows NT to find programs, allocate memory, and control program behavior. The System environment variables are defined by Windows NT, and cannot be changed by the user, unless the Registry is modified.

The system environment variables are found under:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
Session Manager\Environment

NOTE: User Environment Variables can be edited in the System dialog under the System Control Panel. For example, to change the location that the temp variable points to:

1. Click on the temp variable line in the User Environment Variables box.

2. Enter a new value and click the Set button.

Dr. Watson

The Windows NT retail product will include Dr. Watson, DRWTSN32.EXE, also referred to as the Windows NT User Application Debugger, which is similar in functionality to the Windows 3.1 Dr. Watson utility.

Under Windows NT, Dr. Watson is configured to automatically catch any Win32 application errors and generate a log file containing fault information about the offending application. The following data is generated in the Dr. Watson log file:

1. Exception information, such as exception number and name.

2. System information, such as machine name, user name, os version, etc.

3. Task list.

4. A state dump for each thread, including a register dump, disassembly, stack walk, symbol table.

Enabling/Disabling Dr. Watson

By default, Dr. Watson will be enabled when Windows NT is installed. To disable Dr. Watson, the following Registry value must be changed from a 1 to a 0 (zero):

\HKEY_LOCAL_MACHINE\SOFTWARE \Microsoft\Windows NT\CurrentVersion\AeDebug

There is an entry called "Auto" that corresponds to how Dr. Watson will startup.

To enable Dr. Watson, change the above "Auto" value from 0 (zero) to 1. This will then launch whatever debugger, or application, is under the Debugger registry value. For Dr. Watson, the Debugger value should contain:

	drwtsn32 -p %ld -e %ld -g

This value can be replaced with a debugger contained within whatever development kit

Configuring Dr. Watson

To configure Dr. Watson, start DRWTSN32.EXE from the command line or a Program Manager icon and use the Dr. Watson user interface for configuration purposes.

All of the Dr. Watson configuration information is stored in the Registry under:

\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DrWatson

Registry Size and Construction

Figure 1-11: How the Registry is constructed

Registry Information

The Registry data is collected from the following sources:

· The Windows NT Setup program.

· The Windows NT x86 hardware detection program (NTDETECT.COM), or on ARC compliant systems, the POST routine.

· Hardware, Software, and their installation software.

· The Windows NT applets.

The Windows NT Registry is designed to hold all the configuration information for Windows NT and any installed applications. However, an artificial limit of 1 megabyte is imposed on the amount of data that can be stored in the data field of a Value entry. If more than 1 megabyte of data needs to be stored, it is recommended that the data be stored in a separate file and a Registry entry created that points to the file. Because the Registry is designed to hold small objects, this is an artificial limitation that was imposed to prevent Registry abuse.

The Win32 API

Win32 is the native subsystem of Windows NT. It is an adaptation of the Win16 subsystem. Although it is a proprietary subsystem, Win32 is likely to become widely used, thereby negating one of the major problems of a proprietary system. Other subsystem calls within NT are converted to Win32 services.

The Win32 API is found on three platforms - Win32s, Windows NT, and Windows '95. To developers, it is the 32-bit version of the Win16 API: the Application Programming Interface which has been used for writing windows programs since version 1.0. It is the combination of data types, definition and functions which C programmers include as a set of header files. Most of the functions are implemented in DLLs, to which applications link at run time.

The core API divides into three sections:

• KERNEL: All the low level kernel services
• GDI: Graphics Device Inteface: drawing and printing
• USER: User Interface controls, windows and messaging services

Each is pretty much built on top of the other. In Windows 95 the services are provided by three DLLS -USER32, KERNEL32 and GDI32, which either implement the calls or pass them down to their 16 bit predecessors. In Windows NT many of the services are implemented in Kernel Mode and various forms of inter-process communication are used to manage this.

Differences from the Win16 API

Initial Differences

The following table explains the majority of differences between the Win32 API and the Win16 API in terms of application development.

• Different parameter packing on some windows messages (especially WM_COMMAND)
• Abundant Library of new API calls.
• The Kernel takes better advantage of threads, memory, and async I/O stuff.
• The API can take better advantage of file handling routines
• Objects, Processes, and Modules can have auditing and security built in.
• GDI allows 32 bit co-ordinates.
• To the User - the Explorer (Chicago) common controls and shell extensions
• Console mode apps can use all the 16 bit API, and even create windows. Window-based Applications can create consoles too -great for debugging.
• Structured Exception handling can make your programs more robust, or at least allow them to tidy up after a crash.
• The header files are a lot larger and better structured.

Why move from Win16 to Win32?

When starting out coding a new program, it is far easier to write a pure 32 bit app than old 16 bit programs -even if you used to use the large model. For working 16 bit apps there are a lot of benefits to be gained by porting to 32 bits.

• To get the much coveted Designed for Windows 95/Windows NT logo
• To take advantage of the new APIs
• To work with long file names. [Note: some workarounds here for MSDOS/win16 applications]
• To multitask properly, and the ability to make your programs more robust.
• To take up more disk & RAM.
• To stop appearing like an old-fashioned program.
• To escape many of the addressable limits of 16 bit programs.
• To have a program which runs well on a Pentium Pro CPU and under Windows NT
• So your code has a future, and an easily maintainable one at that.

It can be painful porting, especially during that phase when you have to support both 16 and 32 builds. However, for the Long-term, only 32 bit code has a future.

Why not?

• You've lost the source code - Hopefully, this does not happen frequently but it does happen.
• Your application may depend on a third party DLL or VBX for which there is no 32-bit equivalent. A thunk layer of code can assist, but that depredates overall performance. Those developers heavily into earlier versions of Visual Basic may find it difficult.
• You don't need any of the new API features our UI improvements.
• Your users will not gain much from improved multitasking or mind suffering on a Pentium Pro CPU.

If you choose not to upgrade your application to Win32, then you can still stamp the .exe as requiring Windows '95, so that the OS will automatically clean up all resources it has allocated.

Tools for Developers

Microsoft VC++4.x

Version 4.1 came out (March/96), although you can only buy 4.0 in the shops: you need a subscription to get the regular updates. Version 4.2 shipped in July 1996: it no longer supports Win32s and does not apparently install on Windows NT3.51. So, you have to use Windows NT 4.0. Developers still developing for NT 3.51 should use Visual C++ 2.0.

The class library supports OCX containers as well as control development itself, an improved Integrated Development Environment, over-LAN debugging and copy-on-write strings. Versions 4.0 & 4.1 use the OS to provide all heap management, while earlier and later versions use their own heap manager for better performance.

Microsoft VC++2.x

The last version, 2.2 was available on subscription only. It had the up to date Windows 95 header files and support for the new common controls. Also Windows95 ships with the base run time DLLs (MSVCRT20 MFC32) so your app doesn't have to. Cross compiler for Macintosh and native Mips/Alpha/PPC compilers available [and dearer].

Note: Does not run under Win32s.

Borland C++5.0. (For Intel platforms only).

A true 32 bit Integrated Development Environment that can still develop 16 bit and dos applications. OWL 5 provides wrappers for the common controls and windows sockets. Although apparently the system does support OCX creation and use, the lack of OCX support in the Resource Workshop, and the absence of any OCX Expert, means that it isn't really suitable for OCX development and use. It does still support VBX's in 32 bit apps though. The early 5.0 version had a reputation for leaks and bugs Some patches are available on Borland's Web site http://loki.borland.com/cpp/Patchs.htm. Version 5.01 ships with the MFC source, so that MFC applications can also be built with the compiler.

Visual Basic 4.0

Visual Basic 4.0 is the 32-bit successor to Visual Basic 3.0. It comes with OCX equivalents of all the old VBX's that it used to ship with, plus a more Object-Oriented language.

How does Visual Basic find Windows API Functions?

As mentioned earlier, all of the functions that comprise the Windows API are located in a set of dynamic link libraries that comprises Windows. Each of these dynamic link libraries has a header that defines which functions in the library can be called by other programs and where they are located in the library. These functions are said to be "exported" from the DLL.

When you write a Visual Basic program, the API functions are called just like Visual Basic functions. How does Visual Basic know which functions are API functions and where to find them? This is accomplished using the Declare statement which takes one of the following forms:

Declare Sub globalname Lib "libname" [Alias "alisaname" ][([argumentlist])]

Declare Function globalname Lib "libname" [Alias "alisaname" ][([argumentlist])] [As type]

globalname is the name of the function as it will appear in your Visual Basic code when you call it. This is usually the same as the name of the function in the DLL, but it may be different, in which case the name of the function in the DLL is specified as aliasname.

Watcom C++ 10.x

Has a reputation for good code optimization, and has licensed the MFC class libraries. [Tool of choice by real programmers. Apparently]

Symantec C++ 7.x

Comes with a licensed version of MFC 3.x.

Borland Delphi 2

A 32 bit version of Delphi, with OLE support added: automation client and server and "Support for OCX controls". That means it's a good OCX container but no good for implementing them.

Office 95/97 macro languages

Visual Basic for Applications and Word Basic are 32 bits wide now. They also have full OLE Automation Support

Newer 32 bit tools

Gnu for Win 32

This is a project underway to port the gnu compiler to windows 32. The final product probably won't ship with windows.h -it is intended to help in cross platform portability rather than windows app development.

Microsoft Visual J++.

Microsoft Visual J++ is a Java compiler that supports COM, so that Java can be used to write OLE/COM objects and call out to the Operating System via COM interfaces and the standard Java packages. Presumably the output will work on all 32-bit windows platforms.

The other Java compilers -Sun's JDK and Symantec's Visual Cafe for example, all produce perfectly good applet code, but lack the Operating System interfaces which one needs for Windows logo applications. But then, their output runs on all Java platforms.

Other Useful Tools

The NT resource kit is useful, as are many of the gnu command line tools. It is especially along the lines of application development and management containing versions of ps.exe and kill.exe

MSDN

The Microsoft Developer Network is an annual subscription to get a massive amount of CD-ROM's that are full of useful programming information. They also contain all of the supported operating systems including their resource kits. The kit comes in three varieties

• Library (Level I): All the docs on-line, plus books and sample code. [A lot of the code does not get maintained once it has been added to the disc]
• Professional (Level II): Library plus latest releases of operating systems, SDKs (Software Development Kits) and DDKs (Device Driver Kits). Note that this does not always mean you get beta copies of systems under development.
• Enterprise (Level III): Professional plus the server-side systems: cut down versions of NT Advanced Server, Back Office, Exchange SQL Server &c.
• Universal: Enterprise, plus subscription versions of all Microsoft's development tools and Office applications.

The Win32 Software Development Kit:

Win32 SDK is not a standalone compiler. But it does include some useful tools, including the Multiple Interface Definition Language compiler for custom COM interfaces.

Other Development Issues

OWL vs. MFC

This is a religious issue that is best not asked. C++ purists tend to prefer the OWL (Object Windows Library) because of its effective use of multiple-inheritance, templates and exceptions. MFC (Microsoft Foundation Classes) can be a bit lower level and the two phase construction process can seem unnecessary, but it is often more up to date with respect to windows features (OLE version 2.0, Explorer Objects).

Figure 1-12: Example of MFC common Controls

Which is the best OS for win32 application development? This may be a bit of a religious issue too. Windows NT is excellent for development, mainly because it is so robust and you can still use other applications during compiles. It does use a fair bit of RAM, even before you add the compiler's requirements. Developing 16 bit apps in NT is good too, simply because you can reboot the 16 bit subsystem so easily.

Windows 95 is not quite as robust as NT, but it runs better on a lower-end machine. If you want to use libraries for which there are no current NT equivalents then win95 is a must (or you can cheat and have two computers]. Extensive use of the win95 shell also provides valuable experience in the new user interface that is required to write a true Windows 95 application. As more "consumer-class" functionality is added to Windows NT, the need for using win95 may lessen.

Win31 and Win32s is not really suited for application development. Borland C++ certainly can be used in this situation, but not Visual C++. For others, consider relegating this platform to a test environment if a Win32s version is required.

Porting

When we speak of "porting", we are referring to the act of taking an application from one platform and translating to run on another platform. Initially, it is easier to go from 16 bit to 32 bits than the other way around. There is usually a prescribed process to doing so:

1.Get the 32 bit version of your development tools.

2.Get the 32 bit versions of any support DLLS/VBXs

3.Read the "Creating Great Applications for Windows 95" and "windows 95 logo requirements" articles and understand the implications.

Trying to compile your program with a 32-bit compiler is usually the first big step: fix all the errors it shows and then see if it works when it is run.

A raw API app can just be rebuilt, using PORTTOOL.EXE to help you. Using the "windowsx.h" macros and message crackers can assist you here. Class libraries often provide the message cracking for you, so make life a bit easier. Opening up the project in Visual C++ and rebuilding can port MFC Apps fairly quickly. In terms of the OWL-based apps, you might want to create a new 32-bit target or a new project with a 32 bit exe as the destination.

Implementations of the Win32 API

Windows NT

Windows NT native applications are Win32 applications. This makes those applications more powerful, robust, and faster.

Table 1-3: Areas of Windows NT Covered by the Win32 API

Atoms	Networks
Child Controls	Pipes and Mailslots
Clipboard Manipulations	Printing
Communications	Processes and Threads
Consoles	Registry Database Manipulation
Debugging	Resources
Dynamic-Link Libraries	Security
Event Logging	Services
Files	Structured Exception Handling
Graphics Drawing Primitives	System Information
Keyboard and Mouse Input	Tape Backup
Memory Management	Time
Multimedia Services	Windows Management

Win95 (Win32c)

With the release of Windows '95, application programmers are moving to port their applications to the Win32 API. However, there is some difficulty in making Windows '95 applications binary-compatible with Windows NT's Win32 subsystem. This is due to the Windows NT executive services. There are also significant differences between Windows '95 and Windows NT's memory-mapped file API. Under Windows '95, memory-mapped files are based in the system address range (>2GB) while under Windows NT the memory mapped files are based in the process address space (<2GB).

Many developers have assured the 32-bit compatibility of applications between Windows '95 and Windows NT. Microsoft also requires Windows '95 applications to work under Windows NT as well in order to get the Windows-flag compatibility stamp.

Figure 1-13: A Windows '95 Application

Win32s: Windows 3.x (Win32 on Win 16)

Win32s consists of a few Dynamic-Link Library files and Virtual Device Drivers that add Win32 API functions to the 16-bit Windows 3.x system. Microsoft created Win32s to allow developers to begin writing 32-bit code before the release of Windows 95 and Windows NT.

It is a set of modules that enable 32 bit windows applications to run under Windows 3.1. Only a subset of the Win32 API is implemented, hence the 's' in the name. Many 32 bit apps work with Win32s (Netscape, PhotoShop 3.0), but many do not (Visual C++2.0 onwards)

Although the kernel and GDI of win95 is clearly "cut-down" compared to NT, with 20 million copies sold [April 95], it is probably already the dominant platform for 32 bit windows applications.

Win32 Extension Libraries

There are many extension libraries to Win32. In fact, it seems that everyday, Microsoft is coming out with a new set of technologies alongside a code name. I practically have to review my Microsoft code words at the end of the week so when I give lectures, I can ensure myself that I am using the right word for the right set of technologies. Here are a few common Win32 extension libraries.

OpenGL

Ships with NT and available on win95 as extra DLLs from MSDN II.

WinG

Was used in Graphics/ Gaming Development, however its use is disparaged. Offered little above CreateDIBSection apart from a decent halftoner and a profiler applet. DirectX is the future of gaming under windows.

DirectX Games SDK

There are several different implementations of Direct X. Direct allows for optimization of games and until NT runs on Nintendo, it will be the future of NT gaming. It allows for certain calls to go directly to multimedia hardware. Here is a brief manifest of Direct X:

DirectX 1.0 (DirectPlay, DirectDraw, DirectSound, DirectInput) Win95 only.

DirectX 2.0 : DirectX 1 plus Direct3D Included in NT 4.0. Win95 & NT from Summer 1996. NT4 gets Direct 3D in from Service Pack 1, with hardware assist for 3D rendering in SP2.

DirectX 3.0: Available in both as of August 96.

Windows for Pens

Win95 only. All Win95 installations include an ink renderer DLL.

Explorer/New Shell

In Win95 and NT from versions 4,0 onwards.

TAPI32

Telephony support. Win95 and NT4 . The unimodem/V drivers which work well with voice

modems are available on the MS Web site.

TOOLHELP32

For win95 only. Debugging functions of little use to most programmers now that SEH can trap exceptions in your own code.

WINSOCK2

Available with NT4 and as an add on to win95. No 16 bit or NT3.x versions are planned.

ActiveX, the Internet SDK

An umbrella term for Microsoft technologies that enable developers to create interactive content for the World Wide Web. ActiveX Controls provide a new technique for enhancing web pages. These controls can also be implemented directly in a standard HTML application.

OLE

Prior to OLE, integration of multiple applications into a single custom solution could only be accomplished through a technology known as Dynamic Data Exchange (DDE). DDE proved very difficult to work with as it required execution of numerous commands-commands for establishing DDE channels and then passing commands from one application to another. DDE was also plagued by slow performance. While many applications still supports DDE calls, the preferred method of application communication is OLE.

OLE Automation

OLE Automation is a major advancement in cross-application programmability. While not only demonstrating a substantial improvement in performance, cross-application development via OLE Automation is also easier and more efficient than with DDE. With OLE Automation, instead of sending commands over channels (as was the case of DDE), a developer can access another application's objects as though they were native to the application. For example, because Microsoft Excel 5.0 and Microsoft Project 4.0 both support OLE Automation, a developer can write a Visual Basic for Applications macro in Microsoft Project that accesses Microsoft Excel's objects-and actually sets the properties of and calls the methods of such objects as though they were native to Microsoft Excel.

Figure 1-14: Inserting an OLE/COM object

OLE Controls

File Type Definitions:

VBX: A custom 16-bit Control used with Visual Basic Modules which can also be devloped in C or C++.

OCX: 16 or 32-bit OLE Controls developed in either C,C++, or Visual Basic.

Component Object Model (COM) of OLE.

Briefly, COM provides the plumbing needed for applications to use services on a distributed and cross-platform basis. The beauty of this model is that it means that you will probably never need to write to low-level APIs to enable distributed computing applications. Instead, you will either write or use COM-enabled applications and derive support for DCE and other distributed environments in the process. These abilities are provided by the inclusion of core distributed computing support within the design of Windows NT.

Distributed Component Object Model

Figure 1-15: Looking at DCOM Properties via the DCOMCNFG.EXE utility

A distributed component architecture applies these benefits across a broader scale of multi-user applications. The Distributed Component Object Model (DCOM) has three unique strengths that make it a key technology for achieving this:

COM is based on the most widely used component technology today. DCOM is simply "COM with a longer wire"-a low-level extension of the Component Object Model, the core object technology within Microsoft® ActiveX.

DCOM is the Microsoft networking technology to extend component applications across the Internet. Because it is an ActiveX technology, DCOM works natively with Internet technologies like TCP/IP, the Java language, and the HTTP network protocol, providing "object glue" that will enable business applications to work across the Web. DCOM enables distributed Java today without requiring any communications-specific code or add-ons such as "remote classes."

DCOM is an open technology that runs on multiple platforms. Microsoft is openly licensing DCOM technology to other software companies to run on all of the major operating systems, including multiple implementations of UNIX-based systems.

DCOM Security

The COM/DCOM security model enables the creation of secure distributed applications. COM security can be applied to both existing (legacy) COM components via external configuration as well as new COM code via the COM security APIs and interfaces.

Figure 1-16: Looking at DCOM Security options via DCOMCNFG.EXE

Services

A service is a process that can run on an NT box without a user being logged in, effectively acting as part of the operating system. It is similar to a Unix Daemon or a Netware Loadable Module. It gains the same rights as a user with the API functions LogonUser, ImpersonateUser Parameters for services are not easily changed. The registry should be used to store configuration information, so the service must check for the registry settings.

Running an existing program as a service

There's an example of this in the NT resource kit. It contains the two utilities - INSTSRV.EXE and SRVANY.EXE. They allow administrators to set up applications to function as services.

Table 1-4: Basic Default Services and NetBIOS-Dependent Services.

Alerter	Along with the Messenger service, generates warning messages to administrators about NetBIOS based events, messages, and problems.
Clipbook Server	Allows sharing of Clipbook pages to network users.
Computer Browser	Allows browsing the network for resources shared by other workstations.
Directory Replicator	Performs directory replication service for administrators to easily copy complete directories to multiple workstations.
Event Log	Monitors the workstation's use by local and remote users, recording events of significance. Also reports internal error conditions such as malfunctioning hardware, etc.
Messenger	Sends and receives messages in conjunction with the Alerter Service. The Main value of supporting the messenger service is that you can then receive Service Message Blocks (SMB's) from other networked machines. It uses your username and your workstation name in the NetBIOS name table, with a hex 03 appended to the end of each name.
Net Logon	Used to verify the authenticity of users logging on to a workstation, workgroup, or domain.
Network DDE	Required for dynamic data exchange between workstations
Network DDE DSDM	DDE Shared Database Manager. This service is used by Network DDE.
NT LM Security Support Provider	Supplies Windows NT Security to RPC Applications that do not use LAN Manager named pipe transports.
OLE	Provides OLE Support to applications.
Remote Procedure Call Locator	Used by the RPC to locate available workstations to process remote procedure calls.
Remote Procedure Call	Its primary use is to support client access to the NT machines. Also a necessary InterProcess Communication Mechanism for Client-Server Computing.
Schedule	Required for prescheduled commands, such as automated backups, to run at a specified time.
Server	This refers to a service that allows a device to accept requests from another computers redirector. This is the MS-NET's Network File System Mounter.
Spooler	Allows a workstation to spool printer files.
UPS	Monitors the Uninterruptable Power Supply and instructs the system to issue warnings, save files, and shut down prior to power outages.
Workstation	The redirector service that allows access to shared resources.

DLLs: Dynamic Linked Libraries

It is a collection of functions which do not constitute a process, but which can be loaded into a process and invoked. The loading is done at run time rather than at compile time (those are static libraries). DLLs have a special entry point DllMain that is invoked when processes and threads are attached and detached, allowing data structures to be created and destroyed appropriately.

A lot of the system is implemented in DLLs, even though their extension changes somewhat. The file types OCX, CPL, DRV are all really DLLs.

In windows 3.1 each DLL had only one instance of its data segment regardless of the number of applications using it. In Windows 32 a DLL can be marked as shared, for the same behavior, but the default is for each process to have a private copy of the DLLs data.

Why Create a DLL?

There are several reasons to create and take advantage of Dynamic-Linked-Libraries. Most of revolves around process and task management. Specific reasons-include:

• To divide a program into separate modules which can be loaded on demand.
• To store language dependent resources
• To enable a core code library to be used by your own and other applications
• Implementing OLE objects as in-process DLLs is the only real way to get performance out of an OLE link.
• To implement a control panel extension or some types of driver.

DLL's and the Registry

The following Registry Key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLS

is used heavily by Windows NT to inject DLLs into address spaces for use by active processes. The value for this key might contain a single DLL pathname or a set of DLL pathnames divided by spaces. When you restart your machine and Windows NT initializes, the Win32 subsystem saves the value of this key. Then, whenever the USER32.DLL library is mapped into a process, it retrieves the value from this key and calls a LoadLibrary function for each DLL specified in the string. One important thing to discuss is that the USER32.DLL does not check whether each library has been successfully loaded or initialized.

Windows '95 and the Registry

Windows '95 is a Win32 Operating system in theory although limited. The same goes for its registry. While many of the shell properties are commonalties between 95 and NT 4.0, there are some differences, due to the underlying structure of the operating systems.

Windows 95 writes much of its configuration information into hidden SYSTEM.DAT and USER.DAT files, which are found in the C:\Windows directory. If the system is configured for profiles (multiple users), a separate USER.DAT file is created for each user, and each such file is found in the user's own profile directory.

Here is a table displaying the comparisons of the files used to construct the registry in both Windows '95 and Windows NT:

Table 1-5: Construction of the Windows '95 Registry

Windows NT	Windows '95
SYSTEM SOFTWARE SAM SECURITY DEFAULT Volatile Hardware Detection	System.dat
NTUSER.DAT	USER.DAT

The Registry is divided into a structure similar to Windows NT. There are six HKEY's (Hive Keys) that allow for aligned modifications. Note that there is one more key than what is contained in the Windows NT registry.

HKEY_CLASSES_ROOT

Figure 1-17: HKEY_CLASSES_ROOT under Windows '95

As with Windows NT, the entire HKEY_CLASSES_ROOT key structure is nothing more than a duplicate version of all subkeys found in HKEY_LOCAL_MACHINE\Software\Classes. Its primary purpose is to provide backward compatibility with the Windows 3.1 registration database. More importantly, it sets the logical root of the classes subkeys. This also facilitates the capability of applications integrating 16 and 32 bit Object Linking and Embedding with the Component Object Model.

HKEY_LOCAL_MACHINE

Figure 1-18: HKEY_LOCAL_MACHINE under Windows '95

The information contained within this key is stored in the SYSTEM.DAT file in the WINDOWS system directory. Two of its subkeys (Config\000x and Software\Classes) are the sources for the HKEY_CLASSES_ROOT and HKEY_CURRENT_CONFIG keys.

HKEY_USERS

Figure 1-19: HKEY_USERS under Windows '95

Like Windows NT, this Key contains at least two subkeys. A default subkey displaying the default profile contents, and the profile of the currently logged on user.

HKEY_CURRENT_CONFIG

Figure 1-20: HKEY_CURRENT_CONFIG under Windows '95

The information seen here is aliased to HKEY_LOCAL_MACHINE\Config\000x, where 000x is the subkey for the current hardware configuration. If there is only one configuration, then the information is actually taken from HKEY_LOCAL_MACHINE\Config\0001. There would only be more in the case of multiple hardware profiles. Laptops with port replicators can use this for docked parameters and undocked parameters.

HKEY_CURRENT_USER

This information pertains to the currently logged on user. This information is based upon the user's profile. This governs the current working environment of the user. This information is dynamic during the tenure of that user's session. Upon logout, the contents are then saved to the user's profile (USER.DAT) This key will alias the HKEY_USERS structure by either mapping to a user's subtree, or the .DEFAULT subtree if it the first time the user's profile has been established.

Figure 1-21: HKEY_CURRENT_USER under Windows '95

HKEY_DYN_DATA

The dynamic data key is created every time Windows 95 initializes. Windows NT does not have this key. The data in this key exists wholly in System RAM and is never written to secondary storage. This key is very volatile and is often updated.

This key contains a Configuration Manager that will define the current hardware configuration of the system. These are primarily hardware enumerator keys, which are for pointers to allow for Windows '95's plug and play connectivity.

This key also has sections that are dynamic links to performance statistics that may be monitored on-screen through the System Monitor applet. This is a very large area and very dynamic.

MS-DOS Applications and Windows NT

Most DOS applications will execute in a window or full screen like under Windows 3.1. Associating the Command Prompt icon with the COMMAND.COM executable can create a real MS-DOS icon.

Figure 1-22: COMMAND.COM under Windows NT.

Applications that will not execute are those that directly access the hardware of an NT system.

Win16 Applications and Windows NT

All the major Windows 3.1 applications execute successfully using the Win16 subsystem. and NT uses it to execute applications moved over from Microsoft's Windows 3.1 system. Applications that should not execute are those that directly access the hardware of an NT system.

As popular applications are converted to Win32 (which will execute on both Windows NT and Windows) the importance of Win16 will lessen. Non-Intel (or Intel clone) processors use a Version of Insignia's SoftPC to execute Win16 applications.

Windows 3.1 used flat files primarily for configuration. Rather than using a hierarchical structure, OS Components and Applications used. Initialization files that are parsed for startup parameters and continuously done so frequently throughout the tenure of the process.

Windows 3.x and Win16 use two common initialization files called WIN.INI and SYSTEM.INI. There are also several other .INI files that are often application-specific. These files are in straight ASCII format that can be edited from any utility that can manipulate ASCII or text files. The file is divided into several sections divided with nested headings as given in the example below:

[windows]
Beep=yes
NullPort=None
BorderWidth=3
CursorBlinkRate=530
DoubleClickSpeed=452
Programs=com exe bat pif
Documents=
KeyboardDelay=2
KeyboardSpeed=31
ScreenSaveActive=0
ScreenSaveTimeOut=120
NetWarn=0
device=Canon  BJC-240,CANONBJ,LPT1:

[Desktop]
Pattern=170 85 170 85 170 85 170 85
TileWallPaper=0
GridGranularity=0
Wallpaper=(None)
WallpaperStyle=0

[Extensions]
crd=cardfile.exe ^.crd
trm=terminal.exe ^.trm
txt=notepad.exe ^.txt
ini=notepad.exe ^.ini
wri=write.exe ^.wri
rec=recorder.exe ^.rec
hlp=winhelp.exe ^.hlp
mmf=msmail.exe /f ^.mmf

Figure 1-23: WIN.INI

The .INI files contain computer-specific user and system parameters that help make Windows portable across machines. This information deals with paths, locations to supporting files, user-defined configuration, and overall hardware and software configuration.

The two most common .INI files found in 16-bit Windows are the WIN.INI and SYSTEM.INI files.

WIN.INI

In 16-bit Windows, the file contained much of the data that the user might change directly (or indirectly via an application) pertaining to items such as color schemes, desktop parameters, port settings, and fonts. Windows NT still uses the WIN.INI for some 16-bit application support. The Windows NT Registry also builds certain WOW configuration entries in the Registry based upon certain parameters found in the WIN.INI file. If certain specific applications require parameters in the WIN.INI upon installation, often these setup programs associated with these applications will place these parameters properly in the WIN.INI file while running under Windows NT.

Win32 stores this information in two primary locations. Per-Computer Software settings are found in:

HKEY_LOCAL_MACHINE\Software\

Per User Information is found in:

HKEY_CURRENT_USER

SYSTEM.INI

[keyboard]
subtype=
type=4
keyboard.dll=
oemansi.bin=

[boot.description]
keyboard.typ=Standard 101/102-Key or Microsoft Natural Keyboard
mouse.drv=Standard mouse
language.dll=English (American)
system.drv=Standard PC
codepage=437
woafont.fon=English (437)
aspect=100,96,96
display.drv=Cirrus Logic
secondnet.drv=No Additional Network Installed

[386Enh]
DEVICE=VSHARE.386
device=*vpd
mouse=*vmouse, msmouse.vxd
ebios=*ebios
woafont=dosapp.fon
display=*vdd,*vflatd
netheapSIZE=30
device=*vcd

Figure 1-24: SYSTEM.INI

This file contains system-specific information that Windows uses for primarily driver and hardware configuration. It also contains information that Win16 requires in order to totally boot successfully. Certain sections are very critical and important, especially the [boot] and [386Enh] sections. Pointers to Drivers (.DRV and .VXD's) are located throughout the file.

Windows NT uses this file much more minimally than the WIN.INI file. Windows NT uses a thunk layer of code to pass many of these parameters to and from the Win32 Subsystem. Therefore native Windows NT Drivers are used for these 16-bit applications. Most device drivers, especially CD-ROM drives, Mice, Backup devices, and especially printer drivers are passed through this Win16 on Win32 (WOW) layer.

Do not try to install applications that use Virtual Device Drivers, or any 16-bit device drivers (with the exception of some FAX drivers). The reason for this is that they will write information to the SYSTEM.INI file, which will cause them to be initialized by the application and/or subsystem. They will not be able to initialize properly because they will have to have direct access to hardware and this will not be allowed in Windows NT.

The majority of this information for Win32 is found in the following registry path:

HKEY_LOCAL_MACHINE\SYSTEM\CURRENT CONTROL SET

The Windows 3.1 Registration Database

Windows 3.1 stored certain information in a manner beyond a flat text file. With the introduction of extension libraries like OLE (Object, Linking, and Embedding), Windows brought a Registration Database. This file (REG.DAT) contained information that governed how certain applications would open and how it would manage and print files. It also gave information on file and object associations.

Windows 3.1 REGEDIT.EXE

This was the Registration Database Editor that ran in two modes. In its regular mode, this utility displayed the documents and applications that were registered internally in Windows 3.x. However, when ran in its verbose mode, this utility would display shell branches beyond each registered entity. This allowed the user to discretely view and/or control how document objects were associated by how they would be opened and printed. This allowed you to simply double-click on a .DOC file in the File Manager and pull up the Document in Microsoft Word. It would serve as the vital link that allowed a user to highlight a .WK1 file in the File Manager and have Lotus 1-2-3 automatically print the spreadsheet.

The commonality between Win16 and Win32 in configuration involves the memory-mapped coordinates of this database. Both Win16 and Win32 can reference this as HKEY_CLASSES_ROOT. While this is direct for Win16, this is merely in place as an alias in Win32 (Windows NT) It aliases to HKEY_LOCAL_MACHINE\Software\Classes. This alias insures backward compatibility for 16-bit associations and OLE registration.

REGEDT32 is not be confused with Windows 3.x REGEDIT

The REGEDIT Program found in the System Root directory of Windows NT 3.5x systems (usually \WINNT35) is the similar one from Windows 3.x.'s Registration Info Editor. It is a tool for adding, modifying, or updating application-integration information in the registration database. In Windows 3.x, the registration database is a source of information about applications. This information is used when you open or print a file from File Manager, and by applications that support object linking and embedding. The REGEDIT program under Windows NT allows you to edit 16-bit OLE registration information. 32-bit OLE registration is contained in the Registry's HKEY_CLASSES_ROOT subtree.

OS/2 Applications and Windows NT

The OS/2.subsystem supports character-based applications through Version 1.3 that can run independent of the Presentation Manager API.

(Other possible subsystems that could be made available in the future are PICK and perhaps VMS but this is speculative.)

Windows NT and POSIX Compliance

POSIX stands for Portable Operating System Interface for Computing Environments. A set of standards drafted by the Institute of Electrical and Electronic Engineers (IEEE) (1003.1) that define various aspects of an operating system, including topics such as programming interface, security, networking, and graphical interface. Many UNIX Environments such as LINUX are POSIX-Compliant as well. Code is source compatible across all POSIX-compliant environments if the code itself is POSIX compliant.

#ifdef DF_POSIX /* DF_MSS */
#include <misc.h>
#include <bsdlib.h>
#endif

#ifndef lint
char copyright[] =
"@(#) Copyright (c) 1989 The Regents of the University of California.\n\
 All rights reserved.\n";
#endif /* not lint */

#ifndef lint
static char sccsid[] = "@(#)ls.c?5.48 (Berkeley) 4/3/91";
#endif /* not lint */

#ifdef DF_POSIX /* DF_DSC */
#include <sys/cdefs.h>

Figure 1-26: Example of LS.EXE, a POSIX application under NT.

Registry Construction

The Boot Sequence

Windows NT boots in a number of stages. Some stages are specific to Windows NT and some are common to Intel and ARC based systems, such as the POST (Power-On-Self Test) routine.

The Intel Boot Process

When an Intel based machine is powered on, the CPU is set to run in real memory. This is the beginning of the Power on Self Test (POST) routine. The POST routine is responsible for determining the amount of memory, if required hardware components are present, such as a keyboard, and allowing adapter cards to initialize. The developer of the system's ROM, and the manufacturers of any installed adapter cards determine the information that appears on the screen at this point. Once the system has executed its POST routine, any installed adapter cards are permitted to run their POST routines.

At the end of the POST routine process, the CPU is instructed to process any commands that are at the reboot computer interrupt. This routine attempts to locate the boot device, by first checking drive A: and if no disk is found in drive A: the hard disk C: is checked. The first sector of the hard disk contains the Master Boot Record (MBR), which is loaded into memory. This contains a program that is executed. This program scans the partition table (the remaining portion of the MBR) to locate the "active partition" in the partition table.

Next, the "boot record" for the active partition is loaded into memory. The boot record starts at the first logical sector in the active partition. The program located in the boot record loads the first layer of the program necessary to start the operating system. When Windows NT is installed, the boot record is changed to support the loading of NTLDR. The former boot record (if DOS or OS/2 was on the system is saved as BOOTSECT.DOS.

NTLDR is used to control the Boot Loader Operating System selection process and requires NTDETECT.COM, BOOT.INI, and BOOTSECT.DOS to be in the root directory of the boot drive. In addition, if the drive the system is booting from is a SCSI drive, the file NTBOOTDD.SYS must also be in the root directory. NTBOOTDD.SYS is created during Setup (if the boot drive is a SCSI device), by making a copy of the appropriate SCSI driver in the root directory, and renaming the driver NTBOOTDD.SYS.

Once NTLDR is started, it proceeds through the following steps:

• Switches the processor into 32 bit flat model mode
• Starts the appropriate mini file system
• Reads the BOOT.INI and displays the operating system selections
• Allows the user to select an operating system
• Loads the correct operating system
• Executes NTDETECT.COM

Construction of the Registry

The registry subtree is divided into parts called hives (after their resemblance to the cellular structure of a beehive). A hive is a discrete body of keys, subkeys, and values that is rooted at the top of the registry hierarchy. A hive is backed by a single file and a .log file which are in the WINNT\system32\config or the WINNT\profiles\username folders. By default, most hive files (Default, Sam, Security, Software, and System) are stored in the WINNT\%\system32\config folder. The NTUSER.DAT and NTUSER.DAT.LOG files are stored in the WINNT\profiles\username folder. The WINNT\profiles folder contains the user profile for each user of the computer.

Registry hive	File names
HKEY_LOCAL_MACHINE\SAM	Sam and Sam.log
HKEY_LOCAL_MACHINE\SECURITY	Security and Security.log
HKEY_LOCAL_MACHINE\SOFTWARE	Software and Software.log
HKEY_LOCAL_MACHINE\SYSTEM	System and System.log
HKEY_CURRENT_USER	Ntuser.dat and Ntuser.dat.log
HKEY_USERS\.DEFAULT	Default and Default.log

Table 1-6: Registry Keys and their sources.

Registry Size Limits

The total amount of space that can be consumed by Registry data (hives) is restricted by the registry size limit, which is a kind of universal maximum for registry space that prevents an application from filling the paged pool with registry data. Registry size affects both the amount of paged pool the registry can use and the amount of disk space used by the registry.

To view or set the value for RegistrySizeLimit, first create the key using the following path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\RegistrySizeLimit

The registry size can also be viewed and set using the System option in Control Panel. See the Virtual Memory box in the Performance tab. The registry size should be changed only if the computer is either a primary or backup domain controller for a large network because all user accounts are stored in the registry. RegistrySizeLimit must have a type of REG_DWORD and a data length of 4 bytes, or it will be ignored. By default, the registry size limit is 25 percent of the size of the paged pool.. Setting a large value for RegistrySizeLimit does not cause the system to use that much space unless it is actually needed by the registry. A large value also does not guarantee that the maximum space will actually be available for use by the registry.

The BOOT.INI file

The file boot.ini contains the commands used in the menu that appears when a multiple boot is performed. The syntax used uses labels much like the alternate system boot capability of MS-DOS 6.0 and 6.2 and 6.22. Strings within square brackets are labels that each have a meaning for NTLDR.

In the following example, [boot loader] denotes the section used to specify the time-out period in seconds, and the default directory specification for the default system to boot:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(2)partition(2)\WINNT35
[operating systems]
multi(0)disk(0)rdisk(2)partition(2)\WINNT40="Windows NT Server Version 4.0" 
multi(0)disk(0)rdisk(2)partition(2)\WINNT40="Windows NT Server Version 4.0 [VGA mode]" /basevideo
c:\="Windows '95"

Figure 1-27: BOOT.INI

Directory specification are in the ARC syntax, a generic device designation used by RISC systems.

The ARC syntax is as follows, where <component> specifies the hardware adapter for the device:

	scsi or multi(x)disk(y)risk(z)partition(a)

scsi

The scsi option represents the ordinal number of the adapter with the first device 0. SCSI controllers that do not have their BIOS enabled are indicated as scsi.

multi

The multi option represents the ordinal number of the adapter with the first device 0. All other disk controllers including those scsi controllers that do have their BIOS enabled.

disk

The disk option is used only when using a SCSI disk the SCSI bus number for multiple-bus SCSI Adapters times 32 plus the SCSI ID of the disk. For multi y is always 0.

rdisk

the rdisk option is used when using a SCSI drive z is the logical unit number of the device For a non-SCSI device y is the ordinal number of the disk on the adapter.

partition

Partition is the ordinal partition number for the partition. MS-DOS extended

Partitions (type 5) and unused partitions (type 0) aren't numbered.

BOOT.INI Switches

The BOOT.INI file can contain switches that affect hoe Windows NT will be booted. In many of my training classes people ask me whether or not Windows NT has a facility to manage multiple startup configurations similar to DOS or Windows '95. We discussed earlier the HKEY_CURRENT_CONFIG key and how it is used to manage multiple hardware profiles. In addition to the use of hardware profiles, text-based start-up parameters can be placed after additional entries in the BOOT.INI file.

Here are most of the BOOT.INI switches:

/NOSERIALMICE= [COMx | COMx,y,z...]: Disables Serial Mouse Detection on the specified COM port. If no COM port is specified, then detection is disabled on all ports. This is excellent when trying to troubleshoot potential IRQ conflicts.

/BASEVIDEO: This causes the system to bypass whatever video driver is configured and use the standard VGA display driver (VGA.SYS and VGA.DLL) in the standard 16-color 640x480 resolution mode.

/DEBUG : enables debugging and sends the debug output to the last COM port known to the system.

/DEBUGPORT=COMx: sends debug output to the designated port.

/BAUDRATE=nnnnn: specifies the baud rate for the COM port using a modem with default of 19200 (can use null modem cable).

/CRASHDEBUG: This enables Windows NT's automatic recovery and restart capability. This can also be enabled within the System icon in the Control Panel.

/SOS: This switch is used the display the names of the drivers as they are being loaded. Without this switch, the normal progression dots display.

/NODEBUG: This switch specifies that there is no debugging information being monitored. This is only useful for developers and has a tendency to slow down system performance.

/MAXMEM:n: Specifies the maximum amount of memory Windows NT will use. Does not work on certain configurations.

/SCSIORDINAL:n: This switch is used only if the system has two identical controllers. This allows for distinguished controllers

NTDETECT.COM

If Windows NT is selected, NTLDR then executes NTDETECT.COM. NTDETECT.COM collects information on the hardware components installed in the machine. It then builds a list of these components and returns this information to NTLDR.

Currently, the following information can be detected by NTDETECT.COM:

Table 1-7: Information Gathered by NTDETECT.COM

Information	Example Registry Entry
Machine ID	AT/AT Compatible
Bus/Adapter Type	ISA
Video	Video7 VGA
Keyboard	PCAT_ENHANCED
Communication Port	COM1
Parallel Port	PARALLEL1
Floppy	Floppy1/Floppy2
Mouse	Microsoft Serial Mouse

After NTDETECT.COM has given NTLDR the list of installed hardware, the Windows NT boot process continues in its load phases.

The ARC Based Boot Process

On ARC based systems, the resident ROM firmware will select a boot device by reading a boot precedence table from non-volatile RAM. In the case where the non-volatile RAM is not valid or blank, the firmware will either query the user for the boot device or default to a: floppy, hard disk sequence. For a hard disk boot, the firmware will read the first physical sector of the boot drive (the Master Boot Record (MBR)) and determine if a bootable partition is present. If there is a bootable partition present, the first sector of the partition will be read into memory and the BIOS Parameter Block (BPB) examined to determine whether or not the volume's file system is one that the firmware supports. If the file system is supported by the firmware, the root directory of the volume will be searched for OSLOADER.EXE, and if found will be loaded and control passed to it.

The Boot Loader menu and functionality that is implemented by NTLDR on x86 based systems is not needed on ARC (Advanced RISC Computer) based systems. This is because ARC based systems have the NTLDR functionality built into the system firmware. Therefore, there is no need for NTLDR, the initial stages of the Windows NT load are handled by OSLOADER.EXE.

In addition, there is also no need for NTDETECT.COM on ARC based systems. The ARC POST routine collects the hardware information and OSLOADER.EXE gets the necessary information from the POST routine.

The Windows NT System Load Phases

The following stages will occur on all platforms once the Windows NT Kernel has been located.

Kernel Load

During this stage, the Windows NT kernel (NTOSKRNL.EXE) and the Hardware Abstraction Layer (HAL) are loaded into memory, but not initialized. Next a copy of the system hive, HKEY_LOCAL_MACHINE\SYSTEM, from the Registry is loaded into memory. When the system hive is loaded, this gives the user the option to select a hardware profile or to boot the LastKnownGood Configuration. Otherwise, at this time, the Registry is scanned for drivers with a start value of 0 (boot), which indicate they should be loaded but not initialized before the kernel, and a service type value of 0x1, which indicates it is a kernel device driver. Drivers with these values are typically low-level hardware device drivers, such as hard disk device drivers.

These drivers are not loaded into memory in the order found, instead their group value is first examined to sort the list. The sorting is based on the position of the Group Value in:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder

Value: List

Kernel Initialization

The screen turning blue signifies this stage of the boot process. This is when NTOSKRNL.EXE is initialized and control is passed to it. Subsequently, all of the drivers that were loaded during the Kernel Load stage are initialized. If an error is encountered, action will be taken based on the drivers ErrorControl Value. Once again, the Registry information is scanned, this time for drivers that have a 0x1 start (System) value. Similar to the Kernel Load phase, the list is sorted according to order and the drivers are then loaded. In addition, these drivers are initialized as soon as they are loaded.

During this stage, the Registry Hardware list is created using the information that was passed from NTLDR or OSLOADER.EXE, depending on the type of system. Creating a link to ControlSet00x, where x is 1, creates the CurrentControlSet or 2 as determined by checking the value of Default under:

\HKEY_LOCAL_MACHINE\SYSTEM\Select

In addition, making a copy of the CurrentControlSet creates the Clone ControlSet and both CurrentControlSet and Clone are initialized, but not saved yet.

Services Load

This stage is when Session Manager (SMSS.EXE) is started. The first thing Session Manager does after starting is it reads and executes the list of programs under the BootExecute program in:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute

The default entry is:

autocheck autochk *. 

AUTOCHK.EXE is the version of CHKDSK that automatically performs a check on each partition. If this entry is changed to read:

autocheck autochk /p *, 

the /p will force the equivalent of a CHKDSK /F on each partition on every subsequent restart of the system. Since the BootExecute value is a REG_MULTI_SZ, BootExecute can have more than one entry under it. Therefore, you could add a second line such as: autocheck autochk /p \DosDevices\c:, to have AUTOCHK.EXE perform the equivalent of CHKDSK /F on drive c: for each restart of the system. If a drive has been set to be converted to NTFS on the next system boot, the following entry will be added to ...\SessionManager\BootExecute: autocheck autoconv \DosDevices\x: /FS:ntfs.

Once the check disk information starts displaying on the blue screen, it is a clear indication that Session Manager has started. Of course, if this information does not appear it is possible that the autocheck line was removed from the BootExecute Registry entry.

After all of the checks have been successfully performed on the system's hard drives, Session Manager will set up the Pagefiles defined under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

Next, since the partitions are now checked and the paging files are setup the CurrentControlSet and the Clone ControlSet are written to the Registry. The next items to occur are the creation of symbolic links. These links are used to direct certain classes of commands to the correct component in the file system. These entries are located in:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Device Drivers

Finally, the entries in Required under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems

are loaded.

As can be seen, by default the only required entry is the Win32 subsystem (CSRSS.EXE). This subsystem is required, because all access to the video screen goes through the Win32 subsystem, therefore it must always be loaded.

Win32 Subsystem Start

When the Win32 subsystem is started, it automatically starts WINLOGON.EXE, which starts its System entries under:

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\Current Version\Winlogon

By default WINLOGON.EXE will start the Local Security Authority subsystem (LSASS.EXE) and the print spooler (SPOOLSS.EXE). Next, the welcome screen is presented with the CTRL+ALT+DEL logon message and then the Service Controller (SCREG.EXE) is executed.

Once the Service Controller has started, it makes a final pass through the Registry looking for items with a start value of 0x2 (Automatic). However, at this point the loading sequence is determined differently from that of the device drivers that were loaded earlier in the process. All services with a 0x2-start value have certain dependencies, DependOnGroup and/or DependOnService entries that determine their load order. This is necessary because these services are loaded in parallel for better performance, where as the device drivers were loaded serially so their Group order was sufficient. Each service must have its dependencies started before it will be able to start.

Migrating .INI information to the Registry

If you install Windows NT as an upgrade over Windows 3.1, all the settings from various initialization files are copied into the Registry, including CONTROL.INI, PROGMAN.INI, SYSTEM.INI, WIN.INI, WINFILE.INI, and others. You can see where the Windows initialization files are mapped in the Registry by viewing the subkeys and value entries under this path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping

When you install an application created for 16-bit Microsoft Windows, the application's setup program creates its own .INI file or creates entries for the WIN.INI or SYSTEM.INI file. This is the same way that is done for any versions of 16-bit Windows 3.x. These entries are not updated in the Registry, because these applications do not know how to access the Windows NT Registry. For this reason, basic SYSTEM.INI, WIN.INI, and WINFILE.INI files appear in the root directory in Windows NT.

To find mapping information in the HKEY_LOCAL_MACHINE\Software key, the system looks up the FILENAME.EXT of the initialization file. If a match is found, it looks under the mapped key for the specific application name and a variable name, and if necessary it continues to look for keys whose value entries are the variable names. If no mapping for either the application name or filename is found, the system looks for an .INI file to read and write its contents.

Table 1-7: Symbols within entries in the IniFileMapping key.

!	Forces all writes to got to both the Registry and to the .INI file on disk.
#	Causes the Registry value to be set to the value in the Windows 3.1 .INI file whenever a new user logs in for the first time after Setup, if Windows NT was installed on a computer that had Windows 3.1 already installed.
@	Prevents any reads from going to the .INI file on disk if the requested data is not found in the Registry.
USR	Stands for HKEY_CURRENT_USER, and the text after the prefix is relative to that key.
SYS	Stands for HKEY_LOCAL_MACHINE\SOFTWARE, and the text after the prefix is relative to that key.

 COMPUTING MCGRAW-HILL | Beta Books | Contact Us | Order Information | Online Catalog

Computing McGraw-Hill is an imprint of the McGraw-Hill Professional Book Group.