Hi. I've been dabbling with the idea of writing my own OS for a long time now, and have come to the conclusion that writing my own kernel is not feasable (i learned the hard way... over and over again). I am wondering if MenuetOS would be a suitable base - although my OS ideas are sorta microkernelish, i was hoping to include raw hardware access in the kernel (eg video driver), and ive noticed MenuetOS has a lot of this.

I understand that MenuetOS lacks a memory manager, however i was wondering what this actually means. I dont need a malloc (ill do that myself), but does MenuetOS supply applications with a [realistic] way of requesting another 4kb page or something?

Other than MM, MenuetOS seems to provide everything im looking for (my OS booter could be a GUI app, how cool is that!), can anyone think of problems i might encounter?

By the way, the OS i am planning is forth based (JIT compiled, not interprited), highly VFS oriented (it will only use the MenuetOS filesystem for booting, although a server could easily be made to provide access to it). The OS should also have a GUI - again, not relying on the MenuetOS GUI, perhaps using the gs direct graphics access.

PS: i think ive mentioned such ideas in here before, however this time i'm serious - I have working simulator for my OS's forth applications, and I have almost perfected the base API (excluding VFS functions, and obviously GUI, etc. dont fit under "base API").

A system function expands the memory an application is using. So if you start with a memory space of 0-0x10000, just a call to system function gives you a linear memory from 0-0x80000, or whatever you want.

So saying that Menuet lacks a memory manager, is clearly an ignorant over-statement. It's just a bit different, in a good way Processes memory isn't fragmented.

http://www.menuetos.org/www/eng/sysfuncs.txt - function 64



Stay withing GPL rules.



A full-screen application for MenuetOS would do the job.

Ville

Okay, i think most Unices do that too, and malloc is implemented by calling it whenever it runs out of memory. Is this efficient enough for regular calls (just checking it just modifies the app's page tables, and it doesnt like copy the whole process into another memory space or something silly like that)?

I'll stick with GPL, although ill probably write it mostly in C (the forth compiler and VFS anyway) and of course forth, so you ASMers might not be too interested. Or if you meant dont violate the GPL rules, i wont. hopefully i wont even need to touch the kernel or any MenuetOS apps - other than maybe hacking FASM to compile things w/o the GUI.

I understand the screen can be accessed by gs:, but how can I prevent the mouse from clicking MenuetOS buttons? I guess if no MenuetOS windows are open this'll be ok, but for flexibility i should consider it. I could make a full screen window, but then how do i stop the window title bar from interfering with the mouse?

You just don't load anything up.
The titlebar and all the icons are loaded at boot and you just delete these entries and use yours.

Applications memory resize doesn't affect the applications internal memory locations. Process will always start at location 0x0.



You can define the window as non-movable ( sysf 0 ).

Thanks.

I've decided to use C instead of Forth (i asked myself why i chose forth in the first place), but im still retaining most of my original plans, so hopefully this should all go smoothly. Havent started coding yet though - I might even go back to Forth.

Would I encounter any troubles getting GCC (+NASM maybe) to produce MenuetOS executables? I assume ld (on Linux) can produce flat binary.

I'll try and get something interesting going this weekend (after I finish my science project). Im hoping to have a [very basic] VFS (done via IPC with the "main server"), as well as malloc, free and clone going soon.

My applications will need to be able to find the "main server"'s PID. The only way i see to do this is for the main server to store it in a MenuetOS RD file, is there a better option?

Is anyone else interested in such a project (multi-server Unixish (but not too much Unix) OS with VFS built on top of MenuetOS, hopefully followed by a GUI and some basic tools)?

I've removed the GUI from the kernel (mostly a process of removing the GUI parts, compiling, seeing what stopped it from compiling, changing the line to remove references from the GUI parts, repeating from step 2), and ive got GCC compiling a menuet app.
I'm working on the IPC abstractions now, then I'll do the file server and add related library code. I'll have to do a linker (elf, perhaps, maybe elf and pe, so windows users can easily compile stuff for it).

T'is emerging...