Uhmmm no, savepos is ok in both the ways since the last file operation was in the "for" cycle (get OFFSET asize isn't a file operation)
You're probably right. I discovered that the tool I was using to visualize the binary content of the files had some cache issue. So it's very probable that after changing the condition the first file was correctly extracted but the tool display the previous content leading me to believe I needed something else to work.
Anyways, I continued trying to decipher the format of the files contained in the archive. Knowing that RES5 stored its XMI files uncompressed, I deducted that the nine first bytes were some sort of header related to the archive (or the program) and after that was the file proper :Offset
0x00 | 0x45 | 'E'
0x01 | 0x48 | 'H'
0x02 | 0x03 | consistent
0x03 | 0x00 | consistent
0x04 | 0x00 | consistent
0x05 | 0xXX | file size
0x06 | 0xXX | file size
0x07 | 0x00 | consistent (file size ?)
0x08 | 0x00 | consistent (file size ?)
The bytes at 0x05-0x06 would give me a UInt16LE whose value is the file size minus 9. The file size might be actually a UInt32LE with the inclusion of bytes 0x07-0x08 but I've not yet seen a file size bigger than 65535.
I tested my assertion with RES6 which actually contains the voice files in format VOC (Creative Voice File) and it worked except for the byte at 0x02 whose value is consistently 0x04 (some sort of file type for the program maybe ?).
However that assertion does not work at all with the archive RES0. Byte 3-4 would either be 0x02 0x08 or 0x01 0x08 and the values at the "size" emplacement would not match at all.
RES1 did also not follow the pattern, its byte 3-4 being mostly 0x01 0x08. However in this file I discovered that the offset table pointed multiple file to the same offset and some of the file only had a 4-bytes length whose value was 0x60 0x00 0x00 0x00 which departed from the "EH" marker.
RES2 did also not follow the pattern, its byte 3-4 being 0x01 0x08.
RES3 did also not follow the pattern, its byte 3-4 being 0x07 0x00.
RES4 did also not follow the pattern, its byte 3-4 being 0x06 0x00.
RES7 did also not follow the pattern, its byte 3-4 being 0x01 0x08.
RES8 did also not follow the pattern, its byte 3-4 being 0x01 0x08.