Hacking Apart Standalone Runtime Binary?
I’ve recently been enamored with the idea of packaging my patches as standalones that are as lean and as far from being an obvious vanilla Max standalone application export as possible – on the OS X side only, for now. (Windows will come later.) Much of my work at this point has been modeled after this presentation:
I’ve also done a fair bit of cutting away at maxinterface.json, in addition to making it the only asset in that folder when you look at the Package Contents of the .app.
I’m wondering how far I can go with this paring away until there’s nothing left but what I need. Taking out the .svg graphics for the Max editing environment (why are those packaged into a Standalone – besides those used in the Max window – in the first place??) took a whopping 10MB out as it was. The program I’ve been experimenting with is very small, and uses nothing outside of Max – no MSP, no Jitter, no Vizzie, no externals, nothing.
What irks me is the 10MB binary. It’s almost the entirety of my remaining filesize. I don’t know enough about building applications (let alone outside of Max) to be able to itemize this in an educated fashion, but I can’t help but feel like this program’s total necessary file assets couldn’t be more than a meg, when taking into consideration the couple of pictures used (and maybe image files used for panel objects?? or is that "drawn" by your GPU…)
Again, at least at this point in my life, I hang out on a pretty high-operating level. So, I guess rather than asking HOW to do this, I’ll just ask the more developmentally savvy people here IF it is hypothetically possible to do this: assuming you’re just using some kind of hex editor front-end, is it possible to just delete cherry-picked large chunks of the runtime binary to pare down anything built into it that I don’t need anymore? Is it all such a soup when built in that form that it’s too sticky to be a surgeon with? Would "cleanly" taking out chunks break seemingly unrelated assets? What HAPPENS when you edit a binary executable?
I suppose I could also start working on the .mxf that’s in the Package Contents, too… that’s a couple of megs, but I don’t know if .mxf’s are still so heavily tied to enumerating every possible object in your installation of Max and holding on to references to them, regardless of whether or not you use them, for example.
Anyone feel like educating me a bit?
The binary is an exact copy of the one you find inside MAX Runtime. Nothing of your patch is part of this. Everything concerning the patch is in the mxf file. The application Textwrangler for example, allows you to view its content as text, and you’ll be able to recognize your patch.
In that sense there is little to do in reducing file size of your custom built. There are however applications like CleanMyMac that allow for removal of unnecessary resources (in my case 108 kb).
+1 about the .svg files: any explanation for these, when the vast majority are not used?
This is just guessing, but I presume there’s not really a reason for it other then that it makes standalones complete in terms of all required resources. The ad, extension, init, interfaces and mididrivers folders simply appear to be copied from the Cycling’74 folder inside the Max application folder, and it’s left up to the developer to remove unused resources.
"The binary is an exact copy of the one you find inside MAX Runtime. Nothing of your patch is part of this. Everything concerning the patch is in the mxf file."
I’m a bit confused about what you mean by this. Do you mean to say that the binary executable is the same every time one exports a standalone because it’s an exact image of Max Runtime with all dependencies and file associations hard-pathed in, without any reference to your patcher other than that it interfaces with the .mxf file? Or do you mean that after building the standalone, the binary executable only constructs resources from what is needed, and therefore there are no "things" left to pare out of it?