Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A deep dive into Apple's .car file format

dbg.re

Post reply on HN
Print view View original

61–70 of 73 posts

Re: A deep dive into Apple's .car file format

#61

Post by giantrobot »

jonhohle wrote: post #57
crandyboy wrote: post #49

Team manager at NeXT worked on the file format here, AMA

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 progra…

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.

Re: A deep dive into Apple's .car file format

#62

Post by mrexcess »

crandyboy wrote: post #49

Team manager at NeXT worked on the file format here, AMA

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?

Re: A deep dive into Apple's .car file format

#63

Post by lelandfe »

mwkaufma wrote: post #54

Originally read "BOM (Bill of Materials)" and thought it was a misattribution of the more common "Byte Order Marker" acronym common to file format headers, but websurfing reveals it's correct -- referring to this format's origin in Installers, haha.

$ man bom

> bom – bill of materials

[..]

> HISTORY

> The bill of materials file appeared in NeXTSTEP to support installation. The file format was updated and extended for Mac OS X 10.0. The format was extended to support 64 bit file sizes with OS X 10.3.

Re: A deep dive into Apple's .car file format

#64

Post by streetfighter64 »

coderatlarge wrote: post #59
streetfighter64 wrote: post #41

Earlier quoted context omitted.

> Don't use binary formats when it isn't absolutely needed. JSON in particular isn't very good [0] but I'd also argue that text formats in general aren't great. Isn't it a lot better that an int32_t always takes exactly 4 bytes instead of anywhere between one and eleven bytes (-2147483648)? [0] https://news.ycombinator.com/item?id=40555431

one use-case is if you need to be able to stream the data.

One use-case of what? Whether a format is "streamable" is entirely orthogonal to whether it is text or binary. Streamability depends on other things such as if it has a header or checksum at the end, et cetera.

Re: A deep dive into Apple's .car file format

#65

Post by [deleted] »

jitl wrote: post #14

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 reada…

[deleted]

Re: A deep dive into Apple's .car file format

#66

Post by skrebbel »

worldsavior wrote: post #58
skrebbel wrote: post #16

Earlier quoted context omitted.

I'm not sure it's about money. This maybe be increasingly hard to imagine in this age of AI-slop, but some devs actually don't want to publish code that is a terribly embarrassing mess, and prefer to clean it up first.

There is nothing bad with messy code unless you work with a team. Showing that you coded messy code doesn't make you a bad coder.

I know, but not everybody knows or agrees with this. The idea that when someone doesn't put their code online it must be because they want money seems way off the mark to me, and that's the only point I was making.

Re: A deep dive into Apple's .car file format

#67

Post by mwkaufma »

lelandfe wrote: post #63
mwkaufma wrote: post #54

Originally read "BOM (Bill of Materials)" and thought it was a misattribution of the more common "Byte Order Marker" acronym common to file format headers, but websurfing reveals it's correct -- referring to this format's origin in Installers, haha.

$ man bom > bom – bill of materials [..] > HISTORY > The bill of materials file appeared in NeXTSTEP to support installation. The file format was updated and extended for Mac OS X 10.0. The format was extended to support 64 bit file sizes with OS X 10.3.

orly

  $ man bom
  No manual entry for bom

Re: A deep dive into Apple's .car file format

#68

Post by lelandfe »

mwkaufma wrote: post #67
lelandfe wrote: post #63

Earlier quoted context omitted.

$ man bom > bom – bill of materials [..] > HISTORY > The bill of materials file appeared in NeXTSTEP to support installation. The file format was updated and extended for Mac OS X 10.0. The format was extended to support 64 bit file sizes with OS X 10.3.

orly $ man bom No manual entry for bom

rly. Ran on two different Macs. Works up to Tahoe 26.2.

Maybe depends on developer tools installed?

Re: A deep dive into Apple's .car file format

#69

Post by mwkaufma »

lelandfe wrote: post #68
mwkaufma wrote: post #67

Earlier quoted context omitted.

orly $ man bom No manual entry for bom

rly. Ran on two different Macs. Works up to Tahoe 26.2. Maybe depends on developer tools installed?

Is the feedback that instead of a short web search, I could "simply" have checked the man page on a different computer, after confirming dev tools are installed?

Re: A deep dive into Apple's .car file format

#70

Post by krackers »

jonhohle wrote: post #56
JamesSwift wrote: post #48

Earlier quoted context omitted.

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…

>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.

Post reply on HN