Any use of this Beta Book is subject to the rules stated in the Terms of Use.
|
|
|
|
| |
| © 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 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:
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.
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:
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.
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.
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?
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
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:
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:
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.
| 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.
