rang@cs.wisc.edu (Anton Rang) (05/07/91)
In article <15931@helios.TAMU.EDU> jeff@archone.tamu.edu (Jeff Raymond) writes: >Windows 3.0 can do it, the Amiga can do it, so why not the Mac? I'm not >an Apple engineer nor do I claim to know how they do what they do, but if >this functionality can be grafted on top of DOS' aching bones (across >multiple platforms), certainly it can be done on the Mac as well. It can be done, though without a 68020 and PMMU it's may not be worth the effort (protected memory and separate address spaces really help here). The big problem, at least as I see it, is that the current libraries aren't re-entrant. Some of these things would be easy to change; others wouldn't. For instance, take QuickDraw. Suppose that process A is busily doing a DrawPicture. What happens when process B is context switched in and tries to update its window which was moved earlier? I suspect there are parts of QuickDraw which expect various global variables and data structures to be in consistent states, and that you'd have a problem. (What if you're in the process of creating a new window and it's not fully linked into the window list when a new process tries to create one, too?) I don't think the file manager currently processes more than one request either, though that isn't as serious a problem (especially when asynchronous I/O can be used) since it at least queues multiple requests for service. Some parts of the system which have been introduced for MultiFinder will help quite a bit when preemptive multitasking finally comes (and I do believe it will, though I'll make no predictions on dates). The notification manager, for instance, is a great tool even with MF. Programs which depend on global variables may have to be changed, though a lot of the functionality could be emulated by using the MMU to trap accesses to global variable addresses and emulate them (at some cost in speed). Programs which use the managers should work fine, since the *internals* can be changed to allow for pre-emptive multitasking without changing the interface. (At least, I haven't come up with any obvious cases where it can't be done yet.) It's possible to do. It'll be expensive and take a long time. I'd hope that Apple's already working on this stuff, and that their newer code (e.g. System 7) is written with it in mind.... Anton +---------------------------+------------------+-------------+----------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | "VMS Forever!" | +---------------------------+------------------+-------------+----------------+
robertk@lotatg.lotus.com (Robert Krajewski) (05/08/91)
In article <RANG.91May7015648@nexus.cs.wisc.edu> rang@cs.wisc.edu (Anton Rang) writes:
For instance, take QuickDraw. Suppose that process A is busily
doing a DrawPicture. What happens when process B is context switched
in and tries to update its window which was moved earlier? I suspect
there are parts of QuickDraw which expect various global variables and
data structures to be in consistent states, and that you'd have a
problem.
There is a way to get around this. It would be the following rule:
drawing is only done in a thread (flow of control) that is controlled
by the Process Manager's (nee MultiFinder) event loop. Old programs
would continue to work without changes. New programs would have to spawn
off separate threads to actually compute things in an environment
where they knew that preemptive scheduling was in effect. And, they
would not be allowed to draw; an application would have to send
events to itself, and handle the drawing in the round-robin thread.
This is basically how OS/2-PM works. Even though it has true
preemptive multitasking, Presentation Manager programs still have to
obey the event-loop discipline, just as under Macintosh or Windows.
(The PM event/message scheduler uses a round-robin approach so that it
can serialize mouse and keyboard events.) The beneficial difference is
that OS/2 apps can spawn threads (very cheap processes that live in
the same address space as the spawner) that are decoupled from the PM
thread discipline. Lengthy tasks should be performed in non-PM
threads; in fact, PM will put up a dialog box if a task does not
release control from a message handler in approximately a second.
In OS/2 PM, drawing in the non-PM thread is discouraged, if not
prohibited, even though the drawing environment is an argument to the
graphics functions, instead of an implicit global as it is on the Mac.
Non-PM threads cannot wait for or synchronously send messages to
windows, but they can asynchronously send (post) messages to windows.
OS/2 also offers more general forms of inter-thread (process)
communications like semaphores and queues, if you don't want to use
window messages.
Some parts of the system which have been introduced for MultiFinder
will help quite a bit when preemptive multitasking finally come...
Programs which depend on global variables may have to be changed,
though a lot of the functionality could be emulated by using the MMU
to trap accesses to global variable addresses and emulate them (at
some cost in speed). Programs which use the managers should work
fine, since the *internals* can be changed to allow for pre-emptive
multitasking without changing the interface.
Exactly. The real problem with the Mac and ``real'' multitasking is
that it's still possible for an application to know too much system
globals and data structures -- these are things that Multifinder has
to swap in and out when applications are switched. New facilities and
interfaces to old facilities are much better about this, but I'm not
enough of a Mac expert to say if you could build a cleaner, smaller
multitasker assuming that *all* programs did in fact use all the
latest/cleanest interfaces.mpretzel@cs.utexas.edu (Benjamin Allums) (05/11/91)
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?philip@pescadero.stanford.edu (Philip Machanick) (05/12/91)
In article <1443@cash.cs.utexas.edu> mpretzel@cs.utexas.edu (Benjamin Allums) writes: > 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. The MultiFinder model has alway allowed applications to request extra memory outside their initial space. Maybe this feature hasn't been much used up to now because MultiFinder isn't always on (of course this will change with SYstem 7). The real problem is fragmentation, which occurs because all applications are running in the same address space. Your proposal of what Apple should do (deleted) does not address this problem at all. I think the only way out of this is to design a completely new OS with a Mac compatibility mode, much the way AUX works (except I don't think this new OS should be unix). Your old Mac applications will still be able to run, but new applications will run directly under the new OS. >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? Now this I can agree with. Phliip Machanick
rang@cs.wisc.edu (Anton Rang) (05/13/91)
>Windows - Windows can multitask DOS applications if it runs 8086 based [...] > This is due entirely to the fact that the 386 chip was designed to > run multiple virtual 8086 machines. Windows does no magic. Well, actually it does do some "magic" -- it takes care of managing the screen and keyboard. MS-DOS programs make calls to the operating system which are intercepted by Windows. (I assume, though I'm not familiar with the internals, that there is either some interception of direct writes to video memory, or separate copies of video memory swapped in and out as needed.) >Amiga - From the ground up, day one, the Amiga's operating system was designed > to pre-emptively multitask. That is why it does it. Right. >Mac - Implementing a pre-emptive multi-tasking OS would guarantee software > incompatibility for all programs. No, no. See my earlier posting (heck, see several hundred earlier postings, though they're scattered over two years at least :-). There is no reason why pre-emptive multitasking couldn't be implemented on the Mac without requiring existing programs to be changed. > [ ... ] 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. Yes, *but* this isn't necessarily a problem. Given protected memory (a PMMU or 68030), every application *can* have complete access to "all available memory." The way that UNIX works, for instance, is that programs think they have access to "infinite memory." It would be fairly easy to use the MultiFinder model (setting a memory size), or simply give each application a large virtual address space. In fact, though it would be complicated, the current memory manager model would let virtual memory be reclaimed, by doing a purge and/or relocating it. Hmmm...this sounds interesting.... >What I think Apple should do. > >Apple has just completed a total rewrite of system software into C++. Is this true? (Not intended to be a challenge, just an honest question--I'm curious.) [ ... various suggestions not really relevant to pre-emptive MT elided ... ] >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. Yes, this would be nice. Maybe have a bit on applications which is like the '32-bit clean' bit, but means 'knows System 8.0' :-). >Since all the work will have to be done some day, why not start >working now on smoothing the transistion to System 8? I hope Apple's been already thinking about this and talking it over with developers, actually. :-) I'd like to see this sort of thing soon (but not too soon, I gotta replace my SE with a //fx first :-). Anton +---------------------------+------------------+-------------+----------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | "VMS Forever!" | +---------------------------+------------------+-------------+----------------+
esink@turia.dit.upm.es (Eric Wayne Sink) (05/13/91)
In article <1443@cash.cs.utexas.edu> mpretzel@cs.utexas.edu (Benjamin Allums) writes: > >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. > Strong words. I'm not sure if I disagree or not. Apple's engineers are awfully clever people, if not always motivated in the direction I want them to go. I might hope that they could produce a nice preemptive multitasking, MEMORY PROTECTED OS which is still compatible. Maybe not. Yes, the memory model is a problem, but if the OS may assume the presence of a MMU, I believe the use of a virtual address space would avoid the scenario you speak of. Of course, don't expect this to run on a Classic. The Amiga : yes, more efficient. But what happens if a process doesn't explicitly release its allocated memory ? Disclaimer : I like the Amiga. A lot. I confess that I did sell my Amiga to buy something better, but in my case I bought an engagement ring ! > >What I think Apple should do. > >Apple has just completed a total rewrite of system software into C++. No, they rewrote the Finder in C++. They may have rewritten other stuff too, but they did NOT rewrite the WHOLE system. Of course we've waited long enough to start thinking that they had... :-) >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? Cool ideas, but the DESIGN of System 8 is perhaps the biggest part (as opposed to the implementation). I am impressed with Apple and how they have been innovative with their OS (any arguments containing the words GNU, Xerox, Windows, legal, Parc Place, or any profanity, should be sent to /dev/null). The Mac OS is not DOS, and I am not interested in the functionality of DOS. Nor is it UNIX, but I want the functionality of UNIX in a Macintosh OS. No, I don't want my Mac to smile at me when I turn it on, and then give me a csh. But I WOULD like to see the Mac OS support protected memory, preemptive multitasking, standard IO, virtual memory, and IAC; ALL of it in a manner that it truly *Macintosh*. Some of this functionality is going to be released today. Some of it is going to be rather difficult to implement. In summary, I want more than just preemptive multitasking. The decision of what features to include in the System, and how to handle them in a Macintoshy way, is just as difficult as cranking out the C++ code to do it. Problems I see : How are we going to let simultaneously running programs share the menu bar ? It would be nice to have a whole program in a window, so I could do two things at once without having to put one in front of the other. How are we going to define an analogy to standard IO ? I would really like to be able to arbitrarily pipe the output of some program to some other program's input. But in a GUI system, what form does this IO stream take ? AppleEvents ? No flames ! The Mac, the Amiga, and whatever UNIX box you like are all great platforms. I am simply interested in seeing the functionality of the Mac advance. Politely expressed opinions, pro or con, are a delight. Eric Eric W. Sink | "If no one is criticizing |Opinions Departamento de Telematica | your work, it is possible |mine - Universidad Politecnica de Madrid| that you are not doing |all of esink@turia.dit.upm.es | anything." -George Verwer |them.
death@public.BTR.COM (David Burrowes death@btr.com) (05/14/91)
>>Mac - Implementing a pre-emptive multi-tasking OS would guarantee software >> incompatibility for all programs. Certainly they could be modified and It's my understanding that, under AUX 2.0, one can run most Mac applications as separate processes in the preemptively multisking AUX system. That is, most Mac apps (those that aren't doing heinous nasty things =) are apparently happy as clams living in a preemptively multitasking world. NOTE! I have never seen this! I have only been assured this by one who has used the system. If this info is not accurate, I'd love to know! >How are we going to let simultaneously running programs share the >menu bar ? It would be nice to have a whole program in a window, so >I could do two things at once without having to put one in front >of the other. Probably much like the NeXT does, I expect. The current set of menus will reflect whatever application the user is working on at that time (thus, they'll switch just as they do with Multifinder now). This would not work if you have more than one user working on the screen at once. But, that messes up a lot of other things too. =) \david john burrowes death@btr.com
mpretzel@cs.utexas.edu (Benjamin Allums) (05/14/91)
In regard to AUX 2.0 multitasking Mac apps pre-emptively . . . it ain't happening. AUX pre-emptively multitasks AUX programs, UNIX programs, and a special version of MultiFinder. Mac apps run just like they would on a Mac system with a normal MultiFinder, co-operatively. So, MultiFinder is a UNIX task which is pre-emptively multitasked which just so happens to co-operatively multi- task apps in its own memory protected application space.
bc@Apple.COM (bill coderre) (05/15/91)
esink@turia.dit.upm.es (Eric Wayne Sink) writes, essentially: "I want protected memory more than preemptive multitasking." Well, since you are a UNIX hacker, those are nice things to want. As a Mac programmer, I want a main event loop that doesn't include every kludge since System 1.0. Since I write 5 page programs, I really don't want 20 pages of code to support the OS. (This is a good argument for MacApp, even if you IGNORE all the user interface help and the object-oriented-ness.) I also want a completely re-written Inside Mac that doesn't force me to memorize THOUSANDS of pages of irrelevant, outdated, WRONG technical data. Of course, this has nothing to do with what USERS want. They want the Mac to stay compatible with older programs. They want it to speed up or at least stay pretty fast. They want more features. They want less memory eaten by the System. And, they want to be stunned by the easiest, best-looking interface available without chemical alterations. Rewriting almost the entire OS, including Quickdraw, TextEdit, every driver, INIT, and DA out there, most of the file system code, the Dialog/Alert/Window managers, sound managers, etc etc, is perhaps a bad thing for the other 99% of the Mac clientele. Of course, if you wanna start in on it, go right ahead. Mean time, I'll use System 7. bill coderre who didn't participate in System 7, but is damn proud of those who did.
ddl683@sarah.albany.edu (Cinderella Man) (05/15/91)
From bc@Apple.COM (bill coderre) come these immortal words: [article WIPED CLEAN LIKE A CAR WINDSHIELD] >bill coderre > >who didn't participate in System 7, but is damn proud of those who >did. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "SUPPORT THE MEN AND WOMEN OF OPERATION SYSTEM SEVEN" "GOD BLESS OUR PROGRAMMERS" freakin' from finals (carasso mode) -- Bill Gates *IS* Hussein! -- + + "When nothing else remains, one must scream. Silence is the ultimate + + + crime against humanity." -- Nadezhda Mandelstam + + _________________________ [Affix disclaimer here] ________________________ + + + + + Each one's life a novel no one else has read -- Peart + + + +
Jim.Spencer@p510.f22.n282.z1.fidonet.org (Jim Spencer) (05/18/91)
Anton Rang writes in a message to All
>Apple has just completed a total rewrite of system software into C++.
AR> Is this true? (Not intended to be a challenge, just an honest
AR> question--I'm curious.)
Its not completely true. The Finder was rewritten in C++.
* Origin: White Mailer Test Point (1.0d6) (1:282/22.510)