Xref: utzoo comp.sys.mac:49872 comp.sys.mac.programmer:12892
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!okstate!minich
From: minich@a.cs.okstate.edu (MINICH ROBERT JOHN)
Newsgroups: comp.sys.mac,comp.sys.mac.programmer
Subject: Re: mac emulation
Message-ID: <5433@okstate.UUCP>
Date: 5 Mar 90 02:58:48 GMT
References: <1990Mar3.190730.15647@mintaka.lcs.mit.edu>
Distribution: usa
Organization: Oklahoma State Univ., Stillwater
Lines: 80

From article <1990Mar3.190730.15647@mintaka.lcs.mit.edu>, by dbplass@abp.lcs.mit.edu (David Plass):
> Whoa!  I just read a posting of a news release on comp.newprod that
> announced a product for X/Unix computers that allow them to emulate
                                                              ^^^^^^^
> a Macintosh in software.  They did this by implementing the Toolbox ROMs in
> software, and have included just about every Toolbox trap as documented in IM.
> 
> BTW, the news release claimed 2-3x better performance on a Sun 3/60 than a 
> MacPlus. Could this be the beginning of a mac clone market?
> 
> -- David Plass

  Your missing some of the message of this product. The package does NOT
"emulate" the Mac's ROMs. It provides a library you can use to implement
routines with the same names/calling conventions as those documented by
Apple. When you read Inside Mac, you are given lots of documentation describing
what the routines do. Noone said you can't write your own source code for
these routines (of course, you'd also risk compatability problems!) for your
programs. What this new product does is provide the Mac's programming interface
on X-Windows systems. That way, when you port to another computer system, you
only (hopefully) have to recompile the program. This is very different from
an emulator, which works with binary/machine language data. 

> 
> The problem I have with this is: if Abacus (the company who announced the 
> product) can "copy" the Mac Toolkit in this way, why aren't there any Mac 
> "clones?"
> Did Apple give premission to Abacus to copy the Toolbox ROMs? 
  
  Apple did not give premission to Abacus to copy the Toolbox ROM's. Moreover,
Abacus didn't copy the Mac's *ROMs*. They implemented a karge subset of the
Mac's toolbox routines.
  There aren't any Mac clones because this technique is NOT complete in its
support of the Mac's routines. Also, just having the routines is NOT enough
to make a clone. To do a clone, you have to make the hardware/machine language
portions of the operating system work effectively the same exact way as the
hardware your cloning. This is very very dificult, as not everything in the
Mac's ROMs are documented, much less easy to program. (After all, Apple does
pour a lot of money into developing these things in the first place. The only
advantage you have as cloner is that you don't have to decide the functionality
that goes in. You still have to write all the code, though.) 
  About the speed increase on a ported program: That's not too surprising. In
fact, if Apple could rewrite alot of the ROM code today, we could probably
eek out a decent performance increase, but some braindead programs that depend
on subtle quirks/undocumented parts of the ROMs woul likely die. (MiskeySoft
springs to mine imagination!) The perfomance wouldn't be orders of magnitude
better, but it could be a nice boost.

  Now, for the more interesting possibilites with this discussion: Apple could
conceiveably make a Mac with just about any CPU and rewrite all the routines
for the ROM. We could have an Intel based Mac (that's really an extreme, how
bout an 88000 Mac?. :-) Then, with new compilers, we could take most of the
existing source code and recompile it for the new hardware, since the toolbox
interface would be the same! (This is what the Sparcstation requires to port
software written for its CISC counterparts.) We could conceivably get a lot
more performance and EXACTLY the same interface. The notion of SOURCE code
compatability as opposed to BINARY compatability is a very interesting one.
This is part of what has made UNIX very succesful. You can take a fairly
complex program and recompile it on a completely different machine and get
the same results. IF Apple does release a RISC Mac anytime, I think we'd 
see some sort of scheme like this along with a 69K EMULATOR in software so
you could still run all the programs you have. (Although it would be much
much slower than a recompiled version.) The bigger question here is "Would
Apple trim off some of the fat of older routines that are kept around only
for compatability? (Probably.) 
  Geesh, now I've gotten long winded with this whole thing, and a bit excited,
too. **way down the road prediction** Apple will start making Macs of different
flavors, allowing you to pick a hardware platform with an architecture that
is wildly different while still being able to run the same programs. Imagine
a Mac based on an Intel (No flames, please. I realise there are major problems
with this. :-) that could run OS/2 (half an OS, that is) as well as the Mac
OS! 
===============================================================================
                             | tup - to copulate with a ewe
Robert Minich                |
Oklahoma State University    | Some people come up with the strangesr BS
minich@a.cs.okstate.edu      | when playing Scrabble! (That was really used
                             | in a game.) 
Take OSU's President, please!| Send me any other great Scrabble words you use.
===============================================================================