Someone on https://github.com/wixtoolset/issues/issues/4381 found this
repository recently and judged it to be abandoned, whereas in fact
it's been working reliably for me for nearly a decade and I just don't
have to fix bugs in it very often.
Looking at the README, I wonder if the reason they thought it was
abandoned is that _that_ hadn't been updated in a very long time! It
still said 'very new', 'only ever tested on Ubuntu 14.04' (which was
true at the beginning of the project's life), and 'only supports
Python 2' (an outright untruth).
I've brought it up to date, and made it look more like 'stable' than
'abandoned immediately after creation'.
Upgrading to Ubuntu 18.04, which seems to have become more prone to
allocating process memory above the 4G boundary, has revealed that the
client code of the phony msi.dll functions is not in fact prepared to
accept arbitrary machine-word sized pointer values. It's expecting
32-bit handles, so we were segfaulting because MsiDatabaseImportW was
only being given the bottom 32 bits of the 64-bit pointer that
MsiOpenDatabaseW had returned.
So now I just keep a trivial registry of small integer handle values
and the pointers they map to. I don't even bother to recycle them -
the process isn't expected to run for long enough for me to care.
I made the mistake of using the same variable name _offset for the
temporary variable in WORD16 and WORD32, and for the one in BYTE which
the other two use as a subroutine - meaning that the declaration on
the first line of BYTE read 'size_t _offset = _offset+3' or similar,
in which the RHS _offset referred to the newly declared LHS one rather
than to the one in the outer scope.
WORD32 had the additional goof that I had declared its return-value
accumulator variable as a 16- rather than 32-bit integer due to
copy-and-paste error.
Between those two mistakes - surely introduced at the last minute when
I was doing code cleanup on this source base, because I know this
function was working OK before then - I had completely broken the
extraction of version strings from PE executables.
At the moment it only tests MsiGetFileVersion, because that's the
piece I just found a problem in, but I could easily extend it to have
convenient command-line test rigs for other parts of this setup too.
I don't know why those strange names seemed necessary to start with
and now don't seem to be. I probably changed something subtle
somewhere without noticing.
It's now a sensible source flie containing a set of routines that do
something coherently connected to each other, so it doesn't deserve
that 'fake-' prefix that I used for the previous monolithic files full
of tangled-together stuff.
While I'm here, I've also made up nicer (i.e. more distinguishable)
random magic numbers for the structure-type disambiguation.
This sets up $WIX and $LD_PRELOAD before running a Wix .NET executable
via mono, so the user doesn't have to have pre-prepared those
variables (and, in particular, libpreload doesn't uncontrolledly
affect loads of other stuff too).
We have to define $WIX in any case for libpreload, so we might as well
get our money's worth out of it and not also require the Wix directory
to be on PATH.
[MS-CAB] is pretty unclearly worded in this area. Turns out that if
the sequence of bytes being checksummed is not a multiple of 4 bytes,
you are supposed to _first_ reverse the order of the trailing (n % 4)
bytes, and _then_ append zero bytes to pad to a multiple of 4, before
you do the main checksum operation of XORing together all the 32-bit
words of the input.
I had expected that if you were returning a failure code you didn't
have to - perhaps even _shouldn't_ - write through the output pointer
arguments. But in fact, now that my implementation of
MsiGetFileVersion _knows_ how to fail (i.e. doesn't just return a
hardcoded value for every call), the MSI build doesn't work unless I
also clear the output strings in the case of failure.
A quick experiment or two with the real Windows version suggests that
the hash function in question is just MD5, repackaged as an array of
four little-endian 32-bit words instead of 16 bytes.
lcab produces uncompressed CAB files, which is a bit low-quality for
my taste - especially when it turns out CAB files have Deflate as one
of their compression options, so I can write a compressed CAB-builder
in only about 100 lines of Python using the zlib module! I'd expected
to have to faff about finding an implementation of LZX, but there's
really no need to bother.
Apart from dependency on native-code DLLs, the one other quirk of
running WiX under mono is that it doesn't seem to quite get the right
answers when combining $PWD with a Unix absolute path to one of its
own supporting files - it doesn't interpret the leading slash on the
latter as meaning $PWD should be ignored, so it tries to look for
/home/my/build/dir/home/my/wix/install/dir/some.file. Previously I was
bodging around that by having my build dir contain a symlink 'home'
pointing at /home; this is marginally less intrusive.
In my test MSI, the files are supposed to be in alphabetical order,
not in 'whatever order lcab enumerated the Unix directory I pointed it
at' order. The test MSI didn't install, but with this change, it does,
so my guess is that either the real Windows installer system depends
on the alphabetical order for a search algorithm, or else files in the
cab are referred to by a numeric index of some kind.
If I compile this to Linux native code, and then run WiX under Mono,
it loads this library and gets past the first CabExtract call, so I
can find out what the next problem turns out to be.
