Bug#869630: game-data-packager: Please add support for Heroes of Might and Magic III

Simon McVittie smcv at debian.org
Tue Jul 25 21:46:46 UTC 2017


On Tue, 25 Jul 2017 at 20:41:49 +0200, Johannes Schauer wrote:
> There is also the Heroes 3 demo as provided by the internet archive:
> 
> https://archive.org/details/HeroesOfMightAndMagicIiiTheRestorationOfErathia
> 
> Unfortunately, getting the right files out of it is currently a bit
> complicated:
> 
> $ dd if=h3demo.exe skip=1 of=h3demo.cab ibs=130731
> $ cabextract -F Disk1/data1.cab h3demo.cab
> $ unshield Disk1/data1.cab
> 
> So the .exe embeds a cab archive which itself contains an InstallShield file
> which then contains the data we want. Is g-d-p able to somehow extract the
> files from the h3demo.exe?

Someone would have to teach game_data_packager.build about cabextract
(we haven't needed that yet), and possibly also about skipping prefixes
of files (but cabextract(1) says it can work on executables containing
an embedded cabinet, so you might not actually need the dd step). At
the moment the only formats for which we've needed "skip X bytes first"
are tar and umod, which we do in Python code that can read from a stream,
rather than by running a separate executable like cabextract.

But once g-d-p knows how to extract cab archives, extracting recursively
is easy. If you give it syntax like this:

files:
  h3demo.exe:
    provides:
      - Disk1/data1.cab
    unpack:
      format: cab       # needs implementing, see above
      skip: 130731      # also needs implementing, see above

  Disk1/data1.cab:
    provides:
      - foo.bar
    unpack:
      format: unshield

and ask it to install foo.bar, it will work out that it has to
extract Disk1/data1.cab from h3demo.exe, then extract foo.bar from
Disk1/data1.cab.

(I'm quite proud of this declarative approach, it works a lot better
than trying to support 210 games with individual shell scripts!)

There are two ways a demo can be packaged: you can either install it
to the same place as the full game, with Conflicts/Replaces (like we
do for Quake 1 shareware), or you can install it to a separate location
and make the game engine or wrapper script try both (like we do for the
Quake 2 demo). We prefer the Quake 2 approach where feasible: it is
usually no better than the Quake 1 approach for actual users, but it
makes life easier for game engine and g-d-p maintainers who want to be
able to test with both versions :-)

    S



More information about the Pkg-games-devel mailing list