6 ms·

One missing approach is just appending the binary data to the end of the file, and then reading the resource from /proc/self/exe on Linux (or the equivalents on

One missing approach is just appending the binary data to the end of the file, and then reading the resource from /proc/self/exe on Linux (or the equivalents on Mac and Windows). It's not "portable" per-se, but all modern platforms [1] have a way to interrogate the binary contents of the currently-running executable. [1] _NSGetExecutablePath, GetModuleFileName(), getexecname() etc EDIT: Apparently https://github.com/gpakosz/whereami https://github.com/gpakosz/whereami will manage a lot of this complexity for you

naasking 4y ago
And on microcontrollers where embedded binaries are essential?
- duskwuff 4y ago
  Most microcontrollers run code directly from flash memory -- there's no "executable file" (or, indeed, any files) involved at all.
  - naasking 4y ago
    The lack of files is exactly the point. Any kind of blobs need to be bundled with the compiled code in a -defined and preferably portable way, and this is the domain where it's used the most. The way the OP described just doesn't work in that context. We had a recent thread about the new #embed which does this properly and portably.
anyfoo 4y ago
Don't do this, it's ugly and relies on assumptions that aren't true. I haven't checked each spec, but it is very unlikely that your ELF/mach-O/PE/... is still valid with added junk at the end. You may try it out and it may work, but that is true for many things that may come back to bite you (or others) in spectacular ways.
- fabian2k 4y ago
  I'd be interested in any example where this approach would produce an invalid executable. I have used this without issues, but of course I have certainly not tried this in every possible environment.
  - anyfoo 4y ago
    Computing history is chock full of examples where something "seems to work" but is actually invalid (and a mach-O treated that way would be invalid [EDIT: or just "not accepted" by some parts of the system, see below], whether it runs or not), and then Raymond Chen has to write a blog post about it decades later. Here's just one out of many as a random example: https://devblogs.microsoft.com/oldnewthing/20041026-00/?p=37473 https://devblogs.microsoft.com/oldnewthing/20041026-00/?p=37... Back to this particular case, the binary will fail strict code signing validation on macOS. It may still run because the kernel does not access the binary past the coverage of the code signature (and all the bits there are still intact), similar to how multiarch binaries work, but you will at least severely be hampered to distribute your binary, since Gatekeeper won't be happy either.
- dmitrygr 4y ago
  > it is very unlikely that your ELF/mach-O/PE/... is still valid with added junk at the end. I've written loaders for all of the executable formats you mentioned, and maybe a dozen more. I know of none where this would violate the strict interpretation of the word of the spec. That being said, valid file != happy OS
  - anyfoo 4y ago
    Agreed. As above: It may for example run, but not be accepted by other parts of the OS (as evidenced).

naasking 4y ago

And on microcontrollers where embedded binaries are essential?

duskwuff 4y ago
Most microcontrollers run code directly from flash memory -- there's no "executable file" (or, indeed, any files) involved at all.
- naasking 4y ago
  The lack of files is exactly the point. Any kind of blobs need to be bundled with the compiled code in a -defined and preferably portable way, and this is the domain where it's used the most. The way the OP described just doesn't work in that context. We had a recent thread about the new #embed which does this properly and portably.

anyfoo 4y ago

Don't do this, it's ugly and relies on assumptions that aren't true. I haven't checked each spec, but it is very unlikely that your ELF/mach-O/PE/... is still valid with added junk at the end. You may try it out and it may work, but that is true for many things that may come back to bite you (or others) in spectacular ways.

fabian2k 4y ago
I'd be interested in any example where this approach would produce an invalid executable. I have used this without issues, but of course I have certainly not tried this in every possible environment.
- anyfoo 4y ago
  Computing history is chock full of examples where something "seems to work" but is actually invalid (and a mach-O treated that way would be invalid [EDIT: or just "not accepted" by some parts of the system, see below], whether it runs or not), and then Raymond Chen has to write a blog post about it decades later. Here's just one out of many as a random example: https://devblogs.microsoft.com/oldnewthing/20041026-00/?p=37473 https://devblogs.microsoft.com/oldnewthing/20041026-00/?p=37... Back to this particular case, the binary will fail strict code signing validation on macOS. It may still run because the kernel does not access the binary past the coverage of the code signature (and all the bits there are still intact), similar to how multiarch binaries work, but you will at least severely be hampered to distribute your binary, since Gatekeeper won't be happy either.
dmitrygr 4y ago
> it is very unlikely that your ELF/mach-O/PE/... is still valid with added junk at the end. I've written loaders for all of the executable formats you mentioned, and maybe a dozen more. I know of none where this would violate the strict interpretation of the word of the spec. That being said, valid file != happy OS
- anyfoo 4y ago
  Agreed. As above: It may for example run, but not be accepted by other parts of the OS (as evidenced).