MikeOS 1.0 has been released. It is an open source PC operating system, designed as a tutor for basic OS design and x86 assembly language. “MikeOS is a 16-bit operating system for x86 PCs, written in assembly language, which boots from a floppy disk or CD-ROM. It features a text-based dialog-driven user interface, a command-line, support for FAT12 (DOS) floppies and PC speaker sound. It can load external programs and has over 30 system calls. Basic DOS .COM program support is also included.” This version includes a complete Handbook with a whole section on writing your own OS.
Best. Name. Ever.
Well, apart from the name: I browsed the handbook a bit, and I must say it’s written pretty well, especially for beginners
“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.
This guy insulted him–he’s a high faluting Linux guy who probably can’t code. I defended Mike–said it was fast. But we know Linux guys get modded up and competition gets modded down. His is +6.
I’ll bet it’s pretty fast.
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; 79×18)
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.
An OS acting as a teaching tool sounds like a good idea
Yeah, but by writing it in assembly and using IA16 is a bit, well, out of date?
JAL
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.
Not true. I have a version of MikeOS with a preliminary GUI, using a PS/2 mouse.
the bios doesnt provide mouse support via an interrupt.
Yes it does: http://heim.ifi.uio.no/~stanisls/helppc/int_33.html
That’s not BIOS, those are DOS mouse driver calls.
You’re quite right. I even got modded up for it (Hmm). Oh well; it’s hardly a stretch to read a few bytes from the PS/2 AUX port and interpret them yourself.
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
If you want to make a 64-bit OS, you can see the code to change to 32 and 64 bit in LoseThos. Might as well go for something more modern. http://www.losethos.com
It’d be appropriate to submit articles about that OS, but just linking to (your?) project while insulting the topic of the article is just advertising.
It’s only 75,000 lines of code, so you can find stuff easier than in Linux.
Your OS is good but it is not for educational purposes.
The code wasn’t much readable. Sorry but i feel there are other better documented OS to read from. Also what is cpz file extension anyways?
and eventually meet your current high level coding practices makes you undoubtedly a better coder.
Thanks for the feedback folks. This is just the first version of the handbook, so I’ll include other sections if anyone has suggestions.
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.
And aren’t you smug M saunders, mocking him some more.
Who was I mocking? Could you quote me?
He also advertised BSD. That’s not fair.
Why don’t we call a truce. Everybody pushes their favorite operating system. I’m honest and direct. You guys think you’re sly.
where do you get a 186/286 these days. Give me a break.
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 🙂
Since 386 or anything upwards don’t have any new 16bit instructions your OS should work just fine on a 286
286 has a limited protected mode too, but generally if you did implement a protected mode OS you’d need 386+.
Good info, thanks. Perhaps I can convince QEMU or Bochs to run in 286 mode and see if MikeOS runs fine there!
I like huge chips. Is that a sin? It might be.
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.
i thought it’s a joke os. but it is rather cool
http://prevedgame.ru/in.php?id=20508
The old Nike moto fits this case exactly!