Hybrid MacOS-A/UX programming (was Re: A/UX Release 2.0)

[Matthias Urlichs]

In comp.unix.aux, article <1990Mar27.054249.26503 at intercon.com>,
  amanda at mermaid.intercon.com (Amanda Walker) writes:
< In article <1990Mar26.212747.11274 at smurf.sub.org>, urlichs at smurf.sub.org
< (Matthias Urlichs) writes:
< > 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.
< 
To be more exact, what I would like to do (if I'm not beaten to it ;-) is
something like a "unixrun" MPW tool which would be given an A/UX program w/
arguments. It would then redirect stdin/our/err, fork, exec the
A/UX program, and shuffle data to and from A/UX (optionally swapping newline
and return of course) until the client exits.
The newline/return problem is something which should be given some serious
thought to anyway. I'm not happy with the fact that I seem to be unable to
open any A/UX text file with any Mac word processor without getting one
infinitely long line. But maybe A/UX 2.0 does something intelligent here?

< Step 1: decide what calls you need.
< Step 2: extract the object files you need from libc.a using 'ar'.
< Step 3: disassemble these object files into 68000 assembly code.
< Step 4: massage the resulting assembly code into a form acceptable to the
< 	MPW assembler (this isn't too hard), and assemble into an MPW
< 	object file.
< Step 5: link with your application.
< 
I suspected that something like this would be necessary. :-(
Step 4, BTW, is complicated by the fact that A/UX's notion of assembler syntax
is as different from Motorola's as could be.

< As I said, it's a hack, but it works.
< 
Thought so. ;-)

My basic question is/was if the toolbox survives that kind of programming
(especially fork/exec). The basic problem now seems to be that said fork()
would, unless A/UX 2.0 has copy-on-write and/or vfork by now, duplicate the
entire MultiFinder environment (taking time, running out of swap space).
The fork itself should not be that much of a problem since it already works
under 1.1.1.
-- 
Matthias Urlichs