New ASM Programmers Desktop OS
I have come to the conclusion, that the only real option for us is to to make a new OS, that has the same aims as menuet, but is a totally new OS. The New ASM programmer desktop, it will be full written in assembly, have has little layers between program and hardware, be optimised for both speed and size. Be as simple as possibly for ASM programmer to understand and use. Have built in support for multi-core CPU, have the best scheduler we can come up with for multi-tasking. We will uses the same call convertions to help with the porting of program form menuet to the NEW OS, but they will all need to be reassembled to run on the new OS. I have put a vote to see what member think, i will be making the New OS anyway, but just want to get your input. I see this as the only way for the spirt of menuet to live on, the old menuet code is still there for anyone else to go in a differant direction.

I think a rewrite would be in our best interests. Managing Menuet and fixing all the bad things is going to bite us in the future. Being a re-write, this OS will no longer be Menuet and will need a new name, if we can decide on a decent name, I'll change the wiki to that. I'm currently working on getting forums and a web interface for SVN repositories working. I think we can hand out repositories like candy. Here is what I would like to see in a new project: 1). We should design and Document as much as possible BEFORE starting code. 2). I don't think the goal should be to make it easy to program in assembly, the goal should be, "Make the best OS we can make WHILE making it as easy as possible to program in assembly" We should not sacrifce preformance or size just to make it easier to program in Assembly. 4). The Kernel should be some kind of modular combination of monolithic and micro. We should make it so kernel features can be built in for fast preformance, or loaded later for increased security. It would be neat if we could make it possible to re-assemble and reload the kernel without even rebooting. It would also be great if we could make it so we could change schedulars while the OS is running. 3). We should not worry about copying other ideas. If it works, and it is good, we should do it that way, and improve apon it if possible. 4) stdio and "Everything is a file" should be worked into the OS. This works very well for linux and makes administration, using and programming for Linux much easier.We should use the Filesystem Hierarchy Standard (have Linux style directories like /dev /etc... ). (see #5) 5). We should implement Linux virtualization (not emulation). This way we could run linux compiled applications on menuet and it would translate syscalls into native Menuet syscalls and be completely invisible to the linux application. This would be a big project but would be worth it in the end. As a small, open source project, we need all the support we can get. One of the largest criticisms of Menuet is "thats neat, but it can't even do what the mainstream OSes can do, why should I use it?". Supporting linux apps will instantly give us access to thousands of applications already developed, and a huge community of people who are already aquanted with the open-source world and are more likely to contribute. I think this would substantially increase our user-base. Rule Number 1 should alway be: "All official code should be written in Assembly, no execptions". Assembly is what makes Menuet different and is why a lot of us are here, we should keep that quality, its what sets us apart. I would really like to start a VMware like Virtual Machine project written in ASM, I think that would really make the OS useful to other people. These are just suggestsions, we really need to discuss these things before going along. The problem is, there are too many people. Groups are unable to make decisions. We need one person, or a couple people that we elect to Vote on issues so we can actually get decissions made and stuff done instead of talking about it. /Loplin

Voted YES since there's nothing bad in another one, good I hope, OS. But I won't participate. Many tasks in Kolibri, job, etc etc.

I did not no, I did not NO, I did YES. Nevertheless I have still qualm about assembly. If we're going to write an OS running also on i386 then it won't be optimal on an x86-64, but we've decided to make an OS for future architectures (e.g. multi-core processors). It's not impossible, but needs some additional work: you will need to write your functions to almost each processor type to take advantage from its capabilities otherwise your code would be non-optimal on certain platforms. Or do only I think this problem to be so serious? T.

