My this is a little text box...

Anyway, I haven't had a chance to try MenuetOS yet (I have no floppy drive), but I was looking over the system call list and I had some questions and comments, well, mostly comments...

I wasn't going to say anything at first, but then I saw the line that reads "The Assembly Language Programmers OS!" and thought "anyone who makes a claim like that has got some responsibility." So...

I'll start with the TCP/IP stack, since it's the worst...

First, why is there a seperate poll for sockets, why isn't it part of "wait for event?" It seems to me that the best one could do would be to call "wait for event with timeout" and just keep polling the network socket, which just seems like a bad idea. It forces you to make a tradeoff between network lag time and wasting system resources.

Then I see that there are seperate calls for closing TCP and UDP sockets. Why? They take the same parameters, and since both TCP and UDP share the same read call, the socket numbers must be unique.

How exactly are you implementing a datagram service via a system call that reads one byte at a time and offers no indication of datagram boundaries?

Why one byte at a time? Does someone not like using pointers? Making all of those system calls just seems wasteful of processing time.

Why isn't the network code capable of splitting up large TCP writes? It seems silly to pass this task along to the application.

When you close a TCP socket does the stack understand that you don't want to read anything more from that socket? The particular text I'm reading is a little ambiguous. It says "When closing a TCP socket, don't forget that the other end
may continue to send data, so the socket may remain active for a few seconds after your call." Does it mean that I may still have to continue reading data, or is this just referring to how you cannot re-use that port number until the connection is good and closed?

I see in many places in the system call list stuff like this:

ebx [x start]*65536 + [x size]
ecx [y start]*65536 + [y size]

Doing this sort of thing seems quite wasteful. It leads to people writing code like this:

mov ebx, [x size]; shl ebx, 16; mov bx, [x start]
mov ecx, [y size]; shl ebx, 16; mov cx, [y start]

...only later to have the kernel have to do this...

mov [x start], bx; shr ebx, 16; mov [x size], bx
mov [y start], cx; shr ecx, 16; mov [y size], cx

...which is just silly. Why not just put the data in memory somewhere (where it probably was before you loaded it into registers) and pass a pointer instead?

04 = WRITE TEXT TO WINDOW

ebx [x start]*65536 + [y start]
ecx color - 0x00RRGGBB
font (0 or 1) - 0xF0000000
edx pointer to text beginning
esi text length
ret: nothing changed

I simply fail to see how this could work with anything other than a fix width font and a specific size window. There's no mechanism to know how much text will fit in how many pixels, how many pixels high the font is, etc. Of course, I can't really claim to care either. Proportional fonts aren't all that important, and not really worth the complexity in my opinion. However, this does leave the application assuming a specific font size, and from what I've seen in example code, I doubt any of the software knows how to re-wrap lines to different window widths, assuming it's even possible for the user to resize windows. (which I haven't seen any evidence that it is)

12 = WINDOW REDRAW STATUS

ebx 1 start of redraw, 2 end of redraw
ret: nothing changed

This one scares me, just because every possible reason I could think of that the kernel would want to know this is very, very bad. If I had a floppy drive, I'd be tempted to write an application that calls "start of redraw" and never calls "end of redraw" and see if it locks up the user interface.

24 = CD AUDIO

ebx 1 - play from ecx 00 FR SS MM
ebx 2 - get playlist size of ecx to [edx]
ebx 3 - stop/pause play

Nothing to indicate which CD drive to play?...

25 = SB16 - MIXER I

ebx 1 - set main volume cl [L]*16+[R]
ebx 2 - set cd volume cl [L]*16+[R]

27 = WINDOWS SOUND SYSTEM

ebx 1 - set main volume to cl 0-255
ebx 2 - set cd volume to cl 0-255

28 = SB16 - MIXER II

ebx 1 - set main volume to cl 0-255
ebx 2 - set cd volume to cl 0-255

I'm not sure what happened here. I guess they had the first, then someone made a _seperate_ one for windows sound system cards, then someone made a third one that works like the second? No controls for wave or midi?

35 = READ SCREEN PIXEL

ebx = pixel count from top left of the screen

return : eax = 0x00RRGGBB

Someone couldn't be bothered to take our X and Y values, and do a simple Y * L + X ? I just don't know what to say.

37 = READ MOUSE POSITION

ebx=0 screen relative
ebx=1 window relative
ebx=2 buttons pressed
return in eax

Wow, a race condition with a user interface device. This is bound to be annoying, especially since the user is unlikely to catch on to what's really going on.

42 = GET DATA READ BY IRQ

ebx : IRQ number
ret : eax number of bytes in buffer
bl data
ecx 0 = successful data read
1 = no data in buffer
2 = incorrect IRQ owner

Aparently you program the kernel so that when IRQ N occurs, it reads from ports A, B, and C, and saves the data, then your program notices via "wait for event" that something was read and you read that data here?

Why not just implement real signals? This isn't going to work with more complex I/O.

47 = DISPLAY NUMBER TO WINDOW

