Coding An OS

When you say "Arbritary executables", you mean executables in a format designed specifically for your OS, right?

You can't run Windows programs except in Windows. This means there is absolutely no chance of running an arbritary win32 executable under your emulation environment.

You *can* write a kernel that runs under another OS, this is sometimes considered to be desirable. In fact Linux has been ported to run under existing OSs, mostly Linux (i.e. User Mode Linux), but possibly also win32 (Can't remember the name of the project).

However, you can't write a kernel which will run win32 executables without having a complete working win32-based environment inside your OS, which is extremely unlikely as you won't have access to the source code of most of the libraries.

As far as writing some code which does task switching is concerned, yes this is entirely possible and can indeed be done in user space inside an existing OS. It can even be done in C using longjmp() and setjmp().

Normally you'd switch between two tasks inside the same program however.

In order to run two separate processes, there is more than task switching required, as you need to also make them appear in separate virtual memory contexts. This is also nontrivial.

---

I think the problem is, that you don't really understand the difference between "programs", "processes" and "tasks". On most OSs, these are different concepts.

Mark

If you want to play around with making a toy OS I'd recomend doing it the 'normal' way rather than having it run inside windows. Use an emulator such as BOCHS so you don't need to setup a test machine and you won't have to constantly reboot either. You also won't have to worry about setting up remote kernel debugging.

As for what you want to do it shouldn't be too difficult to setup. Take a look at OS Development for dummies here which has source code of a very simple kernel in varying stages of development. It also has links to useful info. You'll also want a copy of the x86 system programming guide that you can get from here. You'll probably want the other volumes in that set as well (linked to on that page).

Quote:

Original post by ace_lovegrove Hi, I'm wondering whether it is possible to write a very simple OS kernel that runs two executables simultaneously without being multithreaded, in Windows. Ok for example, is it possible to write a kernel that starts, load two arbitrary executables and then start exe 1 then after a second, stores its register values in a struct in the kernel somewhere, then load in exe 2's registers and start exe 2 and then continuously switch. Basically like an OS does.

NACHOS can do this. See the Forum FAQ.

First, if you want to write a small kernel to run in Windows, isn't the title a bit misleading? ;)

Anyway, there would be a handful big problems with it.
First, executables are made to run in their own memory space. I'm not sure exactly how they're implemented (if all executables start at the same address, for example), but I'm pretty sure they'd overlap the same addresses badly if they were made to run in the same memory space.
I guess you could solve that, either by running it on a virtual machine of some kind (but that would probably be slow, and a lot of work to implement), or maybe you could rewrite the executables to use non-overlapping addresses? Again, it'd be a pain to actually do that, and probably would still be buggy.

Most likely, you'd have to make a custom format for executables, and possibly a custom compiler (or at least linker) too.
Since you can't assume that you have the address space to yourself, you'd *somehow* need to tell each executable which addresses are legal, and which are already in use.

But even if you got all this setup, you'd still need a way to transfer control between your different executables. You can't use interrupts, because they go to the OS, not to your own "kernel". I suppose you might be able to do some kind of hack by using a separate thread for the kernel, so that Windows occasionally switches to that, and then from there, you might be able to manipulate your executable thread to switch to the other exe. You could probably find the other thread's stack if you looked hard enough, and then you might be able to swap it out for the other exe's stack.

I'm curious why you'd ever want to do this though. As far as I can see, it doesn't really have any advantages. It'd be a clumsy and buggy implementation of what any OS already does much more elegantly, with better performance and robustness too. And it doesn't even seem like a very good learning experience.

Hi, thanks for the replies,

Actually im very much in the know about how OS's work, i was just in a hurry this morning because i had to catch a train, probably why i garbled most of it hehe.


Do these emulation environments emulate OS booting, i mean like how Linux does it, making the kernel the first process etc.

ace

They don't do like Linux does it, they give you a blank system you can install Linux on, just as if it was a real computer. And then Linux does its thing just as if it was running on a real system, yes.

Although i know in detail the architecture of a linux kernel i have no idea what would be the first thing to code. I mean would it be as simple as giving EAX the address of a piece of code containing a while loop, supposing i wanted to do something that was UBER simple?

ace

It sounds like you might want to check out the Windows Debugging Functions.

This might help too The Win32 Debugging Application Programming Interface.

the kernel isnt the first thing ran, the bootloader is

Yes, BOCHS is your friend for emulating PCs. There's others as well. In the meantime, Bonafide OS Devers will help you on your way. Many tutorials from Bootloaders (first thing run as a basic rule) to Kernals involving C++, and the trillion things in the middle.