Prev: ANN: Seed7 Release 2010-03-07
Next: The perpetual calendar
From: BGB / cr88192 on 7 Mar 2010 23:47
the text below is from a misc email.
it is an idea I had considered recently, but as of yet have not done much.
I am not sure if anything similar is already in common use.


some later variants on the idea had considered:
really, I don't strictly need a special section, as using pretty much any
section would work (assuming that a scan is done over the entire mapped
image).

other thoughts had considered the possibility of doing something along the
lines of WAD or WAD2 (itself embedded into the EXE with a similar mechanism,
or possibly based on the same mechanism).


----
as for another idle thought, I have another thought WRT adding custom
metadata/... to PE/COFF:
a collection of "chunks" are linked into the image in a special section,
such as ".chunks".

in general, the chunks section is relatively unstructured, but each chunk
could contain a header:
{
FOURCC magic1; //"\x89\n\r\x1A"
FOURCC magic2; //"CHNK"
FOURCC magic3; //payload-fourcc
byte head_size; //base header size
byte head_flags; //base header flags
u16 head_crc; //CRC16 of header
//(16-bytes)
u32 chunk_size; //total chunk size (includes headers)
u32 flags; //chunk flags
//...
}

beyond this, each chunk header would start on a 16-byte boundary (not
difficult, as linkers do this by default).

note that it is likely that some amount of scanning/matching would be used
(this being a major reason for making the header so bulky and including a
CRC).

the idea for how this would get loaded into PE/COFF images would be that the
data would be converted into COFF objects which would be linked into the
image (I am assuming for now a stock linker, such as "link.exe" or
similar...).

I am also considering the possibility of this coexisting with CLR metadata.


now, what sorts of data would be encoded here?...
matadata-DB dumps (maybe a deflated version of a textual dump?... well, it
is that or devise a binary serialization...);
maybe symbolic-linking info (would mostly be used to key the DB against the
binary code/data/... mostly because my main DB does not directly hold
references to code or data);
JVM-style class and jar files;
ZIP files (embedded sub-files, could be accessed via the VFS).

the idea is that any unknown chunks will be ignored by default.


although, I guess it may be worth looking and seeing if there is some other
established convention for doing something similar to this...

however, at present I often store info like this in sideband files, but this
would allow packaging the info directly into the PE/COFF image...

then, an API could be added which could iterate over the chunks, possibly
looking for chunks with a given FOURCC and returning pointers to the
payload, ... (technically, the core functionality for implementing this is
provided by the Win32 API).


don't know if all this is a good idea though...




 | 
Pages: 1
Prev: ANN: Seed7 Release 2010-03-07
Next: The perpetual calendar