Some findings and suggestion about Emacs on w32

[Lennart Borgman]

After compiling Emacs CVS with MinGW+MSYS on ms windows I have some simple
suggestions. Please tell me if I am misunderstanding something here!

1) I suggest that MinGW+MSYS is mentioned in the doc as the primary
environment for building Emacs on w32. It works well if some small problems
are removed (see below).

2) Addpm.exe currently has a switch /q that does not work under MSYS since
this is believed to be a path there. Replace this with -q (or add it as an
alternative). This must be changed in nt/makefile.w32-in too.

3) Addpm.exe should perhaps only add emacs_dir to the registry? Are the
other values really used?

4) Addpm.exe besides changing the registry adds an shortcut to the Start
menu in GNU Emacs/Emacs that points to runemacs.exe. This is perhaps not
very good? Adding this entry could make a user believe that this is how
Emacs should be used. (I believed that for a long time and therefore did not
use Emacs. I wanted to, but it did not gave me the functionality I needed
invoked this way! I needed gnuserv.) I suggest that addpm.exe should not add
this entry.

5) Emacs without gnuserv is in my opinion very crippled on w32. Gnuserv
should in my opinion be part of Emacs distribution for ms windows. I suggest
the version from http://www.wyrdrune.com/. I suggest that CVS should include
this gnuserv.

6) The docs should be clearly telling that gnuserv should be used on ms
windows.

7) MSYS should include a newer version of Texinfo. (This is of course not
something Emacs Devel should fix, I tell this jus to inform you.) As far as
I could see Emacs Info could not be built with makeinfo 4.3 which is what
currently is in MSYS. I have in another mail suggested that version 4.6 from
http://gnuwin32.sourceforge.net/ should be included in MSYS.

8) The procedure for building on w32 (NT) is not currently merged with the
normal build procedures in all places as far as I can see. I suggest that
they should be in the long run, but realises that this takes some time. In
the mean time I suggest changing the docs so that a user on w32 can
immediately be redirected to the relevant docs. Just put a note at the top
the docs! (Several persons have told me that they found it very difficult to
build Emacs on ms windows. It is not, but it is confusing to read the docs.)

- Lennart

[Kim F. Storm]

"Lennart Borgman" <***@student.lu.se> writes:

> 4) Addpm.exe besides changing the registry adds an shortcut to the Start
> menu in GNU Emacs/Emacs that points to runemacs.exe. This is perhaps not
> very good? Adding this entry could make a user believe that this is how
> Emacs should be used. (I believed that for a long time and therefore did not
> use Emacs. I wanted to, but it did not gave me the functionality I needed
> invoked this way! I needed gnuserv.) I suggest that addpm.exe should not add
> this entry.

I completely disagree!

Once you have started emacs (from the start menu), what business do
you have outside emacs (i.e. in Windoze land)?

But really, I practically never use gnuserv / emacsclient as I work inside
emacs most of the time... so I have all the file navigation tools I need
right there.

I used to work with a collegue who used emacs just like vi, ie.
starting a new instance for each file he wanted to edit. I tried to
teach him that emacs could do much better, but he wouldn't listen. (I
couldn't even get him to use emacsclient... :-)

>
> 5) Emacs without gnuserv is in my opinion very crippled on w32. Gnuserv
> should in my opinion be part of Emacs distribution for ms windows. I suggest
> the version from http://www.wyrdrune.com/. I suggest that CVS should include
> this gnuserv.

Sure, we should include a version of emacsclient which works with emacs'
new internal emacsserver -- today I guess it will work fine with sockets
(rather than mailslots which IIRC gnuserv uses).


--
Kim F. Storm <***@cua.dk> http://www.cua.dk

[Lennart Borgman]

----- Original Message -----
From: "Kim F. Storm" <***@cua.dk>


: "Lennart Borgman" <***@student.lu.se> writes:
:
: > 4) Addpm.exe besides changing the registry adds an shortcut to the Start
: > menu in GNU Emacs/Emacs that points to runemacs.exe. This is perhaps not
: > very good? Adding this entry could make a user believe that this is how
: > Emacs should be used. (I believed that for a long time and therefore did
not
: > use Emacs. I wanted to, but it did not gave me the functionality I
needed
: > invoked this way! I needed gnuserv.) I suggest that addpm.exe should not
add
: > this entry.
:
: I completely disagree!
:
: Once you have started emacs (from the start menu), what business do
: you have outside emacs (i.e. in Windoze land)?

Of course you have a point there, but why not have the freedom of working
different ways? Does not that make the learning curve less steep? I have
seen people hesitating to begin using Emacs just because there is too much
to learn to begin with. If we want people to use Emacs I think we should
make it as easy as possible to begin. They will learn more after a while.

Another trouble with this menu entry: What will happen if you start Emacs a
second time from that Start menu entry?

What I would want is that this entry pointed to gnuclientw.exe (or
emacsclient.exe). But there is a trouble with this too. In the case of
gnuclientw.exe gnuserv.el must be started too. But an idea hit me:
gnuserv.el could be started by gnuclientw.exe! The version of gnuclientw.exe
that comes from http://www.wyrdrune.com/ has a switch -e for executing lisp.
I believe this could be used - have to give it a test... - what would you
think of a menu entry like this instead?

BTW the name of the entry is "GNU Emacs". I thought that just "Emacs" was
preferred?


: > 5) Emacs without gnuserv is in my opinion very crippled on w32. Gnuserv
: > should in my opinion be part of Emacs distribution for ms windows. I
suggest
: > the version from http://www.wyrdrune.com/. I suggest that CVS should
include
: > this gnuserv.
:
: Sure, we should include a version of emacsclient which works with emacs'
: new internal emacsserver -- today I guess it will work fine with sockets
: (rather than mailslots which IIRC gnuserv uses).

Can you tell me more about emacsserver/emacsclient? Does it work like
gnuserv or are there big differences?

Is not the main thing to get this kind of functionality working on w32 right
from the distribution, without having to install more things? Since gnuserv
exists and works well on w32 today would it not be good to include it now?
(The gnuserv at wyrdrune uses sockets. I do not know if that is important
here.)

Of course I have nothing against including emacsclient instead if it works!


- Lennart

[Kim F. Storm]

"Lennart Borgman" <***@student.lu.se> writes:

> ----- Original Message -----
> From: "Kim F. Storm" <***@cua.dk>
>
> : Once you have started emacs (from the start menu), what business do
> : you have outside emacs (i.e. in Windoze land)?
>
> Of course you have a point there, but why not have the freedom of working
> different ways? Does not that make the learning curve less steep? I have
> seen people hesitating to begin using Emacs just because there is too much
> to learn to begin with. If we want people to use Emacs I think we should
> make it as easy as possible to begin. They will learn more after a while.

I don't understand. How does gnuclient make emacs easier to learn ?

I definitely think GNU Emacs should be on the start menu --

If emacs/gnuclient is included, your installer may offer to make file
associations in the registry for e.g. *.el *.c *.h.

>
> Another trouble with this menu entry: What will happen if you start Emacs a
> second time from that Start menu entry?

You get a second instance of emacs -- that's perfectly legal and may be useful
if you need a separate thread for some things (like gnus).

There is a problem if you start the server in .emacs; does the first
or second instance run the server ? I don't know if there is a
generic answer to that question.

> BTW the name of the entry is "GNU Emacs". I thought that just "Emacs" was
> preferred?

Right -- but mentioning GNU explicitly on the windoze start menu is a
nice thing to do to remind users about "the issues", so IMO we should
keep it there.

> Can you tell me more about emacsserver/emacsclient? Does it work like
> gnuserv or are there big differences?

A major difference is that in CVS emacs, emacsserver is now INTERNAL
written in ELisp via make-network-process. I.e. only emacsclient is
an external program.

AFAIK emacsclient uses a local unix socket, gnuclient uses a mailslot.

--
Kim F. Storm <***@cua.dk> http://www.cua.dk

[Stefan]

> There is a problem if you start the server in .emacs; does the first
> or second instance run the server ? I don't know if there is a
> generic answer to that question.

The current code just overwrites any previous server, so the last instance
is the one that wins.


Stefan

[Guy Gascoigne-Piggford]

Actually I think that it's the other way around. The first server is
listening and so the second can't bind to the port and so errors out.

Guy

Stefan wrote:

>>There is a problem if you start the server in .emacs; does the first
>>or second instance run the server ? I don't know if there is a
>>generic answer to that question.
>>
>>
>
>The current code just overwrites any previous server, so the last instance
>is the one that wins.
>
>
> Stefan
>.
>
>
>

[Stefan]

> Actually I think that it's the other way around. The first server is
> listening and so the second can't bind to the port and so errors out.

That hasn't been my experience, and disagrees with the comments (and
messages) in the server.el code. Maybe it depends on the underlying OS?


Stefan

[Lennart Borgman]

----- Original Message -----
From: "Stefan" <***@iro.umontreal.ca>
To: "Guy Gascoigne-Piggford" <***@wyrdrune.com>
Cc: "Kim F. Storm" <***@cua.dk>; "Lennart Borgman"
<***@student.lu.se>; "Emacs Devel" <emacs-***@gnu.org>
Sent: Monday, October 25, 2004 1:36 AM
Subject: Re: Some findings and suggestion about Emacs on w32


: > Actually I think that it's the other way around. The first server is
: > listening and so the second can't bind to the port and so errors out.
:
: That hasn't been my experience, and disagrees with the comments (and
: messages) in the server.el code. Maybe it depends on the underlying OS?

I have no idea about that, but I think it could be very frustrating if
starting a second instance of Emacs makes the first instance behave
differently. The way it works on windows seems best to me. (Though I have
never wanted to start a second instance.)

- Lennart

[Guy Gascoigne-Piggford]

>A major difference is that in CVS emacs, emacsserver is now INTERNAL
>written in ELisp via make-network-process. I.e. only emacsclient is
>an external program.
>
>AFAIK emacsclient uses a local unix socket, gnuclient uses a mailslot.
>
>
>

That was the case for a windows only version of gnuclient that Nico
Francois put out at some point in 1996/1997. At about the same time I
took a copy of the latest gnuserve that I could find on the net , which
was a version by Peter Breton modified from the version that Andy Norman
originally wrote ( I'm not sure if this was based on emacsclient code,
or just based on the same idea). I got rid of the mailslot support and
ported the Unix socket code over to NT. This gave us a version of
gnuserve that worked compatibly from Unix to NT. I've found this
feature very useful since this version allows connections to be made
over a network from a telnet or xterm on a Unix machine to an Emacs and
gnuserv on an NT machine.

So I took Andy Norman's stock Unix version and ported the socket code
over to NT (coincidentally this seems to work on Win9x). To this I
added some of the NT specific stuff from Peter Breton & Nico Francois'
version.

This seems to be the version of gnuclient that appears to be most
commonly referenced when talking about to gnuserve on NT, you still
sometimes hear about the mailslot version of gnuserve but I don't know
if it's actually available on the net easily any longer (I do still have
a copy if anyone needs it BTW).

And to complcate all of this, the XEmacs folks have a completely
difference gnuclient port, same original code base, but diverged a long
time ago. The lisp is XEmacs specific and the protocol has changed from
the other version.

Anyway, I'm still trying to get an emacs build enviroment on my NT box
(that's an entertaining waste of a weekend), Oh the joys of tools that
can't cope with varied line endings :(

Anyway, some time later I'll see what needs to be done to get
emacsclient working. Then I guess I'll find all of the reasons why I
started using gnuclient.

Off to google for all of the previous discussions of this issue.

[David Kastrup]

***@cua.dk (Kim F. Storm) writes:

> "Lennart Borgman" <***@student.lu.se> writes:
>
>> ----- Original Message -----
>> From: "Kim F. Storm" <***@cua.dk>
>>
>> : Once you have started emacs (from the start menu), what business do
>> : you have outside emacs (i.e. in Windoze land)?
>>
>> Of course you have a point there, but why not have the freedom of working
>> different ways? Does not that make the learning curve less steep? I have
>> seen people hesitating to begin using Emacs just because there is too much
>> to learn to begin with. If we want people to use Emacs I think we should
>> make it as easy as possible to begin. They will learn more after a while.
>
> I don't understand. How does gnuclient make emacs easier to learn ?
>
> I definitely think GNU Emacs should be on the start menu --

Well, I think emacsclient -a emacs (add the appropriate paths) would
be an even better candidate: if you have not started an Emacsserver,
it will just bring up Emacs.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[Kim F. Storm]

David Kastrup <***@gnu.org> writes:

> ***@cua.dk (Kim F. Storm) writes:
>
>> "Lennart Borgman" <***@student.lu.se> writes:
>>
>>> ----- Original Message -----
>>> From: "Kim F. Storm" <***@cua.dk>
>>>
>>> : Once you have started emacs (from the start menu), what business do
>>> : you have outside emacs (i.e. in Windoze land)?
>>>
>>> Of course you have a point there, but why not have the freedom of working
>>> different ways? Does not that make the learning curve less steep? I have
>>> seen people hesitating to begin using Emacs just because there is too much
>>> to learn to begin with. If we want people to use Emacs I think we should
>>> make it as easy as possible to begin. They will learn more after a while.
>>
>> I don't understand. How does gnuclient make emacs easier to learn ?
>>
>> I definitely think GNU Emacs should be on the start menu --
>
> Well, I think emacsclient -a emacs (add the appropriate paths) would
> be an even better candidate: if you have not started an Emacsserver,
> it will just bring up Emacs.

Sounds fine. I don't really care what exact command is run by the
start menu item named "GNU Emacs" -- as long as there is such an item
on the start menu.

--
Kim F. Storm <***@cua.dk> http://www.cua.dk

[Lennart Borgman]

: > ----- Original Message -----
: > From: "Kim F. Storm" <***@cua.dk>
:
: I don't understand. How does gnuclient make emacs easier to learn ?

What I wanted to say was that if gnuclient is used then you can open your
files from Windows Explorer or cmd.exe and they all get into Emacs just as
if you opened them from inside Emacs. Then the new user does not have to
rethink how he/she searches for files for example. It can be done as usual.
Does not this makes it more easy to learn Emacs? At least it seems to me
that less details have to be learned to begin using Emacs. (Of course I
could give more examples like this, but I hope the main idea gets through.)

: A major difference is that in CVS emacs, emacsserver is now INTERNAL
: written in ELisp via make-network-process. I.e. only emacsclient is
: an external program.

Is emacsserver started automatically or does the user have to start
emacsserver from .emacs (or another init file)?

- Lennart

[Kim F. Storm]

"Lennart Borgman" <***@student.lu.se> writes:

> : > ----- Original Message -----
> : > From: "Kim F. Storm" <***@cua.dk>
> :
> : I don't understand. How does gnuclient make emacs easier to learn ?
>
> What I wanted to say was that if gnuclient is used then you can open your
> files from Windows Explorer or cmd.exe and they all get into Emacs just as
> if you opened them from inside Emacs. Then the new user does not have to
> rethink how he/she searches for files for example. It can be done as usual.

I understood this, but I don't see how it makes _learning_ emacs easier.
For one thing you wont learn of dired or C-x C-f which are much better
integrated.

Anyways, what you talk about is 'integration' with the o/s, and I
think that is a good thing to do. And yes, clicking on a .c file
should launch the file in emacs rather than Visual Stupido.

> Does not this makes it more easy to learn Emacs?

Being able to start a program doesn't usually make you an expert :-)

> At least it seems to me
> that less details have to be learned to begin using Emacs. (Of course I
> could give more examples like this, but I hope the main idea gets through.)

I think we should do both -- users are not alike, and once you master emacs,
why would you ever go into Windoze Exploder to open a file when it's right
there in C-x C-f ?

> : A major difference is that in CVS emacs, emacsserver is now INTERNAL
> : written in ELisp via make-network-process. I.e. only emacsclient is
> : an external program.
>
> Is emacsserver started automatically or does the user have to start
> emacsserver from .emacs (or another init file)?

You must start the server with (server-start) in .emacs.

--
Kim F. Storm <***@cua.dk> http://www.cua.dk

[Lennart Borgman]

----- Original Message -----
From: "Kim F. Storm" <***@cua.dk>

: > Is emacsserver started automatically or does the user have to start
: > emacsserver from .emacs (or another init file)?
:
: You must start the server with (server-start) in .emacs.

Thanks. Is not this a bit fragile? One of the problems I had in the
beginning when I started to use Emacs was errors in startup files that
prevented gnuserv from starting. That made it a bit more difficult to fix
the problems than it should have been.

Is there any reason that emacsserver is not started automatically when
called by emacsclient? If you call with the client you probably want the
server to connect to the server, or? There could still be possibilities for
options when starting the server. A lisp file in site-lisp could for example
be called.

I just made a slight rewrite of gnuclient to test such a solution and I
found it hard to see any drawbacks with it. But our total creativity is of
course much bigger ;-)

- Lennart

[Jason Rumney]

Lennart Borgman wrote:

>Is there any reason that emacsserver is not started automatically when
>called by emacsclient?
>
Chiken and egg. emacsclient has nothing to "call" if the server is not
started.

[Lennart Borgman]

----- Original Message -----
From: "Jason Rumney" <***@gnu.org>


: Lennart Borgman wrote:
:
: >Is there any reason that emacsserver is not started automatically when
: >called by emacsclient?
: >
: Chiken and egg. emacsclient has nothing to "call" if the server is not
: started.

I did not think of that, but then the problem with the chiken and the egg is
solved by me ;-) -- and many others.

For gnuserv/gnuclient (from Guy Gascoigne-Piggford) it works like this:

- Gnuclient.exe starts Emacs if it is not started.
- I did a test and added an option to make Emacs start gnuserv automatigally
(simply by using the --load switch to Emacs). Works nice I think.

I believe that many users would expect the server to start like this (but
maybe I am wrong?).

[Stephan Stahl]

Hi.

Jason Rumney said:
> Lennart Borgman wrote:
>
>>Is there any reason that emacsserver is not started automatically when
>>called by emacsclient?
>>
> Chiken and egg. emacsclient has nothing to "call" if the server is not
> started.

I guess something like
emacsclient -a emacs --eval (start-server)
would meet Lennarts needs? But is there a reason that (start-server) is not
always called when emacs is started?

Stephan
--
Stephan Stahl

[Lennart Borgman]

----- Original Message -----
From: "Stephan Stahl" <***@eos.franken.de>

: I guess something like
: emacsclient -a emacs --eval (start-server)
: would meet Lennarts needs? But is there a reason that (start-server) is
not
: always called when emacs is started?

Maybe there are situations when you do not want the server to start. My
point is really that if you start Emacs with emacsclient then you probably
expect emacsserver to be started automatically.

If there are situations where you want to start Emacs without the server
then it would be much simpler if the server was not started by the init
files.

- Lennart

[Kim F. Storm]

"Lennart Borgman" <***@student.lu.se> writes:

> ----- Original Message -----
> From: "Stephan Stahl" <***@eos.franken.de>
>
> : I guess something like
> : emacsclient -a emacs --eval (start-server)
> : would meet Lennarts needs? But is there a reason that (start-server) is
> not
> : always called when emacs is started?
>
> Maybe there are situations when you do not want the server to start. My
> point is really that if you start Emacs with emacsclient then you probably
> expect emacsserver to be started automatically.
>
> If there are situations where you want to start Emacs without the server
> then it would be much simpler if the server was not started by the init
> files.

If your setup requires that the server is running, you could add it to
a site-wide default.el file (see the doc string for the site-run-file
variable).

--
Kim F. Storm <***@cua.dk> http://www.cua.dk

[Lennart Borgman]

----- Original Message -----
From: "Kim F. Storm" <***@cua.dk>

: If your setup requires that the server is running, you could add it to
: a site-wide default.el file (see the doc string for the site-run-file
: variable).

Yes, thanks, but that still misses the point that if the user runs
emacsclient he/she probably want emacsserver to be started. The chance that
he/she does not is very small (if it was not a mistake) so why not start
emacsserver automatically in this case - so that running emacsclient get the
expected result?

- Lennart

[Guy Gascoigne - Piggford]

Whilst *I* like the idea of always having the server running, I don't
know enough here to know if this is actually a good general purpose
solution or not.

As for starting it the first time that emacsclient is run, how to you
propose doing this? Since emacsclient needs the server to be running to
communicate with emacs, how can it instruct emacs to start the server
when it has no mechanism to communicate over?

Guy

Lennart Borgman wrote:

>----- Original Message -----
>From: "Kim F. Storm" <***@cua.dk>
>
>: > Is emacsserver started automatically or does the user have to start
>: > emacsserver from .emacs (or another init file)?
>:
>: You must start the server with (server-start) in .emacs.
>
>Thanks. Is not this a bit fragile? One of the problems I had in the
>beginning when I started to use Emacs was errors in startup files that
>prevented gnuserv from starting. That made it a bit more difficult to fix
>the problems than it should have been.
>
>Is there any reason that emacsserver is not started automatically when
>called by emacsclient? If you call with the client you probably want the
>server to connect to the server, or? There could still be possibilities for
>options when starting the server. A lisp file in site-lisp could for example
>be called.
>
>I just made a slight rewrite of gnuclient to test such a solution and I
>found it hard to see any drawbacks with it. But our total creativity is of
>course much bigger ;-)
>
>- Lennart
>
>
>
>
>
>

[Lennart Borgman]

----- Original Message -----
From: "Guy Gascoigne - Piggford" <***@wyrdrune.com>


: Whilst *I* like the idea of always having the server running, I don't
: know enough here to know if this is actually a good general purpose
: solution or not.
:
: As for starting it the first time that emacsclient is run, how to you
: propose doing this? Since emacsclient needs the server to be running to
: communicate with emacs, how can it instruct emacs to start the server
: when it has no mechanism to communicate over?

You can still use the --load switch when you start emacs from the client.
Or --eval. (I guess you have already seen this now, but for those reading
the thread I answer anyway.)

- Lennart

[Benjamin Riefenstahl]

Hi Lennard, Kim,


"Lennart Borgman" writes:
> 3) Addpm.exe should perhaps only add emacs_dir to the registry? Are
> the other values really used?

Isn't the opposite the case? When "emacs_dir" is not set it is
automatically replaced with a generated value. I had to remove it to
be able to switch between production and development versions easily.

The other pseudo-variables still make sense. Or are they replaced by
Windows-specific initializations in the Emacs code itself by now?
(Note that I am not saying that I would like that, just that I didn't
investigate if it was the case.)


Kim F. Storm writes:
> Once you have started emacs (from the start menu), what business do
> you have outside emacs (i.e. in Windoze land)?

;-)

> Sure, we should include a version of emacsclient which works with
> emacs' new internal emacsserver -- today I guess it will work fine
> with sockets (rather than mailslots which IIRC gnuserv uses).

I think we should keep in mind that sockets do tend to cause grief
with personal firewalls. Mailslots are not portable but they are in
effect more user-friendly and so reduce the need for support.


benny

[Lennart Borgman]

----- Original Message -----
From: "Benjamin Riefenstahl" <***@epost.de>

: "Lennart Borgman" writes:
: > 3) Addpm.exe should perhaps only add emacs_dir to the registry? Are
: > the other values really used?
:
: Isn't the opposite the case? When "emacs_dir" is not set it is
: automatically replaced with a generated value. I had to remove it to
: be able to switch between production and development versions easily.

Gnuclientw.exe looks for emacs_dir in the registry.


: The other pseudo-variables still make sense. Or are they replaced by
: Windows-specific initializations in the Emacs code itself by now?

The installation says that the registry values are not needed any more. It
seems to be true, except for that gnuclientw.exe needs it.


: I think we should keep in mind that sockets do tend to cause grief
: with personal firewalls. Mailslots are not portable but they are in
: effect more user-friendly and so reduce the need for support.

Could you please explain a bit more? I believe this is a serous issue since
many corporate portable pc:s will have personal firewalls. The ms docs for
mailslots says that this could be used between pc:s. Why is not the
firewalls involved there? It seems like it is not, but I am not sure why. Is
it some kind of bypassing of the network of both client and server are on
the some pc?

Unfortunately the old mailslot version does not have the -e switch for
executing lisp code which I mentioned in another message.

- Lennart

[Benjamin Riefenstahl]

Hi Lennart,


"Lennart Borgman" writes:
> Gnuclientw.exe looks for emacs_dir in the registry.

The versions of gnuclient that I use work fine when installed in the
same directory as emacs.exe.

> Benjamin Riefenstahl wrote:
> : I think we should keep in mind that sockets do tend to cause grief
> : with personal firewalls. Mailslots are not portable but they are
> : in effect more user-friendly and so reduce the need for support.
>
> [...] I believe this is a serous issue since many corporate portable
> pc:s will have personal firewalls.

*Any* stand-alone machine should have a personal firewall active these
days. The latest XP update even includes one as part of the OS.

> The ms docs for mailslots says that this could be used between
> pc:s. Why is not the firewalls involved there?

I don't know the details, I have never programmed or actively
researched mailslots.

But I doubt that local mailslots use IP. If I remember the history
right, mailslots where introduced long before IP could be treated as a
given. When mailslots work between separate machines, they are
probably bridged by some protocol proxy module.

Anyway, I wasn't advocating any particular implementation, I just
thought that whoever wants to provide an implementation at any level
should keep this issue in mind.


benny

[Jason Rumney]

Benjamin Riefenstahl <***@epost.de> writes:

> Isn't the opposite the case? When "emacs_dir" is not set it is
> automatically replaced with a generated value.

emacs_dir is always replaced with the generated value. The only time
it is not is if Emacs can't work out what the generated value should
be (you have installed in a non-standard directory).

The other values in the registry are the same as the defaults. Emacs
will actually work now with nothing in the registry, the main reason
for setting them in the install program is that older versions used
hard-coded paths (not relative to emacs_dir), which may cause
problems if they point to a different version, so we want to replace
the old values.

[Benjamin Riefenstahl]

Hi Jason,


Jason Rumney writes:
> emacs_dir is always replaced with the generated value. The only time
> it is not is if Emacs can't work out what the generated value should
> be (you have installed in a non-standard directory).

You mean if it is not running from within a standard installation tree
(in any top-level directory).

> The other values in the registry are the same as the defaults. Emacs
> will actually work now with nothing in the registry, the main reason
> for setting them in the install program is that older versions used
> hard-coded paths (not relative to emacs_dir), which may cause
> problems if they point to a different version, so we want to replace
> the old values.

So Lennart has a point there. The variables are not needed. They
should probably be removed by the installer, if they exist, instead of
overwriting them with unneeded values. Or am I missing something?


benny

[Jason Rumney]

Benjamin Riefenstahl <***@epost.de> writes:

> So Lennart has a point there. The variables are not needed. They
> should probably be removed by the installer, if they exist, instead of
> overwriting them with unneeded values. Or am I missing something?

Someone else has pointed out that some versions of gnuclient rely on
emacs_dir being set. If we are going to leave emacs_dir, we might as
well leave the others. It makes it easier for the user to see what
variables are available if they want to change anything.

[Lennart Borgman]

----- Original Message -----
From: "Jason Rumney" <***@gnu.org>
To: "Benjamin Riefenstahl" <***@epost.de>
Cc: "Emacs Devel" <emacs-***@gnu.org>
Sent: Sunday, October 24, 2004 10:02 PM
Subject: Re: Some findings and suggestion about Emacs on w32


: Benjamin Riefenstahl <***@epost.de> writes:
:
: > So Lennart has a point there. The variables are not needed. They
: > should probably be removed by the installer, if they exist, instead of
: > overwriting them with unneeded values. Or am I missing something?
:
: Someone else has pointed out that some versions of gnuclient rely on
: emacs_dir being set. If we are going to leave emacs_dir, we might as
: well leave the others. It makes it easier for the user to see what
: variables are available if they want to change anything.

It was me. But maybe this whole discussion is obsolete if emacsclient.exe is
ported to ms windows. I guess it will then recognize where it is loaded from
and that will make all the registry keys in Software\GNU\Emacs unnecessary.
Until that is done I think that no value except emacs_dir should be written.
Maybe cleaning can wait. (I do not know if the other values are ever read
now?)

- Lennart

[Jason Rumney]

"Lennart Borgman" <***@student.lu.se> writes:

