Well, since everyone was so insistant that I try it, I burned a copy to CD and ran it that way. My opinion remains the same, if not lower...

My expectations wern't that high, but strangely they wern't met either. Rather than go into detail, I'll try to sum this up in just one paragraph.

I need to tell it how much RAM I have, the number keypad doesn't work in stackconfig, windows flicker when their contents are changed, each icon on the desktop is an individual process, the line drawing code draws awful lines (a good routine drawing from 0,0 to 16,2 would put 4 pixels on line 0, 8 pixels on line 1, and 4 pixels on line 2). No cursor in text entry fields, arrow keys don't work either, loading a large number of processes seems to fudge up the button clicking code, attempting to quickly move a window which isn't the foreground window nearly always causes the mouse click to be registered somewhere else, the IPC program doesn't seem to work. Now what's design flaws and what's simply bugs I can't really say.

I couldn't get networking to work (perhaps my network card isn't supported), but if I had, judging from the network stack's API, I imagine I would have been even more disappointed with it.

So in the end, the lack of planning definately shows through. However, I never was concerned with how the software on it works anyway. When I first heard about it I was hoping for something I could write programs for, but I just can't touch an API like that.

That's the kind of hacked together nonsense I had to deal with back in the days of DOS, and now that I've been programming under Linux for years, I'm just far too used to having better. It's really quite an odd feeling since I'm of the opinion that Linux pretty much sucks (you wouldn't believe the shit you've got to do just to be able to use a VGA mode in Linux), yet when I look at Menuet's API I actually like Linux. Menuet just reminds me of what DOS would be if it had multitasking capabilities and a GUI.

That may be the entire problem right there. I suspect the developers have never programmed assembly under anything besides DOS, and so they've never seen better. They're used to calling DOS interrupts which were always just strange hacks just enough to say that the feature they provided access to was there. They're used to not being able to use shared libraries. Despite a lot of Menuet's APIs being really bad, they're far better than anything they've ever had before.

I wonder, is anyone interested in discussing OS design, trying to come up with an incredibly good design for an assembly language OS? I've got a message board I've been itching to find a use for, and though I have a lot of good ideas, I'm sure I haven't thought of the best, and quite likely everyone has some ideas that are better than some of everyone else's. It's unlikely I'd ever make an operating system out of the ideas we end up with, but someone else might, perhaps even the Menuet developers might like some of the ideas enough to add them into MenuetOS.

My forum is at http://www.xersedefixion.com/forum/
Just disregard what's already there, it's a dead discussion. I'd delete it but it was just posted yesterday and I feel like I should wait at least a few days.

I'll type up my ideas there some time later today. If anyone else is interested, don't feel like you have to wait on me before posting your own ideas. And don't be afraid to use HTML, it's got a syntax checker better than anything the world has ever seen.

OK, I followed this disscussion since its begining and have to say I am agree with almost everything Pj wrote here. And MenuetOS team have to read carefully his postings and even to ask for more, because it's a shame MenuetOS developers to develop applications for MenuetOS on Win32 emulator...(just for example). Instead of writing some common widgets, dynamic memory, at least some common driver interface and dynamic loaded libraryes, the menuet developers write what??? Right - port of Doom and DOS games and funny 3D maze and fancy sstupid menues (that also have bad behaviour).

Regards

Hi there!

Maybe I'm not so good in English but I'll try to say something more than one sentence.

I'm with Menuet since previous year and wrote some programs for it. Maybe they're some kind useless, maybe the're non-professional but I have to say 'Thanks!' to Menuet because it teached me Assembly. MFAR was my first program written for Menuet and my first program written in Assembly and I don't care if someone don't like it and if someone asks me 'Why console??? Why not GUI' (OK, nevermind that). I've been using MS-DOS before during ~3 years and yes, Menuet is better . I don't saying you I had no problems with Menuet when writing MFAR - lack of some functions to the fore.

Now about emulators. MeOSEmul was my IIRC 2nd program dedicated to Menuet. And once again, I wrote it to learn more Assembly. Noone saying why're you using Linux when there're a couple of emulators e.g. Line or a couple of x86 machines emulators e.g. MS VPC, twoOStwo, VMWare WS etc. It's your own choice to use it or not. Another question is what I really have to do? Modifying kernel to make it better? No way! I didn't even thought to write my own OS ever, not saying to modify someone's else.

What to say nowadays... I'm still here, with Menuet, still working in a real system (without any emulators) and still coding for it and yes, I'm still learning Assembly . My current project is ATi VCs driver and I'm writing it for russian distro (BTW have you tried it?) because official has no drivers support yet (yeah, your truth here). Some inconvenience is still there but who saying it must be easy?

