I am for ASM OS too, I want the same as you Solidus117, but my ideal ASM OS would work more like this: This what the GUI would look like (be fully skinable). I know that 99% will not agree, but think of how we use phones, pda, games consols. You start with a menu, you move around the menu up or down left or right. you select a game, note pad, email etc, and goto it and run the program. Menuet is a multi-tasking OS, but do we need it ?, i know people open lots of note pad to read from one to the other, but this can be done just as easy by coding a note pad to open many files and windows. same with web browsers, and yes even in a single tasking OS, you can listen to background music. But it would speed programs up alot and be easier for programmers and with multi core chip coming more common, this makes giving each program a core a possibility.

Hi, Menuet is a multi-tasking OS, but do we need it ?, i know people open lots of note pad to read from one to the other, but this can be done just as easy by coding a note pad to open many files and windows. same with web browsers, and yes even in a single tasking OS, you can listen to background music. But it would speed programs up alot and be easier for programmers and with multi core chip coming more common, this makes giving each program a core a possibility. Consider how you'd write something like an NTP (network time protocol) client. The idea is that every hour or something it gets the current time from a server on the internet and keeps your clock set right - sounds simple, but without multi-tasking you'd need to devote an entire CPU core to it even though it'd use about 3 ms of CPU time each hour. How about a HTML server (or FTP/SSH/telnet/news/mail server), or something that checks for software updates in the background? How about using cut & paste to copy several seperate paragraphs from a web site into a text document - open the web browser, select a paragraph, press copy, close the web browser, open the text document, paste the paragraph, close the text editor and repeat? Then there's things like "ls | more" (one process for "ls", one for "more" and one for the CLI itself), or perhaps "make" (which spawns processes to run commands). Let me see, the computer I'm using is running a HTML server, an FTP server, sendmail, a samba server, a little utility to keep "noip" happy, cron, X, KDE, 3 Mozilla browsers, 2 kwrite windows and some other stuff. Most of these use multiple processes - it adds up to over 100 processes, and I'm not really doing too much. If all of this was specifically designed to run without multi-tasking, I'd probably still need a computer with around 64 CPUs! :) Cheers, Brendan

@Brendan, This is a miss conseption, because i am able to do most of those things you mention, including surf the net (using "linksboks" a xbox web browser ) on a single- tasking OS, namely the XBOX OS ':shock:', Take a good look at the XBOX OS spec: http://www.extremetech.com/article2/0,1697,1670116,00.asp This to me is one of the biggist problem with OS Dev, not looking at the truth, Menuet can not do any of the above things, it too hard to implement, at the moment. Your try to save CPU cycles, here and there, but you have a loop with a 100 process, slow vesa, hi graphic res, that adds up to slow OS to me. Take Menuet64 as a example, we know it got a web browser, looks great on the screenshots, but villemt admits to a big problem, it's much too slow to use. Some how we need to get round the above problem, of being slow, i say we get rid of the 100 process :wink: . I would like menuet to be the fastest, smallest useably OS, there is, along with the best OS for ASM programmers. This can not be done by writing its in asm alone, or using the latest coding tricks (that only work on new PC ), i say we do what M$ did when they made the first XBOX, which is just a 700Mhz PC, but it can run games faster than my 2.7 Ghz PC, use there spec, at the same time work on code for multi core chips. And guess what, the new XBOX is multi core, so they are thinking along those lines too. Check it out here: http://electronics.howstuffworks.com/xbox-three-sixty2.htm @ALL, But for this to happen, we need to make some comprises, you know where i stand, but where do you ?. PS: @Brendan, I can bet you that in less than 5 year, a 1000 CPU will be common, it will take us longer than that, to agree on anything :lol:.

