Re: PakFiles & Portability

[Christian Reiniger <warewolf@mayn.de>]

Jaroslav Benkovsky wrote:

>> >> (2) (almost the same issue as above) Is support for (sym-) links useful?
>> >Useful, yes.  Portable, no. :)
>If we are speaking about PAK files, it is portable.

Right. The file format itself is platform independent.

>> >> 64bit has the advantage of supporting files > 2GB, but implementing 64bit
>> >> values in C portably is a pain in the a**.
>> Well, I'll stick with internal 32bit handling for now...
>
>You can define that in version 1 of PAK files the offset size is 32

The Pak files will have 64 bit offsets, (writing these is no problem on a
32bit system). The decoding functions will handle these offsets as 'long'
(the data type used by fseek () and ftell ()) for now. That's 32 bit on
Linux-gcc-x86.

And that's perfectly ok, as long as the *actual* offsets fit in 32bits. So
the 1st generation code will have no problems handling the 64bit offsets
for Pak files <2Gig.

>bits. It is not probable to see games w/ 2GB+ files often soon. And the
>symlinks may even enable to link several CD's to one (virtual) big

Actually you don't even need symlinks for that, because the Archive
mechanism simulates a "perfectly normal" directory hierarchy (have a look
at the draft on
http://sunsite.auc.dk/penguinplay/PenguinDoc/FileAccess.html
for more info on that.

>file. I hope that there's version info in the format?

Yep. Version info, endianness info, native int size info. You can liberally
mix Pak files generated by bigendian-64bit, littleendian-32bit and
littleendian-64bit systems without having to care.
(Well, of course the formats of the files stored in the Pak files have to
be able to handle that)

Cu
	Christian
--

Where Do You Want To Swap Today?