Give Your PC the Boot

By Rob Wentworth

Reprinted with permission from The Digital Viking
(official newsletter of the Twin Cities PC User Group)
November 1997

There are some interesting tricks you can do to customize and streamline the way your PC behaves (or misbehaves) when you turn it on. To understand just what you can do, it helps to understand what is going on under the hood during power up. In the following paragraphs, we will explore a simplified description of the PC power-on bootstrap process, and how to modify it. (Warning: semi-simplified computer geek-speak deep-magic buzzwords spoken here). :-)

Undercover Operations

Besides a CPU (Central Processor Unit) and RAM (Random Access Memory) the PC motherboard contains a BIOS (Basic Input / Output System) ROM (Read Only Memory) chip. The motherboard BIOS is a set of 16-bit program code that provides basic initialization and control for built-in motherboard resources and some common plug-in cards, including memory controller, keyboard controller, serial and parallel I/O controllers, floppy disk controller, IDE controller, and more. The motherboard BIOS also contains POST (Power-On Self-Test) diagnostic code, which gives us the familiar memory count-up display while memory is being tested.

Any recent motherboard BIOS also contains a setup program that enables changes to be made to the CMOS settings. CMOS (Complementary Metal-Oxide Semiconductor) memory can retain its contents even when the computer is off for long periods of time, using only a small battery which is often soldered directly onto the PC motherboard. The CMOS settings tell the motherboard BIOS things it needs to know about your computer such as hard disk parameters, and how you want motherboard resources configured. On older computers, the setup program is not contained in the BIOS ROM but comes on a floppy disk supplied by the motherboard manufacturer, and must be run as a separate application program. You may have to look in your computer reference manual to figure out how to run the CMOS setup program for your PC.

Some plug-in cards such as video boards, SCSI hard disk controllers, and some network cards, contain a BIOS ROM of their own. Other plug-in cards do not have their own BIOS ROM and are not handled by the motherboard BIOS, but are handled by device driver programs that must be loaded from external storage (floppy diskette, hard disk, or network server) later in the boot sequence, or must be handled directly by the application programs that need them. A sound card is a good example of hardware that is usually initialized and controlled directly by application programs (or Windows drivers).

Start Your Engines

When you turn on the power, press the Reset button, or press the "three-finger salute" (Ctrl-Alt-Delete) keyboard command, the CPU inside your PC begins executing the startup bootstrap program residing inside the motherboard BIOS ROM. This program first initializes motherboard resources, such as the memory controller for RAM, to safe settings before using any RAM or other devices. It then scans a range of memory addresses reserved for external device BIOS ROMs, looking for device initialization routines to call.

Video boards contain a video BIOS ROM chip. The video BIOS device initialization code sets up the video hardware into its 80-character by 25-line text display mode, so that the motherboard BIOS can display any messages generated during the bootstrap process.

Hard disk controller and network BIOS ROMs may contain additional bootstrap code allowing the computer to load the operating system using that device.

After the initialization routines in all the device BIOS ROMs have been executed, the motherboard BIOS examines the CMOS settings to decide in which order to search bootable storage devices for additional bootstrap code to load and execute. A recent motherboard BIOS I have been using allows me to select the boot device order amongst floppy A: drive, hard disk drives C: through F:, CD-ROM drive, SCSI hard disk or tape drive, ZIP drive, and LS-120 drive. The usual default CMOS setting is to try to boot from the A: (first floppy) drive then the C: (first hard disk) drive. In the following paragraphs, we will assume this default setting.

DOS Boot (Wasn’t That A Movie?)

