Valid HTML 4.01 Transitional

OS Boot Tools

Version 3.3 Freeware Edition for non-commercial use: DOWNLOAD.

This tool set is designed for fast, easy and reliable booting of your operating system or one of the existing OS to PC memory from floppy disks, flash-drives, hard drives from partitions MBR, EBR and GPT including that beyond 2TB limit and with file systems FAT12/16/32, exFAT, NTFS, Minix1/2/3, Ext2/3/4, from CD/DVD-disks with file system ISO-9660 and from ISO-images written to the USB flash-drives (USB-ISO) without installing complicated multistage loaders.

Attention! Incorrect or inaccurate usage of this tools may cause problems with booting your work OS!

Windows 98/ME handles 128GiB and larger drives incorrectly.

To work with 128GiB and larger drives under Windows 2K/XP certain updates must be installed and LBA48 support must be switched on in the registry.

Windows XP and preceding OS don't support drives larger than 2TiB.


In spite of existence of complicated boot loaders and boot managers, thus far no any standard for first stage booting from different kind of file systems and drives. That's why an OS or second stage loader developer encounters the complete absence of software that organizes the booting in easy and standard way and immediately faces the task of learning the installation and using of complicated boot-loaders, such as GRUB2, or developing his own first stage loader that will be able to boot the simple OS image file or second stage loader into memory. When solving the task you may encounter common problems:

  • Extreme lack of space for boot code;
  • Lack of space in base memory for kernel image;
  • Variety of device classes and file systems;
  • Necessity to make booting process independent of file system;
  • Hard to debug first-stage boot code;
  • Difficulty of testing loader on a variety of systems;
  • High risk of data loss on manipulation with boot sectors and partition tables on disks;
  • Necessity of learning disk data structures and file systems on early stages of OS development;
  • Necessity to take into account those factors that you even don't know anything about.

This toolset provides complete solution of all these problems with maximum reliability and safety and has a variety of unique features. So, for example, no one set of first stage boot-loaders passes the volume identifier, is not able to boot OS from drives of more than 2TB capacity and at that time doesn't provide the loading of such large files on all supported file systems. Valuable advantages of toolset are full unification of booting process independently of file system used and ultimate simplicity of its usage. Also I've done the best to provide the developers the quick startup tools for their own projects. Nevertheless, it is supposed that the user has at least basic knowledge in assembler, PC functioning, disk structure and file systems.



  • Added support of Microsoft Windows NT4.0, XP/64, WS2003/64, Vista, 7 loaders by mksys utility;
  • Added boot from ISO-image on USB drive (USB-ISO);
  • Added boot from exFAT file system;
  • Added boot from Ext4 file system;
  • Added boot from Minix/Minix2/Minix3 file systems;
  • Added workaround for BIOS bug with incorrect patch of boot disk number in FAT32;
  • Fixed bug in FreeDOS kernel conversion.


  • Added boot from alternative partition in MBR, EBR or GPT;
  • Boot code for linear loading modified for installing to the partition;
  • Added FAT32 boot code with automatic LBA/CHS detection;
  • Fixed bug of loading from far sectors in Ext2/Ext3 or NTFS partitions with size more than 2TB;
  • Fixed bug of loading on some weird BIOSes;
  • Added passing the start of boot partition to the loaded kernel;
  • Added support of GRUB Legacy loader by mksys utility;
  • Added support of GRUB4DOS loader by mksys utility;
  • Added support of SYSLINUX loader by mksys utility;
  • Added support of FreeDOS kernel by mksys utility;
  • Added recognition of Ubuntu-version of GRUB2 loader by mksys utility;
  • Fixed erroneous flags on file creation by Linux version of mksys utility.


  • Added boot code for linear loading of sectors from disk without file system;
  • Added utility for conversion of some foreign loaders to the format adopted by this toolset;
  • Removed necessity to store the EBR code in all logical drives of extended partition, simplified MBR/EBR interface;
  • Increased reliability of detection of native MBR/GPT;
  • Added sanity check of boot drive number in MBR/GPT;
  • Added support of geometrical number of boot partition;
  • kernel.asm:
    • Extended the output of information;
    • Added canonical stack setup in demo-kernel.


  • Added Linux support (boot utility in ELF32 format);
  • Added boot from hybrid systems MBR+FAT;
  • Added boot from Ext2/3 file systems;
  • Fixed set of minor bugs;
  • Fixed error loading large files in FAT12/16;
  • boot.exe:
    • Totally reorganized internal structure;
    • Added possibility to change activity flags without recording boot code;
    • Added possibility to remove activity flags from all partitions;
    • Added possibility of separate recording of MBR and VBR boot code;
    • Provided reliable recording of boot code to the volumes, mounted by system;
    • In device listing added the detailed output of partition structure with flags and attributes;
    • Improved detection of file systems and partition structure.


  • Fixed a series of bugs with loading beyond 2TiB in GPT and VBRs;
  • Increased reservation of space for Extended BIOS Data Area up to 12kiB in VBRs;
  • Fixed set of minor bugs.


  • Added boot from NTFS file system;
  • Added boot from GUID partitions (GPT);
  • Added boot from CD/DVD-ROM ISO-9660 in No Emulation mode;
  • Added support of booting from drives of size more than 2TiB;
  • Added "friend/foe" check in MBR/EBR when passing parameters to next boot sector;
  • In VBRs boot code added usage of passed partition start value upon detection friend MBR/EBR;
  • boot.exe:
    • Added support of NTFS file system;
    • Added support of GUID partition table (GPT);
    • Fixed work with sector other tan 512 bytes.


  • Added boot code of extended partition – EBR;
  • Added support of boot from extended partitions in MBR;
  • LBA detection fixed in FAT12/16;
  • All boot sectors:
    • Fixed work with 256 heads in CHS mode;
    • On loading errors Int 18h is called to meet the requirements of BBS v1.01 1996.
  • boot.exe:
    • Fixed work with 256 heads in CHS mode;
    • Added support of extended partitions.
    • Added selection of active partition (including logical drives on extended partition).


  • VolumeID now passed in EBX instead of CX:BX;
  • Fixed bug with loading large files in FAT32;
  • All boot sectors:
    • Fixed bug with loading on some systems;
    • Added control of upper limit of data loading from file to 620k;
    • Added reading drive parameters from BIOS to allow booting independent of CHS translation method;
    • Code optimized.
  • boot.exe:
    • Added support of Vista/Windows 7;
    • Added support of logical drives;
    • Added lock of file/logical drive when writing boot sector;
    • Improved file system detection.


  • First release.

