Path: utzoo!attcan!uunet!bcstec!iftccu!bressler
From: bressler@iftccu.ca.boeing.com (Rick Bressler)
Newsgroups: comp.os.misc
Subject: Re: Re: terminology (Macintosh OS (was: 68000 and Workstations.))
Message-ID: <880003@iftccu.ca.boeing.com>
Date: 8 Jun 90 21:48:59 GMT
References: <6480@amelia.nas.nasa.gov>
Organization: Boeing Commercial Airplane Group
Lines: 194


[some stuff deleted]

>> I maintain that there is a price here.  The price is portability.  If
>> every computer in the world ran the MAC OS I'd agree with you.  I don't
>> think that this is likely to happen.  It seems that you are arguing for
>> standard API's and if that is the case, I couldn't agree with you more.
>
>A lot of the portability is being taken care of by the people who write and
>rewrite compilers... a well-written C program ought to run on most any
>machine (if the dialect of C is consistent across platforms).
>Once you have the base code laid out, it's just interface.... :)
>(Yes, I know that's a gross oversimplification, but I have seen some stuff
>that runs on *anything* with a good compiler...)
>

I don't want this to degenerate into a discussion of Apple vs World,
although I fear there may be some overtones of this.  I am using this as
an example only, there are many others.  The original thread related to
the dividing line between OS and application.  My intent here was to
provide one possible view.  In this particular case above, I think we
are talking about a *different* kind of portability.  I'm sure that code
written for the MAC will compile with *many* compilers.  (C should be
and slowly is becoming standardized :-).  Linking and executing is
another matter altogether, because so many of the functions called by
MAC applications are built into the OS (in ROM even) rather than in
*portable* libraries.

>
>>
>> I remember reading a review a while ago about a set of libraries
>> available for the PC that when linked with MAC applications written in
>> C, would run on a PC with virtually the same look and feel... the

[ some of my comments deleted ]

>
>You might be able to get it to *run*, but as far as looking like Mac apps,
>I wouldn't bet on it...
>
>
>Let's just say this must have been either a dream or deceptive advertising.
>The PC just doesn't have the right stuff built into it's ROMs to get away
>with this... you can see how improbable this is by looking at Windows 3.0,
>then comparing it to a Mac Plus... unless you have a *very* fast 286 or a nice
>386 with a lot of memory, it looks like a kludgy Mac on Valium... not to
>mention that you're still riding on top of MS-DOS.
>
>>

I don't know that there are any magical properties of Apple hardware.
It makes no difference if static code is loaded into RAM or ROM.  I'm
sure that if these libraries do indeed perform as advertised, they
emulate much of the MAC ROM.  If you will agree that code that jumps to
hard ROM locations is ill behaved, the physical location of the code
shouldn't be an issue.  In fact, I'd rather have this code in RAM.  In
general RAM is faster and I can do my upgrades with a disk rather than a
screw driver.  I think Apples intent in putting their OS and API in ROM
was to cut down on piracy and enforce a proprietary architecture.  That
idea is failing and I believe Apple is realizing it.  Witness the
opening up of the MAC architecture.

It seems to me that given the same screen resolutions (this might
require a specialized monochrome board and a really tiny monochrome
monitor in some cases :-) you should be able to duplicate exactly any
particular program or OS you cared to put the effort into.  I worked on
an IBM PC 370 for a time.  While a PC based box, it was *object*
compatible with IBM mainframe 370's.  (There was additional hardware
in the box) without getting into the merits (or demerits :-) of working
in IBM land, it was interesting that IBM didn't even sell compilers for
this box.  You were supposed to download the compiler object modules
from your mainframe!  (for a license fee of course :-().

>>
>> Certainly you can run PC applications on the MAC but only with the
>> purchase of hardware that in effect converts the MAC to a pc :-).
>>
>
>Sorry.  Not true.  SoftPC (to name one) lets you run MS-DOS apps on an
>unmodified Mac... with the right setup, you might be able to run A/UX, Mac
>applications, and MS-DOS applications... all at the same time... with memory
>protection under A/UX...
>

This is good to know.  If I ever wind up with a MAC project, I'll 
be sure to find the command line interface you mentioned.

