This is a version of Bill Spitzak's Mach-O object file format 680x0 disassembler. It was originally distributed along with "Hack Kit 2" just as NeXTStep 2.0 was released. I needed a disassembler and I found the source code this is based on. It didn't compile at all under NeXTstep 3.0. So, I hacked on it a little bit. Bruce Ediger bediger@teal.csn.org ediger@metamatic.denver.co.us Main changes: 1. Total reformatting of source code. The original style was a little eccentric, seemingly chosen to minimize source code line count at the expense of clarity. 2. Removed most of the Magic Numbers used in the code, replaced them with symbolic constants from system .h files. There's still a few Magic Number Constants in the actual disassembly, but they don't have a header file replacement. The original code seemed to have an allergy to symbolic constants. 3. Made the Mach-O file support work with the official system header files. Spitzak had concocted some custom thing that subsumed most of mach-o/loader.h, mach-o/nlist.h, mach-o/ldsyms.h and a few others. Needless to say, this concoction didn't track official NeXT include file updates. This change necessitated changing arguments to a lot of the functions that dealt with Mach-O files, or the original author's conception of them. 4. Removed a few inexplicable things like using lseek() to find a file's size. 5. Used a simple memory-mapped file object to replace the scattered uses of map_fd(). This neccessitated making the main() routine be Objective-C source. What I couldn't do, but wanted to do: 1. Make the symbol table use comprehensible. I still don't really understand what's going on. It seems to me that the code does things the hard way. A hashtable or something might be faster and more understandable, but I was afraid to replace the code already existant because it seems to work. 2. Make it use the symbol table and/or LINKEDIT info from shared libraries to identify calls into the shared libraries. This stems from the odd symbol table stuff. Unfortunately, a dissassembly of a stripped object file won't be as informative as it could. 3. Make it completely ANSI C. There appears to be some hoseup in sys/types.h vs bsd/libc.h in the NeXTStep 3.2 include files. Or kill me.
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.