harrow@exodus.dec.com (Jeff Harrow, NCSE BXB1-2/E02 DTN=293-5128) (06/28/87)
In response to a recent comment from Larry Rosenstein, I would
like to suggest that 20K or so of patches to continue to allow
*ALL* programs written for *ANY* Macintosh (specifically full
color programs written for the Mac II to be runable on any
Classic Mac with appropriate translation to B&W) is a VERY
reasonable tradeoff.
One of the cornerstones of the Mac line has been this fantastic
compatibility, and it should indeed be carried forward. Will
every program written to make use of full color look decent (or
even work well) in B&W? No, of course not, but that also applies
to a Mac II running with a B&W monitor - it is up to the
developer to make sure that the result is reasonable (the gray
scales could be automatically translated to standard replacement
patterns by the patches).
As a developer AND a user, I don't want to see the Macintosh line
in the position of so many of its competitors, where some
programs require THIS configuration, and some require THAT. I
want to be reasonably assured that ANY program that I write or
buy will work on ANY of my Macs. This represents a significant
"added value" over the competition and will certainly help to
sell more Macs!
Jeff Harrow
Work address:
ARPAnet: HARROW%EXODUS.DEC@decwrl.ARPA
Usenet: decwrl!exodus.dec.com!harrow or
{allegra,Shasta,decvax}!decwrl!dec-rhea!dec-exodus!harrow
Easynet: EXODUS::HARROW
Telephone: (617)264-5128
USPS: Digital Equipment Corp.
Mail stop: BXB1-2/E02
85 Swanson Road
Boxboro, MA 01719
Disclaimer: These are, of course only MY opinions, and not that
of my employer.lsr@apple.UUCP (Larry Rosenstein) (06/29/87)
In article <10574@decwrl.DEC.COM> harrow@exodus.dec.com (Jeff Harrow, NCSE BXB1-2/E02 DTN=293-5128) writes: >In response to a recent comment from Larry Rosenstein, I would >like to suggest that 20K or so of patches to continue to allow >*ALL* programs written for *ANY* Macintosh (specifically full >color programs written for the Mac II to be runable on any >Classic Mac with appropriate translation to B&W) is a VERY >reasonable tradeoff. I apologize for the confusion. The 25K figure was picked out of a hat. (That is the size of the current patches for the Mac Plus). For all I know, it could require 50K or 100K to implement the necessary code. (After thinking about it a bit longer, I think the 100K figure might be more accurate.) I don't have any concrete information on the work that went into implementing Color Quickdraw. My intuitive feel is that it was considerable. Consider what would be required. You would have to provide support for all the new data structures (colored grafPorts, patterns, cursors, windows, controls, menus; PixMaps; graphics devices; color palettes). The patches would have to understand these structures and map the colors to black or white (whichever is closer). There are probably 100+ new calls that would have to be implemented. It is not a matter of making these calls NOOPs. You need to get the same results as on a Mac II running a 1-bit deep screen, so these call have to do some amount of work. Also, some of the Color Quickdraw algorithms were written assuming a 68020. If any of these needed to be ported to the Mac Plus, they would have to be rewritten. (In this case, it is not clear that you could achieve an adequate level of performance.) On top of this, consider color printing. One would naturally want to have the same color output as on a Mac II. I think this would require most of Color Quickdraw to be ported to the Mac Plus. >One of the cornerstones of the Mac line has been this fantastic >compatibility, and it should indeed be carried forward. Will >every program written to make use of full color look decent (or >even work well) in B&W? No, of course not, but that also applies >to a Mac II running with a B&W monitor - it is up to the >developer to make sure that the result is reasonable (the gray >scales could be automatically translated to standard replacement >patterns by the patches). On a Mac II, every machine is capable of 16 levels of gray. On a Mac Plus, there is only black and white. The gray levels makes a big difference. I don't think you can simulate 16 levels of gray adequately on a Mac Plus. As far as compatibility goes, I think there are 3 kinds of color applications: (1) Applications that use the old color model. These are limited to 8 fixed colors, but this model is supported on all machines. This is a way to get limited color with no compatibility issues. (2) Applications that use the new color model, but only in a simple way. In this case, it is easy to check for the existence of a Mac II, and make different calls if color is available. The MacApp DrawShapes example does this, and I expect most commerical program will also work this way. (3) Applications that use color in a sophisticated way. Examples would be a color painting program, color animation program, a program that uses color table animation, etc. In these cases, it would be difficult to make tests at all the necessary places to support color and B&W machines. On the other hand, since they are advanced users of color, the programs would not be very useable on a B&W screen. (Consider a color painting program on a B&W screen; you would have a difficult time distinguishing colors..) >As a developer AND a user, I don't want to see the Macintosh line >in the position of so many of its competitors, where some >programs require THIS configuration, and some require THAT. I As far as color goes, the situation is not (and hopefully will never be) as bad as the MS-DOS world. The Mac II has a definite color architecture, which is extensible. I expect commercial developer to write application that fit into categories (2) or (3). In other words, either the application will either be compatible on all machines (but color machines will have extra color features), or the application will run only on color machines because it is more sophisticated. Sorry for the confusion caused by my earlier message. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
avjewe@cvl.umd.edu (Andrew V Jewell) (06/29/87)
YES!!! It would be a VERY good thing to have access to a
set of color quickdraw patches. 20K extra?? 50K extra??
a small price to pay if the alternative is to not be
able to use some needed program.
However, the point Apple raises is a good one : all these patches
take up space, and there are times when they wont be needed
or wanted. This problem already exists. The standard system
file has all the code necessary to patch all existing machines.
Thus a Mac+ is forced to carry around all the code to patch
old roms to look like the one it has, and also the code to
allow the Mac II to do things that the Mac+ can't do anyway.
Sure, I can use ResEdit to remove the appropriate resources,
but this is error prone, unpleasent to non-hackers and impossible
to those without ResEdit.
A very similar problem is solved with the font/DA mover.
I can imagine a program very like it which could reduce the
system file to what is necessary on a particular subset of
existing machines (often a set of size 1). Now that we have this,
we can set a color-quickdraw-compatibility switch to tell it
that we want the above mentioned patches.
Andy Jewell
-- it seems so easy, I must be overlooking somethingdplatt@teknowledge-vaxc.ARPA (Dave Platt) (06/30/87)
Posting-Front-End: GNU Emacs 18.41.3 of Tue Apr 7 1987 on teknowledge-vaxc (berkeley-unix) I agree that a "color QuickDraw compatibility" feature could be a nice thing to have, but that it isn't a good idea to install such a beast in the "standard" System file... 20k on disk, and another 20k of memory, may well be more than many people will want to have consumed by default for a feature that they may never need. Could the patches to implement "color QuickDraw" stubs simply be released in an INIT file, and then dragged into the user's System folder (or moved by the Installer) for boot-time installation by Apple's neat "INIT 31"? This wouldn't require the implementation of a new patch-installation facility (one less thing to release!).
ragge@draken.nada.kth.se (Ragnar Sundblad) (07/05/87)
In article <1209@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes: > >I apologize for the confusion. The 25K figure was picked out of a hat. >(That is the size of the current patches for the Mac Plus). For all I >know, it could require 50K or 100K to implement the necessary code. (After >thinking about it a bit longer, I think the 100K figure might be more >accurate.) How about a ROM-upgrade (for Plus and SE) then?