Path: utzoo!attcan!uunet!snorkelwacker!ira.uka.de!smurf!urlichs
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.unix.aux
Subject: Re: A/UX Release 2.0 (long)
Message-ID: <1990Mar26.212747.11274@smurf.sub.org>
Date: 26 Mar 90 21:27:47 GMT
References: <239@inpnms.UUCP> <2863@unisoft.UUCP> <14743@phoenix.Princeton.EDU> <1990Mar22.152002.15159@athena.mit.edu> <7359@goofy.Apple.COM>
Organization: University of Karlsruhe, FRG
Lines: 37

In comp.unix.aux, article <7359@goofy.Apple.COM>,
  dwb@sticks.apple.com (David Berry) writes:
< In article <1990Mar22.152002.15159@athena.mit.edu> vpsingha@athena.mit.edu (Vivek P. Singhal) writes:
< >
< >Even after reading numerous postings about the power of the A/UX
< >operating environment, I still haven't seen the answer to one
< >question: under A/UX 2.0, can applications be written that take
< >advantage of BOTH the Macintosh toolbox and Unix library calls (e.g.
< >fork ())?  Can such "hybrid" programs be written with existing tools
< >like MPW?  Or, are programs that use the Mac toolbox restricted to
< >residing in the "compatibility" layer, unable to use the
< >multiprocessing (and other) capabilities of Unix?

< 	Yes, a hybrid program can be written to take advantage of
< the toolbox and unix libraries both.  CommandShell (the by now infamous
< terminal emulator) is one such program.  The documentation suite includes,
< "A/UX Toolbox" which contains complete information on how to do it.

The question here seems to be not whether you can write an A/UX binary which
happens to use the Toolbox (the original "term" from A/UX 1.0 did that, even),
but whether you could write a MacOS application (and/or standalone code
resource, like an XCMD/XFCN for Hypercard) which happens to use A/UX system
calls, including fork/exec.

I, for one, would very much like to convince the MPW Shell (or even Hypercard)
to use some Unix facility or other, but the Shell's notion of running a tool
(and Hypercard's of loading an XCFN into memory) and A/UX's notion of
fork+exec have virtually nothing in common.

I suspect that one of the obstacles would be that almost all system calls I
would like to use are in libc.a, and MPW's linker has never heard of COFF.
One would also have to do something about global variables, right? (Most C
library calls use them.) And how about things like sbrk(2)?
Lots of not-quite--minor difficulties, but it could be made to work.
If enough people need it. (I doubt that.)
-- 
Matthias Urlichs