Package contents

bootUtility for preparing disks and disk images for booting (Linux console executable)
boot.exeUtility for preparing disks and disk images for booting (Windows console executable)
ebr.binBoot code of extended partition
eula_en.txtLicense agreement in English
eula_ru.txtLicense agreement in Russian
exfat.binBoot record for exFAT
ext.binBoot record for Ext2/3
ext4.binBoot record for Ext4
fat12.binBoot sector for FAT12
fat16.binBoot sector for FAT16
fat32.binBoot code for FAT32 with automatic LBA/CHS BIOS access detection
fat32chs.binBoot sector for FAT32 with CHS addressing
fat32lba.binBoot sector for FAT32 with LBA48 addressing
freedos.sysFreeDOS operating system kernel
gpt.binBoot code for GUID partition table (GPT)
grub.sysSecond stage loader GRUB Legacy
grub4dos.sysSecond stage loader GRUB4DOS
hybrid.binBoot code for hybrid systems MBR+FAT
iso9660.binBoot sector for CD/DVD-ROM ISO-9660 in No Emulation mode
kernel.asmSource code of demo OS module
kernel.sysCompiled demo OS module
mbr.binBoot code of disk partition table
minix.binBoot record for Minix
minix2.binBoot record for Minix2
minix3.binBoot record for Minix3
mksysUtility for conversion of foreign loaders to the format of this package (Linux console executable)
mksys.exeUtility for conversion of foreign loaders to the format of this package (Windows console executable)
ntfs.binBoot record for NTFS
rawfs.binBoot code for linear loading of sectors from disk without file system
readme_en.htmPackage description in English
readme_ru.htmPackage description in Russian
syslinux.sysSecond stage loader SYSLINUX
usbiso.binBoot sector for USB-ISO


Files "kernel.asm" and "kernel.sys" are distributed under the terms of free license WTFPL.

Files "freedos.sys", "grub.sys", "grub4dos.sys" and "syslinux.sys" are distributed under the terms of GNU GPL v2 license.

All other files of this package are distributed under the terms of the license agreements in the file "eula_en.txt".

