From: johnsd2@lib104.its.rpi.edu.its1 (Daniel Norman Johnson)
Subject: Re: Mac multitasking?
Reply-To: johnsd2@lib104.its.rpi.edu.its1
Organization: Sun Microsystems, Inc.
Date: Sun, 13 Dec 1992 00:57:18 GMT

In article 12678@athena.mit.edu, zmonster@athena.mit.edu (Eric M Hermanson) writes:
>In article <7_g2zs#@rpi.edu> johnsd2@jec325.its.rpi.edu.its1 writes:
>>>
>>>With the Next, all color information is handled by the color panel (object).
>>>When NeXT upgraded the color panel to include PANTONE color support, ALL
>>>applications that had a color panel (or variation thereof) in them 
>>>automatically took advantage of this change.  Since the objects (in this
>>>case color panel) are bound (read in) at the run time of the program, the
>>>new color panel object popped up when the user selected "Color.." from 
>>>the menu.  This new color panel allowed the users to select colors through
>>>the PANTONE color matching system.  This is another advantage of NeXT.  It
>>>has PANTONE color support BUILT into the operating system.  ANY program
>>>may take advantage of it.  On the Mac, only programs that are WRITTEN to 
>>>have PANTONE color picking have it.  Object oriented technology makes
>>>programs very modular.  In this way, if a "module" is upgraded, ALL 
>>>applications benefit.  It is INHERENT in the operating system. 
>>
>>It is inherint in ANY OS that provides services like that; and MacOS
>>is one such. To do the same thing you replace or patch the Color Picker
>>Package.
>>
>>And it isn't even object oriented. :) This particular benefit is not
>>really very unique.
>>
>
>I may be wrong about this, but here it goes anyways.  The Mac Color picker
>is a Package, as you wrote.  It is a SEPARATE program from the existing program
>you are running in.

Not exactly, it is most similar to a DLL. It is a library that is loaded
at runtime. But there are ways to replace ROM-based routines too,
so this is not an important distinction.

>  WIth NeXT, the color panel is an object INSIDE of the
>existing program.

It IS? Its ->not<- provided by this OS? So how can an OS update
affect it at all?

>  This is better than the Mac setup, because with NeXT, a
>programmer can write extensions to the NeXT color panel to modify it in
>any way they choose.

Yes, but it sounds like that's on an app-by-app bases; there's no
general color picker to that you could change to modify ALL programs.

>  The Mac Color picker is a separate program that 
>Apple alone upgrades.  A person is stuck with the same old color picker on the
>Mac until Apple decides to release another OS version.

No. Anyone can change it. The obvious way is to patch the color picker's
trap, and either do your own thing to play games of various sorts with
parameters and whatnot. You can of course also change the dialog box
itself, but you'd have to patch the dialog manager to make the bits you
add work, which is kinda messy. This stuff is nowhere near as clean
as the NeXT approach, but it does work. (well, just REPLACE it is
easy enough. Its modifying an existing thing that is messy)

>  WIth NeXT, programs
>can contain variations of standard objects (i.e. color panel).  This is only
>ONE of the many many advantages of NeXT.

Now now, no need so shout "one"; I can read fine. :)

I do realize that NeXTs have numerous nifty features. You give a REALLY
neat one in annother article. I know this. But you were claiming
that Mac can't do something that it not only can do, but routinely
does.

>The thing I like better about NeXT is display postcript.  Postcript is sent
>directly to the screen, no proprietary imaging model is used, as with the
>Mac, which only EMULATES postcript using QuickDraw.  A concrete example
>of Display postcript's powers would be to try this test:

You are either spewing hot air, or simply do not know what QuickDraw is.
QuickDraw does not even TRY to emulate postscript. It is a graphics
library basically, and it can image things to send to the printer. Some
printers use this technique- notably ImageWriters, StyleWriters, DeskWriters
and a few LaserWriters. The output in this case matches the "quickdraw" drawing
to the pixel. Quickdraw is rather limited in some ways tho, so that drawing
rotated, er well anything, is rather messy. And it doesn't support a lot
of the neat things postscript does. But it is much, much faster than postscript
is for screen drawing (reputately). So Im not about to throw it away, unless
I have a need for the abilities of Postscript. And if I do that, I can use
postscript on a Mac, albiet programming the Mac to do that is not trival.

The reason the Mac converts Quickdraw drawing primitives to Postscript when
printing on a postscript printer is because this makes it transfer faster that
just generating a bitmap and sending it.

I rather expect that all quickdraw primitives have equivalents in the
(more powerfull) Postscripts, so I doubt this is a big source of error.

At no time, however, does QuickDraw try to interpret postscript and use it.

>Draw a cirle on your Mac screen.  Then draw a tangent to that circle, as best
>you can, without zooming in.  Do the same thing on a NeXT (built in display 
>postcript).  You will find that the tangent is correct when printet out on
>the NeXT 100% of the time.  On the Mac, the tangent is off.

Really? How does the NeXT do that? How does it knwo I meant 'make this tangent'
and not 'make this almost, but not quite tangent'? Does it assume that
if anything is drawn near-tangent to a circle, it should make it all-the-way
tangent?

Just exactly what does Display Postscript do here?

>
>>(b) The NeXT was not designed so from teh ground up, as one of its major
>>    components (Mach) was just not designed for the NeXT; NeXT built
>>    on a pre-existing foundation. However well they did it it, your
>>    assertion isn't right. Interestingly, the MacOS ->was<- designed
>>    from the ground up. (solidly is annother thing); does this help
>
>Wrong.
>Carnegie Mellon University developed Mach with the aid of NeXT.  Carnegie
>Mellon now owns around 5% of NeXT computer.

Mach, last I checked, was a kernal that was designed for general use. Im
not surprised NeXT took an interest in it, but it clearly did not design
mach for the NeXT. Somebody else designed Mach (Carnegie Mellon), and NeXT
uses it but does not own it. Last I checked Mach was not even object
oriented- that was put in on top of it. No?

I think to say that the NeXT was "designed from the ground up" is pretty
silly, even if NeXT went ahead and payed for the entirety of the development
of Mach; I rather doubt they did, tho. If so, why not make it object
oriented like everything else?

I also think it's pretty irrelevent, but heck why not argue about it,
we argue everything ELSE here. :)

---
			- Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.