Writing a 16 bit OS - Ideas, suggestions...

[tloszk]

Hi there,

I am pretty new to OS development, but I want something interesting to do, so I decided to write this post.

So, I have attended an OS theory course in the university, so I have some idea, how an OS works (but not so many).

My plans are the following:

• It would be a 16 bit system, targeting the 8086.
  So I would use the real mode of the x86 processor.
  I would use the BIOS as much as I can.
  Maybe, if it is possible, make it a multitasking system.

My first question is: are these all things possible to make? I am curious exactly about multitasking, because in real mode there is no any protection. Using the BIOS functions will prevent me to do multitasking? Is it a good idea to use BIOS or should I write my own drivers?

This would be an experimental project for me, because I have never done anything like this.

Oh, by the way, I am familiar with C, and I have a strong knowlege base on Assembly and the architecture of the 8086. (That is why it is my chosen architecture.)

Thanks for all the answers!

Cheers
tloszk

[bubach]

Hi, yes it's possible. You can use the timer to change task even if there is no protection, using BIOS interrupts, why not - if you're in 16-bits mode there is no reason why not. If you write your own drivers you could just as well use protected mode. I'd start with a simple bootsector that loads a few sectors and hello world kernel that uses BIOS to print to screen, just to get started. Not sure about how the 16-bit support is in GCC, but here's a thread that might help on that: http://forum.osdev.org/viewtopic.php?f=13&t=14157

[Brendan]

Hi,

My first question is: are these all things possible to make?

Yes.

I am curious exactly about multitasking, because in real mode there is no any protection.

You can still have multitasking without protection.

Using the BIOS functions will prevent me to do multitasking?

No. However, you will probably want to have some sort of "in BIOS" flag and postpone any task switch/es until this flag is clear (e.g. until no BIOS code is running). You can't have multiple threads running BIOS code because the BIOS is not reentrant.

Is it a good idea to use BIOS or should I write my own drivers?

Because you can't have multiple threads running BIOS code, it can be very inefficient for multi-tasking. For example, if you want to read sectors from disk you call the BIOS function, the BIOS function asks the hard drive and waits for the hard drive controller to transfer the data; and while the CPU is doing nothing (waiting for the hard drive controller to transfer the data) you can't do anything at all.

If you do write your own drivers you don't have this problem. However, if you write your own drivers and don't use the BIOS, then there's no point bothering with real mode (e.g. it'd be easier to use protected mode and GRUB).


Cheers,

Brendan

[Combuster]

Multitasking exists in many forms, and it's very well possible to do one of its many forms in combination with BIOS calls as long as you realize it's not written to be thread-safe. Multitasking as a concept is completely unrelated to protection.

Most of the other practicalities depend on what functionality you want - I only see technical choices, but no functional ones. You will probably want to have a goal to give direction to your project.

[VolTeK]

I am curious exactly about multitasking, because in real mode there is no any protection. Using the BIOS functions will prevent me to do multitasking?

I gave this some thought, and had designed my memory manager around the idea that multitasking in real mode was to be done soon using a cooperative tasking model. Since its cooperative multitasking, no ones going to ask for the same area of memory at the same time, your manager will give different locations if written correctly. Future plans of working on a GUI and writing an API that requires programs to register their loops to the OS, so the OS may co through every loop. At the end of every loop there must be a function or Interrupt that calls back to the tasking manager that goes on and calls the next loop. This is my idea implementation cooperative multitasking, but the "A program that crashes can stop the entire system" isn't bad as long as you have a good service to catch errors via their Interrupt. If the program corrupts the stack, and jumps to random places, or writes to a buffer more then it asked for. Watching for this is a little more difficult but, anything can be done if thought about enough


Edit: If every program is given their own stack, Running an interrupt should be fine even if the stack of the program is corrupted, but that goes under my idea that ill never use iret to return back to the program.

[Rudster816]

BIOS functions are none re-entrant, however since you will only ever have on thread of execution running at any given time that really isn't a problem. If you plan on using C, you will need to dust off an old compiler like OpenWatcom, because no modern compiler can generate 16 bit machine code.


IMO, creating a 16 bit operating system is a pretty useless exercise. You'll be limiting yourself to technology from the late 70's, which means you will learn close to nothing about modern operating systems\hardware. You said yourself that you just want to experiment, so why would you want to experiment with completely outdated stuff? Experimenting in protected mode is just as easy with GRUB, and far more rewarding. Right now I dont even have plans to support standard x86 CPU's with my kernel (x64 only for x86 derivatives) because even x86 only CPU's are pretty outdated (the first x64 CPU's appeared in 2003). This is just me two cents though.

[linguofreak]

My first question is: are these all things possible to make? I am curious exactly about multitasking, because in real mode there is no any protection.

Well, Windows 1.x and 2.x ran in real mode, and Windows 3.0 could, but you only get ~640k of memory in real mode, which, while it doesn't prohibit multitasking, is rather cramped when you've got multiple programs running in it.

Furthermore, while you can multitask without protection, you can't prevent programs from disabling your multitasking mechanism.

[bluemoon]

multi-tasking do not necessary switch tasks regularly, to some extend, you can do task switch only when "alt-tab" is pressed, and swap the old task to disk, or to higher memory region which otherwise cannot be accessed directly.

It also make more sense to switch task that way, to organize which process own the console (just like ctl-alt-Fx on a linux)

[VolTeK]

is rather cramped when you've got multiple programs running in it.

Furthermore, while you can multitask without protection, you can't prevent programs from disabling your multitasking mechanism.

If you are developing an API for the applications to be run in this environment where you are multitasking in Real Mode, design it so they cant. Unless the program either

-Performs a system halt
-or-
-Ruins its own stack, i have fixed this scenario but it can still cause problems jumping to random parts of memory.

;-----------------------
As for big programs, allocate memory to buffers during run time rather then having them at compile time, though it may fix very little. Choose your resource usage wisely, Real mode is challenging for nice features

multi-tasking do not necessary switch tasks regularly, to some extend, you can do task switch only when "alt-tab" is pressed, and swap the old task to disk, or to higher memory region which otherwise cannot be accessed directly.

Good idea for running very big programs, i would suggest making this an option in the control panel, however this means services running in the back ground would have a problem if i get your idea correctly.

[bluemoon]

services is not application, that can act like a "TSR"

[VolTeK]

that can act like a "TSR"

*are not


TSR's start out as applications that install as TSR's. My idea of services are Interrupts or programs running in the back ground performing as watchdogs for the system, or monitoring other hardware.

[bluemoon]

Let me clarify:

1. normal application that has a proper process context, resource allocation(like console), and get switch out by some trigger.
2. services or kernel module that stay on main memory that do not get swapped out.

It does not matter how you load services.
and my disclaimer: this is only one possible suggestion, it may not be the best one, it is not even a full design plan.

[rdos]

The non-reentrancy of BIOS would not be a problem unless the keyboard input function is used. It is practical to put a huge semaphore around BIOS calls, and use the BIOS for disc-IO, and possibly some other operations that doesn't block extended periods of time (like read character from console might do).

[bluemoon]

To OP:

You may want to look into DESQview on how it implement multi-tasking into DOS.
That's the model similar to which I described, the difference is how to swap or manage process address (DESQview uses VM86 mode)

[rdos]

If I looked at a multitasking OS for real mode, I wouldn't even glance at DOS, or how various tools like DesqView tried to add the missing multitasking functionality to DOS. When designing something from ground-up, using real mode is not much different from using protected mode or 64-bit mode, possibly except for paging that would not be available.

Besides, I have written a multitasking real-mode, kernel myself (I did this in the late-90s), and it is still used in our commersial terminal applications that run on a V25 processor (basically a 8086). In my case, the kernel is statically linked to the application, so it is not an OS in the typical sense, but it is a "module" that implements preemptive multitasking, a thread API, and some synchronization primitives. That is a space-conserving approach that allows larger applications to be run without "tricks". Our design has no BIOS, so that was not an issue.