Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!UIAMVS.BITNET!AWCTTYPA
From: AWCTTYPA@UIAMVS.BITNET ("David A. Lyons")
Newsgroups: comp.sys.apple
Subject: following programming guidelines
Message-ID: <8903201645.aa09462@SMOKE.BRL.MIL>
Date: 20 Mar 89 21:44:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 58

>Date:         Sun, 19 Mar 89 05:38:51 GMT
>From:         David Douthitt
>              <astroatc!nicmad!madnix!rat%speedy.wisc.edu@BRL.MIL>
>Subject:      Re: Following Programming Guidelins

> [...]
>| Taking silly shortcuts & other shortsightedness is not only bad for
>| _future_ compatibility:  it's also bad for _present_ compatibility
>| with other applications and utilities.
>
>I would maintain that following ALL guidelines is not necessarily
>a good thing.  I have been appalled by the low quality of ROM code
>for quite a while.  ROM calls are routinely circumvented to improve
>speed and simplify programming.  Perhaps all we need is someone to
>rewrite the ROMs.

That is not an accurate picture of the quality of ROM code.  Please
point out particular things that you are appalled by.

>I would agree however, that in a tight-[k?]nit system such as GS/OS and
>the Macintosh MFS compatibility guidelines are mandatory.  Yet, under
>Pro[DOS] and Pro[DOS]-16, I would maintain that the ROMs are worth
>avoiding - so write to the 80-column screen directly, write to the
>ACIA directly - read the keyboard directly - most average programmers
>can improve on these somehow, someway.

(ProDOS 16 is obsolete except for use with AppleShare file servers.
Assuming that GS/OS will become AppleShare compatible in a reasonable
time frame, there's no reason to think about P16.)

The world is full of trade-offs, of course.  There will always be
cases where the system-provided resources do not meet your needs
(possibly because the system provides something more general than
what you need, and you can get by with something less powerful but
faster), when you'll have to do things your own way.  But _most_ of
the time, _guaranteed_ ways to do things exist, and they should be
used.

If you _must_ write to the serial chip directly to get the speed you
need, fine.  But try it the other way first--if memory serves, TIC
uses the firmware on the GS and is able to keep up at high speeds
(9600 or 19200--don't remember which).

If you have to go out on your own, do it with care.  Look for
alternative guaranteed approaches before throwing the rules out the
window.  (For example, if you need to draw faster than QuickDraw can,
you can start up QuickDraw anyway and ask it for a table of the
starting addresses of all the scan lines.)

>======== David Douthitt :::: Madison, WI :::: The Stainless Steel Rat ========
>FidoNet: 1:121/2 ::::: WittiNet: "Curiouser and curiouser, said Alice." ::::::
>UseNet: ...{rutgers|ucbvax|harvard}!uwvax!astroatc!nicmad!madnix!rat
>ArpaNet: madnix!rat@cs.wisc.edu        {decvax|att}!

 --David A. Lyons              bitnet: awcttypa@uiamvs
   DAL Systems                 CompuServe:  72177,3233
   P.O. Box 287                GEnie mail:    D.LYONS2
   North Liberty, IA 52317     AppleLinkPE: Dave Lyons