Port of Emacs client / server programs to Windows NT

Port of Emacs client / server programs to Windows NT

[Neil Roberts]

Hi,

I've made a native port of the emacsclient and emacsserver programs
for Windows that uses named pipes instead of sockets. The programs are
drop-in replacements and should work if you just copy the exe files
into the bin/ folder of an Emacs 21 install.

The advantages of using named pipes instead of TCP are:

- The SID of the current user forms part of the name of the pipe so if
  you use your Windows in a multi-user environment then running
  multiple instances of the server won't collide with each other. The
  client will always connect to the server that was started by the
  same user.

- The access control list is set for the pipe so that only the current
  user can connect to it. Thus there is no security risk that another
  user will mess with your Emacs session, or even worse a remote
  user. There doesn't need to be any complicated authentication
  mechanisms because the authentication built in to Windows is used.

- It won't pop up a warning whining that the emacsserver is opening a
  port on systems that are running the Windows firewall.

- It doesn't require Winsock.

- It is much more like the original Unix implementation of the server.

Unfortunatly when I started writing it, I didn't realise that the
latest CVS no longer runs emacsserver as a separate process so it
won't work after Emacs 22 is released. Would it be worth making the
code in server.el resort back to running a separate process if the
:local sockets are not supported? Or maybe Emacs could be made to use
named pipes instead of sockets if a :local socket is created on
Windows as they seem to be the Windows equivalent of Unix domain
sockets?

If anyone is interested, the programs can be downloaded from here:

http://www.busydoingnothing.co.uk/weserver-0.1.zip

- Neil

Re: Port of Emacs client / server programs to Windows NT

[Jason Rumney]

> - It doesn't require Winsock.
>   
That might have been important 10 years ago, but now I doubt there are 
any installations of Windows 95 without the networking addon used by 
Emacs users.

>  Would it be worth making the
> code in server.el resort back to running a separate process if the
> :local sockets are not supported?
Maybe a week ago it would have been worth it, but not now that Juanma 
has completed his work.

> Or maybe Emacs could be made to use
> named pipes instead of sockets if a :local socket is created on
> Windows as they seem to be the Windows equivalent of Unix domain
> sockets?
>   
It might be worth adding cross-platform support for named pipes after 
the release.

Re: Port of Emacs client / server programs to Windows NT

[Stefan Monnier]

> The advantages of using named pipes instead of TCP are:

It has some disadvantages as well:

- They're specific to a non-free OS.
- TCP support is useful in its own right, to support remote connections.


        Stefan

Re: Port of Emacs client / server programs to Windows NT

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The advantages of using named pipes instead of TCP are:
>
> It has some disadvantages as well:
>
> - They're specific to a non-free OS.

Uh what?  Can you name a free general-purpose OS that does not have
named pipes?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Port of Emacs client / server programs to Windows NT

[Stefan Monnier]

>>> The advantages of using named pipes instead of TCP are:
>> It has some disadvantages as well:
>> - They're specific to a non-free OS.

> Uh what?  Can you name a free general-purpose OS that does not have
> named pipes?

Uh, ahem, I guess I got confused, sorry,


        Stefan

Re: Port of Emacs client / server programs to Windows NT

[Neil Roberts]

On Sun, Oct 29, 2006 at 07:56:30PM -0500, Stefan Monnier wrote:
> > The advantages of using named pipes instead of TCP are:
> 
> It has some disadvantages as well:
> 
> - They're specific to a non-free OS.

In a way, Windows named pipes are more like Unix domain sockets then
Unix named pipes (AKA FIFOs) because they disappear as soon as the
server process closes the pipe and so aren't proper file system
entries.

So instead of making 'local sockets do nothing on Windows because they
are not supported, it would seem to make sense to make it create named
pipes because they are as close to Unix domain sockets as there is in
Windows and they seem to be used as the equivalent.

> - TCP support is useful in its own right, to support remote
>   connections.

Granted that is true, so there would be no harm in leaving TCP support
and presumably implementing it for the Unix build as well. However as
the current default is to use named pipes and TCP sockets aren't even
implemented under the regular Unix version surely that implies that
the preferred solution is to use Unix domain sockets?

- Neil

Re: Port of Emacs client / server programs to Windows NT

[Lennart Borgman]

Neil Roberts wrote:
> Granted that is true, so there would be no harm in leaving TCP support
> and presumably implementing it for the Unix build as well. However as
> the current default is to use named pipes and TCP sockets aren't even
> implemented under the regular Unix version surely that implies that
> the preferred solution is to use Unix domain sockets?
>   

It may solve another problem on w32 too. The software firewalls jumps in 
if you are using TCP. As far as I understand it this will not happen 
with pipes (but I am not sure).

Can't w32 pipes have access protection on them too?

Re: Port of Emacs client / server programs to Windows NT

[Neil Roberts]

On Mon, Oct 30, 2006 at 09:56:56AM +0100, Lennart Borgman wrote:

> It may solve another problem on w32 too. The software firewalls
> jumps in if you are using TCP. As far as I understand it this will
> not happen with pipes (but I am not sure).

Yes, that's true.

