Thread: Writing an OS
View Single Post
Old 02-16-2006, 04:25 PM   #12 (permalink)
TheHeadFL
 
Ultra Techie

Join Date: Jul 2005

Posts: 530

TheHeadFL

Send a message via AIM to TheHeadFL
Default

This is a response I wrote recently to a thread about programming:
Quote:
Originally posted by TheHeadFL
To really write an OS you are going to need to know your processors assembly inside and out.

You're also going to have to be very very good at C.

The true beginning of an OS is basically building a binary image that you can write to a floppy disk (or other bootable media). This binary image basically contains a few lines of assembly that direct the computer to begin loading the rest of the OS (specifically the interrupt handler) from the floppy disk or the hard drive.

Once the interrupt handler is in place in memory, the fence register in the CPU must be set so that user programs cannot overwrite the interrupt handler.

Next, the System Vector Call table (syscall) must be loaded. This would be generally your lowest level functions like console input and output. This would also be basic functions that handle basic disk access. These syscalls are generally written in C with built-in assembly routines. In these cases, the C files must not rely on any standard libraries. All syscalls can only consist of the most basic C language statements, no libraries.

The next step is to pass control over the machine over to whatever higher level layer exists. In most cases, there are many layers between the SVC table, interrupt handler, and the end shell/interface.

If you were writing an OS at this point, you would want to implement your own implementation of the C standard libraries (or download a working source) and get those running on your system.

At this point, you are ready to execute binaries compiled using a high-level language like C and the standard libraries. Generally you only want the OS kernel to run at this level. The kernel then, combined with the interrupt handler, sets up a multi-programming environment. This just means you enable the 'OS' to manage processes and threads, and if neccesary handle multiple processes and context switching.

Once you are this far you would also want to write drivers to wrap the assembly calls (or low level syscalls) that are required to interface with the rest of the system hardware. This includes, but is in no way limited to sound cards, high-resolution video adapters, mouse or keyboard input, and any other essential hardware.

Finally, once this is completely done, you could write a shell or some other interface. This could be as simple as a command line, or you could use your driver layer to render high resolution graphical video. Either way, you are writing the main process by which the user interacts with the OS, including input/output, and launching and managing other processes.

At this level, you've basically got a complete OS. Theoretically you could compile and run user programs at this point.

Of course, what I've described easily encompasses months if not years of work. An OS that implements what I've described could easily be thousands and thousands of lines of code.

__________________
Desktop machine: 2 x Opteron 246, Asus K8N-DL, 2GB PC3200 ECC Reg., XFX GeForce 6600GT, 74gb WD Raptor, 2 x 19\" LCDs, Windows XP x64
Server machine: Intel P4 3.0GHz 2MB EM64T, ECS i865pe, 1GB PC3200, 36gb WD Raptor, Windows Server 2003
Laptop: Dell Inspiron 9100 (Intel P4 3.2GHz 1MB Prescott, i865pe, 512MB PC3200, Mobility Radeon 9700, DVD+R/DL Burner), Windows XP
Linux: P3 450Mhz, 386MB ram, Slackware 10.1 (Running mySQL/Apache)
TheHeadFL is offline