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.