> Can't w32 pipes have access protection on them too?

And that's also true. My implementation of emacsserver sets the access
control list so that only the current user can connect.

- Neil

Re: Port of Emacs client / server programs to Windows NT

[Lennart Borgman]

Neil Roberts wrote:
> On Mon, Oct 30, 2006 at 09:56:56AM +0100, Lennart Borgman wrote:
>
>   
>> It may solve another problem on w32 too. The software firewalls
>> jumps in if you are using TCP. As far as I understand it this will
>> not happen with pipes (but I am not sure).
>>     
>
> Yes, that's true.
>
>   
>> Can't w32 pipes have access protection on them too?
>>     
>
> And that's also true. My implementation of emacsserver sets the access
> control list so that only the current user can connect.
>   

Thanks Neil.

Juanma, I know very well that you have got the TCP version working now 
(since I have tested it), but are not the arguments above compelling? It 
looks to me like pipes is better to use on w32. That will avoid the 
security problems that could arise with TCP.

Keeping the TCP support for later use is however very good in my 
opinion. It has been a hard problem to solve for w32.

BTW why are not not TCP used on unixes? Is that because of security?

Re: Port of Emacs client / server programs to Windows NT

[Kim F. Storm]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Juanma, I know very well that you have got the TCP version working now
> (since I have tested it), but are not the arguments above compelling?
> It looks to me like pipes is better to use on w32. That will avoid the
> security problems that could arise with TCP.

Emacs core does not support named pipes, so server.el cannot use them.
So there's no current alternative to TCP for W32.

We may add named pipes in Emacs 23.

IMO, we should add the tcp support in Emacs 22 (before the next pretest).

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

Re: Port of Emacs client / server programs to Windows NT

[Lennart Borgman]

Kim F. Storm wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>   
>> Juanma, I know very well that you have got the TCP version working now
>> (since I have tested it), but are not the arguments above compelling?
>> It looks to me like pipes is better to use on w32. That will avoid the
>> security problems that could arise with TCP.
>>     
>
> Emacs core does not support named pipes, so server.el cannot use them.
> So there's no current alternative to TCP for W32.
>   

Would there be any difficulty adding this for w32?

> IMO, we should add the tcp support in Emacs 22 (before the next pretest).
>   

For unixes too?

Re: Port of Emacs client / server programs to Windows NT

[Jason Rumney]

Lennart Borgman wrote: 
> For unixes too?
It was my understanding that Juanma's changes allowed the use of TCP 
sockets for emacsclient and server.el on all platforms (unixes and GNU's 
not unixes included).

Re: Port of Emacs client / server programs to Windows NT

[Neil Roberts]

On Mon, Oct 30, 2006 at 11:00:07AM +0000, Jason Rumney wrote:

> >For unixes too?

> It was my understanding that Juanma's changes allowed the use of TCP
> sockets for emacsclient and server.el on all platforms (unixes and
> GNU's not unixes included).

The patch that Juanma made contains mostly Winsock specific code and
in fact (although I'm sure it wasn't intentional) breaks the Unix
build because it contains Winsock specific symbols like closesocket
and SOCKET in the main function of emacsclient without any #ifdefs.

- Neil

Re: Port of Emacs client / server programs to Windows NT

[Juanma Barranquero]

On 10/30/06, Neil Roberts <bpeeluk@yahoo.co.uk> wrote:

> The patch that Juanma made contains mostly Winsock specific code

I wouldn't say "mostly" because it does, in fact, contain little
additional socket code. Most of it was in place, and apart of the
initialization/finalization of Winsock (which is needed in Windows),
the main change was switching from file functions to send/recv.

> breaks the Unix
> build because it contains Winsock specific symbols like closesocket
> and SOCKET in the main function of emacsclient without any #ifdefs.

You're right, that's an oversight. I cannot test it on non-Windows
systems right now. That's why I'm going to commit the changes so the
problems can be found right now.

-- 
                    /L/e/k/t/u

Re: Port of Emacs client / server programs to Windows NT

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Mon, 30 Oct 2006 11:16:47 +0100
> Cc: Neil Roberts <bpeeluk@yahoo.co.uk>, emacs-devel@gnu.org,
> 	Juanma Barranquero <lekktu@gmail.com>
> 
> IMO, we should add the tcp support in Emacs 22 (before the next pretest).

Agreed.

Re: Port of Emacs client / server programs to Windows NT

[Stefan Monnier]

>> - They're specific to a non-free OS.
> So instead of making 'local sockets do nothing on Windows because they
> are not supported, it would seem to make sense to make it create named
> pipes because they are as close to Unix domain sockets as there is in
> Windows and they seem to be used as the equivalent.

The issue I was mentioning is just that as a general rule, if we can use
*code* non-specific to a non-free system, it's preferable.


        Stefan

Re: Port of Emacs client / server programs to Windows NT

[Stefan Monnier]

> Would it be worth making the code in server.el resort back to running
> a separate process if the :local sockets are not supported?

Looks ugly: the semantics is different (each client (i.e. connection) is
a different Elisp-process now), so making the code support both will
probably require a good bit of uglifying.


        Stefan