gamedevlists-windows

[GD-Windows] Un-zips and 3x the storage space

[Jon W. <hp...@mi...>]

When downloading a program from the interwebs, I typically get a 
self-extracting EXE. It creates a number of CAB files and a setup.exe on 
my hard disk. It, in turn, will extract the cabs or msis into the 
install location. This means that I need three times the storage space 
on my hard disk, which for a laptop and modern 4G+ games sometimes is a 
problem (and will be more so once flash drives become commonplace!)

Is there any real reason why you can't bundle all your game assets into 
the .EXE file in the first place? Thus, when downloading, you don't even 
necessarily need an installer (although the Windows model of an 
installer right now pretty much requires at least 2x the storage space). 
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)

If this is feasible, why does nobody do this?

Cheers,

          / h+

-- 
-- Revenge is the most pointless and damaging of human desires.

Re: [GD-Windows] Un-zips and 3x the storage space

[Dan T. <da...@ar...>]

There's already a system for putting resources into EXEs and DLLs, and 
you can access them easily from code. As long as you don't mind your 
resources paging in ala a memory mapped file, its good to go.

The data as I recall is also read-only (not sure?), so if you do any 
pointer patching or whatnot, that might not work. Of course if you are 
just going to unpack to another section of memory, that's moot.

-Dan

Jon Watte wrote:
> When downloading a program from the interwebs, I typically get a 
> self-extracting EXE. It creates a number of CAB files and a setup.exe on 
> my hard disk. It, in turn, will extract the cabs or msis into the 
> install location. This means that I need three times the storage space 
> on my hard disk, which for a laptop and modern 4G+ games sometimes is a 
> problem (and will be more so once flash drives become commonplace!)
>
> Is there any real reason why you can't bundle all your game assets into 
> the .EXE file in the first place? Thus, when downloading, you don't even 
> necessarily need an installer (although the Windows model of an 
> installer right now pretty much requires at least 2x the storage space). 
> 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)
>
> If this is feasible, why does nobody do this?
>
> Cheers,
>
>           / h+
>
>   

Re: [GD-Windows] Un-zips and 3x the storage space

[Alen L. <ale...@cr...>]

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