MS-Windows build broken in Fmake_network_process

MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

This change:

    revno: 99750
    author: Helmut Eller <eller.helmut@gmail.com>
    committer: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
    branch nick: trunk
    timestamp: Thu 2010-03-25 17:48:52 +0900
    message:
      Call `select' for interrupted `connect' rather than creating new socket (Bug#5173).

breaks the MS-Windows build:

The compiler emits a warning, and the linker errors out:

  gcc -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2     -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc -DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -o oo-spd/i386/process.o process.c
  process.c: In function `Fmake_network_process':
  process.c:3663: warning: passing arg 4 of `getsockopt' from incompatible pointer type

  oo-spd/i386/temacs1.a(process.o)(.text+0x3297): In function `Fmake_network_process':
  D:\gnu\bzr\emacs\trunk\src/process.c:3663: undefined reference to `getsockopt@20'

The compiler warning is because the prototype on Windows is:

  int getsockopt(SOCKET, int, int, char*, int*);

The linker error is because we would need to link against yet another
library to get this function.  But I don't think we should do that.
I'm actually bewildered why this code:

	    int len = sizeof xerrno;
	    eassert (FD_ISSET (s, &fdset));
	    if (getsockopt (s, SOL_SOCKET, SO_ERROR, &xerrno, &len) == -1)
	      report_file_error ("getsockopt failed", Qnil);

was used unconditionally when a very similar code in
wait_reading_process_output is clearly marked with a comment saying
not to use it except on GNU/Linux:

  #ifdef GNU_LINUX
		/* getsockopt(,,SO_ERROR,,) is said to hang on some systems.
		   So only use it on systems where it is known to work.  */
		{
		  int xlen = sizeof(xerrno);
		  if (getsockopt(channel, SOL_SOCKET, SO_ERROR, &xerrno, &xlen))
		    xerrno = errno;
		}
  #else

Would you please provide an alternative code (similar to what the
#else branch does in wait_reading_process_output) that will not use
getsockopt?

Re: MS-Windows build broken in Fmake_network_process

[Helmut Eller]

* Eli Zaretskii [2010-03-26 16:22+0100] writes:

> This change:
>
>     revno: 99750
>     author: Helmut Eller <eller.helmut@gmail.com>
>     committer: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
>     branch nick: trunk
>     timestamp: Thu 2010-03-25 17:48:52 +0900
>     message:
>       Call `select' for interrupted `connect' rather than creating new socket (Bug#5173).
>
> breaks the MS-Windows build:
>
> The compiler emits a warning, and the linker errors out:
>
>   gcc -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2     -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc -DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -o oo-spd/i386/process.o process.c
>   process.c: In function `Fmake_network_process':
>   process.c:3663: warning: passing arg 4 of `getsockopt' from incompatible pointer type
>
>   oo-spd/i386/temacs1.a(process.o)(.text+0x3297): In function `Fmake_network_process':
>   D:\gnu\bzr\emacs\trunk\src/process.c:3663: undefined reference to `getsockopt@20'
>
> The compiler warning is because the prototype on Windows is:
>
>   int getsockopt(SOCKET, int, int, char*, int*);
>
> The linker error is because we would need to link against yet another
> library to get this function.  But I don't think we should do that.
> I'm actually bewildered why this code:
>
> 	    int len = sizeof xerrno;
> 	    eassert (FD_ISSET (s, &fdset));
> 	    if (getsockopt (s, SOL_SOCKET, SO_ERROR, &xerrno, &len) == -1)
> 	      report_file_error ("getsockopt failed", Qnil);
>
> was used unconditionally when a very similar code in
> wait_reading_process_output is clearly marked with a comment saying
> not to use it except on GNU/Linux:
>
>   #ifdef GNU_LINUX
> 		/* getsockopt(,,SO_ERROR,,) is said to hang on some systems.
> 		   So only use it on systems where it is known to work.  */
> 		{
> 		  int xlen = sizeof(xerrno);
> 		  if (getsockopt(channel, SOL_SOCKET, SO_ERROR, &xerrno, &xlen))
> 		    xerrno = errno;
> 		}
>   #else
>
> Would you please provide an alternative code (similar to what the
> #else branch does in wait_reading_process_output) that will not use
> getsockopt?

getsockopt is not Linux specific; it's pretty much part of the BSD
socket API and is available on Windows too.  Why don't you just link it
in which would simplify wait_reading_process_output too?  Why do the
Unix ports have to pay the price for the Window port?

Helmut

Re: MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 26 Mar 2010 16:48:18 +0100
> 
> getsockopt is not Linux specific; it's pretty much part of the BSD
> socket API and is available on Windows too.  Why don't you just link it
> in which would simplify wait_reading_process_output too?  Why do the
> Unix ports have to pay the price for the Window port?

Perhaps you've missed this part of the fragment I posted:

		/* getsockopt(,,SO_ERROR,,) is said to hang on some systems.
		   So only use it on systems where it is known to work.  */

Re: MS-Windows build broken in Fmake_network_process

[Helmut Eller]

* Eli Zaretskii [2010-03-26 18:56+0100] writes:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 26 Mar 2010 16:48:18 +0100
>> 
>> getsockopt is not Linux specific; it's pretty much part of the BSD
>> socket API and is available on Windows too.  Why don't you just link it
>> in which would simplify wait_reading_process_output too?  Why do the
>> Unix ports have to pay the price for the Window port?
>
> Perhaps you've missed this part of the fragment I posted:
>
> 		/* getsockopt(,,SO_ERROR,,) is said to hang on some systems.
> 		   So only use it on systems where it is known to work.  */

Have you test case to reproduce it?

Helmut

Re: MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 26 Mar 2010 19:05:47 +0100
> 
> * Eli Zaretskii [2010-03-26 18:56+0100] writes:
> 
> >> From: Helmut Eller <eller.helmut@gmail.com>
> >> Cc: emacs-devel@gnu.org
> >> Date: Fri, 26 Mar 2010 16:48:18 +0100
> >> 
> >> getsockopt is not Linux specific; it's pretty much part of the BSD
> >> socket API and is available on Windows too.  Why don't you just link it
> >> in which would simplify wait_reading_process_output too?  Why do the
> >> Unix ports have to pay the price for the Window port?
> >
> > Perhaps you've missed this part of the fragment I posted:
> >
> > 		/* getsockopt(,,SO_ERROR,,) is said to hang on some systems.
> > 		   So only use it on systems where it is known to work.  */
> 
> Have you test case to reproduce it?

No.  And I don't know enough about this issue to work on the problem,
even if I did.

Re: MS-Windows build broken in Fmake_network_process

[Helmut Eller]

* Eli Zaretskii [2010-03-26 19:09+0100] writes:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 26 Mar 2010 19:05:47 +0100
>> 
>> * Eli Zaretskii [2010-03-26 18:56+0100] writes:
>> 
>> >> From: Helmut Eller <eller.helmut@gmail.com>
>> >> Cc: emacs-devel@gnu.org
>> >> Date: Fri, 26 Mar 2010 16:48:18 +0100
>> >> 
>> >> getsockopt is not Linux specific; it's pretty much part of the BSD
>> >> socket API and is available on Windows too.  Why don't you just link it
>> >> in which would simplify wait_reading_process_output too?  Why do the
>> >> Unix ports have to pay the price for the Window port?
>> >
>> > Perhaps you've missed this part of the fragment I posted:
>> >
>> > 		/* getsockopt(,,SO_ERROR,,) is said to hang on some systems.
>> > 		   So only use it on systems where it is known to work.  */
>> 
>> Have you test case to reproduce it?
>
> No.  And I don't know enough about this issue to work on the problem,
> even if I did.

Then link in getsockopt.  That's the most direct solution.

Helmut

Re: MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 26 Mar 2010 19:17:41 +0100
> 
> >> > 		/* getsockopt(,,SO_ERROR,,) is said to hang on some systems.
> >> > 		   So only use it on systems where it is known to work.  */
> >> 
> >> Have you test case to reproduce it?
> >
> > No.  And I don't know enough about this issue to work on the problem,
> > even if I did.
> 
> Then link in getsockopt.  That's the most direct solution.

Solution for what?  The previous code had no problems on Windows.  The
bug report that triggered the new code was deeply rooted in Posix
behavior; the solution is Posix-centric code, and was never tested on
Windows.  Why should it be run on Windows, and what ``problem'' will
that solve?

Re: MS-Windows build broken in Fmake_network_process

[Helmut Eller]

* Eli Zaretskii [2010-03-26 21:05+0100] writes:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 26 Mar 2010 19:17:41 +0100
>> 
>> >> > 		/* getsockopt(,,SO_ERROR,,) is said to hang on some systems.
>> >> > 		   So only use it on systems where it is known to work.  */
>> >> 
>> >> Have you test case to reproduce it?
>> >
>> > No.  And I don't know enough about this issue to work on the problem,
>> > even if I did.
>> 
>> Then link in getsockopt.  That's the most direct solution.
>
> Solution for what?  

The problem that you apparently can't compile it on Windows.

> The previous code had no problems on Windows.  The
> bug report that triggered the new code was deeply rooted in Posix
> behavior; the solution is Posix-centric code, and was never tested on
> Windows.  Why should it be run on Windows, 

Because Windows has the same BSD based socket API.

> and what ``problem'' will
> that solve?

a) that you can compile it b) that connect can be interrupted before the
connection is established.  If C-g or some other key is pressed during
connect this must be dealt with in some way.  Which the previous code
did not do correctly.

Helmut

Re: MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 26 Mar 2010 22:14:09 +0100
> 
> If C-g or some other key is pressed during connect this must be
> dealt with in some way.  Which the previous code did not do
> correctly.

Please see my other mail in this thread.  I think your view of what
happens on Windows when the user presses C-g is at least incomplete.

I don't argue about this code's correctness or necessity on Posix
systems.  I accept your and others' expert knowledge about that.  What
I'm saying is that this code is unneeded and possibly inappropriate on
Windows, where most of the system calls and mechanisms involved in
this issue work in an entirely different way under the hood.
Therefore, I submit that this code should have never been installed
unconditionally, at least not without discussing its applicability and
implications on Windows.

Re: MS-Windows build broken in Fmake_network_process

[Helmut Eller]

* Eli Zaretskii [2010-03-27 09:50+0100] writes:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 26 Mar 2010 22:14:09 +0100
>> 
>> If C-g or some other key is pressed during connect this must be
>> dealt with in some way.  Which the previous code did not do
>> correctly.
>
> Please see my other mail in this thread.  I think your view of what
> happens on Windows when the user presses C-g is at least incomplete.

Yes, right.

> I don't argue about this code's correctness or necessity on Posix
> systems.  I accept your and others' expert knowledge about that.  What
> I'm saying is that this code is unneeded and possibly inappropriate on
> Windows, where most of the system calls and mechanisms involved in
> this issue work in an entirely different way under the hood.
> Therefore, I submit that this code should have never been installed
> unconditionally, at least not without discussing its applicability and
> implications on Windows.