If there is a floppy diskette in the A: drive, the data at the very beginning of the diskette (sector zero) is loaded into memory and executed. If this is not a bootable diskette, the code in this sector displays a message telling you to insert a bootable diskette and press the Enter key. A package of IBM brand pre-formatted diskettes I once purchased (with English-labeled packaging) contained diskettes with sector zero code that displayed this message in Spanish ( :-( !).

If this is a bootable diskette, the code and data contained in sector zero depend on the operating system and diskette format. Let’s assume for our purposes that the diskette is in a FAT (File Allocation Table) format, in which case sector zero also contains a description of the floppy diskette layout, including number of cylinders, number of heads (single or double sided media), sectors per track, location of the FAT, location of the file directory, and location of the file storage area on the diskette. Let’s also assume that this diskette boots a version of MS-DOS (Microsoft Disk Operating System).

The bootstrap code uses the data in sector zero to locate and load the IO.SYS file into memory. This file contains a more advanced level of I/O device control code than is provided by the BIOS ROM code alone. The bootstrap code also locates, loads and executes the contents of the MSDOS.SYS file, which is the memory-resident portion of MS-DOS. MS-DOS reads and processes the contents of the CONFIG.SYS file, then loads and executes the COMMAND.COM program with parameters telling it to execute commands in the AUTOEXEC.BAT file. After all commands in the AUTOEXEC.BAT file have been executed, COMMAND.COM provides a DOS prompt (usually A:> when booting from floppy) where you can type in DOS commands and executable program names.

Boot Hard Disk Through Windows

If the A: drive is empty, then the data at the very beginning of the first hard disk (physical sector zero of drive zero) is loaded into memory and executed. Physical sector zero normally contains bootstrap code, a description of the physical hard disk layout (cylinders, heads, and sectors per track), partition management code, and a partition table.

This is where stealth partition viruses like to hide. Because the operating system has not been loaded yet, a virus can intercept hard disk BIOS calls from any program loaded later, and hide itself by feeding a hidden copy of the original uninfected physical sector zero contents to any program requesting to read physical sector zero. Anti-virus code can’t even see the infected hard disk physical sector zero contents, unless the system is booted from a known good uninfected write-protected boot floppy disk, and an uninfected anti-virus program is loaded and run from that floppy. That’s why it’s not safe to trust an anti-virus program unless you boot and run it from an uninfected floppy diskette. When booting from floppy, the infected hard disk physical sector zero code is not loaded or executed, so hard disk BIOS calls are not intercepted by the virus and the anti-virus program can see the actual virus code residing on physical sector zero.

The partition table on physical sector zero describes exactly where on the physical drive each partition (logical drive letter) starts, what format each partition uses, and which partition is marked as the active bootable partition. In this example, we are going to boot Windows 95 from the C: drive, which is FAT-16 formatted and resides in the first partition of the first physical hard disk.

The physical sector zero bootstrap code uses the partition manager code to locate the starting sector of the active bootable partition, then loads the data at the very beginning of that partition (logical sector zero) into memory and executes the logical sector zero bootstrap code.

When a hard disk partition is Windows 95 bootable, logical sector zero contains bootstrap code, a description of the logical hard disk layout (cylinders, heads, and sectors per track re-mapped to conform to the MS-DOS 1024 cylinder limitation), and Windows 95 MSDOS.SYS (text file) boot option processor code. When this logical sector zero bootstrap code is executed, it uses the boot option processor code to decide what to do next.

Let’s assume that the MSDOS.SYS BootGUI=1 option is set (the default value), so we will boot to the Windows 95 desktop instead of a DOS command prompt. At this point, the IO.SYS file (extended I/O system code) is loaded into memory. Then the original contents of the MS-DOS.SYS file (MS-DOS 7.0 operating system code -- copied to a different hidden file when Windows 95 was installed), is loaded into memory and executed.

Just like when booting from floppy disk, MS-DOS reads and processes the contents of the CONFIG.SYS file. Unlike when booting from floppy disk, additional device drivers (including HIMEM.SYS and EMM386.EXE) are loaded automatically at this time if they have not already been loaded by CONFIG.SYS processing. Then MS-DOS loads and executes the COMMAND.COM program with parameters telling it to execute commands in the AUTOEXEC.BAT file. After all commands in the AUTOEXEC.BAT file have been executed, COMMAND.COM automatically executes a win command to load and run the rest of Windows 95 if not already executed in the AUTOEXEC.BAT file.

When Windows 95 loads, it uses many of its own high-performance 32-bit device drivers to talk directly to most standard devices and motherboard resources, instead of using slower 16-bit code in the motherboard BIOS ROM. Windows 95 cannot load 32-bit drivers to replace any drivers loaded in CONFIG.SYS or AUTOEXEC.BAT, so some of these (like MSCDEX.EXE) were commented out by the Windows 95 setup program when Windows 95 was installed.

Boot Caught in a Net

A computer with a network card but no disk drives is often called a "diskless workstation" or NC (Network Computer). With hard disk drives so cheap these days, why would anyone want a computer without one? In an environment with many PCs running the same application software and sharing a central database, such as airline reservation systems, a significant amount of money can be saved by leaving out the unneeded local storage devices. Also, any application using highly confidential data may need to keep that data (even data in temporary swap files) in a high-security central storage area, to prevent data theft via stolen computers, stolen hard disk drives, or unauthorized floppy disk copies of the data.

If a PC has no disk drives but does have a network card containing a boot ROM, the code in this network BIOS boot ROM is used to locate a network boot server. Additional bootstrap code is loaded from the boot server and executed. Exactly how this is done depends on the type of network card and the communications protocol, but the result is that a network file server is located and assigned a drive letter as though it was a local disk drive.

This network bootstrap code is similar to floppy disk drive "sector zero" code, and it loads the operating system into memory from the network drive in a manner similar to loading an operating system from a local disk drive.

These days, dedicated diskless workstation network computers can be purchased that have no card slots -- everything needed is built onto a small circuit board (including video and network hardware).

Most of us don’t own NCs or diskless workstations, so we can store all those gigabytes of Internet download files (and web browser cache files) right there on our own local hard disk drives. Those of us who have access to a satellite Internet connection ($19.95 per month DirecPC MoonSurfer II package) know how easy it is to suck a Gig-a-week off the net. Isn’t it great that recordable CD-ROM media only cost about two dollars each (mail order) these days? :-) !

