windows installer

classic Classic list List threaded Threaded
64 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

windows installer

Phillip Lord-3

I've had a quick play and created an "installer" version of Emacs for
windows. Cheesy and ugly at the moment, but it works. It uses the NSIS
toolkit which is nicely packaged for msys2.

NSIS is free software, albeit the non GPL compatible CPL
(http://nsis.sourceforge.net/License). I don't believe this is a problem
as it would only be a packager. I'd welcome more informed opinion about
whether this is appropriate for Emacs.

Probably too late to put this onto Emacs-26 now I fear, but it could be
ready in time for Emacs-27. If any one is interested, I can uploaded it
to the pre-test website (as the Emacs source is already there).

As with the new zips I've created, this does raise questions about
release of updates to the binaries. This installer will contain (lots
of) other dependency files. My current plan is to freeze the
dependencies during pre-test. But this means, that these dependencies
will get old during the Emacs release cycle.

Anyway, thought's welcome.

Phil

Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Richard Stallman
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > NSIS is free software, albeit the non GPL compatible CPL
  > (http://nsis.sourceforge.net/License). I don't believe this is a problem
  > as it would only be a packager. I'd welcome more informed opinion about
  > whether this is appropriate for Emacs.

I agree, it would not be a problem, since used only as a packager.

--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.


Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Jostein Kjønigsen
In reply to this post by Phillip Lord-3
As a (part time) Windows-user I'd very much appreciate this.

Like I've mentioned earlier on this mailing-list, I have some custom scripts I use to manually assemble a new release when it's available, but even then it's so much of a hastle that I can't always be bothered.

Having an installer which makes this a next-next-next process would be a great

But I'm already on the train. Where this would clearly be most benefitial is for new Windows/Emacs-users if they could get going in the usual "next next next" Windows-fashion which they're already accustomed to.

Feel free to publish some test-installers for the community to try out.

--
Vennlig hilsen
Jostein Kjønigsen



On Fri, Oct 27, 2017, at 12:11 AM, Phillip Lord wrote:

I've had a quick play and created an "installer" version of Emacs for
windows. Cheesy and ugly at the moment, but it works. It uses the NSIS
toolkit which is nicely packaged for msys2.

NSIS is free software, albeit the non GPL compatible CPL
(http://nsis.sourceforge.net/License). I don't believe this is a problem
as it would only be a packager. I'd welcome more informed opinion about
whether this is appropriate for Emacs.

Probably too late to put this onto Emacs-26 now I fear, but it could be
ready in time for Emacs-27. If any one is interested, I can uploaded it
to the pre-test website (as the Emacs source is already there).

As with the new zips I've created, this does raise questions about
release of updates to the binaries. This installer will contain (lots
of) other dependency files. My current plan is to freeze the
dependencies during pre-test. But this means, that these dependencies
will get old during the Emacs release cycle.

Anyway, thought's welcome.

Phil


Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Jostein Kjønigsen
Hey Phil.

I've done some testing on this installer now, and so far it seems most things works as it should.

My impression is that on overall, this will make life much easier for Windows-users, and maybe finally bring the installation-experience on par with Linux-users who've for a long time just been able to "apt install emacs", "dnf install emacs" or whatever.

I've tested on Linux with Wine and I've also tested on Windows 10, and didn't encounter any critical issues or errors either place. It mostly just worked.

This is no doubt a major-improvement.

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.

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.

Upon launching the installer, I'm getting this warnin:

To run this, you have to know that you can click "More info" and proceed from there:


This I think can become a major hindrance for some new users, and unfortunately this problem will not solve itself.

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.

If not... This will cost money. How much, I do not know. Symantic has Authenticode-certificates starting at $500. While StartCom is no longer a trusted CA, I know they used to offer a significantly cheaper option. That gives me hope that there might be options cheaper than $500 available.

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.

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.

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.

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

  • 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?

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

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

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

--
Regards
Jostein Kjønigsen



On Tue, Nov 7, 2017, at 12:23 PM, Phillip Lord wrote:

The first snapshot is up on alpha.gnu.org!

Feedback welcome. And, I think you are right, this will be a big win for
Emacs users new to the party; I've seen people looking at the zip, and
not knowning what to do.

Phil

Jostein Kjønigsen <[hidden email]> writes:

As a (part time) Windows-user I'd very much appreciate this.

Like I've mentioned earlier on this mailing-list, I have some custom
scripts I use to manually assemble a new release when it's available,
but even then it's so much of a hastle that I can't always be bothered.
Having an installer which makes this a next-next-next process would
be a great
But I'm already on the train. Where this would clearly be most
benefitial is for new Windows/Emacs-users if they could get going in
the usual "next next next" Windows-fashion which they're already
accustomed to.
Feel free to publish some test-installers for the community to try out.


Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Phillip Lord-3
Jostein Kjønigsen <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Eli Zaretskii
> From: [hidden email] (Phillip Lord)
> Date: Fri, 10 Nov 2017 17:01:39 +0000
> Cc: [hidden email], [hidden email]
>
> >  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.

Just to make this more complex: the Windows platform conventions frown
upon installing stuff in that directory; you are supposed to create a
subdirectory and install there.

And programs should not end up there, they should be under
%ProgramFiles% instead.  The user's directory is for files, not for
programs.

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

They _will_ want to add it to PATH if they want to install packages
from the likes of ELPA, which frequently come with Makefiles that
invoke Emacs to compile the Lisp files.

Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Stefan Monnier
> They _will_ want to add it to PATH if they want to install packages
> from the likes of ELPA, which frequently come with Makefiles that
> invoke Emacs to compile the Lisp files.

For lack of familiarity with the Windows world, I don't know if typical
Windows users will want to add it to PATH (as a GNU/Linux user, of
course I'd do that), but I think the "frequently" above is incorrect.

The way Elisp files are compiled by package.el is to do it in the
running Emacs rather than by executing a separate Emacs session, AFAIK.

And even if you configure it to use something like async.el, doesn't
(expand-file-name invocation-name invocation-directory) let async.el find
an Emacs executable even when it's not in PATH?


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: windows installer

John Mastro
Stefan Monnier <[hidden email]> wrote:
> And even if you configure it to use something like async.el, doesn't
> (expand-file-name invocation-name invocation-directory) let async.el find
> an Emacs executable even when it's not in PATH?

Yep, that's exactly what async.el does.

        John

Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Fabrice Popineau-3
In reply to this post by Eli Zaretskii


2017-11-10 19:52 GMT+01:00 Eli Zaretskii <[hidden email]>:
> From: [hidden email] (Phillip Lord)
> Date: Fri, 10 Nov 2017 17:01:39 +0000
> Cc: [hidden email], [hidden email]
>
> >  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.

Just to make this more complex: the Windows platform conventions frown
upon installing stuff in that directory; you are supposed to create a
subdirectory and install there.

And programs should not end up there, they should be under
%ProgramFiles% instead.  The user's directory is for files, not for
programs.

That are the recommendations, yes. But I have never installed stuff like Emacs or TeX (or others)
in %ProgramFiles%.
And neither Cygwin or MSYS2 install in this directory.
You are still free to install stuff in c:\Gnu is you chose to do so.

Fabrice
Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Fabrice Popineau-3
In reply to this post by Stefan Monnier


2017-11-10 21:46 GMT+01:00 Stefan Monnier <[hidden email]>:
> They _will_ want to add it to PATH if they want to install packages
> from the likes of ELPA, which frequently come with Makefiles that
> invoke Emacs to compile the Lisp files.

For lack of familiarity with the Windows world, I don't know if typical
Windows users will want to add it to PATH (as a GNU/Linux user, of
course I'd do that), but I think the "frequently" above is incorrect.

Makefiles ? But the average Windows user does not have a make.exe program on his machine
and does not even know what it is used for.

(Admittedly, an Emacs user is probably not an average Windows user).

Fabrice
Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Phillip Lord-3
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

>> From: [hidden email] (Phillip Lord)
>> Date: Fri, 10 Nov 2017 17:01:39 +0000
>> Cc: [hidden email], [hidden email]
>>
>> >  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.
>
> Just to make this more complex: the Windows platform conventions frown
> upon installing stuff in that directory; you are supposed to create a
> subdirectory and install there.
>
> And programs should not end up there, they should be under
> %ProgramFiles% instead.  The user's directory is for files, not for
> programs.


The disadvantage with ProgramFiles is that it requires elevation, which
user profile does not, although user profiles gets mixed up with
roaming. Although, elevation is pretty normal for installation. But I
didn't want to it straight away in case I made the uninstaller
accidentally delete my windows installation.

I'm also investigating making Emacs a portable app (as in
PortableApps.com), assuming everyone is happy with this. This might be
the better route for single user (and portable) installs.



>> I'm presuming most people will not add it to the path, but launch it
>> from the shortcut that the installation adds.
>
> They _will_ want to add it to PATH if they want to install packages
> from the likes of ELPA, which frequently come with Makefiles that
> invoke Emacs to compile the Lisp files.

Really?

Phil

Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Phillip Lord-3
In reply to this post by Phillip Lord-3
Drew Adams <[hidden email]> writes:

>> They _will_ want to add it to PATH if they want to install packages
>> from the likes of ELPA, which frequently come with Makefiles that
>> invoke Emacs to compile the Lisp files.
>
> I haven't been following this thread.  But I was hoping that
> one thing that would come out of it is push-button building
> of Emacs for Windows.  I was hoping too that the result would
> be (could be, at least) what we get now: a build complete with
> binary executables and Lisp source code - but without any
> "installation" into Program Files etc being necessary (i.e.,
> hard-coded).

My scripts build all the distribution scripts with a single command (not
a push-button, unless this includes the "enter" key). But they do assume
that you have msys and the rest installed. At heart, though, they just
run three commands (autogen.sh;configure;make install).

> I, for one, am not interested in "installing" any Emacs build
> (Program Files etc.).  I use multiple builds from different
> releases.  I don't even want anything added, by default, to
> PATH.

I am debating with my installer whether to allow multiple versions or do
the more normal windows things of one version. I suspect the latter is
more sensible because, well, it's the normal windows thing.

> But an easy way to build Emacs for Windows - essentially
> push-button, specifying only an output directory and optionally
> other things that might be relevant - would be welcome.

Other than what we have, this isn't really on my radar. Building emacs
from source is now as easy as I need it to be.

Phil

Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Fabrice Popineau-3
In reply to this post by Phillip Lord-3


2017-11-11 0:27 GMT+01:00 Phillip Lord <[hidden email]>:
Eli Zaretskii <[hidden email]> writes:

>> From: [hidden email] (Phillip Lord)
>> Date: Fri, 10 Nov 2017 17:01:39 +0000
>> Cc: [hidden email], [hidden email]
>>
>> >  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.
>
> Just to make this more complex: the Windows platform conventions frown
> upon installing stuff in that directory; you are supposed to create a
> subdirectory and install there.
>
> And programs should not end up there, they should be under
> %ProgramFiles% instead.  The user's directory is for files, not for
> programs.


The disadvantage with ProgramFiles is that it requires elevation, which
user profile does not, although user profiles gets mixed up with
roaming. Although, elevation is pretty normal for installation. But I
didn't want to it straight away in case I made the uninstaller
accidentally delete my windows installation.


User profiles are subject to roaming. When you are on a Windows network, 
it means your emacs directory is copied everytime you log in. 
Definitely not a good idea.

 
I'm also investigating making Emacs a portable app (as in
PortableApps.com), assuming everyone is happy with this. This might be
the better route for single user (and portable) installs.


But Emacs is already portable. What do I miss here ?

Fabrice
Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Eli Zaretskii
In reply to this post by Stefan Monnier
> From: Stefan Monnier <[hidden email]>
> Date: Fri, 10 Nov 2017 15:46:09 -0500
>
> > They _will_ want to add it to PATH if they want to install packages
> > from the likes of ELPA, which frequently come with Makefiles that
> > invoke Emacs to compile the Lisp files.
>
> For lack of familiarity with the Windows world, I don't know if typical
> Windows users will want to add it to PATH (as a GNU/Linux user, of
> course I'd do that), but I think the "frequently" above is incorrect.
>
> The way Elisp files are compiled by package.el is to do it in the
> running Emacs rather than by executing a separate Emacs session, AFAIK.
>
> And even if you configure it to use something like async.el, doesn't
> (expand-file-name invocation-name invocation-directory) let async.el find
> an Emacs executable even when it's not in PATH?

Maybe I'm missing something.  29 packages (out of 166) in ELPA have a
Makefile.  Taking just one random Makefile, company/Makefile, I see
this:

  EMACS=emacs
  [...]

  compile:
          ${EMACS} -Q --batch -L . -f batch-byte-compile company.el company-*.el

If this Makefile is invoked with "make compile", it clearly expects
Emacs to be found along PATH.  And even if Make is invoked from Emacs,
the directory where the Emacs binary was found is not added to PATH.
So how can this work without Emacs's binary being on PATH?  And what
am I missing here?

Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Eli Zaretskii
In reply to this post by Fabrice Popineau-3
> From: Fabrice Popineau <[hidden email]>
> Date: Fri, 10 Nov 2017 22:33:43 +0100
> Cc: Phillip Lord <[hidden email]>,
> Jostein Kjønigsen <[hidden email]>,
> Jostein Kjønigsen <[hidden email]>,
> Emacs developers <[hidden email]>
>
>  And programs should not end up there, they should be under
>  %ProgramFiles% instead.  The user's directory is for files, not for
>  programs.
>
> That are the recommendations, yes. But I have never installed stuff like Emacs or TeX (or others)
> in %ProgramFiles%.

Neither did I.  But did you ever install programs under
%USERPROFILE%\%USERNAME%?  I don't think so.  And my comment was to
the suggestion to install in the latter place.

> You are still free to install stuff in c:\Gnu is you chose to do so.

Of course.  I never said anything to the contrary.

Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Eli Zaretskii
In reply to this post by Phillip Lord-3
> Date: Fri, 10 Nov 2017 13:43:08 -0800 (PST)
> From: Drew Adams <[hidden email]>
> Cc: [hidden email], [hidden email], [hidden email]
>
> I, for one, am not interested in "installing" any Emacs build
> (Program Files etc.).  I use multiple builds from different
> releases.  I don't even want anything added, by default, to
> PATH.

Then you should be fine with just unzipping a zip file, because by
default the Windows explorer does that into a separate directory.

But this installer is not for people like you or me who know what they
are doing and have special needs and requirements.  It is primarily
for the naïve (a.k.a. "newbie") who just want to be able to invoke the
installer and get Emacs installed "correctly", meaning that Emacs is
available to any other program running on the system.  And that means
being installed where other programs are installed (which gives them
additional protection by system-wide processes and features), and
being on PATH.

Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Eli Zaretskii
In reply to this post by Phillip Lord-3
> From: [hidden email] (Phillip Lord)
> Cc: [hidden email],  [hidden email],  [hidden email]
> Date: Fri, 10 Nov 2017 23:27:49 +0000
>
> >> >  environment-variables on my Windows 10 test-machine: USERPROFILE (or
> >> >  by concatenating HOMEDRIVE and HOMEPATH ).
> >>
> >> I'll fix this.
> >
> > Just to make this more complex: the Windows platform conventions frown
> > upon installing stuff in that directory; you are supposed to create a
> > subdirectory and install there.
> >
> > And programs should not end up there, they should be under
> > %ProgramFiles% instead.  The user's directory is for files, not for
> > programs.
>
> The disadvantage with ProgramFiles is that it requires elevation, which
> user profile does not, although user profiles gets mixed up with
> roaming. Although, elevation is pretty normal for installation. But I
> didn't want to it straight away in case I made the uninstaller
> accidentally delete my windows installation.

I don't think I understand the last sentence.

For the rest, installing into the user's profile because doing TRT is
harder is not a sufficient reason in my book.  If you want to avoid
elevation (which I don't think you should, given that this is "normal"
Windows behavior nowadays), then install into a directory that is
neither user profile nor Program Files (and maybe not even drive C:,
if there is another drive).  But going to the user profile is highly
unusual, to say the least.

> > They _will_ want to add it to PATH if they want to install packages
> > from the likes of ELPA, which frequently come with Makefiles that
> > invoke Emacs to compile the Lisp files.
>
> Really?

AFAIU, yes.

And even if ELPA packages have alternatives which don't invoke Make,
there will be other situations where building a package with Emacs
support will want to invoke Emacs.  One such example is GNU ID-utils.

IOW, Emacs is not just a GUI application used interactively, it is
also a program that supports batch-mode invocation, and that mode is
at times used by other programs.  Keeping the Emacs binary off the
users' system PATH is therefore less than ideal, because the users
will then bump into subtle problems whereby Emacs seems "unavailable".

Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Eli Zaretskii
In reply to this post by Phillip Lord-3
> From: [hidden email] (Phillip Lord)
> Cc: Eli Zaretskii <[hidden email]>,  [hidden email],  [hidden email],  [hidden email]
> Date: Fri, 10 Nov 2017 23:35:35 +0000
>
> I am debating with my installer whether to allow multiple versions or do
> the more normal windows things of one version. I suspect the latter is
> more sensible because, well, it's the normal windows thing.

I agree.  For those who want multiple versions, providing an opt-in
option of installing into a user-specified directory should suffice.

Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Yuri Khan-2
In reply to this post by Eli Zaretskii
On Sat, Nov 11, 2017 at 2:40 PM, Eli Zaretskii <[hidden email]> wrote:

> It is primarily
> for the naïve (a.k.a. "newbie") who just want to be able to invoke the
> installer and get Emacs installed "correctly", meaning that Emacs is
> available to any other program running on the system.  And that means
> being installed where other programs are installed (which gives them
> additional protection by system-wide processes and features), and
> being on PATH.

Being on the PATH is not a necessary condition. In the case of a
single user-facing binary, it is more efficient to register it on the
App Paths registry key.

https://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx

Reply | Threaded
Open this post in threaded view
|

Re: windows installer

Eli Zaretskii
> From: Yuri Khan <[hidden email]>
> Date: Sat, 11 Nov 2017 16:42:41 +0700
> Cc: Drew Adams <[hidden email]>, Jostein Kjønigsen <[hidden email]>,
> Emacs developers <[hidden email]>, [hidden email],
> Phillip Lord <[hidden email]>
>
> Being on the PATH is not a necessary condition. In the case of a
> single user-facing binary, it is more efficient to register it on the
> App Paths registry key.
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx

This has its own problems: it requires changing the Registry if you
want to modify the setting.  Also, will it work from the shell prompt?
I'm not sure.  More generally, the above documentation talks about
ShellExecuteEx, but that's not the only way programs are executed on
Windows.

Personally, I find all those fancy methods to be unnecessary
complications at best, and a source of subtle problems at worst.  PATH
is there, and if needed, can be customized per user as well.  If
nothing else, it makes the dialog easier between Windows users and
Emacs developers who are only familiar with Posix hosts.  So why would
we want to advise users to use those Windows-specific features?  I see
no compelling reasons.

1234