Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!usc!snorkelwacker!ira.uka.de!smurf!urlichs
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.sys.mac.programmer
Subject: Re: How to tell if a volume is a floppy drive?
Message-ID: <29a8f2.2=5@smurf.sub.org>
Date: 3 Sep 90 18:55:38 GMT
References: <3900@wucc.waseda.ac.jp> <690@dbase.A-T.COM> <12229@hoptoad.uucp>
Organization: University of Karlsruhe, FRG
Lines: 28

In comp.sys.mac.programmer, article <12229@hoptoad.uucp>,
  tim@hoptoad.UUCP (Tim Maroney) writes:
< In article <690@dbase.A-T.COM> cy@dbase.UUCP (Cy Shuster) writes:
< >Always clear out your PB blocks: before every call!
< 
< No offense, but I think that's terrible advice. [...]
< We all know what wonders of efficient performance Ashton-Tate's Mac
< applications are.  If this is what A-T considers good programming
< practice, that may have something to do with it.

I fail to see why a small assembly-language DBRA loop to clear a parameter
block (that's what I'm using, anyway) could affect I/O performance in any
significant way. Dispatching the trap and calling the driver takes longer than
even a did-it-the-stupid-way-in-Pascal loop.

On the other hand, it is far easier to debug I/O stuff when you can see
exactly which parameters are going in, which are returned, and which were
changed (PBGetCatInfo comes to mind). It also protects one against gratuitious
interface-changing done by Apple, stupid interface-changing done by INITs
(yes, that happens :-( ), and mysterious crashes provoked by mistakenly-
omitted parameters (you mentioned ionamePtr); at least when they're zero,
you'll know where to look for mysterious changes, and running with the
VBR register set to a clone of the interrupt table (on 68020/030s) protects
you against the evil _BlockMove(somewhere,NIL,larger_than_eight).

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)