Good point, Don. Let people vote!

Mike.dld Main word from now on should be together. Absolutely Mike, that's why I posted the above post. BTW, I'm not going to get involved in the development of uncommented/undocumented spaghetti code that is Menuet32/Kolibri. My vote is a complete redesign from scratch, putting together things learnt over the years. I see no future for either Menuet32/Kolibri. The fact people keep making programs when we haven't even got a basic font engine is beyond me ..... it's time to go back to the start, build the building blocks and then move forward!

I prefer write a new subsystem from stratch, test it and then completely replace existing one to new one. It is really more productive approach - users aren't waiting while we rewriting big subsystems. And eventually we rewrite all of them. Returning to the start will lead to months of discussion how new system should looks like. PS Design suggestions are welcome. But you have to learn KolibriOS code in order to give really usefull suggestions. PSPS Why I understand others code in KolibriOS although it is undocumented and spaghetti? I think current code contains enough comments and hints in order to understand it. Just try read source and ask me/mike.dld/Mario79 about difficult places. We will try to improve comments if possible.

Hi, I'm not a Menuet developer, just an intruder/observer, but I think you may want to at least consider what I have to say.... Basically, as far as I can tell, the existing MenuetOS kernel is crap. It has design flaws that will need to be fixed before MenuetOS can become anything more than a hobby/toy OS. I'll list the design flaws I've found (and the alternatives), so that you can see what I'm talking about and make an informed decision. Before I start I should point out that these observations are derived from the latest 32 bit kernel source code taken from sourceforge (the "kernel source" link at http://www.menuetos.org/download.html). I haven't looked at the Russian version (Kolibri). Also, I haven't studied this source code for a long time - I may have missed things, I may be wrong (I am human). If you think I am wrong, please double check and reply. Of course it's also likely that I've missed other design flaws, so if anyone has anything to add... THE SCHEDULER As far as I can tell, the scheduler is a simple round-robin scheduler without wait states or task priorities. No wait states means that if there's 100 tasks that are waiting for something and only one that needs the CPU, then all 100 tasks waste CPU time with polling. Normally, if a task needs to wait for something it sets a flag and the scheduler never switches to that task until the flag is cleared. For example, most OS's have a "sleep()" function where the task is placed on a timer queue and it's "waiting for timer" scheduler flag is set. Sooner or later (when the time expires) the timer IRQ handler will remove the task from the sleep queue and clear this flag to wake the task up when the time is right. For task priorities, one example is if the user is typing a text document while the computer is doing heavy processing. Normally, the text editor's task would be given a higher priority than the task doing heavy processing, so that the OS doesn't become "unresponsive". The way it uses hardware task switching would also limit the OS to less than 8190 tasks. This isn't so great. For example the Linux kernel has no fixed limit - it will run over 4 billion processes (if memory doesn't run out first, which is the real limit). THE IPC The IPC system is mostly broken due to the scheduler's problems. Consider this code (cut & pasted from "KERNEL.ASM"): sys_waitforevent: call get_event_for_app test eax,eax jne eventoccur newwait: call change_task call get_event_for_app test eax,eax je newwait eventoccur: mov [esp+36],eax ret While a task is waiting for an event, the CPU is constantly switching to that task, checking for an event and then switching to the next task. This is one of the ways scheduler wait states are used. Instead of the polling above, this function should set a "waiting for event" scheduler flag so that the task does not get any CPU time until an event arrives. Normally (for a scheduler that supports task priorities), when the "waiting for event" scheduler flag is cleared the kernel checks if the currently running task has a lower priority than the task that received the event, and immediately does a task switch to the task that received the event if it has a higher priority. This means that (for example), as soon as the user presses a key the keyboard IRQ handler sends an event, and this event causes the receiver of the keypress to get CPU time immediately. For the current kernel, the user may have to wait for the currently running task to finish it's time slice and for all other tasks to finish their time slices before the receiver of the keypress gets any CPU time. This could be a long long time if there's a lot of tasks doing heavy processing, and in general makes the GUI look like crap. MEMORY MANAGER To be honest, I couldn't find it. It looks like it's spread all over the place, doesn't support paging well (if at all), and doesn't even ask the BIOS which areas can be safely used as RAM (does it still ask the user????). Adding support for memory mapped files, allocation on demand or even swap space will be a nightmare. KERNEL API For most OSs there's an API entry point (a software interrupt, call gate, SYSCALL and/or SYSENTER) that does a "call ", where the selected function executes and then returns to the caller. I must have missed something here, but it looks like the kernel API is tied in with the scheduler somehow. When a task calls the kernel API it sticks some values somewhere and ends it's time slice, and the kernel searches for a new task to run and then, when the calling task gets CPU time again the kernel function is called. This would result in a huge number of unnecessary (and slow) task switches for a lot of simple kernel API functions. This is entirely insane (which is why I'm assuming that I missed something - there's no other explanation). SOURCE CODE This is a joke. There's barely any comments, there's no structure and there's no documentation. For example, while trying to find the memory manager (and giving up) I was wading though sound card initialization code and video code. What the <insert expletive here> is this doing in "KERNEL.ASM"? Wouldn't it make sense to have one file for everything to do with the scheduler, one file for everything to do with memory management, on file for video code, etc? The other thing is the lack of documentation - this has nothing to do with the source code files themselves, but should be a seperate set of files (perhaps in HTML) that describe how things are meant to work. The chance of anyone maintaining this mess for an extended period of time is close to none (especially if your brave enough to modify it or add features to it). CONCLUSION Do you really want to spend years developing an OS with this kernel as your foundation? My advice (unless the Russian version "Kolibri" fixes ALL of this) is to dump it fast and either rewrite the kernel completely or start with a good kernel from anywhere else. Cheers, Brendan

Well, Brendan... I must say that you'd better look into Kolibri's code instead. Your opinion then could be more valuable (but it still is). The only thing that is still on place is lack of documentation. All other issues you are pointing to are already (or 99.9%) fixed. If you're interested, you may get Kolibri source from here: http://kolibri.hut1.ru/downlo_e.htm (0.5.2.0) or just wait a few days until 0.5.3.0 is out and get it from the same link. Anyway, thanks for your investigation. Best regards, Mike.

I vote for redesign. I admit my intrest in Menuet has been waning for a while but now this... the 32 bit menuet.org forum, just gone. I have always considered my involvement as a learning experience. A fresh start could hieghten this learning experience for me and others. What I would love to see is a complete redesign. Many people have mentioned design flaws and room for optimization... if the current kernel could be broken down, docuemented, discussed and then pieced back together, I'm sure we would end up with an assembly OS that satisfies everyone. This would involve alot of documenting the assembly. Which I think many would agree is lacking so far. My hope would be that users of all levels would be able to take part in development f things were clearer. I would also insist on using CVS or Subversion as has been suggested before. A wiki would also be very helpful if used to its fullest extent. We have all seen what can be done by one person: A multi-tasking, graphical assembly OS that fits on a floppy. Lets see what can be done with a group of people... There are numerous assembly OSs out there already that we can borrow code from though I think Kolibri and Menuet would be the best resources. I still feel a deep connection for this community so I wish to know where everyone wants Menuet32 to go. If it disappears.. so be it, but if there is a desire to keep it alive and improved upon I would be much happier. Unfortunately the language barrier (russian to english) prevents me from following Kolibri too closely. I would rather take this opportunity to suggest/support redesign.

Hi, OK - I've taken a look at the source code for Kolibri 0.5.2.0. First impression is that the commenting isn't much better, but the source code structure is much better. The documentation (as noted by Mike) is still missing. The kernel API is fixed, but I'd recommend adding a check to see if the requested function is in the function table. For example, don't do this: and edi,0xff call dword [servetable+edi*4] But instead, do this: cmp edi,MAX_SYSCALL_FUNCTIONS jae .undefined call dword [servetable+edi*4] This will allow you to increase the size of the function table in future, but also means that any user level code that currently does "mov al,<function>" will need to be corrected. For memory management, it seems like it's mostly all there, but I didn't understand a lot of it (it looked like it's using a linked list of free RAM areas to manage memory, which is one of the slowest methods, but I could be wrong). For detecting how much RAM is present during boot it does manual probing, which is rarely reliable. The exact code used is completely broken for a number of reasons:- it does checks at 4 MB increments (on a computer with 9 MB of RAM it'll think there's 12 MB and crash later) - it doesn't account for holes in physical memory (e.g. if there's an "ISA hole" between 15 MB and 16 MB then it would think there's 15 MB of RAM, but currently it won't because it skips over the entire 4 MB block anyway). - if the computer has a lot of RAM it could think the video card's linear frame buffer (or any other memory mapped PCI device) is usable RAM. This won't be a problem unless the computer has 3 GB of RAM or more, but it's still a problem. - it will trash ACPI tables (although I honestly don't think you'll need to worry about ACPI for a long time) - it won't work reliably on some older 80386 and 80486 computers due to "bus capacitance". This can make it think that memory is present when it's not. This can be fixed with a dummy write (add something like "mov dword ,0x12345678" just before the "wbinvd"), but I'd still recommend detecting the RAM properly using the BIOS functions. For the scheduler, some support for wait states has been added (so the polling loops, like in "sys_waitforevent" in my previous post, shouldn't be wasting CPU time anymore). I don't think a waiting task can pre-empt the current task when the waiting condition occurs though. For e.g. if a task is waiting for an event and that event occurs, the CPU won't/can't do an immediate task switch to the task that received the event, so the event won't be handled immediately and the system will appear slow to react. Unfortunately I can't be too sure here as I couldn't find a "send_event" routine. There still doesn't seem to be any task priorities, so those tasks that do a lot of heavy calculation are still going to make the rest of the system look unresponsive and sluggish. The way it uses hardware task switching limits this kernel to 256 tasks (not "less than 8190 tasks" as I previously thought). The IPC still seems to suffer from the scheduler's problems, and doesn't appear to use the wait states at all. To be honest, I'm also wondering why there's events and IPC, and why the IPC system isn't used to send events to applications. Kolibri is better, and the next release may fix things I've mentioned, but (IMHO) there's still a lot that needs to be rewritten/redesigned if you want to achieve more than "hobby/toy OS" status... Don't get me wrong here - there's nothing wrong with hobby/toy OS's (DOS did rather well). I also hope no-one finds my comments too upsetting (I just think it's better to find the problems now rather than finding them after years of work). :) Cheers, Brendan

