Why a monolithic kernel? Ville: When you look at process execution at a more detailed level, Menuet kernel has features from both micro- and monolithic scheduling. For example, applications graphics access is implemented monolithic style and networking is implemented like in microkernels. Monolithic kernel is a reliable backbone for all the other features.
Why a real-time OS? That seems unusual for something with a GUI. Ville: Menuet task-switching is a combination of pre-emptive and event-based scheduling. Every process has a maximum execution time which is interrupted by the timer scheduler. With a built-in GUI, this doesn't have any down-sides, since the amount of processing doesn't really change whether the multitasking is real-time or something else. So it really comes down to the actual GUI design, not that much to the scheduling type.
One of the main hassles of writing an operating system is the driver support. How did you pick the devices you support? Ville: In general, we try to support the most popular device types first. For example, we support USB video, storage and printer device classes, which gives us the widest range of support. But more drivers are needed before hitting the 1.0 mark. Currently we just have a minimal set of drivers to add network applications, for example.
How well does Menuet deal with multi-core systems, given they seem increasingly common? Madis: MenuetOS is still using a single core or a thread of a multicore system. There have been tests to enable the additional cores and threads, but this needs some work with the kernel before we get it working.
Menuet has Ring 3 support. What exactly is running in Ring 3? Just applications? Ville: Only applications are running in Ring 3. Kernel and drivers are running at Ring 0.
How do you debug when working on Menuet? Madis: My personal favourite is QEMU, which runs MenuetOS nicely. For single applications there are some approaches. One is IPC, in which case the other program listens to the debug-strings or numbers sent. Another possibility is to halt the program's execution (jmp $) at the interested spot and use QEMU to inspect the registers and memory at that time.