Boot specifications

  1. Maximal simplification of OS installation. Now OS installation is just a simple file copy!
  2. Supported booting from the following file systems: FAT12/16/32, NTFS, Minix1/2/3, Ext2/3/4 and ISO-9660 (both from CD/DVD and USB-drive). Supported all allowed FAT, NTFS, Minix and Ext2/3/4 file system parameters: sector size, cluster size, number of hidden sectors and FAT copies and other parameters. Sector size other than 512 is not yet tested on real hardware. Probable restrictions see in the description of corresponding boot-loaders.
  3. Supported booting from drives partitioned in MBR, GUID partition table (GPT) and hybrid systems MBR+FAT. Supported booting from any active partition including extended partitions. Number of logic drives in extended partition is not limited.
  4. Supported CHS and LBA48 BIOS calls. Unless otherwise stated, the access is selected automatically
  5. Supported boot from beyond 2TB limit.
  6. Supported booting from floppy disks, HDD, CD/DVD-disks and USB storage devices.
  7. There is no limitation on physical placement of image on disk, placement of file name in directory and the file name itself. The only limitation is that the file must be in root directory. Also it is not recommended to choose file name with more than 8 symbols in name and 3 in extension.
  8. The boot-loader loads the specified file into PC memory starting from address 600h.
  9. Supported loading up to 620 kB from file. If the file is larger than 620 kB only first 620 kB will be loaded. If the file is not larger than 620 kB, it is guaranteed that the file will be loaded whole.
  10. Boot-loader gets boot disk number from BIOS in DL. This number is passed to the loaded OS also in register DL.
  11. Boot Volume ID is passed to loaded OS in register EBX, this is for correct boot disk/partition detection for the loading of the rest of OS components. Calculation of ID is separately described for each supported file system below.
  12. If MBR/EBR/GPT boot code used from this package also, then to loaded system in register DH passed the geometrical number of partition, from which the system is booted. The numbering of MBR and GPT partitions begins with 1. Independently of number of primary partitions in MBR partition table, logical drives of extended partition are numbered starting with 5. So, if you have, for example, two primary partitions and two logical drives on extended partition, they will have numbers 1, 2, 5 and 6, correspondingly. If your system is booted from not partitioned disk or used MBR/EBR/GPT boot code from other packages, then register DH will contain 0. Due to register DH has only 8 bits, on booting from GPT partitions number 255 and more, register DH will contain wrong partition number, in this case you need to use Boot Volume ID, passed in register EBX.
  13. Loaded kernel receives 64-bit sector number of the boot partition start in ECX:EAX registers pair. This number may be used for future identification of system volume or for immediate parsing of the file system.
  14. Zero stage boot-loader (MBR/EBR/GPT) passes to the volume boot record the definite set of parameters. Register EAX contains magic number 0x138FC3D2 for determining that the zero stage boot-loader exists and passed valid parameters. DL contains the boot drive number. DH – geometrical partition number in the format described above. Register pair ECX:EBX contains 64-bit sector number on disk from which the partition starts. This number is equivalent to the "hidden sectors" number, which is present in BPB area on some file systems.
  15. Zero stage boot-loaders (MBR/EBR/GPT) provide booting from alternative partition on holding Alt key while system bootup. The method of specifying the alternative partition see in the description of corresponding boot-loaders and "boot" utility.
  16. Right after the OS image file loading, the control is passed to the first byte of image (at address 600h). There are no warranty about register contents (including ALL the segment registers), except for registers EAX, EBX, ECX, DL and DH, which described earlier.
  17. Guaranteed at least 6.5 kB of free memory for stack and data immediately after the loaded image. Correct stack setup see in demo-kernel.
  18. On every boot error there is message displayed to user and awaited pressing of any key. After that will be performed an attempt to boot from other devices in boot chain.

Package contents description

kernel.asm – the source of OS startup sample, written in NASM. You may use this code as a startup for your own project. This sample shows correct initialization and saving the passed values and shows some system parameters. The passed values are shown on the display.

kernel.sys – is the compiled sample. You can just copy this file by any convenient way to the root directory of a volume prepared by the "boot.exe" command (see below) then boot from that disk.

rawfs.bin – Boot code for linear loading of sectors from partition without file system or with an arbitrary file system. For installation to the partition you need to fix three parameters in boot sectors: first sector of the boot partition, number of bytes to load from disk and volume ID that passed to the loaded kernel in EBX register. The first sector number has 8 bytes (64 bits) and is placed in the position 90…97 in little-endian format. The default value is 1, which means the sector right after the boot sector. This value is counted not from the beginning of the whole disk but from the start of partition. Number of bytes to load has 4 bytes (32 bits) and is placed to the position 98…101 in little-endian format. Volume ID has 4 bytes (32 bits) and is placed to the position 102…105 in little-endian format. The default value is 0. Boot-loader doesn't use bytes from 2 to 89 including, so you may use the loader in file systems that contain in this area their parameters.
Also this code is suitable for preparing the boot disk image with OS kernel in one click. In OS development the frequent system reboot with new kernel version is required, at that you need to prepare every time the disk image that contains the recompiled kernel. This task may turn to be rather complicated if you prepare the image with real file system. Nevertheless, at early stages of kernel development you don't need to create real file system and it is sufficient just to load the compiled code into PC memory. With the help of this file you may drastically simplify the task of image creation. You just need to make image with the first sector containing this boot code, and the following 620 kB containing your kernel. For example, to prepare image for Bochs virtual machine you may create file hdd.asm with the following contents:

	incbin	"rawfs.bin"
	incbin	"kernel.sys"
	times	630*2*512-($-$$)	db	0

then after building the kernel compile it with the NASM assembler:

nasm hdd.asm -o hdd.img

add the following lines to the Bochs configuration file:

ata0-master: type=disk, path=hdd.img, cylinders=2, heads=10, spt=63, translation=none
boot: disk

and run Bochs. All sequence may be automated with the help of make-file. If your kernel is small and you wish to optimize boot process, you may explicitly specify the size of your kernel to the loader in bytes and fill it in to the position 98…101 in little-endian format. In this case boot code will calculate how many sectors to load and will load only necessary. Corresponding code in NASM syntax will look like the following:

	incbin	"rawfs.bin", 0, 98
	dd	Kend-Kstart
	incbin	"rawfs.bin", 102
Kstart:	incbin	"kernel.sys"
Kend:	times	630*2*512-($-$$)	db	0

The resulting image "hdd.img" will be suitable not only for running in virtual machine. You may copy it to the first sectors of flash-disk and run it in real hardware.

