Behind Menuet, an OS Written Entirely In Assembly

angry tapir writes "MenuetOS is an operating system written entirely in assembly language. As a result it's extremely quick and compact (it can even fit on a floppy disk, despite having a GUI). It can run Quake. Two of the developers behind MenuetOS took time out to talk about what inspired them to undertake the daunting task of writing the operating system, the current state of Menuet and future plans for it."

Comments

It's not FOSS?

[Nursie]

It's free as in beer, AFAICT, but not open. That seems strange to me.

Stupid license. No thanks.

[Desler]

Menuet64 Copyright (c) 2005-2009 Ville Turjanmaa

1) Free for personal and educational use.
2) Contact menuetos.net for commercial use.
3) Redistribution, reverse engineering, disassembly or decompilation prohibited without permission from the copyright holders.

Probably won't gain much steam with a license like that. Enjoy your obscurity and 3 users.

Re:Stupid license. No thanks.

[damburger]

More to the point, the prohibition on disassembly makes it impossible to independently verify their claim it was written in assembly language without violating their license, and that claim is central to the idea of this being an interesting research project.

Re:Stupid license. No thanks.

[Desler]

No software got popular with such a restrictive licence! Heaven forbid they give it away free for personal use, all the most popular OSs are free for all!

The only non-free OSes that have have actually been used by more than 5 people actually provided more features than "Can play a 13 year old game fast".

(I don't disagree with you that it might seem a pointless licence, depending on what their plans for it are, but I don't think this has much relevance to popularity.)

Actually it does. Since this is clearly not a commercially viable OS the only segment of the population that might possibly use it would be tinkerers in the FOSS crowd, but they are going to be turned off by the license. There is really no viable reason to run the OS if you aren't allowed to tinker with the source code.

Re:Stupid license. No thanks.

[geckipede]

A far more serious issue in gaining popularity for this project is going to be hardware support. I've actually tried this OS, and discovered that if you cram everything into one floppy disc, there isn't much room left for a range of drivers. I'm fairly sure that this thing was designed and written to work on the developer's own computer, and practically nothing else.

Re:Stupid license. No thanks.

[Verdatum]

Yeah? Well, you're a meanie-head!

Re:Stupid license. No thanks.

[ae1294]

Probably won't gain much steam with a license like that. Enjoy your obscurity and 3 users.

SO what?

At least the they are doing something interesting... Maybe they will find someone who needs a really small and quick OS that is hacker-unfriendly. I'd personally love to see ATM machines running something like this instead of Win2k and XP....

If by some oddball chance they can make some money off their hobby more power to them... Anyone who can code a OS in ASM is ok in my book and you got no room to judge them just because they are covering all their bases. I mean do you really not think some company wouldn't come and grab up all their work and laugh after spitting in these guys faces?

Not the best choice of languages

[Anonymous Coward]

In today's multi-level cache, highly pipelined CPU environment, hand optimized assembly is not usually the best choice when compared to a good compiler. It's easier for bugs to hide, and small mistakes can cost way more than any possible optimization is going to buy you.

Re:Not the best choice of languages

[jnaujok]

Spoken like someone who's never coded in Assembly. While I almost never touch assembly any more, there's very little fact in your statement. In assembler, everything is in front of you. There's no need to worry about what the libraries are doing, or whether the call to some function is going to cause side effects or something you didn't intend, or whether some compiler quirk is going to make your code take ten times longer to run.

Having written in assembly on 8048, 8051, 8086 and DEC Vax boxes, I can tell you right now that debugging most of that code was a lot easier than chasing down the side effect from some array overwrite on leaked memory from a third-party library that you didn't even know was being linked into your code.

Writing in a compiled language is easier, faster, and usually has a better set of pre-written functionality, but never, ever claim that it's going to be more optimized. Even with pipelining updates from the compilers that help the look-ahead caches on the CPU, there's very few times that hand-coded assembler isn't going to be faster.

Go look at the assembler that some of these compilers produce. It's frightening to see the amount of overhead they cost on even simple assignment operations. I saw one compiler (Microsoft's Visual C++) that took a simple x=10; in C++ and turned it into 15 assembly language operations that, had it been coded by hand, would have been one MOV statement. The compiler turned it into conditional conversions for type, did some byte order and range checking on it (for a hard assign to a constant -- rolls eyes) and then finally did the same MOV AX, 0x0a that you would have coded by hand.

Re:Not the best choice of languages

[Desler]

Actually his points are quite valid. It is not a good choice to write everything in assembly when the speedups you gain in most places is not worth the amount of time and effort you spend in hand-optimizing the code. And considering how many bugs I've seen in people's asm code that they didn't spot till later his second point is also true.

