MS-Windows build broken in Fmake_network_process

[Eli Zaretskii]

This change:

revno: 99750
author: Helmut Eller <***@gmail.com>
committer: YAMAMOTO Mitsuharu <***@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 `***@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?

[Eli Zaretskii]

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. */

[Eli Zaretskii]

Date: Fri, 26 Mar 2010 19:05:47 +0100

Post by Eli Zaretskii

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?

/* 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.

[Eli Zaretskii]

Date: Fri, 26 Mar 2010 19:17:41 +0100

Post by Eli Zaretskii

Post by Eli Zaretskii
/* 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?

[Chong Yidong]

Post by Eli Zaretskii
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.

[Eli Zaretskii]

Date: Fri, 26 Mar 2010 20:48:52 -0400

Post by Eli Zaretskii
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'?

[Jason Rumney]

Post by Eli Zaretskii
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.

[Eli Zaretskii]

Date: Sun, 28 Mar 2010 00:49:01 +0800

Post by Eli Zaretskii
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?

[Christoph]

Post by Eli Zaretskii
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

[Florian Beck]

Post by Christoph

Post by Eli Zaretskii
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.

[Óscar Fuentes]

Post by Florian Beck

Post by Christoph

Post by Eli Zaretskii
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)

[Eli Zaretskii]

Date: Sun, 28 Mar 2010 01:37:29 +0100
=20
=20

Post by Eli Zaretskii
How is this not a concern anymore? We didn't stop supporting
Windows 9X, did we?
=20

Microsoft did. Why don't we?=20

Hardware. Windows 9X is the main choice for old machines (like 64=

MB

ram). Don't take that away without need.

=20
If they run a 15 year old trashy OS, do they really demand the late=

st

and greatest Emacs? (which is a very fat application for such machi=

nes)

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.

[Chong Yidong]

Post by Eli Zaretskii

Post by Óscar Fuentes

Post by Florian Beck
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?

[Eli Zaretskii]

Date: Sun, 28 Mar 2010 14:55:02 -0400
=20
I understand the virtues of maintaining support for older systems, =

but

the prospect of maintaining support for non-networked Windows 95, w=

hen

there's no one to use or test or develop that support, does not fil=

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

[Jason Rumney]

Post by Eli Zaretskii

Post by Chong Yidong
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).

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

[Stephen J. Turnbull]

Post by Richard Stallman
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.

[Eli Zaretskii]

Date: Wed, 31 Mar 2010 13:57:31 +0900
=20
=20

However, it is not a high priority for us, because supporting an=

y

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 ca=

n

choose which platforms to support.

=20
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.

[Juanma Barranquero]

Post by Eli Zaretskii
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

[Eli Zaretskii]

Date: Wed, 31 Mar 2010 12:38:41 +0200

Post by Eli Zaretskii
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.

[Stephen J. Turnbull]

Post by Juanma Barranquero

Post by Eli Zaretskii
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).

[Juanma Barranquero]

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

[Stephen J. Turnbull]

Post by Juanma Barranquero

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

Post by Juanma Barranquero

[...] 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. ;-)

[Juanma Barranquero]

Post by Stephen J. Turnbull
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.

Post by Stephen J. Turnbull
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

[Stefan Monnier]

Post by Juanma Barranquero

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

[Stephen J. Turnbull]

Post by Eli Zaretskii

Date: Wed, 31 Mar 2010 13:57:31 +0900

Post by Richard Stallman
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.

Post by Eli Zaretskii
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.

[Eli Zaretskii]

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

[Stephen J. Turnbull]

Post by Eli Zaretskii
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.

[Eli Zaretskii]

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.

[Stephen J. Turnbull]

Post by Eli Zaretskii

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.

[David Kastrup]

Post by Óscar Fuentes
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.

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

[David Kastrup]

Post by David Kastrup
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.

Post by David Kastrup
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.

[Christoph]

Post by Florian Beck

Post by Christoph

Post by Eli Zaretskii
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.

[Eli Zaretskii]

Date: Sat, 27 Mar 2010 18:39:01 -0600
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.

[Óscar Fuentes]

Post by Eli Zaretskii

Date: Sat, 27 Mar 2010 18:39:01 -0600
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.

[Lennart Borgman]

Post by Óscar Fuentes
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.

Post by Óscar Fuentes
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.

[Eli Zaretskii]

Date: Sun, 28 Mar 2010 16:59:54 +0200
=20
=20

Post by Eli Zaretskii

Date: Sat, 27 Mar 2010 18:39:01 -0600
The need is in my opinion a growing pain in the rear-end to supp=

ort this=20

Post by Eli Zaretskii

backwards compatibility.

This argument can only be persuasive if it comes from someone who
personally experienced this pain, which could only be true if the=

y are

Post by Eli Zaretskii
active maintainers of the MS-Windows port.

=20
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 W9=

X

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 trivia=

l

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 i=
n
file ops is one example that comes to mind; the "load average" displa=
y
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 wit=
h
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 the=

m

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 function=
s
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.

[Juanma Barranquero]

Post by Eli Zaretskii
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

[j***@verona.se]

Post by Juanma Barranquero

Post by Eli Zaretskii
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.

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

[Óscar Fuentes]

Post by Eli Zaretskii

Post by Óscar Fuentes
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.

Post by Eli Zaretskii

Post by Óscar Fuentes
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).

Post by Eli Zaretskii
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]

Post by Eli Zaretskii

Post by Óscar Fuentes
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.

Post by Eli Zaretskii
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?

[Eli Zaretskii]

Date: Sun, 28 Mar 2010 21:57:02 +0200
=20

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.

=20
... and precisely gaining this information is difficult, because yo=

u

must read the documentation for every API call and even then you ca=

n hit

a bug, which is not rare in W9X (and before you say that any API ha=

s

this problem, well, yes, but not to the extent of W9X).

You read too much into our reluctance to drop W9X support. There's n=
o
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 user=
s
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.

=20
Sorry, but do you have experience writing Windows raw API code on i=

ts

successive incarnations since Windows 95? I'm starting to think you=

have

not. Looking at the set of functions that makes the Windows API, th=

ose

available on W95 are, for the most part, a proper subset of those
available on XP. So, in theory, and unless you use certain obsolete=

d

parts of the API (shell interaction, for instance, which is not par=

t 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 behavio=

ur

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.

[Juanma Barranquero]

Post by Eli Zaretskii
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

[Christoph]

Post by Eli Zaretskii

Date: Sat, 27 Mar 2010 18:39:01 -0600
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

[Eli Zaretskii]

Date: Sun, 28 Mar 2010 13:27:03 -0600
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.

[Christoph]

Post by Eli Zaretskii
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.

Post by Eli Zaretskii
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.

Post by Eli Zaretskii
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.

Post by Eli Zaretskii
Your contributions, past and future, are welcome. Thanks.

Thank you.

[Eli Zaretskii]

Date: Sat, 27 Mar 2010 16:28:13 -0600

Post by Eli Zaretskii
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.

[Jason Rumney]

Post by Eli Zaretskii

Date: Sun, 28 Mar 2010 00:49:01 +0800

Post by Eli Zaretskii
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?

[Eli Zaretskii]

Date: Sun, 28 Mar 2010 15:33:43 +0800

Post by Eli Zaretskii

Post by Jason Rumney
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?

[Richard Stallman]

Post by Jason Rumney
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-***@gnu.org saying you see this message" at startup.

[Christian Lynbech]

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.

[Adrian Robert]

Post by Christian Lynbech
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

[Adrian Robert]

Post by Adrian Robert
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.

[David Reitter]

Post by Adrian Robert
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.

[Chong Yidong]

Post by Adrian Robert

Post by Adrian Robert
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.

[Adrian Robert]

Post by Chong Yidong
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.

Post by Chong Yidong
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

[David Reitter]

Post by Adrian Robert

Post by Chong Yidong
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.

[Jimmy Yuen Ho Wong]

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

Post by Adrian Robert

Post by Adrian Robert

Post by Chong Yidong
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.

[Chong Yidong]

Post by Jimmy Yuen Ho Wong
It seems there was some code merge problem for this patch commit. I was
./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: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.

[Jimmy Yuen Ho Wong]

Post by Chong Yidong
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.

[Chong Yidong]

Post by Jimmy Yuen Ho Wong
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.

[Jimmy Yuen Ho Wong]

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

Post by Chong Yidong

Post by Jimmy Yuen Ho Wong
Yes. The prototype and the definition are different. The definition has

an

Post by Jimmy Yuen Ho Wong
extra param called oldval.

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

[Chong Yidong]

Post by Jimmy Yuen Ho Wong
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.

[Adrian Robert]

Post by Jimmy Yuen Ho Wong
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

[Davis Herring]

Post by Jason Rumney

Post by Eli Zaretskii
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

[Jason Rumney]

Post by Davis Herring
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.

[Helmut Eller]

Post by Eli Zaretskii

Date: Fri, 26 Mar 2010 19:17:41 +0100

Post by Eli Zaretskii

Post by Eli Zaretskii
/* 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.

Post by Eli Zaretskii
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.

Post by Eli Zaretskii
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

[Eli Zaretskii]

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.

[Helmut Eller]

Post by Eli Zaretskii

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.

Post by Eli Zaretskii
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

[Eli Zaretskii]

Date: Sat, 27 Mar 2010 11:09:17 +0100

Post by Eli Zaretskii
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;

[Helmut Eller]

Post by Eli Zaretskii

Date: Sat, 27 Mar 2010 11:09:17 +0100

Post by Eli Zaretskii
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.

Post by Eli Zaretskii
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.

Post by Eli Zaretskii
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

[Helmut Eller]

Post by Eli Zaretskii

Date: Fri, 26 Mar 2010 19:05:47 +0100

Post by Eli Zaretskii

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?

/* 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

[Juanma Barranquero]

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

The most direct solution is not breaking other builds needlessly.

Juanma

[Helmut Eller]

Post by Eli Zaretskii

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?

/* 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

[Helmut Eller]

Post by Eli Zaretskii
revno: 99750
branch nick: trunk
timestamp: Thu 2010-03-25 17:48:52 +0900
Call `select' for interrupted `connect' rather than creating new socket (Bug#5173).
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:3663: warning: passing arg 4 of `getsockopt' from incompatible pointer type
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.
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
#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

[YAMAMOTO Mitsuharu]

Post by Eli Zaretskii
revno: 99750
branch nick: trunk
timestamp: Thu 2010-03-25 17:48:52 +0900
Call `select' for interrupted `connect' rather than creating new socket (Bug#5173).

(snip)

Post by Eli Zaretskii
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.
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
#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
***@math.s.chiba-u.ac.jp

[Eli Zaretskii]

Date: Sat, 27 Mar 2010 09:51:56 +0900
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.

[Óscar Fuentes]

Eli Zaretskii <***@gnu.org> writes:

[snip]

Post by Eli Zaretskii
. 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]

[Juanma Barranquero]

Post by Óscar Fuentes
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

[Kim F. Storm]

Post by Eli Zaretskii

Date: Sat, 27 Mar 2010 09:51:56 +0900
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).