| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
This begins a programme of code reorganisation at the end of which I'd
like to end up with something almost legible :-)
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This is pretty ugly code, but it works well enough to deliver the
right versions for the files in my test MSI. I can polish it later.
|
| | |
|
| |
|
|
|
| |
But I haven't tested it yet, so it's probably got a zillion things
wrong inside it.
|
| | |
|
| |
|
|
|
| |
Now I can get an idea of what sequence of calls WiX actually expects
to use to build an MSI.
|
|
|
This seems to be the next function WiX expects from its native-code
DLLs. So far it's just a stub.
|