Extreme Booting

My primary computer system has Windows 95 and Windows NT 4.0 both installed. To do this, I booted my PC from an MS-DOS 7.0 boot diskette and formatted the primary (FAT-16) partition of my "primary" hard disk (of seven attached hard disks) from MS-DOS (format /s c:). Then I installed Windows 95 onto the newly-created C: drive. Then I installed Windows NT 4.0 onto the extended NTFS (NT File System) partition of my primary drive.

Immediately after formatting, logical sector zero of drive C: contained MS-DOS bootstrap code. The Windows 95 setup program replaced that logical sector zero with its own sector zero contents after saving the original contents into a hidden file. Then the Windows NT setup program did the same thing to the Windows 95 sector zero contents, resulting in a boot drive physical sector zero, a boot partition logical sector zero, and two hidden "sector zero" files, all containing sequential portions of bootstrap code. Even though Windows NT stores a small portion of its "dual-boot" code on drive C:, the rest of the operating system is stored on the NTFS partition, which has its own drive letter when Windows NT is operating.

When I boot from C: and navigate the boot menus to get a C:> DOS prompt, my PC system first executes motherboard (and other device) BIOS initialization code, then hard disk controller BIOS bootstrap code, then boot drive physical sector zero bootstrap (and partition manager) code, then boot partition logical drive C: sector zero bootstrap (and Windows NT BOOT.INI boot menu) code, then hidden Windows 95 "sector zero" bootstrap (and Windows 95 MSDOS.SYS option processor) code, then hidden MS-DOS "sector zero" bootstrap code, then the MS-DOS operating system code, then CONFIG.SYS device driver initialization code, then COMMAND.COM is loaded to process the commands in AUTOEXEC.BAT, then I get my C:> DOS prompt.

MS-DOS 7.0 is included as part of Windows 95, and is put onto any bootable floppies created with Windows 95. The Windows NT setup program can format unused hard disk partition space into an NTFS partition, which I did.

