As president and co-founder of Bear River Associates Inc., P.O. Box 1900, Berkeley, CA 94701 (a software engineering department for hire), Anthony Meadow has developed Macintosh applications since 1985. Anthony is an active member of the Software Entrepreneurs' Forum. He and David Richey cofounded Bear River Institute, which develops and presents technical courses about the Macintosh.
One of our earliest experiences with the Macintosh involved installing CP/M-68K from Digital Research. We walked through the tedious installation procedure, inserting all those 400K diskettes, to be rewarded ultimately with a text window and an A> prompt in an ugly font.
CP/M-68K did what it was supposed to do, but by the time we had it installed, we had all but forgotten why we had thought it would be a good idea to graft an alien and archaic operating system onto the Mac anyway.
Which is just the question some people are asking about A/UX, Apple's version of Unix for the Macintosh. A/UX wouldn't be as interesting if it only allowed you to turn off everything that makes a Mac a Mac so you could run mainframe Unix software. But as a veteran Mac programmer Tony Meadow explains in this article, how A/UX does a bit more than that. Under A/UX you can:
Oh, and Apple solved the installation problem, too, by making the distribution medium for A/UX an 80-Mbyte hard disk. --eds
Why did Apple Computer work so furiously on a version of Unix tweaked for the Mac? First of all, Apple Computer's customers have been pretty vocal about wanting a Unix that runs on some flavor of a Macintosh. Many of these voices echo in the hallowed halls of Academia, where Unix first began its slow but methodical move toward world domination, or from the somewhat less hallowed halls of the federal government, where the support for Unix or the lack thereof, can make a difference in the decision about who gets those "really big" contracts. If A/UX doesn't do anything else, at least it addresses the needs of this audience, because it is a real Unix running on a Macintosh.
(What many people don't know is that A/UX, Apple's long awaited version of the Unix operating system, isn't the first version of Unix to be sold by Apple. There was a Unix available for the Lisa, but neither the Lisa nor its Unix implementation caught fire.)
Second, A/UX isn't just another vanilla Unix. Apple has tried very hard to provide all the tools that most people want in Unix. Many of these tools (Documenter's Workbench, Adobe's Transcript, the Korn shell, and so on) aren't part of the standard Unix on most other machines, but Apple has been quite generous with this well-provisioned Unix.
Third, the system administration tasks make Unix a burden when systems are used by non-experts. The A/UX tools for automating a large chunk of this work, make the Mac II and A/UX an attractive delivery vehicle for companies that want to deliver Unix software to end users, as opposed to programmers and gurus. And finally, by providing access to much of the Macintosh OS and human interface code, it's possible to develop Unix applications (or modify existing ones) that use the well-designed and well-documented Macintosh human interface. This can significantly increase the potential marketplace for some products because the Mac interface is so easy to use.
A/UX will prove attractive to many different groups of people for a variety of reasons. A/UX is attractive to the community of developers who already use Unix. Apple has simplified the licensing procedures for A/UX by providing right-to-copy licenses for 10, 25, 50, 250, and 1000 copies. The first release of A/UX:
There are tools for developing other categories of applications: a standard Unix application, a Unix application with a Macintosh interface, or an application that behaves as a Unix application under A/UX and as a Mac application under the Mac OS.
First, you need a Mac II. Because A/UX supports demand-paged virtual memory, you need to replace the MMU chip in a Macintosh II with a Motorola 68851 with a Paged Memory Management Unit (PMMU). The user address space is 512 Mbyte and the kernel address space is 4 gigabytes.
You'll also need at least 4 Mbyte of RAM to develop software in A/UX, but you can get by with as little as 2 Mbyte for running applications (although more memory is always appreciated). A/UX itself is distributed on an 80-Mbyte disk drive with the documentation sold separately. (See Table 1, page 47, for configurations and prices.)
Prices for A/UX
Price Includes
Description Retail Mac II Monitor/Video Card 80Mb Disk (2) Memory (3)
----------------------------------------------------------------------------
Monochrome
Entry
System $8597.00 Y Monochrome Y 2MB
Color
Entry
System $9346.00 Y Color Y 2MB
Development
System $8399.00 Y N Y 4MB
External
Drive
Upgrade
Kit $4979.00 N N Y (External) 4MB
Internal
Drive
Upgrade
Kit $4879.00 N N Y 4MB
External
A/UX 80MB
Hard Disk $3282.00 N N Y (External) 0
Internal
A/UX 80MB
Hard Disk $3182.00 N N Y 0
A/UX Manual
Set (14
volumes)
(1) $649.00 N N N 0
Notes:
(1) Manuals must be purchased separately.
(2) The disk is an internal disk unless noted otherwise.
(3) If memory is included, then a 68851 PMMU is needed as well.
Derived from AT&T's System V, A/UX has passed the System V Validation Suite (SVVS) and adheres to the System V Interface Definition (SVID). File locking and record locking, both mandatory and advisory, are supported in accordance with the IEEE Posix standard. While A/UX was being developed from System V, Release 2.2, AT&T finished System V, Release 3, so Apple has a little catching up to do. Apple intends to release updates to A/UX at six-month intervals.
Components of BSD Unix were spliced into A/UX because Apple wants A/UX to attract the academic community, where Berkeley Software Distribution (BSD) Versions 4.2 and 4.3 are popular. A/UX includes the BSD 4.2 signal package as well as most of the 4.2 networking code. Many commands unique to BSD are also included. In some cases, their names have been changed to avoid conflicts with System V commands.
All three of the Unix shells are included: Bourne, C, and Korn. C and Fortran77 compilers are provided as part of standard Unix. make, awk, yacc, lex, lint, cb, and all the other standard development tools are there too. The Source Code Control System (SCCS) is also included.
Many tools are provided for those who work with words. Four editors are included: vi, ex, ed, and sed. The full Documenter's Workbench includes ditroff, troff, pic (for creating object-oriented illustrations), tbl (for creating tables), and eqn (for creating mathematical equations). Apple also licensed TranScript from Adobe Systems, so that the LaserWriter printer can be used from A/UX as a PostScript printer. But there is no way to print from a Macintosh application running under A/UX!
The TCP/IP protocol suite is supported over Ethernet. Sun's Networking File System (NFS) is also available, including Yellow Pages. AT&T's STREAMS is also there. The first release of A/UX does not include support for AppleTalk.
The 68881 FPU can be used for floating-point calculations. Apple's Standard Apple Numeric Environment (SANE), which adheres to the IEEE 754 Standard for Binary Floating-Point Arithmetic, is also available. SANE produces more accurate results than the 68881, but it is slower because all the work is done in software.
Autorecovery programs simplify the system administration process by handling such problems as bad disk blocks, filesystem inconsistencies, and missing (or damaged) system files. Some routine administrative tasks must still be performed to support autorecovery, but these are fairly simple. Autorecovery doesn't do everything, though. You will still need to back up and restore your own files because autorecovery only deals with critical system files. The list of files that it is concerned about is called the configuration master list.
Many other goodies are included with A/UX. In fact, you could recover a couple of megabytes by deleting things such as the complete source code for the Free Software Foundation's GnuEmacs. Kermit, the popular file transfer utility, is included, as are lots of standard Unix games (in binary form), such as adventure, fortune, trek, life, and twinkle.
Apple plans to release the source code for almost all of the drivers in A/UX (except those licensed from other companies) as part of a device driver kit.
The launch command is used to start a Macintosh application. You must pass it the name of the application that you want to start and, if desired, the name(s) of one or more document files for it to open.
In order to run any Macintosh application, the toolboxdaemon must be running in the background. This program, which is normally started by scripts run at boot time, manages the transfer from the A/UX world to the Macintosh world and back again. The daemon is necessary because the Macintosh application environment is normally managed by the Macintosh operating system and the Finder, neither of which are present under A/UX.
Two utilities help to transfer files between A/UX and Macintosh. The mfs utility transfers files from Macintosh MFS disks to your current working directory. This release of A/UX provides no support for HFS (Hierarchical File System, the more recent file system) floppies. The settc utility sets the creator and type of a Macintosh resource file. This is needed only if the file was transferred from a Macintosh through some means other than the mfs utility or if the file was created under the A/UX file system and not the A/UX Toolbox File Manager.
Several new A/UX programs are of interest to anyone who plans to use a Macintosh application or an A/UX application that calls the Macintosh ROMs. A/UX also includes the rez and derez programs, which are used to compile and decompile Macintosh resources. These programs were ported from MPW (Macintosh Programmers Workshop), the native development environment from Apple for Macintosh.
One of the pleasant surprises in A/UX is that it can run well-written Macintosh applications. A large percentage of Macintosh applications will run in A/UX, but only one at a time. This is because the Layer Manager, a new component of the Macintosh OS introduced by MultiFinder, hasn't been moved over to A/UX yet.
Since the Macintosh was released, Apple has consistently told programmers what programming techniques are good (and safe) to use. Anything explained in the five volumes of Inside Macintosh is usually safe and is pretty much guaranteed to apply from machine to machine. Apple has also consistently explained which techniques are not safe to use. It is particularly dangerous, for example, to use CPU specific features or instructions such as using the structure of the stack frames (which differ between the 68000 and 68020), fiddling with handles directly instead of using the appropriate system calls, and directly accessing hardware (such as the NCR 5380 SCSI or Zilog SCC chips). As it turns out, if an application was written avoiding these dangerous practices, there is a high probability that it can be run from A/UX.
One reason why properly written applications still might not run under A/UX is that not all the managers are supported under A/UX yet. In some cases, there are bugs in the Macintosh ROMs that have never appeared under the Macintosh OS. They have only appeared under A/UX because A/UX is a more demanding environment. For example, there is no hardware memory protection under the Mac OS, while A/UX uses the Motorola PMMU. Under the Mac OS, an application can directly address the Serial Communications Controller (SCC) chip, but it will be prevented from doing so by A/UX. Apple will try to make most, if not all, of the Macintosh managers available under A/UX, although it may take another release or two.
One way to develop applications that are properly written is to use MacApp. MacApp, the Expandable Macintosh Application, is an application toolkit written in Object Pascal. This language, developed by Apple Computer and Nikolaus Wirth, is a small superset of Pascal. MacApp provides all the behaviors of a standard Macintosh application. The programmer need only code those portions that are application-specific. MacApp has minimal penalties in space (10 percent) and execution time (10 percent) because the implementors of both Object Pascal and MacApp were careful in these areas. At this time, if you want to develop with MacApp, you must develop under the Macintosh operating system.
The Memory Manager under A/UX consists of code completely different from that used by the Macintosh OS. The A/UX Toolbox version uses the standard Unix system calls, malloc and free, to do the work of the Memory Manager. Its internal data structures are mostly different as well. A/UX master pointers are 8 bytes long rather than the 4 bytes, as in Mac OS. The flag bits, which were stored in the high-order byte of the master pointer under the Macintosh OS, are now stored in the second long word of the master pointer. You can still dereference a handle in the old way.
When a Macintosh application is launched, A/UX behaves as if there is 1 Mbyte of free memory. This is a compromise, because A/UX has virtual memory and the Macintosh Memory Manager was designed to manage a finite amount of physical memory. Also, A/UX has only a single heap zone--A/UX does not distinguish between the application and system heap zones.
Figure 1, page 50, which is a schematic view of the memory map of a Macintosh II, shows the traditional environment for Macintosh applications. Figure 2, page 50, a view of the virtual memory map of a Macintosh application running under A/UX, is obviously different. Any Macintosh application that makes assumptions about the order or location of various sections of memory is clearly out of luck when trying to run under A/UX.
The shared common data and code segments are managed by the toolboxdaemon, which runs in the background. The launch utility has to set up part of this world because it is replacing some functions of the Mac OS and the Finder.
Figure 3, page 51, shows a schematic view of the virtual memory for an A/UX program that uses the Toolbox. This environment, which does not apply to any Macintosh application, is even more different. Macintosh ROM Support A/UX supports almost all the user interface managers and many of the operating system managers. The largest number of unsupported managers is in the area of devices (SCSI Manager, AppleTalk Manager, Serial Driver, and so on). Table 2, page 52, lists all the managers supported in Release 1 of A/UX, as well as those that are supported by dummy routines and those that are not supported at all.
Supported Managers Dummy Routines Only (1) Unsupported Managers (2) ------------------------------------------------------------------------- Binary-Decimal Color Manager Apple Desktop Bus Conversion Package Control Manager Color Picker Package AppleTalk Manager Dialog Manager Desk Manager Deferred Task Manager Event Manager, Device Manager (some Printing Manager OS (partial) dummy routines) Event Manager, Disk Driver (some Script Manager Toolbox dummy routines) File Manager Disk Initialization SCSI Driver (partial) Package Font Manager Palette Manager Serial Driver International Sound Manager (some Slot Manager Utilities Package dummy routines) List Manager Startup Manager (not needed) Memory Manager Video Drivers (partial) Menu Manager Package Manager QuickDraw Resource Manager SANE Package Scrap Manager Segment Loader (partial) Shutdown Manager Standard File Package System Error Handler (partial) TextEdit Time Manager (partial) Utilities, OS (partial) Utilities, Toolbox Vertical Retrace Manager (partial) Window Manager
Notes:
(1) Dummy routines will return with no action. If there are only some dummy routines, then the others in that Manager are unimplemented.
(2) Making a system call to any of the unsupported managers will result in an 'unimplemented trap' message.
Dummy routines return with no error, but have no effect. Unsupported routines cause an unimplemented trap message, and the application is stopped in its tracks. As future releases of A/UX are developed, there will be support for more of the Macintosh managers.
Figure 4, page 53, illustrates how A/UX, the A/UX Toolbox and the Macintosh ROMs interact when a Macintosh system call is made. If a call is made to the operating system (rather than to the user interface), the call is handled by code in the A/UX Toolbox. This code performs the function by executing A/UX system calls to the standard A/UX libraries. The Macintosh OS code in ROM is not used at all.
If a call is made to the user interface code, then the A/UX Toolbox first translates the parameters into a form usable by the ROM code. It does this because the ROMs were written to expect parameters that look as if they came from Pascal, rather than C. This is a tricky area because parameters that are part of a structure (or record) are not translated. The Macintosh ROM routine is then called. This routine may call other user interface toolbox routines or Macintosh OS routines.
One area where there are some small, but tricky, differences between the two OS's is file management. There is a lot of support for Macintosh OS files under A/UX, but it isn't complete yet. A Macintosh file has two forks: data and resources. The data fork looks and behaves like any Unix file in that it is a finite sequence of bytes that can be randomly accessed. The resource fork, a concept unique to the Macintosh operating system, is normally accessed through a series of system calls.
Under A/UX, a Macintosh file can be stored in one of two formats. These formats were proposed by Apple and discussed by quite a few people over Usenet, the Unix community's primary electronic network. In the AppleSingle format, there is only one A/UX file for each Macintosh file. This file contains the contents of both forks of the Macintosh file as well as all other information about the file. The latter includes a file's black and white icon, color icon, Finder information, comment (as in Get Info), and other file information, such as attributes. In the AppleDouble format, the data fork is stored as one file, and the remainder of the information is stored as another file with a % (percent) prefixed to the name of the file containing the data fork. A/UX is capable of working with Macintosh files in either the AppleSingle or AppleDouble formats.
In the Macintosh OS world, each volume appears as a single-rooted tree. Under A/UX, all volumes appear somewhere in the file directory hierarchy, that is, the file system appears as a single-rooted tree. To Macintosh applications, all volumes appear as part of a single simulated volume whose name is / (slash). This volume cannot be mounted, unmounted, or taken on- or off-line.
Files are managed differently under the two operating systems. A/UX filenames are case-sensitive and limited to 14 characters. The Macintosh allows 64-character filenames that are not case-sensitive. Directory names are separated by / (a slash) under A/UX and by : (a colon) under the Macintosh OS. These differences will mainly affect hard-coded filenames.
Text files differ only slightly between the two operating systems. The newline character is a carriage return (0x0D) in the Macintosh operating system and a line feed (0x0A) under A/UX.
The Unix veterans that make up the A/UX team at Apple have delivered an applications development platform to programmers who want to tackle the academic, government, and commercial markets. Unix on the Macintosh will stimulate the Unix applications market because A/UX provides not just the Macintosh user interface but also a simplified system administration process.
While many aspects A/UX were well-implemented, there are still areas that could be improved. Here's a smattering of them: