On Sun, 2017-04-09 at 13:12 -0600, Erich E. Hoover wrote:
The "Windows SDK Components for Windows Installer Developers" has a command line tool called msidb that is incredibly useful for creating, editing, and exporting MSI installer databases, think of it as winemsibuilder on steroids. This patch series implements much of the functionality of the msidb tool, maintains compatible CLI flags, and the underlying MSI functionality necessary to support these features. With this patch series all the existing winemsibuilder functionality is available, plus the ability to drop streams, export the _SummaryInformation table, export binary streams (Binary/Icon tables), and some miscellaneous bug fixes. A big feature of the implementation is that it allows you to edit existing installer databases, rather than just creating new ones.
I can see how the extra functionality is useful for package builders but at the same time it's not essential to build Wine. That doesn't mean we can't maintain it in Wine, but I can also see it being part of a separate SDK tools project. Have you considered that?
On Mon, Apr 10, 2017 at 1:53 AM, Hans Leidekker hans@codeweavers.com wrote:
... I can see how the extra functionality is useful for package builders but at the same time it's not essential to build Wine. That doesn't mean we can't maintain it in Wine, but I can also see it being part of a separate SDK tools project. Have you considered that?
Yes, I've actually been using this as a separate project for a few years. There are several of reasons that I think that this is worth including into Wine itself: 1) It allows us to match a documented tool for creating our own installers (gecko, mono), rather than having a custom interface (MSDN provides a lot of documentation on msidb) 2) The ability to easily extract and modify installers is very helpful for doing Wine MSI development 3) I've recently discovered that there are some bugs in Wine's ability to modify MSI databases
I'm mostly interested in #2 and #3, but #1 is a nice side benefit. Discovering #3 is really the "final straw" for me and, while I have not had a chance to find the bug yet, I have found a reproducible test case. Since I rely upon this tool to create that test case, it's somewhat of a prerequisite for both solving the problem and demonstrating to you that it's fixed.
Best, Erich