Post a Comment
"Well, apart from the name: I browsed the handbook a bit, and I must say it's written pretty well, especially for beginners"
I completely agree. Even if you're not going to implement an OS by yourself, the handbook is worth reading because it contains really interesting information about how OSes can work inside their basis. Should have known this when I tried a simple OS implementation 10 years ago. :-)
Really good.
I usually don't like these learning OS, but I think this one is different, mostly because it's pretty documented.
I think the documentation is one of the greatest "features" an OS can have. Coincidentally, one of the reasons why I like (and use) OpenBSD every day.
Every guy that writes it's own OS is freaking cool. Keep it up and do your thing and don't let anybody stomp on your creativity. I thinks the time is right for an OS with a GUI where every application has it's own circular window. Plus they are all named Sally.
Seriously though... You're the man!
An OS acting as a teaching tool siunds like a good idea. Look at what Minix ended up doing ... Linux used its filesystem to help develop a kernel of his own. If MikeOS helps to light a similar spark someday, many people will benefit.
Browser: Links (1.00pre17; Linux 2.6.16.27-omap1 armv5tejl; 79x18)
There are a lot of learning OS out there. But it's hard to find a well documented one like this.
Maybe I'm forgetting some (or even don't know), but I think only Minix (with his detailed written book) and now MikeOS (althought it's much simpler than Minix) it's worth to take a look.
It would be if MikeOS was meant to be a modern, general-purpose operating system. But it's not; it's a learning tool, and 16-bit real mode assembly is quite simple to grasp.
Once you throw in another language, you have to deal with linkers and stubs and it all gets rather messy. Besides, you have to use a bit of assembly to kick-start a kernel anyway, so you can't really avoid it.
Using 32-bit protected mode is a no-no. You lose (easy) access to the BIOS, and therefore have to write your own keyboard/screen drivers etc from scratch. By sticking with 16-bit real mode, the MikeOS code can focus on interesting stuff like loading programs and system calls -- not trying to faff around with the keyboard controller.
It would be if MikeOS was meant to be a modern, general-purpose operating system. But it's not; it's a learning tool, and 16-bit real mode assembly is quite simple to grasp.
I agree that real mode is perhaps better to use when starting out, but to call 16-bit real mode assembly 'quite simple' is a bit of an overstatement, with its total non-ortogonalness and weird memory layout. Yes, some asm must be learned to get the thing to boot etc., but a higher level language like C is really better to use as a teaching instrument, to hide all this crappy IA16 stuff.
JAL
It's what you make of it. Yes, 16-bit real mode memory management is hideous, but MikeOS avoids that completely by residing in a single 64K segment. The code never ventures outside that, so we can forget the memory complications.
And yes, x86 asm isn't as nice as, say, ARM, but the code is mostly movs, cmps and jmps, so it's not doing anything really obscure.
you do have to write your own drivers in pmode but staying with the bios, you lose mouse, cdrom, networking, sound, hard drive size restrictions, etc.
the originaly minix 16bit is probably the better educational os out there.
for a 16bit os, you can write it all in c with no asm since you dont need to deal with GDT or anything. you dont even need to write a bootsector you can re-use any old PC boot sector and just rename your os kernel to be IO.SYS on the root of a fat12/fat16 partition.
you make some easy wins really hard. and a 486 requirement for a 16bit os is overkill. a plain old 286 would suffice.
Old approaches aren't always bad ones, and assembly language is sometimes an appropriate solution.
If the assembly is well-documented, and it sounds like it might be in this case, then MikeOS could server as a tutorial for x86 assembly use as well as general OS design, and that isn't a bad thing at all in my book.
If the assembly is well-documented, and it sounds like it might be in this case, then MikeOS could server as a tutorial for x86 assembly use
No, just x86 16-bit, which is really crappy (I know, I've written 1000s of lines of asm code in the old days) and out-dated, as opposed to the slightly better 32-bit version.
JAL
I just had a read through your hand book and have to say its pretty darn good. I like that you take the lowest common denominator approach as I know neither assembly or the Linux commands necessary to get things running. Keep things up as it is really friendly to read!!
Edited 2007-09-17 09:45
A ps/2 mouse is connected to the keyboard controller and should just work fine on a 16 bit os. Also a serial mouse should work. But why is the minimal cpu a 486. I don't know about the 486 adding 16 bit instructions. So why doesn't it run on a 286. Or even an 8088. Staying in real mode that should be fine or am i overlooking something?
Browser: Opera/9.50 (J2ME/MIDP; Opera Mini/4.0.8993/58; U; en)
Regarding the '486' requirement: it may run on a 286 (or even an 186), but I'm not sure what the illegal opcode handler requires. I wrote '486' as a rough baseline as I can't imagine many people keeping 286s around :-)
But if someone does have a 186/286 around and can test it, I'd muchly appreciate it.
What? Who said that? One guy asked if MikeOS really needed a 486, and I said that it may actually work on a 186/286.
You seem to be very angry and have a huge chip on your shoulder, so I won't reply to any more posts :-)
I was wondering about that 486 requirement too, though I will grant the author that it would be hard to find earlier systems. But there are a few still out there and there are people who like programming them and demoing them. (Example: see 8088 Corruption.) I, for one, would love to find an 8088 based system to play around with an ICE I was given a while back.
As for 80186 based systems, I've never seen one of those. Though I did see a multiport serial board that used that rather obscure processor.
80186 systems are rare. They were mainly used in embedded systems.
I'm sure there's more, but the only difference I've come across between an 8086 and an 80186 was in the bit shift instructions. The 8086 could only shift one bit at a time, whereas the 80186 introduced the two operand version allowing you to specify the numbers of bits to shift.
I myself find real-mode quite limiting, 640K memory restrictions without going into that "voodoo" mode called "unreal"..
While you might like holding onto the BIOS services, they are clearly obsolete..
I've run Minix on a 286, that was cool back in the day, Unix-like system puring away with multitasking!
If anyone has 80286 or older units, avoid using DOS-like/monotasking crap and check out Minix or http://elks.sourceforge.net/.
Oh absolutely -- 16-bit real mode would be crazy for a proper OS. Still, MikeOS is small enough to fit into a single 64K segment, so that nasty side of programming doesn't come into the equation :-)
Minix and ELKS are great, and I'll add a section to the Handbook with links, for those wishing to go further once they have the basics sorted out.
BSDfan wrote:
-"I myself find real-mode quite limiting, 640K memory restrictions without going into that "voodoo" mode called "unreal".. "
I would say extremely limiting actually
but real mode knowledge does give you a good idea of what's actually going on in your machine. and iirc, os'es need to boot in real mode and from there enter protected mode, so knowledge of real-mode is essential in this area.
my own very little experience with real mode was when I first switched from Amiga to PC back in the day, I remember being appalled at the architecture forcing you to use segment registers due to 64k boundaries. shortly after I switched however, the dos4gw dos extender appeared and brought amongst other great things, a flat memory model.
It is so good to see an article like this on OSNews.com, sort of reminds of how it use to be. I would be very interested in reading something similar to this on how to write a 32-bit OS.
I once read a book (http://www.ipdatacorp.com/mmurtl.html) on writing your own 32-bit OS, otherwise known as MMURTL - anyone remember that? It was quite an exciting book considering I was using MSDOS as the time.
I did once attempt to write my own OS, starting as a 16-bit OS, and soon realised how easy it must have been for Microsoft to write MSDOS.
I soon aborted this idea having realised all the short-comings of MSDOS, and attempted to write my own 32-bit OS.
However, switching to protected mode and writing all my own functions that BIOS provides in real-mode was certainly using all my time, so I soon gave in.
Anyway, nice to see MikeOS and keep up the good work.
Edited 2007-09-17 20:44
Writing a 32-bit one is a helluva lot of work indeed. I am in the middle of writing one
I just have a small loader in assembly which initializes PM and A20 and then jumps to C code. Using C makes things a lot easier to code. But well...creating a PM OS is really such a huge task that it'd be best to start learning a real-mode one first and MikeOS seems just perfect for that.
I think it's very good that this example is based on real-mode. Apart from the problem that BIOS calls don't work in protected mode anymore, there are several difficult learning steps that one must master:
- Switching to PM is black magic, because the ugly details of the CPU implementation shine through (e.g. one must execute a far-call directly after switching, to flush the instruction prefetch queue).
- Even with switching, the motherboard artificially disables one address line to memory (called gate A20), which must be enabled. How this works depends on exactly what mainboard you're using.
- protected mode does NOT have a flat memory model. If is still segmented, with the segment registers no more being added to the final address, but being indices into a segment descriptor table. To just do *anything* in PM, you must first fill the table with valid entries, and after switching re-load the segment registers (or alternatively, understand how real-mode segment selectors *really* work). Actually, there are two such tables distinguished by a bit in the segment selector.
- to use interrupts, one must set up a similar table filled with interrupt descriptors.
That's a lot of work just to do basic stuff, not mentioning the advanced features of PM (like paging), or even the x86's built-in micro operating system (task descriptors, call gates, task gates, etc.) For beginners, real mode is much less confusing and disappointing than protected mode.
Never tried asm before, so I have used this chance...
If anybody have problems compiling/linking the "Hello World!" example, try this:
vi hello.asm; nasm -f elf hello.asm; ld -m elf_i386 -s -o hello hello.o; ./hello
"-m elf_i386" was the missing parameter for my x86_64 setup.