Hi, I did not no, I did not NO, I did YES. Nevertheless I have still qualm about assembly. If we're going to write an OS running also on i386 then it won't be optimal on an x86-64, but we've decided to make an OS for future architectures (e.g. multi-core processors). It's not impossible, but needs some additional work: you will need to write your functions to almost each processor type to take advantage from its capabilities otherwise your code would be non-optimal on certain platforms. Or do only I think this problem to be so serious? I would assume that the idea is to write a 32 bit OS (boot code and kernel, at least) in assembly. I'm not sure if SMP is intended (or just desired), but an SMP OS would work fine for everything from Pentium to multi-core 64 bit CPUs (running in 32 bit protected mode). If SMP is intended, I recommend not bothering with SMP on 80486 (or older), as these CPUs used an external local APICs that have differences (and problems). Put simply, it's not worth the hassle - supporting SMP for Pentium and above makes more sense, even if the OS supports single CPU for 80386 and above. If a future 64 bit version is intended, then design the API/s carefully. It is possible to run 32 bit processes on a 64 bit OS without modifying or recompiling them, as long as 32 bit processes don't rely on things that would change (e.g. the address of any kernel data). As for optimizing the code for specific CPUs, don't bother. Just do generic optimizations, and possibly have some "special case" code. For example, the GUI might check if MMX or SSE is supported and use it if it is. Forcing users to recompile the OS for their CPU, or making them download version 0.1234 for Pentium II model 5 stepping 3 will make them hate your OS. The same applies regardless of which language you use. This is part of the reason why it's rare to find a Linux user who isn't a programmer, system administrator or general geek - normal users (secretaries, office workers, games players, your mom) shouldn't need to know anything about source code or details of their own hardware. Let's be honest, most "non-technical" users don't even know the difference between a computer and a monitor (quite often people think they've got a white box thing with a computer on top, rather than a computer with a screen thing on top). Don't believe me - ring your Aunty, Uncle, Cousins, etc and ask them what CPU they've got in their computer. I can guarantee most of the time they'll say "What's a CPU?" or "I don't know - it says Dell on the sticker, does that help?". Cheers, Brendan

1. Programming language doesn't affect the kernel-design. SMP or not doesn't count anything. 2. You mean it's a great thing to run a 32 bit OS on your 64 bit machine just because it's able to run it? Then why not 16bit OS? 3. Then will the GUI not be in the kernel? Will it not be written in assembly or what? Checking for MMX, SSE, etc. is one thing use of them is another. 4. I don't think that for an assembly programmer it would be hard to recompile the kernel. 5. You mean that informatical-illiterates will use MenuetOS or Menuet4U or what? So I guess an assembly OS written for i386 will definitely be slower then an HLL OS on K6, K7, K8, PIII, P4, x86-64 etc., assuming the same level of services. Size of the OS. Does it count? No, it doesn't.

Hi, 2. You mean it's a great thing to run a 32 bit OS on your 64 bit machine just because it's able to run it? Then why not 16bit OS? I didn't say it was a great thing, only that it would work. Would you rather have half of a 32 bit OS and half of a 64 bit OS, or would a working 32 bit OS be better? 3. Then will the GUI not be in the kernel? Will it not be written in assembly or what? Checking for MMX, SSE, etc. is one thing use of them is another. Not sure why it matters where the GUI is (I prefer implementing GUIs as normal processes at CPL=3, but then I prefer device drivers like that too - it doesn't suit a "performance is the most important thing" OS though). 4. I don't think that for an assembly programmer it would be hard to recompile the kernel. 5. You mean that informatical-illiterates will use MenuetOS or Menuet4U or what? Are you saying that people who don't know assembly shouldn't be able to use Menuet? If you design it for non-technical users, then non-technical users and experienced programmers can use it. If you design it for experienced programmers then non-technical users won't use it. So I guess an assembly OS written for i386 will definitely be slower then an HLL OS on K6, K7, K8, PIII, P4, x86-64 etc., assuming the same level of services. Assuming the same level of services (and ignoring long mode), and depending on how good the code is (which is the main factor anyway), it should be faster on these CPUs than a Knoppix boot CD, Windows or anything else that doesn't need to be recompiled. Something like Gentoo might be half a fraction faster (but Gentoo takes 3 days to install from stage 1). Remember the original Menuet32? You could make a boot disk, put it in any 80x86 computer and it'd work. IMHO (apart from asking the user how much memory is present) that's one of the things they got right. Size of the OS. Does it count? No, it doesn't. Spoken like a true non-technical user - do you know what a trace cache is? Cheers, Brendan

