>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.