nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
b26077b1ae
putty-source/windows/installer.wxs

613 lines
30 KiB
Plaintext
Raw Normal View History

New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<?xml version="1.0" encoding="utf-8"?>
<!-- WiX source code for the PuTTY installer. -->
Build MSI installers for Arm Windows. I expected this to be nightmarish because WiX 3 doesn't know about the Windows on Arm platform at all. Fortunately, it turns out that it doesn't have to: testing on a borrowed machine I find that Windows on Arm's msiexec.exe is quite happy to take MSIs whose platform field in the _SummaryInformation table says "Intel". In fact, that seemed to be _all_ that my test machine would accept: I tried taking the MSI apart with msidump, putting some other value in there (e.g. "Arm64" or "Arm") and rebuilding it with msibuild, and all I got was messages from msiexec saying "This installation package is not supported by this processor type." So in fact I just give WiX the same -arch x86 option that I give it for the real 32-bit x86 Windows installer, but then I point it at the Arm binaries, and that seems to produce a viable MSI. There is the unfortunate effect that msiexec forcibly sets the default install location to 'Program Files (x86)' no matter how I strive to make it set it any other way, but that's only cosmetic: the programs _run_ just fine no matter which Program Files directory they're installed into (and I know this won't be the first piece of software that installs itself into the wrong one). Perhaps some day we can find a way to do that part better. On general principles of caution (and of not really wanting to force Arm machines to emulate x86 code at all), the Arm versions of the installers have the new DllOk=no flag, so they're pure MSI with no embedded DLLs.
2018-05-31 18:31:20 +00:00
<?if $(var.RealPlatform) = x64 ?>
MSI installer: add version info to product name. This appears to be conventional, and the full version info for builds like development snapshots is not visible elsewhere in Control Panel.
2017-02-16 10:08:14 +00:00
<?define Bitness = " (64-bit)" ?>
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
<?define RegKeyPathLocation = "Software\SimonTatham\PuTTY64" ?>
Build MSI installers for Arm Windows. I expected this to be nightmarish because WiX 3 doesn't know about the Windows on Arm platform at all. Fortunately, it turns out that it doesn't have to: testing on a borrowed machine I find that Windows on Arm's msiexec.exe is quite happy to take MSIs whose platform field in the _SummaryInformation table says "Intel". In fact, that seemed to be _all_ that my test machine would accept: I tried taking the MSI apart with msidump, putting some other value in there (e.g. "Arm64" or "Arm") and rebuilding it with msibuild, and all I got was messages from msiexec saying "This installation package is not supported by this processor type." So in fact I just give WiX the same -arch x86 option that I give it for the real 32-bit x86 Windows installer, but then I point it at the Arm binaries, and that seems to produce a viable MSI. There is the unfortunate effect that msiexec forcibly sets the default install location to 'Program Files (x86)' no matter how I strive to make it set it any other way, but that's only cosmetic: the programs _run_ just fine no matter which Program Files directory they're installed into (and I know this won't be the first piece of software that installs itself into the wrong one). Perhaps some day we can find a way to do that part better. On general principles of caution (and of not really wanting to force Arm machines to emulate x86 code at all), the Arm versions of the installers have the new DllOk=no flag, so they're pure MSI with no embedded DLLs.
2018-05-31 18:31:20 +00:00
<?else ?>
<?define Bitness = "" ?>
<?define RegKeyPathLocation = "Software\SimonTatham\PuTTY" ?>
<?endif ?>
<?if $(var.RealPlatform) = x86 ?>
<?define InstallerVersion = "100" ?>
Fix platform field in Windows on Arm installers. I had previously left the platform field (in line 7 of the installer database's SummaryInformation table) set at "x86" instead of any value you might expect such as "Arm" or "Arm64", because I found that an MSI file with either of the latter values was rejected by WoA's msiexec as invalid. It turns out this is because I _also_ needed to upgrade the installer database schema version to a higher value than I even knew existed: apparently the problem is that those platform fields aren't present in the older schema. A test confirms that this works. Unfortunately, WiX 3 doesn't actually know _how_ to write MSIs with those platform values. But that's OK, because diffing the x86 and x64 MSIs against each other suggested that there were basically no other changes in the database tables - so I can just generate the installer as if for x64, and then rewrite that one field after installer construction using GNOME msitools to take apart the binary file structure and put it back together. (Those are the same tools I'm using as part of my system for running WiX on Linux in the first place.) This commit introduces a script to do that post-hoc bodging, and calls it from Buildscr. I've also changed over the choice of Program Files folder for the Arm installers so that it's ProgramFiles64Folder instead of ProgramFilesFolder - so now the Windows on Arm installer doesn't incongruously default to installing in C:\Program Files (x86)!
2018-08-16 18:01:36 +00:00
<?define PlatformProgramFilesFolder = "ProgramFilesFolder" ?>
<?elseif $(var.RealPlatform) = x64 ?>
Build MSI installers for Arm Windows. I expected this to be nightmarish because WiX 3 doesn't know about the Windows on Arm platform at all. Fortunately, it turns out that it doesn't have to: testing on a borrowed machine I find that Windows on Arm's msiexec.exe is quite happy to take MSIs whose platform field in the _SummaryInformation table says "Intel". In fact, that seemed to be _all_ that my test machine would accept: I tried taking the MSI apart with msidump, putting some other value in there (e.g. "Arm64" or "Arm") and rebuilding it with msibuild, and all I got was messages from msiexec saying "This installation package is not supported by this processor type." So in fact I just give WiX the same -arch x86 option that I give it for the real 32-bit x86 Windows installer, but then I point it at the Arm binaries, and that seems to produce a viable MSI. There is the unfortunate effect that msiexec forcibly sets the default install location to 'Program Files (x86)' no matter how I strive to make it set it any other way, but that's only cosmetic: the programs _run_ just fine no matter which Program Files directory they're installed into (and I know this won't be the first piece of software that installs itself into the wrong one). Perhaps some day we can find a way to do that part better. On general principles of caution (and of not really wanting to force Arm machines to emulate x86 code at all), the Arm versions of the installers have the new DllOk=no flag, so they're pure MSI with no embedded DLLs.
2018-05-31 18:31:20 +00:00
<?define InstallerVersion = "200" ?>
Fix platform field in Windows on Arm installers. I had previously left the platform field (in line 7 of the installer database's SummaryInformation table) set at "x86" instead of any value you might expect such as "Arm" or "Arm64", because I found that an MSI file with either of the latter values was rejected by WoA's msiexec as invalid. It turns out this is because I _also_ needed to upgrade the installer database schema version to a higher value than I even knew existed: apparently the problem is that those platform fields aren't present in the older schema. A test confirms that this works. Unfortunately, WiX 3 doesn't actually know _how_ to write MSIs with those platform values. But that's OK, because diffing the x86 and x64 MSIs against each other suggested that there were basically no other changes in the database tables - so I can just generate the installer as if for x64, and then rewrite that one field after installer construction using GNOME msitools to take apart the binary file structure and put it back together. (Those are the same tools I'm using as part of my system for running WiX on Linux in the first place.) This commit introduces a script to do that post-hoc bodging, and calls it from Buildscr. I've also changed over the choice of Program Files folder for the Arm installers so that it's ProgramFiles64Folder instead of ProgramFilesFolder - so now the Windows on Arm installer doesn't incongruously default to installing in C:\Program Files (x86)!
2018-08-16 18:01:36 +00:00
<?define PlatformProgramFilesFolder = "ProgramFiles64Folder" ?>
<?else ?>
<?define InstallerVersion = "500" ?>
<?define PlatformProgramFilesFolder = "ProgramFiles64Folder" ?>
Build MSI installers for Arm Windows. I expected this to be nightmarish because WiX 3 doesn't know about the Windows on Arm platform at all. Fortunately, it turns out that it doesn't have to: testing on a borrowed machine I find that Windows on Arm's msiexec.exe is quite happy to take MSIs whose platform field in the _SummaryInformation table says "Intel". In fact, that seemed to be _all_ that my test machine would accept: I tried taking the MSI apart with msidump, putting some other value in there (e.g. "Arm64" or "Arm") and rebuilding it with msibuild, and all I got was messages from msiexec saying "This installation package is not supported by this processor type." So in fact I just give WiX the same -arch x86 option that I give it for the real 32-bit x86 Windows installer, but then I point it at the Arm binaries, and that seems to produce a viable MSI. There is the unfortunate effect that msiexec forcibly sets the default install location to 'Program Files (x86)' no matter how I strive to make it set it any other way, but that's only cosmetic: the programs _run_ just fine no matter which Program Files directory they're installed into (and I know this won't be the first piece of software that installs itself into the wrong one). Perhaps some day we can find a way to do that part better. On general principles of caution (and of not really wanting to force Arm machines to emulate x86 code at all), the Arm versions of the installers have the new DllOk=no flag, so they're pure MSI with no embedded DLLs.
2018-05-31 18:31:20 +00:00
<?endif ?>
<?if $(var.RealPlatform) = x64 ?>
<?define ProductNameSuffix = " (64-bit)" ?>
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
<?define UpgradeCode_GUID = "C9EAA861-2B72-4FAF-9FEE-EEB1AD5FD15E" ?>
<?define PuTTY_Component_GUID = "C673C970-25AE-4659-9621-A1FE0598E9DC" ?>
<?define Pageant_Component_GUID = "BA37328A-9A9C-4912-B84D-9C4A21B4E79A" ?>
<?define PSFTP_Component_GUID = "8BC2740F-CD4A-4076-8C33-2847ECA17B4E" ?>
<?define PuTTYgen_Component_GUID = "4E3F554E-C9C9-419B-9816-94135D1F6EFF" ?>
<?define Plink_Component_GUID = "72C38830-1C06-40D5-B2C5-BE21F4C9D529" ?>
<?define PSCP_Component_GUID = "58FCAA52-CEF9-4665-B95E-7695FCF8F0A9" ?>
<?define HelpFile_Component_GUID = "B880CECB-2CDA-4DB1-8EB3-1627D29394FB" ?>
<?define Website_Component_GUID = "08A334E8-D376-438A-98C7-4E65BE09A335" ?>
<?define LICENCE_Component_GUID = "D15E5FA9-C912-4F7A-A663-9FE3CFD5FB01" ?>
<?define README_Component_GUID = "B8F2F9DE-0311-436E-86A4-BEFED84968C0" ?>
<?define PPK_Assoc_Component_GUID = "70B4360C-7A2E-4C9E-9135-289C5467CB04" ?>
<?define Path_Component_GUID = "A0CFC986-489D-452B-8A8F-F9DBEF6916F4" ?>
<?define ProgramMenuDir_GUID = "3B2B7A2B-25F1-4EC4-987F-75BFD038632E" ?>
<?define Desktop_Shortcut_Component_GUID = "0A715416-EA6E-4A1C-8670-838307083EE5" ?>
Build MSI installers for Arm Windows. I expected this to be nightmarish because WiX 3 doesn't know about the Windows on Arm platform at all. Fortunately, it turns out that it doesn't have to: testing on a borrowed machine I find that Windows on Arm's msiexec.exe is quite happy to take MSIs whose platform field in the _SummaryInformation table says "Intel". In fact, that seemed to be _all_ that my test machine would accept: I tried taking the MSI apart with msidump, putting some other value in there (e.g. "Arm64" or "Arm") and rebuilding it with msibuild, and all I got was messages from msiexec saying "This installation package is not supported by this processor type." So in fact I just give WiX the same -arch x86 option that I give it for the real 32-bit x86 Windows installer, but then I point it at the Arm binaries, and that seems to produce a viable MSI. There is the unfortunate effect that msiexec forcibly sets the default install location to 'Program Files (x86)' no matter how I strive to make it set it any other way, but that's only cosmetic: the programs _run_ just fine no matter which Program Files directory they're installed into (and I know this won't be the first piece of software that installs itself into the wrong one). Perhaps some day we can find a way to do that part better. On general principles of caution (and of not really wanting to force Arm machines to emulate x86 code at all), the Arm versions of the installers have the new DllOk=no flag, so they're pure MSI with no embedded DLLs.
2018-05-31 18:31:20 +00:00
<?elseif $(var.RealPlatform) = x86 ?>
<?define ProductNameSuffix = "" ?>
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
<?define UpgradeCode_GUID = "DCE70C63-8808-4646-B16B-A677BD298385" ?>
<?define PuTTY_Component_GUID = "07ACF511-6DF6-4883-AABA-33BC14901324" ?>
<?define Pageant_Component_GUID = "649F963E-21C4-4755-8CE4-D80598DCEE6D" ?>
<?define PSFTP_Component_GUID = "3D7B9536-EC0E-4A6A-A3DF-8D285474391A" ?>
<?define PuTTYgen_Component_GUID = "4774F6B3-8A07-42A5-9F4D-E7FE6AA78B84" ?>
<?define Plink_Component_GUID = "7D96F9BB-4154-49D6-86AE-0D8F1379ACBC" ?>
<?define PSCP_Component_GUID = "71519D4A-3ED5-4A46-A7E4-B6E4600A8684" ?>
<?define HelpFile_Component_GUID = "72806A73-9D4D-49BF-8CAA-E90B0D83AEED" ?>
<?define Website_Component_GUID = "7DAD6536-C1A7-430C-BC8A-90176CCB78D0" ?>
<?define LICENCE_Component_GUID = "6AB710C0-F7A1-4B7A-AC2E-6993D6E98332" ?>
<?define README_Component_GUID = "0AB63F2A-0FD9-4961-B8F7-AB85C22D9986" ?>
<?define PPK_Assoc_Component_GUID = "13BBF036-F4C0-4F5B-9167-7BA35C673AAB" ?>
<?define Path_Component_GUID = "D1F68AAA-D20D-4047-828F-D0AC443FAF64" ?>
<?define ProgramMenuDir_GUID = "C12C3BB3-EC24-4883-8349-4AC8017C9E6A" ?>
<?define Desktop_Shortcut_Component_GUID = "D039E3D1-CE42-488D-96CC-90E1DE3796F8" ?>
Build MSI installers for Arm Windows. I expected this to be nightmarish because WiX 3 doesn't know about the Windows on Arm platform at all. Fortunately, it turns out that it doesn't have to: testing on a borrowed machine I find that Windows on Arm's msiexec.exe is quite happy to take MSIs whose platform field in the _SummaryInformation table says "Intel". In fact, that seemed to be _all_ that my test machine would accept: I tried taking the MSI apart with msidump, putting some other value in there (e.g. "Arm64" or "Arm") and rebuilding it with msibuild, and all I got was messages from msiexec saying "This installation package is not supported by this processor type." So in fact I just give WiX the same -arch x86 option that I give it for the real 32-bit x86 Windows installer, but then I point it at the Arm binaries, and that seems to produce a viable MSI. There is the unfortunate effect that msiexec forcibly sets the default install location to 'Program Files (x86)' no matter how I strive to make it set it any other way, but that's only cosmetic: the programs _run_ just fine no matter which Program Files directory they're installed into (and I know this won't be the first piece of software that installs itself into the wrong one). Perhaps some day we can find a way to do that part better. On general principles of caution (and of not really wanting to force Arm machines to emulate x86 code at all), the Arm versions of the installers have the new DllOk=no flag, so they're pure MSI with no embedded DLLs.
2018-05-31 18:31:20 +00:00
<?elseif $(var.RealPlatform) = Arm ?>
<?define ProductNameSuffix = " (32-bit Arm)" ?>
<?define UpgradeCode_GUID = "B8E49D4D-7C56-400D-85B4-DF953C227207" ?>
<?define PuTTY_Component_GUID = "207B46FA-0554-4DB4-AA87-F85464FA065E" ?>
<?define Pageant_Component_GUID = "F20A76A8-C4D5-4447-A345-C52F437BDEDC" ?>
<?define PSFTP_Component_GUID = "F868395D-2135-419B-AB97-B782D7FBA468" ?>
<?define PuTTYgen_Component_GUID = "FC558E64-D17D-4297-8694-92F5284965FF" ?>
<?define Plink_Component_GUID = "E2ECE65F-4D41-4B17-AF24-A90B6649E732" ?>
<?define PSCP_Component_GUID = "5C6A332C-9D9C-4097-94DB-995994B29B51" ?>
<?define HelpFile_Component_GUID = "9C666B10-5F6F-41D3-AFF3-F746DB785CF5" ?>
<?define Website_Component_GUID = "C520868B-9EC8-4CEC-B740-40D947F23928" ?>
<?define LICENCE_Component_GUID = "14A5A99F-C347-4D6B-8E3F-2B7297D94C64" ?>
<?define README_Component_GUID = "E1C9357C-7524-4B8B-A2AE-6FB9A1B4AE0B" ?>
<?define PPK_Assoc_Component_GUID = "8A1E556E-8E39-465E-BAE5-9E112F7DCBFD" ?>
<?define Path_Component_GUID = "425860FA-B31E-440E-99AD-C2CCFC195092" ?>
<?define ProgramMenuDir_GUID = "0F2F67F1-FB69-4D0F-8A7F-A6BA2CD79F00" ?>
<?define Desktop_Shortcut_Component_GUID = "63CA2A72-4B56-4207-9E2B-1FC4E3C883AE" ?>
<?elseif $(var.RealPlatform) = Arm64 ?>
<?define ProductNameSuffix = " (64-bit Arm)" ?>
<?define UpgradeCode_GUID = "2125AD39-A960-4377-AD41-99E50D842AE5" ?>
<?define PuTTY_Component_GUID = "43A61725-EC31-4F8C-8BF3-3C988E53185B" ?>
<?define Pageant_Component_GUID = "8D36F326-F1BC-42E4-AC42-925449782B5A" ?>
<?define PSFTP_Component_GUID = "E3C7B364-35F9-4B25-A0FB-B86B4E4949EE" ?>
<?define PuTTYgen_Component_GUID = "BE5F4873-152E-477B-B8F8-2F7FDD6186BC" ?>
<?define Plink_Component_GUID = "46382105-49C3-4B59-B250-C889F03BD73E" ?>
<?define PSCP_Component_GUID = "CB738CC0-7F19-457B-9B32-A3665E0E46CB" ?>
<?define HelpFile_Component_GUID = "F5170725-418F-448B-A9F2-C484E43E1C56" ?>
<?define Website_Component_GUID = "87D4BA0A-0DDC-4D82-A58A-F32B4E9B898F" ?>
<?define LICENCE_Component_GUID = "AAD0A8B0-FAB0-4712-87F9-336FEF2629BF" ?>
<?define README_Component_GUID = "9D20B714-5E8A-40A3-AE65-DFE21C2270C9" ?>
<?define PPK_Assoc_Component_GUID = "B967F31F-25C6-4586-B042-DA7E448BA773" ?>
<?define Path_Component_GUID = "12E0B4AA-C8AF-4917-AFB5-DD8143A1A784" ?>
<?define ProgramMenuDir_GUID = "A9C3DFD6-682F-4B9F-B6AE-B2FFA8050CB5" ?>
<?define Desktop_Shortcut_Component_GUID = "8999BBE1-F99E-4301-B7A6-480C19DE13B9" ?>
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
<?endif ?>
Configurable CHM path in installer source. At the moment, it assumes the CHM lives in ../doc, which won't always be true once we start doing out-of-tree builds of the documentation.
2021-05-03 15:21:26 +00:00
<?ifndef HelpFilePath ?>
<?define HelpFilePath = "../doc/putty.chm" ?>
<?endif ?>
MSI installer: add version info to product name. This appears to be conventional, and the full version info for builds like development snapshots is not visible elsewhere in Control Panel.
2017-02-16 10:08:14 +00:00
<?define ProgramName = "PuTTY$(var.Bitness)" ?>
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<!--
Product tag. The Id component is set to "*", which causes WiX to
make up a new GUID every time it's run, whereas UpgradeCode is
set to a fixed GUID. This combination allows Windows to
recognise each new PuTTY installer as different (because of Id)
versions of the same underlying thing (because of the common
UpgradeCode).
$(var.Winver) is define on candle.exe's command line by the
build script, and is expected to be a dotted tuple of four
16-bit decimal integers (similar to a Windows VERSIONINFO
resource). For PuTTY's particular conventions, see comment in
Buildscr.
-->
<Product
Build MSI installers for Arm Windows. I expected this to be nightmarish because WiX 3 doesn't know about the Windows on Arm platform at all. Fortunately, it turns out that it doesn't have to: testing on a borrowed machine I find that Windows on Arm's msiexec.exe is quite happy to take MSIs whose platform field in the _SummaryInformation table says "Intel". In fact, that seemed to be _all_ that my test machine would accept: I tried taking the MSI apart with msidump, putting some other value in there (e.g. "Arm64" or "Arm") and rebuilding it with msibuild, and all I got was messages from msiexec saying "This installation package is not supported by this processor type." So in fact I just give WiX the same -arch x86 option that I give it for the real 32-bit x86 Windows installer, but then I point it at the Arm binaries, and that seems to produce a viable MSI. There is the unfortunate effect that msiexec forcibly sets the default install location to 'Program Files (x86)' no matter how I strive to make it set it any other way, but that's only cosmetic: the programs _run_ just fine no matter which Program Files directory they're installed into (and I know this won't be the first piece of software that installs itself into the wrong one). Perhaps some day we can find a way to do that part better. On general principles of caution (and of not really wanting to force Arm machines to emulate x86 code at all), the Arm versions of the installers have the new DllOk=no flag, so they're pure MSI with no embedded DLLs.
2018-05-31 18:31:20 +00:00
Name="$(var.Puttytextver)$(var.ProductNameSuffix)"
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
Manufacturer="Simon Tatham"
Id="*"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
UpgradeCode="$(var.UpgradeCode_GUID)"
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
Language="1033" Codepage="1252" Version="$(var.Winver)">
<!--
Windows installer: restore InstallScope setting. This reverts commit 0615767224a5a5234b1916d45eca29cec1fe4a59 ("Windows installer: remove explicit InstallScope setting"), albeit with different comments. The original change worked around a Windows security vulnerability (CVE-2023-21800), but also resulted in a rather broken installer.
2023-03-17 16:48:19 +00:00
We force the install scope to perMachine, largely because I
don't really understand how to make it usefully switchable
between the two. If anyone is a WiX expert and does want to
install PuTTY locally in a user account, I hope they'll send a
well explained patch!
(Leaving InstallScope unset produces an installer that
superficially appears to work in some cases, but often fails
to do some of its work.)
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
$(var.Puttytextver) is again defined on the candle command
line, and describes the version of PuTTY in human-readable
form, e.g. "PuTTY 0.67" or "PuTTY development snapshot [foo]".
-->
<Package Id="*" Keywords="Installer"
Description="$(var.Puttytextver) installer"
Manufacturer="Simon Tatham"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
InstallerVersion="$(var.InstallerVersion)" Languages="1033"
Windows installer: restore InstallScope setting. This reverts commit 0615767224a5a5234b1916d45eca29cec1fe4a59 ("Windows installer: remove explicit InstallScope setting"), albeit with different comments. The original change worked around a Windows security vulnerability (CVE-2023-21800), but also resulted in a rather broken installer.
2023-03-17 16:48:19 +00:00
Compressed="yes" SummaryCodepage="1252"
InstallScope="perMachine" />
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<!--
Permit installing an arbitrary one of these PuTTY installers
over the top of an existing one, whether it's an upgrade or a
downgrade. In particular, this makes it easy to switch between
trunk development snapshots and a release or prerelease, in
cases where you change your mind about whether you want the
features or the stability.
Setting the REINSTALLMODE property to "amus" (from its default
of "omus") forces every component replaced by a different
version of the installer to be _actually_ reinstalled; the 'o'
flag in the default setting breaks the downgrade case by
causing Windows to disallow installation of an older version
over the top of a newer one - and to do so _silently_, so the
installer claims to have worked fine but putty.exe isn't
there.
-->
<MajorUpgrade AllowDowngrades="yes" MigrateFeatures="yes" />
<Property Id="REINSTALLMODE" Value="amus"/>
<!-- Boilerplate -->
<Media Id="1" Cabinet="putty.cab" EmbedCab="yes" />
<!--
The actual directory structure and list of 'components'
(individual files or shortcuts or additions to PATH) that are
installed.
We install directly under "Program Files\PuTTY" rather than
the recommended three-level pathname including a manufacturer.
It's bad enough that I put my name irrevocably in everyone's
Registry without putting it in all of their filesystems as
well...
-->
<Directory Id="TARGETDIR" Name="SourceDir">
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
<Directory Id="$(var.PlatformProgramFilesFolder)" Name="PFiles">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<Directory Id="INSTALLDIR" Name="PuTTY">
<!--
The following components all install things in the main
install directory (implicitly, by being nested where
they are in the XML structure). Most of them also put a
shortcut in a subdir of the Start menu, though some of
the more obscure things like LICENCE are just there for
the sake of being _somewhere_ and don't rate a shortcut.
-->
<Component Id="PuTTY_Component"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Guid="$(var.PuTTY_Component_GUID)">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<File Id="PuTTY_File"
Do the Windows build in a subdirectory windows/build32. Uses the BUILDDIR mechanism I added to Makefile.vc in commit d3db17f3e. This change is purely internal to Buildscr, and shouldn't affect the output of a build. It paves the way to have Buildscr run multiple Windows builds using different compilers, by putting each one in a different subdirectory so that their outputs don't collide.
2017-01-21 14:55:47 +00:00
Source="$(var.Builddir)putty.exe" KeyPath="yes">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<Shortcut Id="startmenuPuTTY" Directory="ProgramMenuDir"
WorkingDirectory="INSTALLDIR"
Set our explicit AppUserModelID on our Start Menu shortcut. This is apparently the other half of what we should have done when we called SetCurrentProcessExplicitAppUserModelID at run time: it associates to PuTTY's Start Menu shortcut the same identifier that we give to the running PuTTY process, so that jump lists saved under the latter will be visible to users mousing over the former. I've also done the same thing to the desktop shortcut, just in case that does anything useful.
2017-02-23 18:24:11 +00:00
Name="PuTTY" Advertise="no">
<!-- Set AppUserModelId to match what PuTTY sets at runtime.
Source for the GUID key:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd391569(v=vs.85).aspx
via http://stackoverflow.com/questions/2820983/ -->
<ShortcutProperty
Key="{9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3}, 5"
Value="SimonTatham.PuTTY" />
</Shortcut>
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
</File>
</Component>
<Component Id="Pageant_Component"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Guid="$(var.Pageant_Component_GUID)">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<File Id="Pageant_File"
Do the Windows build in a subdirectory windows/build32. Uses the BUILDDIR mechanism I added to Makefile.vc in commit d3db17f3e. This change is purely internal to Buildscr, and shouldn't affect the output of a build. It paves the way to have Buildscr run multiple Windows builds using different compilers, by putting each one in a different subdirectory so that their outputs don't collide.
2017-01-21 14:55:47 +00:00
Source="$(var.Builddir)pageant.exe" KeyPath="yes">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<Shortcut Id="startmenuPageant" Directory="ProgramMenuDir"
WorkingDirectory="INSTALLDIR"
Name="Pageant" Advertise="no" />
</File>
</Component>
<Component Id="PSFTP_Component"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Guid="$(var.PSFTP_Component_GUID)">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<File Id="PSFTP_File"
Do the Windows build in a subdirectory windows/build32. Uses the BUILDDIR mechanism I added to Makefile.vc in commit d3db17f3e. This change is purely internal to Buildscr, and shouldn't affect the output of a build. It paves the way to have Buildscr run multiple Windows builds using different compilers, by putting each one in a different subdirectory so that their outputs don't collide.
2017-01-21 14:55:47 +00:00
Source="$(var.Builddir)psftp.exe" KeyPath="yes">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<Shortcut Id="startmenuPSFTP" Directory="ProgramMenuDir"
WorkingDirectory="INSTALLDIR"
Name="PSFTP" Advertise="no" />
</File>
</Component>
<Component Id="PuTTYgen_Component"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Guid="$(var.PuTTYgen_Component_GUID)">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<File Id="PuTTYgen_File"
Do the Windows build in a subdirectory windows/build32. Uses the BUILDDIR mechanism I added to Makefile.vc in commit d3db17f3e. This change is purely internal to Buildscr, and shouldn't affect the output of a build. It paves the way to have Buildscr run multiple Windows builds using different compilers, by putting each one in a different subdirectory so that their outputs don't collide.
2017-01-21 14:55:47 +00:00
Source="$(var.Builddir)puttygen.exe" KeyPath="yes">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<Shortcut Id="startmenuPuTTYgen" Directory="ProgramMenuDir"
WorkingDirectory="INSTALLDIR"
Name="PuTTYgen" Advertise="no" />
</File>
</Component>
<Component Id="Plink_Component"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Guid="$(var.Plink_Component_GUID)">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<File Id="Plink_File"
Do the Windows build in a subdirectory windows/build32. Uses the BUILDDIR mechanism I added to Makefile.vc in commit d3db17f3e. This change is purely internal to Buildscr, and shouldn't affect the output of a build. It paves the way to have Buildscr run multiple Windows builds using different compilers, by putting each one in a different subdirectory so that their outputs don't collide.
2017-01-21 14:55:47 +00:00
Source="$(var.Builddir)plink.exe" KeyPath="yes" />
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
</Component>
<Component Id="PSCP_Component"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Guid="$(var.PSCP_Component_GUID)">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<File Id="PSCP_File"
Do the Windows build in a subdirectory windows/build32. Uses the BUILDDIR mechanism I added to Makefile.vc in commit d3db17f3e. This change is purely internal to Buildscr, and shouldn't affect the output of a build. It paves the way to have Buildscr run multiple Windows builds using different compilers, by putting each one in a different subdirectory so that their outputs don't collide.
2017-01-21 14:55:47 +00:00
Source="$(var.Builddir)pscp.exe" KeyPath="yes" />
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
</Component>
<Component Id="HelpFile_Component"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Guid="$(var.HelpFile_Component_GUID)">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<File Id="HelpFile_File"
Configurable CHM path in installer source. At the moment, it assumes the CHM lives in ../doc, which won't always be true once we start doing out-of-tree builds of the documentation.
2021-05-03 15:21:26 +00:00
Source="$(var.HelpFilePath)" KeyPath="yes">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<Shortcut Id="startmenuManual" Directory="ProgramMenuDir"
Name="PuTTY Manual"
Advertise="no" />
</File>
Stop looking for putty.chm alongside the binary. With this change, we stop expecting to find putty.chm alongside the executable file. That was a security hazard comparable to DLL hijacking, because of the risk that a malicious CHM file could be dropped into the same directory as putty.exe (e.g. if someone ran PuTTY from their browser's download dir).. Instead, the standalone putty.exe (and other binaries needing help) embed the proper CHM file within themselves, as a Windows resource, and if called on to display the help then they write the file out to a temporary location. This has the advantage that if you download and run the standalone putty.exe then you actually _get_ help, which previously didn't happen! The versions of the binaries in the installer don't each contain a copy of the help file; that would be extravagant. Instead, the installer itself writes a registry entry pointing at the proper help file, and the executables will look there. Another effect of this commit is that I've withdrawn support for the older .HLP format completely. It's now entirely outdated, and supporting it through this security fix would have been a huge pain.
2019-01-26 20:26:09 +00:00
<RegistryValue Root="HKLM"
Key="$(var.RegKeyPathLocation)\CHMPath"
Type="string" Value="[#HelpFile_File]"/>
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
</Component>
Stop looking for putty.chm alongside the binary. With this change, we stop expecting to find putty.chm alongside the executable file. That was a security hazard comparable to DLL hijacking, because of the risk that a malicious CHM file could be dropped into the same directory as putty.exe (e.g. if someone ran PuTTY from their browser's download dir).. Instead, the standalone putty.exe (and other binaries needing help) embed the proper CHM file within themselves, as a Windows resource, and if called on to display the help then they write the file out to a temporary location. This has the advantage that if you download and run the standalone putty.exe then you actually _get_ help, which previously didn't happen! The versions of the binaries in the installer don't each contain a copy of the help file; that would be extravagant. Instead, the installer itself writes a registry entry pointing at the proper help file, and the executables will look there. Another effect of this commit is that I've withdrawn support for the older .HLP format completely. It's now entirely outdated, and supporting it through this security fix would have been a huge pain.
2019-01-26 20:26:09 +00:00
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<Component Id="Website_Component"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Guid="$(var.Website_Component_GUID)">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<File Id="Website_File"
Source="website.url" KeyPath="yes">
<Shortcut Id="startmenuWebsite" Directory="ProgramMenuDir"
Name="PuTTY Web Site"
Advertise="no" />
</File>
</Component>
<Component Id="LICENCE_Component"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Guid="$(var.LICENCE_Component_GUID)">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<File Id="LICENCE_File"
Use / in pathnames in the Wix installer source. I've also been experimenting recently with running Wix on Linux under Mono, rather than running it on Windows in the obvious way. Wix under Mono insists on forward slashes in pathnames, and it turns out that Wix on Windows doesn't object to them either, so I can safely change them over unconditionally and then my installer source will work in both modes.
2017-05-25 07:22:22 +00:00
Source="../LICENCE" KeyPath="yes" />
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
</Component>
<Component Id="README_Component"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Guid="$(var.README_Component_GUID)">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<File Id="README_File"
Provide a separate post-install README for MSI. The old README.txt instructed you to manually update PATH if you wanted to run pscp from a command prompt. But the MSI installer can do that automatically, so the wording needs tweaks. And now that we're actually launching README (at least optionally) from the installer UI, it's more important to not make it look silly.
2016-04-02 07:22:12 +00:00
Source="README-msi.txt" Name="README.txt" KeyPath="yes" />
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
</Component>
<!--
This component sets up the file associations for the
.ppk private key file extension: right-clicking should
give options to launch both Pageant and PuTTYgen with a
given key.
Unlike all the above components, this one also puts a
registry entry in HKEY_LOCAL_MACHINE, which is the 'key
path' for the component, i.e. the thing Windows checks
to know whether this component is installed. Those have
to be either files or registry entries; so for all the
above things the key paths are the actual files we
wanted to install, whereas for this one we have to
invent a spurious extra thing to be the key path.
-->
<Component Id="PPK_Assoc_Component"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Guid="$(var.PPK_Assoc_Component_GUID)">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<ProgId Id="PPK_Assoc_ProgId"
Description="PuTTY Private Key File">
<Extension Id="ppk"
ContentType="application/x-putty-private-key">
<Verb Id="open" Command="Load into Pageant"
TargetFile="Pageant_File" Argument='"%1"'/>
<Verb Id="edit" Command="Edit with PuTTYgen"
TargetFile="PuTTYgen_File" Argument='"%1"' />
</Extension>
</ProgId>
<RegistryValue Root="HKLM"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Key="$(var.RegKeyPathLocation)\PPKAssociation"
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
Type="string" Value="" KeyPath="yes" />
</Component>
<!--
This component appends the install directory to PATH, so
that command prompt windows automatically get the
ability to run the command-line utilities (PSCP, PSFTP
and Plink, though all the others are available too if
you want). Again, it needs a pointless registry entry to
act as a key path.
-->
<Component Id="Path_Component"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Guid="$(var.Path_Component_GUID)">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<Environment Id="Path_Environment"
Name="PATH"
Value="[INSTALLDIR]"
Permanent="no"
Part="last"
Action="set"
System="yes"/>
<RegistryValue Root="HKLM"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Key="$(var.RegKeyPathLocation)\PathEntry"
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
Type="string" Value="" KeyPath="yes" />
</Component>
</Directory>
</Directory>
<!--
This component doesn't actually install anything, but it
arranges for the Start Menu _directory_ to be removed again
on uninstall. All the actual shortcuts inside the directory
are placed by code above here.
-->
<Directory Id="ProgramMenuFolder" Name="Programs">
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
<Directory Id="ProgramMenuDir" Name="$(var.ProgramName)">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<Component Id="ProgramMenuDir"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Guid="$(var.ProgramMenuDir_GUID)">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<RemoveFolder Id="ProgramMenuDir" On="uninstall" />
<RegistryValue Root="HKLM"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Key="$(var.RegKeyPathLocation)\StartMenu"
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
Type="string" Value="" KeyPath="yes" />
</Component>
</Directory>
</Directory>
<!--
This component puts a shortcut to PuTTY itself on the
desktop.
-->
<Directory Id="DesktopFolder" Name="Desktop">
<Component Id="Desktop_Shortcut_Component"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Guid="$(var.Desktop_Shortcut_Component_GUID)">
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<Shortcut Id="DesktopPuTTY"
WorkingDirectory="INSTALLDIR" Target="[INSTALLDIR]putty.exe"
Set our explicit AppUserModelID on our Start Menu shortcut. This is apparently the other half of what we should have done when we called SetCurrentProcessExplicitAppUserModelID at run time: it associates to PuTTY's Start Menu shortcut the same identifier that we give to the running PuTTY process, so that jump lists saved under the latter will be visible to users mousing over the former. I've also done the same thing to the desktop shortcut, just in case that does anything useful.
2017-02-23 18:24:11 +00:00
Name="$(var.ProgramName)" Advertise="no">
<!-- Set AppUserModelId to match what PuTTY sets at
runtime. I don't know if this does anything directly
useful on the desktop version of the shortcut, but we
might as well keep it consistent with the Start Menu
version in case someone starts manually moving or
copying shortcuts around. -->
<ShortcutProperty
Key="{9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3}, 5"
Value="SimonTatham.PuTTY" />
</Shortcut>
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<RegistryValue Root="HKLM"
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
Key="$(var.RegKeyPathLocation)\DesktopEntry"
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
Type="string" Value="" KeyPath="yes" />
</Component>
</Directory>
</Directory>
<!--
Detect an installation of PuTTY made by the old Inno Setup
installer, and refuse to run if we find one. I don't know what
would happen if you tried anyway, but since they install files
at the same pathnames, it surely wouldn't end well.
It could be argued that a better approach would be to actually
_launch_ the Inno Setup uninstaller automatically at this
point (prompting the user first, of course), but I'm not
nearly skilled enough with WiX to know how, or even if it's
feasible.
-->
<Property Id="LEGACYINNOSETUPINSTALLERNATIVE32PROPERTY">
<RegistrySearch
Id="LegacyInnoSetupInstallerNative32RegSearch"
Root="HKLM"
Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\PuTTY_is1"
Name="QuietUninstallString" Type="raw" />
</Property>
<Property Id="LEGACYINNOSETUPINSTALLER32ON64PROPERTY">
<RegistrySearch
Id="LegacyInnoSetupInstaller32On64RegSearch"
Root="HKLM"
Key="SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\PuTTY_is1"
Name="QuietUninstallString" Type="raw" />
</Property>
<Condition Message="A version of PuTTY is already installed on this system using the old Inno Setup installer. Please uninstall that before running the new installer.">
<![CDATA[Installed OR
(LEGACYINNOSETUPINSTALLERNATIVE32PROPERTY = "" AND
LEGACYINNOSETUPINSTALLER32ON64PROPERTY = "")]]>
</Condition>
<!--
Separate the installation into 'features', which are parts of
the install that can be chosen separately.
Since PuTTY is tiny, I haven't bothered to separate the actual
_files_ into features; I've just put them all in a single
feature that's always installed. The only features that are
separately disableable are the auxiliary ones for desktop
shortcuts, .PPK file extension and modifying PATH.
MSI installer: turn the desktop icon off by default. I rushed out the MSI in too much of a hurry to sort out this kind of thing, but now we've got leisure to reconsider, I think it's better behaviour not to clutter everyone's desktops unless specifically asked to.
2016-04-02 07:00:17 +00:00
DesktopFeature (the desktop icon) is disabled by default, on
the basis of not cluttering up desktops too much unless
someone actually wants it. The .PPK association and PATH are
behind-the-scenes sorts of thing, so they're on by default.
(The old Inno Setup installer also made it optional whether
PuTTY got a Start Menu subfolder. That seems to be harder in
WiX, because the Start Menu shortcuts are tied in to the
installation of the files themselves, so the Start Menu
subfolder is mandatory if you're using this installer at all.
That doesn't seem unreasonable to me - if you don't want
_that_, you might as well just unpack the zip file and not
bother with an installer at all.)
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
-->
<Feature Id="FilesFeature" Level="1" Absent="disallow" AllowAdvertise="no"
Title="Install PuTTY files">
<ComponentRef Id="PuTTY_Component" />
<ComponentRef Id="Pageant_Component" />
<ComponentRef Id="PSFTP_Component" />
<ComponentRef Id="PuTTYgen_Component" />
<ComponentRef Id="Plink_Component" />
<ComponentRef Id="PSCP_Component" />
<ComponentRef Id="HelpFile_Component" />
<ComponentRef Id="Website_Component" />
<ComponentRef Id="LICENCE_Component" />
<ComponentRef Id="README_Component" />
<ComponentRef Id="ProgramMenuDir" />
</Feature>
MSI installer: turn the desktop icon off by default. I rushed out the MSI in too much of a hurry to sort out this kind of thing, but now we've got leisure to reconsider, I think it's better behaviour not to clutter everyone's desktops unless specifically asked to.
2016-04-02 07:00:17 +00:00
<Feature Id="DesktopFeature" Level="2" Absent="allow" AllowAdvertise="no"
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
Title="Add shortcut to PuTTY on the Desktop">
<ComponentRef Id="Desktop_Shortcut_Component" />
</Feature>
<Feature Id="PathFeature" Level="1" Absent="allow" AllowAdvertise="no"
Title="Put install directory on the PATH for command prompts">
<ComponentRef Id="Path_Component" />
</Feature>
<Feature Id="PPKFeature" Level="1" Absent="allow" AllowAdvertise="no"
Title="Associate .PPK files with PuTTYgen and Pageant">
<ComponentRef Id="PPK_Assoc_Component" />
</Feature>
<!--
Installer user interface.
WiX provides several pre-cooked UIs, but annoyingly, every
single one of them has the wrong combination of features for
what I want. For example, WixUI_InstallDir lets me select the
install directory, but not the feature set. WixUI_Advanced
lets me select both, but also insists on giving me the option
of per-user vs systemwide install (and I haven't managed to
get per-user to behave sensibly). And _most_ of them insist on
having a click-through EULA page in the interface, which I
absolutely don't want - the MIT licence does not need to be
presented as a EULA at all (if you didn't accept it in your
mind you had no business copying the software in the first
place, and it's not imposing any scary restrictions anyway).
So what we see below is my own sequence of UI dialogs, all
included by reference from the WiX standard set. It's probably
most similar to WixUI_InstallDir, but I've removed LicenseDlg
and included FeaturesDlg.
(I'm not actually sure that FeaturesDlg is all that good a fit
for this particular project, with a treeview control that
doesn't really get used as a tree, and inappropriate wording
in the dropdown you use to select or deselect features.
Perhaps in future I might replace it with a simpler dialog box
containing a checkbox for each of the desktop shortcut, the
PATH addition and the PPK associations.)
-->
<UIRef Id="WixUI_Common" />
<UI>
<TextStyle Id="WixUI_Font_Normal" FaceName="Tahoma" Size="8" />
<TextStyle Id="WixUI_Font_Bigger" FaceName="Tahoma" Size="12" />
<TextStyle Id="WixUI_Font_Title" FaceName="Tahoma" Size="9" Bold="yes" />
<Property Id="DefaultUIFont" Value="WixUI_Font_Normal" />
<Property Id="WixUI_Mode" Value="InstallDir" />
<DialogRef Id="BrowseDlg" />
<DialogRef Id="DiskCostDlg" />
<DialogRef Id="ErrorDlg" />
<DialogRef Id="FatalError" />
<DialogRef Id="FilesInUse" />
<DialogRef Id="MsiRMFilesInUse" />
<DialogRef Id="PrepareDlg" />
<DialogRef Id="ProgressDlg" />
<DialogRef Id="ResumeDlg" />
<DialogRef Id="UserExit" />
<DialogRef Id="FeaturesDlg" />
Installer: condition out use of WiX DLL components. This arranges that we can build a completely pure MSI file, which doesn't depend on any native code at install time. We don't lose much by doing this - only the option to pop up the README file at the end of installation, and validation of the install directory when you select it from a file browser. My immediate use for this is that I want to use it for installers that will run on Windows on Arm. But it also seems to me like quite an attractive property in its own right - no native code at all running at install time would be an _especially_ good guarantee that that code can't be hijacked by DLLs in the download directory. So I may yet decide that the features we're losing are not critical to _any_ version of the MSI, and throw them out unconditionally.
2018-05-31 18:23:59 +00:00
<?if $(var.DllOk) = yes ?>
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<Publish Dialog="BrowseDlg" Control="OK" Event="DoAction" Value="WixUIValidatePath" Order="3">1</Publish>
<Publish Dialog="BrowseDlg" Control="OK" Event="SpawnDialog" Value="InvalidDirDlg" Order="4"><![CDATA[NOT WIXUI_DONTVALIDATEPATH AND WIXUI_INSTALLDIR_VALID<>"1"]]></Publish>
Installer: condition out use of WiX DLL components. This arranges that we can build a completely pure MSI file, which doesn't depend on any native code at install time. We don't lose much by doing this - only the option to pop up the README file at the end of installation, and validation of the install directory when you select it from a file browser. My immediate use for this is that I want to use it for installers that will run on Windows on Arm. But it also seems to me like quite an attractive property in its own right - no native code at all running at install time would be an _especially_ good guarantee that that code can't be hijacked by DLLs in the download directory. So I may yet decide that the features we're losing are not critical to _any_ version of the MSI, and throw them out unconditionally.
2018-05-31 18:23:59 +00:00
<?endif ?>
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<Publish Dialog="ExitDialog" Control="Finish" Event="EndDialog" Value="Return" Order="999">1</Publish>
<Publish Dialog="WelcomeDlg" Control="Next" Event="NewDialog" Value="InstallDirDlg">NOT Installed</Publish>
<Publish Dialog="WelcomeDlg" Control="Next" Event="NewDialog" Value="FeaturesDlg">Installed</Publish>
<Publish Dialog="InstallDirDlg" Control="Back" Event="NewDialog" Value="WelcomeDlg">1</Publish>
<Publish Dialog="InstallDirDlg" Control="Next" Event="SetTargetPath" Value="[WIXUI_INSTALLDIR]" Order="1">1</Publish>
Installer: condition out use of WiX DLL components. This arranges that we can build a completely pure MSI file, which doesn't depend on any native code at install time. We don't lose much by doing this - only the option to pop up the README file at the end of installation, and validation of the install directory when you select it from a file browser. My immediate use for this is that I want to use it for installers that will run on Windows on Arm. But it also seems to me like quite an attractive property in its own right - no native code at all running at install time would be an _especially_ good guarantee that that code can't be hijacked by DLLs in the download directory. So I may yet decide that the features we're losing are not critical to _any_ version of the MSI, and throw them out unconditionally.
2018-05-31 18:23:59 +00:00
<?if $(var.DllOk) = yes ?>
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<Publish Dialog="InstallDirDlg" Control="Next" Event="DoAction" Value="WixUIValidatePath" Order="2">NOT WIXUI_DONTVALIDATEPATH</Publish>
<Publish Dialog="InstallDirDlg" Control="Next" Event="SpawnDialog" Value="InvalidDirDlg" Order="3"><![CDATA[NOT WIXUI_DONTVALIDATEPATH AND WIXUI_INSTALLDIR_VALID<>"1"]]></Publish>
<Publish Dialog="InstallDirDlg" Control="Next" Event="NewDialog" Value="FeaturesDlg" Order="4">WIXUI_DONTVALIDATEPATH OR WIXUI_INSTALLDIR_VALID="1"</Publish>
Installer: condition out use of WiX DLL components. This arranges that we can build a completely pure MSI file, which doesn't depend on any native code at install time. We don't lose much by doing this - only the option to pop up the README file at the end of installation, and validation of the install directory when you select it from a file browser. My immediate use for this is that I want to use it for installers that will run on Windows on Arm. But it also seems to me like quite an attractive property in its own right - no native code at all running at install time would be an _especially_ good guarantee that that code can't be hijacked by DLLs in the download directory. So I may yet decide that the features we're losing are not critical to _any_ version of the MSI, and throw them out unconditionally.
2018-05-31 18:23:59 +00:00
<?else ?>
<Publish Dialog="InstallDirDlg" Control="Next" Event="NewDialog" Value="FeaturesDlg" Order="2">1</Publish>
<?endif ?>
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<Publish Dialog="InstallDirDlg" Control="ChangeFolder" Property="_BrowseProperty" Value="[WIXUI_INSTALLDIR]" Order="1">1</Publish>
<Publish Dialog="InstallDirDlg" Control="ChangeFolder" Event="SpawnDialog" Value="BrowseDlg" Order="2">1</Publish>
<Publish Dialog="FeaturesDlg" Control="Back" Event="NewDialog" Value="WelcomeDlg">Installed</Publish>
<Publish Dialog="FeaturesDlg" Control="Back" Event="NewDialog" Value="InstallDirDlg">NOT Installed</Publish>
<Publish Dialog="FeaturesDlg" Control="Next" Event="NewDialog" Value="VerifyReadyDlg">1</Publish>
<Publish Dialog="VerifyReadyDlg" Control="Back" Event="NewDialog" Value="InstallDirDlg" Order="1">NOT Installed</Publish>
<Publish Dialog="VerifyReadyDlg" Control="Back" Event="NewDialog" Value="MaintenanceTypeDlg" Order="2">Installed AND NOT PATCH</Publish>
<Publish Dialog="VerifyReadyDlg" Control="Back" Event="NewDialog" Value="WelcomeDlg" Order="2">Installed AND PATCH</Publish>
<Publish Dialog="MaintenanceWelcomeDlg" Control="Next" Event="NewDialog" Value="MaintenanceTypeDlg">1</Publish>
<Publish Dialog="MaintenanceTypeDlg" Control="RepairButton" Event="NewDialog" Value="VerifyReadyDlg">1</Publish>
<Publish Dialog="MaintenanceTypeDlg" Control="RemoveButton" Event="NewDialog" Value="VerifyReadyDlg">1</Publish>
<Publish Dialog="MaintenanceTypeDlg" Control="Back" Event="NewDialog" Value="MaintenanceWelcomeDlg">1</Publish>
Installer: condition out use of WiX DLL components. This arranges that we can build a completely pure MSI file, which doesn't depend on any native code at install time. We don't lose much by doing this - only the option to pop up the README file at the end of installation, and validation of the install directory when you select it from a file browser. My immediate use for this is that I want to use it for installers that will run on Windows on Arm. But it also seems to me like quite an attractive property in its own right - no native code at all running at install time would be an _especially_ good guarantee that that code can't be hijacked by DLLs in the download directory. So I may yet decide that the features we're losing are not critical to _any_ version of the MSI, and throw them out unconditionally.
2018-05-31 18:23:59 +00:00
<?if $(var.DllOk) = yes ?>
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
<Publish Dialog="ExitDialog" Control="Finish" Event="DoAction"
MSI installer: offer to display the README file after install. This is a thing that the Inno Setup installer did, and that I didn't get round to replicating when I rushed out the initial MSI in a hurry. I've checked that this doesn't prevent unattended installation by administrators: running 'msiexec /q /i putty-whatever.msi' as administrator still installs silently after this change, without popping up the README unexpectedly on anyone's desktop as a side effect. (I _think_ - but I'm still a long way from an MSI expert - that that's because /q turns off the whole UI part of the MSI system, and the loading of README is actually triggered by the transition away from the final UI dialog box, which we now never visit in the first place.)
2016-04-02 07:00:25 +00:00
Value="LaunchApplication">WIXUI_EXITDIALOGOPTIONALCHECKBOX = 1 and NOT Installed</Publish>
Installer: condition out use of WiX DLL components. This arranges that we can build a completely pure MSI file, which doesn't depend on any native code at install time. We don't lose much by doing this - only the option to pop up the README file at the end of installation, and validation of the install directory when you select it from a file browser. My immediate use for this is that I want to use it for installers that will run on Windows on Arm. But it also seems to me like quite an attractive property in its own right - no native code at all running at install time would be an _especially_ good guarantee that that code can't be hijacked by DLLs in the download directory. So I may yet decide that the features we're losing are not critical to _any_ version of the MSI, and throw them out unconditionally.
2018-05-31 18:23:59 +00:00
<?endif ?>
MSI installer: offer to display the README file after install. This is a thing that the Inno Setup installer did, and that I didn't get round to replicating when I rushed out the initial MSI in a hurry. I've checked that this doesn't prevent unattended installation by administrators: running 'msiexec /q /i putty-whatever.msi' as administrator still installs silently after this change, without popping up the README unexpectedly on anyone's desktop as a side effect. (I _think_ - but I'm still a long way from an MSI expert - that that's because /q turns off the whole UI part of the MSI system, and the loading of README is actually triggered by the transition away from the final UI dialog box, which we now never visit in the first place.)
2016-04-02 07:00:25 +00:00
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<!--
This ARPNOMODIFY flag prohibits changing the set of
installed features, which would otherwise be possible by
reactivating the same MSI (from its original disk file, or
in Add/Remove Programs, or I think also by GUID on the
msiexec command line) and selecting 'Change' from the
maintenance-type dialog.
The reason I've prohibited it is because I couldn't get it
to *work* in my initial testing - it would look as if it had
done the right thing, but in fact the features it should
have removed would still be there after the installer
finished running. So if any WiX expert can help me fix this,
I'd love to take this flag out and make the installation
retrospectively modifiable!
(As well as removing this flag and fixing whatever the
problem is, I'd also have to add a line in the above set of
Publish tags which points MaintenanceTypeDlg's ChangeButton
at FeaturesDlg.)
-->
<Property Id="ARPNOMODIFY" Value="1" />
</UI>
Installer: condition out use of WiX DLL components. This arranges that we can build a completely pure MSI file, which doesn't depend on any native code at install time. We don't lose much by doing this - only the option to pop up the README file at the end of installation, and validation of the install directory when you select it from a file browser. My immediate use for this is that I want to use it for installers that will run on Windows on Arm. But it also seems to me like quite an attractive property in its own right - no native code at all running at install time would be an _especially_ good guarantee that that code can't be hijacked by DLLs in the download directory. So I may yet decide that the features we're losing are not critical to _any_ version of the MSI, and throw them out unconditionally.
2018-05-31 18:23:59 +00:00
<?if $(var.DllOk) = yes ?>
MSI installer: offer to display the README file after install. This is a thing that the Inno Setup installer did, and that I didn't get round to replicating when I rushed out the initial MSI in a hurry. I've checked that this doesn't prevent unattended installation by administrators: running 'msiexec /q /i putty-whatever.msi' as administrator still installs silently after this change, without popping up the README unexpectedly on anyone's desktop as a side effect. (I _think_ - but I'm still a long way from an MSI expert - that that's because /q turns off the whole UI part of the MSI system, and the loading of README is actually triggered by the transition away from the final UI dialog box, which we now never visit in the first place.)
2016-04-02 07:00:25 +00:00
<!--
Offer to display README after installation.
-->
<Property Id="WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT"
Value="View README file" />
<Property Id="WIXUI_EXITDIALOGOPTIONALCHECKBOX" Value="1" />
<Property Id="WixShellExecTarget" Value="[#README_File]" />
<CustomAction Id="LaunchApplication" BinaryKey="WixCA"
DllEntry="WixShellExec" Impersonate="yes" />
Installer: condition out use of WiX DLL components. This arranges that we can build a completely pure MSI file, which doesn't depend on any native code at install time. We don't lose much by doing this - only the option to pop up the README file at the end of installation, and validation of the install directory when you select it from a file browser. My immediate use for this is that I want to use it for installers that will run on Windows on Arm. But it also seems to me like quite an attractive property in its own right - no native code at all running at install time would be an _especially_ good guarantee that that code can't be hijacked by DLLs in the download directory. So I may yet decide that the features we're losing are not critical to _any_ version of the MSI, and throw them out unconditionally.
2018-05-31 18:23:59 +00:00
<?endif ?>
MSI installer: offer to display the README file after install. This is a thing that the Inno Setup installer did, and that I didn't get round to replicating when I rushed out the initial MSI in a hurry. I've checked that this doesn't prevent unattended installation by administrators: running 'msiexec /q /i putty-whatever.msi' as administrator still installs silently after this change, without popping up the README unexpectedly on anyone's desktop as a side effect. (I _think_ - but I'm still a long way from an MSI expert - that that's because /q turns off the whole UI part of the MSI system, and the loading of README is actually triggered by the transition away from the final UI dialog box, which we now never visit in the first place.)
2016-04-02 07:00:25 +00:00
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
<!-- Glue: tell the install dir part of the UI what id my actual
install dir is known by. Otherwise the former won't know how
to alter the setting of the latter. -->
<Property Id="WIXUI_INSTALLDIR" Value="INSTALLDIR" />
<!--
Include my custom installer artwork, created in Buildscr.
-->
<WixVariable Id="WixUIDialogBmp" Value="msidialog.bmp" />
<WixVariable Id="WixUIBannerBmp" Value="msibanner.bmp" />
Set an icon for the MSI package's entry in Add/Remove Programs. It would be nicer if we could also make this show up as the icon for the .msi file itself when viewed in Explorer, but apparently nothing can change that. But at least this still gives us _some_ use for the cardboard-box icon :-)
2016-03-20 16:01:36 +00:00
<!--
Set the icon that will show up in Add/Remove Programs.
http://www.codeproject.com/Articles/43564/WiX-Tricks says that
for some weird reason the Id of this icon has to end in .exe.
-->
<Icon Id="installericon.exe" SourceFile="puttyins.ico" />
<Property Id="ARPPRODUCTICON" Value="installericon.exe" />
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
</Product>
</Wix>
Reference in New Issue Copy Permalink