Brendan, with this spluttering you could be a politician. I wish you the trace cache be the only thing which saves the day for you. Do you think that only not existing assembly OSs were considered at intel when scaling the trace cache? Knoppix and Gentoo are distributions not kernels, so when you compile for 3 days then you mostly compile applications not kernel. Is it otherwise clear to you? No, I think that non-technical people won't use MenuetXX. They should but they won't. Right? I would rather have a working hybrid OS on my multi-core x86-64bit machine than a working 32bit one. T.

Just a little info on the OS code named "Menuet4U", first i be leave that the only way a OS project, can servie is to have a strong leader who has to say yes or no. So here a outlines so far for "Menuet4U". 1. It will boot from Dex4U, it will start in pmode and be loaded to maybe 8MB. 2. Dex4u can run on anything from a i386 upwards, "Menuet4U" will need at least a Pentium and vesa1 and about 32MB ram, this lets people who have old pc still use it by use Dex4u CLI, some one can make a low res GUI to run from the CLI. 3. We will develop a 64bit ver that can simple replace the 32bit ver, that is loaded at 8MB. 4. "Menuet4U" will be very easy to use for both ASM programmers and user's, that was the big misstake of linux. 5. "Menuet4U" willbe a all NEW OS based on the principles of menuet, but not the code, the call functions with have the same int number and regs, but most programs will need re-assembling. 6. The name Menuet4U is only temp, a name will be chosen that does not have Menuet in. 7. Built in from the start will be a module interface the same one as used in Dex4U, so driver can be made. 8. I see this is the only way to continue, to dev a ASM desktop OS, as menuet as been killed off. NOTE: This project does not effect Menuet32 in anyway, anyone who wishs can take the menuet code and go in a differant dirction, most of the programmers will come from The Dex4U Dev team, but we welcome new programmers or nonprogrammers to the project. We also wish KolibriOS programmers well and they are welcome to share any code, including program from the New OS.

I voted for a new assembly desktop. A fresh start for a great concept. 1). We should design and Document as much as possible BEFORE starting code. 2). I don't think the goal should be to make it easy to program in assembly, the goal should be, "Make the best OS we can make WHILE making it as easy as possible to program in assembly" We should not sacrifce preformance or size just to make it easier to program in Assembly. 4). The Kernel should be some kind of modular combination of monolithic and micro. We should make it so kernel features can be built in for fast preformance, or loaded later for increased security. It would be neat if we could make it possible to re-assemble and reload the kernel without even rebooting. It would also be great if we could make it so we could change schedulars while the OS is running. 3). We should not worry about copying other ideas. If it works, and it is good, we should do it that way, and improve apon it if possible. 4) stdio and "Everything is a file" should be worked into the OS. This works very well for linux and makes administration, using and programming for Linux much easier.We should use the Filesystem Hierarchy Standard (have Linux style directories like /dev /etc... ). (see #5) 5). We should implement Linux virtualization (not emulation). This way we could run linux compiled applications on menuet and it would translate syscalls into native Menuet syscalls and be completely invisible to the linux application. This would be a big project but would be worth it in the end. As a small, open source project, we need all the support we can get. One of the largest criticisms of Menuet is "thats neat, but it can't even do what the mainstream OSes can do, why should I use it?". Supporting linux apps will instantly give us access to thousands of applications already developed, and a huge community of people who are already aquanted with the open-source world and are more likely to contribute. I think this would substantially increase our user-base. Rule Number 1 should alway be: "All official code should be written in Assembly, no execptions". Assembly is what makes Menuet different and is why a lot of us are here, we should keep that quality, its what sets us apart. I would really like to start a VMware like Virtual Machine project written in ASM, I think that would really make the OS useful to other people. These are just suggestsions, we really need to discuss these things before going along. The problem is, there are too many people. Groups are unable to make decisions. We need one person, or a couple people that we elect to Vote on issues so we can actually get decissions made and stuff done instead of talking about it. 1. Absolutely. It was the (one of) reason Menuet died. 2. I Agree. Especially when porting some other language compilers. 3. That would be cool. Also, imagine run-time assembling and execution of sources. 4. Definately. 5. Meh, KISS. Rule No. 1 is very important, especially since this'll be an Assembly OS. The VM idea would be cool. Solidus