I chose to use NTFS for the Windows NT installation because FAT-16 typically wastes about one-third of total disk space as slack-bytes at the end of clusters (on a 2 gigabyte partition even a single-byte file consumes an entire 64 KB (kilobyte) cluster, and all files are padded with slack-bytes up to the next 64 KB cluster boundary. I am very disappointed that Microsoft never saw fit to make publicly available any disk compression method or efficient partition format that works for both Windows 95 and Windows NT. I use both operating systems and most of my data sits on extremely wasteful FAT-16 format partitions so I can access it from both operating systems. :-( ! I am sure glad that 4.3 gigabyte hard drives only cost $199 (Best Buy, sale price after rebate). :-) !

Chopped and Channeled Full-Body Massage

I have customized my Windows NT multi-boot menu (in the BOOT.INI file) to clarify menu wording and to shorten the time before automatic selection of the default menu item. To change this file, you must unhide and unprotect it using a DOS command (attrib -r -h -s c:\boot.ini), edit the file, then rehide and reprotect it (attrib +r +h +s c:\boot.ini). My BOOT.INI file is shown below.

[boot loader]

[operating systems]
C:\="Windows 95 or DOS prompt"
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows NT 4.0"
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows NT 4.0 [VGA safe mode]" /basevideo /sos

My Windows 95 startup options (in the MSDOS.SYS file) have also been customized. I shortened the two-second "Starting Window 95" boot delay to zero seconds (BootDelay=0). This delay allows time to press the F8 function key to bring up the Windows startup menu, but is not necessary when a CONFIG.SYS startup menu is used. I also turned off auto-loading of Windows 95 (BootGUI=0), so the DOS command win is needed to start Windows 95. To change the MSDOS.SYS file, you must unhide and unprotect it (attrib -r -h -s c:\msdos.sys), edit the file, then rehide and reprotect it (attrib +r +h +s c:\msdos.sys). My MSDOS.SYS file is shown below, with lots of extra lines of Xs (required for compatibility) not shown.


;--- BootDelay defaults to 2 secs (0 okay with config.sys menu)
;The following lines are required for compatibility with other programs.
;Do not remove them (MSDOS.SYS needs to be >1024 bytes).
;xxx<excess baggage not shown here>xxxz

My CONFIG.SYS file has another boot menu, and loads device drivers as needed. This lets me just load Windows 95 as usual, or boot to a DOS prompt or load Windows 95 with various extra 16-bit device drivers not needed for normal operation. My CONFIG.SYS file is shown below.

menuitem=win32,Windows 95
menuitem=command,DOS prompt
menuitem=datman,Windows 95 & 16-Bit SCSI Drivers for Datman Tape Drive T:
menuitem=imgstar,Windows 95 & MSCAN.SYS for Microtek ImageStar program
menuitem=winice,Windows 95 & Soft-Ice 95

;--- force himem.sys to load before emm386
;--- emm386 & dos= needed for dos scandisk on windows (OSR2) restart
device=c:\win95\emm386.exe noems

;--- mscan needed by Microtek ImageStar scanning software
device=c:\bin\mscan.sys 240

;* The Datman software emulates a 1 GB floppy drive on DAT tape. The current
;* version of Datman requires 16-bit ASPI drivers. Unfortunately, the current
;* version of Windows 95 requires that SCSI drivers must be either all 32-bit
;* or all 16-bit. Therefore, we need to load 16-bit ASPI drivers for all SCSI
;* controllers, and a 16-bit ASPIDISK driver for disk drives not supported by
;* BIOS, and a 16-bit ASPICD driver and MSCDEX for CD-ROM support.
;* Loading the ultrastor 14f aspi driver after the ncr aspi driver does not
;* work, but loading it before the ncr driver redefines the drive letters of
;* all drives on the ncr controller. Are we having fun yet?
;--- load ultrastor 14f aspi driver
;--- load ncr/symbios aspi driver
;* Datman uses advanced ASPI features that are not stable in Symbios drivers.
;* Use older NCR drivers instead.
;--- load aspidisk driver
devicehigh=c:\scsi\aspidisk.sys /d
;--- load aspicd driver
devicehigh=c:\scsi\aspicd.sys /d:scsicd00

;* MSDOS.SYS must have BootGUI=0, or Windows will always load
;--- load ncr/symbios SCSI CD-ROM drivers
devicehigh=c:\scsi\aspicd.sys /d:scsicd00



My AUTOEXEC.BAT file has conditional tests and branches based on the CONFIG.SYS menu selection (stored in the CONFIG environment variable -- environment variables may be defined or viewed from the DOS prompt with the SET command). When the "DOS prompt" item is selected in the CONFIG.SYS menu, my AUTOEXEC.BAT file loads MSCDEX.EXE to assign a drive letter to my SCSI CD-ROM drive, then it exits to the DOS prompt (assuming that MSDOS.SYS BootGUI=0). When any CONFIG.SYS menu item is selected that needs to load Windows 95, then my AUTOEXEC.BAT executes a win command to load and run Windows 95. My AUTOEXEC.BAT file is shown below.

@echo off
rem --- proagio mouse driver must be loaded first
lh c:\proagio\msc3d\
rem --- if no menu, default to Windows 95
if %config%*==* set config=win32
set blaster=a220 i10 d0 h5 p330 e620 t6
set temp=c:\temp
set tmp=c:\temp
set path=c:\win95;c:\win95\command;c:\bin
set mvid=vga
set videoblst=c:\vblaster a2ad6 i11
rem --- fdmouse enables graphics tablet mouse emulation
lh c:\bin\fdmouse gtcodp com2
rem --- setcrt adjusts video frequencies
lh c:\hercules\setcrt c:\hercules\62khz_ss.crt
goto %config%

lh c:\datman\datmanfe -VU
goto win32

lh c:\win95\command\mscdex /d:scsicd00 /s /l:z
goto exit

rem --- winice loads SoftIce95 and Windows 95
goto exit



rem --- MSDOS.SYS must have BootGUI=0, or Windows 95 will always load

Specific details of the inner workings of all the options, commands and parameters contained in these files is beyond the scope of this article, and looking them up will be left as an exercise for the reader. :-) ?

All Right, What Have We Done Now?

Hopefully, we have learned how to make our PCs a bit more friendly, so we don’t have to keep commenting out and uncommenting lines in our CONFIG.SYS and AUTOEXEC.BAT files, or hitting the F8 function key during the "Starting Windows 95" message (or pressing the Reset button after hitting F8 too late) every time we want to do something a little different.