= Gpg4win installer
**~TODO, under construction**

Gpg4win v2.3.0 and earlier uses an installer build on top of NSIS, cross build on Debian GNU/Linux.
There were once instructions to manually build an MSI installer from the NSIS package, which are now outdated (see below).

Should we use something else? What is a better solution?


== Criteria

(Todo: weight and rank)

# can be automated, because manual building will induce errors, is less reproducible and costs significant efforts.
# can be cross build, because main GnuPG build environment and developer community is on GNU/Linux.
# consists of Free Software, so it can be independently audited
# behaves like a common application on the platform, so users can use their tools and knowledge
#* if a software distribution system or a system management solution is used, we shall play nice with it.
#* deinstallation should work via system controls
# looks attractive, to promote acceptance.
# can be internationalized, because GnuPG and apps target a lot of international users. German is a core language.
# can do everything that is needed, e.g. if services are to registered for autostart.
# is easy to understand and change, because this reduces efforts and problems.
# handling some level of dependencies and version, because we want Ggp4win to be updated separately from applications that use it, e.g. Claws Mail.
#* we also want the crypto engine to be updateable independently from "the rest" of Gpg4win. Rationale: less risk of breaking by separate testing and faster (security) updates.
# install/updates/deinstall should be possible
# update notifications, so that users will know when they run an outdated version and should update.
# verification of the Installer, so that user can be sure where it comes from.
# allow (volunteering) payments?
# allow to be found, conceived via "popular" stores? Windows App Store? Steam?
# maybe inspected before execution? Could be security feature or making it possible to get it installed in more restricted environments?