You seem to think that adding lots of #ifdefs is a good solution; I
don't think that.

The code in question is not executed unconditionally.  It's inside an
if(errno==EINTR).  If Windows' connect doesn't return EINTR the code is
still correct and simpler than adding #ifdefs.

Helmut

Re: MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Date: Sat, 27 Mar 2010 11:09:17 +0100
> 
> > I don't argue about this code's correctness or necessity on Posix
> > systems.  I accept your and others' expert knowledge about that.  What
> > I'm saying is that this code is unneeded and possibly inappropriate on
> > Windows, where most of the system calls and mechanisms involved in
> > this issue work in an entirely different way under the hood.
> > Therefore, I submit that this code should have never been installed
> > unconditionally, at least not without discussing its applicability and
> > implications on Windows.
> 
> You seem to think that adding lots of #ifdefs is a good solution

No, I don't.  I think it's an ugly solution which should only be taken
as a last resort.  That is why I asked you to provide an alternative
solution that didn't use getsockopt, like the one we already have in
wait_reading_process_output.  I hoped that such an alternative
solution would avoid the #ifdef.

Failing that, unless we have on board an expert on Windows sockets, or
could find one, who could explain how this affects Windows, what else
can we do except #ifdef this code away?  I do think that it is a bad
idea to apply code that was written on very specific assumptions about
the underlying low-level system behavior, to platforms whose behavior
is fundamentally different.

> The code in question is not executed unconditionally.  It's inside an
> if(errno==EINTR).  If Windows' connect doesn't return EINTR the code is
> still correct and simpler than adding #ifdefs.

I didn't say Windows will never generate EINTR at that point.  I
simply don't know enough about the subject to analyze all the possible
flows which could lead to that point, and make sure none of them will
ever generate EINTR.  The original code did have this portion, which
was also run on Windows:

      if (xerrno == EINTR)
	goto retry_connect;

Re: MS-Windows build broken in Fmake_network_process

[Helmut Eller]

* Eli Zaretskii [2010-03-27 12:11+0100] writes:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Date: Sat, 27 Mar 2010 11:09:17 +0100
>> 
>> > I don't argue about this code's correctness or necessity on Posix
>> > systems.  I accept your and others' expert knowledge about that.  What
>> > I'm saying is that this code is unneeded and possibly inappropriate on
>> > Windows, where most of the system calls and mechanisms involved in
>> > this issue work in an entirely different way under the hood.
>> > Therefore, I submit that this code should have never been installed
>> > unconditionally, at least not without discussing its applicability and
>> > implications on Windows.
>> 
>> You seem to think that adding lots of #ifdefs is a good solution
>
> No, I don't.  I think it's an ugly solution which should only be taken
> as a last resort.  That is why I asked you to provide an alternative
> solution that didn't use getsockopt, like the one we already have in
> wait_reading_process_output.  I hoped that such an alternative
> solution would avoid the #ifdef.

But the code in wait_reading_process_output does use getsockopt inside
#ifdef GNU_LINUX and a very odd way to extract some error code in the
#else branch.  Despite that it's also inside an #ifdef
NON_BLOCKING_CONNECT.  Note that src/s/ms-w32.h defines
BROKEN_NON_BLOCKING_CONNECT.  In summary that code path is hardly ever
executed.

> Failing that, unless we have on board an expert on Windows sockets, or
> could find one, who could explain how this affects Windows, what else
> can we do except #ifdef this code away?  

a) Trust the Windows API documentation for getsockopt.  Judging from the
documentation alone there's little reason to assume that it wouldn't
work in a similar way as on Unix.

or b) reproduce the scenario described in bug 5173 on Windows to see if
connect returns EINTR and getsockopt works.

> I do think that it is a bad
> idea to apply code that was written on very specific assumptions about
> the underlying low-level system behavior, to platforms whose behavior
> is fundamentally different.

Writing code as described in the API documentation seems reasonable to
me.

I also had asked some questions regarding this code in
http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00337.html but
nobody answered.  Then I filed bug 5173 that was ignored too.  When bug
5723 popped up I asked the same question again, bug again the
maintainers didn't know the answer but they decided to put some code
into trunk for testing.  I don't see what's wrong with this approach.

Helmut

Re: MS-Windows build broken in Fmake_network_process

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> Solution for what?  The previous code had no problems on Windows.  The
> bug report that triggered the new code was deeply rooted in Posix
> behavior; the solution is Posix-centric code, and was never tested on
> Windows.  Why should it be run on Windows, and what ``problem'' will
> that solve?

I conditioned the patch out for WINDOWSNT, for now, to avoid breaking
the Windows build.

However, could you investigate whether we could link in getsockopt in
the Windows build?  Although the original bug recipe in Bug#5173 does
not look relevant to Windows, Bug#5723 might be.

Re: MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Helmut Eller <eller.helmut@gmail.com>, emacs-devel@gnu.org
> Date: Fri, 26 Mar 2010 20:48:52 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Solution for what?  The previous code had no problems on Windows.  The
> > bug report that triggered the new code was deeply rooted in Posix
> > behavior; the solution is Posix-centric code, and was never tested on
> > Windows.  Why should it be run on Windows, and what ``problem'' will
> > that solve?
> 
> I conditioned the patch out for WINDOWSNT, for now, to avoid breaking
> the Windows build.

Thank you, it now builds again.

> However, could you investigate whether we could link in getsockopt in
> the Windows build?

Yes, we could (it just needs an additional -lws2 switch during
linking), assuming Someone(TM) knows how to resolve the issue with
incompatible pointers in the 4th arg (see my original report about the
broken build).  But what would this be good for, if we don't
understand the effect the added code will have on Windows?

> Although the original bug recipe in Bug#5173 does not look relevant
> to Windows, Bug#5723 might be.

I'm probably missing something, because the fix for Bug#5723 was
applied to the Windows build as well, and I can see no issues with
it.  That fix was about not starting atimers around the call to
`connect'.  How is this relevant to `getsockopt'?

Re: MS-Windows build broken in Fmake_network_process

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, we could (it just needs an additional -lws2 switch during
> linking)

We already use functions from ws2. I think effort was made in the past
to dynamically load it when required, because network support was not
always installed on early versions of Windows 95, and because loading
the library at startup caused a dialup dialog to pop up when the default
network connection was a dialup connection.  Neither of these is
probably a concern anymore, so it might be better to simplify the code
by with linking ws2 normally.

Re: MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Cc: Chong Yidong <cyd@stupidchicken.com>,  eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 28 Mar 2010 00:49:01 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Yes, we could (it just needs an additional -lws2 switch during
> > linking)
> 
> We already use functions from ws2. I think effort was made in the past
> to dynamically load it when required, because network support was not
> always installed on early versions of Windows 95, and because loading
> the library at startup caused a dialup dialog to pop up when the default
> network connection was a dialup connection.  Neither of these is
> probably a concern anymore, so it might be better to simplify the code
> by with linking ws2 normally.

How is this not a concern anymore?  We didn't stop supporting
Windows 9X, did we?

Re: MS-Windows build broken in Fmake_network_process

[Christoph]

On 3/27/2010 10:55 AM, Eli Zaretskii wrote:
> How is this not a concern anymore?  We didn't stop supporting
> Windows 9X, did we?
>    
Microsoft did. Why don't we? Are there plans on dropping support for 
these ancient OSs instead of kludging backwards compatibility into the 
system? I looked in the Windows source recently and I by the comments 
("On Windows NT...") some of that code it pretty old. Now, that doesn't 
mean it doesn't work but I am just wondering if the entire Windows API 
hasn't evolved in areas that we could take advantage of. Also, I think 
the longer one waits the harder it will be if Micro$oft at some point 
moves on with its API in a way that breaks compatibility with 
non-supported OSs (which is basically anything older than Windows 2000 
and probably soon to be XP).

Just curious,
Christoph

Re: MS-Windows build broken in Fmake_network_process

[Florian Beck]

Christoph wrote:
> On 3/27/2010 10:55 AM, Eli Zaretskii wrote:
>> How is this not a concern anymore?  We didn't stop supporting
>> Windows 9X, did we?
>>    
> Microsoft did. Why don't we? 

Hardware. Windows 9X is the main choice for old machines (like 64MB 
ram). Don't take that away without need.

Re: MS-Windows build broken in Fmake_network_process

[Óscar Fuentes]

Florian Beck <abstraktion@t-online.de> writes:

>>> How is this not a concern anymore?  We didn't stop supporting
>>> Windows 9X, did we?
>>>    
>> Microsoft did. Why don't we? 
>
> Hardware. Windows 9X is the main choice for old machines (like 64MB
> ram). Don't take that away without need.

If they run a 15 year old trashy OS, do they really demand the latest
and greatest Emacs? (which is a very fat application for such machines)

Re: MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 28 Mar 2010 01:37:29 +0100
> 
> Florian Beck <abstraktion@t-online.de> writes:
> 
> >>> How is this not a concern anymore?  We didn't stop supporting
> >>> Windows 9X, did we?
> >>>    
> >> Microsoft did. Why don't we? 
> >
> > Hardware. Windows 9X is the main choice for old machines (like 64MB
> > ram). Don't take that away without need.
> 
> If they run a 15 year old trashy OS, do they really demand the latest
> and greatest Emacs? (which is a very fat application for such machines)

We still support DOS, which is even trashier, remember?

I really don't understand this urge to be unkind to users of lesser
machines.  If there was some effort required from the active
developers, I could at least begin to understand.  But there isn't
any.

Re: MS-Windows build broken in Fmake_network_process

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Hardware. Windows 9X is the main choice for old machines (like 64MB
>> > ram). Don't take that away without need.
>>
>> If they run a 15 year old trashy OS, do they really demand the latest
>> and greatest Emacs? (which is a very fat application for such machines)
>
> We still support DOS, which is even trashier, remember?
>
> I really don't understand this urge to be unkind to users of lesser
> machines.  If there was some effort required from the active
> developers, I could at least begin to understand.  But there isn't
> any.

I understand the virtues of maintaining support for older systems, but
the prospect of maintaining support for non-networked Windows 95, when
there's no one to use or test or develop that support, does not fill me
with enthusiasm.

We have one developer---you---who can still make sure Emacs works on
DOS.  (And also DOS can be emulated these days.)  I'm not aware of
anyone who is still using and/or reporting bugs (let alone developing)
on a non-networked Windows 95 system.  Are you?

Re: MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> Date: Sun, 28 Mar 2010 14:55:02 -0400
> 
> I understand the virtues of maintaining support for older systems, but
> the prospect of maintaining support for non-networked Windows 95, when
> there's no one to use or test or develop that support, does not fill me
> with enthusiasm.

