Linked by Thom Holwerda on Thu 21st Nov 2013 18:48 UTC, submitted by Rohan Pearce
OSNews, Generic OSes

MenuetOS sits in an interesting nexus between astonishing technical achievement and computerised work of art. The super-speedy, pre-emptive multitasking operating system is still, despite adding more driver support, more included applications, an improved GUI and digital TV support over the years, capable of fitting on a floppy disk (assuming you can find one).

MenuetOS is a technical marvel. Not only is it written entirely in assembly, it also shoves a fully capable multitasking operating system on a single floppy disk.

Permalink for comment 577251
To read all comments associated with this story, please click here.
RE: Comment by MOS6510
by saso on Fri 22nd Nov 2013 00:09 UTC in reply to "Comment by MOS6510"
Member since:

This fancy OS proves that all these layers between the computer and the user written in all these high(er) level programming languages waste an enormous amount of CPU and memory recourses.

It's often times not the languages per se, but more the way programmers handle computing resources. Sure Java and C# are at times bloated (because the programmers who wrote those also were wasting resources), but take any near-machine language like C or (parts of) C++ and you can easily get close to or match the speed of any hand-written assembly implementation, at a fraction of the time requirements and with far fewer bugs. Keep in mind that 10% of your code runs 90% of the time, so the key is to focus your resources on what really matters, rather than taking either extreme approach (all high-level, or all assembly).

In regards to MenuetOS, the main reason why modern OSes tend to be so large is because:
a) they contain tons of multimedia (high-res icons, full CD-quality tunes, etc)
b) they simply do a lot (there's almost zero extra cruft in a kernel, almost all of it is executable code that actually does something)
It's possible to compromise on a), but if you want to actually get things done, you don't want to lose b). And no, compiler-produced assembly is not inherently slower and/or larger. What most do is give developers options to choose from (would you like this loop to be small or fast?).

Reply Parent Score: 8