> Until that is done I think that no value except emacs_dir should be written.
> Maybe cleaning can wait.

Noone has demonstrated any case where setting these variables causes
harm, so I suggest that we just leave things as they are now. There
are definite problems that could result from your suggestion if someone
is upgrading from a sufficiently old version of Emacs (I don't know
exactly how old that is, but I think 20.4 would probably be around the
mark).

> (I do not know if the other values are ever read now?)

Yes they are. All variables under the Software/GNU/Emacs key are read,
and treated as either environment variable or .xresources
equivalents.

[Guy Gascoigne-Piggford]

Also IIRC my version of gnuclient uses these variables to locate emacs
so that it can run it for the first time if it's not already running.
Since I think that gnuclient does stuff that emacsclient doesn't (such
as remote communication with emacs), I'd be a bit reluctant to break
stuff that gnuclient uses.

Guy

Jason Rumney wrote:

>"Lennart Borgman" <***@student.lu.se> writes:
>
>
>
>>Until that is done I think that no value except emacs_dir should be written.
>>Maybe cleaning can wait.
>>
>>
>
>Noone has demonstrated any case where setting these variables causes
>harm, so I suggest that we just leave things as they are now. There
>are definite problems that could result from your suggestion if someone
>is upgrading from a sufficiently old version of Emacs (I don't know
>exactly how old that is, but I think 20.4 would probably be around the
>mark).
>
>
>
>>(I do not know if the other values are ever read now?)
>>
>>
>
>Yes they are. All variables under the Software/GNU/Emacs key are read,
>and treated as either environment variable or .xresources
>equivalents.
>
>
>
>_______________________________________________
>Emacs-devel mailing list
>Emacs-***@gnu.org
>http://lists.gnu.org/mailman/listinfo/emacs-devel
>.
>
>
>

[Richard Stallman]

5) Emacs without gnuserv is in my opinion very crippled on w32. Gnuserv
should in my opinion be part of Emacs distribution for ms windows.

We do not have an "Emacs distribution for ms windows". The same Emacs
source code is used on all systems.

We could consider merging gnuserv into Emacs. That is not a trivial
decision. Why do you think this is desirable to do?

[Jason Rumney]

Richard Stallman <***@gnu.org> writes:

> We could consider merging gnuserv into Emacs. That is not a trivial
> decision. Why do you think this is desirable to do?

I seem to recall we considered it about 2 years ago. We managed to get
most, but not all papers for it. In the meantime, the extra features
that gnuclient/gnuserv has were added to emacsclient/emacsserver, so
there was no need to pusue it further, except for Windows where
gnuserv has been ported, but emacsserver has not. But it is probably
just as easy to make emacsserver/emacsclient work on Windows as it
would be to replace the parts of gnuserv that we cannot get papers for.

[Guy Gascoigne-Piggford]

Hmm, well I've not looked at emacsclient for nigh on ten years so it
doesn't exactly suprise me that there is no longer much difference
between gnuclient and emacsclient.

I'd be more than happy to take a look at the two of them again and see
what needs to be done to get emacsclient up and running on Windows. That
said I've been very happy with what gnuclient offers, which is why I've
not bothered changing it for quite a long time - heck I think that the
download on my site is dated something like 1996.

Anyway I'll take a look at see what's involved.

Guy

http://www.wyrdrune.com/gnuserv.html


Jason Rumney wrote:

>Richard Stallman <***@gnu.org> writes:
>
>
>
>>We could consider merging gnuserv into Emacs. That is not a trivial
>>decision. Why do you think this is desirable to do?
>>
>>
>
>I seem to recall we considered it about 2 years ago. We managed to get
>most, but not all papers for it. In the meantime, the extra features
>that gnuclient/gnuserv has were added to emacsclient/emacsserver, so
>there was no need to pusue it further, except for Windows where
>gnuserv has been ported, but emacsserver has not. But it is probably
>just as easy to make emacsserver/emacsclient work on Windows as it
>would be to replace the parts of gnuserv that we cannot get papers for.
>.
>
>
>

[Lennart Borgman]

I think that would be very good. It would make it more easy switching
between using Emacs on different os:es. And ms windows users too would have
a full Emacs in the distribution.

I would be glad if someone could explain how the server is started when
using emacsclient. Is it done the same way as when using gnuclient/gnuserv?
Could the server part be started automatically by giving arguments to
emacsclient or does it have to be in the startup files? Or is it done
automatically?

- Lennart


----- Original Message -----
From: "Guy Gascoigne-Piggford" <***@wyrdrune.com>
To: "Jason Rumney" <***@gnu.org>
Cc: "Lennart Borgman" <***@student.lu.se>; <***@gnu.org>;
<emacs-***@gnu.org>
Sent: Saturday, October 23, 2004 8:58 PM
Subject: Re: Some findings and suggestion about Emacs on w32


: Hmm, well I've not looked at emacsclient for nigh on ten years so it
: doesn't exactly suprise me that there is no longer much difference
: between gnuclient and emacsclient.
:
: I'd be more than happy to take a look at the two of them again and see
: what needs to be done to get emacsclient up and running on Windows. That
: said I've been very happy with what gnuclient offers, which is why I've
: not bothered changing it for quite a long time - heck I think that the
: download on my site is dated something like 1996.
:
: Anyway I'll take a look at see what's involved.
:
: Guy
:
: http://www.wyrdrune.com/gnuserv.html

[Jason Rumney]

Guy Gascoigne-Piggford <***@wyrdrune.com> writes:

> I'd be more than happy to take a look at the two of them again and see
> what needs to be done to get emacsclient up and running on
> Windows. That said I've been very happy with what gnuclient offers,
> which is why I've not bothered changing it for quite a long time -
> heck I think that the download on my site is dated something like
> 1996.
>
> Anyway I'll take a look at see what's involved.

