A mirror of https://git.tartarus.org/simon/wix-on-linux.git https://git.lua4.win/wix-on-linux/atom?h=main 2023-08-18T07:29:32+00:00 2023-08-18T07:29:32+00:00 Simon Tatham anakin@pobox.com 2023-08-18T07:29:32+00:00 urn:sha1:3ed828da1b7ff1992b345fac6ce15787a03befad 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'. 2020-08-26T20:13:29+00:00 Simon Tatham anakin@pobox.com 2020-08-26T20:13:29+00:00 urn:sha1:558d8cf7cd971c024a1eee0221e0dc1c952039f0 2018-05-14T17:14:12+00:00 Simon Tatham anakin@pobox.com 2018-05-14T17:14:12+00:00 urn:sha1:1c1c3850e8a54938f41afb5e49a9176b229a3a88 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. 2017-06-07T05:39:21+00:00 Simon Tatham anakin@pobox.com 2017-06-07T05:39:21+00:00 urn:sha1:66f1f5d2bff9900a62db381c8718acb1982f4753 2017-05-28T09:00:03+00:00 Simon Tatham anakin@pobox.com 2017-05-28T09:00:03+00:00 urn:sha1:0bc12e1c6704b1d34bebcf54770ee1a6434c3880 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. 2017-05-28T08:54:05+00:00 Simon Tatham anakin@pobox.com 2017-05-28T08:54:05+00:00 urn:sha1:fe5eb01f9b84b344bd1d476f409626fd7b4cd5f9 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. 2017-05-18T18:01:01+00:00 Simon Tatham anakin@pobox.com 2017-05-18T18:01:01+00:00 urn:sha1:f501b2927d7e4bf6b26c1e348270e6f4a48ffb27 2017-05-18T18:00:07+00:00 Simon Tatham anakin@pobox.com 2017-05-18T18:00:07+00:00 urn:sha1:5e1f0d7e9fb3b05c5867c57c9dfee0363441feae 2017-05-18T17:50:08+00:00 Simon Tatham anakin@pobox.com 2017-05-18T17:50:08+00:00 urn:sha1:8574dcc8c56971345a688a61a8d2022f4cc000cc 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. 2017-05-18T17:49:35+00:00 Simon Tatham anakin@pobox.com 2017-05-18T17:49:35+00:00 urn:sha1:2cab25bf140eff04aef44b87e5a2ac791cc74c30 I did these in passing while looking for the bug in the previous commit, and they seem like general improvements, so I'll keep them.