Re: Note from a donor

[Bob Arnson via Digitalmars-d]

On Saturday, 28 October 2017 at 01:42:52 UTC, evilrat wrote:
At a minimum you'd better try WinSDK first, there should be all 
necessary tools. After all it is system's development kit, not 
some fancy junk.


The Windows SDK hasn't included compilers since Windows 7.

Visual C++ is available as a NuGet package, which is just a .zip 
file. The 2017 version is ~650MB: 
https://www.nuget.org/packages/VisualCppTools.Community.VS2017Layout/


Unfortunately, it doesn't include the SDK headers or libs.

Bob

Re: 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?



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



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" 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.

Re: Code signing to help with Windows virus false positives

[Bob Arnson via Digitalmars-d]

On Wednesday, 12 October 2016 at 06:39:05 UTC, Thomas Mader wrote:

On Tuesday, 11 October 2016 at 06:09:03 UTC, Thomas Mader wrote:
I worked with NSIS and InnoSetup. InnoSetup is much cleaner 
and easier.
At work we switched from NSIS to InnoSetup and we create MSI 
packages from NSIS and InnoSetup packages IIRC.
I think it's better to go with InnoSetup because it might be 
more easy and probably more powerful than building MSI 
directly. But I don't have any experience with building an MSI 
installer and the feature set of MSI.

We are also signing the installer and all exe and DLLs inside.


I was right. We create the MSI package out of the InnoSetup 
executable with a minimal xml config for WiX.


That's not an MSI installer, it's an Inno installer wrapped in an 
.msi package. It doesn't solve false antivirus positives because 
the antivirus engines simply monitor the Inno installer getting 
extracted and executed.

Re: Code signing to help with Windows virus false positives

[Bob Arnson via Digitalmars-d]

On Tuesday, 11 October 2016 at 01:37:55 UTC, Martin Nowak wrote:
Whatever makes more sense. From my very limited understanding 
.msi installers are natively understood installers in Windows, 
and the weapon of choice for robust and more professional 
installers.
If innosetup is just another NSIS like tool, it might not solve 
all our problems.


InnoSetup is like NSIS in that it builds an .exe that does the 
file copying, registry writing, downloading, executing, and so 
forth. MSI packages are "executed" by the MSI engine built into 
the OS -- the logic is in the OS, the data is in the MSI package.



We're fairly clueless here and could really use help here.

Just signing the NSIS installers could work for now, any 
support for this hypothesis.
I tried to submit the latest release as sample to Microsoft but 
their file upload had a size limit smaller than the binary.


Getting past the antivirus gauntlet is mostly about (1) signing 
and (2) submitting installers until they get tired of blocking 
you. The two go hand-in-hand because it's basically building up a 
history of trusted behavior.


I don't know that NSIS is any worse or better than Inno about 
triggering antivirus. If that's your primary goal, it might not 
be worth a big porting job.


Bob (co-BDFL, WiX toolset, http://wixtoolset.org/, 
https://www.joyofsetup.com/)