Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!mpretzel From: mpretzel@cs.utexas.edu (Benjamin Allums) Newsgroups: comp.sys.mac.system Subject: Re: Changes for preemptive multitasking Keywords: MULTITASKING WINDOWS AMIGA Message-ID: <1443@cash.cs.utexas.edu> Date: 11 May 91 12:03:05 GMT References: <811@newave.UUCP> <15931@helios.TAMU.EDU> Distribution: comp Organization: U Texas Dept of Computer Sciences, Austin TX Lines: 64 Couple of comments on Windows and Amiga multitasking and what I think Apple should do about it. Windows - Windows can multitask DOS applications if it runs 8086 based programs. If it can multitask 286, 386, or 486 programs, I think that there is a special way to program such. Basically though, only 386 and 486 based DOS boxes can pre-emptively multitask under Windows. This is due entirely to the fact that the 386 chip was designed to run multiple virtual 8086 machines. Windows does no magic. It merely enables the processor to operate as it should. 286 machines running Windows run similarly to MultiFinder, only with- out background processing. Amiga - From the ground up, day one, the Amiga's operating system was designed to pre-emptively multitask. That is why it does it. Mac - Implementing a pre-emptive multi-tasking OS would guarantee software incompatibility for all programs. Certainly they could be modified and recompiled, but Apple will not release a multi-tasking OS until the Mac memory model has been altered. Currently, applications assume that they have complete access to all available memory. MultiFinder works by allowing the user to specify the amount of memory that the program may take. Under the Amiga, an application may request and release additional memory on the fly, so memory use is more efficient. The reason why MultiFinder requires so much memory is this fact. The current memory model blows tons of megs. If people start running all kinds of little programs, probably 25% of main memory will be wasted. So, Apple will not provide multi-tasking until the way in which applica- tions use memory has been changed. What I think Apple should do. Apple has just completed a total rewrite of system software into C++. I think that they will obviously release a new developement environment centered more around C++ with an update to MPW and MacApp. But, I think that they should go farther. Apple should create a developement environment that assumes C++ as the base of the Mac OS, not Pascal. New interfaces and system wide classes should be defined and made accessible with patches to the compiler and not so much with patches to the OS and ROMs. This is to say that there will be a C++ interface and class defined for a routine and structure, but that the compiler will map these to their Inside Mac Pascal interfaces. Included with the recentering around C++ is the necessary creation of new editions of Inside Mac with only C++ interfaces and classes defined. Not that the old editions aren't great, but searching through manuals containing updates to updates which have probably been updated by Technical notes gets old. Also, invoking THINK C's little Pascal conversion function for arguements is, at times, annoying. Finally, Apple should lay out the structure of how a pre-emptively multi-tasking program should operate. A new method for dealing with memory could be imple- mented within new programs, but their more efficient memory handlers would simply be unnoticed by the System 7.0 MultiFinder. Wasted memory, but program- mers can know what they need to do. Once again, the compiler can handle the details of patching upon the code and providing the glue necessary to allow a program designed to run in the future Mac environment to run in the current one. What I'm suggesting is the creation of a hybrid environment which allows pro- grammers the ability to write applications for System 8 today and have them run on System 7. And if they choose not to do so, then they do not. Since all the work will have to be done some day, why not start working now on smoothing the transistion to System 8?