urlichs@smurf.sub.org (Matthias Urlichs) (03/29/90)
In comp.unix.aux, article <1990Mar27.054249.26503@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: < In article <1990Mar26.212747.11274@smurf.sub.org>, urlichs@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
dwb@sticks.apple.com (David Berry) (03/30/90)
In article <1990Mar28.213721.3427@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >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? With A/UX 2.0, you can. The lf/cr mapping gets handled for you by the normal file manager calls. David W. Berry A/UX Toolbox Engineer dwb@apple.com