This page is a wiki. Please login or create an account to begin editing.


13 posts / 0 new
Last post
Jatoba's picture
Online
Joined: 2018 Apr 16
Program to identify Mac binary types?

Hiya. Is there a program, preferably for OS 9 (OS X PPC is fine, too), that correctly identifies the binary type of a program? The real Mac OS uses PEF to my knowledge, while OS X uses Mach-O (despite having some PEF support for Carbon, from what I read). Not sure if other binary types existed for those 2 systems.

So far, these are the binary types I roughly learned about:

1. 68k Classic Mac Software (PEF?):
1.1 -> 24-bit (requires System Software 7.5.5 and earlier, also allegedly requires 68030 and older processors, and if used in System Software 7, the OS needs to be NOT running in 32-bit mode);
1.2 -> 32-bit Clean (requires System Software 7 and later);

2. PowerPC Classic Mac Software (PEF?)
2.1 -> Regular PEF binaries
2.2 -> Carbon

3. PowerPC Mac OS X Software (Mach-O? Requires Snow Leopard or older)
3.1 -> 32-bit Software
3.2 -> 64-bit Software (requires Leopard & newer or, if the GUI is a separate 32-bit process, Tiger & newer. Needless to say, it also requires 64-bit processors)

4. Intel Mac OS X Software (Mach-O? Requires Tiger & newer)
4.1 -> 32-bit (soon to be unsupported in the latest OS X versions)
4.2 -> 64-bit (same requirements as PowerPC counterpart)

Then there are also "FAT binaries", containing code for more than 1 of these. For OS X, it's better known as a "universal binary", and can contain any of all the 4 possibilities (32/64-bit PPC/Intel). I think those can be Carbon apps, too, meaning perhaps they'd also work with PowerPC Classic Mac OS if the Carbon Extension is installed.
IIRC Mac OS X reveals in some app whether apps are PPC or Intel or both, but not sure if they also report whether it's 32-bit or 64-bit.

For the real Mac OS, "FAT binaries" often refer to those that have both 68k and PowerPC PEF code, to my knowledge. What I don't know is whether or not the 68k side of such binaries have to be 32-bit Clean or if they may just be 24-bit, as well. I also don't know if there was ever something like a 68k binary that was both 24-bit and 32-bit clean, with either one being run according to the system it is run on.

Anyway, I was just wondering if someone knows of some program that reveals as much information about binaries as possible. I have once seen something that identified PEF binaries as 68k or PPC or both, but that was about all I saw (and even then I forgot that program's name...).

Comments

SkyCapt's picture
Offline
Joined: 2017 Jan 11

You got "NativeChecker" which tells you when a program is 68k, PPC, or both (Fat).

For OSX, you can load a program's Contents/MacOS/* or any "unix executable file" into any "hex editor" then look at the first 4 bytes. It's almost an "Easter egg" how Apple chose to distinguish PPC vs Intel vs UB: they spelled comical words in hexadecimal with only the letters A thru F.
PowerPC starts with "FEED-FACE" - perhaps apt because RISC is more "RAM hungry" than CISC.
Intel starts with "CEFA-EDFE" aka feed-face backwards.
UB starts with "CAFE-BABE" which ought to be somebody's online persona.

SkyCapt's picture
Offline
Joined: 2017 Jan 11

Another one of these 32bit hexadecimal apple easter eggs. In Open Firmware's forth-like language, the stack underflow error message shows one. You can access it by typing in Open Firmware just the period key followed by return. The data for the error msg comes preloaded with this msg describing the predicament: deadbeef

Troyd's picture
Offline
Joined: 2014 Nov 14

For OSX you can also drill down via Show Package Contents until you find the MacOS executable. Open a Terminal window and type file and then drag the executable into the window. The file command returns an analysis of the executable, including platform.

e.g. For TextEdit, the command file /Applications/TextEdit.app/Contents/MacOS/TextEdit returns the following info

/Applications/TextEdit.app/Contents/MacOS/TextEdit: Mach-O 64-bit executable x86_64

SkyCapt's picture
Offline
Joined: 2017 Jan 11

Cool. Tiger OS tells me either "Mach-O executable ppc" or "Mach-O executable i386" (or both if UB). It tells me Classic apps are "header for PowerPC PEF executable"

One caveat in using OSX Terminal to inspect Classic Mac files, the Terminal ignores file Resource Forks, so look at the aforementioned "NativeChecker" (March 1994 version), it's an executable entirely in the Resource Fork and its Data/Standard Fork is zero bytes or Empty.

in Terminal> file NativeChecker
its reply> NativeChecker: empty

and when I specify to Terminal use Resource Fork instead of Data Fork, i get this:

in Terminal> file NativeChecker/rsrc
its reply> NativeChecker/rsrc: ms-windows icon resource

... looks like "file" command describes the "first" individual resource it encounters in the filefork, then ignores remaining resources.

Far out.

Jatoba's picture
Online
Joined: 2018 Apr 16

Thanks, guys! Exactly the kind of info I was hoping for. Smile

I also just saw now I Love Native! (Pro) listed as a program similar to NativeChecker, too.

SkyCapt's picture
Offline
Joined: 2017 Jan 11

There is something been eating at me.
"MacBinary" file format, nearly like how named in this thread title, but I bet you mean to say "Mac binary" in the generic sense of: file-on-a-Mac.

The "MacBinary" is (or was) a specific file-TYPE-on-a-Mac. There were even multiple versions 1, 2, 3 (4?) of this File Type, sometimes written as "MacBinary I, MacBinary II, MacBinary III".

Apple has obliterated (beyond deprecated) the MacBinary file types. MacBinary was a small (228 bytes in one case) "wrapper" whose main task was to conjoin one file's resource fork and its data fork into this new file having only the data fork. For network file transfers, to avoid loss of resource fork, like we all use StuffIt (or OSX .zip) for nowadays.

Apple's obliteration of MacBinary file type has left OSX (Tiger) with some strange behavior when encountering a MacBinary file. We have a small example MacBinary file here on mg, found AS the one little download on this page. File name "macosx-ati-displays-4-5-7.dmg", I'll refer to as The MacBinary hereout.

By default, OSX (Tiger) DiskImageMounter was programmed to passthru this particular .dmg file's MacBinary wrapper like the wrapper's not even there. Finder Get File Info calls it a "disk image", double clicking it behaves as a disk image, but that's where normalcy stops.

Terminal's "file" command fails to describe MacBinary. Try the "file" command on this MacBinary .dmg download I mentioned, "file" says the .dmg is "data" and nothing else, whereas a 'real' disk image is described (with attributes) by the "file" command, when not compressed at least; my Tiger makes bogus garbage descriptions of compressed disk images even though Tiger created those images.

There was a way to make DiskImageMounter/Disk Utility choke on the MacBinary .dmg but maybe it was another version of OSX, I'm not finding it in 10.4.11 (Server). Anyway, there's wide varying behavior from different versions of OS/StuffIt/Toast concerning this example MacBinary file, if you use Finder Get File Info to remove the .dmg suffix in name, then add .bin suffix in name. And more different when compared to a genuine .dmg file undergoing the same treatment.

I'll go to the ATI-Displays page, and say stuff...

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

One issue that I have, with files downloaded from the web, is, it really depends on the archiver/uploader as to the filename ending. That is, a file name ending in .dmg, but opens as a .bin may simply be an incorrectly named .bin file.

I have struck this several times in the past, usually with ".hqx" and ".bin" named files that were actually pure ".sit" StuffIt files.

For example: devcdjan92cat.hqx File says ".hqx" but it's actually a plain text document (a tab-delimited directory catalog of a CD's contents actually). It was hosted here, since been removed, but still available on the MG mirror site.

