Next Previous Contents

14.5 System booting procedures

MS-DOS 6.22 and Windows 98

DOS boot sector (either on the partition itself or in the diskette boot sector) is loaded to 0000:7C00 and then jumped into it. This boot sector doesn't make any assumptions about its initial registers. Boot sector will reset the FDC controller (Windows 98 only when booting from the floppy).

Then it correctly calculates the first sector of the root directory entries list and also the first sector of data zone (where the clusters reside). It will use "hidden sectors" field of the partition boot sector to correctly offset the whole partition for physical disk reads. Exact calculations come out from the information found in:

MS-DOS 6.22:

Zone of bytes 003..03D inclusive

Windows 98:

Zone of bytes 003..03F inclusive

MS-DOS 6.22 specifics

MS-DOS 6.22 loads only the first sector of root directory. It checks whether the very first two entries are "IO.SYS" and "MSDOS.SYS", in this order. Only the exact 11 bytes of each name are compared. When it matches, it will read the cluster number of IO.SYS file and recalculate it to the sector offset on the disk. As the last action it will read the first 3 sectors from this offset to 0070:0000. CPU is then jumped to 0070:0000. The loader contained in the first 3 sectors of IO.SYS then expects some registers already prepared and the root directory sector read at 0050:0000. First touches of FAT are done in IO.SYS.

All reads are done through INT 0x13:AH=0x02 so all accessed sectors of all filesystems have to be accessible by standard BIOS (below 8GB BIOS limit). No LBA32 calls are implemented.

Summary of the requirements:

Windows 98 specifics

Please honour in the following text always correctly the difference between FAT32 (support for disk partitions larger than 2GB) and LBA32 (support for accessing data on disk above approx. 8GB limit)!

Windows 98 scan the whole root directory, through all of its sectors up to the first 0 byte found in the first character of any directory entry filename (which generally ends the entry list anyway). The scan is done in two phases: First phase is for "WINBOOT.SYS", the second (due to possible failure of the first phase) is for "IO.SYS". This boot sector will generally make no differences in loading techniques of these two files.

On successful filename match it will read the cluster number of it and recalculate it to the sector offset on the disk. As the last action it will read the first 4 sectors from this offset to 0070:0000. It will check whether the first two characters are 'MZ' and also it will check for 0x424A (big-endian notation) on 0070:0200. CPU is then jumped to 0070:0200. The loader contained in the first 4 sectors of IO.SYS was not analyzed but it generally doesn't make any further requirements on files distribution on the disk. First touches of FAT are done in the chosen file loaded.

Although even in Windows 98 boot record exists filename for "MSDOS.SYS", the code really doesn't use it in any way. It was probably left there to keep some sort of compatibility with broken third party disk management software.

In the FAT32 boot record is also entry "Backup Boot Sector" Please take care during modifications that this sector-relative offset of the copy of the boot record refers to the whole 4 sectors:

  1. The boot record itself containg boot code and filesystem parameters
  2. Info sector containing only free clusters count and "next cluster to use"
  3. Secondary code of boot sector containg, used for LBA32 hard disk partitions
  4. Usable as the store for long secondary boot sector code etc., currently zeroed

Generally the whole chosen .SYS file is read through INT 0x13:AH=0x02 (standard BIOS - accessible only the first 8GB of physical disk). (The previous sentence is described in detail in the following Bug in Windows 98 IO.SYS section). All other reads (the filesystem access, including "COMMAND.COM") are performed depending on the partition type:

old ones

(without LBA32 marked filesystem type, e.g. 0x1, 0x4, 0x6 or 0xB) are limited to the first 8GB by BIOS

new ones

(LBA32-marked filesystem type, e.g. 0xC or 0xE) are not limited by any capacity. The whole partition is accessed by INT 0x13:AX=0x4200 - so called Enhanced BIOS packet calls: http://www.phoenix.com/products/specs.html

Summary of the requirements:

Bug in Windows 98 IO.SYS

The original goal of Microsoft was probably to leave the BIOS limitation only for the first 4 sectors of the chosen .SYS file (to not to require BIOS-accessible the whole file). If you specify 0xC or 0xE value in the third byte of the boot record (standard value is 0x90 - NOP instruction), the whole rest of .SYS file is read correctly by LBA32. Unfortunately the system doesn't recognize partitions with such changed 0x90 byte and due to this fact even COMMAND.COM is not readable in such situation. I see this behaviour as evident bug - if you have some better explanation/fix, please contact the team.

We supply a fix for this bug (although the bug is not serious, of course). The 0x90 byte (on offset 0x002) leave as it is, just modify two bytes in your IO.SYS file: on offset 0x5F2 set the bytes 0x80, 0x7E to the bytes 0xEB, 0x0A. Generally this should apply to all Windows 98 variants, to be sure check the bytes around:

orig. @0x5F0:

75 2E 80 7E 02 0C 74 06 | 80 7E 02 0E 75 22 33 F6

fixed @0x5F0:

75 2E EB 0A 02 0C 74 06 | 80 7E 02 0E 75 22 33 F6

Already checked variants are provided below:

Windows 98 US

Length 222390, orig. md5sum "4823258556ae481a19015c22e33e8a9e", fixed md5sum "c6cbf356b13b963a354954f1f3d595a9".

Windows 98 CZ

Length 222390, orig. md5sum "aebf26a7fc32aa0d740ab1a3b539637a", fixed md5sum "d71b96afa511af4dd6f1d058a0ff71d6".


Next Previous Contents