On Tuesday, 6 December 2016 at 17:28:25 UTC, Jim Hewes wrote:
> On 12/6/2016 12:21 AM, Thomas Mader wrote:
>>
>> You can also create a WiX installer out of an InnoSetup installer.
>> I think it's more important to decide upon the feature set, readability
>> and the time needed to build an installer.
>> Have you experience with both? I only have experience with NSIS and
>> InnoSetup and in InnoSetup the feature set for Windows is really good
>> and the readability is good.
>
> I started out by using InstallShield some years ago and got battle scars there. I don't recommend that. I used NSIS a little because a company we partnered with required it but I'm no authority on NSIS or Inno.
>
> It really depends on how complicated your particular install is and where you expect it to go in the future. If you're just copying a few files then anything will work. I don't mean to make too big a deal out of it if the requirements are really simple.
>
> Personally I think it's better in the long run to generate an MSI for several reasons you can probably look up yourself---security, ability to rollback (installation is a transaction), appears in Programs and Features, transforms, etc.
>
>> I wouldn't advise doing the coding part externally in D this makes
>> things much more complicated than it should be. Stick with what's
>> supported by the tool.
>
> I'm not suggesting you necessarily use D together with something like NSIS. But you do want to have a one-button automated build process, not just for convenience but for repeatability. That's important. Soon you will want to get away from the tool's own GUI and run things programmatically.
>
> After having not-so-good experiences with InstallShield I looked at things like SCons and msbuild, which was just coming out at the time. (This was a while ago). I tried msbuild but it didn't have modules to support many of the things I needed to do. Things like code-signing with a verisign signature, injecting data and files into exe resources, etc. Fortunately you can build your own custom modules using C# which is what I tried. But the process of transferring variables back and forth from the script to C# for every custom module was painful and I thought, "if I just do this all in C# it will be much easier". So I switched. I used C# not only to call on the WiX tools to run them, but to easily manipulate pathname and filename strings, which were different because I needed to build different configurations for different customer companies. And I also needed to build different combinations of language localization. I could use .NET to build a nice GUI for selecting configurations, and C# to call the Windows API when needed, move files around, anything.
>
> You may also run into issues when you need to do complicated updates and there are already earlier versions in the field. You may want to remove features, but your installer has to both update existing users in addition to supporting new users. It's hard to predict the future though so I won't say much about it except that it helps to have a more powerful tool when you run into such situations.
>
> The scripting-type tools are tempting because they're easy and no one wants to spend any time on installers. It's usually something that people hope to just slap on at the end and it often gets underestimated. But as I said, maybe it IS easy if you're just copying files and you will only ever have one configuration. So it depends.
>
> Jim

Nice writeup.
In our company we used NSIS and are switching over to InnoSetup. Most of the work is already done, just a few apps need to be moved.
I think no one really wants NSIS because of readability issues. It's assembler like language is too low level and many common functions are just missing.

InnoSetup on the other hand gives you everything you could ever want. I never missed a thing because pretty much everything is right there and if you happen to have very special needs you can do it quite nicely with the pascal scripting ability. You can call every Windows API function you just need to wrap it if it is not provided in one way or another via the InnoSetup API.
I don't think you need to do that for the D Installer though.

Our installers need to handle quite a few things.
- Signing and timestamping of exes, dlls, Installer and Uninstaller
- SendTo Handler registration (Windows doesn't provide a common SendTo directory so you need to handle it quite complicated for each users individual SendTo directory if you don't want to write a proper SendTo COM thing)
- Registration of a COM server
- Differentiate between 32 and 64 bit installs
- User elevation for Installs and Uninstalls but Updates are done for the current User (We still use Inno for our Updates too but move away from that because it's not at all transactional and cannot be undone in the middle of the update)
- Create MSI Installer from InnoSetup Installer via Wix

The update case could be better supported by Inno by default though I don't know how to really do it transactionally/atomic. Once everything is on the drive, how would you be able to switch from the old directory to the new one with one atomic action under Windows?

Apart from that I don't miss a thing in Inno for now apart that messing with Installers is always not that funny. :-)

On 12/6/2016 10:31 PM, Thomas Mader wrote:
>
> The update case could be better supported by Inno by default though I
> don't know how to really do it transactionally/atomic. Once everything
> is on the drive, how would you be able to switch from the old directory
> to the new one with one atomic action under Windows?
>

I'm not sure what you mean by switch the directory. If you mean that the update uses a different directory for the program than the original, then you can probably just use a "major" upgrade. Windows Installer has the idea of minor upgrade and major upgrade. (So, it's independent of whatever tools your using.) A minor upgrade just updates the files that have changed. A major upgrade essentially removes the original product totally and installs the new one. Some people even use a major upgrade for _every_ new version just to avoid problems that might occur with a minor upgrade.