But anyway, you can't really trust what you see and assume that it must be.

Case in point: That ATI binary file that is incorrectly labeled ".dmg" - On OS X, change the ".dmg" suffix ending to ".bin" and drag it over to StuffIt Expander to deal with it. You'll find that it extracts from the .bin to an actual ".dmg" file that is mountable in OS X.

It's correct download filename should have been "macosx-ati-displays-4-5-7.dmg.bin".

SkyCapt's picture
Offline
Joined: 2017 Jan 11

(ew, I did terrible writing in my last msg, but edit time has gone)

Weird thing is the ".dmg.bin" misnomered as plain ".dmg" was programmed to operate normally with click-to-mount/etc on Tiger OS. More efficient than un-stuffing it, it takes no extra disk space nor extra time to unstuff, as the MacBinary layer is being emulated in real time by OSX PPC. But perhaps Snow Leopard or later rejects this imagefile in its present form ?

I can vouch for ati-display's uploader, they're merely relaying how they found the file online plus it worked for them the way it is. I obtained the same file a long time ago from a different source and the garden file is exact match against my old archive.

On top of it, I today wouldn't know anything unusual about the ati-displays.dmg file, if I hadn't done something chancy like drag it to StuffIt Expander totally by accident.

Then, I tested all my .dmg files from downloads in my archive, and found groups of other files also like ".dmg.bin" presented as ".dmg"-alone. On one hand, it was nice to find oem datestamps preserved within the dmgbin's.

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

I can vouch for ati-display's uploader, they're merely relaying how they found the file online plus it worked for them the way it is.

I would (and do) test any downloaded file before re-upping somewhere, on the basis that it may be useful to someone else... No matter. I strike a lot of anomalies with online downloads, so it doesn't surprise me and they're often solvable.

MacBinary of course is not a compression algorithm, so there is usually little difference in file size between it and the file it is wrapping.

My 1st port of call for inspecting dubious or unknown archives is BBEdit Lite (and/or TextWrangler).

BBEdit inspects the data fork of a file (much like "file" in a *nix Terminal), only you get to see much more.

I just drop a file (including classic Mac executables) onto BBEdit to view their data content. If you know what to look for, you can glean a lot of info about a file in this way.

If you drop a classic Mac app onto BBEdit and it opens to a blank page, then you know that that executable is encoded as a classic Mac 68k, application. - If it's a PPC app that you drop onto BBEdit, you'll get much more info, confirmed by the PPC header that begins with "Joy!" Wink

BBEdit Lite 6.1.2 for OS X, a pure Carbon app, dropped onto TextWrangler, returns: Joy!peffpwpc.

But BBEdit/TextWrangler comes into it's own when inspecting misnamed archived binary or text files (.sit, .bin, .hqx, etc) that don't behave as they should they should, to aid in determining what file types they may actually be.

Various versions of BBEdit Lite can be used on classic Mac OS's 6.0.x and up to 10.6.x (Rosetta) on OS X, BBEdit & TextWrangler for newer and earlier Mac OS X variants than 10.6.x.

IIGS_User's picture
Online
Joined: 2009 Apr 8

There is also Carbonic to determine carboniced Mac OS X applications, but it seems this application doesn't work properly.

Jatoba's picture
Online
Joined: 2018 Apr 16

What a shame, Carbonic seemed to totally fit with the category of programs I was seeking, like Troyd's approach and NativeChecker. Thanks for bringing that one up to our attention, as well!

SkyCapt's picture
Offline
Joined: 2017 Jan 11

It wasn't reasonably possible to do a lot of those things shown in Carbonic, this was vaporware/dreamware.

"Carbonized" hasn't been well defined. My idea is it means you can successfully launch the individual executable from both OS9/8 and OSX. A program just making use of the CarbonLibrary isn't enough to say it's Carbonized.