Even with pipelining updates from the compilers that help the look-ahead caches on the CPU, there's very few times that hand-coded assembler isn't going to be faster.

The GP never made that claim.

Re:Not the best choice of languages

[TheRaven64]

Which encryption routines are these and what architecture are they written for? The fastest encryption routines I'm aware of are written in GLSL which is not just compiled, it's compiled to bytecode then JIT-compiled by the driver when the program is loaded! The second fastest use dedicated crypto hardware, via (C) ioctl() functions calling a driver, which is written in C. Oh and:

For well over a decade this meme has been out there and for well over a decade there has been continual performance improvements to those compilers.

Just because version n+1 of a compiler is better than version n of a compiler doesn't mean that version n isn't better than a human. Maybe you can do cross-module function specialisation in your head, but the rest of us aren't so lucky.

Re:From the license...

[buddhaunderthetree]

Yeah I wonder about why they chose that particular license. I mean it's not a commericially viable product, and if it's meant to spur research and development then why not chose some sort of free software license.

Fast due to assembly or fast because it's minimal?

[Walter White]

I have to wonder if it is small and fast because when writing in assembly it is easier to resist the urge to add features. Todays compilers are pretty good and can produce pretty tight binaries. However, you can write (and debug) a lot more code in a given time using a high level language.

Re:From the license...

[Rockoon]

Decompiling never results in the original source code.

I think only a few of the responders have a firm grip on the distinction between decompilers and disassemblers.

The true distinction is not on the input to these programs, but instead on their output. You can feed a good decompiler some white noise and still get some high level source code.

Re:Not that amazing

[Lemming Mark]

Wow, this thing must have been fun to debug and maintain. And also, must be a challenge to optimize current generation CPUs for, with separate data and instruction caches... No wonder it never gained traction.

Yeah, I read somewhere that that was the reason everybody's given up on the Synthesis techniques today. A shame, in a way, as it was a really cool system.

Re:That's kinda cool.

[El_Muerte_TDS]

What's academic about writing an OS in assembly?

Ehhh.....

[OwnedByTwoCats]

Ehhh. The whole effort doesn't impress me. There are/were Linux distros that fit onto a floppy. OSs were written in Assembly for years.

If they can demonstrate that "remov[ing] the extra layers between different parts of an OS" simplifies programming and eliminates bugs, then they'll have something interesting. And they can have a flame war with the microkernel folks, who assert that separating the OS into separate parts that are independent and can be thoroughly tested simplifies programming and eliminates bugs.

Abstractions have a purpose; they make it easier to think about things. There are no "Files" or "Folders" (or "Directories", for those of a Unix persuasion) on your hard drive; there are only a sequence of blocks. The Operating System provides the abstraction of files. Various protocols and their implementations then provide an abstraction that "Files" and "Folders" on remote machines are just like "Files" and "Folders" on the local drive.

If abstractions make life complicated for the OS developer, but easier for the user, is it a win? It depends on whether the OS has more developers or users.

Re:From the license...

[__aaxwdb6741]

You are all incorrect in assuming that legalese (should|can|does|will) make any sense from a technical point of view.

Re:From the license...

[yesteraeon]

So if I find a book lying in the street can I pick it up and read it, or do I need to call the publisher to get a license? I think you're overstating the scope of copyright just a *tad*.

Re:From the license...

[TheRaven64]

Fitting onto a 1.44MB floppy is useful in some embedded contexts, because it means that it will also fit onto a small ROM chip or possible the on-die flash in a microcontroller. Unfortunately, being written entirely in x86 assembly disqualifies it from any such situation.

I played with Menuet a year or so ago, and it is very impressive how much they've squeezed into such a small space. It boots almost instantly with a responsive GUI and a number of applications. It's not so impressive, however, when you compare it to something like RiscOS, which did the same thing on a 25MHz ARM2 with 1MB of RAM, or comparable operating systems of the time. It does highlight how poor an effort DOS was (although it requires protected mode, so won't run on anything before an 80386), but I think we already knew that.

Re:That's kinda cool.

[El_Muerte_TDS]

I also had to create slides for a presentation for my degree, but that doesn't make it academic.

Re:Quake?

[TheRaven64]

Citation massively needed. I've poked around briefly in the Quake source code and found nothing like this (although it does make some use of coroutines). And, even if true, the fact that it contains its own threading implementation and doesn't require anything more than the OS than timer interrupts does nothing to counter the grandparent's point. Quake has been ported to Java and, even with the software renderer, ran well several years ago on a then-modern CPU, so it's hardly an example of something particularly demanding on either the CPU or the OS.