Maybe assembly programmers both like cool things _and_ useful things?
Thats why we are better then the C guys..

I think there's difference between cool & useful software. Programmers are paid for writing useful software, which doesn't necessarily do cool things. People actually have to earn money to live, not code for coding itself. Do you think smart people go to university only for title. It's all about money. Parents won't give you money forever. That was (indirectly) about coding apps in C. Of course there's time for coding cool software. I don't blame anyone for it, but people who say that coding cool software is more important than working to earn money (when you have money, you can afford power & PC to code )
Of course asm is useful to code time-critical parts, I don't blame asm.
That was just my opinion.

Anyway, I think that moving to microkernelness it better approach. Application will be more powerful. Virtually everything can be accessed through message port. So application doesn't have to know what device does it communicate with. It just sends and receives messages. IMO menuet kernel is good for microkernel, becuase it's lightweight and has all needed stuff to build servers. GUI should also be moved to application server. It allows more flexibility. For example app server can provide image object. And you don't care what type of image you load. It's appserver + media codecs job to give you raw bitmap (RGB or RGBA, whatever), and you just send request. The only thing is missing, is separate address space for each executable. Programs need dynamically allocated memory. If task dies, kernel should send info to application server and app server should free task resources.
For example there are many opensource media codecs (images, video, sound). Why recode them again ? We can make media codec using it, and applications won't even notice what are they using.

Just my 0.02$ :>

If somebody would be interested in microkernels...
http://www.cs.vu.nl/pub/amoeba/Intro.pdf

Hey there,

Just want it known that MenuetOS has performed well for us.

We retired an OS that won't remain running (M$win) with a beta "hobbyOS" that just won't stop running on several PCs.

Servers, Motor controllers, Entry Systems using Com/LPT realtime hardware control, communication, presentation w/ syncronized cd-audio , networking and much more.

For the first time I can easily control the ports AND have a GUI.

Can't wait for the next development whatever it is.


Cool, Useful, small, FREE, Stable, easy to program in and more.

This OS has changed the way we work.

Criticize if you wish, make it better if you can!

G'day, Mark

Bloglite: It's rather about lack of functionality in some parts.

Our aim should however be: Criticize if you can, make it better if you wish!

I guess a microkernel architecture would not affect your wishes: controlling anything with a PC; but it might help you control anything with several PCs (all of them running MenuetOS, of course).

Endre.

> Criticize if you can, make it better if you wish!

