Boot of the operating system

Source: Internet
Author: User

The system boot link is the most important link in the process of operating system startup, and it is also one of the most easily problematic links. In accordance with the hardware standards of personal computers, the boot link occurs after the computer hardware system has been detected. The specific boot work is done by the BIOS. The BIOS maintains a list of hardware devices that can be used to boot the computer, such as a local hard drive, a local optical drive, a network, a USB interface device, and so on. The BIOS will attempt to check its status and boot capabilities from the first device of the entire sequence. For example, for the optical drive, you will first determine if there is a disc in the optical drive, if it does not exist, skip the optical drive device, into the next device detection process. If a disc is found to exist, try to read the first sector of the disc and check if this is a bootable sector (for example, by checking that the last two bytes of the sector are 0X55AA). If the discovery is not a bootable sector, it also skips the disc and then checks the next device in the boot sequence until a bootable sector is discovered. If you traverse the entire boot device list and no bootable sector code is found, the boot process fails and the BIOS prompts you to not find the bootable device. If a bootable sector can be found during this process, the BIOS loads the contents of the sector into memory and jumps to that sector to execute the boot code. This jump instruction, is the BIOS program in the computer startup process of the last instruction, so far, the work of the BIOS is completed. Subsequent work will be done by the boot sector code.

Thus, the role of the BIOS in the computer boot process is very important and complex. But because of its independence from the implementation of the operating system, not our focus on the scope of analysis. In this article, we focus on analyzing the boot sector that was loaded into memory and started the process after the execution. This process is a function of the operating system, and is the first part of the operating system life cycle. This article will take the hard disk as an example, first analyze the logical structure of the hard disk and the role of the Master Boot Record (MBR), and then analyze the different file systems, operating system boot sector functional differences and implementation differences, as well as the functional shortcomings of each implementation. Finally, a kind of Guide program making method, which overcomes these defects, is presented, and the application of this method is illustrated with the example of the bootstrap program of Hello China operating system.

The logical structure of hard disk and the function of boot sector

The hard disk can be logically understood as a linear array, and the elements of this array are sectors. Each sector is numbered according to its location on the hard disk, and the first sector is the famous MBR (main boot area, master boot Record).

For administrative convenience, a hard disk can be divided into logical partitions, each of which occupies a portion of contiguous storage space on the hard disk. In general, the location and size of the partition on the hard disk can be described by its starting sector area code and the number of sectors on the hard disk. The current implementation is, a physical hard disk, the maximum can be divided into four partitions, the location of the partition, size, attributes and other information, recorded in a linear table of only four elements, this table is the partition table.

The partition table is stored in the MBR and is located at a fixed location in the MBR. Because in general, the capacity of each sector of the hard disk is 512 bytes, and if the partition table is not fixed in the MBR, the contents of the partitioned table cannot be explicitly read. But the partition table is not the only content of the MBR, and the MBR also holds the boot sector code. After the BIOS discovers a bootable hard disk, it reads the MBR code into memory and then jumps to the beginning to execute. It is necessary to note that the MBR code is generally OS-independent. This may cause some confusion, as explained below.