Hi, This to me is one of the biggist problem with OS Dev, not looking at the truth, Menuet can not do any of the above things, it too hard to implement, at the moment. Your try to save cpu cycles, here and there, but you have a loop with a 100 process, slow vesa, hi graphic res, that adds up to slow OS to me. Take Menuet64 as a example, we know it got a web browser, looks great on the screenshots, but villemt addmits to a big problem, it's much too slow to use. Some how we need to get round the above problem, of being slow, i say we get rid of the 100 process :wink: . I haven't seen the source code for Menuet64, but it is possible that it is similar to the source code for Menuet32 (the official version, not the Russian version). Consider what happens if there's 99 tasks that are waiting for something (a keypress, an "event", a specific time, some hardware, whatever), and one "busy task" that needs the CPU. Let's assume that this busy task is a web browser. For Menuet32, the web browser would be running and the timer IRQ would interrupt. The scheduler moves to the next task in a round-robin way, and does a task switch to the next task. The next task does a quick check to see if there's any reason why it needs the CPU, realizes it doesn't and goes back to the scheduler. The scheduler switches to the next task in a round robin way, the next task does it's check, has nothing to do and goes back to the scheduler. This happens 99 times, and after 100 task switches the web browser gets the CPU back, but all it's TLB entries are gone and most of the CPU's instruction and data caches would contain useless information. The web browser only runs for a little while until the timer IRQ interrupts again, and the whole pointless mess starts again. Let me be brutaly honest here (and I admit I may have mis-understood something), but this scheduler seems like the biggest pile of crap I've seen for many, many years. First thing to fix is to add wait states to the scheduler, so that a task can tell the scheduler "don't give me any CPU time until <something> happens". If done properly this would have saved 100 pointless task switches and 99 pointless little "is there something I can do" checks. AFAIK the russians did this for "events" but not for "IPC" (and I bet they were surprised at how much difference that made). After this, the scheduler is still looping through 100 tasks checking to see if they are ready to run or if they are in a wait state. If that sounds dumb to you, then good (it is). A better idea would be to have a queue of tasks that are ready to run. When a task becomes ready to run it's put on this queue. If the running task tells the scheduler "don't give me any CPU time until <something> happens" then the scheduler takes it out of the queue. After this, the scheduler just grabs the next task on the queue. The ugly loop is replaced with something like: timer_IRQ: push esi push eax mov esi,[ready_queue_head] lodsw cmp esi,[ready_queue_top] jb .noWrap mov esi,[ready_queue_bottom] .noWrap: mov [ready_queue_head],esi cmp [current_task],ax ;Is this task already running? je .noSwitch ; yes, skip the task switch mov [current_task],ax jmp far [current_task-4] ;Do the task switch pop esi pop eax iretd This is a good start, but if there's only one task that is ready to run why are we bothering to check the queue? When there's only one task to run, you don't need a timer IRQ at all - why not just mask the IRQ in the PIC when there's only one task to run, and unmask it when when there's more running tasks? Sounds good to me - it removes that last little bit of overhead (making multi-tasking as efficient as a single tasking OS when only one task is running :)). Unfortunately, the scheduler is still crap.... What if someone is running a program to find the first million prime numbers (or they're compiling a huge program or something), and they're chewing heaps of CPU time? This would make the GUI and everything else sluggish because the CPU is being shared - you're sitting there waiting for the screen to be updated and the CPUs doing work that can wait. What you want to do is tell the CPU to do the GUI's stuff (or your text editor or whatever) now and forget about the the first million prime numbers until the GUI doesn't need the CPU anymore. The problem here is the round-robin scheduler - every ready to run task is treated equally. This isn't so hard to fix - instead of having one queue of running tasks, let's have 3 of them. The first queue can be for high priority tasks, the next queue for normal tasks and the last queue for low priority tasks. The scheduler can check the high priority queue, and if there's no high priority tasks to run it can check the normal priority queue, and if there's still no tasks to run it'll find something in the low priority queue. Now all you need to do is make the GUI (and text editor or whatever) run as a high priority task and the program calculating the prime numbers can run as a low priority task. When the GUI has work to do the prime number thing won't be slowing it down. Actually, that not strictly the truth. If the prime number thing is running and the user presses a key, then the keyboard IRQ handler would tell the scheduler to put the GUI back on the "ready to run" queue, but the prime number thing would keep running until the next timer IRQ. If the timer is set to 10 Hz or something then the user could be waiting for 1/10th of a second before the GUI gets the keypress. That isn't good enough. If the code to put a task back on a ready to run queue checks to see if the task being restarted is a higher priority than the currently running task, then it can do a task switch immediately. That isn't hard to do, and it means that the 1/10 of a second delay is gone. After all of this you'd have a modern scheduler, but it's still limited to 256 tasks (or less than 8190) because of the way it's using hardware task switching (one TSS per task). There's ways to do hardware task switching without this limit, but it's possible to do software task switching too, and a software task switch can be up to 10 times faster.... Any questions? :) Cheers, Brendan

