Re: windows installer

[Phillip Lord]

Jostein Kjønigsen <address@hidden> writes:
> This is no doubt a major-improvement.

Thank you!


> If I were to provide some feedback or comments, I would like to point
> out a few things.
>
> 1. Not commonly downloaded (yet)
>
> For the time being, the installer is reported as "not commonly
> downloaded", and gives a big red warning in MS EDGE. I'm guessing
> you'll get the same in Chrome, and also possibly Firefox:
>
> I've seen this before when developing and delivering other
> Windows-software, and this should only appear in a transitional phase.
>
> This will make the initial roll-out a little more painful, but it
>should basically resolve itself over time.
>
> I'm just mentioning this, so that if you get other comments on the
> same subject, I don't think you need to be overly worried about it.

Okay. For the snapshots, I will probably start adding a date to the file
name which will exacerbate this, but as you say it should go away when
Emacs-27 comes out.





> 2. Installer is not signed
>
> These days trying to distribute a unsigned installer on Windows is
> getting increasingly cumbersome. Especially for the end-users trying
> to run it.


Yeah, couldn't agree more. This has to be fixed.



> The solution is signing the installer. Signing an installer (and any
> EXE-file really) is fairly trivial and there are tools for this in the
> Windows SDK. (And make sure to use the time-stamp options too!)
>
> To do this of course, you will have to be in possession of a X509
> code-signing certificate. If GNU already has one of these, it should
> be easy to convert into whatever format Windows expects it to be in,
> and put into use.

A single GNU one would be the thing, I think.

> If this is deemed important enough to resolve, I think the first
> course of action will have to be finding an affordable option for
> buying and renewing code-signing certificates.
>
> Managing the security of this certificate is also important concern,
> but one we can dig deeper into at a later point.

One solution here would be to sign the exe's when I upload them; this
means that the signature would happen inside gnu.org. AFAICT, it's
possible to do the signature with mono based tools -- so gnu.org would
not need a windows box to achieve this. I guess they'd need to re-GPG
sign it also, as signtool signature would break the GPG one.

> Also setting up code-signing in a CI-environment (and especially for a
> FOSS-project) can be a bit of a pain. Is the Windows-installer built
> in a CI-environment? Should it be? If so, this may also something we
> will need to solve too, but again, that's definitely something for
> later.

Signing on upload would solve this also. But, no, the windows-installer,
like the rest of the windows binaries on a cheap media box in my living
room.



> 3. Installer defaults
>
> Once launched the installer seems to work as intended. I do however question 
> some of the defaults provided.
>
> Install default directory has IMO at least 2 issues:
>
> * The default is to install to a folder on the desktop. This is highly 
> unconventional.

Yeah, known issue "Currently, it installs to Desktop which is not right,
but was easy.".

It's quick and easy to see what is going on there.

>  I suggest we instead use the user's profile folder. From an initial
>  probe, this can be found in at least the following
>  environment-variables on my Windows 10 test-machine: USERPROFILE (or
>  by concatenating HOMEDRIVE and HOMEPATH ).

I'll fix this.


>
> * The default install-directory includes the Emacs-version.
>
>  This means that if I create any mappings to this installed
>  Emacs-version, add it to the path, and I later want to upgrade Emacs
>  to a newer version... Will that be installed in a different place?
>  Will I have to re-register Emacs all over the registry and in all
>  open-with dialogs?

No idea.

I'm presuming most people will not add it to the path, but launch it
from the shortcut that the installation adds.



>  Not including the version-number will give us much less issues down
>  the line, especially for upgrades.

I think it will make it hard for the installer to notice downgrades,
though.

>
> * It should be noted that the Start-menu folder created for Emacs also
> contains the version number.
>
>  For the same reasons given above, I advice that we also remove the
>  version-number from this folder too. Again, it will make upgrades and
>  similar scenarios much more hygienic, with less "old stuff" we have
>  to clean up, in order to avoid stale links, or double
>  program-registrations for the same piece of software.

Would you be able to test the program-registrations for me? You should
be able to do this just by changing the directory name.

For the start menu, what about adding both "Emacs" and "Emacs-27"?


> Apart from that, I'm all positive about this initiative and the
> improvements it provides. This is just so much better.

Me too. I'm tired of seeing blank looks on the faces of people shown the
zip.

Phil