Slashdot Mirror
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."
It's free as in beer, AFAICT, but not open. That seems strange to me.
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.
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.
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.
"Technology.....the knack of so arranging the world that we don't have to experience it." Max Firsch
What puzzles me (apart from the amusing bit about decompiling something that was never compiled) is the prohibition on disassembly. Given the pretty much trivial mapping between assembly mnemonics and the actual binary files they distribute, it seems a silly thing to prohibit.
If we can put a man on the moon, why can't we shoot people for Apollo-related non-sequiturs?
The point was to write an OS in assembly, so all of your analysis is irrelevant.
It's monumentally cool, and academic. The point wasn't to have a portable OS, and assembly can be very maintainable if structured correctly.
If they wanted a lightweight, portable OS they would have chosen a different language.
Why do you think "Task is easy to do" has anything to do with "The author and rights holder does not wish it done" ?
Just because a thing is easy to do does not mean one automatically has some right to do it.
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.
I agree, Synthesis was a much bigger achievement with a much grander vision.
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.
"His name was James Damore."
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.
What's academic about writing an OS in assembly?
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.
Tiny User Base. So there's no incentive to be a developer for the platform. Doesn't support UNIX/POSIX standards, so it's not easy to port existing software to the platform. Freely available OSs have orders of magnitudes more users and developers, and far more reference material making them easier to learn. Who cares about fitting on a 1.4 MB floppy when 1 GB USB drives are practically free?
How is KolibriOS "based on" Menuet, given than the former is GPL, and the latter is under a proprietary license? Their history page seems empty, and the only description I found on their page is in Russian, which I'm not good in.
You are all incorrect in assuming that legalese (should|can|does|will) make any sense from a technical point of view.
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*.
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.
I am TheRaven on Soylent News
I also had to create slides for a presentation for my degree, but that doesn't make it academic.
Hey tards, you do know the 32-bit version is open-source, don't you? Go examine that. But, I bet none of you who are criticizing it being in assembly can even read ANY assembly.
As someone who hacks on LLVM... you don't want to put it in the kernel unless you like crashes whenever it hits an assert() statement. In would like to integrate it into the loader though, so the first time you run a program it runs a JIT-compiled version with profiling code all over the place then emits an optimised static-compiled version for later (I've started doing this a bit with LanguageKit, but it would be better if it moved a layer down the stack). Unfortunately, the link-time optimisation stuff in LLVM isn't really well-designed for keeping code in separate modules, which is important if you want to take advantage of shared libraries (you don't want every program to have its own copy of libc, for example. If I did that, my memory would currently have 500MB filled with libc copies). Hopefully this will change soon...
I am TheRaven on Soylent News
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.
I am TheRaven on Soylent News
The one implies the other. It is very hard to write large, structured, maintainable, assembly code. If your goal is to write structured, maintainable, assembly code then you end up with small and simple code out of necessity.
I am TheRaven on Soylent News
I'm going to go out on a limb and say they re-used the license that was initially written with higher-level languages in mind. It prohibits 2 things they wanted to prohibit and prohibits a 3rd action that isn't possible. Why mess with a license that already says what you want.
I know this is being sarcastic, but if you are doing huge amounts of number crunching you are better off writing it in FORTRAN as it will be faster.
All of this is just the normal software cycle - hopefully you start with a good design that represents the problems at hand at the time. But eventually the requirements change and the original design becomes insufficient, or outright irrelevant, or muddled by refactoring by people with different designs in mind (or outright hacking), until eventually you get a strong urge to chuck the whole thing and start over - which is what they are doing.
Correct. And then we're also talking about information that can't be recovered by decompiling binaries, so the point is moot.
Once you're done debugging, you don't need the symbol tables any more, yes? We may need the comfort of rich commentary and maintainability, but the system really only needs the instructions, opcodes, addresses, literals and data in the binary code to work. [Decompiled|Disassembled] stripped binaries are very hard to make sense of.
In the olden days, we obscured code by renaming variable and constant names with some variation of "I"'s and "1"'s and "O"'s and "0"'s. Not as effective as adding the "strip symbol table" switch to the compiles, but far more fun, which mattered then. "O000O01I = o0oo0OI1" and variations were good for inducing headache. We took DRM into our own hands in those days.
Ahh, to be a sadistic, bastard developer again. I miss that.
Do not mock my vision of impractical footwear