leipold@eplrx7.uucp (Walt Leipold) (09/12/90)
[Herewith, a short, fairly incoherent review of a new Mac product...]
ROMlib(tm) is a Unix library that simulates the Macintosh ROMs, allowing
Macintosh source code to be compiled and run *unchanged* on a Unix
platform. The Unix version of a Macintosh program retains complete
Macintosh 'look and feel', interacting with the user via X Windows on
any X server on a network (even Mac X, if you like to see a Mac
pretending to be a Mac). However, by running your application on Unix
you gain the advantages of protected virtual memory, the Unix file
system, Unix development tools (e.g., make and SCCS), true multitasking,
and all the speed of whatever Unix platform you are using. The current
version of ROMlib includes only those routines documented in Inside
Macintosh volumes 1 through 4 (e.g., the Mac SE); I believe that ARDI is
working on compatibility with Color QuickDraw and the rest of Inside Mac
volume 5.
ROMlib was developed by Abacus Research & Development Incorporated
(ARDI) of Albequerque, NM, and has just been released as a commercial
product. A recent posting on comp.sys.mac.announce contains an in-depth
description and ordering information. The initial commercial release of
ROMlib is for Sun 3 workstations, and costs $400 per copy. ROMlib has
been run on many other computers, and versions will probably be released
as the demand warrants (but don't quote me on that!).
I have been beta testing ROMlib on Sun 3/60 and 3/260 workstations since
early April, and on a duPont MacBLITZ since early June. The three
guinea pig applications I've ported are a simple maze generator, a grid
generator for a finite difference thermal analysis program, and a rather
nifty units conversion program. Running on Unix, these programs are
practically indistinguishable from their Macintosh counterparts.
Since ROMlib performs all its graphics via X Windows, screen updates are
performed at network bit rates. For a normally-loaded Ethernet, this
translates into a screen repainting rate about the same as that of the
Macintosh Plus. Thus, while its graphics performance is acceptable,
ROMlib is not the tool of choice for porting an animation program.
However, if your Mac application is compute-bound, you can simply
recompile the source code on your favorite Unix box for a significant
speedup.
The programs I ported using ROMlib were written in various versions of
Think C. One, written in version 1 of Lightspeed C, needed extensive
revision before I could get it to compile with the current (rel 4) Think
C, but once I got it to compile on the Mac it compiled under ROMlib with
only two minor changes in printf format strings. The most difficult
part of the porting process was getting the supplied ROMlib makefile
working on my system; ARDI's development was done with Gnu make and gcc,
so I had to make some changes to get the bloody thing working with Sun's
standard tools. But even this took only a few hours; the total time for
the most difficult port of a Mac application was about eight hours.
Remember that with ROMlib you are compiling your Mac code with your Unix
compiler, which will probably have subtly different behavior than the
Macintosh compiler you're used to. For example, you must be careful
about the default size of an integer. Your Mac code should always
qualify ints with either 'short' or 'long'. (This is good practice
anyway, given the differences between the Think and MPW C compilers.) If
your Mac program uses stdio calls, you should similarly use the %hd and
%ld printf/scanf formats instead of just %d. If your Unix system has
only a K&R C compiler, you'll have to take out all those nice
ANSIfications you put in your Macintosh code.
The Unix file system doesn't know about resource forks, file types and
creators, or any of the other neat info that the Mac keeps squirreled
away about every file. ROMlib maintains the resource forks of its
'Macintosh' files in a separate '.Rsrc' directory, a la Tops, with
directory information kept as an ndbm database. You only have to make
a Unix directory into a virtual Mac volume once, after which the
ROMlib-simulated File Manager calls keep everything up to date. The
Standard File routines work normally within each virtual Macintosh
volume, except that you cannot type to select a file in the SF{Get,Put}
routines.
To create the resources used by your Mac application, you run ResEdit or
Rez on your Macintosh, then move the resource file over to your Unix
system. ROMlib's Resource Manager routines work exactly like the Mac's.
Of course, with a ROMlib-based application you don't have the Macintosh
Finder or MultiFinder. However, your Unix platform is performing true
(not cooperative) multitasking, so you can have multiple ROMlib-based
applications running simultaneously, each of which thinks it is running
on a dedicated virtual Macintosh. It's quite a sight to see three or
four Macintosh 'screens' on a single SuperMac monitor! The only
drawback to this style of multitasking is that there's no global
clipboard, so you can't cut and paste between applications (yet).
The bottom line: ROMlib is a nice product, and appears to be a bargain at
$400/copy. If you have a Sun 3, you can develop and run Mac software on
it today. If you have some other flavor of Unix platform, I recommend
that you call ARDI and tell them you're interested in a version for your
system -- they might just be able to supply you with one.
If you want more details, I'd be glad to supply them...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
DISCLAIMER: This review in no way constitutes an endorsement of ROMlib
or Abacus Research & Development Incorporated (ARDI) by E.I.duPont de
Nemours & Co., Inc.
CLAIMER: I have no financial interest in Abacus Research & Development
Incorporated (ARDI) nor, as far as I know, does duPont. However, I have
been a beta tester for ARDI's ROMlib product, and they have reciprocated
by beta testing one of duPont's new products (the MacBLITZ, a Unix
workstation on a NuBus card).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
------------------------------------------------------------------------
"It is better to have loved and lost, Walt Leipold
than never to have lost at all." (leipolw%esvax@dupont.com)
------------------------------------------------------------------------
--
The UUCP Mailer