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

[bluemoon]

I know that you have a solution, but there are more than one way to do it.
I don't see any harm studying various solutions before designing his own, especially the OP needs a starter.

The point that 3rd party adding multi-tasking features into DOS has nothing to do with the technique and ideas behind them.

[rdos]

I never claimed to have the solution, only that I know how to do this, and that DOS doesn't set the limits of what is possible. Of course, studying DOS-extenders and virtualisation tools that run DOS in V86 could have some interest, but most of these issues are not related to writing a multitasking OS for real mode, but rather to making a notorously bad design (DOS) perform sligthly better. And I do have experience with this as well, as I have written a DOS emulator that runs DOS apps in V86 mode, which I regard as 100% obsolete. I even have written DOS-extender emulators, that are equally obsolete. I wouldn't look at any of these projects if I tried to make a real-mode OS.

But I suppose we are once again back to people that have no experience trying to make claims about things that people with experience write. I suppose it is thought to be more useful to have a background knowing everything about yesterdays OSes than having hands-on experience.

The point that 3rd party adding multi-tasking features into DOS has nothing to do with the technique and ideas behind them.

Totally wrong. It has everything to do with how those tools were developped.

Edit: And, besides, you are totally off-topic as the tools you discuss are not real mode OSes, but protected mode OSes that emulate real mode with V86.

[bluemoon]

But I suppose we are once again back to people that have no experience trying to make claims about things that people with experience write.

That's an ugly turn.

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.

I agree.

Edit: And, besides, you are totally off-topic as the tools you discuss are not real mode OSes, but protected mode OSes that emulate real mode with V86.

Umm, you changed your mind quick.

Totally wrong. It has everything to do with how those tools were developed.

I am aware that the OP want to run is on 8086, but there are many techniques and ideas can be extracted from those projects.
What consideration they made, what limitation they faced, any trap they solved? Yes, some are cause by poorly designed DOS you may safely ignore if you are in a rush, but some are general issues on real mode environment.

