www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How about a bounty for a new windows installer using inno setup ?

reply Basile B. <b2.temp gmx.com> writes:
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.
Dec 05 2016
next sibling parent Basile B. <b2.temp gmx.com> writes:
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.
https://issues.dlang.org/show_bug.cgi?id=16405 https://issues.dlang.org/show_bug.cgi?id=15375 https://issues.dlang.org/show_bug.cgi?id=14847 https://issues.dlang.org/show_bug.cgi?id=14849 https://forum.dlang.org/post/akxxnjatohebpmhbeqip forum.dlang.org
Dec 05 2016
prev sibling parent reply Kjartan F. Kvamme <forbjok gmail.com> writes:
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?
Dec 05 2016
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 5 December 2016 at 11:19:31 UTC, 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?
D has `extern(Pascal)`, which means the the new setup program could be mostly coded in a D dll used by the innosetup script.
Dec 05 2016
parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 5 December 2016 at 11:39:37 UTC, Basile B. wrote:
 On Monday, 5 December 2016 at 11:19:31 UTC, 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?
D has `extern(Pascal)`, which means the the new setup program could be mostly coded in a D dll used by the innosetup script.
I have a little guy in my town, he thinks he's a genius. This job is for him. He'll start the hard way.
Dec 05 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Monday, 5 December 2016 at 14:42:26 UTC, Basile B. wrote:
 I have a little guy in my  town, he thinks he's a genius.
i'm not living there!
Dec 05 2016
parent Basile B. <b2.temp gfmx.com> writes:
On Monday, 5 December 2016 at 15:24:20 UTC, ketmar wrote:
 On Monday, 5 December 2016 at 14:42:26 UTC, Basile B. wrote:
 I have a little guy in my  town, he thinks he's a genius.
i'm not living there!
yes, i know ketmar.if you know me,dont bother. https://www.youtube.com/watch?v=4XVQ5GScEoI&index=15&list=PLFp2qxgnM_2MmFfd_hoWor6CHS80i5-Yq
Dec 05 2016
prev sibling parent reply Jim Hewes <jimhewes gmail.com> writes:
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 never found scripts to be flexible enough and it's just one more language to know. Jim </Delurk>
Dec 05 2016
next sibling parent reply Thomas Mader <thomas.mader gmail.com> writes:
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 enough and it's just one more language to know. Jim </Delurk>
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 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.
Dec 06 2016
parent reply Jim Hewes <jimhewes gmail.com> writes:
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. I tried. But the process of transferring variables back and forth from 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 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
Dec 06 2016
parent reply Thomas Mader <thomas.mader gmail.com> writes:
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 tried. But the process of transferring variables back and forth 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 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. :-)
Dec 06 2016
parent reply Jim Hewes <jimhewes gmail.com> writes:
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
Dec 07 2016
next sibling parent Thomas Mader <thomas.mader gmail.com> writes:
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.
Dec 08 2016
prev sibling parent reply Thomas Mader <thomas.mader gmail.com> writes:
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?
Dec 08 2016
next sibling parent Jim Hewes <jimhewes gmail.com> writes:
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.
Dec 08 2016
prev sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
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.
Dec 08 2016
parent reply Kagamin <spam here.lot> writes:
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.
Dec 09 2016
parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
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).
Dec 09 2016
parent reply Kagamin <spam here.lot> writes:
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/aa3685 3%28v=vs.85%29.aspx this?
Dec 09 2016
parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 9 December 2016 at 17:05:24 UTC, Kagamin wrote:
 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/aa3685 3%28v=vs.85%29.aspx this?
Thanks, prove me wrong :) I suppose you'd use the DLL because it has access to the MSI database during installation while the EXE won't. I'm doing it because I'm replacing a 3rd party DLL and want to make sure the custom action is called correctly by our installer.
Dec 09 2016
prev sibling parent reply Brad Anderson <eco gnuk.net> writes:
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 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.
Dec 07 2016
parent Bob Arnson <bob joyofsetup.com> writes:
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 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.
Dec 10 2016