OSDev.org

Hi All,
I feel described by https://wiki.osdev.org/Lino_Commando

My Question:
What is the advantage of Monotasking systems over Individual programs?
I can think of a few:

• One bootloader. (You could write a boot loader without an OS, and just follow a convention for program location)
• System Calls. This would have to be the big one.
  BIOS takes care of this, but maybe BIOS is outdated...
• You can say "I developed an Operating System" instead of "I wrote some programs"

Couldn't you just create a set of conventions, instead of a kernel?
E.g. All opened files are stored in ES:BX,
All apps must terminate by a jump to the start of the disk?

How much do you gain by developing a Monotasking OS?

P.S. I posted a similar thread in the Delete forum.
I don't want to over-post, I just want to post in the right place.

What you are describing here / in your other thread is not a monotasking operating system - that term refers to operating systems like DOS that run only a single application at a time, but can still run many different programs in the course of a user's session and provide system calls for the functionality the OS implements.

Instead, what you are describing is commonly known as a unikernel or sometimes an exokernel (after a popular implementation from MIT). The idea of a single application working directly with the hardware, without any "operating system" in between, is well studied and new library operating systems (which provide the functionality for the application to the talk to the hardware) have been popping up with the rise in virtualization.

You can read more about unikernels on Wikipedia: https://en.wikipedia.org/wiki/Unikernel

Advantage of monotasking is that you have a simpler, smaller OS. Mainly you don't need a multitasking scheduler. And you can access hardware directly without worrying that some other program might do the same simultaniously.

You don't need to write a new bootloader to do what you mention (if I understood you correctly, you are a bit hard to understand.)

Yes, I think BIOS is outdated. I may not be happy with UEFI, but it is more powerfull.

Personally speaking bragging is not my motivation (OK sometimes I brag a little bit, too). But, yes, you can brag with saying "I wrote an OS".

Did you think about implementing a GUI? Because AFAIK a GUI is best done in a multitasking OS. (Yes, I know there are monotasking GUIs.)

Greetings
Peter

I feel that there would be demand for a baremetal application framework. Some device drivers, memory management, a C/C++ standard library.

It would be useful for kiosks, cloud servers, cross platform desktop applications that "run on QEMU" instead of the JVM.

AndrewAPrice wrote:I feel that there would be demand for a baremetal application framework. Some device drivers, memory management, a C/C++ standard library.

It would be useful for kiosks, cloud servers, cross platform desktop applications that "run on QEMU" instead of the JVM.

They exist - look at things like IncludeOS.

klange wrote:They exist - look at things like IncludeOS.

Thanks for sharing!

PeterX wrote:Did you think about implementing a GUI? Because AFAIK a GUI is best done in a multitasking OS. (Yes, I know there are monotasking GUIs.)

The GUIs of smartphones, tablets, and game consoles be inspiration for what a monotasking OS could look like. Even though many of these are technically multitasking, there's still the basic idea of a desktop/launcher that opens a fullscreen program, and you could still provide a UI library to give a consistent design across your programs.

I don't know anything about unikernels, but I can write about this:

PeterX wrote:you can access hardware directly without worrying that some other program might do the same simultaniously.

This is not really true if you allow things like DOS TSR (terminate and stay resident) programs. (You would allow them; there's no way to block them without full hardware control.) TSRs could hook into the keyboard interrupt or any other, or into any BIOS call, and take control of the machine in in all sorts of ways from simply providing a new driver to allowing the user to pause the main program and scroll back its output. I even heard of a scriptable TSR with a full Turing-complete Forth compiler. In some ways, the end result is *more* complex than if the operating system had proper support for sharing resources. Once you have that support, I think a scheduler is just one relatively small addition. Scheduling does make precise timing more complex, but so do complex TSRs.

I've heard said that MS-DOS only remained single-tasking because Microsoft wanted people to use Windows. I'm not sure why it was at first; perhaps because microcomputers were expected to be single-tasking at the time, or perhaps because Microsoft were a small company and maybe had to rush it? I'm not sure. I did hear they bought an OS rather than start from scratch. I am sure that many professionals didn't take microcomputers seriously until IBM entered the market, so in a sense, Microsoft were developing new territory.

eekee wrote:I've heard said that MS-DOS only remained single-tasking because Microsoft wanted people to use Windows.

There was a multitasking version of MS-DOS! But at the time, Microsoft only sold DOS to OEMs, and most OEMs weren't interested in selling a multitasking MS-DOS.

This comes directly from one of the DOS developers, so I think it's a bit more substantiated than most claims about DOS.

Ooh! Good to know. The situation with all the pros basically worshipping IBM was so weird!


I forgot, DOS text editors are a good example of complexity introduced by single-tasking. Running programs from the editor, editing multiple files, and saving the session (so you can pick up where you left off) are all nice features in an editor, but they're not nearly so important when the operating system helps you do multiple things at once.