info-mac@utcsrgv.UUCP (info-mac) (04/26/84)
Date: Sun 22 Apr 84 21:56:31-PST
From: Bill Croft <uw-beaver!CROFT@SUMEX-AIM.ARPA>
Subject: Macintosh programming in C under UNIX: a progress report
To: info-mac@SUMEX-AIM.ARPA
Cc: croft@SUMEX-AIM.ARPA
At the Stanford SUMEX project we are developing "MacEther", a cluster
controller that allows groups of Macintoshes to use the file server
capabilities of our TCP Ethernet hosts. As part of this project
we have created a Macintosh software development environment on our UNIX
system. It consists of the following pieces:
68000 C compiler/assembler/loader/libraries. This already existed from
earlier projects at MIT (Nu) and Stanford (SUN, V). The compiler is
Johnson's PCC. If your UNIX is already 68000 based you won't even need
these.
Resource Compiler. This is equivalent to the "rmaker" that comes with
the Lisa development system. Currently CODE, HEX, and STR type resources
are supported. For CODE, rmaker takes the output from the loader (with
relocation information still attached) and run-length encodes the relocation
into the resulting resource. Thus the resource file on the Mac is only
very slightly bigger than the corresponding executable would be on UNIX.
Rmaker currently allows only one segment per program, however this
segment can be as large as you like. (The Pascal system limits each
segment to 32K bytes because it uses PC relative addressing). We don't
see this as a limitation with the simple applications we are designing.
However if your program+data requirements are greater than about 66K
bytes (128K doesnt go very far after the OS and screen memory are
accounted for) then you may need to make heavy use of program segmentation
and our development environment may not work for you. Let's hope that
big Macs are right around the corner.
Run-time startoff. This gets control first after the Mac loads the
C program into memory. Using the relocation information from above,
the startoff relocates the C program to its current load address.
Download utilities. These are used to hexify and dehexify the binary
resource file on UNIX into a form that can be transfered using MacTerminal.
After the printable file exists on the Mac, the inverse program converts
it to a binary executable resource file. Since this is a bit awkward,
we may soon try to convert the C version of Kermit to run in a
primitive fashion on the Mac.
Header definition files and argument linkage conversion routines.
These provide the C programmer with a parallel view of Mac
structures as are available with the record definitions under Pascal.
Since 99% of the toolbox utilities are entered via traps to the ROM,
this is rather straightforward. However under the Lisa development
system there are a couple object modules ("Graf3D" and numeric printf/
scanf functions in "sane") that will not be immediately available.
We may figure out some scheme similar to the "package" approach
now used for StdFile and MacPrint to handle this.
All that we mention above is currently working, we are finishing up
the linkage conversion part. We expect a final announcement of
availability to be made sometime in May. Please no inquiries until
then.
We plan to make this software available as a TAR file on the SUMEX-AIM
2060 for FTPing over the Arpanet. The software will be treated similar
to Columbia's Kermit project: it is unsupported, not to be sold,
and changes/modifications should be reported back to us for revision
of the master copy.
--Bill Croft, Stanford Medical Center
-------