On 3/29/02 3:59 AM, "Robert Purves" <robert.purves@...>
wrote:

> 
>> The following toolbox access routines allow the user to directly access data
>> files. They work fine in R6, except when compiled under carbon they create a
>> "function must be defined before using" and other compile errors.
>> 
>> FN OPEN(PBlk&)
>> FN CREATE(PBlk&)
>> FN FLUSHVOL(PBlk&)
>> 
>> In OS X what is the correct syntax for these routines, if any?
> 
> Step 1.  Turn on the checkbox:
> Preferences/DBug/Insure validity of PPC toolboxes.
> 
> Leave it on always (except, perhaps, for compiling your app's shipping
> version, and even then not a bad idea to leave it on).
> 
> 
> Step 2.  Convert old wrong toolbox names in your project to the correct modern
> names. This avoids ambiguity about what you are actually calling.
> 
> Old wrong name             Correct name
> 
> Open, OpenSync, PBOpen     PBOpenSync
> Close, CloseSync, PBClose  PBCloseSync
> Read,  ReadSync,  PBRead   PBReadSync
> FlushVol                   PBFlushVolSync
> Create                     PBCreateSync
> Control                    PBControlSync
> KillIO                     PBKillIOAsync
> Status                     PBStatusImmed
> 
> Compilation should be unaffected by this renaming.
> 
> 
> Step 3. Think: "Why am I using these notoriously incomprehensible ParamBlock
> routines? They hark back to the 1980's.  Why am I not using the FB file
> statements: Open, Write #, and so on?  For special toolboxery, if that is
> really necessary, why don't I use a FSSpec with FSxxxx routines, which would
> be 1990's code and less conspicuously out of date?"
> 
> Macho Mac programmers would do anything, even drink bad beer, to avoid PBxxxxx
> calls.
> 
> Step 3'  Drink another glass of Fine Old Panther Piss. Go to step 3.
> 
> 
> Step 4.  Insert this in your source code, to fix a Release 6 headers bug that
> wrongly makes PBFlushVolSync seem unavailable in Carbon
> 
> #if CarbonLib
> toolbox fn PBFlushVolSync(long) = word
> #endif
> 
> 
> Step 5.    Replace calls to PBCreateSync by PBHCreateSync, which Apple says is
> (very nearly) an equivalent.
> 
> Replace calls to PBOpenSync by PBHOpenDFSync.  This is preferred, according to
> Apple, over the obvious alternative PBHOpenSync.
> 
> 
> 
> Step 6.  Special action is needed whenever a ParamBlock gets its ioRefNum%
> field set to a wdRefNum, as obtained from FB Files$(...).  A wdRefNum was a
> workaround introduced by Apple for HFS, to allow old MFS file calls to limp
> along into System 6. Apple discontinued it in Carbon, where no toolbox
> routines can accept a wdRefNum parameter.
> 
> PBlk&.ioVRefNum%=Vol% ' this is volume reference number
> // Note: the var named vol% may be wrongly named and commented.
> // If it came from an FB Files$(...) statement, it's a wdRefNum
> 
> You *must* call FBWDToPBWD(PBlk&)  before supplying the PBlk to any PBxxxxx
> toolbox routine.  FBWDToPBWD fixes up the ParamBlock to resolve the obsolete
> wdRefNum. This is an ingenious Andy Gariepy workaround, to help old FB code to
> survive into OS X.
> 
> 
> HTH,
> 
> Robert P.



Thanks for the information. This is exactly what I wanted to know!



Doug Stemen