How about a bounty for a new windows installer using inno setup ?

[Bob Arnson via Digitalmars-d]

On Thursday, 8 December 2016 at 02:06:30 UTC, Brad Anderson wrote:
> 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.

The "Desktop 
Bridge"<https://developer.microsoft.com/en-us/windows/bridges/desktop> in Windows 10 lets Win32 apps become Appx packages and work like universal apps. It's really geared toward GUI apps, though, with traditional activation mechanisms (shortcuts, file type associations, protocols).

Building a new MSI installer with WiX for DMD itself is pretty 
straightforward. MSI and WiX support almost everything but you'd 
need install-time code for:

   * _ReplaceInFile replacement
   * UCRT manipulation in SDK searches

What's not straightforward is the "extras": Visual D, DMC, D1, 
Visual Studio. Usually, that kind of thing is handled in WiX with 
a bundle but that doesn't fit this pattern well, because the 
expectation is that you're handed off to the other installer. And 
order matters, because you need to get VS installed first to get 
the detection right but Visual D expects to come after the DMD 
installer.

It's not a hard problem, just one that doesn't really fit into 
the MSI model well.