fat12.bin, fat16.bin – boot sector images for FAT12 and FAT16 file systems. Note that the bytes 3…61 (including) are the BIOS and file system parameters. This area requires correction after file system generation. If you choose file name other than KERNEL.SYS (the default name), you need to write it in by the capital letters to the position 62…72 in the following format: short file name padded by spaces to 8, then extension padded by spaces to 3 without separating period. In total 11 symbols.

fat32.bin, fat32chs.bin, fat32lba.bin – boot sector images for FAT32 file system with automatic access mode, CHS and LBA48 access respectively. Note that the bytes 3…89 (including) are the BIOS and file system parameters. This area requires correction after file system generation. If you choose file name other than KERNEL.SYS (the default name), you need to write it in by the capital letters to the position 90…100 in the following format: short file name padded by spaces to 8, then extension padded by spaces to 3 without separating period. In total 11 symbols. The fat32.bin version of boot-loader occupies two sectors if sector size is 512 bytes, so you need to place second sector anywhere in the reserved area of file system. The number of the reserved sectors is specified in bytes 14…15, in that limits the boot code will seek its extension. Keep in mind that at least two sectors in the reserved area are occupied, – the sector with file system information, its number is specified in bytes 48…49, and the backup copy, its number is in bytes 50…51. Second sector of boot code may be placed at any free sector, but it is preferable to place it closer to the partition start. It is common that the backup copy is in 6-th sector, and file system information is in 1-st, so the best choice will be placing the boot code extension in sector number 2. If the file system formatted so that it is not enough reserved sectors for placing the boot code extension, you need to use CHS or LBA version of loader. If the sector size is 1 kB or more, the whole boot code must be placed in one sector.

exfat.bin – boot record for exFAT file system. Note that the bytes 64…119 (including) are the file system parameters. This area requires correction after file system generation. If you choose file name other than KERNEL.SYS (the default name), you need to fill it in to the position 122…134 in the following format: file name up to 8 symbols, then dot without preceding spaces, then up to 3 symbols of extension terminated by null byte. In total not more than 13 symbols including null terminator. exFAT file system allows to create clusters of big size, but due to peculiarities of CPU architecture loader supports cluster size only up to 32kb. It is needed to keep in mind that the whole volume boot record of exFAT file system is protected by checksum and it is needed to update checksum after any change of data in VBR according to documentation at the link in the end of this help. Also you need to update the backup copy of the volume boot record.

ntfs.bin – boot record for NTFS file system. Note that the bytes 3…83 (including) are the BIOS and file system parameters. This area requires correction after file system generation. If you choose file name other than KERNEL.SYS (the default name), you need to fill it in to the position 84…96 in the following format: file name up to 8 symbols, then dot without preceding spaces, then up to 3 symbols of extension terminated by null byte. In total not more than 13 symbols including null terminator. Because NTFS boot record has 8-bytes Volume ID, it is not passed as a whole. Instead, EBX register contains the result of XOR operation (exclusive "or") between high and low parts of Volume ID value. Loading of compressed and sparse files is not supported.

ext.bin, ext4.bin, minix.bin, minix2.bin, minix3.bin – boot records for Ext2/3, Ext4 and Minix1/2/3 file systems. Note that the bytes 2…11 (including) are the boot-loader parameters. This area requires correction after file system generation. Bytes 2…3 must contain the size of sector in bytes in little-endian (Intel) format. Bytes 4…11 must contain 64-bit number of hidden sectors (sectors, preceding the partition) also in little-endian format. You may omit number of hidden sectors, if you use MBR/GPT loader from this package. If you choose file name other than KERNEL.SYS (the default name), you need to write it in to the position 12…24 in the following format: short file name up to 8 symbols, then dot without preceding spaces, then up to 3 symbols of extension terminated by null byte. In total not more than 13 symbols including null terminator. Because superblock of Ext2 file system version 1.0 and higher has 16-byte Volume ID, it is not passed as a whole. Instead, EBX register contains the result of XOR operation (exclusive "or") between four 32-bit words, making up the Volume ID value. In case that the result of XOR operation is zero (earlier versions of file system have no Volume ID), boot code passes in EBX register the CRC32 code of the whole superblock (bytes 1024…2047 of the partition). Minix loaders always pass the CRC32 code of the superblock. The CRC32 computation algorithm is given below. The Ext4 boot code doesn't support file systems with more than 2^32 blocks (4TiB or more with 1kiB blocks).

mbr.bin, ebr.bin – boot code for master and extended boot records. If you need to specify the alternative boot partition, you need to place its number in zero sector in byte number 0x1BD (445), immediately before partition table. The numbering of partitions for alternative boot starts from 1. If that byte contains 0, then the alternative booting is switched off. Keep in mind that in zero sector (MBR) for alternative boot may be specified only the primary partition or the whole extended partition. The logic drive for alternative boot in extended partition you must set in the zero sector of extended partition (EBR) at the same address 0x1BD (445). The number of logical drive also specified starting from 1.