If your install is simple it may not matter whether it's transactional or not. If it fails halfway through just try again or else ask the user to delete files. But for a more complicated install it's possible that it fails halfway through and leaves the system in a bad state where the half-install cannot be easily removed nor can you try again because the installer now thinks the product is already installed. Trying to fix this on a remote user's system can be a headache.

I liked WiX because it was down to the metal and I don't think there's anything you can't do. With other tools (like InstallShield) I spent too much time trying to get the tool to do something I could have done really easy at the low level if I could've just gotten to it. But granted, for simpler install situations the scripting tools can work OK and have a smaller learning curve.

Jim

On Monday, 5 December 2016 at 19:33:33 UTC, Jim Hewes wrote:
> On 12/5/2016 3:19 AM, Kjartan F. Kvamme wrote:
>> On Monday, 5 December 2016 at 09:24:59 UTC, Basile B. wrote:
>>> How about a bounty for a new windows installer using inno setup ?
>>>
>>> There are several issues related to the nsis-based windows installer
>>> (even on bugzilla). The problem that happened last Fall with a virus
>>> false detection may happen again. "Braddr" proposed to handle digital
>>> signatures in case it would involve payment.
>>>
>>> Programming an installer is a small job but it has a long term impact
>>> on the user experience. Worth 100€ imo.
>>
>> Any particular reason to use Inno Setup over for example Wix Toolset?
>
> <Delurk>
> In my last job I worked on installers (which I didn't like but someone had to do it.) I recommend WiX over Inno. The main reason is that WiX produces an MSI and Inno doesn't. An MSI is just a data file, not an executable, and is thus better for security. I normally wrapped the MSI in a bootstrap exe. But we had one customer that was part of the government and wouldn't accept anything but an MSI.
> If you want, you can generate the XML with a program. I just didn't because I figured it was easier to modify if you can directly see the XML. My install builder was actually a combination of C# and WiX. I never found scripts to be flexible enough and it's just one more language to know.
>
> Jim
> </Delurk>

Yes, if DMD is going to switch the installer to something else it should be MSI. It's the official way to create installers on Windows and IT departments prefer it. Just switching to another installer executable generator is a lateral step, rather than a step forward.

Microsoft seems to be wanting to quietly deprecate MSIs too and are increasingly not using them for their own products (likely to push people to the Windows Store). I'm not sure if the Windows Store is suitable for DMD though and adapting DMD to it would probably involve quite a bit of work and would likely involves legal agreements with Microsoft that only the D Foundation could make.

On Wednesday, 7 December 2016 at 23:00:13 UTC, Jim Hewes wrote:
> On 12/6/2016 10:31 PM, Thomas Mader wrote:
>>
>> The update case could be better supported by Inno by default though I
>> don't know how to really do it transactionally/atomic. Once everything
>> is on the drive, how would you be able to switch from the old directory
>> to the new one with one atomic action under Windows?
>>
>
> I'm not sure what you mean by switch the directory. If you mean that the update uses a different directory for the program than the original, then you can probably just use a "major" upgrade. Windows Installer has the idea of minor upgrade and major upgrade. (So, it's independent of whatever tools your using.) A minor upgrade just updates the files that have changed. A major upgrade essentially removes the original product totally and installs the new one. Some people even use a major upgrade for _every_ new version just to avoid problems that might occur with a minor upgrade.

The Update is triggered by the application itself. If the install fails or is Canceled in the middle the application can not start anymore and so the user needs to do something manually.
It would be possible to update everything into a new directory and after everything is done just exchange the stuff in the already installed directory with the new update directory.
But even this operation isn't atomic even though it's much better.
What might work is to make it work like the Nix package manager.
NixOS (Nix Package manager) provides atomic updates because the entire system environment is build by links. Replacing a version with another one is just a matter of changing the link to the proper directory.

