|appending data to an executable binary email@example.com (2000-04-11)|
|Re: appending data to an executable binary firstname.lastname@example.org (2000-04-14)|
|Re: appending data to an executable binary email@example.com (Joachim Durchholz) (2000-04-14)|
|Re: appending data to an executable binary firstname.lastname@example.org (2000-04-15)|
|From:||"Joachim Durchholz" <email@example.com>|
|Date:||14 Apr 2000 23:49:44 -0400|
> Would this be platform/compiler dependent? Is there
> another/better/any way of tagging a binary _after_ it's been created?
On a Windows platform, there is - though I'm not sure that it will
help you. The standard way to do this on Windows is to insert
resources and later modify them with the appropriate API (I think it's
"imghlp" but I couldn't find the exact function names quickly). This
has the advantage that your information will be protected by the
checksum of the executable. The disadvantage is that it won't work for
Unix, so if you're going multi-platform you'll have to find an
appropriate mechanism for each.
One general advice: while it's technically not a problem to append data
to the end of the executable, it tends to give you problems later, as:
* It's not always possible to determine which file your executing
program was loaded from (in particular on Unix where the user may have
execute permission but no read permission on the binary file).
* Like John, I don't know of any executable format that will give
problems, but some day you may want to port to a machine with a really
braindead format, and you'll be in deep trouble. Sometimes the
run-time system of a language that you interoperate with wants to see
specific information at the end of the executable (this has happened
to me once, years ago under CP/M IIRC).
* You may get into sequencing problems. For example, you may want to
strip debugging symbols from your executable, and depending on the
builtin intelligence of 'strip' this may work or not after you added
your special data. If there is interference, you'll have created a
dependency between make steps; it's generally better to avoid
introducing such dependencies (the more gratuitous dependencies you
have, the greater the likelihood that you'll have to strike some
unfortunate compromises later).
For these reasons, I generally put such data into a file that goes in
the same directory as the executable.
Return to the
Search the comp.compilers archives again.