

MenuetOS: an OS that fits on a floppy, written entirely in assembly, has GUI - shaddi
http://www.menuetos.net/index.htm

======
r3570r3
The homepage says it caters to assembly developers particularly. Its GUI can
be controlled using ASM. This can be a nice tryout for those interested in
hacking. Ttruly, hacker News stuff. :)

------
kbob
The original Mac OS fit on an 800K floppy (plus 64k ROM), with room for user
programs and documents too.

It might have had some Pascal, but was >99% assembler.

~~~
chc
Looking at the screenshots, this appears to go pretty far beyond the original
Mac System software. I mean, it's a full OS with file management, pre-emptive
multitasking, networking, Web browser, FTP client, USB with device drivers,
multimedia playback and a full GUI with transparency and perspective
transforms. The Macintosh had — well, it had primitive file management, at
least.

~~~
kragen
Most of that stuff has to do with improvements in the hardware. The original
Macintosh's GUI was somewhat limited by the hardware.

CPU: Remember Cringely's story of how before Apple fired him, the last thing
he did was to implement an animation of flies buzzing around the trashcan to
indicate that it was full, which took 30% of the CPU. And it's a lot easier to
do transparency and perspective transforms if you have a GPU to run them on.

Pre-emptive multitasking: pre-emptive multitasking takes up very little code
(you just need an interrupt handler that saves one set of registers and
restores another set) but it's more error-prone to program on than cooperative
multitasking. Its usefulness is that no task can hang the whole computer. But
on a machine without an MMU, like the original Mac, any task programmed in an
unsafe language can crash the whole computer, so that's worthless. Even
preemptive-multitasking OSes that use the MMU effectively (with locks,
facilities for limited shared memory, message queues, and so on) can be quite
small.

Oberon was a system more or less contemporary with the Mac with hierarchical
file management, networking, hypertext, networked file transfer, and a GUI
(although obviously not an FTP client, a Web browser, or transparency and
perspective transforms) that was similar in size.

So why are our other systems so much more code? Here are some of my guesses.

• You can always do something better (faster, in a more general way, with
better error reporting, covering that last little detail of the CSS standard,
whatever) in 10× the code. So people do.

• In big and old systems, in order to keep communication overhead to a
manageable level, people duplicate code — either because they don't know it
already exists, or because they don't understand the code that depends on it
well enough not to break it when they change what it depends on, or just
because changing the interface is so much work. (In theory, you could migrate
all Motif applications to use GTK, with enough work on them.) I'm not saying
this is justifiable in systems of merely a few million lines of code, but in
systems like Debian, up in the billions of lines, it's unavoidable.

• Big and old systems also have lots of code of minimal utility. Do you know
about Xdmcp? Your X server does. How about X resource parsing? Lots of your
programs are still linked with Xt. How about the xbm file format, to say
nothing of three quarters of the formats supported by netpbm and ImageMagick?
Handling for printing teletypes that can't erase? Handling of terminals with
no lowercase? Hardware-accelerated non-antialiased rendering of polygons?
Video cards that have separate palettes for the red, green, and blue color
channels ("DirectColor")? Xcms? Have you ever looked at the random crap in
terminfo? Did you know that Microsoft Windows machines still have fields in
struct sockaddr_in for IMP numbers, in case you're on the ARPANet? And when
was the last time you needed magnetic tape handling programs? Did you know
Emacs still comes with notes on how to port Mocklisp to it?

------
bombs
I wonder why Menuet32 is open source (GPL), but Menuet64 isn't.

~~~
Joeboy
As I understand it the developer got annoyed with other developers polluting
his 32 bit ASM codebase with impure C and decided to focus on a 64 bit version
with a more restrictive license. Shame.

~~~
WiseWeasel
He could simply deny their contributions, and make them fork it... The license
has little to do with who's managing the project and the decisions they make.

------
swolchok
Is it slow and clunky on real hardware, or is that just because I'm running it
in qemu? (menuet64)

