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

21–30 of 73 posts

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

#21

Post by trashb »

silvestrov wrote: post #2

Looks very much like a format that should just have been gzipped JSON. Don't use binary formats when it isn't absolutely needed.

Every format is binary in the end, you are just swapping out the separators.

I personally subscribe to the Unix philosophy. There are really two options, binary or plain text (readable binary due to a agreed standard formatting). All other formats are a variation of the two.

Additional a binary format suits makes sense when the format is to be used for mobile devices which may not have much storage or bandwidth.

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

#25

Post by jasode »

silvestrov wrote: post #2

Looks very much like a format that should just have been gzipped JSON. Don't use binary formats when it isn't absolutely needed.

>Looks very much like a format that should just have been gzipped JSON.

For application file formats that require storing binary blob data such as images, bitmaps, etc , many in the industry have settled on "SQLite db as a file format": (https://www.sqlite.org/appfileformat.html)

Examples include Mozilla Firefox using sqlite db for favicons, Apple iOS using sqlite to store camera photos, Kodi media player uses sqlite for binary metadata, Microsoft Visual C++ IDE stores source code browsing data in sqlite, etc.

Sqlite db would usually be a better choice rather than binary blobs encoded as Base64 and being stuffed into json.gzip files. One of the areas where the less efficient gzipped JSON might be better than Sqlite is web-server-to-web-browser data transfers because the client's Javascript engine has builtin gzip decompress and JSON manipulation functions.

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

#26

Post by mort96 »

silvestrov wrote: post #6
mort96 wrote: post #4

Earlier quoted context omitted.

Uh. You want to store assets in JSON? Why? You generally want asset packs to be seekable so that you can extract just one asset, and why would you want to add the overhead of parsing potentially gigabytes of JSON and then, per asset, decoding potentially tens of megabytes of base64?

Keep all the meta info in JSON and then the big binary files in a zip file. Much easier to parse.

Easier for the developer or easier for the computer?

Computers need to do it a bunch for every program launch for every single user of macOS for decades. The developer just needed to write a generator and a parser for the format once.

Would it have been a bit easier to write a parser for a format that's based around a zip file with a manifest.json? I don't know, maybe. You'd end up with some pretty huge dependencies (a zip file reader, a JSON parser), but maybe it'd be slightly easier. Is it worth it?

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

#27

Post by mort96 »

embedding-shape wrote: post #8
mort96 wrote: post #4

Earlier quoted context omitted.

Uh. You want to store assets in JSON? Why? You generally want asset packs to be seekable so that you can extract just one asset, and why would you want to add the overhead of parsing potentially gigabytes of JSON and then, per asset, decoding potentially tens of megabytes of base64?

> You want to store assets in JSON? Why? Why not have both options? .gltf and .glb being possible for assets been more than helpful to me more than once, having the option gives you the best of both worlds :)

What's Apple's incentive for having two different asset pack formats? It seems like more work to support parsing and generating both, and Apple expects you to use their tools to generate asset packs.

Working with binary files really isn't that hard. If Apple documented the .car format, writing your own parser wouldn't be difficult. It's not like it's a complicated format. Still, Apple clearly doesn't intend for people to make their own .car generators; to them, ease of reverse engineering is a bug, not a feature.

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

#29

Post by orbital-decay »

lpcvoid wrote: post #11
empiricus wrote: post #10

Idea: pass the decompiled code through a "please rename variables according to their purpose" step using a coding agent. Not ideal, but arguably better than v03, v20. And almost zero effort at this time and age.

And have it hallucinate stuff? Nah, this stuff is hard enough without LLMs guessing.

It's a labeling task with benign failure modes, much better suited for an LLM compared to generation
Post reply on HN