hsg@duke.UUCP (04/19/87)
Does anyone out there know if Apple will be trying to allow Mac applications to run as tasks under UNIX? The situation seems to be that one will have to reboot (!) the Mac II in order to run the Finder (or Juggler). This seems to throw away the whole advantage of having a Mac II as opposed to a Mac Plus and a Sun workstation, and is also very wasteful if one is trying to run moderate sized computations under the UNIX environment, which will die upon rebooting and switching to the Finder. Especially nice would be the ability to run Finder/Juggler as a task under UNIX so that both modes are available at the same time. The Mac II would then be far more useful than a Sun workstation. Someone should be clever enough to pull a trick like that off. One more comment: will the scroll bars for standard windows be improved? Once one has large (say 19") screens, it is pretty painful to jump back and forth large distances to click on the righ/left or up/down scroll arrows. Much better would be to put double arrows: <--> at each edge of the screen, or even 4 arrow heads at each corner so that screen manipulation can be done with a minimum of mousing. It would also be helpful to add universal (application independent) key-board equivalents for scrolling in both directions for the active window.
jww@sdcsvax.UCSD.EDU (Joel West) (04/19/87)
Here's what I've got on A/UX:
A-line traps supported
Allowed: Toolbox, OS Event, OS Utilities, packages
Disallowed: Printing, device, dis, sound, serial, appletalk,
vertical retrace, disk initialization, SCSI
Restricted:
Memory Manager (most is ok)
File Manager (high-level only)
Segment Loader
If a Macintosh application follows these rules, you can run ONE on
A/UX against any number of UNIX tasks. No recompilation required.
--
Joel West
{ucbvax,ihnp4}!sdcsvax!jww (ihnp4!gould9!joel once I fix news)
jww@sdcsvax.ucsd.edu if you mustali@rocky.STANFORD.EDU (Ali Ozer) (04/19/87)
In article <9519@duke.cs.duke.edu> Henry Greenside writes: >Does anyone out there know if Apple will be trying to allow Mac applications >to run as tasks under UNIX? ... >Especially nice would be the ability to run Finder/Juggler as a task under >UNIX so that both modes are available at the same time. The Mac II would then >be far more useful than a Sun workstation. But most Mac applications are use busy-waiting in their main event loops, no? It might be possible to run them as tasks, but they will all be "cpu-hogs". It seems like most old applications will not do too well under a multitasking Mac II Finder. Ali Ozer, ali@rocky.stanford.edu
mrh@Shasta.STANFORD.EDU (Marc Hannah) (04/20/87)
In article <9519@duke.cs.duke.edu>, hsg@duke.cs.duke.edu (Henry Greenside) writes: > One more comment: will the scroll bars for standard windows be improved? Once > one has large (say 19") screens, it is pretty painful to jump back and > forth large distances to click on the righ/left or up/down scroll arrows. > Much better would be to put double arrows: <--> at each edge of the > screen, or even 4 arrow heads at each corner so that screen manipulation > can be done with a minimum of mousing. It would also be helpful to add > universal (application independent) key-board equivalents for scrolling > in both directions for the active window. VersaTerm 3.0, the March 21 1987 version allows the user to scroll by using the following keyboard equivalents: Command - uparrow move up one screenfull Command - downarrow move down one screenfull Command - leftarrow move the thumb to the top of the scrollbar Command - downarrow move the thumb to the bottom of the scrollbar I find these equivalents to be excellent. Personally I wish all programs had similar equivalents. David Gelphman BITNET address: DAVEG@SLACVM Bin #88 SLAC ARPANET address: DAVEG@SLACVM.BITNET Stanford, Calif. 94305 UUCP address: ...psuvax1!daveg%slacvm.bitnet 415-854-3300 x2538 usual disclaimer #432 applies: my employer apologizes for the fact that I have access to this net.
huxham@apple.UUCP (Fred Huxham) (04/21/87)
In article <9519@duke.cs.duke.edu> hsg@duke.cs.duke.edu (Henry Greenside) writes: >Does anyone out there know if Apple will be trying to allow Mac applications >to run as tasks under UNIX? Applications that are "well behaved" currently run under A/UX. One example is FullPaint. (It did require one patch where they had gone in and monkeyed with the memory manager flag bytes. We use the full 32-bits under A/UX. But other than the one patch, everything was fine.) Fred
lincoln@randvax.UUCP (Tom Lincoln) (04/21/87)
In article <9519@duke.cs.duke.edu> hsg@duke.cs.duke.edu (Henry Greenside) writes: > >Especially nice would be the ability to run Finder/Juggler as a task under >UNIX so that both modes are available at the same time. The Mac II would then >be far more useful than a Sun workstation. Someone should be clever enough >to pull a trick like that off. > Agree. One gets the flavor of this possability using the MAC+ as a terminal to a Sun Unix system. The flow back and forth adds significant flexability. p q \|/ /|\ TOM LINCOLN lincoln@rand-unix.ARPA \|/ "Life is short, art is long, opportunity fugitive, /|\ experimenting dangerous, reasoning difficult." Signature pasted in from MAC file.
huxham@apple.UUCP (Fred Huxham) (04/22/87)
In article <252@rocky.STANFORD.EDU> ali@rocky.UUCP (Ali Ozer) writes: >In article <9519@duke.cs.duke.edu> Henry Greenside writes: >>Does anyone out there know if Apple will be trying to allow Mac applications >>to run as tasks under UNIX? ... >>Especially nice would be the ability to run Finder/Juggler as a task under >>UNIX so that both modes are available at the same time. The Mac II would then >>be far more useful than a Sun workstation. > >But most Mac applications are use busy-waiting in their main event loops, >no? It might be possible to run them as tasks, but they will all >be "cpu-hogs". It seems like most old applications will not do too well >under a multitasking Mac II Finder. But most are just processing null events, waiting for events that they really want to handle. If there was some way to only deal with "real" events and let null event time be shared, well that would be cool.... Is anyone at Apple listening? ...Oh that's right, I'm at Apple, never mind. Fred
ali@rocky.STANFORD.EDU (Ali Ozer) (04/22/87)
In article <649@apple.UUCP> huxham@apple.UUCP (Fred Huxham) writes: >In article <252@rocky.STANFORD.EDU> ali@rocky.UUCP (I) write: >>But most Mac applications are use busy-waiting in their main event loops, >>no? It might be possible to run them as tasks, but they will all >>be "cpu-hogs". It seems like most old applications will not do too well >>under a multitasking Mac II Finder. > >But most are just processing null events, waiting for events that they really >want to handle. If there was some way to only deal with "real" events and >let null event time be shared, well that would be cool.... Well, one way to get around this is to start using "true" event based input handlers --- using interrupts and all. (Of course that shouldn't mean you have to go way down and grind interrupt code in assembly!) For instance, in the Amiga, you can "sleep" until an event occurs with the following type of statement: WakeUpBits = Wait (bitset); This will cause the task to go to sleep. The scheduler will not awaken this task until the an event specified in "bitset" occurs. For instance, if you want the task to wake up on some user I/O (such as mouse or keyboard), you might say "Wait (IDCMPSig)". If you also want a timer event to wake the task up you might say "Wait (IDCMPSig | TimerSig)". This would be useful in a game where things happened in real time (say every 5 seconds) but you wanted to be able to capture user event at the time it happened... You tell which event happened by looking at WakeUpBits. This method of programming certainly beats... while not Button do; when it comes to efficiency and proper behaviour in multitasking environments. Seems like existing applications would have to be changed, but, if the correct functions are added to the Toolbox, the changes in the applications can probably be kept to a minimum. (Because, after all, once you recieve the event (whether you busy wait or sleep) you have to do the same sort of case-statement to determine what the event was and to act upon it. So that part of the application would not have to be changed.) Ali Ozer, ali@rocky.stanford.edu
mce@fluke.UUCP (04/23/87)
In article <252@rocky.STANFORD.EDU> ali@rocky.UUCP (Ali Ozer) writes: > But most Mac applications are use busy-waiting in their main event > loops, no? It might be possible to run them as tasks, but they will > all be "cpu-hogs". It seems like most old applications will not do > too well under a multitasking Mac II Finder. Assuming a multitasking Mac II acts something like the SUN-3/75 I am currently using, you can have many "CPU hogs" without any performance degradement. After all, if your CPU is idle, it is in a busy-wait loop of sorts in the kernel/finder. Certainly response is slower, but not to the point that I can notice it. The 68020 has a lot of horsepower. I do suspect that Mac applications running under A/UX will be somewhat less responsive than running under the Finder. But that the reason will be the overhead of running A/UX (virtual memory, context switches, etc). Brian McElhinney mce@tc.fluke.com
barmar@think.uucp (Barry Margolin) (04/28/87)
In article <252@rocky.STANFORD.EDU> ali@rocky.UUCP (Ali Ozer) writes: >But most Mac applications are use busy-waiting in their main event loops, >no? It might be possible to run them as tasks, but they will all >be "cpu-hogs". It seems like most old applications will not do too well >under a multitasking Mac II Finder. Each time through the loop a Mac application is required to call getevent (I think that's its name, I haven't actually done any Mac programming). This can make a system call so that the Mac-emulation process will block until there's actually an event.
jdb@mordor.s1.gov (John Bruner) (04/29/87)
One of the characteristics of GetNextEvent that some applications depend upon is that it does *not* block if there is no event (hence the "null" event). For instance, well-behaved applications (written for the current operating system) must repeatedly call SystemTask, TEIdle, etc. They may also want to do some explicit busy-waiting on other things (e.g. the Ticks variable or background I/O that doesn't call a completion routine). A multitasking system can't simply block a task if no event is ready for it. There are workarounds -- the task could be blocked until the next lbolt wakeup (er, ah, wrong operating system -- say for the next 59 ticks or so). However, the current paradigm for Mac programming is at a pretty low level (witness the use of timer constants to set baud rates for the serial ports instead of small integers which index an internal hardware-dependent table). That, and the large number of magic state variables in low memory, make it harder to multiprogram programs written for the Mac O/S than programs written for more conventional O/S environments. (Harder, not impossible.) -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) jdb@mordor.s1.gov ...!seismo!mordor!jdb (415) 423-4848
zrm@mit-eddie.UUCP (04/29/87)
In article <7832@mordor.s1.gov> jdb@mordor.UUCP (John Bruner) writes: >One of the characteristics of GetNextEvent that some applications >depend upon is that it does *not* block if there is no event (hence >the "null" event). For instance, well-behaved applications (written Quite right! Scratch what I said about blocking on a lack of events. As an example, I wrote a program that calculates the Mandelbrot fractal and plots it. To remain interactive, it polls the event manager so that you can at least run DAs while it is cruching away at the fractal. Really, any application that works on something, like background printing, and remains interactive would be completely screwed by blocking on a lack of events. That means that a Macintosh running Unix and a Macintosh application would be faced with the serious problem of a having a task that is always runnable and hardly ever doing anything useful with its time. Has Apple asked developers what they want in multi-tasking? I could make do with some rudimentary stack switching and a re-entrant memory manager (if it isn't already). And a place to put background tasks (e.g. a third heap zone) would be nice. With that, one could implement background processing very nicely. -Zigurd