51–60 of 73 posts
> Apple's .car file > not related to Apple CarPlay
The article is well worth reading even without ingesting the specifics in order to follow the author's reverse engineering process.
> _QWORD *__fastcall Is that WinDOS shit? Anyway, compiling to WASM is smart. Apple can't kill your tools if they're not on the app store. And you don't have to pay Apple tax for giving access to a free tool. Cool project!
Earlier quoted context omitted.
Strong disagree. I like binary formats because I can just fopen(), fseek() and fread() stuff. I don't need json parser dependency, and don't need to deal with compression. Binary formats are simple, fast and I need a way smaller buffer to read/write them normally. I don't like wasting resources.
Binary formats are painful to deal with from user perspective Sane for 3rd party devs
Earlier quoted context omitted.
> 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.
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.
Team manager at NeXT worked on the file format here, AMA
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.
This is cool work. However, the author claims the following: > This knowledge could be useful for security research and building developer tools that does not rely on Xcode or Apple’s proprietary tools. Yes it could be. But if you developed it for such altruistic purposes, why tease the code? > I’m considering open-sourcing these tools, but no promises yet! Maybe OOP is thinking of selling their reverse engineering t…
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.
Looks very much like a format that should just have been gzipped JSON. Don't use binary formats when it isn't absolutely needed.
> 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
Seems a better choice to just parse the files than using private APIs as I couldn't see much of the documentation for them (or rather reversed APIs in various projects) + image handling is weirdly complicated in macOS generally so I want to avoid that.
Currently I've experimented by just recreating the graphics from scratch using vector rendering but it's quite cumbersome.
Other libraries, such as Qt, try to draw the native widgets into offscreen image but it's extremely hacky way prone to GUI breaking with any OS update. Java has their own Apple blessed way, but seems quite limited to me and don't want to depend on that either.