My point Brendan, is that all schedulers are crap, multi-tasking is crap, why did multi-tasking come about ?. The answer is simple, when CPU cost $6000 you need to use as much of there prosessing power, as much you can, if you need to do many tasks, you split the CPU time into little parts, and give each task some CPU time. The word multi-tasking is miss leading, as only one task is done at a time. Now let look at where we are to day, CPU are cheap and CPU get faster each year, But there a problem the speed inc is getting harder to achieve, So what going to happen to get the speed, is intel, amd, will make multi core processes. With lots of 700Mhz processes. This will start with 2 or 4 cores to start with, but with in 5 year 1000 core will be common. Then big software co will tell you how slow multi-tasking is and giveing each program is own cpu is the way forward and people will flock like sheep. So to the point i think we need a single tasking ver of MenuetOS, which is the ver Dex4u team will make, it will run all programs made to run in Menuet32 This will help us in lot of ways, it should run program faster, be easier for new programmers to understand. On top of this the Dex4u team will build in support for multi-cores, so processes can be run at the SAME time.

I think that a rewrite/source cleaning that tries to get menuet "less" monolithic would be cool. Try to seperate the drivers and stuff from the kernel, make it more modular (driver interface), and add a "autoexec.bat" thingy for the booting. :)

autoexec.bat? we already have that my friend it's called launch.mt

Hi, My point Brendan, is that all schedulers are crap, multi-tasking is crap, why did multi-tasking come about ?. The answer is simple, when CPU cost $6000 you need to use as much of there prosessing power, as much you can, if you need to do many tasks, you split the CPU time into little parts, and give each task some CPU time. The word multi-tasking is miss leading, as only one task is done at a time. Sort of - once upon a time CPUs where very expensive and very slow. This led to "batch processing", where jobs were queued and then done one at a time. For business (the only ones who could afford it) this meant the computer could be working all day and all night doing the queue of jobs (rather than just during the day when employees were present to start the jobs), which was a better use of hardware. Batch processing wasn't much good though, because while one job was waiting for hardware the CPU would do nothing useful. This is a waste of resources, so multi-tasking was used to improve efficiency. When one job is waiting for hardware, run another job until the hardware needed for the first job becomes ready. In this case multi-tasking meant that several jobs could be in progress at the same time (but if the job at the start of the queue didn't need to wait for hardware, it'd use all CPU time until it completed, just like the older batch processing systems). I've shown how a multi-tasking OS can be as efficient as a single-tasking OS when only one task is running. What you may not understand is that a multi-tasking system running 2 or more tasks is more efficient because the CPU isn't wasted when a task needs to wait for hardware or the user. There are no advantages to single tasking, except that it's easier to implement and it might save a few KB of RAM. Now let look at where we are to day, CPU are cheap and CPU get faster each year, But there a problem the speed inc is getting harder to achieve, So what going to happen to get the speed, is intel, amd, will make multi core processes. With lots of 700Mhz processes. This will start with 2 or 4 cores to start with, but with in 5 year 1000 core will be common. The three things that effect performance the most are (not necessarily in this order): - poor programming - eye candy - features For example, once upon a time I used to do word processing on a Commodore 64. The word processor was fast, even though it was using less than 64 KB of RAM and the CPU was running at 1 MHz. Today, something like "Word for Windows" needs about 1000 times more CPU power and 1000 times more memory. But, the word processor on the Commodore 64 would have been written in optimized assembly, and if any of it's code sucked the developers would've known there's no way they can make money and fixed it immediately. The word processor on the Commodore 64 also ran in the equivelent of 40 * 25 text mode. No fonts, no support for international characters, etc. You couldn't really see what your document would look like until you printed it. Word will run in high res video, handle fonts and colours, etc. It'll even allow pictures and things to be embedded into the document, and while your editing everything will look the same as when it's printed. Think about this - for 40 * 25 text mode it takes 2000 bytes to update the screen, but for 1024*768 at 32 bpp it takes 3145728 bytes (roughly 1500 times more data) and there's a lot more processing involved to work it out - you can't just copy ASCII characters to display memory. On top of this, Word will be doing stuff like checking for spelling and grammer in the background, seamlessly auto-saving the document every five minutes, etc (even doing stupid animated dancing paper-clips). For the Commodore 64's word processor, these things were technically impossible. The same thing applies to operating systems. You can have a half-assed OS with good programming, no eye candy and no features and it'll perform better than Linux or Windows, but because of the lack of eye candy and features no-one will want it. As soon as you start adding things like internationalization, Unicode and proper fonts, swap space, networking, customizable GUIs, browser plug-ins for movies/animation/flash, spell checking, etc the performance will start to decrease and it won't be much faster than Windows or Linux, regardless of whether it's multi-tasking or not. Cheers, Brendan

