ctm@unmvax.cs.unm.edu (Clifford T. Matthews) (09/04/90)
Note: Abacus Research and Development (ARDI), is in no way affiliated with the
====> University of New Mexico. Abacus Research and Development has had
====> a UUCP link to the University and since that link still down,
====> this note is being posted from unmvax, rather than iclone.
====> Please do not electronically reply to the sender of this message,
====> as it is a courtesy account and responses will not be forwarded to ARDI.
This post announces the official release of ROMlib-V1.0(tm) for Sun3
machines. A description of the beta release of ROMlib was posted in February.
Executor(tm) is not yet a product, but a pre-alpha copy is currently being
shipped with each copy of ROMlib sold. It is being included because it is
useful for debugging, it is amusing and it shows where ARDI is headed in no
uncertain terms.
[two major differences from the information posted when we were looking for
beta sites: the device management code won't be seen in this release and
the memory manager is no longer built on top of malloc (in fact, malloc is
now built on top of it]
This post has 5 parts:
Description of ROMlib and Executor
Technical issues
Limitations
Answers to commonly asked questions
Ordering information
1. Description of ROMlib and Executor
ROMlib is a set of C library routines with the same syntax and semantics as
the routines available on Apple Computer Inc.'s Macintosh(tm) Plus computer.
ROMlib-V1.0 provides all the routines documented in "Inside Macintosh"
Volumes I-IV with a few exceptions noted below. Although the first release
of ROMlib-V1.0 is for SUN3s running X11, there is little dependence on X11,
and experimental versions exist that write directly to Sun "bwtwo"s and IBM
PC "VGA"s. The source to ROMlib can be configured to run on DEC Vaxen,
Decstations, Sun4s, DG Aviion, Dupont MacBlitzen and IBM RT, but we don't
have the facilities to support releases on those machines today. ROMlib is
known as a "source compatibility product."
Executor is a program that has been compiled with a special copy of ROMlib
(it uses different stack frames for some routines and ints are 16 bit).
Executor runs binaries that have traditionally been run on the Macintosh.
It is not a product because there are many things that will make it crash.
I don't know of a single "big ticket" application that runs in entirety under
Executor and some don't even print anything on the screen before they crash.
The reason for most of the crashes are uses of low-memory globals that we don't
understand (we have not disassembled any Macintosh object code, so undocumented
memory locations are a real pain), the use of routines we haven't put in ROMlib
yet (Hierarchical menus, Color) or device level programming (although writes
directly to "screen memory" ARE supported). Executor requires kernel
modifications, which we supply in source form, to quickly dispatch A-line
traps, remap the page 0 memory references, and support the reading and writing
of the Status Register which is normally a restricted operation (we still
disallow altering the interrupt priority). Executor is a "binary compatibility
project."
ROMlib and Executor do exactly what you tell it. There is no attempt to make
your application look any different than it would on a Macintosh.
2. Technical Description
When a program compiled with ROMlib runs, a one bit deep offscreen bitmap is
allocated with sufficient space for a virtual screen (the default is 512x342
but can be altered with Xdefaults geometry). All drawing is done into this
offscreen bitmap and then the portions of the bitmap that have been changed are
sent via XPutImage to the real screen. Note the reliance on X is minimal. The
first verions of ROMlib wrote directly to the screen, and should someone need
a port to a machine with a different (or no) windowing system, it should be
no trouble as long as there is a way of pushing one bit deep rectangles around.
All the windows that are created by a single application are displayed on the
virtual screen that is automatically created when the application starts.
All internal data structures that are documented in Inside Macintosh are used
as described therein. ROMlib-V1.0 reads both V1 and V2 pictures, but writes
only V2 pictures. Although none of the calls documented in Inside Macintosh
Volume V are supported, ROMlib will cheerfully ignore color op codes and the
data that follows them in V2 pictures.
Although for compatibility we support the same internal format of a "region"
as on the Macintosh, we convert it to a nicer intermediate form internally.
We do not use the algorithms described in United States Patent #4,622,545.
Our clipping is performed without the use of a scan line mask as described
on column 10 of that same patent. Although I know of no documentation
concerning the algorithm Apple uses for SeedFill, we clearly use a different
algorithm since they fill horizontally first, where we fill vertically (using
table lookup with a base three encoding to compress the table from 64k to 7k).
Given some free time, someone here will write a paper describing the techniques
used in detail; of course we wouldn't think of patenting such pieces of applied
mathematics.
The filesystem is a straightforward mapping of Macintosh 2-forked files unto
two UNIX files. Resource forks are stored as separate files within the
subdirectory ".Rsrc" that exists in the directory that the data-fork exists
in. In order to map back and forth between directory names and directory
id numbers, ndbm is used to keep a database of all subdirectories of a given
ROMlib "volume." The volume can be rooted anywhere on the UNIX filesystem,
but only ROMlib programs should move or delete directories unless you wish to
rebuild the mapping information after any changes. A program is provided
to do just that. The resource fork files have 512 bytes prepended to them in
anticipation of eventual TOPS compatibility. However the top-most bytes in
the 512 area are actually used to store information and may conflict with
TOPS (it hasn't been tested yet). Very few of the low-level data structures
are compatible, since UNIX is responsible for doing the actual file
manipulation. Setting EOF is allowed, but don't expect the relation between
logical EOF and physical EOF that is documented in Inside Macintosh to hold
true, files never shrink under ROMlib.
3. Limitations of ROMlib (Executor doesn't have as many limitations)
No Printing Manager, Desk Manager, Device Manager, Disk Driver, Sound Driver,
Serial Driver, AppleTalk, Disk Initialization or SCSI Manager. No routines
introduced past Volume IV (notably no Color, hierarchical menus).
Currently the standard xDEF code resources are not read out of the System File
by GetResource. This is because there is no trap facility so the
dynamic linking required would be a mess. It is possible to overwrite the
standard definition procs by changing an array that contains the pointers to
the appropriate functions. The level of compatibility is sufficient that
resource forks created on Macs are readable under ROMlib and vice versa.
Unfortunately, not all UNIX machines are big endian, so a utility is
provided to do byte swapping for you, should you be on a little endian
machine (not necessary on SUN3). The byte swapping program doesn't know how
to byte swap pictures, but ROMlib detects byte swapped pictures and handles
them properly.
SetCursor doesn't allow cursors to invert bits under them because it is not
easy to do under X.
You must be 32 bit clean.
The System Error facility is there but the DSAT resource is in an incompatible
form (since we don't read code from resource files).
The vertical retrace manager and time manager are supported, however the timing
is approximate and not tied to the refresh of the screen. In addition it is a
bit costly to have the kernel signaling your process every 60 seconds, so it is
possible to turn the vertical retrace interrupt off (the clock will continue to
tick).
N?[GS]etTrapAddress are not supported by ROMlib (Executor handles them
properly). SysBeep calls XBell. Environs pretends that ROMlib is a macMachine
with version 0x75 of the ROM. Restart kills the current process.
Segment loader Parameters can be passed in on the command line. ROMlib's
segment loader attempts to locate files named as parameters. UnloadSeg doesn't
do anything, but on a virtual memory system that only means that swap space
will continue to be used as the unloaded set gets paged out.
4. Commonly asked questions
Q: Don't you expect to be sued by Apple?
A: As ludicrous as it might be to be sued as infringing on ``look and feel''
by a company whose CEO made it big running Pepsi, the answer is still yes.
Apple has shown a strong tendency to bully potential competitors. ARDI
intends to provide the ROMs for Macintosh "clones." Should a lawsuit be
filed, Apple will in essence be saying that the look and feel of all the
applications that have been released on the Macintosh belong to Apple,
not the author's of the programs. Even if ``look and feel'' suits do hold
up over time it is unlikely that the courts will transfer the ownership of
an application's look and feel from the application's author to Apple.
Q: Why don't you support [Color, Desk Accessories, ...]?
A: All good things in all good time.
Q: Any plans for executor on non 68000 based machines?
A: You bet. Emulated cpu technology is a viable option on the fast machines
that are becoming available due to the competition in the UNIX market.
Remember, all the time spent in traps will be executing native code so
things should scream.
Q: How dependent is ROMlib on UNIX?
A: Currently we require the UNIX filesystem, but we will write a complete
implementation of HFS that can read and write disks initialized by a
Macintosh.
Q: Are you using inferior algorithms in order to avoid patent infringement?
A: No. Our algorithms are in my opinion better, although we currently don't
blit as fast as the Macintosh, due to the blitter still being in C.
Q: What do the big players think of ROMlib?
A: There's quite a bit of interest out there. The threat of lawsuit is more
intimidating to a large company than to ARDI. If it's going to happen,
let's get it over with.
Q: How big is ARDI?
A: Four Programmers, One Lawyer, an Accountant and a Secretary.
Q: Are you hiring?
A: Not today.
Q: I'd like a demonstration, how do I get one?
A: When we were in beta the non-disclosure agreement was pretty stifling;
now however if you can find someone on a net that you're connected to
that has ROMlib and is willing to give you a demonstration, their license
permits them to do that (the license agreement listed in the next section).
xhost their machine onto your machine, set the DISPLAY environment variable
and go for it. If you plan to be in Albuquerque give us a call. If you
plan to be in Stockholm on October 13th let me know :-).
Q: What are the kernel mods?
A: One new system call is added, one new bit in the proc flags is allocated.
The syscall turns on and off 'fast aline dispatching' and 'page 0 mapping'.
The bit is used to determine whether a given process is needs these
features. BusErrors, A-line traps and illegal instructions are trapped
and examined before the kernel sees them. If the currently executing
process has the new bit turned on in the proc flags field and certain
conditions are met then our code handles the exception and the kernel
is never the wiser. This is all relatively trivial since none of the
three things mentioned above are asynchronous events. NOTE: ROMlib
doesn't need any kernel mods, only Executor.
Q: How hard is it to install the kernel mods?
A: We try to make it as easy as possible, providing a set of mods for SunOS3.5
and SunOS4.1 with the idea that if you have anything else you can compare
the two and figure out how to fit things to your system. You do not need
the source to the kernel (we don't have it either) to make the mods. We
give you the source to the mods, it's you kernel; you deserve to know what
we're doing to it.
Q: How similar are the screens produced with ROMlib to those on a Macintosh
A: They will look as similar as we can possibly make them. Currently we
differ wherever approximations are necessary (scan converting lines,
ovals, scaling bitmaps) because we haven't taken the time to figure out
mathematical equivalent for what Apple is doing. We have disassembled
no Apple code, so getting exact pixel matches in the above cases will
take some work. We were able to reverse engineer Random() (Thanks Bill)
by looking at the numbers it produced so we should be able to do the
others. Non-scaled bitmaps should be bit per bit the same.
Q: Why do your ovals have breaks in them?
A: I've heard several explanations of why Apple's ovals have breaks in them
but we didn't initially set out to duplicate this "feature." However
one day I realized that it was faster to scan convert an oval twice, once
for outer diameter and the second time for inner diameter than it is to
do one scan convert and one inset region. However when you do it the fast
way you get holes in your ovals. So we're compatible there as well.
Q: What's in the release?
A: ROMlib, Executor, man pages, kernel mods, auxiliary programs, and test
programs that provide examples of how to compile/link your programs.
Q: How slick's the packaging?
A: This release? Not very. This is our first release. Remember when DEC
documentation was intentionally funny? When Bill Gates lived in
Albuquerque? the Apple I?
5. Ordering info
The fee per CPU is $400.00. The license agreement printed below will have to
be filled out, signed and accompanied by a check for $400.00 (+ tax if
ordering from within New Mexico) before we will ship ROMlib and Executor.
The license PROHIBITS the transfer of executables and libraries built with
ROMlib to non-licensed CPUS; as such YOU MAY NOT BUILD PROGRAMS AND SELL
THEM OR GIVE THEM AWAY with this license. We will have a separate license
agreement and fee structure that will allow the distribution of derived works.
When we support more machines we offer an educational network license for
Colleges and Universities.
***** Cut Here ********* License Agreement ************ Cut Here *****
ROMlib TM and Executor Non-Exclusive Non-Transferable
Single CPU Object Code License
This agreement is entered this ___ day of _______________, 1990 by and
between Abacus Research & Development, Inc., a corporation organized
under the laws of Delaware with principal offices at 1650 University
Boulevard, Albuquerque, New Mexico 87102 United States (hereinafter
"ARDI"), and ____________________, organized under the laws of
_______________ having its principal offices at ________________
(hereinafter "Licensee").
License Description
ROMlib TM and Executor TM were written and copyrighted by Abacus Research
and Development, Inc. (ARDI). They are not sold but are provided under
Software License Agreements. The license granted by this agreement is
non-transferable. This license allows Licensee, the use of each ROMlib and
Executor software package licensed hereunder on one machine only. None of
the object code that is being licensed may be transferred to or executed by
a machine not covered by a valid license. Licensee may make copies for
backup purposes only. All copies must retain ARDI's copyright notices.
THIS LICENSE DOES NOT ALLOW ANY SOFTWARE (INCLUDING, BUT NOT LIMITED
TO, EXECUTABLES OR LIBRARIES) THAT INCORPORATES ANY OF ROMLIB OR
EXECUTOR TO BE DISTRIBUTED TO OR EXECUTED ON ANY MACHINE EXCEPT
THOSE SPECIFICALLY COVERED BY VALID LICENSES FROM ARDI. IF YOU HAVE
SOFTWARE THAT YOU WOULD LIKE TO DISTRIBUTE THAT REQUIRES THE USE OF
ROMLIB OR EXECUTOR, YOU NEED A DIFFERENT LICENSE.
Sun Microsystems is a registered trademark of Sun Microsystems, Inc.
Sun-3 and SUNOS are trademarks of Sun Microsystems, Inc.
ROMlib and Executor are trademarks of Abacus Research and Development,
Inc.
Limited 90 Day Warranty on ROMlib
This version of ROMlib has been tested on Sun Microsystems Sun-3 series,
running SUNOS from SUNOS3.5 and up, using the X11R3 and X11R4 protocol.
Should Licensee, during the first 90 days after receipt of ROMlib, when
running on a system described above, encounter an error or inconsistency
that prevents ROMlib from functioning as documented, ARDI will supply one
of three solutions upon receipt of written documentation of the error or
inconsistency. The three solutions are an update to ROMlib that fixes the
error, an alternate way to use ROMlib to achieve the same results, or a
change in the documentation. If the solution supplied by ARDI is not
sufficient to allow Licensee to continue to use ROMlib, Licensee may return
all copies of the software and documentation, and ARDI will refund the
license fee paid and this license agreement will be terminated.
Executor sold "AS IS"
Executor is not a finished product. Its inclusion as part of this distribution
is for advertising, amusement and debugging purposes only. EXECUTOR IS
SOLD "AS IS;" ARDI MAKES NO WARRANTY WITH RESPECT TO ITS USABILITY,
QUALITY, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.
Exclusions, Limitations
ROMLIB'S LIMITED 90-DAY WARRANTY, DESCRIBED ABOVE, IS THE SOLE
WARRANTY PROVIDED BY ARDI TO Licensee. ALL OTHER WARRANTIES,
INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY AND
SPECIFICALLY DISCLAIMED.
LICENSEE'S REMEDY IN THE EVENT OF NEGLIGENCE OR CONTRACTUAL BREACH
BY ARDI IN CONNECTION WITH THE CREATION, MANUFACTURE, MARKETING,
DISTRIBUTION OR LICENSING OF ROMLIB OR EXECUTOR IS STRICTLY LIMITED
TO THE LICENSE FEE PAID BY LICENSEE. IN NO EVENT WILL ARDI BE LIABLE
FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
RESULTING FROM THE USE OF ROMLIB OR EXECUTOR, even if advised of the
possibility of such damages.
If Licensee uses the licensed software in a state which does not allow the
the exclusion or limitation of implied warranties or limitation of
liabilities for incidental or consequential damages, then the limitations on
warranties and exclusions of damages agreed upon by the parties to this
license agreement shall be interpreted, to the extent permitted by the
applicable state's law, to fulfill the agreement of the parties set forth
herein.
General Terms
This license is the entire agreement between Licensee and ARDI. If any
provision of this License shall be held to be unenforceable such holding
shall not affect the enforceability of the remaining provisions. This
license shall be governed by and construed under the laws of the state of
New Mexico. Licensee agrees to bring any proceeding concerning this
license before a court of the State of New Mexico or a Federal court located
in the State of New Mexico.
ARDI
______________________________________________ Signature/Date
Clifford T. Matthews__________________________ Printed Name
President_____________________________________ Title
Abacus Research & Development, Inc.___________ Organization
Licensee
______________________________________________ Signature/Date
______________________________________________ Printed Name
______________________________________________ Title
______________________________________________ Organization
***** Cut Here ********* License Agreement ************ Cut Here *****
Thanks for the encouragement We've received so far
Clifford T. Matthews
Abacus Research and Development Phone: (505) 766-9115
1650 University Blvd. Fax: (505) 247-1899
Albuquerque, NM 87102
Please do not electronically reply to the sender of this message,
as it is a courtesy account and responses will not be forwarded to ARDI.
__________________
Macintosh is a trademark of Apple Computer Inc.
ROMlib is a trademark of Abacus Research and Development, Inc.
UNIX is a trademark of AT&T Information Systems