Ville: I actually prefer simplifying the code when I encounter a difficult situation. We need to be certain about the functionality of the code, no matter how intelligent our tools are.
It looks like there's a brk (system call 64) but not a malloc? Isn't that a little cruel, especially when you have some pretty high-level system calls? How does memory allocation work in general?
Ville: Currently Menuet applications have a continuous memory area, which you can resize with a system call. The program binary is located at the beginning of the area and the rest is usable for data. This simplifies greatly any kind of garbage collection after application exit. The OS just needs to free the devices which the application may have been using. However, malloc is in our to-do list.
There has been some work on porting C libraries to Menuet. What's the current status of this effort?
Ville: The C library is released under GPL and it is mainly compiled as 32-bit code. Menuet64 is fully capable of running 32-bit libraries and applications. Currently there are Quake, Doom, Dosbox and other C-based applications that run in both Menuet32 and Menuet64.
Will we ever see a POSIX layer on top?
Ville: POSIX is no doubt a very powerful solution. However, with Menuet we try to keep the system calls at a relatively high level, like create_window and putimage, which generally results to easier and faster application development with assembly language.
Follow PC World Australia on Twitter: @PCWorldAu