|
Size: 1383
Comment: page initiated. Section criteria added.
|
Size: 5947
Comment: criteria: inspectability?
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| 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? |
|
| Line 7: | Line 11: |
| # can be automated, because manual building will induce errors, is less reproducable and costs significant efforts. | (Todo: weight and rank) # can be automated, because manual building will induce errors, is less reproducible and costs significant efforts. |
| Line 9: | Line 15: |
| # consists of Free Software, so it can be indepentenly audited # behaves like a common application on the plattform, so users can use their tools and knowledge |
# 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 |
| Line 17: | Line 23: |
| # handling some level of dependencies and version, because we want Ggp4win to be updated seperately from applications that use it, e.g. Claws Mail. | # 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. |
| Line 20: | Line 27: |
| * verification of the Installer, so that user can be sure where it comes from. | # 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 makeing it possible to get it installed in more restricted environments? == discussion [[http://home.arcor.de/skanthak/!execute.html|Stefan Kanthak's case against executable installers]] 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) === examples for "executable" installers Microsoft and other known vendors still use non-"windows installer" executable installers. Probably for a reason. (Which reasons more precisely?) * Media Creation Tool (Installer für Windows 10) * Outlook 2013 Installer * Outlook 2016 Installer * Microsoft Word Viewer * Microsoft dot net Framework installer * VLC * ~TeamViewer * EvE Online It may still be state of the art used by a large fraction (how large, majority?) of current software products for windows. Potential reasons: * 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. === msi aka "Windows Installer" Old, probably outdated instructions to 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 https://en.wikipedia.org/wiki/Windows_Installer https://en.wikipedia.org/wiki/COM_Structured_Storage The format inside is unspecified and implemented in msi.dll. 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. Free Software that potentially could read/write COM Structured Storage files: * 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 https://iswix.codeplex.com/ //Industrial Strength Windows Installer XML ( IsWiX ) makes authoring Windows Installer XML (WiX) Windows Installers (.MSI)// easier. http://wixtoolset.org/ //The WiX toolset builds Windows installation packages from XML source code.// 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. """ * 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.// == CAB |
| Line 23: | Line 118: |
| // Discussion about the best installing technology targetting MS Windows. // | // Discussion about the best installing technology targetting MS Windows. Started by bernhard.// |
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 makeing it possible to get it installed in more restricted environments?
discussion
Stefan Kanthak's case against executable installers
http://installsite.org/ (contaminated with advertisements) but links to old and new stuff 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)
examples for "executable" installers
Microsoft and other known vendors still use non-"windows installer" executable installers. Probably for a reason. (Which reasons more precisely?)
- Media Creation Tool (Installer für Windows 10)
- Outlook 2013 Installer
- Outlook 2016 Installer
- Microsoft Word Viewer
- Microsoft dot net Framework installer
- VLC
- TeamViewer
- EvE Online
It may still be state of the art used by a large fraction (how large, majority?) of current software products for windows.
Potential reasons:
- 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.
msi aka "Windows Installer"
Old, probably outdated instructions to 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
https://en.wikipedia.org/wiki/Windows_Installer
https://en.wikipedia.org/wiki/COM_Structured_Storage The format inside is unspecified and implemented in msi.dll.
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.
Free Software that potentially could read/write COM Structured Storage files:
- 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
https://iswix.codeplex.com/ Industrial Strength Windows Installer XML ( IsWiX ) makes authoring Windows Installer XML (WiX) Windows Installers (.MSI) easier.
http://wixtoolset.org/ The WiX toolset builds Windows installation packages from XML source code.
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. """
- 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.
CAB
Discussion about the best installing technology targetting MS Windows. Started by bernhard.