32-bitCheck nows checks all code, command tools and dylibs included

There’s more executable code on your Mac than that in apps and bundles alone. The great majority of that which is outside bundles is in executable Mach-O files – things like command tools and dylibs (dynamic libraries). And those Mach-O files can be 32-bit, or 64-bit.

When macOS 10.14 ships, Apple has warned that it will not run 32-bit code without “compromise”, so now is the time to start updating and replacing old 32-bit code, including command tools, dylibs, plugins, extensions, and of course apps themselves.

My free tool 32-bitCheck 1.1 is unique in scanning thoroughly for and reporting apps and bundles which are still 32-bit, but doesn’t examine bare Mach-O files such as command tools and dylibs. So I have improved it further in version 1.2 to give you the option of checking all bare Mach-O files too.

32-bitCheck05

Tick the checkbox to Check Mach-O and run a scan on a folder containing plenty of command tools, etc., like /usr/local, and it informs you which of them are still 32-bit.

It tests for these in the same way that the command tool file does, by examining their ‘magic number’, the first four bytes of the file. If that is 0xfeedface (I kid you not!) in hexadecimal, then that Mach-O binary is 32-bit and not 64-bit. I have checked results returned by 32-bitCheck against those from file.

I have also improved the information provided in the text report, to make it clearer which types of code were included in the scan, and updated the Help book again.

I have looked again at the issue of memory usage: this is almost entirely the result of performing a deep traversal of the folder being scanned. Interestingly, if you repeat a scan on the same folder, perhaps with different option settings (for bundles and Mach-O files), second and subsequent scans seem to be rather quicker, suggesting that the deep traversal is being cached after a scan.

Version 1.2 of 32-bitCheck is available from here: 32bitCheck12a
and in Downloads above.

This completes the features – apart from folder drag and drop support – which I intended this tool to have. If you want any additional features or changes, please let me know here.

3Comments

Add yours

1

Ron Gomes on April 23, 2018 at 7:00 pm

This is very useful. Thanks.

LikeLiked by 1 person
2

xz4gb8 on May 31, 2018 at 12:18 am

I found it scary that there is no indication of the scan origin as it is happening.

I found it frustrating that, even without closing the app, every save operation defaults to ~/ instead of using the previously entered save location. (A scan of / was aborted after about an hour or so ad followed by multiple scan organs.)

LikeLiked by 1 person
- 3
  
  hoakley on May 31, 2018 at 5:17 am
  
  Thank you.
  The folder being scanned is shown in the window title from the moment that the scan starts. The snag with leaving the path in the text box is that that forces the next scan to start using the text box again, unless you select the contents and clear them. There isn’t a perfect solution – I think the current behaviour is the least bad, but welcome suggestions for an alternative.
  The problem with setting the default location for saving reports is that that automatically goes to the folder you have just scanned, which is almost invariably where you don’t want to save the report. I have an idea for creating a local default which may be an improvement on that and will try it out shortly.
  As to scanning from the root, I’m afraid that is inevitable for a deep scan, and I do warn about this in the docs.
  Howard.
  
  LikeLike

Share this:

Related