Slashdot Mirror
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."
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.
Question: MenuetOS is entirely written in assembly? There's no traces of other languages, such as C?
Reply: nop
Get free satoshi (Bitcoin) and Dogecoins
And they'll have something that'd be marginally useable today.
#DeleteChrome
and their website looks like it's from 1995 as well!
So its not bloated and it is fast too? Seems appropriate. :-)
It fits on a floppy disk? We are in 2015, right? What is a 'floppy disk'?
Its a unit of storage space measurement equivalent to about 30 seconds of music from iTunes.
It fits on a floppy disk? We are in 2015, right? What is a 'floppy disk'?
It's an object lesson in using pure assembly. By the time you get anything useful done, technology has moved on.
When our name is on the back of your car, we're behind you all the way!
Not Open
Yeah, KolibriOS is an open fork of MenuetOS. It was forked when Menuet was still open source. Although Kolibri hasn't been updated for almost a year.
Not sure why they want to keep the genie in the bottle. Open source would be perfect for this kind of hobby project.
Now that they've got this thing working, what would be really cool is if they could come up with a way of getting it to run on different processor architectures, in case x86 loses out to ARM in the long run.
I'm thinking maybe they could write some sort of abstraction layer whereby the instructions are originally written in some sort of higher level format, which could then be automatically turned into machine code for different hardware using a special program. You could do all sorts of things with that kind of system. I'm surprised nobody's thought of it before, actually.
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.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
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.
Support my political activism on Patreon.
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.
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?
From their own site:
So, if you want to port your own application to it, you'll need to rewrite it too. And you may need to do it in assembly — although there is, apparently, a C-compiler for MenuetOS it is billed as "low-level", which, I gather, means no (or limited) libc, and other exciting and challenging limitations.
In Soviet Washington the swamp drains you.
It's an object lesson in using pure assembly. By the time you get anything useful done, technology has moved on.
Not really. I have some computational code that I wrote in assembly 4 Pentium architectures ago. Every new architecture I run it against the C implementation, freshly recompiled with a current compiler. The assembly is still faster given all the hardware and compiler improvements. Now the performance improvement is getting much smaller but it is still a win.
I wonder what use they're thinking at all. Minix 3 is a step forward: were we to port Linux interfaces for udev, kevents, and such onto Minix, we could drop a Linux userland onto it wholesale, with systemd and all, and benefit from a core operating system which lends itself to drastic rearchitecting.
Consider that running Minix as an OS-level virtualizer--OpenVZ, LXC--is a trivial task, one which requires only providing a different network server and different security features (e.g. users and groups, and their flow through the file system driver and such), largely doable on the existing code base. You could even run Xen on top of Minix with a minor tweak.
Consider that Minix is a collection of services which may be extended by adding other services. It is interfaces and features, not tightly-bonded kernel code. The shape and form of the OS can be changed without commitment: to add services to handle Linux services is not to change Minix, for you may simply not use those services; you could instead add services to make Minix pretend to be OpenBSD. You could replace its threading model or scheduler by swapping out a service, providing a system that uses the advanced features of DragonflyBSD.
There, again, we see a step forward: DragonflyBSD, with its non-locking semaphores, its highly-efficient threading model, its ability to freeze an application and thaw it after a reboot, to checkpoint running applications--a feature Minix does not possess, but could simply by adding a new kernel service--and even to move applications between machines. Extending some of these things would be to bring the features of OpenMOSIX: check pointing and running an application on a different boot cycle or different machine brings the magic of scheduling applications across a cluster of machines acting as one.
Why, then, do we persist in creating these tinker toys, instead of extending, cannibalizing, or imitating those things which show real progress? Why has Minix not embraced the great strides forward made by Linux and integrated its interfaces so as to integrate its user space in distribution? Why has Linux not subsumed the threading model of Dragonfly BSD? Why has someone chosen to create an OS to no purpose, rather than to create a unified system carrying and integrating the lessons from all prior systems?
Support my political activism on Patreon.
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.
it grows to 2.5"?
Or a $10 ARM chip, programmed in C.
of assembly language on the desktop? will it run linux?
Some drink at the fountain of knowledge. Others just gargle.
Check out the memory footprint of Linux sometime.
Two megabytes. Four, really, when using a single 4MB huge page to allocate the entire kernel in one go. A few bytes to maintain each task's information, each cached disk page, each handle held by an application.
Linux uses so little memory you can run it on a microcontroller with a megabyte of RAM. When you build up all the services needed to supply network management, graphical systems, user log-on, audio mixing, and so forth, you get maybe 100MB. When you then run a Web browser and go to a few open tabs, you need a gigabyte or three.
Support my political activism on Patreon.
That's the whole point. It's not open source. The 32 bit kernel is old and not developed anymore.
A successful API design takes a mixture of software design and pedagogy.