As far as I understood from what Jason said, the issue is not with
non-networked systems, the issue is with popping up the system's
dialup dialog when Emacs starts (and loads ws2_32.dll).  Apologies if
I misunderstood.

Re: MS-Windows build broken in Fmake_network_process

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

>> I understand the virtues of maintaining support for older systems, but
>> the prospect of maintaining support for non-networked Windows 95, when
>> there's no one to use or test or develop that support, does not fill me
>> with enthusiasm.
>
> As far as I understood from what Jason said, the issue is not with
> non-networked systems, the issue is with popping up the system's
> dialup dialog when Emacs starts (and loads ws2_32.dll).  Apologies if
> I misunderstood.

I may have been wrong about that problem being connected to the loading
time - it is connected with the init_winsock function being called (the
standard advice is to call it at startup, but we delay it in Emacs until
networking is actually used for the first time).  It should be easy to
test this problem - disable any network devices you have, and configure
a modem connection (you don't need to connect it to a phone line).

Re: MS-Windows build broken in Fmake_network_process

[Richard Stallman]

    If they run a 15 year old trashy OS, do they really demand the latest
    and greatest Emacs? (which is a very fat application for such machines)

Our decision has nothing to do with their "demands" -- and I doubt
they ever tried to make any "demands" on us.

If they would rather run the latest Emacs, then making the latest
Emacs run on their platform is a nice thing to do.

However, it is not a high priority for us, because supporting any
version of Windows is not a high priority for us.  We have no
commitment to support Windows 9, or Windows 7, or any version of
Windows.  People work on this if they want to do it, and they can
choose which platforms to support.

Re: MS-Windows build broken in Fmake_network_process

[Stephen J. Turnbull]

Richard Stallman writes:

 > However, it is not a high priority for us, because supporting any
 > version of Windows is not a high priority for us.  We have no
 > commitment to support Windows 9, or Windows 7, or any version of
 > Windows.  People work on this if they want to do it, and they can
 > choose which platforms to support.

The point is that some developers find the very need to make the
choice (eg, having to parse #ifdefs that refer to Windows-related
code) annoying, and would like to remove that support entirely from
the code.  You can't have "both in and out", and "in then out then in
then out" would make Emacs a laughingstock (not to mention being even
more annoying all around than parsing #ifdefs); someone must concede.

Re: MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Wed, 31 Mar 2010 13:57:31 +0900
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> Richard Stallman writes:
> 
>  > However, it is not a high priority for us, because supporting any
>  > version of Windows is not a high priority for us.  We have no
>  > commitment to support Windows 9, or Windows 7, or any version of
>  > Windows.  People work on this if they want to do it, and they can
>  > choose which platforms to support.
> 
> The point is that some developers find the very need to make the
> choice (eg, having to parse #ifdefs that refer to Windows-related
> code) annoying

I fail to see how these #ifdefs should be more annoying than similar
ones for Posix systems.  And the issue in this thread was not about
dropping Windows support altogether, only about supporting older
Windows systems, which contribute no #ifdefs whatsoever.

Re: MS-Windows build broken in Fmake_network_process

[Juanma Barranquero]

On Wed, Mar 31, 2010 at 10:38, Eli Zaretskii <eliz@gnu.org> wrote:

> I fail to see how these #ifdefs should be more annoying than similar
> ones for Posix systems.

Ah. Because they are *not* for Posix systems, you know.

    Juanma

Re: MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 31 Mar 2010 12:38:41 +0200
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>, emacs-devel@gnu.org
> 
> On Wed, Mar 31, 2010 at 10:38, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > I fail to see how these #ifdefs should be more annoying than similar
> > ones for Posix systems.
> 
> Ah. Because they are *not* for Posix systems, you know.

Thanks, now I get it.

Re: MS-Windows build broken in Fmake_network_process

[Stephen J. Turnbull]

Juanma Barranquero writes:
 > On Wed, Mar 31, 2010 at 10:38, Eli Zaretskii <eliz@gnu.org> wrote:
 > 
 > > I fail to see how these #ifdefs should be more annoying than similar
 > > ones for Posix systems.
 > 
 > Ah. Because they are *not* for Posix systems, you know.

C'mon, Juanma, don't egg him on.  It's not about POSIX vs. non-POSIX,
it's about free vs. non-free, which is long-standing Emacs policy (not
to mention the whole purpose for GNU in the first place).

It is still a good thing to support a bit of freedom in the unfree
world (as long as the net result is more migration from unfree to free
software), and it is still a good thing to provide free software to
people who are sufficiently poor that they remain dependent on Windows
9x systems, and may not be sufficiently literate in English or French
to have easy access to free software advocacy etc.  But you have to
balance those somewhat nebulous goods against the costs, which are
non-zero (though IMO they're nowhere near as big as the anti-Windows
activists would have it).

Re: MS-Windows build broken in Fmake_network_process

[Juanma Barranquero]

On Wed, Mar 31, 2010 at 17:39, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> C'mon, Juanma, don't egg him on.  It's not about POSIX vs. non-POSIX,
> it's about free vs. non-free, which is long-standing Emacs policy (not
> to mention the whole purpose for GNU in the first place).

I don't hear as much complaining about the Mac support...

> [...] the costs, which are
> non-zero (though IMO they're nowhere near as big as the anti-Windows
> activists would have it).

That's exactly what my comment implied.

    Juanma

Re: MS-Windows build broken in Fmake_network_process

[Stephen J. Turnbull]

Juanma Barranquero writes:
 > On Wed, Mar 31, 2010 at 17:39, Stephen J. Turnbull <stephen@xemacs.org> wrote:
 > 
 > > C'mon, Juanma, don't egg him on.  It's not about POSIX vs. non-POSIX,
 > > it's about free vs. non-free, which is long-standing Emacs policy (not
 > > to mention the whole purpose for GNU in the first place).
 > 
 > I don't hear as much complaining about the Mac support...

The Darwin kernel is free, and the Mac-only GUI support (ie, based on
the Carbon API) is being phased out in favor of the *Step API (which
still requires some Mac-specific code, I suppose, but it's going in
the right direction).

 > > [...] the costs, which are non-zero (though IMO they're nowhere
 > > near as big as the anti-Windows activists would have it).
 > 
 > That's exactly what my comment implied.

If you say so ... but as far as I can tell the people with any sense
of humor left the debate ages ago.  Explicit Is Better Than Implicit. ;-)

Re: MS-Windows build broken in Fmake_network_process

[Juanma Barranquero]

On Wed, Mar 31, 2010 at 19:30, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> The Darwin kernel is free, and the Mac-only GUI support (ie, based on
> the Carbon API) is being phased out in favor of the *Step API (which
> still requires some Mac-specific code, I suppose, but it's going in
> the right direction).

Whatever the color you paint it, all that code and effort goes mainly
to support running Emacs on Mac OS X.

> If you say so ... but as far as I can tell the people with any sense
> of humor left the debate ages ago.  Explicit Is Better Than Implicit. ;-)

I don't think Eli had any trouble getting my meaning...

    Juanma

OT: (was: MS-Windows build broken in Fmake_network_process)

[Stefan Monnier]

>> > C'mon, Juanma, don't egg him on.  It's not about POSIX vs. non-POSIX,
>> > it's about free vs. non-free, which is long-standing Emacs policy (not
>> > to mention the whole purpose for GNU in the first place).
>> I don't hear as much complaining about the Mac support...

FWIW, I consider Apple a greater threat to freedom than Microsoft.
This said, could you please move this thread elsewhere?
W.r.t supporting old Windows versions, I think we should not try to
support Windows-95 and if there's some code cleanup that can be made by
getting rid of Windows-95-specific code, then please go ahead.
Windows-98 support should maybe still stay for now.


        Stefan

Re: MS-Windows build broken in Fmake_network_process

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Date: Wed, 31 Mar 2010 13:57:31 +0900
 > > Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
 > > 
 > > Richard Stallman writes:
 > > 
 > >  > However, it is not a high priority for us, because supporting any
 > >  > version of Windows is not a high priority for us.  We have no
 > >  > commitment to support Windows 9, or Windows 7, or any version of
 > >  > Windows.  People work on this if they want to do it, and they can
 > >  > choose which platforms to support.
 > > 
 > > The point is that some developers find the very need to make the
 > > choice (eg, having to parse #ifdefs that refer to Windows-related
 > > code) annoying
 > 
 > I fail to see how these #ifdefs should be more annoying than similar
 > ones for Posix systems.

Nobody said that they were more annoying than other #ifdefs, only that
they are more annoying than no #ifdefs.  Haven't you recently removed
quite a few #ifdefs and #defines in the process of pruning away code
for supporting extinct *nix systems?  I know we have.

 > And the issue in this thread was not about dropping Windows support
 > altogether, only about supporting older Windows systems, which
 > contribute no #ifdefs whatsoever.

Whatever.  Eli, one of the reasons I work on XEmacs, not SXEmacs, is
that SXEmacs made the choice to remove *all* Windows support.  It's a
decision I disagree with, personally.  But I acknowledge their
motivation, and I think you and Richard are making a mistake by
ignoring the costs those #ifdefs and maintenance of the Windows code
do impose on non-Windows developers, and saying that it's only an
issue of whether Windows developers want to support it or not.

Re: MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
> Cc: emacs-devel@gnu.org
> Date: Thu, 01 Apr 2010 00:28:01 +0900
> 
> Haven't you recently removed quite a few #ifdefs and #defines in the
> process of pruning away code for supporting extinct *nix systems?

Dan did it, yes.  But again, extinct Windows systems contribute
exactly zero #ifdefs.

> I think you and Richard are making a mistake by
> ignoring the costs those #ifdefs and maintenance of the Windows code
> do impose on non-Windows developers, and saying that it's only an
> issue of whether Windows developers want to support it or not.

I don't ignore these costs.  I cannot speak for Richard, but I don't
think he ignores them, either.

I do think that the costs are not too significant, especially since
most of the Windows-specific code is in separate source files.  There
are currently 188 #ifdefs specific to Windows in non-Windows sources
of Emacs; for comparison, there are 112 "#ifdef HAVE_X_WINDOWS" and
100 "#ifdef HAVE_NS".

Re: MS-Windows build broken in Fmake_network_process

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > I do think that the costs are not too significant, especially since
 > most of the Windows-specific code is in separate source files.  There
 > are currently 188 #ifdefs specific to Windows in non-Windows sources
 > of Emacs; for comparison, there are 112 "#ifdef HAVE_X_WINDOWS" and
 > 100 "#ifdef HAVE_NS".

