原本的启动是从img启动的，并且这个img是用FAT12文件系统进行格式化的（详细去搜索FAT12文件格式，这里给大家推荐一篇http://www.doc88.com/p-646605198560.html），那么也就是说我们的img文件符合FAT12文件系统的格式了。接下来我们用winhex这个软件来查看我们的img文件，同一时候比对FAT12文件系统的格式，看是否我们的img文件同FAT12文件系统描写叙述的同样：
从上图中能够看到里面有一个haribotesys的文件夹项。那么我们看看我们的U盘里面是否存在这个文件
从上图能够看到U盘里面确实存在HARIBOTE.SYS这个文件，说明我们的U盘在利用fdisk来拷贝img文件的同一时候就已经被FAT12文件系统格式化了，那么也就是说window下我们的U盘的大小应该为1.44M了，尽管在window下我们的U盘显示的是1.44M（这个高级格式化的结果，高级格式化是将U盘格式化为特定的文件系统格式，我们的U盘被FAT12格式化了，那么window就会以FAT12文件系统定义的信息来计算大小）。可是实际上我们的U盘还是4G的（这个是低级格式化的结果，4G的计算是依据U盘的head(磁头)、sector(扇区)、cylinder(柱面)来计算的。这个计算与文件系统无关）。
那么以下的文件夹信息是怎么写到img文件里的呢？这个就得去看看Makefile了。事实上在Makefile中进行拷贝的时候主要做的工作是FAT12文件系统格式化（wbinimg src:ipl.bin len:512 from:0 to:0 ），这个时候img已经被FAT12文件系统格式化了，接下来的文件拷贝的操作就会自己主动的改动FAT的位图、文件夹等相关控制信息。然后接着是文件的拷贝（copy from:haribote.sys to:@:）这个过程事实上就是一个简单的文件的拷贝过程。当然文件的拷贝过程自然会改动文件系统的相关控制信息了。
从上面的解说，再结合前面我写的的文章——怎样制作从U盘启动。能够总结出来。假设在开发过程中没有遇到启动扇区的改动（也就是说ipl.nas）的改动的话。那么能够将生成的haribote.sys直接的复制到U盘就可以，都不用fdisk来进行拷贝了，这样是不是更加的省事了呢。
好了，今天的文章的内容就这么多了，接下来我会结合《30天自制操作系统》这本书和linux0.01的源码来对操作系统进行分析。