[comp.sys.mac.programmer] What compilers are AppleShareable?

dan@Apple.COM (Dan Allen) (06/23/88)

In article <272@uvabick.UUCP> thomas@uvabick.UUCP (Thomas Fruin) writes:
>
>Can somebody tell me which of the current crop of Pascal and C
>compilers/development systems will work from an AppleShare server?
>I don't mean just single-user, but multi-user as well.  
>
>Presumeably MPW won't work in multi-user mode, but what about the
>LightSpeed compilers?  And Turbo Pascal?

Your presuming MPW won't work was presumptuous.  MPW 2.0 IS MULTI-USER,
except for the Shell itself.  Put the MPW Shell and your own customized
UserStartup file on your own floppy or hard disk, and put all the rest
of the interfaces and tools and libraries on a server.  (A few changes
need to be made to the startup file for things like {AIncludes} and
{PLibraries} and the like, but these changes can also be made in your
own UserStartup file.)

Our own AppleTalk group at Apple has all of MPW, all of their sources,
and all of their objects on a server.  Each workstation only has the MPW
Shell, Startup, UserStartup, and SysErrs.err files locally.

We made sure that the compilers opened their interface files and source
files read only, and that tools could take their input from read only
files as well.

Dan Allen
Apple Computer

clay@claris.UUCP (Clay Maeckel) (06/23/88)

In article <12647@apple.Apple.COM> dan@apple.apple.com.UUCP (Dan Allen) writes:
 [...]
>Your presuming MPW won't work was presumptuous.  MPW 2.0 IS MULTI-USER,
>except for the Shell itself.  Put the MPW Shell and your own customized
 [...]

It is nice to know that is works, but is it legal?  BTW: I never considered
launching anything off a server until I got an Ethertalk card just recently.

Always wondering,
-- 
 Clay Maeckel         *   UUCP: {ames,apple,portal,sun,voder}!claris!clay
 (I know nothing!)    *   Arpanet: claris!clay@ames.arc.nasa.gov
 Claris Corporation   *   AppleLink: Maeckel1   *   CompuServe: 73057,255

nick@ccicpg.UUCP (Nick Crossley) (06/24/88)

In article <12647@apple.Apple.COM> dan@apple.apple.com.UUCP (Dan Allen) writes:
> ...  Stuff about running MPW with AppleTalk ...
>
>Dan Allen
>Apple Computer

What about a version of MPW which works under MultiFinder even better than
it does currently?  That is, when will we be able to run Makes in the
background?
-- 

<<< standard disclaimers >>>
Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA
Tel. (714) 458-7282,  uucp: ...!uunet!ccicpg!nick

dan@Apple.COM (Dan Allen) (06/25/88)

In article <3248@ccicpg.UUCP> nick@ccicpg.UUCP (Nick Crossley) writes:
>What about a version of MPW which works under MultiFinder even better than
>it does currently?  That is, when will we be able to run Makes in the
>background?

The current internal releases of the MPW Shell DO support running in the
background under MultiFinder!  The MPW 3.0 release will have background
processing of tools.  The key to being MultiFinder compatible is by
calling the RotateCursor and SpinCursor calls in ToolLib. Any tool that
CURRENTLY makes these calls is ALREADY MF compatible with the new Shell.

What the new shell does is patch calls to SetCursor.  The patch allows
the MPW Shell to update any windows that need updating, and calls
WaitNextEvent so that MPW can be swapped in and out.  It works very
nicely and I have been doing background compiles for quite some time,
while downloading with MacTerminal 2.3 in the background, while writing
a letter with MS Word 3.02, while looking up phone number with HyperCard
1.2.... while using 5 MB of RAM!

Dan Allen
Apple Computer

gz@spt.entity.com (Gail Zacharias) (06/26/88)

In article <12777@apple.Apple.COM> dan@apple.apple.com.UUCP (Dan Allen) writes:
>What the new shell does is patch calls to SetCursor.  The patch allows
>the MPW Shell to update any windows that need updating, and calls
>WaitNextEvent so that MPW can be swapped in and out.

Sounds dandy, but for this one itsy bitsy little problem.  According to Inside
Mac, SetCursor is one of those calls which can be used in the presence of
dereferenced handles because it doesn't allocate memory.  Guess we can look
forward to all sorts of subtle bugs and unrepeatable crashes while using old
programs with the new shell.  Never a boring moment, eh?

--
gz@entity.com					...!mit-eddie!spt!gz
	 Now let's all repeat the non-conformist oath.