That's much more objective.  However, it's not a matter of just
counting them.  There are a lot more developers who are relatively
familiar with X Windows, and most POSIX-based developers will be
familiar with X.  They would like to be refactoring code, but they
can't do that if it crosses an #ifdef MSWINDOWS (or whatever the
#define is) unless they're willing to take a hack at implementing the
Windows version.  It was precisely such an exercise that triggered
this thread (or maybe it's a similar thread).

Of course in principle it's symmetrical; I'm sure there are
refactoring exercises you'd like to perform, but are deterred by the
need to fix up POSIX/X Windows/GNUStep code you don't know much
about.  However, this kind of friction, like any friction, imposes
more burden on the faster moving object -- which is the POSIX side.

Re: MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 01 Apr 2010 01:59:44 +0900
> 
> There are a lot more developers who are relatively
> familiar with X Windows, and most POSIX-based developers will be
> familiar with X.

I doubt that.  At least my personal experience is different: I know
almost nothing about X, but have no problem hacking the non-X parts of
Emacs, even where they are Posix specific.  It's no accident that the
first build of Emacs that supported bidi was a GNU/Linux TTY build.

> They would like to be refactoring code, but they can't do that if it
> crosses an #ifdef MSWINDOWS (or whatever the #define is) unless
> they're willing to take a hack at implementing the Windows version.

Refactoring of Windows code is done by the maintainers of the Windows
port.  Most of the other maintainers should probably use hideif or
some such to remove the Windows code from sight.

> It was precisely such an exercise that triggered this thread (or
> maybe it's a similar thread).

No, this thread was triggered by an attempt to ignore Windows-specific
aspects of networking and signals, not by some #ifdef'ed code.

Re: MS-Windows build broken in Fmake_network_process

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > It was precisely such a [refactoring] exercise that triggered
 > > this thread (or maybe it's a similar thread).
 > 
 > No, this thread was triggered by an attempt to ignore Windows-specific
 > aspects of networking and signals, not by some #ifdef'ed code.

Open your eyes and look at the forest, instead of just hugging the
trees, man.  Of course you can tie me up in knots with Emacs specifics
... but that doesn't do the Windows port any good.  *I* have no desire
to remove any part of Windows support from Emacs.

Re: MS-Windows build broken in Fmake_network_process

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     If they run a 15 year old trashy OS, do they really demand the latest
>     and greatest Emacs? (which is a very fat application for such machines)
>
> Our decision has nothing to do with their "demands" -- and I doubt
> they ever tried to make any "demands" on us.
>
> If they would rather run the latest Emacs, then making the latest
> Emacs run on their platform is a nice thing to do.
>
> However, it is not a high priority for us, because supporting any
> version of Windows is not a high priority for us.  We have no
> commitment to support Windows 9, or Windows 7, or any version of
> Windows.  People work on this if they want to do it, and they can
> choose which platforms to support.

Starting with Windows XP, Microsoft reserves the right to remotely
install software on your computer (including DRM), without
recompensation should they destroy your installation.  Also starting
with Windows XP, your system installation is rendered inoperative if you
move it to another computer, such as after hardware failure.  Basically,
Microsoft did a lot to promote "plug&play", then made sure that you
can't reap the benefits.

For that reason, people with some interest in the rights to their own
computer may keep an older Windows installation around for software that
can't run on free platforms.  Usually off-net since Microsoft does no
security updates to those versions.

Since you can't acquire any of those old Windows versions anymore, it is
more or less chance which version you kept around.  There is more or
less a progression in the extensiveness with which the Microsoft EULA
forces you to abandon your rights and your own hardware to their whim.
So with quite a number of versions, people might say "this is where I
draw the line with regard how much I want my personal rights be trampled
on".

It probably does not mean much with regard for supporting Emacs,
however: I don't think that people use older Windows versions except for
isolated applications.

-- 
David Kastrup

Re: MS-Windows build broken in Fmake_network_process

[Richard Stallman]

    For that reason, people with some interest in the rights to their own
    computer may keep an older Windows installation around for software that
    can't run on free platforms.  Usually off-net since Microsoft does no
    security updates to those versions.

If there is a substantial pattern of running Emacs on Windows 9 on machines
off the net, that means it would be useful to support Windows 9.

We still have no commitment to support any nonfree operating system.
The users who want this are welcome to work on it.

Re: MS-Windows build broken in Fmake_network_process

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     For that reason, people with some interest in the rights to their own
>     computer may keep an older Windows installation around for software that
>     can't run on free platforms.  Usually off-net since Microsoft does no
>     security updates to those versions.
>
> If there is a substantial pattern of running Emacs on Windows 9 on
> machines off the net, that means it would be useful to support Windows
> 9.

As I said, I doubt that the installations I am thinking of (like mine)
have need for a text editor.

It's probably more relevant that people may be running old systems in
the third world, and "upgrading" is not an option due to computing
resources and (non-OEM) operating system pricing (if people can be
bothered about the legality of their copies).

There probably are not many Emacs users on those systems either.

> We still have no commitment to support any nonfree operating system.
> The users who want this are welcome to work on it.

Well, I thought that the topic of _this_ discussion was at what time it
becomes ok to rip out existing support for older systems.

I have no idea.  I was just countering the statement that there is no
use case for older Windows systems.  With me, the licensing conditions
of newer systems (and their net-requiring phone-home functionality I
can't afford without the ability to do security updates) are
prohibitive.  But my use cases indeed do not require Emacs.

-- 
David Kastrup

Re: MS-Windows build broken in Fmake_network_process

[Christoph]

On 3/27/2010 6:12 PM, Florian Beck wrote:
> Christoph wrote:
>> On 3/27/2010 10:55 AM, Eli Zaretskii wrote:
>>> How is this not a concern anymore?  We didn't stop supporting
>>> Windows 9X, did we?
>> Microsoft did. Why don't we? 
>
> Hardware. Windows 9X is the main choice for old machines (like 64MB 
> ram). Don't take that away without need.

Why would you need to run Emacs 24 on hardware that old? Wouldn't Emacs 
21, 22.3 or 23.2 suffice for your use case or until you upgrade your 
hardware?

The need is in my opinion a growing pain in the rear-end to support this 
backwards compatibility.

Re: Windows 9X compatibility

[Eli Zaretskii]

> Date: Sat, 27 Mar 2010 18:39:01 -0600
> From: Christoph <cschol2112@googlemail.com>
> 
> The need is in my opinion a growing pain in the rear-end to support this 
> backwards compatibility.

This argument can only be persuasive if it comes from someone who
personally experienced this pain, which could only be true if they are
active maintainers of the MS-Windows port.

Re: Windows 9X compatibility

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 27 Mar 2010 18:39:01 -0600
>> From: Christoph <cschol2112@googlemail.com>
>>
>> The need is in my opinion a growing pain in the rear-end to support this 
>> backwards compatibility.
>
> This argument can only be persuasive if it comes from someone who
> personally experienced this pain, which could only be true if they are
> active maintainers of the MS-Windows port.

Maybe the fact that there are no more active maintainers of the
MS-Windows port is somewhat related to the pain in the rear that W9X
compatbility is?

Just an hypothesis.

Speaking for myself, the W9X compatibility requirement means that I
prefer to restrict my very occasional Emacs hacking to Elisp code, even
if I have experience with the Windows API. First, I don't have a machine
for testing. Second, the W9X API is so broken and has some many quirks
that, apart from the permanent browsing of the MSDN it requires, a
trivial change can be easily turned into a long session of mailing list
archive archeology. Third, W9X compatibility means that you either have
to refrain to implement features based on modern APIs or #ifdef them,
which greatly adds to the maintenance burden.

Furthermore, the claim about lots of *running* machines on
underdeveloped areas still having W9X is dubious now. AFAIK, people
transitioned to Windows XP when powerful enough obsoleted machines
arrived, which started to happen about 6 years ago. For the time Emacs
24 is out, the percentage of W9X machines out there will be almost zero,
for the simple reason that computers doesn't last forever (no pun
intended)

Finally, if someone has a weak machine, there are some fine GNU/Linux
distros tailored for his needs. I doubt that someone who insists on
using W9X instead of a modern GNU/Linux distro is interested on being up
to date with Emacs releases, or even on using Emacs at all.

Re: Windows 9X compatibility

[Lennart Borgman]

On Sun, Mar 28, 2010 at 4:59 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>
> Maybe the fact that there are no more active maintainers of the
> MS-Windows port is somewhat related to the pain in the rear that W9X
> compatbility is?


I think this might be true. I saw some signs of that when I first
started looking into the ms-windows port.


> Furthermore, the claim about lots of *running* machines on
> underdeveloped areas still having W9X is dubious now. AFAIK, people
> transitioned to Windows XP when powerful enough obsoleted machines
> arrived, which started to happen about 6 years ago.


The first intranet web-server I built was running on w9x. Due to
severe problem with ms word background conversion to html on this pc I
switched to experminenting on that old pc with nt4. To my surprise nt4
required a lot less resources so it ran much smoother on the old pc.

So I doubt that we need to support w9x because of old pc:s. But maybe
someone is running w9x just because they can't get their hand on nt4
or xp of course.

Re: Windows 9X compatibility

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 28 Mar 2010 16:59:54 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Sat, 27 Mar 2010 18:39:01 -0600
> >> From: Christoph <cschol2112@googlemail.com>
> >>
> >> The need is in my opinion a growing pain in the rear-end to support this 
> >> backwards compatibility.
> >
> > This argument can only be persuasive if it comes from someone who
> > personally experienced this pain, which could only be true if they are
> > active maintainers of the MS-Windows port.
> 
> Maybe the fact that there are no more active maintainers of the
> MS-Windows port is somewhat related to the pain in the rear that W9X
> compatbility is?

Who said there are no more active maintainers?  Please take a look at
the ChangeLog files to have some reality check.

> First, I don't have a machine for testing.

Neither do I.  There's no requirement to test the code on Windows 9X,
only not to use code that we _know_in_advance_ will break W9X.

> Second, the W9X API is so broken and has some many quirks that,
> apart from the permanent browsing of the MSDN it requires, a trivial
> change can be easily turned into a long session of mailing list
> archive archeology.

There's no requirements to use W9X-specific APIs.  We use APIs that
are available on all Windows systems, as much as possible.  When
that's impossible, we use the advanced APIs, and the affected Emacs
features are simply not available on W9X or display an error message.
We have quite a few such features already.  Use of NT file security in
file ops is one example that comes to mind; the "load average" display
on the mode line is another.

The only requirement is to use such features in a way that doesn't
crash Emacs on Windows 9X.  For example, we load system libraries with
error checking, instead of blindly assuming they are always available.

> Third, W9X compatibility means that you either have
> to refrain to implement features based on modern APIs or #ifdef them

See above: this is false.  (And #ifdef is not a solution anyway,
because a run-time check is needed.)

> which greatly adds to the maintenance burden.

True, there is some maintenance burden, but I personally find it
insignificant.  The code to load a library safely and invoke functions
that may not exist is very simple, almost boilerplate, and each
additional API that needs this treatment just needs more-or-less
copy-pasted more of the same.

Once again, I'm bewildered by the intense reaction to this issue,
given the facts.

Re: Windows 9X compatibility

[Juanma Barranquero]

On Sun, Mar 28, 2010 at 17:56, Eli Zaretskii <eliz@gnu.org> wrote:

> True, there is some maintenance burden, but I personally find it
> insignificant.  The code to load a library safely and invoke functions
> that may not exist is very simple, almost boilerplate, and each
> additional API that needs this treatment just needs more-or-less
> copy-pasted more of the same.
>
> Once again, I'm bewildered by the intense reaction to this issue,
> given the facts.

FWIW, I agree.

    Juanma

Re: Windows 9X compatibility

[joakim]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Sun, Mar 28, 2010 at 17:56, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> True, there is some maintenance burden, but I personally find it
>> insignificant.  The code to load a library safely and invoke functions
>> that may not exist is very simple, almost boilerplate, and each
>> additional API that needs this treatment just needs more-or-less
>> copy-pasted more of the same.
>>
>> Once again, I'm bewildered by the intense reaction to this issue,
>> given the facts.
>
> FWIW, I agree.
>
>     Juanma
>
>

I have done some pretty intense C level Emacs hacking, regarding image
support and the display engine. The many different supported plattforms
does make the code harder to read, and I dont generally know if my code
works on other platforms than my own. OTOH the great cross platform
support is one of the aspects that made me use Emacs initially, so its a
worthwile cause to keep it working on many platforms.

Since dynamic linking has now been approved for the Emacs core, maybe
some plugin architecture could be designed now, that makes it easier to
support different platforms.


-- 
Joakim Verona

Re: Windows 9X compatibility

[Richard Stallman]

    Since dynamic linking has now been approved for the Emacs core,

That is a misunderstanding.  It has not been approved YET.

We have a method which we are using in GCC.  Lawyers studied it
in the context of GCC.  Now they are studying how far we can
generalize it.  I hope it will be reliable to use this in Emacs,
but we don't know that yet.

Re: Windows 9X compatibility

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Maybe the fact that there are no more active maintainers of the
>> MS-Windows port is somewhat related to the pain in the rear that W9X
>> compatbility is?
>
> Who said there are no more active maintainers?

"no more" in the sense "more than we have today". I was not saying that
there are no people working on the Windows port.

>> First, I don't have a machine for testing.
>
> Neither do I.  There's no requirement to test the code on Windows 9X,
> only not to use code that we _know_in_advance_ will break W9X.

... and precisely gaining this information is difficult, because you
must read the documentation for every API call and even then you can hit
a bug, which is not rare in W9X (and before you say that any API has
this problem, well, yes, but not to the extent of W9X).

> There's no requirements to use W9X-specific APIs.

Sorry, but do you have experience writing Windows raw API code on its
successive incarnations since Windows 95? I'm starting to think you have
not. Looking at the set of functions that makes the Windows API, those
available on W95 are, for the most part, a proper subset of those
available on XP. So, in theory, and unless you use certain obsoleted
parts of the API (shell interaction, for instance, which is not part of
the proper Windows OS API anyways) you are fine developing for W95. BUT
there are two problems: quite a few W9X functions were extended on
successive Windows versions with new features, so checking that the
function is available on W9X is not enough, you must check that the way
you intend to use the function is supported by W95. Often those
differences are so fundamental that you must split the usage of the API
call, one instance for W9X and another for NT (if you are
lucky). Second, bugs are so frequent in the W9X API that, to all
practical uses, quite a few functions have a non-documented behaviour
that you must be aware of.

There are certain areas where the problem is not serious enough to
notice (mostly GDI) but threading, networking and I/O in general is a
minefield.

[snip]

>> which greatly adds to the maintenance burden.
>
> True, there is some maintenance burden, but I personally find it
> insignificant.  The code to load a library safely and invoke functions
> that may not exist is very simple, almost boilerplate, and each
> additional API that needs this treatment just needs more-or-less
> copy-pasted more of the same.

This is no solution at all for the general problem. A pure W32 API
application made for W95 will build fine with modern versions of the
SDK, and XP (or Windows7) will execute it without complaining. But
chances are that it will not behave as it did on W95.

> Once again, I'm bewildered by the intense reaction to this issue,
> given the facts.

If current Windows maintainers are fine with this scenario, they are the
people who keep the Emacs port on a great shape *now* so they have the
right to set the policy. OTOH, it would be a good thing for the Emacs
project to lower the entry barrier as much as possible, as I previously
said discussing other topics. Is future W9X support important enough to
risk the loss of just *one* prospective contributor?

Re: Windows 9X compatibility

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 28 Mar 2010 21:57:02 +0200
> 
> >> First, I don't have a machine for testing.
> >
> > Neither do I.  There's no requirement to test the code on Windows 9X,
> > only not to use code that we _know_in_advance_ will break W9X.
> 
> ... and precisely gaining this information is difficult, because you
> must read the documentation for every API call and even then you can hit
> a bug, which is not rare in W9X (and before you say that any API has
> this problem, well, yes, but not to the extent of W9X).

You read too much into our reluctance to drop W9X support.  There's no
conscious effort to support W9X that would justify such a research.
We _try_ not to break W9X on purpose, but eventually testing and
reporting bugs (and sometimes, even debugging them) is up to the users
of those systems.  AFAIK, none of the active contributors to the
Windows port has access to a W9X system these days.

> > There's no requirements to use W9X-specific APIs.
> 
> Sorry, but do you have experience writing Windows raw API code on its
> successive incarnations since Windows 95? I'm starting to think you have
> not. Looking at the set of functions that makes the Windows API, those
> available on W95 are, for the most part, a proper subset of those
> available on XP. So, in theory, and unless you use certain obsoleted
> parts of the API (shell interaction, for instance, which is not part of
> the proper Windows OS API anyways) you are fine developing for W95. BUT
> there are two problems: quite a few W9X functions were extended on
> successive Windows versions with new features, so checking that the
> function is available on W9X is not enough, you must check that the way
> you intend to use the function is supported by W95. Often those
> differences are so fundamental that you must split the usage of the API
> call, one instance for W9X and another for NT (if you are
> lucky). Second, bugs are so frequent in the W9X API that, to all
> practical uses, quite a few functions have a non-documented behaviour
> that you must be aware of.

We are nowhere near such an investment.  Grep the sources for
is_windows_9x: you will see that it is used in some 2 dozen places to
return a failure indication where an advanced API is not available.
There are only two places in Emacs sources where W9X gets more than a
one-line code specific to it.  That's all there is to it.

> Is future W9X support important enough to risk the loss of just
> *one* prospective contributor?

No, it isn't.  But I saw no evidence of such a risk until now.  As I
tried to explain above, the bar is much lower than you seem to think,
because we do not promise any high-quality support for W9X that you
have in mind.  We just don't want to do anything that will surely
remove any possibility to run Emacs on these systems.

Re: Windows 9X compatibility

[Juanma Barranquero]

On Sun, Mar 28, 2010 at 22:32, Eli Zaretskii <eliz@gnu.org> wrote:

> AFAIK, none of the active contributors to the
> Windows port has access to a W9X system these days.

Hmm, I just remembered... About a month ago I tried 23.1 (the standard
binary tarball distribution) on a Windows 95 and it refused to start;
had trouble loading a library. Not some uncommon library, though, but
kernel32 or somesuch. Unfortunately, I have no developer tools on that
computer and only occasional access to it, so I haven't been able to
look into the problem. I'll try to gather more information next time,
but it'd be great to have confrmation that it *does* work on W95 right
now.

    Juanma

Re: Windows 9X compatibility

[Christoph]

On 3/28/2010 1:21 AM, Eli Zaretskii wrote:
>> Date: Sat, 27 Mar 2010 18:39:01 -0600
>> From: Christoph<cschol2112@googlemail.com>
>>
>> The need is in my opinion a growing pain in the rear-end to support this
>> backwards compatibility.
>>      
> This argument can only be persuasive if it comes from someone who
> personally experienced this pain, which could only be true if they are
> active maintainers of the MS-Windows port.
>    
You are right. I have not experienced this pain myself, but I have read 
the source. I see the function "is_windows_9x()" and where it is being 
used and other comments like "Visual Studio 6 cannot do this", "MSVC's 
stat doesnt support UNC and has other bugs" which led to code being 
added to eliminate these deficiencies and support old OSs like Win9x or 
old compilers like MSVC 6.

I am just wondering, if this really needs to be there and if anybody 
ever looks into replacing these functions with native Windows code in 
the latest version of their development tool chains. If it makes the 
code cleaner and less prone to breaking with added features or bugs, 
wouldn't that be worth it?

Also, I am not saying the guy looking into something that couldn't be 
myself. In fact, I guess the whole discussion was prompted by me trying 
to find a way to contribute. Maybe I should have picked a less 
controversial subject matter. ;)

Christoph

Re: Windows 9X compatibility

[Eli Zaretskii]

> Date: Sun, 28 Mar 2010 13:27:03 -0600
> From: Christoph <cschol2112@googlemail.com>
> CC: emacs-devel@gnu.org
> 
> You are right. I have not experienced this pain myself, but I have read 
> the source. I see the function "is_windows_9x()" and where it is being 
> used

is_windows_9x is a 12-line function whose all calls but the very first
one just return the value of a static variable.

> and other comments like "Visual Studio 6 cannot do this", "MSVC's 
> stat doesnt support UNC and has other bugs" which led to code being 
> added to eliminate these deficiencies and support old OSs like Win9x or 
> old compilers like MSVC 6.

The latter problem has nothing to do with old compilers: the Windows
implementation of `stat' leaves a lot to be desired, for a
Posix-minded program such as Emacs.  Which is why Emacs has its own
version of `stat' that doesn't rely on the one supplied by Microsoft.
The problem with `stat' exists on all versions of Windows, not just on
Windows 9X.

> I am just wondering, if this really needs to be there and if anybody 
> ever looks into replacing these functions with native Windows code in 
> the latest version of their development tool chains. If it makes the 
> code cleaner and less prone to breaking with added features or bugs, 
> wouldn't that be worth it?

Maybe.  But it's hard to talk about this on this general level.
Specific suggestions to remove old compatibility code are welcome.

> Also, I am not saying the guy looking into something that couldn't be 
> myself. In fact, I guess the whole discussion was prompted by me trying 
> to find a way to contribute. Maybe I should have picked a less 
> controversial subject matter. ;)

Your contributions, past and future, are welcome.  Thanks.

Re: Windows 9X compatibility

[Christoph]

On 3/28/2010 2:18 PM, Eli Zaretskii wrote:
> is_windows_9x is a 12-line function whose all calls but the very first
> one just return the value of a static variable.
>    
Right, I was just commenting on the mere existence of such function and 
its use to disable certain features, which in my mind seems kludgy for 
an OS that has been abandoned by its manufacturer, i.e. no more updates, 
bugfixes etc. But, I think your explanations in response to Oscars email 
made the intent of this clearer for me, i.e. what the status of support 
for legacy systems like Win9x is.

> The latter problem has nothing to do with old compilers: the Windows
> implementation of `stat' leaves a lot to be desired, for a
> Posix-minded program such as Emacs.  Which is why Emacs has its own
> version of `stat' that doesn't rely on the one supplied by Microsoft.
> The problem with `stat' exists on all versions of Windows, not just on
> Windows 9X.
>    
I just googled the UNC issue with Windows' stat and found that it 
actually supports UNC paths (in recent implementations at least), but 
there might be some other issues that I don't know about. Anyway, those 
were examples where comments led me to believe that there might be a 
cleaner solution for this nowadays, compared to what was available 15 
years ago or when the code was initially written.
> Maybe.  But it's hard to talk about this on this general level.
> Specific suggestions to remove old compatibility code are welcome.
>    
Yes, I will dig around some more and see what I come up with. Which 
should help me get familiar with the code.
> Your contributions, past and future, are welcome.  Thanks.
>    
Thank you.

Re: Windows 9X compatibility (was: MS-Windows build broken in Fmake_network_process)

[Eli Zaretskii]

> Date: Sat, 27 Mar 2010 16:28:13 -0600
> From: Christoph <cschol2112@googlemail.com>
> 
> On 3/27/2010 10:55 AM, Eli Zaretskii wrote:
> > How is this not a concern anymore?  We didn't stop supporting
> > Windows 9X, did we?
> >    
> Microsoft did. Why don't we?

Last time we checked, the majority of machines in the 3rd world used
Windows 9X.  The GNU Project doesn't want to be unfriendly to computer
users in those countries.  Maybe things have changed, but someone will
need to show figures, and ask FSF to reconsider.

> Are there plans on dropping support for these ancient OSs instead of
> kludging backwards compatibility into the system?

What ``kludging backwards compatibility''?  All we do is load some
libraries dynamically instead of linking against them statically.  The
rest of back-compatible code was written years ago and needs zero
maintenance.

Re: MS-Windows build broken in Fmake_network_process

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jason Rumney <jasonr@gnu.org>
>> Cc: Chong Yidong <cyd@stupidchicken.com>,  eller.helmut@gmail.com,  emacs-devel@gnu.org
>> Date: Sun, 28 Mar 2010 00:49:01 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Yes, we could (it just needs an additional -lws2 switch during
>> > linking)
>> 
>> We already use functions from ws2. I think effort was made in the past
>> to dynamically load it when required, because network support was not
>> always installed on early versions of Windows 95, and because loading
>> the library at startup caused a dialup dialog to pop up when the default
>> network connection was a dialup connection.  Neither of these is
>> probably a concern anymore, so it might be better to simplify the code
>> by with linking ws2 normally.
>
> How is this not a concern anymore?  We didn't stop supporting
> Windows 9X, did we?

Does anyone still install it without ticking the networking support box,
as was still common in 1995?

Re: MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Date: Sun, 28 Mar 2010 15:33:43 +0800
> Cc: emacs-devel@gnu.org
> 
> >> We already use functions from ws2. I think effort was made in the past
> >> to dynamically load it when required, because network support was not
> >> always installed on early versions of Windows 95, and because loading
> >> the library at startup caused a dialup dialog to pop up when the default
> >> network connection was a dialup connection.  Neither of these is
> >> probably a concern anymore, so it might be better to simplify the code
> >> by with linking ws2 normally.
> >
> > How is this not a concern anymore?  We didn't stop supporting
> > Windows 9X, did we?
> 
> Does anyone still install it without ticking the networking support box,
> as was still common in 1995?

Is there any good way of finding this out?  If not, we will probably
never know.  And what about old installations -- they could still want
to upgrade their Emacs.

What about the issue that led to the code in question -- do you know
if `connect' can be interrupted by C-g on Windows?  Do you have an
opinion about applicability of that code to Windows?

Re: MS-Windows build broken in Fmake_network_process

[Richard Stallman]

    > Does anyone still install it without ticking the networking support box,
    > as was still common in 1995?

It seems unlikely to me that many people use computers today without
ever connecting them to the Internet in any fashion.  Even old
computers.

    Is there any good way of finding this out?

We could put in something in the next release to make it display "Send
mail to bug-gnu-emacs@gnu.org saying you see this message" at startup.

Serious performance problem with process output on Mac OSX

[Christian Lynbech]

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

There is apparently some bad interaction between Emacs 23 and the Mac
OSX desktop with respect to output from background processes.

When emacs is processing such output, there is a kind of lock up where
it literally can take many seconds to switch desktops or to switch
between applications (Cmd-TAB).

I have attached a small example file that exhibits the behaviour. It
creates a number of frames and starts a compilation process (simply a
"ls -lR /System" command) that generates quite a lot of output. Once
that process is running, attempts to switch desktops or to switch
between applications takes very long time. Apparently the severity of
the problem is related to how many frames are created. With the test
file as attached it is really bad, if no extra frames are created, it is
barely noticeable.

The tests I have done just now is on Mac OSX 10.6.2 on an Intel based
Mac Book Air but I have seen the same behaviour on my powermac G5. If I
compile emacs to use X11, there is no such problem.

The emacs identifies itself as "23.1.94.1" and was taken from the
repositorys emacs23 branch a few days ago. The configure options used
when building was just --prefix, --with-ns and --without-dbus.

Let me know if there is any more information I can provide.


[-- Attachment #2: test.el --]
[-- Type: application/emacs-lisp, Size: 230 bytes --]

[-- Attachment #3: Type: text/plain, Size: 371 bytes --]



------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)

Re: Serious performance problem with process output on Mac OSX

[Adrian Robert]

> When emacs is processing such output, there is a kind of lock up where
> it literally can take many seconds to switch desktops or to switch
> between applications (Cmd-TAB).


Hi,

I was able to reproduce this also on a 10.6.2 system, simply by executing the "ls -lR /System" command in a shell buffer and minimizing it.  What I noticed was that app switching through clicking on other app windows is as fast as normal when a disk-intensive background process is going on, but that Cmd-tab or clicking on the dock was slow.  Under Activity Monitor or top, the "Dock" process is taking up a lot of CPU.  This seems to have something to do with the updates Dock wants to do for the icon based on whatever methods Emacs is calling periodically.  I don't think it has to do with external processes -- but I couldn't figure out a way to get a growing buffer redisplayed while iconified purely from lisp code to test for sure.

Nor does it have to do purely with output -- the high Dock CPU usage occurs whether or not emacs is actually displaying the buffer doing the ls or not, and running the same ls -lR in Terminal and minimizing does not cause it.

I suspect unneeded calls to one of the icon/icon_type methods in nsfns.m or the miniwindowimage methods in nsterm.m are causing this.  Someone could try shortcircuiting these in the source and seeing if the problem still obtains.

It would also be interesting to know if this occurs under Leopard or Tiger, if anyone has access to those systems.

thanks,
Adrian

Re: Serious performance problem with process output on Mac OSX

[Adrian Robert]

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]


On Mar 28, 2010, at 5:41 PM, Adrian Robert wrote:

> I suspect unneeded calls to one of the icon/icon_type methods in nsfns.m or the miniwindowimage methods in nsterm.m are causing this.  Someone could try shortcircuiting these in the source and seeing if the problem still obtains.

I went ahead and tried this.  The culprit was an unneeded ns_set_icon_type() call.  The attached patch cleans this up by removing some HAVE_NS special handling in xdisp.c.


[-- Attachment #2: dock_overflow_20100329.patch --]
[-- Type: application/octet-stream, Size: 4573 bytes --]

Index: nsfns.m
===================================================================
RCS file: /sources/emacs/emacs/src/nsfns.m,v
retrieving revision 1.55
diff -u -p -r1.55 nsfns.m
--- nsfns.m	24 Oct 2009 18:58:51 -0000	1.55
+++ nsfns.m	29 Mar 2010 21:56:36 -0000
@@ -80,6 +80,7 @@ extern Lisp_Object Qface_set_after_frame
 extern Lisp_Object Qunderline, Qundefined;
 extern Lisp_Object Qheight, Qminibuffer, Qname, Qonly, Qwidth;
 extern Lisp_Object Qunsplittable, Qmenu_bar_lines, Qbuffer_predicate, Qtitle;
+extern Lisp_Object Vframe_title_format;
 
 Lisp_Object Qnone;
 Lisp_Object Qbuffered;
@@ -586,7 +587,12 @@ x_implicitly_set_name (FRAME_PTR f, Lisp
   if (FRAME_ICONIFIED_P (f))
     ns_set_name_iconic (f, arg, 0);
   else
-    ns_set_name (f, arg, 0);
+    {
+      if (FRAME_NS_P (f) && EQ (Vframe_title_format, Qt))
+        ns_set_name_as_filename (f);
+      else
+        ns_set_name (f, arg, 0);
+    }
 }
 
 
@@ -685,15 +691,18 @@ ns_set_name_as_filename (struct frame *f
 
 
 void
-ns_set_doc_edited (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
+ns_set_doc_edited (struct frame *f, Lisp_Object arg)
 {
   NSView *view = FRAME_NS_VIEW (f);
   NSAutoreleasePool *pool;
-  BLOCK_INPUT;
-  pool = [[NSAutoreleasePool alloc] init];
-  [[view window] setDocumentEdited: !NILP (arg)];
-  [pool release];
-  UNBLOCK_INPUT;
+
+  if (!MINI_WINDOW_P (XWINDOW(f->selected_window))) {
+    BLOCK_INPUT;
+    pool = [[NSAutoreleasePool alloc] init];
+    [[view window] setDocumentEdited: !NILP (arg)];
+    [pool release];
+    UNBLOCK_INPUT;
+  }
 }
 
 
Index: nsterm.h
===================================================================
RCS file: /sources/emacs/emacs/src/nsterm.h,v
retrieving revision 1.29
diff -u -p -r1.29 nsterm.h
--- nsterm.h	16 Oct 2009 03:09:06 -0000	1.29
+++ nsterm.h	29 Mar 2010 21:56:36 -0000
@@ -708,6 +708,8 @@ extern void nxatoms_of_nsselect ();
 extern int ns_lisp_to_cursor_type ();
 extern Lisp_Object ns_cursor_type_to_lisp (int arg);
 extern Lisp_Object Qnone;
+extern void ns_set_name_as_filename (struct frame *f);
+extern void ns_set_doc_edited (struct frame *f, Lisp_Object arg);
 
 extern int
 ns_defined_color (struct frame *f, char *name, XColor *color_def, int alloc,
Index: nsterm.m
===================================================================
RCS file: /sources/emacs/emacs/src/nsterm.m,v
retrieving revision 1.95
diff -u -p -r1.95 nsterm.m
--- nsterm.m	19 Oct 2009 16:58:20 -0000	1.95
+++ nsterm.m	29 Mar 2010 21:56:36 -0000
@@ -4191,7 +4191,6 @@ ns_term_shutdown (int sig)
   ns_send_appdefined (-2);
 }
 
-extern void update_window_cursor (struct window *w, int on);
 
 - (void)fd_handler: (NSTimer *) fdEntry
 /* --------------------------------------------------------------------------
Index: xdisp.c
===================================================================
RCS file: /sources/emacs/emacs/src/xdisp.c,v
retrieving revision 1.1328
diff -u -p -r1.1328 xdisp.c
--- xdisp.c	15 Dec 2009 22:53:39 -0000	1.1328
+++ xdisp.c	29 Mar 2010 21:56:38 -0000
@@ -9494,31 +9494,8 @@ x_consider_frame_title (frame)
 	  || SBYTES (f->name) != len
 	  || bcmp (title, SDATA (f->name), len) != 0)
         {
-#ifdef HAVE_NS
-          if (FRAME_NS_P (f))
-            {
-              if (!MINI_WINDOW_P(XWINDOW(f->selected_window)))
-                {
-                  if (EQ (fmt, Qt))
-                    ns_set_name_as_filename (f);
-                  else
-                    x_implicitly_set_name (f, make_string(title, len),
-                                           Qnil);
-                }
-            }
-          else
-#endif
 	    x_implicitly_set_name (f, make_string (title, len), Qnil);
         }
-#ifdef HAVE_NS
-      if (FRAME_NS_P (f))
-        {
-          /* do this also for frames with explicit names */
-          ns_implicitly_set_icon_type(f);
-          ns_set_doc_edited(f, Fbuffer_modified_p
-                            (XWINDOW (f->selected_window)->buffer), Qnil);
-        }
-#endif
     }
 }
 
@@ -9615,6 +9592,11 @@ prepare_menu_bars ()
 #ifdef HAVE_WINDOW_SYSTEM
 	  update_tool_bar (f, 0);
 #endif
+#ifdef HAVE_NS
+          if (windows_or_buffers_changed)
+            ns_set_doc_edited (f, Fbuffer_modified_p
+                                    (XWINDOW (f->selected_window)->buffer));
+#endif
 	  UNGCPRO;
 	}
 
@@ -22669,9 +22653,6 @@ display_and_set_cursor (w, on, hpos, vpo
 /* Switch the display of W's cursor on or off, according to the value
    of ON.  */
 
-#ifndef HAVE_NS
-static
-#endif
 void
 update_window_cursor (w, on)
      struct window *w;

[-- Attachment #3: Type: text/plain, Size: 2 bytes --]

Re: Serious performance problem with process output on Mac OSX

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

On Mar 29, 2010, at 5:58 PM, Adrian Robert wrote:
> 
> I went ahead and tried this.  The culprit was an unneeded ns_set_icon_type() call.  The attached patch cleans this up by removing some HAVE_NS special handling in xdisp.c.


Adrian, kudos and many thanks for finding this problem.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: Serious performance problem with process output on Mac OSX

[Chong Yidong]

Adrian Robert <adrian.b.robert@gmail.com> writes:

>> I suspect unneeded calls to one of the icon/icon_type methods in
>> nsfns.m or the miniwindowimage methods in nsterm.m are causing this.
>> Someone could try shortcircuiting these in the source and seeing if
>> the problem still obtains.
>
> I went ahead and tried this.  The culprit was an unneeded
> ns_set_icon_type() call.  The attached patch cleans this up by
> removing some HAVE_NS special handling in xdisp.c.

Thank you very much.

I've checked your patch into the emacs-23 branch.  Can you verify that
this also fixes the performance problem reported in
[http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2056]?  I assume it's the
same problem.

One other thing I noticed which looking through the code is that the
Nextstep port assigns a special value, `t', to frame-title-format, and
processes it specially.  Is there any reason to do this?  If not, I
think this should be removed; this looks like a misfeature to me, since
it is not compatible with the variable as documented and can confuse
other people's Lisp code.

Re: Serious performance problem with process output on Mac OSX

[Adrian Robert]

> One other thing I noticed which looking through the code is that the
> Nextstep port assigns a special value, `t', to frame-title-format, and
> processes it specially.  Is there any reason to do this?  If not, I
> think this should be removed; this looks like a misfeature to me, since
> it is not compatible with the variable as documented and can confuse
> other people's Lisp code.

Ah, OK -- this variable and value was checked for in the code I moved in my patch, but I had no idea it was set specially by NS lisp code.  I'll look into it.


>   Can you verify that
> this also fixes the performance problem reported in
> [http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2056]?  I assume it's the
> same problem.


I looked at that and, while I get some slight choppiness, it doesn't seem to be to the extent people are reporting there.  Am not sure how large a file one needs -- I tried with a 1MB text file.  And I'm on 10.6.. mileage might be different under 10.5 or 10.4.  This should be looked into, but it probably relates to event loop stuff and would need some dedicated time to track down / fix.


-Adrian

Re: Serious performance problem with process output on Mac OSX

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]

On Mar 30, 2010, at 3:43 AM, Adrian Robert wrote:

>> One other thing I noticed which looking through the code is that the
>> Nextstep port assigns a special value, `t', to frame-title-format, and
>> processes it specially.  Is there any reason to do this?  If not, I
>> think this should be removed; this looks like a misfeature to me, since
>> it is not compatible with the variable as documented and can confuse
>> other people's Lisp code.
> 
> Ah, OK -- this variable and value was checked for in the code I moved in my patch, but I had no idea it was set specially by NS lisp code.  I'll look into it.

IIRC, NS displays the file's name as the title and requires you to set it that way if drag&drop of the file proxy icons (displayed next to the name of the frame) is supposed to work.  That's all standard functionality on NS or at least on the Mac.  If the frame name is different, I think drag&drop doesn't work right.  See xdisp.c:9503ff and also ns_set_name_as_filename() in nsfns.m.

Introducing a ns-* variable to override would confuse users (frame-title-format won't work as expected), but if we set the file name with this NS function iff ns-frame-title-format is "%f", then that would be consistent with the other platforms.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: Serious performance problem with process output on Mac OSX

[Jimmy Yuen Ho Wong]

[-- Attachment #1: Type: text/plain, Size: 3421 bytes --]

It seems there was some code merge problem for this patch commit. I was
compiling this on my MBP 10.6.3 and I got this:

./configure --with-ns
...
make install
...
gcc -c  -Demacs -DHAVE_CONFIG_H  -I.
-I/Users/wyuenho/packages/emacs/emacs-23/src -Dtemacs     -g -O2
-Wdeclaration-after-statement -Wno-pointer-sign   -MMD -MF deps/nsterm.d
nsterm.m
nsterm.m: In function 'x_set_window_size':
nsterm.m:1189: warning: ISO C90 forbids mixed declarations and code
nsterm.m: In function 'ns_draw_fringe_bitmap':
nsterm.m:2203: warning: ISO C90 forbids mixed declarations and code
nsterm.m: In function '-[EmacsView keyDown:]':
nsterm.m:4481: warning: 'wantsToDelayTextChangeNotifications' is deprecated
(declared at
/System/Library/Frameworks/AppKit.framework/Headers/NSInputManager.h:112)
nsterm.m: In function '-[EmacsView initFrameFromEmacs:]':
nsterm.m:5089: warning: class 'EmacsView' does not implement the
'NSWindowDelegate' protocol
nsterm.m: In function '-[EmacsScroller judge]':
nsterm.m:5761: warning: ISO C90 forbids mixed declarations and code
nsterm.m: In function '-[EmacsScroller setPosition:portion:whole:]':
nsterm.m:5800: warning: 'setFloatValue:knobProportion:' is deprecated
(declared at
/System/Library/Frameworks/AppKit.framework/Headers/NSScroller.h:107)
nsterm.m:5807: warning: 'setFloatValue:knobProportion:' is deprecated
(declared at
/System/Library/Frameworks/AppKit.framework/Headers/NSScroller.h:107)
gcc -c  -Demacs -DHAVE_CONFIG_H  -I.
-I/Users/wyuenho/packages/emacs/emacs-23/src -Dtemacs     -g -O2
-Wdeclaration-after-statement -Wno-pointer-sign   -MMD -MF deps/nsfns.d
nsfns.m
nsfns.m: In function 'ns_get_screen':
nsfns.m:227: warning: assignment makes pointer from integer without a cast
nsfns.m: At top level:
nsfns.m:690: error: conflicting types for 'ns_set_doc_edited'
nsterm.h:712: error: previous declaration of 'ns_set_doc_edited' was here
nsfns.m: In function 'Fx_display_color_cells':
nsfns.m:2377: warning: ISO C90 forbids mixed declarations and code
make[1]: *** [nsfns.o] Error 1
make: *** [src] Error 2


On Tue, Mar 30, 2010 at 9:05 PM, David Reitter <david.reitter@gmail.com>wrote:

> On Mar 30, 2010, at 3:43 AM, Adrian Robert wrote:
>
> >> One other thing I noticed which looking through the code is that the
> >> Nextstep port assigns a special value, `t', to frame-title-format, and
> >> processes it specially.  Is there any reason to do this?  If not, I
> >> think this should be removed; this looks like a misfeature to me, since
> >> it is not compatible with the variable as documented and can confuse
> >> other people's Lisp code.
> >
> > Ah, OK -- this variable and value was checked for in the code I moved in
> my patch, but I had no idea it was set specially by NS lisp code.  I'll look
> into it.
>
> IIRC, NS displays the file's name as the title and requires you to set it
> that way if drag&drop of the file proxy icons (displayed next to the name of
> the frame) is supposed to work.  That's all standard functionality on NS or
> at least on the Mac.  If the frame name is different, I think drag&drop
> doesn't work right.  See xdisp.c:9503ff and also ns_set_name_as_filename()
> in nsfns.m.
>
> Introducing a ns-* variable to override would confuse users
> (frame-title-format won't work as expected), but if we set the file name
> with this NS function iff ns-frame-title-format is "%f", then that would be
> consistent with the other platforms.
>
>

[-- Attachment #2: Type: text/html, Size: 4411 bytes --]

Re: Serious performance problem with process output on Mac OSX

[Chong Yidong]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> It seems there was some code merge problem for this patch commit. I was
> compiling this on my MBP 10.6.3 and I got this:
>
> ./configure --with-ns
> ...
> make install
> ...
> gcc -c  -Demacs -DHAVE_CONFIG_H  -I. -I/Users/wyuenho/packages/emacs/emacs-23/
> src -Dtemacs     -g -O2 -Wdeclaration-after-statement -Wno-pointer-sign   -MMD
> -MF deps/nsterm.d nsterm.m
> nsterm.m: In function 'x_set_window_size':
> nsterm.m:1189: warning: ISO C90 forbids mixed declarations and code

Is this on the emacs-23 bzr branch?  I don't see how this error would
arise from the patch, off the top of my head.

Re: Serious performance problem with process output on Mac OSX

[Jimmy Yuen Ho Wong]

[-- Attachment #1: Type: text/plain, Size: 226 bytes --]

> Is this on the emacs-23 bzr branch?  I don't see how this error would
> arise from the patch, off the top of my head.
>


Yes. The prototype and the definition are different. The definition has an
extra param called oldval.

[-- Attachment #2: Type: text/html, Size: 436 bytes --]

Re: Serious performance problem with process output on Mac OSX

[Chong Yidong]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> Yes. The prototype and the definition are different. The definition has an
> extra param called oldval.

Ah, right.  I've checked in a fix now, thanks.

Re: Serious performance problem with process output on Mac OSX

[Jimmy Yuen Ho Wong]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

I still get this from a clean build:

xdisp.c: In function 'prepare_menu_bars':
xdisp.c:9575: error: too few arguments to function 'ns_set_doc_edited'
make[1]: *** [xdisp.o] Error 1
make: *** [src] Error 2

I'm sorry I don't know anything about Emacs's core to be of any more help
then this.

Jimmy


On Wed, Mar 31, 2010 at 12:00 PM, Chong Yidong <cyd@stupidchicken.com>wrote:

> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
>
> > Yes. The prototype and the definition are different. The definition has
> an
> > extra param called oldval.
>
> Ah, right.  I've checked in a fix now, thanks.
>

[-- Attachment #2: Type: text/html, Size: 1107 bytes --]

Re: Serious performance problem with process output on Mac OSX

[Chong Yidong]

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> I still get this from a clean build:
>
> xdisp.c: In function 'prepare_menu_bars':
> xdisp.c:9575: error: too few arguments to function 'ns_set_doc_edited'
> make[1]: *** [xdisp.o] Error 1
> make: *** [src] Error 2
>
> I'm sorry I don't know anything about Emacs's core to be of any more help then
> this.

OK, I think I've checked in the correct fix now.  Try again.

Re: Serious performance problem with process output on Mac OSX

[Adrian Robert]

On Mar 31, 2010, at 4:41 PM, Jimmy Yuen Ho Wong wrote:

> I still get this from a clean build:
> 
> xdisp.c: In function 'prepare_menu_bars':
> xdisp.c:9575: error: too few arguments to function 'ns_set_doc_edited'
> make[1]: *** [xdisp.o] Error 1
> make: *** [src] Error 2

Hi,

The patch I sent changed the header (nsterm.h), the function definition in nsfns.m, and the call in xdisp.c:

nsterm.h should have:
extern void ns_set_doc_edited (struct frame *f, Lisp_Object arg);

nsfns.m should have:
void
ns_set_doc_edited (struct frame *f, Lisp_Object arg)
{
...
}

xdisp.c should have:
        ns_set_doc_edited (f, Fbuffer_modified_p
                                (XWINDOW (f->selected_window)->buffer));


The 'oldval' arg was neither set nor used, so I dropped it.


HTH,
Adrian

Re: MS-Windows build broken in Fmake_network_process

[Davis Herring]

>> Yes, we could (it just needs an additional -lws2 switch during
>> linking)
>
> We already use functions from ws2. I think effort was made in the past
> to dynamically load it when required, because network support was not
> always installed on early versions of Windows 95, and because loading
> the library at startup caused a dialup dialog to pop up when the default
> network connection was a dialup connection.  Neither of these is
> probably a concern anymore, so it might be better to simplify the code
> by with linking ws2 normally.

Windows 95 could be installed with networking support but without ws2. 
That may be the target audience here.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: MS-Windows build broken in Fmake_network_process

[Jason Rumney]

On 30/03/2010 07:48, Davis Herring wrote:
> Windows 95 could be installed with networking support but without ws2.
> That may be the target audience here.
>    

Indeed, but only in the 1995 - 1996 or 1997 timeframe, as it was added 
to a service pack, at the same time that the installer was changed to 
include networking support by default.

That noone has complained about our change from winsock.dll to ws2.dll 
three years ago makes me suspect that such old versions of Windows 95 
are not a problem we need to worry about.  Windows 98 may still be in 
use, but that definitely comes with ws2 in all installations.

Re: MS-Windows build broken in Fmake_network_process

[Juanma Barranquero]

On Fri, Mar 26, 2010 at 19:17, Helmut Eller <eller.helmut@gmail.com> wrote:

> Then link in getsockopt.  That's the most direct solution.

The most direct solution is not breaking other builds needlessly.

    Juanma

Re: MS-Windows build broken in Fmake_network_process

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 26 Mar 2010 18:22:36 +0300, Eli Zaretskii <eliz@gnu.org> said:

> This change:
>     revno: 99750
>     author: Helmut Eller <eller.helmut@gmail.com>
>     committer: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
>     branch nick: trunk
>     timestamp: Thu 2010-03-25 17:48:52 +0900
>     message:
>       Call `select' for interrupted `connect' rather than creating new socket (Bug#5173).

> breaks the MS-Windows build:

(snip)

> The linker error is because we would need to link against yet another
> library to get this function.  But I don't think we should do that.
> I'm actually bewildered why this code:

> 	    int len = sizeof xerrno;
> 	    eassert (FD_ISSET (s, &fdset));
> 	    if (getsockopt (s, SOL_SOCKET, SO_ERROR, &xerrno, &len) == -1)
> 	      report_file_error ("getsockopt failed", Qnil);

> was used unconditionally when a very similar code in
> wait_reading_process_output is clearly marked with a comment saying
> not to use it except on GNU/Linux:

>   #ifdef GNU_LINUX
> 		/* getsockopt(,,SO_ERROR,,) is said to hang on some systems.
> 		   So only use it on systems where it is known to work.  */
> 		{
> 		  int xlen = sizeof(xerrno);
> 		  if (getsockopt(channel, SOL_SOCKET, SO_ERROR, &xerrno, &xlen))
> 		    xerrno = errno;
> 		}
>   #else

Actually I was aware of the above part when I committed the change in
question.  But the code above was added in 2002, and I doubted whether
it is still the case for the systems that are supported by Emacs
24.0.50.  So I didn't copy the above code for Fmake_network_process.

Can normal (i.e., blocking) `connect' in Windows be interrupted by a
POSIX signal counterpart?  If not, then we can disable the whole added
code for Windows in the first place.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

> Date: Sat, 27 Mar 2010 09:51:56 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: Helmut Eller <eller.helmut@gmail.com>,
> 	emacs-devel@gnu.org
> 
> Actually I was aware of the above part when I committed the change in
> question.  But the code above was added in 2002, and I doubted whether
> it is still the case for the systems that are supported by Emacs
> 24.0.50.  So I didn't copy the above code for Fmake_network_process.

I don't know which systems Kim Storm (who wrote that code; CC'ed) had
in mind when he made it conditional on GNU/Linux.  The related
discussion on emacs-devel does not talk about this issue, and the
preliminary version of the patch Kim posted back then does not include
the conditional GNU/Linux code.

But let me remind you that Windows XP, the Windows version that is
still the most widely used one today, was released in 2002.

> Can normal (i.e., blocking) `connect' in Windows be interrupted by a
> POSIX signal counterpart?  If not, then we can disable the whole added
> code for Windows in the first place.

As I said, I'm far from being an expert on the Windows socket library
and its operation.  Here's what I know about the related issues:

 . The Windows socket functions can only return EINTR (actually,
   WSAEINTR, from which we produce EINTR in Emacs's Windows source)
   only for the old Winsock 1.1 sockets, and only if some code calls
   `WSACancelBlockingCall'.  Emacs does not call that function
   directly, and in fact it is deprecated and was removed from Winsock
   2 library.

 . C-g does not trigger an asynchronous SIGINT on Windows like it does
   on Posix systems.  Instead, the Emacs's Windows code has a separate
   input thread; when that thread sees a C-g keystroke, it triggers a
   special handle that is included in the set of handles on which
   `select' waits.  `select' then returns with -1 setting errno to
   EINTR.  This is how the Windows build interrupts prolonged ``system
   calls''.

 . Note that `select' itself is implemented (as `sys_select') in
   Emacs's Windows code, i.e. we don't use the Windows-supplied
   `select', which only works on network handles.

From this I tend to conclude that `connect' on Windows cannot be
interrupted like on Posix systems, because when `connect' is called,
we are not waiting in `select'.

Perhaps Jason and Juanma can add their expertise to what I say above
and correct me where I'm wrong.

Re: MS-Windows build broken in Fmake_network_process

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

>  . The Windows socket functions can only return EINTR (actually,
>    WSAEINTR, from which we produce EINTR in Emacs's Windows source)
>    only for the old Winsock 1.1 sockets, and only if some code calls
>    `WSACancelBlockingCall'.  Emacs does not call that function
>    directly, and in fact it is deprecated and was removed from Winsock
>    2 library.

http://msdn.microsoft.com/en-us/library/aa923167.aspx says that WSAEINTR
means "the socked was closed". That's for the current Winsock
implementation.

[snip]

Re: MS-Windows build broken in Fmake_network_process

[Juanma Barranquero]

On Sat, Mar 27, 2010 at 14:01, Óscar Fuentes <ofv@wanadoo.es> wrote:

> http://msdn.microsoft.com/en-us/library/aa923167.aspx says that WSAEINTR
> means "the socked was closed". That's for the current Winsock
> implementation.

On "Windows Sockets Error Codes",
http://msdn.microsoft.com/en-us/library/ms740668%28VS.85%29.aspx

  WSAEINTR
  10004

  Interrupted function call.
      A blocking operation was interrupted by a call to WSACancelBlockingCall.

and http://msdn.microsoft.com/en-us/library/ms737526%28VS.85%29.aspx says:

  WSAEINTR        A blocking Windows Sockets 1.1 call was canceled
through WSACancelBlockingCall.


    Juanma

Re: MS-Windows build broken in Fmake_network_process

[Kim F. Storm]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 27 Mar 2010 09:51:56 +0900
>> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
>> Cc: Helmut Eller <eller.helmut@gmail.com>,
>> 	emacs-devel@gnu.org
>> 
>> Actually I was aware of the above part when I committed the change in
>> question.  But the code above was added in 2002, and I doubted whether
>> it is still the case for the systems that are supported by Emacs
>> 24.0.50.  So I didn't copy the above code for Fmake_network_process.
>
> I don't know which systems Kim Storm (who wrote that code; CC'ed) had
> in mind when he made it conditional on GNU/Linux.

I don't recall either, but I do remember that the conditioned code was said
to be unreliable on some systems, and the only system on which I could test
is was GNU/Linux, so I conditioned the code in the hope that someone would
eventually test the code on other platforms and lift the restriction (if
safe).

-- 
Kim F. Storm  http://www.cua.dk