Thanks. I think the main area that needs porting is the use of
unix domain sockets for communicating between emacsclient and the
server. I think there are some security issues with changing to
TCP or UDP sockets (this has been discussed in the past too), so
mailslots are probably the best replacement on Windows.

[Kim F. Storm]

Jason Rumney <***@gnu.org> writes:

> Guy Gascoigne-Piggford <***@wyrdrune.com> writes:
>
>> I'd be more than happy to take a look at the two of them again and see
>> what needs to be done to get emacsclient up and running on
>> Windows. That said I've been very happy with what gnuclient offers,
>> which is why I've not bothered changing it for quite a long time -
>> heck I think that the download on my site is dated something like
>> 1996.
>>
>> Anyway I'll take a look at see what's involved.

IIRC it has been discussed here on the list before.

>
> Thanks. I think the main area that needs porting is the use of
> unix domain sockets for communicating between emacsclient and the
> server.

Notice that the server is built-in using make-network-process.
As emacs doesn't support mail slots, you need to find an alternative.

I recall a discussion on emacs-devel about adding mailslots support in
make-network-process. Try google for it.

> I think there are some security issues with changing to
> TCP or UDP sockets (this has been discussed in the past too), so
> mailslots are probably the best replacement on Windows.

Try google for those too.

--
Kim F. Storm <***@cua.dk> http://www.cua.dk

[Dhruva Krishnamurthy]

Hello,

On Sun, 24 Oct 2004 14:46:42 +0200, Kim F. Storm <***@cua.dk> wrote:
> Notice that the server is built-in using make-network-process.
> As emacs doesn't support mail slots, you need to find an alternative.
> I recall a discussion on emacs-devel about adding mailslots support in
> make-network-process. Try google for it.
>

For records, I had sent a mail regarding mail-slots. IMO, it uses very
low level (BIOS) communication and hence might be the reason for
bypassing firewall. The link the mail I sent is below:
http://lists.gnu.org/archive/html/emacs-devel/2004-01/msg00602.html
I have implemented a mail-slot server and a client in one of my
projects (to control profiling on remote computers). It seems very
striaght forward and simple. The MSDN has sample code which I just
hacked to get a client/server working with in 1hr to 2hr. So, it must
be trivial for the experienced folks here on emacs devel.

with best regards,
dhruva

--
Proud FSF member: #1935
http://schemer.fateback.com/

[Lennart Borgman]

----- Original Message -----
From: "Dhruva Krishnamurthy" <***@gmail.com>

: For records, I had sent a mail regarding mail-slots. IMO, it uses very
: low level (BIOS) communication and hence might be the reason for
: bypassing firewall. The link the mail I sent is below:

I may be wrong but everything I read about network security suggests that
all network traffic goes through network ports. And firewalls are typically
watching the ports.

- Lennart

[Stefan]

> Thanks. I think the main area that needs porting is the use of
> unix domain sockets for communicating between emacsclient and the
> server. I think there are some security issues with changing to
> TCP or UDP sockets (this has been discussed in the past too), so
> mailslots are probably the best replacement on Windows.

Last time this came about "it was decided" that mailslots are *not* the way
to go. A much better approach is to address the security issues with TCP
sockets (UDP is not really an option) because this will then benefit to all
users rather than only to w32 ones.

The simplest way to get it to work is probably along the following lines:

The server side creates a socket on an OS-chosen TCP port. It then checks to
see which port was chosen, and writes it to a file, together with a unique
random key. Emacsclient then just has to read this same file to find the
port to connect to and to find the key to send as an authentication token.


Stefan

[Kim F. Storm]

Jason Rumney <***@gnu.org> writes:

> Thanks. I think the main area that needs porting is the use of
> unix domain sockets for communicating between emacsclient and the
> server. I think there are some security issues with changing to
> TCP or UDP sockets (this has been discussed in the past too), so
> mailslots are probably the best replacement on Windows.

The problem with TCP is that it may allow access from other users on
the same machine and from other machines in the network.

But it is easy to avoid connections from other machines -- just
use :host "127.0.0.1" when creating the emacs server socket, then
it only listens for connections from the local host.

And on windoze, I don't think there (typically) are that many
other users active at the same time...

Someone else pointed out that the use of a personal firewalls
on Windows should be an problem for using TCP for emacs server.

Actually, I think that it is an advantage, as the firewall will block
external access to the emacs server (as an extra security), but not
interfere with local access (to 127.0.0.1).

If mailslots allow external access bypassing the firewall, I think
that's a big problem speaking against mailslots.

--
Kim F. Storm <***@cua.dk> http://www.cua.dk

[Guy Gascoigne-Piggford]

Well the way that gnuserve used to deal with this same issue was a) to
have the option at build time of unix domain sockets, internet sockets
and SYSV messaging.

If you used internet sockets then it would read a file, by default
~/gnu_secure or the like I think, and from that file read a list of IP
addresses. If the connecting host wasn't listed in the file then the
connection was refused. I seem to remember allowing 127.0.0.1 to be
automatically authorised on NT, though it wasn't by default on Unix.

This looks like it deals with the security issue on a single user
machine, but still leaves things open on a multi user one.

Perhaps the best solution is to make server-start work in such a way
that it can not be connected to remotely, so leave it as is on Unix and
make the NT version use tcp restricting connections to localhost only.
Then provide something like server-start-net that uses tcp with a loaded
list of authorised hosts for those people who want to use it over their
network and understand the potential problems and required configuration.

Guy

Kim F. Storm wrote:

>Jason Rumney <***@gnu.org> writes:
>
>
>
>>Thanks. I think the main area that needs porting is the use of
>>unix domain sockets for communicating between emacsclient and the
>>server. I think there are some security issues with changing to
>>TCP or UDP sockets (this has been discussed in the past too), so
>>mailslots are probably the best replacement on Windows.
>>
>>
>
>The problem with TCP is that it may allow access from other users on
>the same machine and from other machines in the network.
>
>But it is easy to avoid connections from other machines -- just
>use :host "127.0.0.1" when creating the emacs server socket, then
>it only listens for connections from the local host.
>
>And on windoze, I don't think there (typically) are that many
>other users active at the same time...
>
>Someone else pointed out that the use of a personal firewalls
>on Windows should be an problem for using TCP for emacs server.
>
>Actually, I think that it is an advantage, as the firewall will block
>external access to the emacs server (as an extra security), but not
>interfere with local access (to 127.0.0.1).
>
>If mailslots allow external access bypassing the firewall, I think
>that's a big problem speaking against mailslots.
>
>
>

[Kim F. Storm]

Guy Gascoigne-Piggford <***@wyrdrune.com> writes:

> Well the way that gnuserve used to deal with this same issue was a) to
> have the option at build time of unix domain sockets, internet
> sockets and SYSV messaging.

You should modify emacsclient.c so that if AF_UNIX (primary choice) is
not available, it should use TCP. SYSV messaging is not an option
anymore.

>
> If you used internet sockets then it would read a file, by default
> ~/gnu_secure or the like I think, and from that file read a list of IP
> addresses. If the connecting host wasn't listed in the file then the
> connection was refused. I seem to remember allowing 127.0.0.1 to be
> automatically authorised on NT, though it wasn't by default on Unix.

If using TCP, accept 127.0.0.1 and nothing else (for now).

>
> This looks like it deals with the security issue on a single user
> machine, but still leaves things open on a multi user one.

Right. Stefan proposed a solution with a secret key that should be
exchanged between client and server; you would need to put that key
into a file that can only be read by the user.

I don't think we need to do this for 21.4 -- as the fix is only used
on (mostly) single user windoze.

>
> Perhaps the best solution is to make server-start work in such a way
> that it can not be connected to remotely, so leave it as is on Unix
> and make the NT version use tcp restricting connections to localhost
> only.

Yes, that's the primary task. And it should be fairly trivial.

FYI- In emacs server (Lisp side), you can use

(featurep 'make-network-process '(:family local))

to check whether unix sockets are supported -- if not, fallback to
using TCP from localhost.

> Then provide something like server-start-net that uses tcp with
> a loaded list of authorised hosts for those people who want to use it
> over their network and understand the potential problems and required
> configuration.

Indeed, there are all sorts of problems allowing external access like
that. For 21.4 we do NOT want to address those issues!

FYI- With a TCP socket, you can use (process-contact proc :remote) to
get the ip address of the remote client; you can then compare that to
the list of accepted addresses. [proc is the client process that is
created when emacsserver accepts the connection from the client].

--
Kim F. Storm <***@cua.dk> http://www.cua.dk

[Dhruva Krishnamurthy]

On Mon, 25 Oct 2004 11:29:33 +0200, Kim F. Storm <***@cua.dk> wrote:
> Guy Gascoigne-Piggford <***@wyrdrune.com> writes:
> If using TCP, accept 127.0.0.1 and nothing else (for now).
>
> >
> > This looks like it deals with the security issue on a single user
> > machine, but still leaves things open on a multi user one.
>
> Right. Stefan proposed a solution with a secret key that should be
> exchanged between client and server; you would need to put that key
> into a file that can only be read by the user.

For anyone interested, I have a crude implementation of a secret key
concept which was the outcome of my earlier discussion on the mailing
list. I can send the small lisp code I wrote which creates a new emacs
server (lisp) and a lisp client code which can be excuted by emacs in
batch mode (not a good solution though but just a proof of concept).

I have a link to it:
http://schemer.fateback.com/pub/emacs/emacsserver.el

with best regards,
dhruva

--
Proud FSF member: #1935
http://schemer.fateback.com/

[Stefan]

> I don't think we need to do this for 21.4 -- as the fix is only used
> on (mostly) single user windoze.

I guess if it's only used on w32 and we only bind to 127.0.0.1, it'd
be acceptable. But note that using a well-known port is a problem (we'd
need to get it registered, ...). Better to let the OS choose the port and
then store it in a file that emacsclient can read. At that point, adding
a secret random key to it isn't that much extra work.

> FYI- With a TCP socket, you can use (process-contact proc :remote) to
> get the ip address of the remote client; you can then compare that to
> the list of accepted addresses. [proc is the client process that is
> created when emacsserver accepts the connection from the client].

IP-address based security (which ws used by `xhost') is *bad*.
Don't go down that road.


Stefan

[Stefan]

>> Better to let the OS choose the port and
>> then store it in a file that emacsclient can read. At that point, adding
>> a secret random key to it isn't that much extra work.
> Don't you need to add support for that random key to the protocol ?

Yes, it's the "extra work" I was referring to.


Stefan

[Kim F. Storm]

Stefan <***@iro.umontreal.ca> writes:

>> I don't think we need to do this for 21.4 -- as the fix is only used
>> on (mostly) single user windoze.
>
> I guess if it's only used on w32 and we only bind to 127.0.0.1, it'd
> be acceptable. But note that using a well-known port is a problem (we'd
> need to get it registered, ...).

You don't need to register the port -- there are numerous well-known
but unregistered ports used everywhere. And this port is only going
to be used locally -- not critical at all.

If you need to make it configurable, use a emacs-server-port variable
in emacs, and an environment variable (or registry key) in the client.


> Better to let the OS choose the port and
> then store it in a file that emacsclient can read. At that point, adding
> a secret random key to it isn't that much extra work.

Don't you need to add support for that random key to the protocol ?


--
Kim F. Storm <***@cua.dk> http://www.cua.dk