So in Windows you could do it the same. Install versions in separate directories. The installation directory is linking to the appropriate version directory. On update just install to new version directory and after everything is done just update the installation directory link to the new update directory.
No matter what happens either the old or the new application version should be workable.

On Wednesday, 7 December 2016 at 23:00:13 UTC, Jim Hewes wrote:
> On 12/6/2016 10:31 PM, Thomas Mader wrote:
>>
>> The update case could be better supported by Inno by default though I
>> don't know how to really do it transactionally/atomic. Once everything
>> is on the drive, how would you be able to switch from the old directory
>> to the new one with one atomic action under Windows?
>>
>
> I liked WiX because it was down to the metal and I don't think there's anything you can't do. With other tools (like InstallShield) I spent too much time trying to get the tool to do something I could have done really easy at the low level if I could've just gotten to it. But granted, for simpler install situations the scripting tools can work OK and have a smaller learning curve.
>
> Jim

I think you might be right about using WiX. MSI seems to be build upon transactional installation.
Do you think it would be possible to use D instead of C++ to write custom code?

On 12/8/2016 3:03 AM, Thomas Mader wrote:

> Do you think it would be possible to use D instead of C++ to write
> custom code?

Custom code where? During the process of building the installation package or during installation itself. Anyway, in either case I don't see why not. You can insert a DLL into an MSI file. Then at some point during installation that you specify, the DLL will be extracted and an arbitrary function in it called. So any language that can generate a DLL will work there.

On Thursday, 8 December 2016 at 11:03:07 UTC, Thomas Mader wrote:
> I think you might be right about using WiX. MSI seems to be build upon transactional installation.
> Do you think it would be possible to use D instead of C++ to write custom code?

Short answer is yes, I've created such and actually inject my custom DLL for testing purposes.

MSI's are pretty awkward, no one knows how to create the MSI database instead there are 3 example databases provided which you can merge together if you desire that feature. From there the Database consists of tables which layout the installation sequence along with the installation sequence for the GUI. These sequences can call "Custom Actions" which are just table entries that point to a DLL (there is more to Custom Actions).

The signature looks something like below. I've got a little wrapper around the MSIHANDLE so as to add some safety and convenience.

   extern(Windows):
   export uint MyCustomActionName(const MsiLiveHandle hModule) {

I'm not too familiar with WIX and the exposure I've had is with older versions (3.x) which have had annoying and weird bugs. D certainly could be used to create the D MSI installer, but that is even lower level than WIX.

On Thursday, 8 December 2016 at 20:04:01 UTC, Jesse Phillips wrote:
> These sequences can call "Custom Actions" which are just table entries that point to a DLL (there is more to Custom Actions).

Why not just unpack the stuff and run a configuration program? The latter would be useful anyway.

On Friday, 9 December 2016 at 10:35:00 UTC, Kagamin wrote:
> On Thursday, 8 December 2016 at 20:04:01 UTC, Jesse Phillips wrote:
>> These sequences can call "Custom Actions" which are just table entries that point to a DLL (there is more to Custom Actions).
>
> Why not just unpack the stuff and run a configuration program? The latter would be useful anyway.

An MSI can't execute an arbitrary executable, just an arbitrary DLL which could run an arbitrary executable :) If you're running an MSI for security you're screwed.

Now if you're question is why not forgo the MSI and create a self-extracting archive which runs a post "install" configuration, well then you're writing your own installer and will need to fully handle upgrades and uninstall (I say fully since even with an MSI there is still uninstall steps you must specify, but generally only if you're doing special install steps that need to be undone)

To me an MSI is a weird complicated mess, but I'm kind of interested to dig in and understand how the MSIexec reads and processes the DB (beyond the basics).

On Friday, 9 December 2016 at 16:47:18 UTC, Jesse Phillips wrote:
> An MSI can't execute an arbitrary executable, just an arbitrary DLL which could run an arbitrary executable :)

https://msdn.microsoft.com/en-us/library/windows/desktop/aa368563%28v=vs.85%29.aspx this?