MenuetOS Programmer Review
MenuetOS bumped major version few days ago. Being such an impulsive fool, I set up a virtualbox image from a floppy image and booted it up.
It was easy to setup the system for programming, it was matter of opening the correct programs. The resulting toolchain doesn't work as well together as the programs in a linux terminal, but it is enough for programming. I didn't figure out how to save the filesystem cache, but it had a http server I could use to recover the files after programming session.
In the order on the screenshot, there's a GUI for the fasm, text editor and a debug board. The debug board is the only tool I found for checking errors in my program. It functions a bit like a primitive strace or dmesg -tool, presenting line by line which events take place in the operating system. When you do an error, the memory address during the crash is getting printed in there.
The system is self-sufficient. It contains the kernel in /FD/1/kernel.mnt. If you had the kernel sources, you could recompile a new kernel for yourself and replace that file to try it, assuming you can save and have a recovery disk.
Programming it is a bit like working on a really old BASIC dialect. First of all you need documentation. There are some example applications, that show how to build up an app. Additionally you need the system calls table to find out how to request things from the operating system. Those are enough if you know a little bit about x86_64 architecture and remember some assembly commands of that architecture.
Okay, this thing isn't portable at all. The main language is x86_64 instruction set. The system calls contain everything from archiving to fonts, USB and window handling. Need a new library used by many apps? Add a system call. It's also not safe as every program can access everything, such as reboot the whole system, without any isolation. In a way this is good, it's small and everything is in the same place. It's equally easy to use by the every programming language on the system. That's how it should be.
In the MenuetOS, the program always loads into the 0x0 -address. Every process got it's own virtual memory address space so that's plain feasible. Fixing the address makes direct association with the memory address and the location in the program without having to add extra shims. Resources provided by the system doesn't pretend to be anything else than what they actually are, for example files and sockets do not try to be streams. The binary format is simple. It consists of 8 64-bit fields followed by the full program:
- 'MENUET64'
- version number (1)
- entry point
- file size
- amount of memory reserved on load
- stack pointer address
- two other fields I didn't figure out what they are and what for they are.
I also looked into the most recent kernel sources I could find. It was about 30k lines of FASM assembly in total. It seemed like very clean read overall. It was easy to discover how things interacted together and everything was sufficiently commented to provide what the otherwise unstructured code didn't tell. It looked like it was simple to work with, despite the whole thing was assembly code.
I don't see any benchmarks that I could compare anywhere, so performance wise I only know the thing worked perfectly well in the virtualbox. The mainpage on the MenuetOS may be right on one thing though: It can be there's bit too many extra layers between different parts of an OS that complicate programming far beyond what is normally considered infeasible in other domains.
Could it be a feasible way to construct a system? Say.. the operating system took some abstract code and translated it into the target machine code, along you had some dynamic shared library scheme with runtime type annotations simple enough to be called in the abstract code. On the same layer you'd have the security, with sane enough defaults that you could download code from the web and run it.
I'd guess there's not enough momentum to switch out from Linux. Heck we almost stuck to the Windows! But you can dream.