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?
but i am ..
copied from the linked page
~~ snip ~~
Modern operating systems are written predominately in high-level languages like C and C++. Menuet, however, is written entirely in assembly language: a symbolic representation of machine language. These days many programmers have minimal if any contact with assembly language, but that hasn't deterred the Menuet development team and the result is a slick, compact and super-quick
operating system.
Two of the Menuet developers, Ville Turjanmaa and Madis Kalme, took time out to talk to PC World Australia about what inspired them to undertake the daunting task of writing the operating system, the current state of the OS and future plans for it.
Firstly, what inspired the creation of MenuetOS? Most people would consider writing an entire operating system in assembly language to be a pretty audacious project.
Ville: The original idea for assembly OS came a few years ago when I was browsing the Internet and came across to a page which used a scripting language. And even with my relatively new computer, the short script executed quite slowly. So it seemed like there will always be the need to create a language which uses the last cycles from a new CPU. So I decided to go to the other extreme
end and just use assembly as much as possible.
Can you give me some idea of the backgrounds of the core developers? Do you have people contributing from outside the core team?
Madis: My passion has always been assembly language. As a teenager I started with some programmable calculators where ML [machine language] was the only way to go. Compared to that, assembly is really a breeze and such an elegant way to program.
Menuet
Ville: We come from different countries and with different backgrounds, but most of us core developers have a university background. I've used different programming languages during the last 30 years. From BASIC and Pascal, to C and assembly. And yes, there are people contributing from outside the core team; the MP3 player is one such contribution.
What aspect of Menuet are you most proud of? Are there any parts of the OS that were particularly challenging to code?
Madis: I am very excited about the GUI part because most hobby operating systems go as far as implementing only a command-line type of OS, but with a true-colour, VESA-supported GUI, it differs from all of these and therefore its ideal for games and small graphical demos. The 64-bit register extensions helped me to make a register-only line and circle routines and these I consider my
"u-achievements" that I can be proud of. "Challenging to code?" - I will let Ville answer that
Ville: As for the actual coding, I'm most pleased with pre-emptive scheduling and USB support. Maybe we have also made a small difference to mindsets about what can be done with assembly language.
What next for Menuet? Do you have a timeline for getting to version 1.0? Are there any features coming up that you're especially proud of?
Ville: We need to add new drivers and improve existing applications. Other than that, there are one or two completely new features I'd like to add before hitting the 1.0 mark.
The 32-bit version of Menuet was released under the GPL, but the 64-bit version uses a non-open-source licence that is free for "personal and educational use". Why did you decide to licence the 64-bit version differently? Has this had any impact on encouraging people to join the effort?
Ville: With a completely new type of open source project, people seem to have strong opinions about what direction to take. Even up to a point when
I'd tell you the chances of this story being a dupe, but you wouldn't like it.
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