That is indeed a step in the right direction.  I wonder how long it will
be before somebody feels a need to do the reverse with the MAC (or has
it already happened?)  It is interesting to note that lots of systems
now emulate DOS.  You can run it under many *NIX systems, the MAC and I
expect others.  Wonder why more systems aren't running the MAC
applications?  Is it because there is no demand?  Is it because that
until recently the MAC was a very closed architecture and as such was
too difficult to duplicate?  Is it because the operating system is so
intermixed with the API that it is difficult to separate?  However
limited the architecture, I believe DOS has owed some of its success to
its portability and sharply defined line between OS and application.

Again, I don't feel that hardware has *anything* to do with it.  I
maintain that given equivalent display hardware you ought to be able
write an application that would run identically on just about any
hardware platform.

>
>>
>> Ah.  What are the fundamentals?  I suspect that as long as we have
>> multiple computer manufacturers this will be a problem.  That is why I
>> favor better dividing lines between OS and API.
>
>That's why I prefer blurring them even more!
>Sooner or later, we might get away from the whole distinction/division of
>"OS" and "Applications."  When you buy a new program, the OS would just
>reach out and merge the features of that application with the body of the
>operating system... ;)
>There are some systems that do this right now, but not in a fully integrated
>fashion.  Could be fun.

Sounds like you're figuring that all user environments will be the same
in the future and that there will be only one computer manufacturer.
Perhaps you don't ever want your code to run on any platform but your
MAC. I would prefer the MAC API to be available on *many* different
hardware platforms so that as well as simply compiling, MAC applications
will link and run!

While we're at it, lets go ahead and support some of the *other* popular
API's.

If the support for all these different API's has to be built into all
operating systems, there won't be much room left for applications until
large disks get *much* cheaper.  (The MAC probably has an advantage here
as it can handle more disk drives) I don't know how much room the MAC OS
takes up (much of it is in ROM, and I'm not sure I like that) but I have
heard that OS/2 for example requires 5-10MB of disk space.  (It also is
up to around 1.5M lines of code??!!)  If everybody gave you everything
you'd run out of space in a hurry.

In the near term I would support the purchaser being given a choice at
purchase time of which API they would like supplied with the system.
Then, if they want to run multiple API's, they could be purchased
separately.

From the user level, I agree with you.  The user shouldn't have to worry
about the difference.  Users should be able to pick the API they like
and run it under *any* OS.  As developers and hardware designers, we
need to be aware of these issues.  (Or have things changed *that* much
in the last 15 years since I've been in school).

[stuff deleted]

>
>The answer to "Why only Apple..." is that the other folks want to *sell*
>their add-ons... :)
>
>So far, the majority of add-on interfaces (Windows, X-Windows, etc) are
>cosmetic changes slapped over a text-oriented machine to make it look like
>a Mac.  Once people discover just how little improvement there is, they get
>this "Graphical OS sucks" attitude... ;)
>

Well, the Amiga is sort of a text based system slapped over a graphical
machine.  (Like the MAC, text operations are emulated in graphics and
are *slow* compared to a *real* text based display.  :-) Obviously, With
improvements in graphics hardware this does not have to be the case, but
we aren't there yet.

I guess that my point here is that APPLE *is* like all the rest.  It
gives you *only* its GUI, not *everything* as I understood you to say.
When is Apple going to supply X-WINDOWS (or name your favorite non-
Apple interface :-) so that those applications can run on an Apple
platform without the added cost of porting them to the Apple GUI?  (My
original idea here was the cost of porting between various OS's and
API's right?)  When are they going to give away a command line
environment?  (Why you ask?  Because I and many others LIKE it :-)
Perhaps as you say there are inexpensive solutions in some cases, but it
certainly isn't the manufacturer giving them away.  Are you suggesting
that the current Apple hardware and software is *the one true* computing
platform?  I wouldn't make such a claim for any computer system I've
seen so far.  There are some good ones and some not so good ones, but
I've not yet seen one that *can do it all* :-),

Apple seems to be doing a relatively good job of allowing many different 
API's and even what I would consider to be OS's running on their systems.
Now if only the other vendors would catch on!  Indeed if they don't, 
Apple may well wind up with a *very* large share of the small computer 
market.

At any rate, sorry to be so long winded about this.  Since I think I've
done the best job I can expressing my delusions/ideas, I'll continue to
watch this from the sidelines for a while.

Thanks for listening.

-Rick-