The File Objectizer
(Download it here)
This little program solves a nagging problem that I had for quite some time: How to make the content of a file a part of the executable under a Unix-type environment. This is convenient for relatively small amounts of data license agreements, etc.
MS Windows and Mac OS tools have the concept of resources that can be linked with program execution code. I couldn't find anything similar with the GNU tools.
The obvious alternative is to distribute any such file along with the program, and read them at run time, but that implies a number of drawbacks:
- The companion file can get lost. Accidental deletion has occasionally happened in the past
- The program needs file i/o capabilities linked in.
- There must be an agreement where the file is to be found (in the same directory as the program? In the user's home directory? In the system directory? Under a URL? What about differences in directory path descriptions?)
- Access to the data requires file i/o code.
- Your target must have a file system (not always a given for embedded systems).
Making the content of files be part of the program takes care of these issues.
With the objectizer, the content of a file is simply available as a pair of const char* pointers. The first of them points to the start of the text string, the second points to one past the end.
It is then possible to do things like:
for ( const char* p = start ; p != end ; p ++ ){
putc ( *p );
}
The objectizer reads in a file and produces a C source file. That file can be compiled by any C compiler into the object file for any target.
The objectizer is a console application. It expects two arguments: The file to read, and the symbol name to be given to the pointer to the start of the data. The end pointer name is derived from the start pointer name by adding "_e." Its output is produced to stdout and can be re-directed into a file, or, if the compiler allows reading from the standard input, into the compiler directly.
Download the objectizer.
Initially I wanted to write the objectizer in a way that it would read the file and directly produce an object file that can then be input into the linker. Two days into it I was questioning that decision. Consider
- should it be a.out, b.out, coff, elf, or PE format? should it be 32 bits, 64 bits?
- what endianness?
- how many different targets to support (even Microsoft's PE file supports targets like the SPARC processor!)?
You can find out a lot about object files in two days - at least enough to know that there's a lot more to learn..
Instead of creating an object file directly, I found it easier (and better) to build an objectizer that leaves the complexities of making an object file to the tool which is the champion in it - the C compiler.
|
Making our customers successful
