Good aritcle, gave me some ideas. I thought I would share how I developed my resource file system a couple years ago. Might give other people some more ideas. My approach was far simpler. Basically, I made wrappers for the basic file i/o functions. fopen, fclose, fseek, ftell, etc. Calling my OpenLibrary function would load in a list from the "lump info table". Then OpenFile would open the library, seek to the file position and return an file pointer which you could use in the normal way (this has it''s advantages, as it is easy to adapt existing PCX/JPG loaders, etc). I used the actual filenames for IDs (8.3 files at the time). If you didn''t call OpenLibrary, all subsequent calls to OpenFile would pass through and just open the actual file. A plus for development. One other difference, is that my merge utility determined the number of files it was dealing with in advance, and reserved the right amount of space at the top of the file so my "lump info table" was stored directly below the header. In a write-once, read-many situtation this may be better... but I''m not sure what would be best if one wanted to handle patching the resource file. Anyway, I plan to create a new system... mainly to deal with long filenames and to use dwords for offsets, lengths, etc. The idea of including all the functions (including to save stuff to the resource file) in a single API is good. I''m not sure if I want to do the whole "loader handler" thing though. If anyone else has some ideas, please post to this forum... thanks. - n8