hybrid.bin – boot code for first sector on drive with hybrid file system. Hybrid file system is such a disk format when it is simultaneously partitioned and not partitioned, depending on interpretation of the first sector of drive. This sector has both partitions table and file system parameters area. If we treat drive as partitioned, then the start of partition points to the volume boot sector with file system parameters. If we treat the drive as unpartitioned, then the first sector of drive contains the copy of file system parameters with certain changes, so that it is possible to work with data stored on drive. For correct work the FS data area has increased number of reserved sectors to cover all the disk area before the start of partition, and, in case of FAT32 file system, changed pointers to informational sector (FS info) and backup copy of boot sector. On recording of boot code to the first sector of such disk we loose hybridity independently of which boot code we'll record onto it – MBR or VBR. To save hybridity we need to save both file system data area and partition table. For this purpose provided this boot code. To record it to disk you need to transfer onto it bytes 3…89 (BIOS parameters block and file system data) and 440…511 (disk ID, partition table and boot signature) from existing first sector of disk.

gpt.bin – boot code for GUID partition table. Code must be placed to protective MBR, the very first sector on disk. GPT is developed to support drives with size more than 2TB. In theory, to work with GUID partitions it is necessary that BIOS of your mainboard support EFI technology. Nevertheless this technology is yet not widely used. This code intended to boot from GPT drives on legacy systems without EFI support. If you need to specify alternative boot partition, you need to set its number in zero sector (protective MBR) in byte 0x1BD (445), immediately before partition table. The numbering of partition for alternative boot starts from 1. If that byte contains 0, the alternative booting is switched off.

iso9660.bin – boot code for booting your OS directly from CD without using floppy-disk or HDD emulation. See below the detailed information about creating bootable CD. If the name of OS file image differs from KERNEL.SYS (the default name), you need to type it in by binary editor to the positions 2…14 in the following format: name of file, point, then extension and null byte string terminator. In total not more than 13 bytes, including terminator. Spaces and special symbols in file name and extension are not allowed. The allowed set includes letters, digits and underscore sign. Because CDs don't have a simple unique value, that may be used as a short volume ID, boot code passes in EBX register the CRC32 code of the whole Primary Volume Descriptor of the CD. CRC32 code is calculated according to the algorithm given below.

usbiso.bin – boot sector USB-ISO for booting ISO-images from USB-drives. In order to make such universal ISO-image you need to put this sector in the first 512 bytes of bootable ISO-image, after that this image may be both recorded to CD and sector-by-sector to USB drive. In this case you may boot from that drive. This technology is extremely convenient for distribution of installation or Live CD as an ISO-image, that may be used not only on PCs equipped by CD/DVD-drives, but also on netbooks which doesn't have such drives. This boot code doesn't load kernel by itself but only a helper code for ISO9660 bootloader. So, ISO-image must be bootable by its own. USB-ISO boot code doesn't select which file to load and doesn't require any settings. Instead it loads ISO9660 boot code according to El Torito specifications and passes control to it. In theory, this boot code may be used for booting ISO images that have foreign boot code in "No Emulation" mode, nevertheless for this the foreign code must be adapted to work with sectors of 512 bytes in size. ISO9660 loader from this package is fully adapted to this mode and may immediately be used. To protect data on USB-drive from accidental overwrite the boot sector is represented as master boot record (MBR) with one hidden partition that covers the whole disk. In theory, such drive may have additional partitions on free space, but in order to do that you need to shrink the size of hidden partition to the size of ISO-image. This task may easily be solved by using "boot.exe" utility. It is quite sufficient to execute command "boot -b -f cd.iso" and the utility will automatically place USB-ISO boot code into the image file cd.iso and will adjust the size of hidden partition.

You may use the files described above in your operating system under terms of license agreements (see eula_en.txt) for file systems generation and formatting.

boot, boot.exe – Linux and Windows console executable programs, designed for preparing boot disk or file image for booting for OS or second stage loader satisfying the former boot specifications. Existing OS, including Windows and Linux do not satisfy the specification directly, so never apply these utilities for disk with you working system! See below the description of boot disk preparing process.

mksys, mksys.exe – Linux and Windows console executable programs, designed for conversion of some second stage loaders to the format, supported by this package. In spite of that operating systems Windows and Linux could not be directly loaded by these loaders, some versions of GRUB2 loader may be loaded after conversion to necessary format. Why do it? Existing Linux loaders (LILO, SysLinux, GRUB, GRUB2) require mandatory procedure of installation after every update. During installation process the installer determines their physical location, after that modifies boot records and the loader file itself to provide the possibility to load. The resulting file, being bound to definite location, could not be relocated to another place on disk; also such disk could not be copied file-by-file keeping the possibility to boot from it. Besides these restrictions there is a risk of that the installer will not be able to bind the new version of loader on some reasons, and after that this disk will no more be bootable. Using converted loader together with this package removes all mentioned restrictions and allows to upgrade the loader safely without binding it to definite location. This package version supports conversion of the following loaders and kernels: FreeDOS kernel builds 2024-2041, GRUB versions 0.94-0.97, GRUB2 versions 1.96-2.00, GUB4DOS versions 4.1-4.4 and SYSLINUX versions 4.05-4.06. To convert you need to take the original loader file, for example, /boot/grub/core.img, and then run the following command:

% mksys -i core.img -o grub2.sys

