The release notes below describe the many other additions and changes.
 FileHandling.c updated to 64-bit - Brian
All FB's I/O verbs no longer accept FSSpecs/FSRefs and only accept CFURLRefs. See Jan/Feb 2017 FB list discussions for details.
a) the file-based version of the OPEN statement must specifically use the CFURLRef version ( OPEN UNIX and OPEN "C" excepted because not file-based )
b) READ/WRITE FIELD are removed and no longer supported due to use of deprecated Handles. Replacement options were discussed in Jan/Feb 2017 FB list discussions.
c) FB Help's 'Appendix A - File Object Specifiers' updated to reflect removal of FSRef/FSSpec support and sample code updated.
d) FB's Rename verb now accepts only CFURLRefs. Syntax is: rename urlForCurrentFile urlForNewFile.
e) FB's Kill now accepts only a CFURLRef for the file name.
f) FB's files$ now only uses/returns a CFURLRef for each of the three major options listed in FB Help. FB Help updated to reflect changes.
1) "ConsoleWindow"'s usage of files$ updated to use URL. I don't like it because ConsoleWindow depends on an FSSpec for its TXNSave() use.
2) New constants for files$ _URLOpen, _URLFolder and _URLSave are preferred over their predecessors _CFURLRefOpen, _CFURLRefFolder and _CFURLRefSave but have the same values.
3) OPEN/FILES$ changes to Editor source to allow it to build with FB 5.7.99.
4) FBtoC flags non-CFURLRef files$ usage for the variable but does not check the mode constant; but runtime honors only valid modes.
a) Make sure to check files$'s returned fileName for non-zero length. Zero indicates failure and possible bad mode constant.
g) Apps crashing with a "Bad file descriptor" message indicates a file i/o attempt which isn't allowed by the OPEN mode (i.e. opening in mode "I" and trying to WRITE the file ).
h) A second attempt ( either within the app or another app )to OPEN "N" on a file currently/already open in "N" mode has specific new behavior compared to prior FB5 versions:
1) The second attempt process/code is given read-only access ( essentially "I" mode ) to the file.
2) The FB runtime sends a "file already open with with write permission" ( _opWrErr ) error code which can used by the caller ( must be trapped with 'on error' and "error" )
3) Even though opened for "I" after a request for OPEN "N", it must be closed or any subsequential exclusive OPEN requests will fail.
4) FBers should always check the error status returned by any file OPEN and take appropriate steps.
5) N.B. OPEN code only provides access; it does not provide any data integrity protection when there are concurrent readers and writers of the same file.
 Util_FileManager additions - Bernie
a) File access functions written with only modern 64-bit code. Eventual replacement for Util_FileDirectory.
b) Only supports CFURLRefs and does not support FSRefs or FSSpecs.
c) Several demos available in the FB Examples
d) Util_FileManager.incl inlcudes Util_PathUtilities.incl and Util_URL.incl
d) Util_FileDirectory is still available for those who need it but folks should plan to migrate to Util_FileManager.
 New/Changed Headers and Examples - Bernie, Steve VV, Brian
a) A slick multi-dimensional Core Foundation array implementation handles all the details. See: FB_Examples/CoreFoundation and Cocoa/MDArray( multi-dimensional )
b] Tlbx CFUUID.incl and Tlbx CFStringTokenizer.incl added to Headers
c] CFMeasurement headers and demo added to FB Examples
d] Superscript/Subscript demos added to FB Examples
e) Util_Files.incl uses outdated ( parameter block ) file functions. N.B. IF YOUR CODE USES FUNCTIONS FROM THIS INCLUDE, IT WON"T BUILD.
 Default error function - Brian
( i.e. when it isn't supplied via 'on error fn yourErrorHandler' in your own code ) updated to include:
a) error string and comment
b) N.B. Carbon calls GetMacOSStatusErrorString() and GetMacOSStatusCommentString() were NOT used. Cocoa's NSError used [NSError errorWithDomain:NSOSStatusErrorDomain
 NSLog.incl updates - Bernie
a) silence a clang 'dealloc' warning ( accidentally omitted in 5.7.97 )
b) Copy & Copy All items added to text view’s contextual menu
c) NSLogBeginEditing & NSLogEndEditing. Bernie's explanation follows:
Multiple NSLog calls in big loops can make it appear that your app is hanging. After issuing NSLogBeginEditing, the NSLog text view is only updated at the point NSLogEndEditing is called.
// — Example1 ---
On my machine, this takes about 95 seconds for the text to appear.
for i = 0 to 150000
// — Example 2 ---
Enclosing the code in an NSLogBeginEditing/NSLogEndEditing pair takes less than 4 seconds.
for i = 0 to 150000
************ REMINDER: there is a header file that needs to be updated for the structure used in FileHandling.c *********************
Fixes - Brian
 FBtoC Help, inadvertently omitted in 5.7.97, is back again.
 Editor scrolls source view to an incorrect line number but FBtoC's line number is accurate ( captured value of global in local before doing a dispatch async )
 Comparing an FB container to a string constant resulted in string stack failure ( changed gFBStk to SInt16 in Runtime.h and General.c so it can go to -1 instead of 65535 )
 FBtoC's Settings dialog would not show up when requested via the Editor's preference pane option. Thanks to RC and BW for noting and reminding.
Internal: Added source for "Error Codes" app to FB project source