With the release of macOS 10.13.4, Apple is now actively warning its users that any 32-bit software may not be fully compatible with future versions of the Macintosh operating system. This does not come as too much of a surprise since we recently underwent this forced transition from 32 to 64-bit software in iOS. 64-bit Intel processors, starting with the Core 2 Duo, have been available in Macs for well over a decade, but it is only now that Apple is "encouraging" that all modern software should be run as 64-bit. Fortunately, a casual perusal of what software is 64-bit shows that most software has already made the transition. Only older software and deprecated frameworks have not been updated. This includes even Apple's own QuickTime framework, which has been replaced by the newer AVFoundation framework.
From Apple's 64-Bit Transition Guide:
Beginning in OS X v10.5, most OS X APIs are available to 64-bit applications. Going forward, Apple plans to make new APIs 64-bit-compatible unless otherwise noted. However, not all existing 32-bit APIs are supported in 64-bit applications. ... In certain technology areas (Carbon particularly), a few APIs have been deprecated for 32-bit use beginning in OS X v10.5. Most of these APIs are not available in 64-bit applications.
Back in 2007, Apple notified developers that it would not be updating the Carbon framework to 64-bit. Considering that a few bits of Permanent Eraser still rely upon Carbon, I was concerned that Permanent Eraser would break in the future due to Carbon. The good news is that "Carbon" acts as more of an umbrella term, and some of its various functionality fall under other frameworks (such as Core Foundation or Core Services) which have been updated to 64-bit. However, in my research, I did come upon some older methods I've used have been deprecated over the years, so it was still a useful exercise to look for more modern alternatives.
I created a small example program which details several methods to determine if a select file contains a resource fork (or not), and if so, determine the size of the fork. Early methods depended on methods such as FSGetCatalogInfo, which was deprecated several years ago in OS X 10.8 Mountain Lion. Even if some of these deprecated methods still work on a 64-bit system, it is a good idea to update them with more modern methods to protect against the case that these methods might break in the future since they are no longer being maintained.
This coding example examines four different methods: getxattr, NSFileManager, getattrlist, and FSGetCatalogInfo
getxattr- This is the most straightforward method I discovered, and it works well on older systems, as well.NSFileManager- By appending..namedfork/rsrcto the end of a file path, one can inspect a file's resource fork (if it exists). This naming scheme could change in the future, so this may not be the most reliable method.getattrlist- This was mentioned on some message boards and mailing lists, but like in my free space example from last year, I was never able to getgetattrlistto work properly.FSGetCatalogInfo- This is the "old" way to inspect a file's data and resource forks. It still works as of High Sierra, but several of the methods used in this example such asCFURLGetFSRefandFSGetCatalogInfohave been deprecated.
References
- 32-bit app compatibility with macOS High Sierra 10.13.4
- FSGetCatalogInfo Reference
- CFURLGetFSRef Reference
- NextPrevious High-Level 64-Bit API Support
- Next Introduction to 64-Bit Transition Guide
- Carbon Dated
- Check for resource fork in Objective C
- How to open and read resource forks in Obj-C
- How should I print types like off_t and size_t?
- Unison - osxsupport.c
- tclMacOSXFCmd.c
- Mac OS X Resource Fork and Command Line Tips
- Carbon only?
- 64-bit support in Leopard: no Carbon love