In the case of success utility will report the version of detected loader and create the file "grub2.sys". The resulting file you need to place to the root directory of your Linux boot disk and then to prepare the disk for booting by "boot" utility with specifying the "grub2.sys" file name to load. The boot disk preparing procedure performed only once and not needed for further loader update. To update the second stage loader it will be sufficient just to replace the "grub2.sys" file in the root directory to the newer version.

For the Microsoft Windows OS family you need to convert file "ntldr" from the root directory of boot disk for operating systems NT4.0, XP, WS2003, XP64, or file "bootmgr" for operating systems Vista and Windows 7.

In the case of FreeDOS OS you need to convert file "kernel.sys".

In the case of GRUB Legacy loader you need to convert file "stage2".

In the case of GRUB4DOS loader you need to convert file "grldr" (preferable) or "grub.exe".

In the case of SYSLINUX loader you need to convert file "ldlinux.bin" from folder "core" of the project.

Attention! Because archive doesn't contain *nix file attributes, before using Linux version of "mksys" utility you need to add execution rights to it, for example so:

% chmod +x mksys

Attention! The boot disk may differ from your system (root) disk. You need to take this into account when placing the resulting file and when preparing drives for booting.

freedos.sys – Kernel of operating system FreeDOS build 2041 with FAT32 support turned on for CPU 386+, converted by mksys utility and ready to boot. When using this file don't forget to add to disk other files, necessary for operating system to work. At least you need file "". The link to the project is at the end of this page.

grub.sys – Second stage loader GRUB Legacy version 0.97, converted by mksys utility and ready to boot. When using this file don't forget to create file "boot/grub/menu.lst" according to GRUB documentation. The link to the project is at the end of this page.

grub4dos.sys – Second stage loader GRUB4DOS version 4.4, converted by mksys utility and ready to boot. When using this file don't forget to create file "boot/grub/menu.lst" according to GRUB4DOS documentation. The link to the project is at the end of this page.

syslinux.sys – Second stage loader SYSLINUX version 4.06, converted by mksys utility and ready to boot. When using this file don't forget to add to root directory necessary modules and to create file "syslinux.cfg" according to SYSLINUX documentation. The link to the project is at the end of this page.

Converted Microsoft Windows loaders are not included into the package because they are components of OS Windows and are proprietary products. You need to convert them by yourself. Don't delete original loader until you check that converted loader successfully loads. Don't forget to make backup copy of all valuable data from disk.

Preparing the drives for booting

The preparing of drive or file image for booting is made with the help of the "boot.exe" utility under OS Windows or "boot" under OS Linux.

Attention! Because archive doesn't contain *nix file attributes, before using Linux version of "boot" utility you need to add execution rights to it, for example so:

% chmod +x boot

While working, the "boot" utility determines the structure of chosen disk, file system type, selects and writes proper boot code in a safe manner, not destroying file system and stored data. If the disk is partitioned, utility will choose the active partition. If there is no active partition, you will need to explicitly define which partition is to be marked as active, that partition will be prepared for booting. After that you once prepared you disk for booting there is no need to do it again. Just copy the OS image file to the root directory of your disk by any convenient way and it will be loaded on booting.

Program usage in OS Windows:

> boot [options]

And in OS Linux:

% boot [options] [devices] [files]

Available options for Windows:

-v       Print version info
-l       List available devices and partitions
-d N     Open device/drive N
         N must be a number for physical device
         and letter for floppy disk or logical drive
-f FILE  Open image file
-a N     Make partition number N active, count from 1
         Set 0 to remove activity flag
         Specify twice to set alternative boot partition
-b       Record volume boot code
-m       Record master boot code (MBR/GPT)
-n NAME  Set name of file to load by boot code. Default is KERNEL.SYS

For Linux available all options with the exception of two – -d and -f. Instead of pointing out the drive or file in options, you need just list them in command line. The difference is determined by that in Linux all devices are available in the same file name space as regular files, and there is no need to specify, whether you work with file with name "A" or with drive A.

Before preparing disks list all available devices in your system:

> boot -l

Remember that disk names or numbers may change after reloading your operating system!

In displayed list will be shown detailed information about all partitions, which partition is active, already have boot code and the name of file that will be loaded.

Then determine the disk you need to work with and enter additional options for certain actions you need to perform, for example:

> boot -d4 -b
for recording boot code to the active partition of drive 4 in OS Windows. The command line in Linux will look like that:
% boot /dev/sdd -b

Never choose the disk with your working OS! Remember that the actual boot drive of your system may differ from the disk where your copy of Windows is installed! It will be a good idea to backup the system area of your disk with the help of any binary disk editor, for example DMDE. This may require an extensive knowledge about disk structure.

If your drive is partitioned, you'll probably need to write not only volume boot code but also master boot code with the -m option and to specify active partition with -a option.

Along with main (active) boot partition you may setup alternative boot partition. This can be done by specifying the -a option twice. The first option will set the active partition and the second – alternative. In this case if you'll press and hold Alt key at system bootup, the alternative partition will be booted. Both active and alternative may be any partition or logic drive on disk without any restriction.

If you have to boot from image file in your emulator or virtual machine, then enter, for example, the following command:

> boot -f floppy.img -b
or for Linux:
% boot floppy.img -b

In the simplest case you may try to prepare bootable floppy disk. This may be done by the following command:

> boot -dA -b
or for Linux:
% boot /dev/fda -b

After that copy file kernel.sys from archive to floppy disk and boot from floppy.

Booting from CD

To create bootable CD you first need to download free toolset for preparing CD – CDRTools. For Linux OS you may download it directly from developer's site: For Windows you need to download Cygwin-port, – archive of pre-compiled binaries for Windows. You better download it from this location:, because on a developer's site only old version port is present. You need two files from archive: mkisofs.exe (utility for creation ISO disk image) and cygwin1.dll (POSIX-library for running Unix-oriented applications on Windows environment). Unpack these files to project directory or to any directory pointed by path of executables search. Then create subdirectory for files with CD image, for example, cdimage. Copy boot sector iso9660.bin and kernel file of your OS kernel.sys to this directory. If the name of your file differs from default, don't forget to fix it in boot sector as described before in boot sectors section. After all this you can start creation of disk image:

> mkisofs -b iso9660.bin -no-emul-boot -o cd.iso cdimage

This is minimal command that allows us to build ISO-image of bootable CD. Here option -b gives the name of file with boot sector, -no-emul-boot points out the mode of boot sector work. These options are obligatory.

You'll see the additional appeared file BOOT.CAT in the disk image. This is auxiliary file for booting system in accordance with El Torito specification, pointing to BIOS, where is located our boot sector and in what mode it is running. This file and boot sector are not needed to user after system bootup, so we may hide them with the help of additional options: -hide boot.catalog and -hide iso9660.bin. System will run OK without these files.

File system ISO-9660 imposes strict limitations to filenames. To get more freedom in naming files we may create disk with file system extension Rock Ridge. This is done by -r option. Nevertheless, Rock Ridge is more oriented to Unix-systems, but Windows-systems use Joliet extension of file system. To create image with this extension, use option -J. But after adding this option you may notice that files boot.catalog and iso9660.bin appear back. This is because Joliet extension in contrast to Rock Ridge extension stores filenames in separate, Joliet-specific disk structures, but not in the main structures as in Rock Ridge. To hide them again from Joliet namespace use options: -hide-joliet boot.catalog and -hide-joliet iso9660.bin, correspondingly. Now we prepared bootable disk image without strict limitations to filenames and their attributes. You may check the obtained image in PC emulator Bochs and then burn it by any software that supports burning ISO-images to the recordable CD.

CRC32 checksum calculation