Some months ago I asked Ville if he wants now, after several years, to rewrite Menuet from scratch, his answer was 'Yes'. I think you got the point now, right? I'm not saying Menuet is the best OS I've seen ever but it also not so worst as you might think. It's a hobby OS, not a professional work and it's a work of almost one man. IMHO Ville was learning how to write OSes like me was learning Assembly. Not bad for the first OS written, how do you think? Try to recall you first program...

Best regards, mike.dld

Mike (and all).
Don't get me wrong. I like MenuetOS (except those new interface with round menues ). It is really great product and proof-of-concept. But several years I see very little advance in it and this really make me sad.
And it is even worse when here come a man, that says true things and some of us instead of welcome and say "thanks" begins to assault him.
If the problems in MenuetOS are visible even reading documents and looking sources - that is bad!
So, the only decent reaction to the Pj posts can be: "Thanks man! Do you want to join the team?"

That is my opinion as a side observer. I am not a part of MenuetOS team in any way and of course you can simply ignore my opinion.

You said: "who saying it must be easy?".
That is IMHO totally not correct. Yes, it can be hard, but it MUST become easer and easer! But it never happens with MenuetOS - it simply becomes more fancy, but never more easy. (OK I never tried some of the russians distributions - I will definately)

Regards.

P.S. Happy new years for all of you.

I agree with Pj. Lack of unix-like system calls show up when you're trying to code good app. For me one disadvantage of kernel is active polling instead of using wait queues and semaphores. When I code network app in unix I use select() to wait for data instead of active polling, and application doesn't waste resources for checking if data came in and reading them byte by byte. Also distinction among files, sockets and devices is not good, because it creates bugs,when you use close socket function for file handle by mistake.
I also agree that user has to code most of the things that kernel should support. For example I had to code tons of unix emulation layers for C library: using real file paths, emulating file access by handle, emulating bsd socket layer API, emulating standard input and output (debug board), emulation of real exec (partial), emulation of users and groups (well, that's not needed so much), emulation of passing parameters and environment to application (uses hack where args & environment are stored in proxy file). All of those things should be done by kernel.
I also don't like packing 2 words into 1 dword. It messes up the code. For example C compiler has to get 32 bit args from the stack and pack them into 2 word pairs, which takes a lot of time and is unnecessary.
GUI is not necessarily better than console for everything. In unix console you use basic tools which does the job well, instead of using big and buggy apps.
I also don't think that layers complicate programming. They actually make life easier. For example why should PPP dialer bother about what type of modem does it use. It should just enumerate all modem devices and use one of them selected by user.

And let's not go back to BAD old days of DOS.

Yeah - back to real world, year 2005 - here's my thoughs, I'll try to concentrate in a few lines.

@Pj: I found you very biased against MenuetOS, but you have the courage to warm developers, maybe because you showed to us anything and have nothing to loose. But some things you pointed does make sense for me. I hope your attitude spread out there, and that you have a FD in 2005.

@MenuetOS: I'd known this OS a couple weeks ago, and from there I've not seem a 'roadmap', what drives devels to write your own code, that should be inside kernel(I'd written a MM in asm, and there's some people doing things in C)

The OS, as spideros1 said, should be orthogonal from first principles.

PS: If something seems non-sense, pardon me, I'm a bit drunken.

same saying again.

let's make the menuetos as linux's GUI.

--

We don't have to provide linux GUI API. If API is well written, people will use it.

Not like Linux!!!

If people want Linux, they can, well, use Linux.

[ long Linux rant deleted for your reading pleasure ]

I was just thinking exactly that.

-Dr.X

I totally agree with Pj. menuetOs should take steps towards being microkernel. You may read interesting doc. about an existing distributed OS with microkernel if you search for the keywords 'microkernel' and 'amoeba' on the web.

I've also read Pj's ideas on his site but it lacks mentioning something: one of the main features of a microkernel is message handling (sending, queueing, dispatching). It's because the different components (kernel, drivers, networking, apps, etc.) communicate to each other with help of messages. So if your application has nothing else to do just waiting for an incomming package on the port it's just listening to then it can be left in rest by the kernel. When a package is received on the given port by the networking component then that posts a message or messages (according to our protocol) delivering the received package to your application. The messages get in the main queue of the kernel, which will care of dispatching them to the addressee's 'mailbox' (which is also a queue). The kernel might for example have the right to just call to the given application when it's mailbox contains at least a message. It would be feasible that each message has its own counter message. For example there were messages having postfixes 'request', 'indication' etc. and there were their counter messages having postfixes: 'confirm', 'response', 'acknowledged' etc. The sender must not assume that the adressee has noticed the message until the appropriate response message received, so till then the sender may or may not (tbd.) send any more messages to the target component.

It maybe sounds complicated and not too well elaborated, but it would make the OS extremly flexible. Just imagine, say an nvidia video driver written in perl, python, basic, logo, etc. running in user-space. Yes, it would be possible since there was a little damned fast kernel in the background: the microkernel menuetOS.

Criticism is a characteristic of freedom. If something is shit then don't call it cookie.

happy new ideas,
Endre.

To me you all sheep with no leader, NO one should criticize a OS, until they have tyred it.
MenuetOS achieved its goal of a multitasking GUI that fits on a floppy and now is lost to were to go next and any thing that is linux like, is only good for C programmers.
You should all pull together and set a goal, by this time next year, you will have a full functioning web browser, or some like that.
Even the so called bad Dos has one of them.
And looking at the programs that Pj has made, they look like you could of made the same programs for Dos, and having program on both Dos and Linux, i think that the Dos ver would of been easier to do (in asm), i think all this does, is showing how good Dos was .

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

Batteries not included, Some assembly required.

I knew I should have explained the TLAs for those who hadn't seen them before. I wrote about IPC a lot, that's what most of it was about actually.

Anyway, let's see...

IPC is inter-process communication. This is where the kernel passes messages and data between one process and another. This covers all sorts of things, like fifo pipes, semaphores, basically anything that allows processes to be connected together somehow, with the exception that it's usually not used to refer to network connections, or to two processes sharing a file to communicate with eachother.

API is application programming interface. This is what the programs use to get things done. This is what interrupt 40 is in MenuetOS. This includes both system calls to the kernel, as well as to loaded drivers.

I think that's all of them that I used.

I'll have to differ here. A Unix-like kernel (with a few well defined and documented syscalls) is extremely helpful in many cases. It's not necessary, but coding is made much easier because of it. I do quite a bit of programming in assembly & forth under Linux, and it's a quite nice environment once you learn the system calls.



Other than DOS allowing direct acccess to the hardware, I consider Linux a better programming environment for any language. The restrictions that 16-bit asm imposes are too great IMO. And if you enter protected mode from DOS, you have to go through more work since you can't use the DOS or BIOS functions without writing a VM86 layer or some other kludge. (And no, Linux isn't perfect, but a Linux-like kernel with no protection would be an ideal platform for me to code under)

