Re: Un-zips and 3x the storage space

Jon wrote:
> After the PE executable data, if I create my own section/sections, could
> I store more than 2 GB or 4 GB of data? Will the OS be unhappy because I
> have such a large image? (I would assume not, given that the 
> self-extractors seem to work fine)

There is no reason to use actual sections. Just "stick" the data to
the end of the executable, using the copy command in the makefile
or in a custom build rule. E.g.:

  copy /b MyGame.exe+MyData.dat Result.exe

The PE loader uses the executable header anyway, so it will ignore the
"junk" at the end of the file.

It is most convenient if MyData.dat is actually a zip file. Zips
already have the tail which says how long the data is and all the Sfx
archives actually work like this.

> If this is feasible, why does nobody do this?

We do this for all our recent downloadable installers (demos, patches
etc.). We unpack directly from the exe into the final install
directory, using our custom installer. As for why MSI or IS don't have
this as an option, I can't believe this kind of sloppiness as well. I
think some other installers do handle this correctly though.

This kind of installers lessens this space problem from 3x to 2x. But
if you want absolutely no copying, there are various practical
reasons, though, why one maybe doesn't want to run directly from
there. E.g. the user might have downloaded this to a temporary
directory which will be deleted, you can't apply patches if you
haven't installed, etc, etc.

JM2C,

Alen


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Gamedevlists-windows mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555