Yes, really. I'm over on my message board writing up my silly ideas and while I'm sure that there are some (maybe even many) special cases where my idea would lead to a sticky mess, no one is pointing them out. (Well, actually, beppe85 is helping out, but that sentence doesn't work well if I include that.) I'd rather they do so now, even if they can't improve it, rather than let me go with that idea for a year and then discover the problem myself.

Also, no one is sharing any of their ideas. It's just not statisticly likely that I have all of the best ideas. I want to hear others.

> but it might help you control anything with several PCs

I don't believe that "microkernel" implies "distributed OS." At least, when I used the term I was just referring to a kernel that does as little as possible, and has lots of features to make sure that non-kernel processes can provide everything that the kernel doesn't.

Here's that link again: http://www.xersedefixion.com/forum/

Pj, i think you will find that most people who could find hole's in your assessment of MenuetOS, will not do so, as these people will in most case, will be making there own OS, so the short coming or not of menuet does not matter to them, these short coming are a good reason to make there own OS.

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

Batteries not included, Some assembly required.

Microkernel does definitely not imply distributed OS, since in my unsderstanding OS = kernel + system programs using facilities of the kernel. So even distributed OS could imply microkernel. I guess any distributed OSs running on monolithickernel can merely simulate capabilities of a distributed OS on real microkernel. We all know the term RPC... And beacause of generality of communication across message interfaces I don't want to see barriers which is manifested by thinking only about one processor.

I promise I'll try to reflect on your ideas.

Endre.

Well well well! I come back from Holiday and look what has happened while I was away, somebody put forth ideas about the design of this here OS and was met with deep resentment. Tisk-tisk.

This is refreshing to me to see. However, I think she's a bit pregnant now and the calfs head is in the canal. MenuetOS has been a work in progress for a long time.

Pj I think you have very valid points that should be addressed by the folks putting the code together. I've actually coded some changes that would help, in one area you mentioned, determining the memory on the fly, but I never heard back from Mike and it wasn't in the latest (pre) release.

I think there is a vacumm here when it comes to making suggestions on improvements, even when they have been presented with fixed code, this vacumm doen't allow anything to penetrate the shell (core group; or for more pun, the kernel group).

I am looking for a new project OS to work on...I'd like to do my own OS, but one head isn't as good a many heads put together. A systematic approach to development is just the thing I'm looking for.

Perhaps a M.I.T. approach to system design. Develop Conops (brainstorming), Requirements, Design and Development, Integration Verification and Validation, and Maintenance and then the next iteration. Paradigm that by a set timeline with inch stones. <waking up> wow Dorthy, I was dreaming I was back in Kansas.

Well, Pj, when I get the opportunity to peruse your forum I will and help with the idea and suggestions as well as interject my experience on where I've met daunting tasks.

I've put alot of work into this OS to try and make it better, but I have a limited understanding of ASM code. Any help from the Pros would be great.

If you have the time please make changes and post them or email me WBSHOME@EXCITE.COM with attached code and it will be included in the EZ distros.

Thank You !!

whats about the idea of a microkernell in MenuetOS ? its posible ?

Is needed?

well .. its my humble opinion... what do you think Ville ?

I think all of PJ's points are valid.

I believe a lot of hard work has went into Menuet, but it is basically a hacker OS. Hacker OS being doing the quickest thing possible to get the job done, basically patching as compared to redesigning.

The reason why this will never be fixed(although a lot hold out hope) is that the designer never want to rewrite. Once you gain a knowledge of something, sometimes you have to change something that is core in order to make it better, otherwise you are making the hacker patch thing.

One of the big things right off the start is that it is a 1.44Meg image system. It is in no way even a floppy OS since a floppy OS wouldn't need to load the entire image of the floppy prior to starting. This was done at first because it was the easiest to start programming, but it was never fixed. This should have been fixed as soon a floppy file support was implemented, but it wasn't. If that was done, then loading off of a hard drive would have been a small issue.

Same thing with other stuff, remaining backwards compability rather than fixing it so that it works good. Right now there are no apps that are just awesome, so I am unsure why it hasn't been designed yet.

Some of the points people made about PJ not trying out the OS are totally hilarious. His points were no less valid just because he didn't try the OS. If him trying the OS would fix the things he pointed out as defects, then he is a magician, I would like him to try any software I wrote(it would save a lot of development time).

I don't think he is saying Menuet programmers did not put a lot work into it. He is just saying the thought regarding design to become extremely useful and programmer friendly was not done. It will never be able to compete with linux, microsoft, whatever in this regard. This is because the only programmers it will atract is hackers, quick-fix type programmers.

If you are looking for an OS that is basically multi-tasking DOS GUI with extremely less functionality than DOS(like BogLite is), then this is the OS for you.

Again not meaning to put down the hard work everybody has put into this, but reality is reality. The longer you ignore the facts, the worse it will get.

I disagree with you, about " you do not need to test the OS", take the Porsche, on paper its a bad design with the engine sticking out of the back, but it one of the best to drive .

Also linux is nearly has slow at reading a floppy, ( from the desktop anyway ) as menuet is at loading its image.

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

Batteries not included, Some assembly required.

Gomer73, do you think that the community are unaware of the evidenced problems?

Collaborative approach is to take one of these problems, study its details and propose a solution, better if implemented.

Some of the problems shown by Pj are misinterpretations driven by the fact he didn't try the system.
I have also find things I dislike about the system but I think I need to elaborate some time more each one of them before posting (i.e. do some tests with proposed alternatives)

Let's say you are now exempted from every undertaking. Can you please mention some of your displeasings with menuetOS?

Endre.

The dword unaligned bitmap structure (RRGGBB RRGGBB... ) makes it harder for optimizations and leads to unnecessary slow operations.

Aligning it would break applications, doing a two-step bitblitting would render it unnecessary slow. IMHO the best for now is to have an alternative for maintaining compatibility at the expense of complicating the kernel.

Hmm, I think the 25% cost in alignment is bad. I Think that with big bitmaps, that won't fit in CPU cache you don't have to have 4-byte alignment because the bottleneck in the RAM2CPU.
I think you can make 4RGB-s per 3-byte work very well. Do you need a hard optimization I can make one. I'm beginning to be very good at it. This parser is a nightmare and I've learned some good tricks