Following on from what was discovered in Unpicking XCom .cat files, here is stuff about an actual utility to have a look at the things!

Writing it for Linux so far, as of course that's what I use- note that that isn't as perverse as it may sound, as I'm perfectly able to run UFO under the dosemu emulator (or I was, until I had to temporarily uninstall it during an upgrade. I've not put it back yet, but will probably do soon), and it's quite plausible the source could be recompiled for DOS or Windows too, whether through DJGPP or Mingw32 or Cygwin, or through Microsoftish compilers.

Notes

Firstly, knowing the format of those start/length records in the main header of the file, doesn't necessarily tell us how many of those there are. However, we can surely assume that there's no more after the first subheader/subfile. So the reasonable interpretation would be that the first subheader/subfile is the boundary for the main header. It's also strictly possible (however unlikely) that the records may be given in a different order to the occurrence of the subfiles themselves, so maybe eg the 3rd file described in the header, occurrs at the first address.

We can deal with both this eventuality, and the annoyance of otherwise having to treat the first record differently to the rest, by simply maintaining a minimum start address seen variable, to act as the boundary.

Functions

The obvious thing we want is to extract the subfiles, but we could probably do a few other things too.

One thing we could do is view what the names are on each of the subfiles, eg "Geoscape1", "0", "1", "nowt"...

Another thing we could do, very handy if making a conversion or wanting to hack at it, is build a new catfile- for this, as none of the subfiles in the sample.cat file have unique names, we must probably use something other than the filenames to determine the names of the subfiles. One obvious approach would be to have the files to be packed in each have a numbered filename to determine where in the catfile it goes, and then give a separate list describing what the names associated are, with the first line being the first subfile's name, etc.. Another similar approach would be that the list file has pairs of fields on each line- first the filename to go in, then the name to use for it, separated by a space. Again the line number determines the subfile number in the catfile. Not sure which is preferable.

For actually extracting the subfiles, we could have 2 methods: Firstly just extracting a single one, specified by number, in which case it prints the name used and writes the file out to uh, not sure where. Perhaps a file based on the name used, but that could be problematic. Second method, it extracts everything. When it does this, it might be desirable to do it in a way that's compatible with the repacking system, so it could manage this 2 ways:

• It extracts the files to filenames based on the index number of the subfiles, possibly into a subdirectory for tidiness, and prints out to another file, a list giving the names used. The list file could be in a standard place I guess. Maybe the subdirectory could be a standard name too, but that could cause problems if maintaining a separate "original" and "new" version. Eh.
• You tell it a specific list file to work with, that has the mappings of filename to name, again with the linenumber of each corresponding to the index number of the subfiles. This would work with the specified repacking method given above, but the list has to be made by hand, and what happens if there's the wrong number of items in it? It's a nuisance too.

So I think that the filenames in either case should be based on the index number, and the extractor can produce the list file that's readable by the repacker. The only argument you have to pass it is what the subdirectory name is for it all.

OTOH the version with filenames specified by hand would mean you could see what you're putting in there a bit clearer I suppose, but eh. Perhaps you could maintain a separate file for those purposes, or do it with symlinks (on Linux at least).

Versions

Have only just started, have a few lines of code so far, just to read the TOC, but that works at least. Have tested it on sample.cat and adlib.cat, got correct results out.

Nothing to download yet. Bear with me.