Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Behind Menuet, an OS Written Entirely In Assembly

Soulskill posted more than 5 years ago | from the keep-it-simple dept.

Operating Systems 419

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."

cancel ×

419 comments

Sorry! There are no comments related to the filter you selected.

Rob Malda wishes to make an announcement (-1, Troll)

Anonymous Coward | more than 5 years ago | (#29117909)

In celebration of Wikipedia's 3 millionth article, Rob "CmdrTaco" Malda would like to announce that he will be participating in the "Gangbang 3 Million" event in order to get in the Guiness Book of World Records for "Most Dicks Put In Your Asshole in One Week". The event will be held in Las Vegas on September 11th, 2009 at the MGM Grand Casino. If you would like to sign up to be a part of this momentous event please go to http://slashdot.org/gangbang_3_million_signup.php [slashdot.org] . Signing up here will automatically enter you in the drawing to be the first in line to fuck Rob's asshole and for the consolation prize of sloppy seconds. After the event is over, DVDs and Blu-Rays will go on sale on December 15th exclusively through Sourceforge, Inc's ThinkGeek.com retail site at a special 30% off discounted price. Later in January these items will be available for a wide release at 100s of other retailers but at the full retail price. Rob Malda and the rest of the staff at Sourceforge, Inc. hope to see you there!

From the license... (5, Funny)

damburger (981828) | more than 5 years ago | (#29117927)

3) Redistribution, reverse engineering, disassembly or decompilation prohibited without permission from the copyright holders.

Are you sure they wrote the entire thing in assembly language?

Re:From the license... (2, Informative)

Anonymous Coward | more than 5 years ago | (#29117983)

Point one: assembly languages are compiled (from a human readable text file to a machine-readable object file). Did you think they wrote it in hex?

Point two: it's therefore possible to decompile it.

Re:From the license... (5, Informative)

damburger (981828) | more than 5 years ago | (#29117999)

That would be disassembly, which they already mentioned separately as being prohibited. Putting "Point one" and "Point two" in front of clearly incorrect statements doesn't improve anything.

Re:From the license... (1, Informative)

Anonymous Coward | more than 5 years ago | (#29118117)

Hm. No. You're assuming a particular reading of their licence: that by saying "disassembly or decompilation" they are implying that there is assembler and higher level language, rather than "disassembly or decompilation" meaning "reversing it, whichever term you prefer".

Furthermore, disassembly is a basic stage of decompilation, and they may also be saying "you aren't allowed to produce C from it", which is usually possible even if it wasn't written in that language. C code can be created by code generation tools from the product of disassemblers.

Re:From the license... (1)

Big Hairy Ian (1155547) | more than 5 years ago | (#29118027)

Did you think they wrote it in hex?

Why not it's how I started writing Machine Code

Re:From the license... (3, Funny)

gbjbaanb (229885) | more than 5 years ago | (#29118237)

Hex? You had it easy.

I had to flip switches on a front panel, in binary.

Though come to think of it, when I was a child I had a 'computer' that was programmed by putting wires into holes in a breadboard. So.. binary, pah! I had it easy...

Re:From the license... (2, Funny)

miffo.swe (547642) | more than 5 years ago | (#29118325)

Thats nothing, when i was a child i had a calculator that was a pile of pebbles. By putting them in different piles i could count different types of objects at the same time.

Re:From the license... (2, Interesting)

FlyByPC (841016) | more than 5 years ago | (#29118333)

Did you think they wrote it in hex?

Why not it's how I started writing Machine Code

Programming in hex, compared to just clicking a "compile" widget on a toolbar, feels a lot more like "programming." It's fun to toggle in a program byte by byte and see it run -- even on a slowed-down Z80 [paleotechnologist.net] .

Re:From the license... (1)

Desler (1608317) | more than 5 years ago | (#29118053)

No, the process you describe is referred to as disassembling. Decompiling has a connotation of going from the compiled asm code in an executable back to the original source code in a higher level language.

Re:From the license... (3, Insightful)

Rockoon (1252108) | more than 5 years ago | (#29118313)

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.

Given that (2, Informative)

warrax_666 (144623) | more than 5 years ago | (#29118457)

Given that most assemblers are macro assemblers, I'd imagine that disassembly doesn't give the original source code back. You get an equivalent source code, but it might be considerably harder to read (depending on macro usage, obviously).

Re:From the license... (1)

moranar (632206) | more than 5 years ago | (#29118571)

You mean the 'good programmer reading client's spec' decompiler?

Re:From the license... (0)

Anonymous Coward | more than 5 years ago | (#29118061)

assembly languages are assembled, compiled languages are compiled

Re:From the license... (1)

crmartin (98227) | more than 5 years ago | (#29118579)

Well, no. Assemblers are translated, but not compiled.

Re:From the license... (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#29117991)

Yes, because its authors are greedy, greedy Jews who pinch memory registers like they pinch pennies.

Re:From the license... (3, Insightful)

buddhaunderthetree (318870) | more than 5 years ago | (#29118003)

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.

Re:From the license... (2, Insightful)

damburger (981828) | more than 5 years ago | (#29118043)

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.

Re:From the license... (2, Insightful)

pentalive (449155) | more than 5 years ago | (#29118203)

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.

Re:From the license... (3, Interesting)

damburger (981828) | more than 5 years ago | (#29118219)

Because it would be like banning you from remembering (not even speaking) dialogue you remember from a movie. Its inane.

Re:From the license... (1)

fractoid (1076465) | more than 5 years ago | (#29118239)

Well I don't want you taking that bowl of delicious fried noodles I sold you, tasting them, and deducing what ingredients I used.

Doesn't give me the right to stop you, though.

Re:From the license... (1)

TheLink (130905) | more than 5 years ago | (#29118363)

Yeah, just because it's easy to say/write "I don't allow you to do this" or "You must do this if you use this program" doesn't automatically mean it is illegal to go against your wishes. Or that your wishes should be supported and enforced by a Court.

Re:From the license... (0)

Anonymous Coward | more than 5 years ago | (#29118221)

IDA Plugins such as hex-rays will take an assemblydump and transform it into some readable C code... Thus decompiling.

Re:From the license... (1)

FlyByPC (841016) | more than 5 years ago | (#29118355)

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.

Driving 90 miles per hour on a city street is reasonably trivial to do as well, but there are reasons that it's illegal. The GP had more of a valid point about the philosophy -- technical ease or difficulty doesn't have that much to do with it. Yes, disassembly is a lot easier than decompiling (and for that matter, you can "decompile" machine code whether or not it ever was compiled). The $HighLevelLanguage code you produce will no doubt look ugly, but if the decompiler is written well, it will work.

Re:From the license... (1)

damburger (981828) | more than 5 years ago | (#29118401)

Pisspoor analogy. Driving at 90mph on a city street can be legislated against without invasion of privacy (its a *city* street and the speed limit is there to regulate a public space)

Re:From the license... (1)

Amouth (879122) | more than 5 years ago | (#29118317)

why would it not be a commericially viable product?

also if they just stuck it out there for anyone to fork off and do what they want with it - then they can quickly remove any chance of it being commericially viable.

It's impressive work - let them share it how they want.

Re:From the license... (2, Insightful)

OwnedByTwoCats (124103) | more than 5 years ago | (#29118473)

why would it not be a commercially viable product?

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?

Re:From the license... (1)

BlueKitties (1541613) | more than 5 years ago | (#29118223)

No no no, decompilation is taking binaries and turning them into a high level, human readable language. When we disassemble, we're turning it into assembly, when we decompile, we're turning it into a higher level language (e.g. see: Boomerang.) Usually, decompiling is nearly impossible and sometimes pointless (considering you lose comments, optimizations can cause fuggly code when reversed, etc.) Still, you can decompile something that wasn't even actually compiled.

Re:From the license... (2, Funny)

gt6062b (1548011) | more than 5 years ago | (#29118499)

So Johnny 5 didn't want to be turned into assembly code?

Can't blame him, I wouldn't want that either.

Re:From the license... (1)

JiffyPop (318506) | more than 5 years ago | (#29118293)

Oh no. Now you get to be hammered by the pedantic amongst slashdot crowd. They will explain the difference between assembly language and machine code for you...

yea but (0)

Anonymous Coward | more than 5 years ago | (#29117929)

does it run linux?

But (3, Funny)

rodrigoandrade (713371) | more than 5 years ago | (#29117933)

Does it run Linux?

Oh wait...

What! (2, Funny)

jozmala (101511) | more than 5 years ago | (#29117959)

It seems their webserver isn't written in assembler.

Re:What! (1, Insightful)

moro_666 (414422) | more than 5 years ago | (#29118403)

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 time is actually spent more with disputes than doing the actual coding. And when that happened, I decided to concentrate more on the original path of Menuet with the 64-bit version and with a new type of license. However, I don't have
      anything against open source or possibly opening up the Menuet64 source later. But with the current licence, I'd say the people are a bit more committed and willing to put more effort in to a new feature.

It's not FOSS? (3, Insightful)

Nursie (632944) | more than 5 years ago | (#29117963)

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

Re:It's not FOSS? (5, Informative)

Anonymous Coward | more than 5 years ago | (#29118105)

for anyone wanting to tinker - it had been forked before they closed it
http://wiki.kolibrios.org/ [kolibrios.org]
http://www.kolibrios.org/?p=SVN&kind=dir&loc=/kernel/trunk [kolibrios.org]

Re:It's not FOSS? (1)

BlueKitties (1541613) | more than 5 years ago | (#29118307)

Wait, it was forked, as in there was community interest, and the buggars just shut it down? Imagine what today's world would be like if Linus had gotten pissed when people started working with the Linux Kernel.

Re:It's not FOSS? (5, Funny)

arndawg (1468629) | more than 5 years ago | (#29118435)

Imagine what today's world would be like if Linus had gotten pissed when people started working with the Linux Kernel.

I'm guessing the population in the western world would be higher.

Re:It's not FOSS? (1)

rascher (1069376) | more than 5 years ago | (#29118109)

Yeah. This would be really cool and interesting, but without the source code its pretty much impossible for me to gain any technical insight.

Re:It's not FOSS? (0)

Anonymous Coward | more than 5 years ago | (#29118429)

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

Only for personal and educationlal uses. Commercial it costs money; which in today's World with so much going to hand held devices, a small OS like this is a very interesting idea.

So, to use your beer analogy, you can drink the beer free at school or at home, but you'll have to pay for it to drink the beer at work.

Re:It's not FOSS? (2, Funny)

Nursie (632944) | more than 5 years ago | (#29118545)

There's always some smart-arse coming up with reasons to disallow free beer at work, dammit.

Stupid license. No thanks. (4, Insightful)

Desler (1608317) | more than 5 years ago | (#29117965)

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. (5, Insightful)

damburger (981828) | more than 5 years ago | (#29118085)

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. (1, Interesting)

i.r.id10t (595143) | more than 5 years ago | (#29118111)

Of course, if they had to integrate Quake with the OS parts, then wouldn't the OS also fall under the GPL like the quake source?

Re:Stupid license. No thanks. (1)

Wooky_linuxer (685371) | more than 5 years ago | (#29118337)

I don't think they did that. Quake was probably compiled as an executable with some changes to allow it to run in their OS. No I didn't RTFA, but I tried to browse their site and it is slashdotted. Perhaps their webserver run on Menuet as well?

Re:Stupid license. No thanks. (0)

Anonymous Coward | more than 5 years ago | (#29118441)

You're an idiot. Just look at their screenshots page. It's SDL Quake. They probably did some minimal changes and then just recompiled it. Any OS that requires Quake to be "integrated with its parts" as you put it is a pretty shitty OS.

Re:Stupid license. No thanks. (2, Insightful)

mdwh2 (535323) | more than 5 years ago | (#29118241)

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!

(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.)

Re:Stupid license. No thanks. (4, Insightful)

Desler (1608317) | more than 5 years ago | (#29118321)

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. (3, Insightful)

geckipede (1261408) | more than 5 years ago | (#29118629)

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. (1)

houghi (78078) | more than 5 years ago | (#29118641)

I indeed would rather see something like:
I'm doing a (free) operating system (just a hobby, won't be big and professional like Linux) for PCs.
and then see what happens

Not the best choice of languages (5, Insightful)

Anonymous Coward | more than 5 years ago | (#29117973)

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 (4, Funny)

damburger (981828) | more than 5 years ago | (#29118137)

You are right of course. What they need is some kind of software tool that can automatically and quickly generate code optimized for any new hardware that comes out. Rather than code in the particular assembly language of the processor of the day they could write out their algorithms in some kind of abstract, human readable script, which the aforementioned tool would then convert to assembly language.

Why has nobody thought to create such a useful tool for these poor chaps??

Yes! (0, Redundant)

warrax_666 (144623) | more than 5 years ago | (#29118541)

I think you're right! Now, what might one call such a tool? A... "compiler" maybe?

Re:Not the best choice of languages (5, Insightful)

jnaujok (804613) | more than 5 years ago | (#29118291)

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 (5, Insightful)

Desler (1608317) | more than 5 years ago | (#29118397)

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 (2, Informative)

rodsoft (892241) | more than 5 years ago | (#29118643)

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 doubt this kind of code is being generated in *RELEASE* builds. I often check the code being generated in inner loops and most of the time it's the Right Thing (tm). I'm pretty amused to see that the compiler can aggregate calls to sin/cos with the same argument into a single fsincos call, or vectorize some loops over arrays. That's like having the best of two worlds: human readable code that maps directly to the problem at hand AND very well optimized generated code. And given a new CPU and a compiler that understands its architecture and can take advantage of it, my higher level code will profit from it with minimal change. PS: higher level code -> C++

Re:Not the best choice of languages (2, Informative)

Rockoon (1252108) | more than 5 years ago | (#29118547)

..and thats why the fastest encryption libraries are written in high level languages, right?

oh, erm.. encryption algorithms need the exact things you claim compilers are great at, yet the fastest encryption libraries are in hand-written assembler.

The fact is that this "compilers are better than humans" meme is complete bullshit and has always been bullshit. This fact can clearly be demonstrated by looking at the change logs of those compilers. 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..

..and to top it all off, if you arent using ICC then your compiler is shitty even compared to other compilers. The easiest optimization a VC or GCC programmer can make is to switch to ICC.

What it all boils down to is that HLL's use an abstract machine that has nothing at all to do with the real world details of computing on a specific architecture, and that my friend is why hand written essembler will always win the performance war.

Re:Not the best choice of languages (1)

OwnedByTwoCats (124103) | more than 5 years ago | (#29118631)

Also, in high level languages, the developer has easy access to powerful abstractions with well-tested implementations. If I know I'm going to need access to a lot of data, it's trivial to say "Map myMap = new HashMap(); while ( ...) { ... ; myMap.add( key, value); }" It's a lot more work to build the structures in assembly language to do the same thing. So the developer takes a shortcut and writes a simple linked list. In cases like these, high-level implementations that use the appropriate algorithms will beat the pants off assembly-language implementations that use simpler algorithms because coding the complex algorithm is not practical.

That's just dumb. And kinda cool. (5, Interesting)

localman57 (1340533) | more than 5 years ago | (#29117977)

The article is slashdotted, so I'll post a thought without RTFA. I do embedded firmware for a living; assembly programming is part of my job. But unless you have to fit all of your software into a $.42 micro, there's no reason to write all your software in assembly. Typically, you get most of your performance gains by rewriting 5% or less of the software in assembly [Citation needed... :-)]. As for the rest, go with C or higher for maintainability and portability.

6 months from now, a new processor revision will provide enough marginal performance to make up for not coding the other 95% in assembly.

That said, this is a monumentally cool achievement, if academic.

Re:That's just dumb. And kinda cool. (3, Informative)

cabjf (710106) | more than 5 years ago | (#29118081)

I agree, the major advantages of assembly for that other 95 percent would be negated by a good C or higher compiler that will probably write more efficient and faster binaries than most programmers could using assembly.

Re:That's just dumb. And kinda cool. (1, Informative)

TheRealMindChild (743925) | more than 5 years ago | (#29118127)

The "entire" OS isn't written in Assembly (Quake and I think the web browser were not. As a matter of fact, there is a C runtime lib at http://menuetlibc.sourceforge.net/ [sourceforge.net] ). But certainly the core bits are. The choice for Assembly was to keep the design uncomplicated, not for performance.

Re:That's kinda cool. (2, Insightful)

b4dc0d3r (1268512) | more than 5 years ago | (#29118173)

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.

Re:That's kinda cool. (3, Insightful)

El_Muerte_TDS (592157) | more than 5 years ago | (#29118357)

What's academic about writing an OS in assembly?

Re:That's just dumb. And kinda cool. (1)

Dex5791 (973984) | more than 5 years ago | (#29118201)

I don't think it's dumb, maybe overkill would be a better term. You want the stuff that is frequently used (e.g. the kernel, device drivers, etc.) to be fully optimized and totally bug free. There's no reason for it be 100% assembly. They could have just as easily written most of the UI code with C/C++ then optimized the lower level code with assembly. The work would get done faster and it would have more useful features.

Re:That's just dumb. And kinda cool. (4, Interesting)

timeOday (582209) | more than 5 years ago | (#29118261)

Interestingly, their homepage does not tout execution speed as a motivation: "Menuet has no roots within UNIX or the POSIX standards, nor is it based on any operating system. The design goal has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs." It sounds to me more like they are fed up with all the clutter and layers of abstraction in a modern OS and want to see what happens if you start with a clean slate. Then again, without open source, the aesthetic appeal of this "clean" approach is limited.

Ehhh..... (5, Insightful)

OwnedByTwoCats (124103) | more than 5 years ago | (#29118417)

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:That's just dumb. And kinda cool. (1)

miffo.swe (547642) | more than 5 years ago | (#29118275)

If it was true that optimizing 5% was enough to get big performance gains in an OS i wonder why most recent ones are slugs on lead diet? Its not all about pure CPU performance, much is about disk and memory footprint which is where i suspect most of the gains lies in using assembly programming. The same routine for altering a picture in Windows might perform just as well as the same routine in for eg. Its just that everything else in a modern OS is written in high level language and the overhead makes it really noticable in the end. Compare reading a floppy into memory to reading and storing 16GB in memory and you get the picture.

Re:That's just dumb. And kinda cool. (4, Informative)

hey! (33014) | more than 5 years ago | (#29118353)

I agree. Every time I've ever profiled code, I've been amazed at how much time is spent in such tiny portions of the code.

It's an interesting exercise though. I've only done a little assembler, but my thoughts were that if I did more of this I could get pretty good at it. The trick in any kind of programming is to learn to express *ideas*. I learned several different programming paradigms over the course of my career, and while I'm doing OO like everyone else these days, having tried functional programming makes me a better programmer.

I could imagine doing non-trivial systems in assembler, but mainly if the problem domain and its solutions are very well understood. When you see that 1% of your code is taking 99% of your execution time, you *could* tighten that code and get an immediate payback, or you could try understand the problem better in order to find a more efficient algorithm. If you can improve your algorithms, that's almost always going to be a bigger win.

We've been making essentially modern operating systems (virtual memory, process scheduling etc.) for a long time. If you just wanted to implement the textbook approaches for everything, and didn't care about architecture portability, it seems pretty feasible for a couple of guys to make a reasonably credible OS in assembler, provided they knew their OS stuff and were very good assembly programmers. Obviously the C with assembly for tight loops approach is a quicker path to a usable system, but the fact that they're assembly enthusiasts probably means they'll get more benefit out assembler where it is most useful and less benefit out of C where assembler is least useful than a sane programmer would. And it's always worthwhile to demonstrate the limits of conventional wisdom.

SInce you work in embedded systems, I don't have to tell you that upgrading your processor in six months isn't always an option.

Re:That's just dumb. And kinda cool. (0)

Anonymous Coward | more than 5 years ago | (#29118475)

You're supposed to RTFA before posting??

Re:That's just dumb. And kinda cool. (2, Interesting)

FlyByPC (841016) | more than 5 years ago | (#29118493)

Typically, you get most of your performance gains by rewriting 5% or less of the software in assembly [Citation needed... :-)].

I think you mean Amdahl's Law [wikipedia.org] (that speeding up or parallelizing one task will only produce a speedup limited by the relative time consumed by that task compared to the rest of the code.)

I do think that writing good, efficient C code (for instance) will get you most of the way there -- and in that case, your argument is right. There's still something to be said for developing something like this just for art's sake, though. Why do people admire handcrafted Swiss watches, when they can get a perfectly good timepiece for a few bucks down at the Wal-Mart? Craftmanship, and the skill it implies, are impressive to those of us who know what is involved.

Perhaps (if they could open up the code, and if it has very good documentation), they could use it as an example of how to get things done quickly in assembly. Once you get into the assembly mindset, it *is* fun to figure out a way to run a loop in 2/3 the instructions (allowing your robot to control 24 servos instead of 16, with the same $5 microcontroller).

They should... (4, Funny)

oldhack (1037484) | more than 5 years ago | (#29117987)

Man, they should, like, totally port that to ARM. ;-)

"it can even fit on a floppy disk"... (5, Funny)

martas (1439879) | more than 5 years ago | (#29117997)

*blink*

is that some kind of new super-awesome flexible organic flash memory?

No (4, Funny)

hasbeard (982620) | more than 5 years ago | (#29118399)

No, a floppy disk is what you get when you leave a DVD in the back window of your car on a hot day.

Re:"it can even fit on a floppy disk"... (0, Troll)

Smidge207 (1278042) | more than 5 years ago | (#29118423)

Close; 'Menuet' was Riker's Holodeck whore on STNG. And, my gosh, the cunt on *that*. Riker, I mean, ;-)

=Smidge=

Not that amazing (4, Interesting)

jdunn14 (455930) | more than 5 years ago | (#29118029)

For a more impressive feat, check out the Synthesis kernel written back in 1988. Also written entirely in assembly, and as stated in the linked wikipedia entry, that OS kernel was the "mother of all self-modifying code." It actually handled things like thread scheduling by generating a custom assembly snippet to jump to the correct point in the next thread to execute.

http://en.wikipedia.org/wiki/Self-modifying_code#Alexia_Massalin.27s_Synthesis_kernel [wikipedia.org]

Re:Not that amazing (3, Interesting)

Massacrifice (249974) | more than 5 years ago | (#29118257)

thread scheduling by generating a custom assembly snippet to jump to the correct point

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.

Re:Not that amazing (3, Insightful)

Lemming Mark (849014) | more than 5 years ago | (#29118331)

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:Not that amazing (1)

LUH 3418 (1429407) | more than 5 years ago | (#29118623)

Nowadays, something like LLVM [llvm.org] could be built into the kernel to handle all the JIT code generation. That would make it more portable and easier to debug. Having written a JIT compiler using LLVM myself, I can tell you it's not that difficult. Anyone that understands assembly well can do it, in fact, you don't even need to know all the details. If the OS was going to generate snippets of code to jump to certain points in a program, the bugs would probably get ironed out pretty quickly.

Re:Not that amazing (2, Insightful)

dawnpatrol1623 (1616393) | more than 5 years ago | (#29118303)

I agree, Synthesis was a much bigger achievement with a much grander vision.

Followup to Menuet (5, Funny)

halfdan the black (638018) | more than 5 years ago | (#29118075)

I think I might work on a sequel...
Build a 747 with nothing but stone knives and bear skins...

Re:Followup to Menuet (2, Funny)

mikael (484) | more than 5 years ago | (#29118491)

Or how about Building a 747 while in the sky [youtube.com] .

Thanks for your great accomplishments! (2, Funny)

Shin-LaC (1333529) | more than 5 years ago | (#29118079)

Hard drive makers, you have my eternal gratitude.

Quake? (1)

pjt33 (739471) | more than 5 years ago | (#29118125)

I don't get it: why is running Quake an impressive feat? That's pretty much the epitome of a program which doesn't need to be multitasked with anything else.

Re:Quake? (1)

Desler (1608317) | more than 5 years ago | (#29118199)

Exactly. Pretty much any computer made from 2000 onward can play quake with no hiccups.

Re:Quake? (2, Informative)

bluefoxlucid (723572) | more than 5 years ago | (#29118289)

Quake is a highly parallel program with dozens or hundreds of threads running at once just to support its physics, AI, and player control operations. The original DOS version brought its own threading library (compiled in); as Quake was written on more modern OSes and ported to DOS, the original implementation used OS calls while the DOS version used an application-level thread manager.

Re:Quake? (1)

Desler (1608317) | more than 5 years ago | (#29118543)

That still doesn't show how that is an impressive feat. I would be more surprised if it couldn't play Quake than the fact that it can.

Yes, but... (0)

Anonymous Coward | more than 5 years ago | (#29118143)

...does it run Linux?

A very neat concept. (0)

Anonymous Coward | more than 5 years ago | (#29118175)

It seems that it is being bashed around here a bit, but I applaud it. They are taking a 'back to basics' approach while implementing modern functionality of a slick GUI.

Kolibri: a Menuet offshoot (4, Informative)

dargndorp (939841) | more than 5 years ago | (#29118183)

Since all links in the article submission seem to be slashdotted, an offshoot of Menuet OS named KolibriOS is located at http://www.kolibrios.org/?&lang=en [kolibrios.org] .

Re:Kolibri: a Menuet offshoot (1)

ZeroExistenZ (721849) | more than 5 years ago | (#29118533)

Why did they at KolibriOS tried to mimic XP?

Look at the menubar in blue and the startbutton in green...

I don't find the XP interface so superb and renewing it should be kopied. I would rather praise new attempts at intuitive navigation. This and the file navigator thingie has been done over and over again...

It's also a bit against creative innovation; people want opensource, but get them at it and they try to rebuild Microsoft, while they continiously bash Microsoft and never seem to get at such a level?

Build something truely amazing and innovative and I'll hop on and spend some of my spare time contributing.

Right now I'm rather waiting for http://gocosmos.org/ [gocosmos.org] to have rewritten their compiler.

Fast due to assembly or fast because it's minimal? (5, Insightful)

Walter White (1573805) | more than 5 years ago | (#29118235)

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.

obsolete technology (5, Funny)

gsslay (807818) | more than 5 years ago | (#29118245)

(it can even fit on a floppy disk, despite having a GUI)

Excellent, but if we're going to measure these things in obsolete technology;

- How many parchments would I need to copy it?
- Could my team of monks transcribe it in its entirety before the Feast of All Hallows Eve?
- If the Germans intercepted a morse transmissions of it, how long would it take them to crack the code and scupper our plans to retake mainland Europe?

Zillions (1)

berpi (1187131) | more than 5 years ago | (#29118271)

You could fit zillions of virtual Menuets in one single computer...

What's a Floppy Disk? (2, Informative)

mdwh2 (535323) | more than 5 years ago | (#29118297)

it can even fit on a floppy disk, despite having a GUI

Those of us who still remember floppy disks should also remember that having a GUI with an OS that fits on a floppy is nothing new. For the most recent example, see the QNX [wikipedia.org] floppy demo. (Was QNX written in assembly?)

Re:What's a Floppy Disk? (1)

larry bagina (561269) | more than 5 years ago | (#29118611)

The QNX Source code is available. The majority is in C, IIRC.

Puleeeease ... (1)

garry_g (106621) | more than 5 years ago | (#29118375)

There's two guys taking on the (nowadays) unheard of task of writing an Assembly OS, and all people go on about is that you can run Quake on it? WTF ... The last Assembly-OS I used (well, to a big part anyway) was my trusty ol' Amiga ... and it ran circles around many systems that came later with more CPU power ...

Re:Puleeeease ... (0)

Anonymous Coward | more than 5 years ago | (#29118615)

As far as I recall, AmigaOS wasn't written entirely in assembly. AmigaDOS was originally written in BCPL and then ported to C, for example.

networking (4, Interesting)

james_shoemaker (12459) | more than 5 years ago | (#29118377)

Too bad it doesn't have wireless networking support, it looked to be the perfect thing to make older notebook computers useful.

Been done already... (1, Interesting)

Anonymous Coward | more than 5 years ago | (#29118479)

There has already been an operating system written in assembly language, which fit on a floppy disc, despite having a GUI.

It was called the Macintosh operating system. (and no, it was not written in Pascal, despite having Pascal calling conventions)

So 95/96ish (1)

jhhdk (1120433) | more than 5 years ago | (#29118513)

QNX from mid 90ies was an OS that would fit on a 1.44Mb floppy although not written entirely in assembly.
Among features were win95ish gui, webbrowser, PPP dialer, TCP/IP stack.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?