The fact that different parts of the file use different endiannesses really added that special Apple tech flavour.
The BOM file format is very, very old - I think for the first decade of its life it actually lived on big-endian platforms (m68k/SPARC/PA-RISC NeXTSTEP, and then over to Apple and big-endian PowerPC.)
EDIT - someone needs to crack open x86 OPENSTEP and do some grepping for 'RATC'...
At this point if a file format could have rounded corners I’m sure it would too.
"You're holding it wrong", but in binary.
Claude is pretty good at turning (dis)assembly into Objective-C. i went exploring these systems looking for the secrets of glass icon rendering. i used ipsw to unpack all the class metadata in relevant system private frameworks. for each class, i extracted class header/interface, and a assembly file per method in the header. i wrote a ruby script to shell out to claude cli with a custom system prompt to give me readable-ish obj-c. It struggled with some patterns but with code as string-dispatch method-call-heavy as obj-c there’s lots of good hints for the ai.
i learned a lot about lldb debugging when i went spelunking through system service process memory. eventually i got too distracted learning about runtime introspection in Swift and obj-c and ended up building a dynamic object explorer/debugger instead of accomplishing my original goal. obj-c runtime dynamism is fascinating. it’s like, “what if we make C as dynamic as Ruby”. you can invent new classes at runtime, swap method implementations, create a new class that extends a specific existing object. you can even change what class an object is.
Swift is a lot less dynamic and a lot less introspectable at runtime :-( (there is a swift reflection api called Mirror but i struggled to do anything interesting with it)
> obj-c runtime dynamism is fascinating. it’s like, “what if we make C as dynamic as Ruby”.
Well thats because objc and ruby are cousins. Both are sort of the only two smalltalk based languages out there
> Well thats because objc and ruby are cousins. Both are sort of the only two smalltalk based languages out there
I'm sure you can trace connections, at least in ideas, but I think Ruby is way more Perl-based than Smalltalk-based.
Im talking the fundamental language framework. 'Everything is an object' and method calls are actually message passing are the two reasons that objc and ruby are actually smalltalks.
I’ve tried to explain this before and unless you’re steeped in late binding, encapsulation, and message passing, the details are lost on most people (it seems including modern language designers).
For the GP, in most languages the dot or arrow operator is field access. If that field is a function reference, parenthesis are used to invoke it.
From outside of the object, neither Ruby or Objective-C allow direct access to object fields or functions. The dot operator sends the object a message that be bound to anything, and even rebound at runtime for specific instances. There is no difference between access and property and calling a function - it’s all messages. Smalltalk and Objective-C (before dot operators) don’t even have different syntax for data fields and functions calls. Ruby’s no arg messages are similar.
Most of the time that distinction doesn’t matter. But writing things like wrappers and proxies becomes trivial. A object can forward any message it receives, and if it sees on it wants to intercept, it can do that easily. Most of the time modifying existing programs and frameworks can be as easy as rebinding some logic to something that wasn’t part of the original program.
This comes at the cost of some runtime performance, and possibly some complexity. The elegance outweighs those, imho.
>The dot operator sends the object a message that be bound to anything
Modern obj-c "dot notation" + properties + synthesized ivars add a lot of syntactic sugar that make things more confusing, if you go back to original obj-c where it was just ivars and explicit getters/setters, things are a lot easier to understand.
Do you feel like the current Apple engineering orgs either don’t understand the philosophy that came from NeXT or has the world changed and some of those choices are no longer possible?
For example, until a decade ago, macOS was extremely scriptable and consistent. IB was flexible, but approachable. There were few specialized frameworks, but a lot was possible with just Cocoa. Now it seems like dynamism at the programming level is frowned upon, scripting and automation require constant user permission, Swift seems to favor performance over dynamism, and it seems like any new concepts are now all relegated to their own framework.
Not the GP but a lot of application level scriptability came from AppleScript/Apple Events which was a MacOS thing and not from NeXT. There was a ton of work that went into adding Apple Events support into AppKit (it was already baked into Carbon) which gave Cocoa applications a level of "free" scriptability. Same with UI scripting. Just adding AppleScript names, I forget the exact terminology now, to a UI control made it accessible via AppleScript.
That never existed in iOS and as UIKit was merged into macOS that old support was never added back in. AFAIK the Shortcuts system uses a totally different automation mechanism for scripting applications.
For a lot of applications, especially ones that started life in the classic MacOS days, AppleScript automation was pretty amazing. You could easily tie very disparate applications together.
The application level automation was orthogonal to the use of Objective-C or even Cocoa.
Source: I was at Apple from 2004-2020 and did a lot with automation over the years while there.
What was it really like working at NeXT? Was there always a sense that you were building what would ideally become Mac OS X, or was that plan held close to the vest? Any cool or memorable Steve Jobs stories? What was with the greyscale debut?