MenuetOS, an Operating System Written Entirely In Assembly, Hits 1.0

angry tapir writes: MenuetOS, a GUI-toting, x86-based operating system written entirely in assembly language that's super-fast and can fit on a floppy disk, has hit version 1.0 — after almost a decade and a half of development. (And yes, it can run Doom). The developers say it's stable on all hardware with which they've tested it. In this article, they talk about what MenuetOS can do, and what they plan for the future. "For version 2.0 we'll mostly keep improving different application classes, which are already present in 1.00. For example, more options for configuring the GUI and improving the HTTP client. The kernel is already working well, so now we have more time to focus on driver and application side."

Comments

Wow. Still?

[halivar]

I remember futzing around with this little project 15 years ago. I am pleased to see that, not only is it still going strong, it's pretty remarkably modern.

Not Open

[Zontar The Mindless]

http://www.menuetos.net/m64l.t...

I might play with it, but if I can't use it for work, play is all it'll be.

Re:Not Open

[bluefoxlucid]

The problem with this thinking is memory is not cheap. Memory has grown, and program memory usage has grown linearly with memory, or greater. The problem is when you run two programs at once: the combined working set is bigger than RAM, and has grown linearly as well. Where you may have had 32MB of RAM and 48MB swapping on and off disk, now you have 16GB of RAM and you're swapping around 10GB of data; but swapping is not now 500 times faster, and so the bloat has slowed the machine.

The growth of the working set means the growth of memory controller latency, the need for RAS and CAS selects on different rows requiring precharges taking up 200 FSB cycles on CPUs which now have multipliers of 10 or 15 instead of 1.5 or 2. Random memory access may now have delays of 3000 cycles, causing an instruction requiring 4 cycles to execute to now take 750 times as long; your typical CAS selection may in fact require 7, 10, even 21 cycles now, multiplied by 10 or 15, so as to take 300 cycles of stall. Modern CPUs are made and broken by their CPU cache efficiency and their predictive execution, and multi-tasking flushes those caches and destroys performance.

Computers have grown to manage immense spans of cheap resources, yet they have not increased their capability to manage resources nearly as fast as they have increased those resources.

Re:It can run Doom

[smooth wombat]

Finally, a web site which doesn't try to overrun your browser with unnecessary rotating images and the latest and greatest shiny because some web designer said, "Why not?"

In other words, a web site which is useful.

Entire OS in about 1/3 of i7 Cache

[perpenso]

I'm not reallyd sure that I understand that point. To me, thst would sound reasonable for educstionsl Ãr entertainment purposes, but are there any other meaningful reasons for writing an entire OS in assembler?

The entire OS would occupy about 1/3 of an Intel i7's cache. For ultra-high performance apps that might actually be useful.

Of course that includes user land apps and such so the footprint of the OS itself would probably be far smaller.

Come a long way

[Anonymous Coward]

Wow, slashdot has come a long way from when I first started reading "chips & dips" in 1997. Even just 10 years ago, a story like this would have been met with enthusiasm and honest support, with a virtual pat on the back to the developers.

Today, a story like this is reduced to a mere platform for chest-beating (see the parent above). As in, "nevermind the lame story, look at me instead". Why in the world are you people even here?

Re: Come a long way

[Anonymous Coward]

After the Beta fiasco and the Systemd wars combined with the 7month long--every day--posts of "all STEM/geek males are severely sexist," all the quality slashdotters left.

Right now we are basically in a post-apocolyptic state here.

Re:Come a long way

[zieroh]

Wow, slashdot has come a long way from when I first started reading "chips & dips" in 1997. Even just 10 years ago, a story like this would have been met with enthusiasm and honest support, with a virtual pat on the back to the developers.

Today, a story like this is reduced to a mere platform for chest-beating

To be fair, the vast world of computers and software has come a long way since 1997. What might have been an interesting accomplishment in 1997 is now basically an exercise in pointlessness. Sure, it can be done. Sure, it's small and fast. But so what? What was actually accomplished that's worth anything? Processor power and memory advances since 1997 have obviated any reasonable need for an operating system such as the one described here, and the demands made on modern operating systems pretty much dictate that they be a whole lot more maintainable than any assembly code will ever be.

Re:Come a long way

[Khyber]

"What was actually accomplished that's worth anything?"

I can turn my computer on and pretty much INSTANTLY use it after POST.

The only other OSes to do that have been purely command-line.

The entire OS can fit within the L3 or L2 cache of modern processors, leaving the RAM entirely free for applications. Got a linux distro that will do that?

It also demonstrates the absolute shit bloat code inefficiencies of today.

MenuetOS is the demoscene of operating systems. It does what any operating system can do, faster, with fewer resources, in much smaller, tighter, SUPERIOR code.

Also, because of the code being pure ASM, most nimrod 'hackers' won't even be able to touch it, as they know jack shit about bare-metal programming. It's more secure by its nature, not by obscurity.

Re:Disappointing

[Anonymous Coward]

Never wrote any DSP code have you? It's trivially easy to beat compiler optimizations even with naive SIMD assembly.

Re:Floppy disk?

[Lunix Nutcase]

And you're assembly is probably easy to beat with even pretty crappy SSE2 code.

Re:Floppy disk?

[Lunix Nutcase]

Damnit, yes it was supposed to be *your*. Typed faster than thinking.

Plenty of OSes written in assembly

[cfalcon]

Plenty of OSes have, over the course of history, been written in assembly.

And all of them proprietary, just like this one.

Menuet is cool, but I don't see a compelling reason to use closed source assembly unless it demonstrates some really crazy superpowers. It's also an odd case of a GPL codebase switching to a closed source license a couple years before it becomes useful.

Kolibri forked from the GPLed 32 bit branch, but I don't think it's pure ASM at all.

Re:Looks great for industrial

[itzly]

Or a $10 ARM chip, programmed in C.

So many negative comments

[folderol]

... says a lot about the posters, and nothing about the OS. Personally I think coders should be obliged to write at least one significant project entirely in assembler before being allowed anywhere near high level languages. You pretty quickly lean to program defensively when just the slightest error results in total melt-down.

I bet this OS doesn't have any buffer overrun issues!

Re:Really?

[narcc]

Seriously? There's absolutely nothing suspicious about the AC's claim. Countless hobbyists have done the same thing.

I know the younger crowd seems to think assembly seems a bit like incomprehensible magic, but it's really not.

Re:It can run Doom

[zieroh]

and their website looks like it's from 1995 as well!

So its not bloated and it is fast too? Seems appropriate. :-)

I can state with authority that in 1995, there were exactly zero fast websites. Of this I am 100% certain.