系统引导-引导记录和LOADER

这篇文章说了啥：

    引导记录与LOADER的作用。

基础背景：

    系统引导 - 启动过程

正文

    解决上次留下来的问题："引导记录与LOADER和操作系统玩什么接力赛？直接把控制权给操作系统不就行了？引导记录跟LOADER这么像，有啥区别？"

    在解决这些问题之前，得说引导记录和LOADER分别是什么。了解它们是什么，上面的问题的答案就出来了：

引导记录：

    实际上引导记录有两层

    第一层是存储器级的（硬盘级、软盘级、光盘级……）。主要用于描述存储器的分区情况。每个记录由其前面一个记录定位，第一个记录存放在0磁头0磁道1扇区。这些记录的结尾必须是0xAA55。这些记录叫MBR(Master Boot Record，主引导记录)。说是MBR结构，其实我觉得就不存在什么结构，这个扇区上放的就是长度为512字节的代码，而且这个代码最后两位的二进制编码是0xAA55。只要你的代码能定位并载入下一级的引导记录并且结尾时0xAA55就行。（这是猜测，等把引导问题搞清楚了做实验验证一下）为什么结尾要是0xAA55？我猜是因为BIOS要根据这个标记来判断这个扇区是不是MBR。

    第二层是分区级的（C盘、D盘、E盘……）。主要用于描述该分区的情况。每个分区都有一个，存放的位置由该分区的MBR定位。这个结构就跟文件系统有关系了（也是猜测，需要实验验证）。因为我用的是M$的FAT32文件系统，所以这里的结构是DBR（DOS BOOT RECORD,DOS引导记录）。DBR也是占用一个扇区，在DBR里也要以0xAA55结束，怎么这里也要以0xAA55结尾了？因为MBR里的引导代码也是用这个标记来验证这个记录是不是DBR，如果你不想用这个标记，可以修改MBR里的引导代码（又是猜测，等我实验验证）。文件系统估计就是在这个扇区开始里做的。DBR中的引导代码的任务就是寻找并载入引导文件了。

    结构是这样的，FAT32里MBR和各个DBR组成这样的一个链表结构，每个DBR有它之前的DBR定位，而第一个DBR由MBR定位：

LOADER：

    LOADER其实是个程序文件，它的任务是加载操作系统的内核。也许你要问为什么不用DBR里的引导代码载入系统内核。原因只有一个：引导代码体积有限，能实现的功能也太有限了，载入操作系统前有一些准备工作要做，短短的512字节根本实现不了。用LOADER一个单独的程序就冲破了512字节的禁锢，还有另外一个好处：可以用C语言开发操作系统内核了，只要你在LOADER里实现对C语言编译出来的文件格式的解析就可以了（还是猜测，有待验证）

看到这里开头的三个问题应该都明白了吧。

软盘里MBR和DBR似乎是重合的，我手头没软驱，而且以后估计不会用软驱了，这个猜测就不用验证了。

倒是遗留了一堆猜测等待验证：

1.MBR是一段以0xAA55结尾的代码。不存在什么结构，之所以定义结构是为了设计方便。

2.DBR是M$专用文件系统，不同的文件系统有不同的结构。文件系统的实现就是在这个扇区上开始的。

3.DBR结尾的0xAA55是由MBR中的相关代码决定的，只要修改了相关代码，这个标记可以是其它的数。

4.只要LOADER实现了解码功能，内核就可以使用C语言等高级语言编写。

下次把MBR的研究结果放上来……

下下次把DBR的研究结果放上来……

以上都是个人理解，不保证正确