Path: utzoo!attcan!uunet!zephyr.ens.tek.com!tektronix!psueea!jove.cs.pdx.edu!kirkenda From: kirkenda@jove.cs.pdx.edu (Steve Kirkendall) Newsgroups: comp.sys.atari.st Subject: Re: Multitasking Message-ID: <1610@psueea.UUCP> Date: 17 Aug 89 05:50:36 GMT Sender: news@psueea.UUCP Reply-To: kirkenda@jove.cs.pdx.edu (Steve Kirkendall) Organization: Dept. of Computer Science, Portland State University; Portland OR Lines: 43 It's my turn to talk now. I promise to try and say something original. 1) Why do I want multitasking? Well, mostly because it would make desk accessories obsolete; each DA could be replaced by an application program. DAs use memory from the time the system is booted to the time it is rebooted. This is bad. You have to reboot the system to install a new DA. This is bad. DAs must be written and compiled differently than "regular" programs. This is bad. Presently we must worry about two kinds of programs ("*.ACC" and "*.PRG"). This is bad. In fact, the only good thing about DAs is that you can run one while you're in the middle of an application, and a REAL multitasking system would give that ability to EVERY program. Also, there are times when it is easier or more efficient to implement a single application as a collection of tasks. An example of this from UNIX is the 'cu' program, which is implemented as two processes: one to copy characters from the keyboard to the modem, and one to copy characters from the modem to the screen. "Client/Server" systems (such as X-windows and certain database packages) provide more examples. The Minix kernel and AmigaDos are both implemented as collections of tasks, because they are easier to maintain that way. 2) One thing I wonder about, though: what would multitasking TOS look like? I mean "look" literally -- how would several GEM programs *share* the screen? Currently, it seems that every GEM program expects to have exclusive control of the screen. Each handles its own refreshes, and has its own menu bar. How does DRI's multitasking 80x86 version of GEM handle this? 3) Concerning the necessity of an MMU: Obviously, an MMU is not *necessary*, since Minix works. Just as obviously, an MMU is *desirable* because it limits the damage from a program on the rampage (pardon the pun), makes debugging easier, eliminates the need for relocation, etc. I want an MMU, but I don't have one, and I'm not going to let that keep me from using multitasking under Minix. Even without an MMU, Minix-ST is fairly secure. It traps stack overflow and any attempt to dereference a NULL pointer. It does NOT trap pointers that overrun a buffer, but these are rare and typically occur only in the last process that I have started (and hence in the process that resides in the last portion of used memory) so no harm is done to other processes. -- Steve Kirkendall ...uunet!tektronix!psueea!jove!kirkenda or kirkenda@cs.pdx.edu