Port Windows installer to WIX?
F. D. Castel
What about replacing the old Inno Setup-based installers with a new installer built using WiX?
Reasons:
-
Inno Setup is Delphi-based, which can lead to issues such as the one described here: https://groups.google.com/g/firebird-devel/c/JuorAbImTTk/m/4tDeIb4aBAAJ
-
WiX is a modern toolset that supports building both .msi and .exe installers.
-
WiX is already part of the Firebird build process (see the Dockerfile: https://github.com/FirebirdSQL/firebird/blob/master/builds/docker/windows/Dockerfile#L47). Removing Inno Setup would eliminate one more dependency.
-
And honestly, I’ve never met anyone who enjoys clicking through endless “Next, Next, Next” dialogs when installing software on Windows.
If everyone agrees, I’m willing to take on the task.
James Starkey
--
Support the ongoing development of Firebird! Consider donating to the Firebird Foundation and help ensure its future. Every contribution makes a difference. Learn more and donate here:
https://www.firebirdsql.org/donate
---
You received this message because you are subscribed to the Google Groups "firebird-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-deve...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/firebird-devel/76373391-17e3-46e1-a190-d0827a639f9an%40googlegroups.com.
Paul Reeves
>installer built using WiX?
>
both? We could start with FB6 alpha/beta and see how it goes.
Paul
--
Paul Reeves
https://www.ibphoenix.com
Supporting users of Firebird
Hamish Moffatt
What about replacing the old Inno Setup-based installers with a new installer built using WiX?
Reasons:
Inno Setup is Delphi-based, which can lead to issues such as the one described here: https://groups.google.com/g/firebird-devel/c/JuorAbImTTk/m/4tDeIb4aBAAJ
There's nothing in that thread that suggestions the false virus warnings is related to Innosetup or Delphi.
I think a bigger problem is that the installer is not signed.
Hamish
Paul Reeves
"'Hamish Moffatt' via firebird-devel" <firebir...@googlegroups.com> wrote:
>> https://groups.google.com/g/firebird-devel/c/JuorAbImTTk/m/4tDeIb4aBAAJ<https://groups.google.com/g/firebird-devel/c/JuorAbImTTk/m/4tDeIb4aBAAJ>
>There's nothing in that thread that suggestions the false virus warnings is
>related to Innosetup or Delphi. I think a bigger problem is that the
>installer is not signed. Hamish
To quote from their web-site...
https://jrsoftware.org/files/is6.5-whatsnew.htm
```
New signature-verification capability
Inno Setup now includes an integrated signature-verification capability that can be used to detect corruption or tampering in your files at compile time, before files are included in an installer being built, or during installation, before Setup copies external files onto a user's system.
Any type of file may be signed and verified, and creation of signatures does not require a certificate from a certificate authority. There is no cost involved.
Note, however, that these signatures cannot be used to eliminate an "Unknown
publisher" warning message shown by Windows when an installer or other EXE
file is started. That requires a completely different kind of signature
(Authenticode) embedded inside the EXE file by a different tool (Microsoft's
signtool.exe), and it does require a (usually expensive) code-signing
certificate from a certificate authority.
```
Regards
Denis Simonov
But updating InnoSetup is a good idea. Yes, version 6.0 and higher doesn't support WinXP, but modern versions of Firebird don't work on it either.
Mark Rotteveel
What about replacing the old Inno Setup-based installers with a new installer built using WiX?
Reasons:
Inno Setup is Delphi-based, which can lead to issues such as the one described here: https://groups.google.com/g/firebird-devel/c/JuorAbImTTk/m/4tDeIb4aBAAJ
Except that wasn't the problem, or at least not the whole problem (I have seen no conclusive proof it's due to InnoSetup, just hearsay and assumptions), some were caused by false positives on (very simple) Firebird binaries *in* the installer and its output, or URLs that you can visit from the installer, and some of the problems are also reported for the zipkit.
Assuming such problems will go away by switching installer frameworks is, I think, a bit naive (though I'd love to be proven wrong).
WiX is a modern toolset that supports building both .msi and .exe installers.
You talk as if InnoSetup is not maintained anymore. Replacing something just because it is not "modern" is generally a recipe for disaster, or for chasing the latest fads and changing what or how you do something every few months (I'm a bit hyperbolic here, to be clear).
Also, I think it would be helpful to explain *why* it would be beneficial to provide both an .exe and .msi (or only an .msi) installer; personally, I have a vague, but possibly wrong idea that an .msi might be beneficial for automated deployments or composite installers, but given I never do such deployments or build such installers, I might be totally off-base on that (and/or not aware how profound such benefit could be). I think I'm not the only one, so some more details could definitely help in deciding on this.
WiX is already part of the Firebird build process (see the Dockerfile: https://github.com/FirebirdSQL/firebird/blob/master/builds/docker/windows/Dockerfile#L47). Removing Inno Setup would eliminate one more dependency.
And honestly, I’ve never met anyone who enjoys clicking through endless “Next, Next, Next” dialogs when installing software on Windows.
I don't think that has anything to do with which toolset you build the installer, but with how you design the installer. And having to either write a commandline config for a silent install (as also supported by the current installer), or fill in dialogs in the installer is pretty much unavoidable if you want to give the user any control over where, how and what is installed.
Don't get me wrong: I've used Inno Setup for years (as well as other excellent tools made by the great Jordan Russell). But I think its time and place have long passed.
If everyone agrees, I’m willing to take on the task.
The first thing you should do is talk to the current maintainer of the current Windows installer (Paul Reeves), if only out of courtesy.
And then, maybe create a proof of concept or mock-up of the installer you envision, and list some real and detailed benefits for such change, if only to have a real discussion.
Also, please be aware, that replacing the installer goes beyond just building the thing, it also comes with maintaining it (which Paul has done for, I guess, the past 25 years), or at minimum handing over that responsibility.
Mark
PS I realize I come across as a negative naysayer here; my intention is primarily to say use caution, and come up with (or present) more solid arguments for replacing it.
-- Mark Rotteveel
Tony Whyman
I assume that you are proposing the WIX toolset (https://github.com/wixtoolset).
I have used WIX for more years than I care to remember and would support such a move. Like all installers, it is really just a way of building the install database used by Windows Installer and the discussion should really be about the most practical way of doing this and maintaining the install information. I doubt whether it can make much difference to "endless “Next, Next, Next” dialogs" as these are part of Windows Installer and all you can really do is select which dialogs are in use for your install.
To me the advantages of WIX are:
1. Open Source toolset.
2. The installer configuration files are XML fragments and thus are readily placed under version control and visible as part of source code repositories.
3. XML Fragments can be re-used on many different projects. For example, I have a standard XML fragment for including a Firebird Client DLL and support files in an a per application installer.
4. Building the install package is readily scriptable and needs only 7-zip to build a .exe installer.
5. You can build a Windows Install package on Linux by running the WIX tools under WINE. I make use of this with the Free Pascal cross compiler to build both Linux and WIndows executables and install packages (debs or rpc for Linux, msi for Windows) as part of the same script running on a Linux host. I have never tried it, but it should be possible to do the same with gcc.
Роман Симаков
Personally, I don't see any advantages of WiX over InnoSetup. XML-style configuration is probably the worst thing imaginable.
But updating InnoSetup is a good idea. Yes, version 6.0 and higher doesn't support WinXP, but modern versions of Firebird don't work on it either.
Mark Rotteveel
>
> I assume that you are proposing the WIX toolset
> (https://github.com/wixtoolset).
>
> I have used WIX for more years than I care to remember and would
> support such a move. Like all installers, it is really just a way of
> building the install database used by Windows Installer and the
> discussion should really be about the most practical way of doing this
> and maintaining the install information. I doubt whether it can make
> much difference to "endless “Next, Next, Next” dialogs" as these are
> part of Windows Installer and all you can really do is select which
> dialogs are in use for your install.
>
> To me the advantages of WIX are:
>
> 1. Open Source toolset.
>
> 2. The installer configuration files are XML fragments and thus are
> readily placed under version control and visible as part of source
> code repositories.
>
and are checked into Git:
https://github.com/FirebirdSQL/firebird/tree/master/builds/install/arch-specific/win32
>
> 3. XML Fragments can be re-used on many different projects. For
> example, I have a standard XML fragment for including a Firebird
> Client DLL and support files in an a per application installer.
>
InnoSetup.
> 4. Building the install package is readily scriptable and needs only
> 7-zip to build a .exe installer.
>
> 5. You can build a Windows Install package on Linux by running the WIX
> tools under WINE. I make use of this with the Free Pascal cross
> compiler to build both Linux and WIndows executables and install
> packages (debs or rpc for Linux, msi for Windows) as part of the same
> script running on a Linux host. I have never tried it, but it should
> be possible to do the same with gcc.
>
Windows anyway to actually build Firebird for Windows, so we use the
same Windows machine to build the installer. Additionally, I would guess
that InnoSetup runs under WINE as well.
Mark
--
Mark Rotteveel
Tony Whyman
present it uses Delphi to compile, but should be readily portable to
Free Pascal. Then it could run native under Windows and Linux and other
platforms. (you can of course build Delphi executables for mutiple
platforms, but that requires a commercial licence).
If the Delphi dependency is an issue then this can be resolved.
Mark Rotteveel
> Quick look an Innosetup on github (never really looked at it before). At
> present it uses Delphi to compile, but should be readily portable to
> Free Pascal. Then it could run native under Windows and Linux and other
> platforms. (you can of course build Delphi executables for mutiple
> platforms, but that requires a commercial licence).
false positives with the installer with some malware scanners is due to
InnoSetup and/or because it's Delphi-based.
There is no problem with InnoSetup itself IMHO, and discussing replacing
the installer with something else (be it Wix or something else), needs
to be grounded in real benefits to the project and the users of the
installers. That means not "I like modern", "I love (hate) XML", but
things like "it will be easier for users to automate or script installs"
(with reasons/explanations to not fall in the trap of wishful thinking),
"the project can (easier) build signed installers", "maintenance is
simpler due to X, Y and Z", etc.
Mark
--
Mark Rotteveel
Mark Rotteveel
> Personally, I don't see any advantages of WiX over InnoSetup. XML-style
> configuration is probably the worst thing imaginable.
eventually you can get used to it (and really, basically the only one to
get to say "I love/hate XML" is the one who's going to maintain it).
Mark
--
Mark Rotteveel
Tony Whyman
> That is not a problem either; some people *assume*/*guess* (some of)
> the false positives with the installer with some malware scanners is
> due to InnoSetup and/or because it's Delphi-based.
>
> There is no problem with InnoSetup itself IMHO, and discussing
> replacing the installer with something else (be it Wix or something
> else), needs to be grounded in real benefits to the project and the
> users of the installers. That means not "I like modern", "I love
> (hate) XML", but things like "it will be easier for users to automate
> or script installs" (with reasons/explanations to not fall in the trap
> of wishful thinking), "the project can (easier) build signed
> installers", "maintenance is simpler due to X, Y and Z", etc.
of building the installer database.
I had no previous experience of InnoSetup and, probably like many on
this list would assume that it was just another commercial graphical
install package generator.
Seeing that it is open source and uses text file scripts and that you
are happy with it then I see no reason as to why you should not continue
to use it.
Mark Rotteveel
> Seeing that it is open source and uses text file scripts and that you
> are happy with it then I see no reason as to why you should not continue
> to use it.
I've seen them presented. Except maybe being able to build an MSI (which
InnoSetup can't do; there is a third-party, I believe commercial,
wrapper to do that), but I'm not sure what the benefits of having an MSI
would provide beyond that of an EXE.
Mark
--
Mark Rotteveel
Denis Simonov
> false positives with the installer with some malware scanners is due to
> InnoSetup and/or because it's Delphi-based.
> eventually you can get used to it (and really, basically the only one to
> get to say "I love/hate XML" is the one who's going to maintain it).
Tony Whyman
> There might be actual benefits to switching, but so far, I don't think
> I've seen them presented. Except maybe being able to build an MSI
> (which InnoSetup can't do; there is a third-party, I believe
> commercial, wrapper to do that), but I'm not sure what the benefits of
> having an MSI would provide beyond that of an EXE.
installer and does not use Microsoft Installer. Hence, there is no MSI
file.
F. D. Castel
The only things worse than WIX are the alternatives.Jim Starkey
F. D. Castel
- The primary objective is to introduce MSI installers alongside the existing EXE packages.
- Inno Setup does not support generating MSI packages -- and is unlikely to do so -- since MSI relies on a fundamentally different installation architecture.
- A secondary goal is to simplify the release process, since we already use WiX Toolset (albeit an older version).
I'm aware of the responsibilities involved in contributing (and maintaining) any new code. If the idea is approved I don't intend to left it unattended. My original post was to "probe the ground" before committing any significant effort.
And to be clear, OF COURSE there was no intention of criticizing or diminishing Paul's work. I assumed my final remark would make that evident.
I'll post in another message a summary of .MSI installers benefits.
James Starkey
--
Support the ongoing development of Firebird! Consider donating to the Firebird Foundation and help ensure its future. Every contribution makes a difference. Learn more and donate here:
https://www.firebirdsql.org/donate
---
You received this message because you are subscribed to the Google Groups "firebird-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-deve...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/firebird-devel/f112272f-73ac-4c57-a8d3-e4a5fbb05bfcn%40googlegroups.com.
F. D. Castel
- Standardized practices
- Transactional rollback
- Self-repair
- Install-on-demand
MSI is the de facto standard for software deployment in Windows enterprise environments. System administrators prefer it because it is deterministic, automation-friendly, and integrates cleanly with enterprise management tools without requiring custom scripting. A few examples:
1) Consistent silent/unattended installation
msiexec /i app.msi /qn
msiexec /x app.msi /qn
There’s no need to document custom command-line switches.
2) Windows Installer enforces predictable behavior through:
- A single product per product code
- Standardized patching (MSP)
- Built-in support for major/minor upgrades
3) Self-repair: Missing files or registry entries can be automatically restored at runtime or on shortcut activation.
4) Standardized logging
msiexec /i app.msi /l*v install.log
No custom logging implementation required.
And now, for the kind members of the audience already ready to type "Inno Setup can also do this!" -- hold your horses, because you’re MISSING THE POINT.
This is NOT about comparing WiX and Inno Setup features.
Inno Setup EXCELS at producing traditional, wizard-driven EXE installers and can build remarkably complex setups -- complete with it's own goddamn SCRIPTING LANGUAGE!
But that model comes from an earlier, bygone era. Modern deployment pipelines prioritize automation, consistency, and enterprise compatibility -- areas where MSI is inherently better suited.
Finally, WiX Toolset is just one option for producing MSI installers today; I mentioned it primarily because it’s already part of the project.
F. D. Castel
And… of course, I should have checked Google first.
Here’s an explanation that’s much better than mine: https://serverfault.com/questions/11670/the-corporate-benefits-of-using-msi-files
Hamish Moffatt
commercial one personally though.)
Hamish
Mark Rotteveel
MSI packages are processed natively by the Windows Installer service (msiexec), which provides several built-in capabilities:
- Standardized practices
- Transactional rollback
- Self-repair
- Install-on-demand
MSI is the de facto standard for software deployment in Windows enterprise environments. System administrators prefer it because it is deterministic, automation-friendly, and integrates cleanly with enterprise management tools without requiring custom scripting. A few examples:
1) Consistent silent/unattended installation
msiexec /i app.msi /qn
msiexec /x app.msi /qn
There’s no need to document custom command-line switches.
Then, how do you customize an automated install?
Mark-- Mark Rotteveel