I must admit that I'm surprised, ok, now we have something to start with, and I THINK (just an opinion, y repeat this in every post hehe) that Kolibri OS can fix all the missing thing and bugs... I red all your explanation about the pros and cons about menuetos and I think it's time to make the poll, Thanx a lot, that was very helpfull, I hope you will stay with the cummunity for teaching us that kind of thing, it was very informative :)

Hi, I must admit that I'm surprised, ok, now we have something to start with, and I THINK (just an opinion, y repeat this in every post hehe) that Kolibri OS can fix all the missing thing and bugs... I red all your explanation about the pros and cons about menuetos and I think it's time to make the poll, Thanx a lot, that was very helpfull, I hope you will stay with the cummunity for teaching us that kind of thing, it was very informative Thanks, but unfortunately I'm just visiting (I have my own work to contend with). If you ever need good unbiased advice, I can recommend the Mega Tokyo OS Development forum. There's a lot of knowledgable people who post there, and I hang out there too. The best thing about it is that everyone is working on different OSs and has different ideas - you can get a wide variety of alternatives for any given question or very specific advice for a very specific problem... Hope everything goes well! :) Brendan

Well im glad we got another forum so soon. The closing of the m32 section for the old forum is in a way a good/bad thing. The bad side is we lost all the old data, but it at least got some people alive. This may sound a bit old (especialy comming from me :D ), but i still think we need someone thats going to keep this whole thing together (Mike, Matt and Mark). For the releases i can get the webspace (and maybe a CVS server, will try). Don: Soory, but your signature is a bit annoying. Mind changing it? For the russian team: I am retiring from the position of head of the international relations team (as assigned on the russian forum) and i suggest Mike takes that position. I am just sick of arguing with everybody about everything. If invited, i will come and have a talk with anyone, but no more trying to get the two sides cooperating. Best Regards

Didnt know you are running that SVN and i didnt think any other owner would be so nice to share it.

Hi guys. You, certainly, can not read my post and delete my post or in general delete me from a forum - it is yours there will be your right and your choice. But nevertheless can, at first you will be read? I offer to forget former insults and to conclude the peace. All my conflicts were with a Ville. Here him is not present or, at least, he here not the main man. I have no enmity for those who is ready to cooperate for general purposes. If you refuse the peace, I am more here not present. I hold promising. Choice to you With respect Mario79.

I'm glad to hear that now everyone are in peace.... :) I'm glad there are not problems anymore... Welcome Mario79 :)

hi mario79 ! ... welcome back to the m32 forums ;)...