Has anyone considered co-operative multitasking? I'm pretty sure SolarOS and the old MacOS's used co-op. @Dex: So basically, you want a windows 3.1 type desktop, but with eye-candy? I dig it. But the GPX2 sucks, go PSP ;) @Brendan: Yep, optimisation and planning/structuring code flew out the window over every 'revision'. It's obvious that the whole thing is a mess of patches, so I think this is a fresh start to churn out some optimised code. But seriously, what about a coke-snorting version of win3.1 using Dex4u as a substitute for MS-DOS? People would get their desktop and all the excellent work done by Dex for Dex4U. Conversion of Menuet application would take some time, but who's got something better to do, right? B.t.w., sorry about the questions, it's in my nature? :p

Hi, Has anyone considered co-operative multitasking? I'm pretty sure SolarOS and the old MacOS's used co-op. Co-operating multi-tasking can be good too. The scheduler I described above is only one way of doing it, but there's plenty of other ways. In general, the "best" way depends on what sort of tasks the OS is designed for. For a single-user OS or a real time system co-operative multi-tasking can be very good (as long as there's a way to control CPU hogs), but for a multi-user system it's hard to say which user's tasks are higher priority... Most modern general purpose scheduler's combine round-robin (or variable time slicing) with co-operative multi-tasking in some way. For example, the scheduler above had 3 priority levels, where tasks at the same priority level used round-robin but tasks at different priority levels behave like co-operative multi-tasking. There's no reason this design has to have 3 priority levels though - you could have 65536 "ready to run" queues and 65536 priorities instead, which would make it a lot more co-operative. For schedulers used in Linux and Windows, there's different "scheduling policies" for different types of tasks, dynamic priority adjustment and other things - they're fairly complex compared to what I described. Cheers, Brendan

Virus on the super-computer: http://www.ks.uiuc.edu/

mmm I don't know what to think... to tell you the truth... I REALLY hate the single tasking idea... I'm one of the users that ALWAYS has 58 opened windows with 35 different programs running at the same time... I won't wait until multitasking disappears (if it does, I don't think it will...) to use all my programs at the same time... I'm not trying to offend anyone, please take it as an opnion of a user....

@Don, Do not worry, you will be able to run you 35 ,45, 55, 65.. programs in Menuet4U, i seem to have panic one or two die hards. The single-tasking part will be temporally, as a rewrite would be hard to debug with so much new code, once we have the basic run and working, multi-tasking will be added, in the mean time we can come up with a good schedule ( or should that be Brendan, can come up with a good schedule design :idea: ) We will also build in support for multi-core CPU 8) . I'm not trying to offend anyone, please take it as an opinion of a user.... And your opinion is valued, along with other uses and the feed back is that we need multi-tasking, so that what we will have, but we got to make shore its the best design for the job, so your 35 programs run as fast as possable :) . PS: The "Menuet4U" aims list, as been updaded: http://dex.7.forumer.com/viewtopic.php?p=1914#1914

just a question.. who is the forum admin???? you know... to keep people like him away