mcdonald@uxe.cso.uiuc.edu (08/12/89)
>In article <21857@dcatla.UUCP> mclek@sunb.UUCP (Larry E. Kollar) writes: ... >>I don't know about PM, but I use Macs and Amigas both quite a bit. I can >>tell the difference (I'm a tech writer, not a programmer): >> >> - The Mac dialog boxes lock out *all* user input to tasks or windows >> other than the dialog box itself. What if I want to pull up the >> on-line documentation to help me decide what to set in the dialog? >> This is a BIG malfeature of Multifinder. > This not a fault of the Mac, but of the programmer who programmed >the dialog. Mac dialogs can be set up to be totally modal, as you >describe, or to be modeless, i.e. just like any other window. It is >more work for the programmer to write programs which use modeless >dialogs, not much more work, but a little more. It is modal dialogs, >not dialogs per se, which lock you out under MultiFinder, and 99% of >the time, you have some lazy application programmer to thank for it. It is a fault of the operating system. In a true multitasking system, it is IMPOSSIBLE for one program to lock up the system, whether intentionally or because of a bug. Incidentally, I was using a Mac recently do some scanning (soon to appear as a lovely posting in sci.astro (advertisement)). It was running multifinder. The watch icon kept appearing and there was no way to stop it except the power switch. Is there a generic way on a Mac II running Multifinder to stop a program or switch programs while the watch icon is present? This is an ABSOLUTE requirement of a multitasking system. My PC under Desqview can easily do it. Doug McDonald
peirce@claris.com (Michael Peirce) (08/14/89)
In article <46100321@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > >>In article <21857@dcatla.UUCP> mclek@sunb.UUCP (Larry E. Kollar) writes: >... >> This not a fault of the Mac, but of the programmer who programmed >>the dialog. Mac dialogs can be set up to be totally modal, as you >>describe, or to be modeless, i.e. just like any other window. It is >>more work for the programmer to write programs which use modeless >>dialogs, not much more work, but a little more. It is modal dialogs, >>not dialogs per se, which lock you out under MultiFinder, and 99% of >>the time, you have some lazy application programmer to thank for it. > >It is a fault of the operating system. In a true multitasking >system, it is IMPOSSIBLE for one program to lock up the system, ^^^^^^^^^^ >whether intentionally or because of a bug. > >Doug McDonald Sigh... Of course it's possible to lock up a "true multitasking" system. Ever heard of priorities? Back in my Vax days we used to lock up Vaxes all the time by having some of the software we were developing run amuck at an elevated prioprity. System also freeze up temporarily when you get I/O storms. And for may other reasons. EVERY system can behave in ways that some users might not like all the time. EVERY system is a compromise between myriad design constraints. Multitasking ("true" or otherwise) is not a panacea. It also takes time and effort to impliment. Personally I'd rather see an async SCSI manager, among other things, before they tackle "true" multitasking... Claris Corp. | Michael R. Peirce -------------+-------------------------------------- | 5201 Patrick Henry Drive MS-C4 | Box 58168 | Santa Clara, CA 95051-8168 | (408) 987-7319 | AppleLink: peirce1 | Internet: peirce@claris.com | uucp: {ames,decwrl,apple,sun}!claris!peirce I use quotes around "true" because there really isn't such a thing. There are LOTS of kinds of multitasking. I wrote a nice multitasking OS for a 4K 6809 based machine a long time ago. It was even "true" multitasking, but I'd rather have MultiFinder any day :-)
kent@lloyd.camex.uucp (Kent Borg) (08/14/89)
In article <46100321@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >It is a fault of the operating system. In a true multitasking >system, it is IMPOSSIBLE for one program to lock up the system, >whether intentionally or because of a bug. Actually, it is partly the `fault' of the user interface. It is important for some modal dialogs to be modal. It the application is warning the user about something important, the user should not be able to go off and do something else without having read the dialog, if s/he did, on later returning to the warning, the context of the warning will have been lost, and if the warning really is important, that is too dangerous. Should the user be given a quick way to say "Wait a minute, I don't understand here, let me check something..."? Yes, that is what the "Cancel" button should do. Should the user be allowed to switch to another application during a long operation? Yes, applications programmers should allow that. Do pre-MultiFinder applications work amazingly well under MultiFinder? Yes, MultiFinder was a trade-off between new design and compatibility with old applications, and it made those trade-offs *very* well. Should the user have some way of blowing away the current application, while leaving the rest alone? I'm not sure. Maybe the debugger switch sould do that when a debugger is not installed. >Is there a generic way on a Mac II running Multifinder to stop a >program or switch programs while the watch icon is present? This >is an ABSOLUTE requirement of a multitasking system. My PC >under Desqview can easily do it. No, there is no way for Joe- and Jane-User to do it currently, but there is a way *you* can. Install MacsBug, reboot your machine. Now, next time you want to blow away an application, hit the programmer's switch to enter MacsBug, and type "es", for exit to shell. Alternatively, go into ResEdit and create an FKEY in your system file with the data a9f4 in it. Now, when you hit cmd-shift-<the number of your FKEY, should be 5 to 9>, you will get an exit to shell. This does not *always* work (I know Stuffit sometimes refuses to die), but it usually will kill the current application, and it usually will not kill your other applications--though your errant application may have already. Kent Borg kent@lloyd.uucp or ...!husc6!lloyd!kent
) (08/14/89)
In article <46100321@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >Incidentally, I was using a Mac recently do some scanning (soon >to appear as a lovely posting in sci.astro (advertisement)). It >was running multifinder. The watch icon kept appearing and >there was no way to stop it except the power switch. This is beacause the scanner is a SCSI device, and the Mac has no way of handling asynchronous SCSI (Because of the plusses... Do we HAVE to drag them along for eternal time ? But there is a light at the end of the tunnel, VM in Sys 7 ! Soon to arrive (around Sys 9 or so :-) : Protected Memory) I once saw a "TRUE MULTITASKING" UNIX system freeze while the SCSI tape streamer streamed. You can always use nice -20 (if you are root) etc. There are many ways to lock up a "true" multitasking system. Try using sockets (play "hunt" for instance) and send lots of small data. Quick. Your system manager's gonna hate you (and have to reboot the machine) :-( Happy hacking anyway, sez' h+@nada.kth.se -- Loop, Endless: (n) Also called Dynamic Halt. See Endless Loop.
peirce@claris.com (Michael Peirce) (08/14/89)
In article <474@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: >In article <46100321@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > >>Is there a generic way on a Mac II running Multifinder to stop a >>program or switch programs while the watch icon is present? This >>is an ABSOLUTE requirement of a multitasking system. My PC >>under Desqview can easily do it. > >No, there is no way for Joe- and Jane-User to do it currently, but >there is a way *you* can. Install MacsBug, reboot your machine. Now, >next time you want to blow away an application, hit the programmer's >switch to enter MacsBug, and type "es", for exit to shell. >Alternatively, go into ResEdit and create an FKEY in your system file >with the data a9f4 in it. Now, when you hit cmd-shift-<the number of >your FKEY, should be 5 to 9>, you will get an exit to shell. > >Kent Borg If you do this, it's usually good to check memory location $910. This contains the name of the currently switched in application. There are times when you think you are killing ApplicationX, but another App has gotten a little time to run (Backgrounder is there often). If the application you want to kill isn't named at $910, just continue running for a bit more, then trap back to the debugger... Claris Corp. | Michael R. Peirce -------------+-------------------------------------- | 5201 Patrick Henry Drive MS-C4 | Box 58168 | Santa Clara, CA 95051-8168 | (408) 987-7319 | AppleLink: peirce1 | Internet: peirce@claris.com | uucp: {ames,decwrl,apple,sun}!claris!peirce
enk@corona (Edan Kabatchnik) (08/15/89)
In some article about Multifinder vs. Multitasking, someone writes: >> This not a fault of the Mac, but of the programmer who programmed >> the dialog. Mac dialogs can be set up to be totally modal, as you >> describe, or to be modeless, i.e. just like any other window. It is >> more work for the programmer to write programs which use modeless >> dialogs, not much more work, but a little more. It is modal dialogs, >> not dialogs per se, which lock you out under MultiFinder, and 99% of >> the time, you have some lazy application programmer to thank for it. > It is a fault of the operating system. In a true multitasking > system, it is IMPOSSIBLE for one program to lock up the system, > whether intentionally or because of a bug. This is just not the case. Here are two examples: 1) Gnumacstool running on the Sun Workstation: when one hits the right menu button quickly and releases it, the Emacs Menu comes up. User input cannot be sent anywhere until the menu is dismissed. 2) Framemaker running on the Sun Workstation: when Frame Maker's modal dialogs appear for things like "OK to Quit Frame Maker?" the modal dialog must be dismissed until the user can direct any of his or her input to another process. At this point, one might argue that "Yes, but other windows (i.e. processes) can continue to carry out any task not related to user input, e.g. a compilation." This is also true for the Macintosh. Take TOPS for example. TOPS can service a remote disk access while a modal dialog is up or while a menu selection is being made. The Macintosh is not a true multitasking system from the perspective of a programmer, not the user: a programmer wishing to write a "multitasking" application under Macintosh OS must take great care to write his program carefully. On a UNIX system, the programmer simply has an easier time writing a such a program. The user, however, can observe the effects of multitasking under Macintosh OS just as easily as he can under UNIX: if the programmer who wrote the applications he or she is using spent the time to develop them properly, the user is rewarded with the benefit of multitasking. The problem is that every application you use must be written properly in order for the whole system to multitask properly. +----------------------------------------------------+-------------------------+ |There is a club if you would like to go. | Edan Kabatchnik | |You could meet somebody who really loves you. +-------------------------+ |So you go, and you stand on your own. | MIT | |And you leave on your own. | enk@wheaties.ai.mit.edu | |And you go home, and you cry, and you want to die. |Schlumberger Technologies| | - The Smiths | enk@slcs.slb.com | +----------------------------------------------------+-------------------------+