For example,
- memory limitation
> which in turns limit the number of concurrent process.
> Some process that block/sleep/pause for long may get swapped (since it's 8086, swap to disk?)
- resource competition
> do it make sense for 2 process printing to same screen, or you need to make virtual screen? (and avoid application draw the dirty way)
- navigation
> since it's not likely to have fancy GUI, there should be a way to navigate between process (and bring active process to screen)


Anyway, since I have no hand on experience on real mode OS development I may as well shut up.

[rdos]

I am aware that the OP want to run is on 8086, but there are many techniques and ideas can be extracted from those projects.
What consideration they made, what limitation they faced, any trap they solved?

This depends on why the OP wants to use 8086, and what his OS is supposed to be used for. The people building FreeDos didn't aim for an OS that run only on 386+ processors, but one that could run on 8086, which none of the emulators can do. There are still 8086 compatible chips out there. I wouldn't recommend any of them for new designs, but they do exist.

For example,
- memory limitation
> which in turns limit the number of concurrent process.

Obviously, but 8086 can address 16 times more than Z80, but we still had computers that used Z80. It is mostly a matter of selecting reasonable applications, and coding applications with memory limits in mind, which today is unusual, but yesterday was commonplace.

> Some process that block/sleep/pause for long may get swapped (since it's 8086, swap to disk?)

You cannot swap with real-mode. It practically requires paging, or at least protected mode segmentation.

- resource competition
> do it make sense for 2 process printing to same screen, or you need to make virtual screen? (and avoid application draw the dirty way)

That issue exists in any environment, and is not specific to real-mode. Again, in real-mode, there is no easy way to provide a virtual screen, and it can practically only be done with an emulator and V86. But the issue of direct hardware access exists in any environment, unless there are means to block IO-ports. Even if IO-ports and memory ranges can be blocked, there is nothing stopping a driver running in kernel from using any IO-port or memory range. But in this case I think it is safe to assume that the application writer (the OP) decides for himself if an application would use direct-IO or not, so it is not an issue.

- navigation
> since it's not likely to have fancy GUI, there should be a way to navigate between process (and bring active process to screen)

If the OP supports this at all. A simpler OS might only have threads, not processes, as the address-space is too small for multiple processes of any considerable size. That is why I claimed a better solution (that uses less memory) would be to statically link the kernel with a single application that needs an OS and / or multitasking.

[Rudster816]

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.

SMP is a huge design consideration for a protected\long mode kernel. Obviously you could choose not to support it, but that would take out a lot of the fun. Since he is targeting 8086 CPU's (hence no unreal mode), he will never be able to access anything above 1MB. This coupled with the fact that paging doesnt exist makes the memory management techniques entirely different and rather trivial IMO. Also, if he wants to truly target only 8086 CPU's, then he cannot use 32 bit registers at all, which is a huge step into the past.

Modern operating systems are entirely different beasts than what one could write for an 8086 IMO. Most of the problems\design considerations with modern operating systems revolve around things like memory protection, SMP, huge physical address spaces, page swapping, multitasking, security, etc are either not present, or entirely different for a real mode OS.

[Combuster]

in real-mode, there is no easy way to provide a virtual screen

using real mode is not much different from using protected mode or 64-bit mode

You like to contradict yourself, speak nonsense, and hijack a thread in the process?

Get out.

[brain]

Who is your target audience for an 8086 based os? I would assume it is for personal amusement as I can't imagine it having widespread use apart from in small niches.

[Brendan]

Hi,

You cannot swap with real-mode. It practically requires paging, or at least protected mode segmentation.

You can swap the entire user space (e.g. a task switch may include saving up to 640 KiB to disk and loading up to 640 KiB from disk for the next process). You can also have "cooperative swapping" where the processes are responsible for storing and loading their data (e.g. kernel needs RAM for "process foo" so it asks "process bar" to free some).

Finally, you can have "process assisted swapping"; where processes ask the kernel to fetch some data before they use it and tell the kernel as soon as they're not currently using that piece of data. In this case kernel knows what the process is actually using at any point in time and can send the rest to disk if it needs to. Note: the XMS Specification is an example of this (where extended memory is usually used for swap space, instead of a hard disk).


Cheers,

Brendan

[rdos]

SMP is a huge design consideration for a protected\long mode kernel.

SMP can (at least theoretically) be used with a real-mode kernel. In fact, every core starts in real-mode, so it is definitely possible to support. Nothing in the usual locking techniques speaks against this either. The only thing is that SMP didn't exist in the original 8086 processor, and neither does it exist in more modern V25/V35 processors either.

Additionally, my current kernel has two modes of operation: SMP and non-SMP. In the non-SMP mode, the locks are nops. This design decision was made in order to provide better efficiency on older, non-SMP systems. A similar design could be used in a real-mode OS, possibly providing it in two versions by compiler switches for SMP / non-SMP.

Obviously you could choose not to support it, but that would take out a lot of the fun. Since he is targeting 8086 CPU's (hence no unreal mode), he will never be able to access anything above 1MB. This coupled with the fact that paging doesnt exist makes the memory management techniques entirely different and rather trivial IMO. Also, if he wants to truly target only 8086 CPU's, then he cannot use 32 bit registers at all, which is a huge step into the past.

True

Modern operating systems are entirely different beasts than what one could write for an 8086 IMO. Most of the problems\design considerations with modern operating systems revolve around things like memory protection, SMP, huge physical address spaces, page swapping, multitasking, security, etc are either not present, or entirely different for a real mode OS.

Take out SMP and multitasking, and you are correct.

[rdos]

Hi,

You cannot swap with real-mode. It practically requires paging, or at least protected mode segmentation.

You can swap the entire user space (e.g. a task switch may include saving up to 640 KiB to disk and loading up to 640 KiB from disk for the next process). You can also have "cooperative swapping" where the processes are responsible for storing and loading their data (e.g. kernel needs RAM for "process foo" so it asks "process bar" to free some).

Finally, you can have "process assisted swapping"; where processes ask the kernel to fetch some data before they use it and tell the kernel as soon as they're not currently using that piece of data. In this case kernel knows what the process is actually using at any point in time and can send the rest to disk if it needs to. Note: the XMS Specification is an example of this (where extended memory is usually used for swap space, instead of a hard disk).

OK, you are right. It would be possible to swap entire processes. What I meant was that parts of a process can not be swapped (without cooperation from the process itself) without paging or segmentation. In addition to XMS (which requires the use of protected mode to some extent, or possibly DMA), people also invented overlays and EMS in order to do this.

[VolTeK]

Your helping each other, not the OP.

Please stay on topic.

[linguofreak]

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.

How do you prevent a program from setting a segment register to 0 and overwriting the IVT with pointers to its own routines? In protected mode the hardware can protect the IDT from being overwritten by user-mode code. In real mode there is no such protection. An application can overwrite the timer interrupt, or any other interrupt that might cause the kernel's scheduler to be called, with pointers to its own routines.

[VolTeK]

How do you prevent a program from setting a segment register to 0 and overwriting the IVT with pointers to its own routines? In protected mode the hardware can protect the IDT from being overwritten by user-mode code. In real mode there is no such protection. An application can overwrite the timer interrupt, or any other interrupt that might cause the kernel's scheduler to be called, with pointers to its own routines.

Obviously