There are only 2 things that annoy me in MenuetOS:
1. This awful flickering of the mouse cursor. I have not looked at the source of MeOS, but I don't think it would be much work to synchronize the redrawing of the cursor with the area being redrawn to avoid the flickering.
2. Lack of three simple controls - single line edit, multiple line edit, scroll bar. It is funny to see how every single app tries to tackle inputting text and scrolling.

Other than that, I think MeOS it is great!

Another one - the window borders (while dragging the window to another place) are flickering too. I see that OS redraws border slowly (2 GHz CPU). Maybe we must reduce rendering of this box by redrawing it only if mouse button released or cursor moved more than 3-5 pixels (not every mickey).(generalise cursor movement)

So, i started coding edit controls, but guess what, I got discouraged. I don't think that it needs them so badly. This OS is getting developed in the wrong way. There is no memory allocation function, yet there are several functions for sound output, different window styles, button styles, etc. Don't get me wrong, but for example in order to support its nice look, every icon from the desktop has its own thread. Why? Because at some point it could be clicked and the rotation animation has to show up. Sorry, for being so harsh, but visual appearance is the last stage of developing an useful OS. First develop a simple shell, then claim that this is the assembly OS.

take memory management from linux..

1)Removing the flicker requires a double buffer
2)Get GUI controls from SolarOS (also an ASM OS)
3)I can not belive that Menuet was able to survive so long without memory allocation functions... is this true? Oh anyway you can copy a very simple allocation scheme from SolarOS again.

Would it not be quicker to just rename solar to MenuetOS

Nope because they have conceptual diffrences and targets...

But since they are both full ASM OSes they can colaborate more to their both benefit

I was only joking, i think both OS's are a Great achievement, it's not until you try and make your own OS that you know how hard it to get a hobby OS running on lots of PC that are suppose to be standard.

"1)Removing the flicker requires a double buffer"
That's the best solution (but memory killing)
Memory management.... heh. Yes, Linux has great manager. But there is too much opportunities(i mean it has complicated code). We can take some concepts only to fit MEOS.

I did not look at the source of MeOS thoroughly (spelling?). I don't know about double buffer, isn't it already present? I mean only the cursor flickers, nothing else (I have no SVGA knowledge at all).

I think that the Sysfuncs idea has to be changed drastically - it looks unprofessional, the x*65536+y thing - is odd. Also, with good designed code passing the parameters by registers than by stack has not more than 0,00001 % percent improvement in speed. Doing it that way also simplifies implementing other languages.

The problem is thatpassing by stack NEEDS better designed code - likeyou said - but passing by registers doesn't need that much effort.

Passing by registers has one disadvantage - it depends on available registers, because eax is taken by interrupt and esp by stack. Then again, good code can compensate that .

Passing by stack has the following disadvantages:
1) Its slow -=> push [constantOrRegister] is random as seen from CPU. The BTB and other optimizations don't work on random read/write because when you push a value then the CPU needs to READ from that address, WRITE to esp and CHANGE esp address. Later when the values are passed to subproc, it has to READ from memory again and after what it does - also clean the stack.
2) Its complicated -=> The pushed values and count of them need to be remembered. Another register (ebp) is wasted to retain stack and you have even less registers to do the job meaning more memory access and wiser register usage. Every value has to be calculated from [ebp+something] and you don't have meaningful aliases or even register names to help you.
3) ITS COMPLICATED
Try reading proc when you know what registers it takes in and gives out - you know exactly only by looking, what it does to these registers. Now push all your values to stack and try reading the memory aliases. You don't know what mov edi,[ebp+8] or sub eax,[ebp+24] mean by just looking at the documentation. You have to take into account the +4 to esp that the call makes and this is too confusing and errorprone.

By the way: imagine. You transfer parameters through the registers. When OS start performing function, it needs free registers. So, parameters in registers SAVED IN STACK anyway. But i like parameters transfered through registers too...

Exactly my point, Night Rider , some functions need 3-4 registers, obviously you would need to push and later pop values when you pass the desired parameters.

Ok, lets agree on some middle way.
When you call some lowlevel API like SetPixel then every pixel can remain the same though you can use i.e. eax,ebx for co-ordinates and ecx for colour etc. You will not write to them.
If your API needs more than some critical 7-8 registers then of course you should immediately use stack not bothering about the minimum amount of registers.

One other thing: What I hated in C was the @$£€@€ I had to go through when I wanted to return more than one value. In assembly you can use all available registers to return values and maybe even seemingly infinite stack

I hope you understand my posts and see that I'm not a "fan" of register passing but I'm for it when it can save you precious clocks

Well the kernel woudn't necessarily have to save the registers on the stack would it? I assume MenuetOS uses a TSS, or some sort of process state table?

Madis731, yes you are right, but there is a lot of situations where 5-7 registers needed, and API interface must be solid, not multi-variant.

THEWizardGenius: " Well the kernel woudn't necessarily have to save the registers on the stack would it?". No, we are talking about other registers saving. Imagine, you call some long function and parameters are in eax,ebx,ecx and edx. This procedure needs registers too, yes? But it needs values in eax ebx ecx edx passed from user's program. So these values are stored somewhere and registers are used by routine. We are !!!!not!!!! talking about saving task state while switching between processes. Situation is different.

Oh I see. You're talking about when the procedure sends the registers, not when the system call needs to use some registers. Well I definitely think the MenuetOS API's are written stupidly, but there is no way to change them without changing backward compatibilty.

Ha! again nope. We are talking about system call, when sustem function needs PARAMETERS passed in registers, and it needs same BLANK registers to perform operations.

My point exactly. I'm asking why a system function can't use the registers as they are. It doesn't have to save the registers, as the registers are saved in the TSS. So when it uses the registers, then it checks TSS of the program that called the system call, and there they are, as they were. System calls don't need to save registers, because this is already done, in the TSS, when the system call is made, correct?

I'm sorry. I did not look very well MEOS code. If when syscall occures, task swith has performed, then yes. But for example, my OS does not change TR when syscall occurs.