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 have an 8" floppy disk.
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
It fits on a floppy disk? We are in 2015, right? What is a 'floppy disk'?
And they'll have something that'd be marginally useable today.
#DeleteChrome
and their website looks like it's from 1995 as well!
if the timing is that tight, it would allow using secondhand PCs instead of ladder logic controllers.
Liberty - Security - Laziness - Pick any two.
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.
Il n'y a pas de Planet B.
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.
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.
It's not based on DOS architecture or any other operating system.
A Floppy Disk is that device you almost never bother using, but which gets added to your virtual machines by default, at least under VMware (haven't paid attention on OpenStack.) The recently-discovered VENOM vulnerability exploits bugs in the floppy drivers, which have been around for a decade, to let a process on a virtual machine break out into the hypervisor and maybe mess with other virtual machines.
So it's especially timely to have a convenient new platform for using floppies!
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Remarkable, in the same way that hand made Swiss watches are remarkable. Really awesome, but pointless at the same time.
Fixed-pitch fonts, I miss those. They made UI development so much easier because the sizing was far more predictable than variable pitched fonts.
True, it's esthetically ugly, but when you want small, quick, and cheap; it's the way to go.
Table-ized A.I.
Assuming it is much faster than an equivalent system written in, say , C. I find it disappointing that hand crafted assembler should be so much faster than what compiler optimizations can achieve.
Nullius in verba
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.
Surely this runs so embiggeningly fast that it's unusable?
I remember running some assembler demo's (back in the day) that made "legacy" hardware do things that just didn't seem possible. The thought of running an OS with that same performance on modern hardware is frightening. Hopefully they've tuned the input routines so that you don't eeennnddd uuuppp wwwiiittthh kkkeeeyyybbboooaaarrrddd jjjiiitttttteeerrr :o)
Moore's law is not a law. Theory, yes; Predictable trend, certainly; Law, no.
The 32-bit version is open (GPL), the 64-bit is currently not.
I have the opposite problem ;)
It's what you call your @#&% when you get old.
Table-ized A.I.
When I went back to community college to learn programming after the Dot Com bust, I was frustrated that all the courses was in every flavor of Java. (The school couldn't afford to renew the Microsoft site license for a few years.) When the assembly language class appeared on the schedule, I later discovered that I was only the student signed up for the course. Class cancelled. Since this class wasn't required for graduation, the dean couldn't grant my request to learn assembly language as an independent study class.
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.
Somebody’s living in the past.
And you're assembly is probably easy to beat with even pretty crappy SSE2 code.
Apparently not by compilers.
You don't seem to understand the purpose of writing in assembly language. Its not to optimize for the current state of the art box. It is to get acceptable performance from old legacy boxes. Some assembly in the right spot(s) can make the difference between an old architecture making the cutoff in terms of acceptable performance, of being able to include that segment of the market in your minimum system requirements.
My point is that such optimizations for the sake of the old boxes doesn't necessarily do any harm to the new boxes. That worrying about future architectures is a red herring of sorts.
Good work Menuetosites!
I am very small, utmostly microscopic.
it grows to 2.5"?
[sarcasm]Can it run systemd?
How about Gnome 3.x?
And does it use binary log files?
I must have those on any OS I run![/sarcasm]
(Or run very far away from!!!)
Comment removed based on user account deletion
of assembly language on the desktop? will it run linux?
Some drink at the fountain of knowledge. Others just gargle.
I bet this OS doesn't have any buffer overrun issues!
No, that only works when the ISO has been expressly engineered to have in its first sectors a fake HD boot record whose boot code will jump into the el torito boot floppy image. Traditional ~year 2000 BIOSes won't look for ISO9660 structures on anything that isn't optical media.
It's not so much that it's hard to learn. It's not actually that hard. When building an operating system dealing with all the small details of the hardware is much more harder than learning assembly. The reason why we stopped building operating systems completely in assembly was not that it was hard to learn but it was because we wanted to port them to different architectures.
Conceivably, you also might pick up a small execution time benefit, although most compilers probably can do better than a hand-coder these days -- they can perform instance specific optimizations that would be impossible to maintain in assembly source.
Writing an OS in assembly in 2015: what a great engineering decision!
Assembly is not difficult.
And nobody creates chips from scratch any more, but the underlying electronics is still worth learning. If you disagree, go look at the THOUSANDS of Arduino etc. projects. Arduino is a microcontroller, not a processor. It has a pittance of RAM, a pittance of speed (16Mhz?) can't access external memory directly, etc. But the principles behind using it reveal a lot about how the electronics work and the problems associated with them.
Just a digital circuit? Far from it when you have power-issues, trace-length issues, hidden impedances in the circuit, etc.
Assembler is also how you begin to understand what a chip DOES. Sure, we all "know". Sure we do. So how do you do bitwise-add-plus-carry? What CPU flags might be triggered and when? What about the circuit timing? Rising-edge, falling-edge, high, low? What about memory refresh, clock-cycles etc.?
Sure, this stuff is not necessary to OPERATE a computer. Nor to PROGRAM a computer in most languages. But then it does begin to come into how to ENGINEER a computer. There are Arduino projects that push a string of bytes down to a Z80 chip with no onboard RAM (literally, the Arduino acts as a memory emulator). They've been enormously helpful in understanding how integrated circuits work - you can literally manually clock one cycle at a time and interrogate the bus timing, memory access, etc. of the attached Z80 as you go. Hell, it's even generating information useful for anyone making a Z80 emulator, etc. What timing does that undocumented instruction have?
There are levels required for certain things, and there's also what happens in science - understanding of OTHER seemingly-unrelated, or obsolete, or total disparate sciences affects your understanding of everything else you touch.
Understanding assembler doesn't make you a better programmer automatically, but it completes the circle - you know what's happening and so can understand why it happens when your engineers come back and tell you the bus timings aren't as they are on the spec sheet, and you can compensate. It's like being a car mechanic who's never seen a Wankel engine. Sure, maybe you never will. Maybe you'll only ever seen them when tinkering with one you bought on eBay. But the different ideas give you different concepts that you can join together because they are based on two solutions to the same problems.
Nobody sits and does arithmetic any more. And you don't need to be able to do mental arithmetic to be a great mathematician. But the knowledge of such things CAN greatly enhance your understanding - and the speed at which you understand new things. Fermat's Last Theorem was solved because someone linked it to elliptic curves. I bet there were mathematicians the world over who were told to stop wasting their time on a 400-year-old problem because it would never be relevant. Now we've JOINED two areas of mathematics, we understand both more. And the guy who had both mathematics in his head simultaneously understands them better than anyone else.
Assembler is not something you'd branch out the next version of Windows into. Of course not. But if you don't tinker with it, understand it, play with other circuits, write your own bootloader, even, then - sorry - you're not a geek with the interest that I would get on with and who I find best at doing geek jobs.
At the end of the day, some bastard had to write the Windows bootloader in assembler. Then, only a few years ago, someone had to rewrite all their bootloaders to take account of UEFI. And every new architecture needs someone to write a bootstrap in assembler even if it's only ever used to get the compiler up and running.
Saying it's a waste is to completely miss the point of life. To pursue interests to satisfy man's innate curiosity.
Your instructor was as blinkered as you.
And, fuck, if you can't get the hang of assembler, when one instruction rarely does anything more than a single piece of binary arithmetic, and each official
Arduino is a microcontroller, not a processor.
Actually, it isn't. The microcontroller is an Atmel AVR. The Arduino project is the processor, plus some standard hardware boards, plus a C++ programming environment that actually shields you from the bare metal.
Comment removed based on user account deletion
Hey buddy, ever wait around near the nurses station at a hospital? Women can and do tell dirty jokes all the time.
Doom is shown as an icon on the desktop in the various screenshots found on the project site, but indeed, Quake is the game running in a window.
How big is that in terms that we can all relate to, say, football fields?
To ensure perfect aim, shoot first and call whatever you hit the target
Doom can run on a Super Nintendo, while Quake requires more system performance.
Doom is a fan favorite, but Quake is a more relevant demo
Wherever You Go, There You Are
Lightweight - fast MenuetOS release 1.0 shipping
DarkStarZumaBeachSurfinApocalypseWow
label MenuetOS64
menu LABEL MenuetOS 64 bit - version 1.0
KERNEL images/clonezilla/syslinux/memdisk
append initrd=images/menuetos/M6410000.IMG
Plus the bootloader firmware (although I guess you could call that part of the environment) - you can't just drop a stock AVR into the socket and have it work without it unless you use an external programmer to burn the sketch into the chip beforehand.
Please stand clear of the doors, por favor mantenganse alejado de las puertas
stable on all hardware with which they've tested
How do they manage ACPI mess that exists on some machines, and unusual chipsets? There is nothing impossible here, but if the end product must fit on a floppy, there is no much room.
So, write your OS in 90% C and optimize the remaining 10% in ASM
"A profiler? What's that?"
Please stand clear of the doors, por favor mantenganse alejado de las puertas
How portable is it? Do you have an interface for C (which would allow compilation of everything else I'd imagine). Can we see the object oriented code? It's got to be temping.
I'm not the least bit surprised that an assembly programmer, who really understands what's happening in the CPU, can write very fast C. I bet for most software, your asm version will be at least twice as fast as a C version written by a typical programmer, who doesn't even realize that the CPU caches have any effect on how well their software runs. More to the point, the typical C programmer would never think about how writing their code differently might allow the inner loop to run from cpu cache. Hell, the typical C# programmer doesn't often even think about the fact that memory is thousands of times faster than disk.
I wouldn't suggest writing much in asm, but being ABLE to do so, having a clue what your C or .NET code may end up looking like in asm, is a huge advantage.
Are there any instructions that give direct insight into the state of the pipeline (like rdtsc for cycle count).
How do you distinguish slowness from faulty "branch prediction", pipeline woes or any other reason on any non trivial codebase ?
You people are forgetting the obvious use of dabbling in assembly today. Hacking software for instance.
"They show off the platform running Quake. Doom is mentioned in the article, but who read that far?"
They also mention floppy disks.
It's written in Assembler, they started this project in 1983, it used up all their time and so didn't have time to follow the technical evolution.
I recall in college, my ADA textbook mentioned that it was the only language who's only and first compiler was written in ADA itself. How in the Hell? There had to be something in at least assembler to start off small, right? Just to plant a seed for gosh sake...
Yep, with assembly is a breeze to keep the system secure.
This sig can be distributed under the LGPL license