ebx = print type, bl=0 -> ecx is number
bl=1 -> ecx is pointer
bh=0 -> display decimal
bh=1 -> display hexadecimal
bh=2 -> display binary
bits 16-21 = number of digits to display (0-32)
bits 22-31 = reserved
ecx = number or pointer
edx = x shl 16 + y
esi = color

Why does the kernel have an STR$() function? This almost makes me cry.

What's really sad is it doesn't seem to have a "display as many digits as necessary" feature.

Plus, dereferencing a pointer is as easy as "mov ecx, [ecx]". Including that instruction or not (especially not) is always going to be faster than having the kernel check bl and decide wether or not it needs to do it.

51 = CREATE THREAD

ebx = 1 ; create
ecx ; = thread entry point
edx ; = thread stack position

ret: eax = pid or 0xfffffff0+ for error

From what I can tell, this works similarly to "fork" except that the new process either has an option to or is required to get it's own GUI window. However, I didn't see anything that looked like "exec." Is it possible for programs to start other programs?

55 = SOUND INTERFACE

ebx = 0 ; load sound block
ecx = ; pointer to (default size 65536 byte) soundblock

ebx = 1 ; play (default 44 khz 8 bit mono) sound block

ebx = 2 ; set format
ecx = 1 ; set play block length
edx = ; block length

Looks like you can play little one second beeps and whatnot, but as far as continuous music goes, it doesn't look like it's intended to play continuously. It might, however, but I'm not sure what this does if the buffer is full when you call it.

57 = DELETE FILE FROM HD

ebx pointer to filename : 11 capital letters
edx pointer to path : path db 0

Why do we need to seperate the filename from the path?


I am generally confused by the whole thing. It's the job of an operating system to do things on behalf of applications, yet from what I see the applications have to do a whole lot on behalf of the operating system. I would guess that this is because it's assembly language, and since everything is more difficult in assembly, programmers tend to leave out anything that doesn't absolutely have to be there in order to get things done faster. However, in the end it just makes every application programmer have to do it instead of just one system programmer.

I also get the impression that when someone makes a new API call they aren't planning ahead for future expansion, but rather making it do only what they plan to make it do at that moment, e.g., the three different mixer calls, because the previous ones didn't take into account the possibility of future expansion. Nothing seems to be designed to handle more than one device, probably because whomever wrote the API didn't plan on making it support more than one device that day.

There also seems to be some needless, even counterproductive, optimizaion (like packing X and Y cooridinates into a single register) and yet complete lack of optimizaion elsewhere (like reading network sockets one byte at a time).

Anyway, I think it's awesome that someone wrote an operating system entirely in assembly, but the whole thing just seems thrown together, like there wasn't much planning in it at all. I definately don't think it's deserving of the title "The Assembly Language Programmers OS!"

I will however definately try it out once I can scrape up a floppy drive, as it looks like a lot of fun. I just think it needs some serious work. (and not new things added, but current things fixed)

Uncontrolled mushroom growth is just wonderful

Let's build Rome in a day! (or two...)

Cities are (these days) usually planned, at least a bit, before they are built . Btw, have a look at Pompei... even though it's a very old city, it's evident that it was planned *very* carefully before it was built.

Pj, It's OK to criticize, others work, if first you have shown that you have done better, I have not coded for MenuetOS, but am making my own OS, so know how hard it is to get to MenuetOS stage, I have try 90% of floppy OS's and other then maybe "QNX DEMO disk", there is nothing that can torch MenuetOS.

PS: If you are going to criticize some thing at least try it, or do you not know how to burn a floppy image on to a CD ?.

\\\\||////
(@@)
ASHLEY4.

Batteries not included, Some assembly required.

What, I have to meet prerequisites first? That's silly. And why should I try it first. So that I can say "well, it is fundementally wrong, but it looks so cool it makes it all alright."

I origionally wrote most of the above in an email to my friend who told me about MinuetOS, in a reply he says "The lack of select would explain their telnet client acting as it does." So I imagine someone else has certainly noticed what he has. Yet is the network stack going to be fixed? It doesn't look like it.

Looks like we have this:

1) Maintain compatibility within Menuet.

Small improvements ( ie. changes ) to system calls propably break
compatibility and make already fine working applications useless.
So maintain 100% compatibility to existing system calls and applications.

So it looks like the #1 rule of contributing is "don't remove the broken shit and replace it with something done correctly." I just can't get into something like that. If applications are going to be broken, perhaps then they just need to be fixed afterwards. I don't see how someone could look at those system calls and not expect to have to rewrite anything that uses them. They're a mess.

My friend also said "The reason I like this thing is that it was not designed to be like anything else." That's certainly the reason I was hoping to like it. I was expecting that when doing things differently one would also choose to do them better. Instead it seems someone decided on a whim to do hard disk access via four directories in the system tree, completely forgetting the possibility that there might be more than one partition to a disk.

I've thought of writing an operating system myself in the past, but I never really got past the planning stage, so I have to say that the people who have written MinuetOS have really done something extraordinary here. I just wish they would have had a planning stage at the beginning, because I'm sure they could have made it so much better. They're obviously talented people.