The operating system is installed on the partition of the hard disk, at least until now, I do not know which operating system, do not partition the hard disk (or the entire hard disk as a partition), and directly installed. The operating system itself-specific boot code is placed on the first sector of the partition on which it resides. For example, a hard disk is divided into two partitions, the starting sector area code for a partition is 2 (MBR's sector area code is 1), and the number of sectors is M. The starting sector area code for another partition is m+2, and the number of sectors is N. Assuming that the first partition is installed on the Windows operating system, the second partition is installed on a Linux operating system. Thus, the boot sector of the Windows operating system is 2 physical sectors (the first sector of the first partition), and the boot sector of Linux is the m+2 physical sector. Obviously, these two (2nd and m+2) boot sectors are strongly related to the operating system.

But the BIOS originally read in the MBR. Once you jump into the MBR execution, the BIOS is gone. At this time, the code on the MBR must be able to find the boot sector of Windows or Linux and read them into memory to complete the boot of the appropriate operating system. So the MBR function code itself, need to complete two issues of decision:

1, there are multiple partitions on the hard disk, each partition has the possibility of installing the operating system, how to select a partition to continue booting?

2. If a partition is determined, how can I get the physical location of the boot sector of this partition (that is, the number of sectors on the entire physical disk)?

Obviously, the second problem is easy to solve in the case of the first problem. Because this time the partition number is determined, just read the partition table and find the corresponding record, you can read out the partition's first sector number, this is the boot sector. For the first issue, it is resolved by setting an activity flag in the partition table. Each partition table entry (corresponding to a partition) has one byte, which is called the activity flag, and four partition table entries must have only one partition of the active flag set, which is the active partition. The operating system installed on this partition will be booted. Specifically, who will set this flag? The answer is the operating system. When the operating system is installed, you will be given the option to install partitions (such as Windows, which will list the partition of the hard disk, denoted by C:, D: And so on). Once a partition is selected, Windows Installer sets the active flag of the partition table entry for that partition to 1, while clearing the activity flags of the other partition table entries.

Under this rule, the last operating system installed will often "suppress" the previously installed operating system, making the previously installed operating system unable to boot. But as soon as we know the process, we can change the situation with some tools. For example, you finally installed the Windows operating system, after booting to the Windows operating system, you can run on the Windows operating system tools, the Linux operating system is located in the partition to the active partition. This will enable Linux to be booted at the next boot. For security reasons, however, the operating system provides protection for the MBR and cannot be written directly to the MBR. This is a hassle, and once you install Windows, it means that the original Linux (with the newly installed Windows in different partitions) is not available. However, this is not absolute, such as the operating system can be booted through the CD-ROM to modify the MBR. Alternatively, you can install Hello China on the win partition and help you complete the work of modifying the active partition flag by Hello China.

Once again, the MBR selects a partition based on the active flag and determines the operating system boot sector based on the partition starting position in the partition table, then reads the sector into memory and jumps to the starting position to continue execution. This shows that the MBR itself is not related to a particular operating system. In fact, the executable code of the MBR sector has not changed since the start of DOS.

A physical hard disk has a maximum of four partitions, and some software companies, such as MS, think this is not enough. A technique, called an extended partition, was invented. The extended partition is essentially a hard disk partition (one of four partitions), but on this basis, it is further expanded to subdivide a partition into smaller partitions (these smaller partitions are called logical partitions), which is the structure of the partitioned partition. As with the MBR of the hard disk, information about the logical partition is recorded on the first sector of the extended partition. However, unlike normal partitions, logical partitions on an extended partition cannot boot the operating system, that is, the operating system cannot be installed on a logical partition. Since the operating system cannot be installed on a logical partition, it must not be installed on the extended partition. Because an extended partition is a "container" for a logical partition, there is no space on its own to store operating system files. Therefore, to install the operating system, you must install it on a normal disk partition. In order to show the features of this "accommodating" operating system, ordinary partitions are also dubbed "Major partitions".

At this point, here are some concepts or principles that you should be aware of:

1, MBR and partition table;

2, the code on the MBR is independent of the operating system;

3, the operating system-specific boot sector, is the first sector of its installed partition;

4, the district activity mark;

5, the main partition, extended partition, logical partition;

6, MBR and operating system boot sector relationship.

Functions and limitations of the boot sector of the operating system

We then shifted our gaze to the operating system boot sector, the first sector of the partition where the operating system resides. The operating system boot sector is closely related to the operating system, and its main function is to locate the boot operating system kernel-related files on the operating system partition and complete the loading of the operating system. The "Boot operating system related files", which is said here, can be either an operating system core module or some executable code to prepare for further booting the operating system core module. After all, the modern operating system is very complex, the core module is very large, unable to directly complete the boot. This may have some auxiliary boot modules, after all, the function of the boot sector code is very limited.

However, the code for the boot sector must find a module (actually a file) in the file system of the partition where the operating system is located, and load it into memory. So the following two functions are the core of the boot Sector code:

1, on the partition of the file system, to find a specific file;

2. Load this file into memory and jump to execute.

The second task is relatively easy, in general, the boot sector is still running in the CPU real mode (for example, PC), you can call the BIOS provided by the disk read and write service, it is easy to read the file into memory. The key is the first job, how to search a file system for a specific file. Actually "search for a file" is not the key, the key is how to "a Sector" of the code, in a complex file system to find a desired file. Here are two factors that form a pair of contradictions:

1, the boot Sector code size is limited, such as only 512 bytes, can not adapt to complex computing requirements;

2, the file system structure is complex, access to the file system requires a large amount of code.

The boot sector needs to be well balanced against this contradiction so that the boot process can continue. In general, there are several ways to solve this problem:

1, expand the boot sector size. It is generally assumed that the boot sector of the operating system is 512 bytes, and the initial boot of the operating system is entirely done by this 512-byte code. In fact, many operating systems, such as windows, have greatly expanded the boot sector size. Since the entire partition is the site of the operating system, how each partition is used is entirely determined by the operating system. The boot sector is the first sector of the partition, which cannot be changed. Then I can totally take the second and third 、... The nth sector also acts as a boot sector. The first sector is just a springboard, after the MBR reads the first sector into memory and runs, the first sector then reads the successive slices of the back into memory, all of which collectively form the boot module. This way, no matter how complex the file system is, I can install the code that accesses the file system by allocating several more sectors. Obviously, this approach is effective and widely used. For example, the Windows operating system, on the NTFS file system boot sector, there are 16 (0~15 sector), there is 8 K of code space. This is sufficient to parse the NTFS file system and read the boot file (such as NTLDR);

2, the boot sector remains unchanged, but the location of the fixed operating system core or related files on the disk. Or that sentence, the whole territory is mine, I would like to arrange who can be anywhere. The operating system can pin the boot-related code to a specific location on the disk, such as the 1024th sector location. This way the boot sector does not have to analyze the file system, just read the operating system core directly from the 1024th sector section. This strategy seems to have been used in the DOS era. Remember when I was in college, I made a DOS boot floppy disk with Io.sys and other files on it. Once the Io.sys file deleted, and re-copied a go in, the result can not start DOS. Presumably, DOS may have fixed the Io.sys on a floppy disk. Once the copy is deleted, its position changes, which leads directly to the inability to boot.

Both of these solutions have their limitations. In the first scenario, it is valid to install only one operating system on a partition, or to install different operating systems from the same software vendor, but if you install two different vendor operating systems, there may be a problem. Assuming that both operating systems A and B are using the first strategy, A is first installed on the partition. In the second operating system B installation, in order to be able to boot a system at the same time, B will be a boot sector (the first sector) back to a file (such as the Windows System Bootsect.dos), and then put their own boot sector (possibly several consecutive) to the beginning of the partition. So the a operating system except the first boot sector, are covered by B. Obviously, it is not possible to boot a system again at this time. But if both A and B are products of the same software company, such as the Windows 98 series and the Windows 2000/XP series, because Microsoft is developing, the structure and number of boot sectors are known, so that when you install XP or a later OS on Windows 98, Later versions of the OS (such as XP) package all boot sectors of the original system into a single file, so there is no overwrite problem. If there is still a problem with this package (for example, the first sector calls the BIOS service to read the subsequent sectors, even if it is packaged and cannot be changed), XP even modifies the packaged boot sector files. The key here is that the latest version of the operating system, the original version of the operating system can be recognized, and to make effective processing.

The disadvantage of the second scenario is that it requires good support from the file system. For example, you fixed a location of a file and asked that location not be changed (unless the file was deleted), which would require the file system not to arbitrarily change the file location (or for the operating system files to do separate processing), otherwise this method will be invalidated. This is obviously harsh, and the result is that the file system cannot change the location of the existing files, causing a lot of disk fragmentation. Commonly used file systems, such as FAT, NTFS, ext, etc., do not provide this functionality. Therefore, the scope of application of the second scheme is very limited. Only some of the early operating systems will be used, most of the current operating systems are designed with the first scheme.

At this point, here are some concepts or principles that you should be aware of:

1, the boot sector of the operating system may be more than one;

2, for Fat32/ntfs and other complex file system, need multiple boot sector to fully accommodate the boot code;

3, can be fixed operating system core files on the disk location, to ensure that the boot code only a sector;

4, different manufacturers operating systems are difficult to coexist in the same partition reason.

So, does that mean you can't install different operating systems on the same partition as the manufacturer? I think the answer is no, we can use some design to effectively coordinate the operating system of different vendors, and coexist harmoniously on the same partition. In the design of Hello China operating system, a strategy called "preset guidance Method" is adopted, which effectively avoids the above two problems.

The overall idea of the preset boot method is to read the physical location of the operating system core module on disk and write directly to the boot sector when the operating system is installed, according to the actual hard disk's file system. When booting the operating system, the boot sector does not need to analyze the file system and determine the location of the core files of the operating system, as long as the files are located in the physical location on the disk from the pre-set location in the boot sector and loaded into the memory. As can be seen, the pre-boot method has a prerequisite: once the operating system core file is written to the hard disk, its location cannot be changed. Because the location of the core file on the disk, it is written to the boot sector. If the location of the file changes, it still fails to boot. This is obviously also harsh, with the same restrictions on the location of the fixed operating system on the disk (but this is fundamentally different, the pre-boot method requires that the operating system core files are located on the disk, the location is not fixed, the location is determined when the file is copied to disk. Fixed operating system core module in the disk-specific location of the practice, is to require the system files must be located in a fixed location of the disk, such as 1024 sectors start.

We can use some strategies to improve the preset guidance method, so that the method can avoid the above limitations. The overall improvement strategy is to dynamically generate (or dynamically configure) the boot sector content at the time of the operating system installation, to write the data that can be fixed to the boot sector beforehand, to avoid the boot sector to calculate these parameters on its own, thereby reducing the amount of code in the boot sector. For example, most boot sectors need to calculate the size of a cluster, based on the number of bytes per sector multiplied by the number of sectors per Cluser. Obviously, when the operating system is installed, the size of the cluster is fixed. Therefore, a variable (cluster size) can be set directly in the boot sector and written to the cluster dimension value. This way, the boot sector does not have to calculate the size of the cluster and can be referenced directly. This method can greatly reduce the amount of boot sector code.

The following is an example of a Hello China operating system boot program, for different file systems, to illustrate the design of the pre-boot method.

Implementation of preset guidance method on FAT32 file system

Obviously, the FAT32 file system is a relatively complex file system, a boot sector space, and it is difficult to load the full boot code, because even if the operating system core file is placed in the root directory, you need to search the entire root directory, locate the operating system file, and load the file. This process requires about two sectors of the code volume. However, by pre-placing some variables into the boot sector, the boot sector size of the FAT32 file system can be greatly reduced, allowing it to be accommodated in a boot sector. For example, the following is the layout of the standard boot sector:

Field Name field Offset field length meaning

Bs_jmpboot 0 3 Jump Code

Bs_oemname 3 8 OEM Name

Bpb_bytspersec 11 2 per sector length (bytes)

Bpb_secperclus 13 1 Number of sectors per cluster

BPB_RSVDSECCNT 14 2 Reserved Sector number

Number of Bpb_numfats 1 FAT16

BPB_ROOTENTCNT 17 2 How many root directories are there?

BPB_TOTSEC16 2 FAT32 Obsolete

Bpb_media 21 1 Media type

Bpb_fatsz16 2 FAT16 file allocation table length

BPB_SECPERTRK 24 2 Number of sectors per track

Bpb_numheads 26 2 head count

Bpb_hiddsec 28 4 Number of hidden sectors

BPB_TOTSEC32 32 4 Partition Total Sector number

......

This is then the executable boot code.

Obviously, much of this information is useless, especially on FAT32 file systems. such as BPB_TOTSEC16 variables. When configuring the boot sector, we can omit these variables to free up more space to arrange the boot code so that the parsing function code of the FAT32 file system can be placed in a sector. Here is the boot sector structure after "preset" Processing:

; 3-byte Jump instruction

JMP short _boot_code; Jump to the real boot code

NOP; NULL instruction to guarantee a byte count of 3

SectorsPerCluster DB 00; Number of sectors per cluster (1 2 4 8 16 32 64 128)

Reservedsectors DW 00; The number of reserved sectors starting from the first sector of a volume;

Numberoffats DB 00; The number of FAT data structures on the volume, which should typically be 2

HiddenSectors DD 00; Number of hidden sectors before the partition containing the FAT volume

SectorsPerFAT32 DD 00; For FAT32, the field contains the size of a fat

Rootdirectorystart DD 00; The starting cluster number of the root directory, usually 2;

Drivenumber DB 00; Drive letter for int 0x13, 0x00 to floppy, 0x80 to hard disk

Then follow the real executable code.

This pre-set saves about 20 bytes of space, and many of the variables have been preset (these are preset variables, called preset variables), without calculations (such as cluster size). If you follow a traditional boot sector, you need to schedule specialized code to calculate these variable values. This is combined to save about 60 bytes of space. Do not underestimate these 60 bytes, in the assembly language implementation of the boot sector, 60 bytes can be implemented to analyze the FAT32 root entry function, which is the core function of the FAT32 boot sector.

At the same time, you can optimize the boot sector code, omit some unnecessary judgments. For example, int13 call function, the basic BIOS now provides this functionality, there is no need to determine whether the BIOS support INT13 call. At the same time, because the operating system is running on a 32-bit CPU, the data processing range can be increased by using 32-bit registers of the CPU (such as EAX, EBX, etc.) and 32-bit instructions to conserve the amount of code.

The implementation process is to provide a disk analysis tool to read or calculate preset variables such as the size of the cluster during the installation of Hello China, and then write to the boot sector.

After the above measures, Hello China implements the function of booting the operating system on the FAT32 file system within a boot sector. Typically, these functions need to be implemented within more than two sectors.

This implementation method does not require the operating system core files on the hard disk fixed location. Although some variables have been preset, but the boot process has not changed, the boot sector is first read into the root directory, the root directory to search the operating system core files. Locate and then query the Fat table, locate the operating system core files on the disk, and then read them in turn. Therefore, even if the location of the operating system core files is constantly changing, it does not affect the loading of the operating system. Obviously, this "preset guidance method" overcomes the problem that the boot sector of the operating system is too large, and avoids the disadvantage of the fixed operating system core file location.

Implementation of preset boot method on NTFS file system

Compared to Fat32,ntfs is a more complex file system. We can barely plug FAT32 's boot code into a sector by using the pre-boot method, but this is absolutely impossible for NTFS. In MS's Windows-series operating system, the boot sector of the NTFS partition has a total of 16 (that is, it requires 8K of code space to boot the operating system files on NTFS). Therefore, you can use the preset guidance method only further.

The most thorough use of the preset boot method is to write the location and distribution of the operating system core files on the disk to the boot sector. The boot sector does not make any file system-related parsing code, directly reading the disk partition based on the data being written. For example, the layout of the operating system core files stored on disk is as follows:

Number of start sector area code sectors

2048 512

4096 512

8000 256

That is, the operating system core file is divided into three parts of the disk storage, the first and second parts occupy a contiguous 512 sectors, the third part occupies a contiguous 256 sectors. It can be calculated that the size of the operating system core file is 640K. The above table can be written directly to the boot sector. For example, the following is the code for the start section of the boot sector:

JMP short _boot_code; Jump to the real boot code

NOP; NULL instruction to guarantee a byte count of 3

StartSectNum1 DD 00

SectorCount1 DD 00

StartSectNum2 DD 00

SectorCount2 DD 00

STARTSECTNUM3 DD 00

SectorCount3 DD 00

Then follow the real boot code.

Once the operating system is installed on an NTFS disk partition, the location of the operating system core files is fixed (that is, described in the table above). This can be done by a tool software that reads the location information of the operating system core files and then writes to the location of Startsectnum and Sectorcount in the boot sector. Such a real boot sector code, no need to do any NTFS file system analysis work, just based on the information at Startsectnum and Sectorcount, the corresponding sectors read into memory. Obviously, such a preset variable and disk read code together, can never exceed 512 bytes.

But the problem with this processing is also obvious, is to require the operating system core files on the disk location must be fixed. Once the file system moves the location of the operating system core files, it cannot be booted. Obviously, this is almost impossible for the NTFS file system. To fully avoid fragmentation, NTFS may periodically scan and defragment the file system, and link the discontinuous disk space by moving the file on the disk in a specific location.

In order to avoid the problem of not being able to boot due to the change of file location, we need to take a step further and write more stable content to the boot sector. To find out more stable content, we begin by analyzing the NTFS file system principle. It is important to note that the NTFS file system content is very large, where only a few key concepts are described. For detailed NTFS file system information, refer to the NTFS file specification and other relevant information.

In the NTFS file system, the exact location of any file on the partition is recorded in the MFT (Master File table). The starting position of the MFT itself is stored in the boot sector. When working with the NTFS file system, the operating system first obtains the location of the MFT from the boot sector of the NTFS partition, and then reads the contents of the MFT. For any file lookup, NTFS also searches the MFT based on key fields such as file names (in effect, starting from the root), locates the corresponding file records, and then obtains the location where the files are stored on disk (NTFS is called Data Run, which runs in the database). Once a file is created or copied to disk, the NTFS file system code allocates a record in the MFT that records information about the file. For us, the location information of the file is the most critical. In general, the location of the file record in the MFT is fixed. At the same time, the location of the MFT itself is fixed (although in theory, the MFT itself may not be fixed, but the implementation of the general NTFS file system, the location of the MFT is fixed). Even if the file itself is moved, the NTFS file system code simply modifies the file's MFT record, or, more specifically, the data run property in the file record, which reflects the most recent location information for the file within the partition.

Therefore, from the above analysis, as long as we have the operating system core files corresponding to the MFT record in the sector pre-placed in the boot sector, can guarantee that no problem. Assuming that the operating system core file is moved, the NTFS file system code modifies the corresponding MFT record, and the MFT record itself is in a location that does not change.

Based on this principle, the preset boot method on the NTFS file system, pre-placing the boot sector is the location of the MFT record in the operating system core file. In this way, the boot sector simply reads the MFT record of the operating system file according to this preset location, then reads the data of the file from the record (that is, location information), analyzes the data run, and loads the operating system files.

The Hello China operating system boot program on the NTFS file system is implemented in this way. In Hello China's setup program, The installer first copies the operating system core file (Hcnimge.bin) to the root of the NTFS partition, then runs an NTFS file system analysis tool, reads the Hcnimge.bin file corresponding to the MFT on disk, and then writes the sector code to the boot sector preset variable. When booting the operating system, the boot sector only needs to read the corresponding file records according to the provisioned disk sector number, then find the data running according to the file records, analyze the data to run, and read the Hcnimge.bin.

Even so, it is a bit difficult to implement the boot program for the NTFS file system in a 512-byte boot sector. The decoding program that runs the data is a bit complicated and takes up most of the code space.

Description of the Hello China Bootstrapper Implementation Code

The boot programs for the FAT32 and NTFS file systems in the V1.69 version of the Hello China operating system are implemented by the preset bootstrap method. You can get a further understanding of this article by reading the source code of the bootstrapper. All code (including the Hello China operating system core module code) can be downloaded via the following links:

http://download.csdn.net/detail/hellochina15/3846735

The source files associated with the bootstrapper are described below:

1, FAT32 and NTFS file system Boot Sector code (assembly language writing), stored in the Sysinit directory. Hdbs. ASM is the boot Sector code for the FAT32 file system, Ntfsbs. ASM is the boot sector Code of NTFS;

2, Dumpf32 directory, stored the FAT32 file System Boot Sector modification program. The program reads the information about the installation partition and then writes to the boot sector program;

3, Mkntfsbs directory, storage of the NTFS file system Boot sector modification tool. The tool parses the root directory of the Hello China installation partition, finds the disk sector number of the file record for the Hcnimge.bin (operating system core module), and writes to the boot sector. Other preset variables, such as cluster size, are also written.

If you have any related questions, you can contact us to discuss what to ask.

http://www.cnblogs.com/roucheng/

Boot of the operating system

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.