oh yeah?? how about plan 9?
--

> until they have tyred it.

I have tried it.

We must have hit that critical point which this message board format suffers, where the thread is just so long that people cease to be able to force themselves to read through the entire thing before posting.

> And looking at the programs that Pj has made, they look like you could of made the same programs for Dos, and having program on both Dos and Linux, i think that the Dos ver would of been easier to do (in asm)

Having actually written Softer in DOS origionally, way back around 1997 or so, (and losing it to an unforutnate power cable accident not more than a week later), I can say that yes, it was easier in DOS, until the point where I needed to be able to start up another program, keeping Softer in memory, and allowing that program to communicate with Softer. I had planned to hook onto DOS's "open file" interrupt, and simply watch for a certain file to be opened, that way I could use Softer from QB. For some reason I wasn't ever able to get it to work, but then I only had a week to work on it.

One thing that was more difficult in DOS was that I didn't have segmentation faults. In Linux, Softer gets a signal when it screws up, and it uses this signal to restore the video mode and keyboard mode, and then display a nice register dump and some other extremely useful debugging information before it exits. In DOS the computer just locked up and I had to reboot.

Even so, it was easier in DOS. When I first started writing the Linux version of Softer, linuxassembly.org didn't exist, and the Linux-Assembly-HOWTO was nothing but an essay about why you should write in C instead of Assembly.

> i think all this does, is showing how good Dos was .

DOS wasn't that great. The problem is that Linux isn't that great, and so by comparison, DOS doesn't look all that bad.

Linux does a lot of things well, but it's just not very good for the things that assembly programmers like to do with their computers. We're more about doing things that are cool rather than useful, and Linux is more about doing things that are useful rather than cool. Doing cool things in Linux is hard, though it's a little bit easier now with Softer.

Do you know that QNX is a microkernel OS? It intensively uses what we sheeps like .

Cheers,
Endre.

That's a rather narrow view of assembly programmers. I use assembly for useful things. (Implementing entire applications in assembly, where I can be in complete control of the compiled code). Doing "cool" things isn't really important to me, or many other assembly programmers I know.

> or many other assembly programmers I know.

Oh, wait, my turn... Let's see...

Hmm... This is harder than I thought.

...

Ok, I got one.

Well, I know bunches of assembly programmers and they all tell me they like cool things. And they also tell me that all of the assembly programmers they know prefer cool things to useful things as well. So there.