Chris Harding

Greetings, I am Chris Harding and am taking MP451 for 3 credits this semester. This semester I primarily worked an operating system called Frosk. I also did a workshop on makefiles, some examples of which can be found here.


This semester, and prior, I worked on a project of my design called Frosk, which is an operating system for the x86-64/AMD64 architecture. It is primarily written in C, and with a notable amount of assembly. The current development version is quite in the development stage, and not truly usable, so I linked an older, more stable, source repo along with the primary development source code. There is also a link to another build of Frosk which is tailored towards a GUI rather than a TUI, but it is quite notably unstable.

Frosk Source - development
Frosk Source - stable
Frosk Source - unstable gui version

For OS development, I found these sites helpful: - General OS Development
Ralf Brown's Interrupt List - Very comprehensive info on interrupts, ports, hardware... etc, somewhat outdated though



I use a hand-rolled 2-stage bootloader that is written in assembly. Once the first stage is loaded into memory, either as an MBR or VBR, it uses BIOS functions to load the second stage bootloader, which then proceeds to load the kernel. The bootloader also does some other things with regard to setup, such as enter 64-bit long mode, identity page the first MB and do other things that are much more easily done in real mode with access to BIOS functions, such as detect memory and the determine the boot medium.

File System

I designed a file system, called f300, for use with Frosk. To create a f300 file system image, I wrote a program that a call fsb (File System Builder) that takes a specification file, which contatins information about what directories and files exist on the system, and creates a disk image. The file system metadata is structured like a tree of metadata blocks, each containing a set amount of metadata nodes, which can describe files, directories, links, strings, data blocks, or child metadata blocks (branches). The pointers to these nodes are 32-bit integers, where each byte describes an index in a metadata block, starting with the root metadata block, and when a branch is found and there is non-zero information in the pointer not used, then it uses the next byte in increasing significance as the index within that child block.


My original idea was to design a microkernel, however the necessity for device drivers in order to load other device drivers, has forced me to go for somewhat of a hybrid kernel (between micro and monolithic), although my plan is to only have backwards compatible drivers, and boot medium IO drivers on boot, and load all other drivers as needed. I have currently implemented drivers for ATA, VGA, PS/2, and serial ports (these is helpful with debugging). The VGA driver is text-based, and compitible with most cards made after 2000, I have implemented a linear-memory SVGA driver that supports pixel mode and resolutions notably higher than what backwards compatible VGA can do and I use in the gui version, but that is not quite as portable so I would rather keep to my microkernel ideolgy and not include it in what the system loads on boot.

While the kernel is able to shift pages around as it pleases withing RAM, I have yet to implement a form of swap-to-disk paging.


Implementation of libraries for use with developing programs on the operating system is quite important, although perhaps not quite part of the operating system itself (although some, like the 'frosk' [aka flib] are not sensible to use outside of frosk). After all, not many people want to rewrite printf everytime they write a program. Implementation of the C standard libraries is not complete, and while I am fond of my (s)rand implementations, there is a notable lacking of the standard print functions. I am still trying to determine the ideal method of implementing this in a frosk fashion.


While userland programs are not considered part of the operating system, it is true that without them a system would not be truly functional (the primary reason why the development version is not so). In the stable version, I have implement mostly standardized functions ls, cd (pseudo command), exit (also pseudo), mkdir, etc.

Frash is the shell that frosk uses (which stands for FRosk [Awesome/Awful] SHell). I have implemented backgrounding processes in frash, through use of '&', though it occurs at the begining of the command rather than the end. Redirection and piping are things I have yet to implement, however.

Notable Distinctions Between More Well-Known OSes

There are quite a few things that have yet to be implemented: the complete C standard library (notably the lack of FILE), networking support beyond serial, virtual file system/mounting support, usb support.

When designing the scheduler, I but more emphasis on the relation between threads rather than the relations between processes. Processes are truly only used to group threads and provide the code/heap region of memory. Parent/Child relationships are emphasised between threads rather than between processes.