== Discussion
[[https://www.firegiant.com/wix/tutorial/|WiX 3 tutorial]] makes a case for Windows Installer/MSI as being declarative and thus more robust, but recommends WiX primarily for sophisticated packaging: //The relatively steep learning curve [..] and the unavoidable exposure to the internal details and, sometimes, intricacies of the underlying Windows Installer technology suggest that [..] those who don't really need the [..] performance [..] might be better served by a simpler, GUI-based setup authoring tool [..]//

Stefan Kanthak has published arguments against executable installers in general. As the Page tries to start a drive by download as a proof of concept for DLL Carpeting we do not link the page directly from this wiki: {{{https://skanthak.homepage.t-online.de/!execute.html}}}

This page does not discuss given reasons for using a "bootstrapper" like [[http://robmensching.com/blog/posts/2009/7/14/lets-talk-about-burn/|burn from WiXtools]].

http://installsite.org/ (contaminated with advertisements) but links to old and new stuff [[http://blogs.msmvps.com/installsite/blog/2015/05/03/the-future-of-windows-installer-msi-in-the-light-of-windows-10-and-the-universal-windows-platform/|The Future of Windows Installer (MSI) in the Light of Windows 10 and the Universal Windows Platform]]:
//AppX is now our deployment model. MSI isn’t going to go away, but we want you to move to AppX.// (May 3rd, 2015)\\
Neither AppX or UWP have found widespread use and Microsoft basically stopped promoting them. (2019)

* 2009: http://stackoverflow.com/questions/458900/free-software-for-windows-installers-nsis-vs-wix

[[werner]] (2015): "As long as we do not have a unified packaging system for free software on Windows, it does not make sense to switch to a new installer framework.  MSI is nice but can only unleash its power if we would make use of almost all of MS SDK features which in turn requires the use and distribution of non-free software.  We want to build on free software as far as possible and only resort to System services if not avoidable.  After all there should be only one packaging system for an OS (e.g. DPKG on Debian, RPM for Fedora, MSI for Windows).  Any mix of packaging systems is always problematic and can only be a workaround (e.g. alien on Debian).  Due to the strategic goal of helping Windows user to migrate to free software I can envison a second packing system on Windows for free software.  However, all efforts in this direction have not brought any success and developers will anyway soon realize that it would be easier to simply switch to a free software OS and maybe run Windows in a VM."

[[olf]] (2019): "'//msi [...] requires the use and distribution of non-free software.//' might not be true, anymore (see below)."


=== Examples for "executable" installers

Microsoft and other known vendors still use executable installers. (That may or may not include Windows Installer (aka msi) files.)
Probably for a reason. (Which reasons more precisely?)

* Media Creation Tool (Installer for Windows 10)
* Outlook 2013 Installer
* Outlook 2016 Installer
* Microsoft Word Viewer
* Microsoft dot net Framework installer
* VLC
* ~TeamViewer
* EvE Online
* WiX itself, e.g. comes as wx310.exe https://wix.codeplex.com/releases/ , the move was made between [[https://wix.codeplex.com/releases/view/60102|v3.5]] and 2012 [[https://wix.codeplex.com/releases/view/93929|v3.6]]

Thus using an executable installer seems to be state of the art (2015-12).
Open questions:
# How many .exe installers contain MSI files?
# What are the most used technologies to create these installers?

Potential reasons to use an executable installer instead of directly using and MSI file:
* need to load additional files from the internet?
* need to register system services?
* easier to construct or to control?
* more transparent in what will be happening?
As custom actions seems possible with Windows Installer, it is unclear where the limitation is.
* [[http://robmensching.com/blog/posts/2009/7/14/lets-talk-about-burn/|Rob Mensching about adding am executable "bootstrapper" to WiX]] (2009): "//Double clicking an MSI file should be sufficient to get the installation process going. Unfortunately, due to several design decisions in the Windows Installer there are a plethora of work items for a bootstrapper.//"


=== MSI aka "Windows Installer"
This is the way recommended by Microsoft for many years.

https://en.wikipedia.org/wiki/Windows_Installer


Specific to Gpg4win: an old, probably outdated instructions to manually build an msi Installer for Gpg4win: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=blob_plain;f=src/README-msi.txt;hb=HEAD


A number of installers come as MSI files or have MSI files wrapped by a "bootstrapper".
Microsoft uses wixtoolset (see below) to create installers for a number of their products.

Probably all system management or software distribution systems on MS Windows will play nicely with MSI files.


https://en.wikipedia.org/wiki/COM_Structured_Storage
The format inside is unspecified and implemented in msi.dll.

2013 [[http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-vs-NSIS-td7585223.html|wix discussion about vs nsis]]

http://stackoverflow.com/questions/1951289/windows-installer-msi-format :\\
//If you really want to know more about the details of the internals of the MSI file format then take a read through of these two blog articles by Rob Mensching (the author of WiX)//
* 2003: http://robmensching.com/blog/posts/2003/11/25/inside-the-msi-file-format/
* 2004: http://robmensching.com/blog/posts/2004/2/10/inside-the-msi-file-format-again/


It is possible to launch executables from MSI during installation:
* http://wixtoolset.org/documentation/manual/v3/customactions/qtexec.html
* https://msdn.microsoft.com/en-us/library/aa368066%28v=vs.85%29.aspx
 //"You want to launch an executable during installation"//


MSI files can contain other MSI files and other files like CAB files.

http://www.jsware.net/jsware/msicode.php5 has tools in VBScript and some comments about structures and tools.

Free Software that potentially could read/write COM Structured Storage files:
* https://github.com/wine-mirror/wine/tree/master/programs/msidb (new in 2019)
* https://developer.gnome.org/gsf/1.14/
* http://www.dimin.net/software/pole/
* https://bitbucket.org/decalage/oletools
* https://bitbucket.org/decalage/olefileio_pl


==== WiX Toolset
http://wixtoolset.org/ //The WiX toolset builds Windows installation packages from XML source code.//

Advantage: can be run automated.

https://iswix.codeplex.com/ //Industrial Strength Windows Installer XML ( IsWiX ) makes authoring Windows Installer XML (WiX) Windows Installers (.MSI)// easier.


It uses msi.dll for the internal, undocumented database implementation inside "COM structure storage", thus **it cannot run without a windows implementation like Wine**.

http://wixtoolset.org/issues/4381/ (2014-04):
"The managed code should work on Mono but WiX contains native code and
relies on an implementation of msi.dll. You end up needing Wine anyway."

* 2019: The Wine developers have released [[https://github.com/wine-mirror/wine/tree/master/programs/msidb|msidb]] for [[https://www.winehq.org/announce/4.4|manipulating the MSI database (see first bullet point, there)]].
* 2007: Marcus trying msi.dll on Wine: http://marc.info/?l=wine-patches&m=119455178826804&w=2
* 2005: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-on-mono-td689218.html //So, you can run WiX on Mono but you can't necessarily build MSI files except on Windows.//

==== msi.dll
Source code (2015-12-02) **not** found on
* https://github.com/dotnet/corefx and other github repos
* http://dotnet.github.io/docs/
* https://msdn.microsoft.com/de-de/vstudio/aa496123
* http://referencesource.microsoft.com/

=== CAB
Is an archive format, can be read and written with Free Software tools.
Can be used within MSI files or other installations methods, e.g. can opened directly?

=== INF
Seems to be for drivers, but may also work as an installer methods. See Kanthaks writings.

=== Cr(azy)eative ideas (2015):
* In order to keep the possibility to create an installer completely on GNU/Linux system:
Maybe an installer template can be created with wixtoolset and then we only need a tool to replace some parameters on GNU/Linux. E.g. replacing the name and the cab file. This looks doable because the COM structured storage files can be read and written, so it is only the work to reverse engineer parts of the embedded database implementation to replace a few things, which looks doable as well.
* To use the security advantages of MSI and to solve the two problems: a) better ui/ux, b) be able to use subpackages.
We could write a small system service that will only manage dependencies between MSIs and calling msiexec. It could be installed as msi itself.
* Offer msi packages and a .bat script for people that can handle dependencies themselfs and do not need some ux elements.
In addition offer a burn.exe bundled nicer package for people that need a combined ux.
* Approach die wixtoolset team, if they have a solution for our criteria or at least what their thinking on it is?
* Approach Microsoft to solve some of the MSI problems that lead to the use of "bootstrappers" and the dependency handling?


----
// Discussion about the best installing technology targeting MS Windows. Started by Bernhard.//