flat assembler
Message board for the users of flat assembler.

Index > MenuetOS > Could MenuetOS's kernel be used as a micro-ish-kernel?

Author
Thread Post new topic Reply to topic
compilax



Joined: 18 Feb 2004
Posts: 56
compilax
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").
Post 21 Aug 2005, 05:33
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
Ville



Joined: 17 Jun 2003
Posts: 231
Ville
Quote:

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?


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 Smile Processes memory isn't fragmented.

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

Quote:

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?


Stay withing GPL rules.

Quote:

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.


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

Ville
Post 21 Aug 2005, 06:05
View user's profile Send private message Reply with quote
compilax



Joined: 18 Feb 2004
Posts: 56
compilax
Quote:
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.


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?
Post 21 Aug 2005, 07:14
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
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.
Post 21 Aug 2005, 08:30
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
Ville



Joined: 17 Jun 2003
Posts: 231
Ville
Quote:

Is this efficient enough for regular calls ?


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

Quote:

I could make a full screen window, but then how do i stop the window title bar from interfering with the mouse?


You can define the window as non-movable ( sysf 0 ).
Post 22 Aug 2005, 03:55
View user's profile Send private message Reply with quote
compilax



Joined: 18 Feb 2004
Posts: 56
compilax
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)?
Post 23 Aug 2005, 08:42
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
Post 23 Aug 2005, 12:45
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
compilax



Joined: 18 Feb 2004
Posts: 56
compilax
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...
Post 27 Aug 2005, 04:15
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.