Tag Archives: boot

ReactOS as a 32bit Open Watcom Dev Environment

2 Replies

I was having problems with the old Windows XP VM I use to compile Open Watcom (OW) boot projects. This VM is an image of my original XP Desktop install that I have IDA and a lot of unused junk, so I decided to build a barebones VM for just using OW compiling. Initially, I was going to use a Windows 7 install as a lightweight single purpose solution; however, that turned out to be a real pain. Even using a real DVD on Windows 7 seemed to be more trouble than it was worth, so I looked for another option. I finally settled on setting up and giving a ReactOS VM.

ReactOS System About
VirtualBox ReactOS VM

I was incredibly surprised that this worked very well. The VM is lightweight, and I have not had many issues of concern. The VM does not seem to restore correctly from a VirtualBox save, but loading is so fast it really does not matter. My work setup for this project is to code in Visual Studio Code for Linux with the source on a Synology NAS share. The share is mounted (systemd automount) in my home directory. The ReactOS VM shares this directory for access to the source and the VM mounts a FAT16 vdi which is my test image that gets booted using Bochs emulator running from a bash shell on my Linux system.

VS Code About GUI

The workflow is to code in VS Code (on Linux), compile and copy the binary to the FAT16 vdi image using the ReactOS VM, and run the test system using Bochs (Linux) using its internal debugger.

VSCode and ReactOS VM on Gentoo Desktop

MSDOS Booting on a snow day

Leave a reply

Anyway, big snow day in southeastern Virginia, so to kill time I was looking around at source on the internet. I had played around with the MSDOS start sequence before, but never looked closely.

The typical start, considering a start from hard drive, is MBR load to 0x7C00, relocate to 0x0600, and the active partition boot sector is loaded at 0x7C00. The boot sector loads either io.sys or ibmbios.com based on the OS flavor at 0x0700. What I had learned some time ago, io.sys or ibmbios.com is about 40K bytes in size. This means the load would overwrite the current boot sector which is currently executing. Being bored, I found the MSDOS 3.3 OAK disks which have a makefile for the bios containing:

copy /b msload.com+msbio.bin io.sys

So, io.sys is the bios file with msload.com grafted to the front end. A closer look at msload seems that it is a small loader. Here is the sequence:

  • Boot sector loads at 0x7C00.
  • Boot sector loads the first few sectors of io.sys which is really msload to 0x0700.
  • The msload module relocates higher in memory with all the needed BPB information.
  • The module then loads the bios portion of io.sys to 0x0700 which overwrites both the original boot sector and the first loaded msload.
  • The msload code jumps into the bios and off we go …

That is a brief sequence that I can figure out, so it is overly simple. I wondered why it was done this way. I looked at the GitHub MSDOS v2.0 source and there was no msload source included. Possibility the older versions of the MSDOS bios file was smaller and did not overwrite the boot sector? Then around V3 it became too large, and this was the work around. Hey, it cannot be discounted that systems back then measured memory in megabytes.

Well, that killed some time on a cold day.