it sounds terrible to all of us (i like menuetOS, a lot) but i think that owr answer should be... "hey Pj, thanx... we will look at that problems..." we need a lot of points of view.... and it's true, that "bugs" won't be fixed in two days, but the will be fixed in a future...

good bye and happy coding

You have two CD drives and no floppy? Frankly...

I just use my SolarOS
And keep an open eye on MenuetOS...
IMHO it will improve over time.

What about DVD drive, CD burner and no floppy? Or a DVD drive and a DVD burner? (et cetera). Many machines are shipped without floppy drives these days, and with bootable USB pendrives, who needs floppies anyway?

IMHO you do need floppy's ...

At least for OS development

I test OS hundreds of times per day...it will take too much time to Start/STOP the USB pen drive device and it will burn it out much too fast from repetitive writes on the same location.

Besides most older PC's are not able to boot from and USB memory stick. And i can not afford to keep an newer PC there just to be rebooted for OS testing all day long.

So IMHO memory sticks are a little unpractical for such things...

Floppy disks are a nice a good device that has its share on small repetitive data transfers... not to mention the costs of a floppy disk compared to memory stick.

Of course when you need bigger data transfers... memory sticks are quite handy

Honestly i also have things against Menuet OS
But i keep my mouth closed until i have done better. That is why i do write my own OS.

Probably the best way is that everybody does its own OS and this way he/she is happy

Yes. I Agree, altought I consider a Interactive help is suficient .

I still planificating it , have some ideas.. that in some way I dont what to share, but others days I what to .

It's just a blast to see what happens on the forum.

Why can't Pj just get a bootable cd and try MenuetOS (it's NOT Minuet)

Help this guy and he can do more than be critical.

Anyone that can find all that "wrong" by just reading sysfunc needs to help.

(Sorry 'bout talking about you while you are in the room)

http://menuet.2.forumer.com/index.php?showtopic=341&st=0&#entry2143

Get a taste from one of the "el toritos".

bunch of our archives and iso's @ http://www.wemakeitbig.com/meos/

You can develop using just HD.

Welcome Pj, and Happy New Year to All !

[quote="Pj"] I just wish they would have had a planning stage at the beginning, because I'm sure they could have made it so much better. They're obviously talented people.[/quote]

In the beginning there was Ville.

Then those who knew and learned.

But "THEY" in the beginning ?


Happy Coding !

Hi there,
I've been using MenuetOS for a while and there is nothing wrong in packing 2-bytes into DWORD. -ARE YOU an assembly programmer?- Ok, the fact is that it really packs 50% which is a good thing but you were concerned about unpacking. You mentioned something about "shl" and "shr". Well these aren't neccessary if you use only 16bit part of the four famous registers ax,dx,cx,bx.
Tell me, how are you going to speed up the process of reading when you have 8bytes instead of 4? You have to make TWO reads from the memory and also waste TWO times more space.
Were you planning to read mov ax,word[esi] and dx,word[esi+2]. Modern computers usually read 4bytes at once anyway so you are wasting bandwidth. WHY???

and it takes less code also!

I won't even bother trying to argue on the other subjects - you haven't tried this OS and making assumptions - many of them totally wrong.

Madis, 16bit operations are slow, and as for Modern computers usually read 4bytes at once anyway so you are wasting bandwidth., read up on cachelines and L1 cache ^_^

> Were you planning to read mov ax,word[esi] and dx,word[esi+2].

No, actually, I was planning on doing the whole thing with dwords.

You see, if I have one number in the higher 16 bits of eax, and another in the lower 16 bits, then what I really have is data in eax that I can't do any calculations with.

There is ax, but there's no equivelent for the upper half of eax, and so putting things there is never worth the trouble of getting them up there and then getting them back out. It makes much more sense just to keep them as two seperate dwords.

Since nothing worthwhile can be done with eax in this state, I would never have the numbers like that in my program, and for the same reason, the kernel cannot make use of them in that state either, and so what we have is me packing the numbers together so that the kernel can unpack them, and it's just a big waste of time.

> ARE YOU an assembly programmer?

http://www.xersedefixion.com/softer/

Sorry I doubted about you. Seems to me that you know your stuff. But you still might want to try it out first before making such claims - the documentation btw is not 100% ready and actual

I know that 16/8 bit operations are slow on modern PIV-s and beyond - the main course is set to MMX/SSE but I would get over this packing issue with this kind of operation:

because the most of the time when dealing with screen and pixels you won't settle for just 1 or 10...
these unpacking commands takw 0.5 clocks each (was the latency 1?) so they are pretty fast (correct me if I'm wrong - again:P).

Criticism is good and welcome if it is sincere. To be sincere Pj must do some first hand testing and the lack of floppy drive isn't a valid excuse.

My opinion is: Do some research and post suggestions, not tasks to be completed for others.

Sorry to barge in like this, but Pj...why not try using Bochs?
It worked well for me, took a long time to get used to but I manged to get some decent speed with MenuetOS.