Sorry about late reply, I've only just gotten around to registering an account on this board! :)
Built-in tileinfo resource patching (eg, %tileinfo filename)
That'd be rather easy to add. You'd need to add the tileinfo offset to each of the CX
nPATCH.PAS source files, and make the parser recognise the %tileinfo command (look at CKXPATCH.INC source file around where %egahead, etc are handled). The comments in the source should make it apparent what goes where.
You also need to determine the length of the tileinfo resource in each Keen executable as well, since I added a safety check feature in CKPatch 0.9.0 to prevent oversized files from overwriting neighbouring resources.
Commands for dumping egahead, egadict, etc. (that is, you don't need to remember to locations in the executable to dump them)
This is similar to the above, just make the parser recognise the new syntax additions (look at CKXPATCH.INC). The resource offsets & lengths are all stored in the CX
nPATCH.PAS source files, if you need to know them.
Hmmm, weren't they written in Pascal? I have zero knowledge of that language.
CKPatch is written in Turbo Pascal because it's the only DOS 16-bit real mode compiler that I've got on me.
I can't use DJGPP or any other 32-bit protected mode compiler, because the DOS extender takes away too much conventional memory, preventing the game from running.
Pascal, once you learn it, is much like a "friendlier C". It's still a procedural language, but there are subtle differences in syntax, and certain operations like set logic and string handling are built into the language; it's slightly more higher-level than C.
While adding more features is nice, you have to remember that CKPatch has to have a minimal memory footprint because it has to remain resident while the game runs; this is due to the way DOS likes to allocate memory. If you make the CKPatch executable bigger, by adding more features, then it might break CKPatch for some end users because they won't be able to free up the required conventional memory.
CKPatch already requires about 20kB of overhead. This means that you need 540kB free conventional memory to run Keen 1-3, and 580kB free conventional memory to run Keen 4-6. I'm planning not to increase this overhead any further; so far the current overhead seems to be trouble-free for majority of CKPatch users out there.
Turbo Pascal however adds some bulk overhead for each executable it generates, usually around 2-3kB for the run-time library. Each procedure that calls a function that returns a string also allocates 256 bytes of extra stack space, because of TP's calling conventions. I did some extensive profiling while I was working on CKPatch 0.9.0, and consequently was able to add the new features with only a minimal increase in memory footprint.
If someone was able to rewrite CKPatch in C or pure assembler, then these overheads would dissappear, so you'd get a more compact executable, allowing more room for improvements. However the main setbacks are that I can't seem to find any decent freely available DOS 16-bit C compilers, and writing CKPatch in 100% pure assembler would make code maintenace much more difficult. I hardly have enough free time as it is, getting caught up with uni and all! :)
In conclusion, you're more than welcome to make your own changes to CKPatch, since I've released the source code via GPL. However keep the memory footprint issue, discussed above, in mind. If you make some useful changes, you might like to email them to me and I'll include them for the next release of CKPatch (with appropiate credit).