🚀 go-pugleaf

The information in this article is based on my direct experience with
the Mac II in my office running A/UX.  Apple has just issued a major
upgrade to beta sites, so I may discover improvements when we get our
disk back...  Note that this contains no marketing hype :-)...

In article <2599@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
>Specifically, my questions are these.
>
>(1) Will existing Macintosh application files run under A/UX, provided they
>adhere to the compatibility guidelines?

As Isaac Newton said, "Pretty Nearly."  This does bring a whole new
order of meaning to adhering to the guidelines, though.  Fullpaint,
for example, works with a couple patched bytes in the help window
handler (peeking at the upper bits in a handle is a no-no).  MacWrite
is hopeless (not suprisingly).  MacDraw 1.9 almost works, but gets a
little confused after a while.  I haven't tride 1.9.5 yet.  The A/UX
toolbox beta docs do give a list of things that you can't "get away
with" any more.  The biggest problem is that the memory manager is now
32-bit based instead of 24-bits-plus-flags based.

>(2) If not, will MPW C applications compile successfully under A/UX with
>only makefile changes provided they do no direct hardware accesses and
>otherwise conform to compatibility guidelines?

All the ones I've tried have worked fine.  You can also write programs
that use both Mac and Unix facilities (talk about unportable, though).

>(3) Will the full Macintosh file system, down to obscure but important
>details like the blessed folder, and most emphatically including volume ids,
>directory ids, resource forks and finder information, be supported by A/UX?

If you ignore the man behind the curtain.  It pretends that the entire
UNIX directory hierarchy is one big happy volume, and makes up
directory IDs on the fly.  This works surprisingly well.  Since this
is all user code, you could in principle write your own version of the
file manager routines that emulate whatever you want.  The resource
manager works fine, and the finder info is stored.  resource forks are
currently stored as "filename.res," but this may change, as I understand.

>(4) [Not of as general concern] Will A/UX come complete with Appletalk and
>Internet protocols and applications?  If so, which ones, and what kind of
>protocol support will be offered?  Will Unisoft's standard NFS be included?

It has complete Berkeley networking and NFS.  The docs describe the
AppleTalk stuff, but Unix has this problem with high-speed serial
I/O...  Raw sockets are now supported, and I intend to get our machine
talking to a Kinetics box and our Pyramid via the Ethernet board, to
allow printing to AppleTalk printers and the like.

>(5) Will Macintosh desk accessories and drivers still be supported?  Will
>they have to be recoded and/or recompiled even if they fit the compatibility
>guidelines?

They don't work now, but who knows?  DAs that don't "write to the
metal" might be possible.  The Vertical Retrace Manager is a major
problem, but there may be ways to fake it well enough for most DAs.
Drivers are probably right out, since they like to do physical I/O.

>(6) What is the relationship between A/UX and any possible multitasking Mac
>OS which Apple might release?  Is the environment significantly different
>from a Servant/MPW environment to the user?

I'm not sure what you are asking here, but it definitely feels like
(because it is) Unix with the ability to do Mac things.

>(7) What happens to the System Heap on a multitasking, memory-managed "A/UX
>Toolbox" environment?  Will Mac applications be prevented from corrupting
>each others' data the way UNIX applications are?

Mac applications are Unix tasks.  There is only 1 heap, and it's part
of the process's address space.  If the program dies, the worst it
will do is core dump, just like a normal Unix program.  This is
because Mac programs really are run as Unix processes, after having
some things set up by a "launch" program (which currently makes sure
the screen isn't in use, maps the ROMs and the screen into the virtual
address space, sets up the trap dispatcher, etc., and then starts up
the program).

>If these have already been dealt with here, then please respond by mail;
>otherwise, I would doubt that many people know the answers, but these
>questions (even the fourth) are clearly of general concern to Mac
>developers, so post.
>-- 
>Tim Maroney, {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
>hoptoad!tim@lll-crg (arpa)


-=-

Clayton Elwell

Arpa/CSNet:	Elwell@Ohio-State.ARPA
UUCP:		...!cbosgd!osu-eddie!elwell
Voice:		(614) 292-6546