How Windows 98 Processed Environment Variables
Microsoft Windows 98 handled environment variables through a hybrid
architecture deeply intertwined with its underlying MS-DOS subsystem,
relying primarily on startup configuration files rather than dynamic
system databases. Because Windows 98 was anchored to MS-DOS 7.1, global
environment variables were defined at boot time through
AUTOEXEC.BAT, captured into a master memory block during
system initialization, and subsequently inherited by both Win32
applications and legacy DOS virtual machines.
The Role of AUTOEXEC.BAT and CONFIG.SYS
The definition of system-wide environment variables in Windows 98
began before the graphical user interface loaded. During the initial
bootstrap process, the real-mode MS-DOS kernel parsed the
AUTOEXEC.BAT script located in the root directory of the
boot drive. Any standard SET statement (such as
SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND or
SET TEMP=C:\WINDOWS\TEMP) initialized variables inside the
master DOS environment table.
Because the default DOS environment table had an allocation limit of
256 bytes, systems with extensive path definitions or third-party
software variables frequently encountered "Out of environment space"
errors. To resolve this, administrators adjusted the SHELL
directive inside CONFIG.SYS, typically declaring
SHELL=C:\COMMAND.COM /P /E:2048 to expand the master
environment buffer prior to launching the operating system.
Transition to the Win32 Subsystem
Once real-mode initialization concluded, the system executed
WIN.COM to load the 32-bit Virtual Machine Manager (VMM32)
and the Windows protected-mode environment. During this handoff, Windows
98 duplicated the existing MS-DOS master environment table into memory
managed by KERNEL32.DLL.
This duplicated table served as the default template for all
processes initiated inside the graphical shell
(EXPLORER.EXE). Whenever a user launched a Win32
application, the Windows kernel allocated a new memory block and copied
the parent process’s environment into the child’s address space.
Applications accessed these values using standard Win32 API functions
such as GetEnvironmentVariable and
SetEnvironmentVariable.
Process Inheritance and Scope Isolation
Windows 98 strictly enforced process-level isolation for environment
variables. Modifying an environment variable inside an active
session—such as running SET FOO=BAR within an MS-DOS prompt
(COMMAND.COM)—modified only the local memory block assigned
to that specific virtual machine (VM).
When a process terminated, its local environment block was destroyed. Changes made in an active command prompt or within a running application could not broadcast upward to the parent shell or laterally to other active applications.
Configuration Management and Absence of Registry Control
Unlike its contemporary NT-based counterpart (Windows NT 4.0 and later Windows 2000), Windows 98 did not utilize the Windows Registry as the canonical source for persistent global environment variables. The System Properties applet in the Control Panel offered hardware and performance tuning options, but it lacked an interface for editing environment variables directly.
To apply permanent, system-wide changes, users edited
AUTOEXEC.BAT manually or used configuration utilities
provided with the operating system:
- System Configuration Utility
(
MSCONFIG): Provided a graphical checklist allowing users to view, enable, or disable lines withinAUTOEXEC.BAT. - System Configuration Editor (
SYSEDIT): Opened text editor windows directly targetingAUTOEXEC.BAT,CONFIG.SYS,SYSTEM.INI, andWIN.INI.
Because environment variables relied on real-mode execution to populate the initial system environment block, any modification to global configuration files required a full system restart to take effect across the entire operating system.