Using A/UX to build MacOS applications

[Kent Sandvik]

In article <GERSON.91Jun7135216 at dupin.parc.xerox.com>, gerson at parc.xerox.com (Dan Gerson) writes:
 
> I'd like to be able to use A/UX as a programming environment for building standard
> (non-A/UX) MacOS applications.  Basically, I want to be able to use Emacs, g++, etc.
> instead of the limited development choices available under the MacOS.

Well, it's a matter of taste, after a couple of years of exposure of Mac development
tools, especially on the OOPS side, I'm not a die-hard UNIX tool user anymore (who
could do C++ programming without a decent browser :-) ?).
 
> According to the 1.1 documentation (yes, I'm running 2.0.1 but I never bought a
> new doc set), the only apparent way to do this is for me to use GNU tools or
> whatever to write and debug the program under A/UX, and then to port the sources
> to the Mac, and run a MacOS compiler to generate the executable.

Many of the GNU tools are ported to the MPW MacOS environment (gcc, g++ according to 
a rumor I heard last week, flex, bison...). Instead of gdb one could use Jasik's Debugger,
SADE or SourceBug, which are far more graphical (and in that sense easy to learn).

> I'd prefer to be able to use g++ etc. directly.  One reason is that there is not
> a g++ which runs under MacOS.  Of course, I will be writing everything in a AT&T
> C++ 2.0 conformant subset anyway, so I could possibly port the code to Zortech
> C++ or whatever.  But that would preclude me from using any useful Unix
> libraries which might just happen to work under MacOS (that is, if they don't
> make any system calls - at least none that I don't supply my own version of.
> For example, lex and yacc should work ok when I define yyinput etc.).

Someone correct me if I'm wrong, but the g++ does not conform in all cases with
Cfront, so there are some additional features that will not work in either environment.
We have both AT&T Cfront and Zortech C++ ported for the MPW environment (and I'm still
waiting for the verification that g++ is ported as well).
 
> I understand that the problem is that the A/UX compilers will be generating
> AppleDouble files, where the data file is a COFF format executable.  But this
> raises two questions:

Yes, the A/UX environment, as a UNIX one, produces SysV COFF object files, while
for instance MPW has it's own object file format for inter-language linking.
 
> 1) Is there a way to translate COFF into CODE resources?  If there isn't, is
> there any real reason why I couldn't write such a beast?

I think that code conforming to ARM in the case of C++ is a better way for
transporting software from one environment to another. You still have to take
into consideration issues with operating system support, like how to for instance
support fork/exec:s under MacOS (hint, latest d e v e l o p article had a good
article about threads under MacOS).
 
> 2) Even if I could translate COFF to a MacOS-style AppleDouble or AppleSingle,
> is it really worth it anyway?  If I can use libg++, yacc, lex, etc., it might
> be.  But will the linked images be usable under MacOS anyway?  Can I simply
> redefine malloc etc., or is the problem much more pervasive?  I can of course
> conditionalize the few calls which might require the Mactoolbox glue routines -
> but I don't expect to have many modules which actually require the code to be
> different between A/UX and the MacOS.

Many of the standard C library routines, such as malloc, lseek and such are supported
as libraries under MPW and Think C. The question in many cases, like both mentioned
earlier, is about performance and how well this works under MacOS. As a good example:
malloc is using NewPtr, a non-relocatable block of memory is reserved for the buffer.
Now non-relocatable blocks of memory are not very efficient in small memory space systems
(Classic, Mac Plus and such), so a rewrite using relocatable blocks (handles) is a better
solution in the long term. Same with lseek, this is a basic routine, which does not take
into consideration any of the special functions of the MacOS file system, which other
trap calls do.

> Any ideas?  Just give up and buy Zortech C++ (if it is available and is at least
> 2.0 conformant, although I prefer 2.1).

A new MPW C++ with AT&T 2.1 support is on the pipeline.

Regards,
Kent Sandvik