Here is given in "C" programming language an optimized in speed sample code of CRC32 calculation based on primitive polynomial 0xEDB88320, adopted as standard for data transmission networks.
unsigned long CRCTable[256] = {
  0x00000000, 0x77073096, 0xEE0E612C, 0x990951BA, 0x076DC419, 0x706AF48F, 0xE963A535, 0x9E6495A3,
  0x0EDB8832, 0x79DCB8A4, 0xE0D5E91E, 0x97D2D988, 0x09B64C2B, 0x7EB17CBD, 0xE7B82D07, 0x90BF1D91,
  0x1DB71064, 0x6AB020F2, 0xF3B97148, 0x84BE41DE, 0x1ADAD47D, 0x6DDDE4EB, 0xF4D4B551, 0x83D385C7,
  0x136C9856, 0x646BA8C0, 0xFD62F97A, 0x8A65C9EC, 0x14015C4F, 0x63066CD9, 0xFA0F3D63, 0x8D080DF5,
  0x3B6E20C8, 0x4C69105E, 0xD56041E4, 0xA2677172, 0x3C03E4D1, 0x4B04D447, 0xD20D85FD, 0xA50AB56B,
  0x35B5A8FA, 0x42B2986C, 0xDBBBC9D6, 0xACBCF940, 0x32D86CE3, 0x45DF5C75, 0xDCD60DCF, 0xABD13D59,
  0x26D930AC, 0x51DE003A, 0xC8D75180, 0xBFD06116, 0x21B4F4B5, 0x56B3C423, 0xCFBA9599, 0xB8BDA50F,
  0x2802B89E, 0x5F058808, 0xC60CD9B2, 0xB10BE924, 0x2F6F7C87, 0x58684C11, 0xC1611DAB, 0xB6662D3D,
  0x76DC4190, 0x01DB7106, 0x98D220BC, 0xEFD5102A, 0x71B18589, 0x06B6B51F, 0x9FBFE4A5, 0xE8B8D433,
  0x7807C9A2, 0x0F00F934, 0x9609A88E, 0xE10E9818, 0x7F6A0DBB, 0x086D3D2D, 0x91646C97, 0xE6635C01,
  0x6B6B51F4, 0x1C6C6162, 0x856530D8, 0xF262004E, 0x6C0695ED, 0x1B01A57B, 0x8208F4C1, 0xF50FC457,
  0x65B0D9C6, 0x12B7E950, 0x8BBEB8EA, 0xFCB9887C, 0x62DD1DDF, 0x15DA2D49, 0x8CD37CF3, 0xFBD44C65,
  0x4DB26158, 0x3AB551CE, 0xA3BC0074, 0xD4BB30E2, 0x4ADFA541, 0x3DD895D7, 0xA4D1C46D, 0xD3D6F4FB,
  0x4369E96A, 0x346ED9FC, 0xAD678846, 0xDA60B8D0, 0x44042D73, 0x33031DE5, 0xAA0A4C5F, 0xDD0D7CC9,
  0x5005713C, 0x270241AA, 0xBE0B1010, 0xC90C2086, 0x5768B525, 0x206F85B3, 0xB966D409, 0xCE61E49F,
  0x5EDEF90E, 0x29D9C998, 0xB0D09822, 0xC7D7A8B4, 0x59B33D17, 0x2EB40D81, 0xB7BD5C3B, 0xC0BA6CAD,
  0xEDB88320, 0x9ABFB3B6, 0x03B6E20C, 0x74B1D29A, 0xEAD54739, 0x9DD277AF, 0x04DB2615, 0x73DC1683,
  0xE3630B12, 0x94643B84, 0x0D6D6A3E, 0x7A6A5AA8, 0xE40ECF0B, 0x9309FF9D, 0x0A00AE27, 0x7D079EB1,
  0xF00F9344, 0x8708A3D2, 0x1E01F268, 0x6906C2FE, 0xF762575D, 0x806567CB, 0x196C3671, 0x6E6B06E7,
  0xFED41B76, 0x89D32BE0, 0x10DA7A5A, 0x67DD4ACC, 0xF9B9DF6F, 0x8EBEEFF9, 0x17B7BE43, 0x60B08ED5,
  0xD6D6A3E8, 0xA1D1937E, 0x38D8C2C4, 0x4FDFF252, 0xD1BB67F1, 0xA6BC5767, 0x3FB506DD, 0x48B2364B,
  0xD80D2BDA, 0xAF0A1B4C, 0x36034AF6, 0x41047A60, 0xDF60EFC3, 0xA867DF55, 0x316E8EEF, 0x4669BE79,
  0xCB61B38C, 0xBC66831A, 0x256FD2A0, 0x5268E236, 0xCC0C7795, 0xBB0B4703, 0x220216B9, 0x5505262F,
  0xC5BA3BBE, 0xB2BD0B28, 0x2BB45A92, 0x5CB36A04, 0xC2D7FFA7, 0xB5D0CF31, 0x2CD99E8B, 0x5BDEAE1D,
  0x9B64C2B0, 0xEC63F226, 0x756AA39C, 0x026D930A, 0x9C0906A9, 0xEB0E363F, 0x72076785, 0x05005713,
  0x95BF4A82, 0xE2B87A14, 0x7BB12BAE, 0x0CB61B38, 0x92D28E9B, 0xE5D5BE0D, 0x7CDCEFB7, 0x0BDBDF21,
  0x86D3D2D4, 0xF1D4E242, 0x68DDB3F8, 0x1FDA836E, 0x81BE16CD, 0xF6B9265B, 0x6FB077E1, 0x18B74777,
  0x88085AE6, 0xFF0F6A70, 0x66063BCA, 0x11010B5C, 0x8F659EFF, 0xF862AE69, 0x616BFFD3, 0x166CCF45,
  0xA00AE278, 0xD70DD2EE, 0x4E048354, 0x3903B3C2, 0xA7672661, 0xD06016F7, 0x4969474D, 0x3E6E77DB,
  0xAED16A4A, 0xD9D65ADC, 0x40DF0B66, 0x37D83BF0, 0xA9BCAE53, 0xDEBB9EC5, 0x47B2CF7F, 0x30B5FFE9,
  0xBDBDF21C, 0xCABAC28A, 0x53B39330, 0x24B4A3A6, 0xBAD03605, 0xCDD70693, 0x54DE5729, 0x23D967BF,
  0xB3667A2E, 0xC4614AB8, 0x5D681B02, 0x2A6F2B94, 0xB40BBE37, 0xC30C8EA1, 0x5A05DF1B, 0x2D02EF8D

unsigned long CalculateCRC (const unsigned char *buf, size_t size) {
  unsigned long  CRC=0xFFFFFFFF;
  while ( size ) {
    CRC = (CRC>>8) ^ CRCTable[(unsigned char)CRC ^ *buf];
  return CRC^0xFFFFFFFF;


In case of problems with booting your OS...

Ensure that you specified correct file name to load when installing the boot code. Ensure that the file specified for loading actually exists and is placed to the root of file system.

Try to boot the demo file. If the other image file name is given, just rename the demo file. If demo file loaded correctly, most probable that the problem is in your OS.

If demo file is not loaded, ensure that drive is prepared for booting. For this you may run the command for device listing "boot -l" and look if necessary partition is marked as "boot" and "active". There you also may see which file will be loaded in every partition. In addition you need to ensure that the main boot record also has mark "bootable".

If demo-file loads OK but your kernel doesn't load. Most probable that you didn't setup segment registers (including CS), didn't set the correct "org" directive or didn't setup stack. Best solution in this case would be either subsequent changes in supplied demo-kernel for your purposes, or transferring the whole initialization code from demo-kernel to your kernel.