Results 1 to 2 of 2

Thread: Why is NT/2k so much more stable? Part 2/5

  1. #1
    Webius Designerous Indiginous
    Join Date
    Mar 2002
    South Florida

    Why is NT/2k so much more stable? Part 2/5

    Everyone always says that Win 9x/ME sucks and Win NT/2k is so much more stable.
    Why is it more stable?

    Well, Here is your answer. Yet another tutorial by xmaddness.


    In this tutorial I will take you on an in-depth look at the inner workings of the M$-DOS/3.x, Windows 9x and Windows NT/2k Operating Systems. This tutorial will be written in lay mans terms and requires no prior knowledge of how each system works. (Although it will definetly help) I will discuss how each operating system boots, manages memory, how applications interact with the Operating System, and how the Operating System interacts with the hardware. This could be a pretty long tutorial. :P

    PART 1

    -----------------------A Brief summary of the PC Boot Process---------------------------

    Every time you boot your computer several steps must be taken to get your system up and running. I will provide a brief summary of the initial tasks that must be completed before the operating system can run succesfully. I will list the processes first giving you a brief glimps, and then I will continue to explain them in more detail. Each time you boot your computer the following occurs:

    [list=1][*]Startup BIOS tests essential system hardware. This test is called the Power on self test (POST)[*]Setup information is used to configure both hardware and software.[*]Hardware is assigned system resources that they will later use for communication.[*]The operating system is loaded, configured, and started.[*]Hardware is matched up via the BIOS to the specific device drivers that control them.[/list=1]

    Now lets take a deeper look at each process in this list.

    • POST

      During POST the ROM BIOS startup program surveys hardware resources and needs, and assigns system resources to meet those needs. The BIOS starts by reading information from the hardware provided by DIP switches, jumpers, and the CMOS chip, and the compares what it finds with the hardware that is found. Some hardware components, such as video cards, have their own BIOS's and request system resources at this time as well.

    • The ROM BIOS startup program searches for and loads an OS.

      Most often the Operating System is loaded from logical drive C on the hard drive. The CMOS chips configuration information tells the startup BIOS where to look for the OS. The BIOS turns to that device (usually the hard drive, but could also be a floppy boot disk, hence why you choose the boot order in the BIOS), reads the beginning files of the OS, copies them to the memory and then turns the control over to the OS.
    • The OS configures the system and completes its own loading sequence.

      The OS checks some of the same things that the startup BIOS checked, such as available memory, and whether that memory is reliable. The OS continues by loading drivers to control such things as a mouse, cd-rom drive, and other peripherals.

    From this point on the loading sequence begins to change depending on which OS you are using on your machine. Lets take a brief look at the M$-DOS/3.x Operating System.

    ---------------------------The M$-DOS Operating System-------------------------------

    [list=1][*]BIOS locates the IO.SYS file and executes it.[*]The IO.SYS file finishes and locates the MSDOS.SYS file and executes it.[*]The MSDOS.SYS file locates the CONFIG.SYS file and if found executes it.[*]The COMMAND.COM file is executed and locates the AUTOEXEC.BAT file, and if found executes it.[/list=1]

    Once the autoexec.bat file is executed, the OS is completely loaded and the command.com waits for your commands. (hence why it is called command.com) Now lets take a quick look at what takes place during each step.

    [list=1][*]The BIOS locates the master boot record on the hard drive, which looks to the partition table to determine where the logical boot drive is physically located. Once the BIOS locates the boot record it begins the loading of the first OS files. The M$-DOS boot record is a very short program; it consists of only two small hidden files which make up the core of the DOS OS. These two files are IO.SYS, and MSDOS.SYS.
    [*]The first file that the BIOS loads and exectues is the IO.SYS file, which contains more BIOS software. Once this file is executed the MSDOS.SYS file, which contains software to manage files, run application software, and interface with hardware, is executed.
    [*]The MSDOS.SYS file locates the CONFIG.SYS file and if found begins to execute it. The CONFIG.SYS file contains information that loads the proper device drivers and is actually optional. Next comes the COMMANd.COM. The COMMAND.COM is the file that provides you with a command prompt and awaits your instructions. The COMMAND.COM file includes the basic navigational instructions such as DIR, COPY, MOVE, RD, MD, CD, and many more.[/list=1]

    This loading sequence will be the same to this point for the Windows 3.x/9x/ME Operating Systems. These OS's are based on the DOS core file system and this is the main reason for their instability. The instability issues will become clear to you after I discuss how each OS manages memory and resources.

    -----------------------------The Windows 3.x Operating System-------------------------

    If Windows 3.x is present on the machine there is usually and command in the AUTOEXEC.BAT file that executes the WIN.COM file located in the C:\WINDOWS directory. Windows software loads just like other software running in DOS. The program is first loaded into memory and then executed. Lets take a quick look at what happens when the WIN.COM is executed.

    [list=1][*]WIN.COM is executed via the AUTOEXEC.BAT file. (or from the dos prompt)[*]WIN.COM looks for and loads the folowing initialization files: SYSTEM.INI, PROGMAN.INI, WIN.INI, CONTROL.INI, and MOUSE.INI.[*]Windows 3.x is then fully loaded and awaiting your commands. [/list=1]

    Now lets take a quick look at what each of these INI files did.

    • SYSTEM.INI contains hardware settings and multitasking optioins for windows.
    • PROGMAN.INI contains information about Program Manager groups.
    • WIN.INI contains information about user settings, fonts, file associations and extensions, and application settings.
    • CONTROL.INI contains information about the user's desktop, screen saver, wallpaper, colors, etc...

    NOTE: Windows 3.x is really NOT a true Operating System persay. During this stage of creation it was simply an application that ran in the DOS Operating System.

    Continued here-------------------------------------------------------------

    The M$-DOS Operating System was limited to 16-bit data processing because originally only 16 lines on the system bus were devoted to transmitting data to and from the CPU. With the earlier CPU's DOS could only handle one program at a time, and that program had direct access to the first 1024K of memory addresses. This processing mode is called REAL MODE. Later, beginning with the i286 CPU, the CPU could handle more than one program at a time by switching back and forth between them. This mode, called PROTECTED MODE, allows for memory adresses above 1024K, 32-bit data transfers, and the OS could use the hard drive as virtual memory. Once this technology became available, Windows 9x would start to emerge. We will discuss more of how the various OS's handle memory and resources in more detail in later sections.

    PART 2

    -----------------------The Windows 9x/ME Operating System------------------

    In this section we will take an indepth look into how the Windows 9x/ME Operating systems differ in the boot process from the M$-DOS/3.x OS.

    M$-DOS is a 16-bit OS. All portions of the OS are written using 16-bit code, and DOS only supports 16-bit drivers and 16-bit applications. Windows 3.x also only supports 16-bit drivers and 16-bit applications, but does contain a smal amount of 32-bit code. With the advent of Windows for Workgroups 3.11, M$ introduced a fast 32-bit programming for disk access, which is now called VFAT, but generally speaking Windows 3.x is a 16-bit program and only supports 16-bit applications. Another change to note is that with the advent of Windows 9x/ME, plug and play devices become available and widly used.

    For more on file systems see my tutorial FAT vs. NTFS The ultimate Guide to Win file systems.

    The Windows 9x/ME OS contains some 16-bit code and some 32-bit code. Programs written in 32-bit code require much more memory and are generally faster than the 16-bit programs. Windows 9x supports VFAT, which was written for Windows with Workgroups 3.11, and is 32-bit code. Windows 9x/ME can support 16-bit drivers, although its better to use the 32-bit drivers supplied with Windows 9x/ME for three main reasons:

    • 32-bit drivers are much faster.
    • 32-bit drivers can be stored in Extended Memory, freeing more of the first MB's of memory for applications.
    • 32-bit drivers are dynamically loaded, meaning they are loaded when needed and unloaded when not needed, saving yet more memory.

    For now it is important to understand that with Windows 9x/ME, the 32-bit processes are much more used rather than M$-DOS, more of the 32-bit vs. 16-bit processing will be discussed in later sections.

    Now lets take a look at the Windows 9x/ME boot process and core files.

    Windows 9x/ME first loads in real mode, and then switches to protected mode. With M$-DOS, the two core real-mode system files that are needed for starting up the OS, IO.SYS and MSDOS.SYS, remain in memory once the OS is up and running. With Windows 9x/ME the IO.SYS is responsible for only the initial startup processes performed in real mode, then control is turned over to VMM32.VXD, which runs in protected mode, and the IO.SYS is removed from memory and terminated. Windows 9x/ME also includes a file named MSDOS.SYS, but it is only a text file that contains some switches to affect the way the OS boots. Lets now take a quick look at the outlined startup processes and the files involved.

    [list=1][*]BIOS boots the PC, runs POST, and the Plug and Play BIOS configuration begins. [*]IO.SYS loads and checks for the MSDOS.SYS, CONFIG.SYS, and loads any information found within. The COMMAND.COM and AUTOEXEC.BAT are loaded. Finally WIN.COM loads the real mode core components. IO.SYS is now terminated.[*]VMM32.VXD creates virtual machines (will be discussed later), and loads static vxd's in the registry, and the system.ini file.[*]Windows 9x/ME now transfers to PROTECTED mode.[*]Plug and Play configuration manager loads and and configures PnP devices, and loads the dynamic 32-bit device drivers (VxDs)[*]Windows then loads the remaining components such as:[/list=1]
    • Kernel (kernel32.dll, Krnl386.exe)
    • GDI (gdi.exe, gdi32.dll)
    • Fonts
    • Win.ini is checked
    • Shell and desktop is constructed

    Windows 9x/ME is now loaded and ready to take commands. Lets now take a closer look at each of these processes.

    • BIOS Boot
      Startup BIOS begins its process discussed earlier in the tutorial. If the BIOS is Plug and Play (PnP) compatible, it then looks to the perminent RAM stored on hardware devices for configuration information. It then performs the POST and then stores the PnP information for the PnP configuration manager used later in the boot process.
    • IO.SYS
      IO.SYS is now loaded, which creates a real mode OS environment. It automatically loads many drivers, sets environmental variables, and executes any commands listed in the CONFIG.SYS and AUTOEXEC.BAT. These two files are not used in the same way that they were used with DOS, because many of these commands are now located in the IO.SYS file. Although they are still ran and the entries found within are still loaded. The reason for this is so the Windows 9x/ME OS is backwards compatible with older 16-bit drivers. IO.SYS then loads the COMMAND.COM, and follows instructions found within the AUTOEXEC.BAT file. Finally IO.SYS loads the WIN.COM, which loads other real mode components.
    • VMM32.VXD
      In this part of the OS boot the IO.SYS gives control to the VMM32.VXD (Virtual Memory Manager) and loads static VxDs. (recall that Static VxDs are loaded and stay in memory, whereas Dynamic VxDs load when needed and unload when not needed) A VxD (Virtual Device Driver) works with a virtual machine to provide access to hardware for software running in the Virtual Machine. (will be discussed later) Under Windows 3.x, these VxDs were loaded from the system.ini in the [386enh] section, and had a 386 file extension.

      The VMM32.VXD is built specifically for the computer it is on when Windows 9x/ME was installed and contains critical VxDs needed for a succesful boot. VMM32.VXD kills the IO.SYS and, while still in real mode, loads static VxDs device drivers that are found in the following four locations:

    [list=1][*]Embedded in the Vmm32.VXD file.[*]Found in the registry.[*]Found in the SYSTEM.INI file.[*]Or stored in the \windows\system\vmm32 directory.[/list=1]
    • Protected Mode switchover and PnP configuration.
      The VMM32.VXD now switches to Protected mode and loads the PnP Configuration Manager. The PnP Manager loads and configures both the legacy devices and the PnP devices. Legacy devices are older devices that do not have a RAM bios with PnP information, and usually make use of DIP switches, Jumpers, or both. It looks into the memory and uses any information that the BIOS left for it and loads the appropriate PnP VxDs accordingly.
    • Windows loads the remaining components.
      With the VMM32.VXD still in control, Windows 9x/ME loads the three core componets (GDI, KERNEL, and USER, which will be discussed later) of the Windows 9x/ME OS. At this time the appropriate fonts are loaded and other associated resources are loaded. The WIN.INI file is checked, and commands found within are executed for backwards compatibility. The shell and desktop are now loaded, and finally the startup directory is executed.

    This completes the Windows 9x/ME Operating system startup procedure. If some of the things do not make sence now, do not worry. I will discuss the KERNEL, GDI, and User subsystems in the "How Windows manages memory and resources section". These core components are what determines the stability of the Operating Systems and will become the focus of this tutorial. Although to understand WHY these core components you must have an understanding of how each operating system loads and interacts with the hardware and resources.

    Well, thats it for now. The reason I'm writing this is because I have my final coming up next week in my PC Support and Services -- Operating Systems class. I figured I would write this tutorial from my notes to be sure I would pass the test. I am splitting this tutorial into five parts. Part one and two is here. The other parts will be as follows:

    • Part 3 - Windows NT/2K
    • Part 4 - How windows manages memory and resources
    • Part 5 - Conclusion

    Look for them coming soon. They will be additions to this same thread and I will either bump or post when the additions are made. Hope you enjoy!


    BTW: If any thing is found to be confusing or wrong in this tutorial, contact me and I will correct them accordingly.

  2. #2
    Webius Designerous Indiginous
    Join Date
    Mar 2002
    South Florida
    Part 3 can be found here.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts