Xref: utzoo comp.sys.apple:23739 comp.sys.mac:50889 comp.sys.apple2:249
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!ssbell!mcmi!unocss!dent
From: dent@unocss.unomaha.edu (dent)
Newsgroups: comp.sys.apple,comp.sys.mac,comp.sys.apple2
Subject: Re: Accepting the Mac (was Re: More Macweek Rumors)
Message-ID: <2595@unocss.unomaha.edu>
Date: 18 Mar 90 10:49:57 GMT
References: <1848@crash.cts.com> <18491@boulder.Colorado.EDU> <12667@thorin.cs.unc.edu> <1990Mar17.105403.17776@spectre.ccsf.caltech.edu>
Organization: U. of Nebraska at Omaha
Lines: 116


I've been an Apple fan ever since the ][+ (which is still running fine, thank
you, with the expansion chasis, Rana drives, etc etc etc etc... :-), and I'm
a Mac-lover now.  So, all of this discussion got me thinking (look out).

The Apple // -vs- Mac debate (war?) has been going on for a very long time,
and it seems that by doing next-to-nothing to "finalize" the outcome of that
battle, Apple may have stumbled across the solution to it all.  Let me
elaborate:

The appeal of the Mac, (at least back in 1984, when Apple had DAMN GREAT ads..
[anyone got 1984 on VHS, btw?] :-) is not (at first), the hardware, but the
user interface.  In fact, the Macintosh User Interface has had such a huge
impact on the entire industry (by virtue of actually being sucsessful
at it), that nearly all of the functionality of it has been copied to other,
sometimes radically different, archtechtures.  If you have been asleep for
the last 7 years, some examples would be: GEM for the PC, "TOS" (i.e., GEM
for the Atari ST), Amiga "Intuition", MicroSoft Windows (how could we
forget, right?), and more recently, NeXT STeP, IBM's SAA (The Sleeping Giant
moved!), and the rash of Interfaces that "The X Window System" brought on :
DECwindows, Motif, Open Look, and on and on....

Case 1:

A little closer to home, witness the Apple IIgs.  "Coincidentally", it has
also adopted a Mac-style user interface (but without fear of litigation :-).
The IIgs is not going anywhere, folks.  Apple would probably not have released
System 5.0 for it if they weren't expecting it to last a little while longer.
So given that the IIgs will be around for a while (the fate of the //e and
//c is less certain, however.. ), let's press on.

Case 2:

System 7.0 for the Mac can just barely be seen on the horizon now, and some
of the major developments for it weren't entirely for the Mac.  Apple and
Microsoft (kind of a love-hate relationship there :-) have joined Presentation
Manager running on OS/2 with the Mac, by using a consistant font format:
TrueType.  In exchange, Microsoft provided the means to more inexpensively
keep compatiblilty with the good old PostScript LaserWriters (as well as non-
Apple printers) in the world.  So, another part of the Mac Interface has
expanded beyond the confines of a single architecture.

Case 3:

AU/X 2.0 is on the horizon as well, and with it, MacX.  This is perhaps one
of the most exciting developments of all, IMHO.  From the rumors, MacX allows
X Windows applcations to display on the Mac, which is what you would expect.
What it additionally does is provide those X Windows applications with the
"Mac Look".  The implications of this are that the industry without a
standard interface may get one, if MacX can be expanded to "MacWM" (for lack
of a better name).  If this is done, the Mac Interface could be used on
even more dissimilar architectures.

Case 4:

The 68xxx series Mac is not going to last forever, and it's no secret that
Apple has been playing with the idea of an 88000-based machine.  This new
machine does not, however, mean that the users of the old machine will be
abandoned.  The Mac /Interface/ can run on /any/ architecture.  Sure, 
assembly language programmers will be a little upset :-), but C and Pascal
programmers should be able to just link with a new library, tweak a little,
and go.  [Yes, this is oversimplifying the case dramatically, I realize.]

Ok, let's wrap it up:

The entire point of this rambling article is that the "Macintosh" is really
more than simply the hardware by the same name that does the work.  (Kind
of like "AppleTalk", huh?)  Steve Jobs was correct in a sense when he talked
of the impending doom of the Mac.  Sure, the 68000-based Mac is eventually
going to be ancient technology (how many new 6502-based machines do you see
today? :-)  But the essence (look&feel if you like) of the Macintosh will
outlive it's 68000-based "body" (I can't beleive I'm talking about Meta-
Physical Macintoshes here.. :-)

Similarly, certain Apple II machines will probably die.  The //e and //c lines
really should be replaced with something similar to what the //gs is now (but
for considerably less I hope!!).  The //gs will also be replaced, but not by 
a "Low Cost Mac" in the Hardware sense.  An "enhanced" //gs that runs the
Mac-like Interface is really enough.  There's no need for over-engineered 
Apple-II compatibility boards in every Mac.  There /is/ a need for the Mac
functionality on the Apple II architecture, so the two lines can merge in
that sense.

There is only one way that this all is going to work, however:  The Macintosh
Toolbox has got to be freed from the Macintosh Hardware.  I have no idea
how similar the GS Toolbox is to the Mac Toolbox, but I hope they are nearly
identical.  Only by making the Macintosh Toolbox the standard programmers'
interface to hardware, can the same source code be used to generate machine
code for various kinds of architectures.  Programmers shouldn't really need
to know what specific machine their program is going to run on.  (well,
the ones writing the toolboxes obviously should, but.. :-)

This is *NOT* going to happen overnight, however. :-)  The current state of
programming on the Mac seems to be filled with minor inconsistencies that
require the /programmer/ to correct for.  Is this machine an SE?  Do this...
is it a Mac II?  HasColorQD is TRUE.. but then it could be an SE/30 too, so
better check for that...  This is pure nonsense.  The toolbox already is
designed to be generalized.  You can have any size display you want on a Mac;
it makes no difference to your applications.  This same generality needs to
be perfected, and expanded to the other areas... what we'll wind up with
is the "Macintosh Virtual Machine", and if /only/ toolbox calls are used to
access hardware, and dynamic linking could be used to link in the machine-
specific implementations of the toolbox, the same applications /will/ run
on different architctures, and not even know it.

The preliminary steps have been made; file transfer has almost become trivial,
and hopefully future support for Foreign File Systems will make it moreso.
I know I'm asking for a lot here, but I don't think I'm asking for the
/impossible/.  I suppose we'll have to wait around to see if /any/ of this
occurrs (what a let-down ;-)... but it should be fun to watch if nothing
else.  (It'd be even more fun to participate in, but what do I know.  I /liked/
the Apple ///+. :-)

-/ Dave Caplinger /---------------------------------------------------------
 Microcomputer Specialist,   Campus Computing,   Univ. of Nebraska at Omaha
 dent@zeus.unomaha.edu         ...!uunet!unocss!dent            DENT@UNOMA1