Menuet Rewrite
Here is my proposal, for a Menuet rewrite: http://dex.7.forumer.com/viewtopic.php?t=184 If anyone want to help, lead, the project let me know. I hope other coders will start simular projects, from which will come a new and better menuet OS, for the good of ASM programmers and nonASM programmers users.

Wow! :D big step! Nice! To tell you the truth, the only thing I want is keep the project alive and if you have a programmers team who can do it, then it's great for me and Menuet (or Menuet4u :P) :) lets see what the other people think, remember that there is a Russian team of programmers that is really good and it would be great if they agree to suport the same project :)

Why don't you plan to change to call-gates instead of int 40h? Did you know that amd processors (and recently intel, tool) have extra instructions for supporting this? For this you need paging. Does Dex4u use paging? If not, how do you plan to use shared libraries later? How does Dex4u determine available memory? How does Dex4u determine usable and disabled memory ranges? Does Dex4u have a memory manager or you're going to take it over from kolibri? Does Dex4u have working DMA service? Can it do slow, but background memory-to-memory copy with DMA? Does Dex4u have elaborated interrupt management? What sort of IRQ prioritising strategy is used by Dex4u? Is SMP supported by Dex4u? Is APIC or only legacy i8259 based one supported? Is there ideas about supporting interrupt sharing? What sort of device driver interfaces have already been worked out for Dex4u? Is 8254 based timer used by Dex4u? What do you think why menuetos is so slow? What do you mean it is a good idea to keep GUI in the kernel? Any imaginations how to speed up networking? Has Dex4u an own bootloader or can it be booted with any of the well known bootloaders like e.g. grub.

I will answer each of your ? in time (no time now), but you miss understand what we are going to do, that is we will rewrite menuet, but we will use Dex4u as a bootloader, that way we can have the best of both world. Whats in Dex4u has nothing to do with the menuet rewrite, thats why its call a rewrite. Dex4u will load Menuet to say, 8MB and give control to it.

Yeah, you're right I perhaps missed the point. Till now I believed that Dex4u and MenuetOS will shape a new hybrid OS. But if Dex4u is purely and simply a bootloader and as such it will be swept out from the memory as MenuetOS starts then it no longer bothers me. Thus you don't need to answer my questions.

No we do not want any type of hybrid OS, we would use Dex4u, as some people would use GRUB.

Menuet needs the CD support. I'm working on the kernel to see it I can improve the way the mouse pointer interacts with the apps. last K version from the Russians has mouse problems. "It will cause OS to lock up." Matt

Yes menuet needs the CD support, :), the main things wrong with menuet is not so much, thinks like we need to change from int 40h to call-gates etc. But be more useable for users, i need to beable to read/write from any program or the desktop to floppy, hdd, cd/dvd(read), usb drives, i also need a module interface, so drivers can be load on the fly or things added, and i need a web browser etc. And from a programmer point of view i need the code to be split up into inc files. 80% of the kernel should look like a list of inc file, So programmer can get to the bit of code they want and maybe change the whole inc file. At the moment little problems become big problems, because you can not trace the code down. @Matt9876, good luck.

Hello, I'm entering the debate with mixed feelings. I like what Dex has put foward, ie using Dex as a subsystem of a larger OS. But then over the weekend I had other ideas (please hear me out). Let's start with the boot process. One of the big problems with the old MeOS was the lack of dynamic drivers. They were simply assembled in and contributed to physical bloat. I thought of a nice process, similar to grub, but with an extension or two. Basically, you'd have the bootsector which loads the stage-2 boot code binary. This binary switches to p-mode, enumerates devices (like on the PCI bus) and loads drivers into memory, as well as GDT/IDT etc. On the aesthtic side, it fronts up a VGA/VESA boot screen and gives a choice of mode (ie CLI or GUI). It also obviously loads the kernel into place and sets flags that say what devices are onboard. Although a smarter choice would be some sort of UPnP function. Filesystems and Device Drivers. I think adoption of the read/write interface of *nix is a good idea. Open a device like a file and perform an operation. It is very simple and easy to learn. Pathing would just be the same as before (ie /HD/0/ for the primary part of a HDD, much like the /dev FS works). In another topic, Brendan noted inefficiencies in the scheduler and other important coponents of the operating system. Something that I noted to myself was that using round-robin multitasking was bad most of the time, especially since icons on the desktop were in fact, their own processes. I vote for optional passing-on of processing time. In the above example, instead of wasting 100 cycles (or whatever time slice is given to each process) on polling to see if the state has changed, it could poll, then co-operativly deselect itself as the active task if not needed. Also, with the problem of priority processing, how about a hybrid between round-robin and priority processing. Basically, it be increased probabilty of selection by increased priority. I can come back with an algorithm later. System calls can be simplified by passing a pointer to a structure containing parameters of a call. Then fill eax with the call# and ebx with the struc ptr and call a software interrupt. Or even then put the call# as the first element in the struc and so on. Other things I noted were that the source needed more modularity (MeOS was atrocious) and commenting. How about when writing code (in structured functions), people put a small to medium note saying that this function does this, requires this from that, and refers to an external source about how and why this function is needed. That way people can dive into the source (as most asm coders would) and can refer to external documents on the inner workings. A prime example for someone learning about OS's would be enabling the A20 memory gate. The header would say that this enables the a20, and refers to an outside document for explaination why (to enable more that 1Mb of addressable memory). K.I.S.S. is an ideal methodology for design. Documentation should be profuse and of quality, not "See Code". Licensing: GPL and LPGL sucks. Why not PD (public domain)? I'd like to see what people think, especially what the programmers think. Is this too big a task? Solidus. No

I have been looking over the kernel code and i have come to the conclusion, that it would be near impossible, to adapt the kernel, as only the person who wrote it or has been studying it for years could understand it (no comments), the code its self is written in a nice way, it just that you have no idea of whats stored at ******* address or why you do things like hard code "add eax,65536*1-1" :? . So the only way to make it work, is to copy the way Menuet does things, calls, program lay out etc, but fully recode it underneather. But we could take this opportunity to do things differant, but then it will not be compatable with the old menuet. Whats your thoughts.

Just about my post up the top there, assuming a CLI interface is accessable, a (not THE) new format would go sort of like this: org 0 use32 include "F_Struc.inc" ; insert app header here ; @@: mov eax,10 ; 10 is a theoretical call# for Waiting for a KeyPress/GetKPress mov ebx,MyF10Struct int 0x40 mov al,[MyF10Struct.keypressed] ;Move the key that was pressed into a STDOUT structure mov [MyF25Struct.outkey],al mov eax,25 ; 25 is a theoretical call# for putting a key into the Standard Out interface mov ebx,MyF25Struct int 0x40 jmp @b MyF10Struct F10_Struc MyF25Struct F25_Struc "F_Struc.inc" has standard sized data structures for interfacing with the kernel. Behind the scenes, when the app calls a soft-int, the handler copies EAX and EBX into a temp location. It tests A for the call number, and now that it knows the required parameter size for that call#, it loads the required amount of data from ptr->EBX into a temp workspace and goes to work. Just my thoughts. Solidus.

@Solidus117, Nice idea, like anything, will need testing to see if we run into any problems :) . PS: @Solidus117, I am looking for a team leader, to put forward to lead the "Menuet4u" Project. I think your the right person for the job , are you interested ???.