emacsclientw.exe bug: random exit status

[garyo]

emacsclientw exits with a random exit status when called from a win32 window app (such as emacs itself).  The reason is an uninitialized variable in w32_teardown_window in w32emacsclient.h.  I suspect if "ret" is initialized to zero (exit status success) in this function it would just work.  I don't have mingw so I can't compile it here myself, sorry.

This is on emacs 23.1.50, also happens on the latest CVS test version.  I'm using the EmacsW32 patched version on XP, but don't think that matters either.

The symptom is easy to reproduce.  In a shell window inside emacs (I use cygwin zsh, but any shell will work), run
  emacsclient foo || echo BAD
then C-x # to close the server buffer, and then look back in the shell window:
% emacsclientw foo || echo BAD
Waiting for Emacs...
BAD
%

(I'm sure you already know that "emacsclient", the non-windows version, is totally broken, gives "Unknown&_command:&"... but emacsclientw is fine so it doesn't really matter.)

Here's the affected code:
===========
int
w32_teardown_window (int connected)
{
  int ret;                    <<<<<<<<<<====== FIX HERE to int ret=0;
  if (w32_window_app ())
    {
      w32_check_not_synced();
      w32_wait_threads_fin(connected);
      ret = W32_SYNC_get_g_exit_value();
      DeleteCriticalSection(&g_cs.cs);
      return ret;
    }
  else
    ret = g_exit_value;
  return ret;
}
============


--
. . . . . . . . . . . . . . . . . . . . . . . . .
Gary Oberbrunner                garyo@...
GenArts, Inc.                   Tel: [phone]
955 Mass. Ave                   Fax: [phone]
Cambridge, MA 02139 USA         www.genarts.com

[Lennart Borgman (gmail)]

On Fri, Sep 25, 2009 at 12:04 AM, Gary Oberbrunner <garyo@...> wrote:
> emacsclientw exits with a random exit status when called from a win32 window app (such as emacs itself).  The reason is an uninitialized variable in w32_teardown_window in w32emacsclient.h.  I suspect if "ret" is initialized to zero (exit status success) in this function it would just work.  I don't have mingw so I can't compile it here myself, sorry.
>
> This is on emacs 23.1.50, also happens on the latest CVS test version.  I'm using the EmacsW32 patched version on XP, but don't think that matters either.

It does in this case. Thanks for the fix below, I will apply it to
EmacsW32. (The standard emacsclientw.exe does not have any windows.)

> The symptom is easy to reproduce.  In a shell window inside emacs (I use cygwin zsh, but any shell will work), run
>  emacsclient foo || echo BAD
> then C-x # to close the server buffer, and then look back in the shell window:
> % emacsclientw foo || echo BAD
> Waiting for Emacs...
> BAD
> %
>
> (I'm sure you already know that "emacsclient", the non-windows version, is totally broken, gives "Unknown&_command:&"... but emacsclientw is fine so it doesn't really matter.)
>
> Here's the affected code:
> ===========
> int
> w32_teardown_window (int connected)
> {
>  int ret;                    <<<<<<<<<<====== FIX HERE to int ret=0;
>  if (w32_window_app ())
>    {
>      w32_check_not_synced();
>      w32_wait_threads_fin(connected);
>      ret = W32_SYNC_get_g_exit_value();
>      DeleteCriticalSection(&g_cs.cs);
>      return ret;
>    }
>  else
>    ret = g_exit_value;
>  return ret;
> }
> ============
>
>
> --
> . . . . . . . . . . . . . . . . . . . . . . . . .
> Gary Oberbrunner                garyo@...
> GenArts, Inc.                   Tel: [phone]
> 955 Mass. Ave                   Fax: [phone]
> Cambridge, MA 02139 USA         www.genarts.com
>
>
>

[Lennart Borgman (gmail)]

Eh, or no. Is not the code below from an older version of emacsclient?


On Fri, Sep 25, 2009 at 12:07 AM, Lennart Borgman
<lennart.borgman@...> wrote:

> On Fri, Sep 25, 2009 at 12:04 AM, Gary Oberbrunner <garyo@...> wrote:
>> emacsclientw exits with a random exit status when called from a win32 window app (such as emacs itself).  The reason is an uninitialized variable in w32_teardown_window in w32emacsclient.h.  I suspect if "ret" is initialized to zero (exit status success) in this function it would just work.  I don't have mingw so I can't compile it here myself, sorry.
>>
>> This is on emacs 23.1.50, also happens on the latest CVS test version.  I'm using the EmacsW32 patched version on XP, but don't think that matters either.
>
> It does in this case. Thanks for the fix below, I will apply it to
> EmacsW32. (The standard emacsclientw.exe does not have any windows.)
>
>
>> The symptom is easy to reproduce.  In a shell window inside emacs (I use cygwin zsh, but any shell will work), run
>>  emacsclient foo || echo BAD
>> then C-x # to close the server buffer, and then look back in the shell window:
>> % emacsclientw foo || echo BAD
>> Waiting for Emacs...
>> BAD
>> %
>>
>> (I'm sure you already know that "emacsclient", the non-windows version, is totally broken, gives "Unknown&_command:&"... but emacsclientw is fine so it doesn't really matter.)
>>
>> Here's the affected code:
>> ===========
>> int
>> w32_teardown_window (int connected)
>> {
>>  int ret;                    <<<<<<<<<<====== FIX HERE to int ret=0;
>>  if (w32_window_app ())
>>    {
>>      w32_check_not_synced();
>>      w32_wait_threads_fin(connected);
>>      ret = W32_SYNC_get_g_exit_value();
>>      DeleteCriticalSection(&g_cs.cs);
>>      return ret;
>>    }
>>  else
>>    ret = g_exit_value;
>>  return ret;
>> }
>> ============
>>
>>
>> --
>> . . . . . . . . . . . . . . . . . . . . . . . . .
>> Gary Oberbrunner                garyo@...
>> GenArts, Inc.                   Tel: [phone]
>> 955 Mass. Ave                   Fax: [phone]
>> Cambridge, MA 02139 USA         www.genarts.com
>>
>>
>>
>

[garyo]

----- "Lennart Borgman" <lennart.borgman@...> wrote:

> Eh, or no. Is not the code below from an older version of
> emacsclient?

It's what I found in my c:/Program Files/Emacs/EmacsW32/gnuwin32/ dir... is that wrong?  Maybe that's not really getting installed with my emacs and it wormed its way in from elsewhere.  If so, perhaps you could send me (offline) the current copy?  Or is it browseable somewhere?

-- Gary

[Lennart Borgman (gmail)]

On Fri, Sep 25, 2009 at 12:53 AM, Gary Oberbrunner <garyo@...> wrote:
>
> ----- "Lennart Borgman" <lennart.borgman@...> wrote:
>
>> Eh, or no. Is not the code below from an older version of
>> emacsclient?
>
> It's what I found in my c:/Program Files/Emacs/EmacsW32/gnuwin32/ dir... is that wrong?  Maybe that's not really getting installed with my emacs and it wormed its way in from elsewhere.  If so, perhaps you could send me (offline) the current copy?  Or is it browseable somewhere?

Ah, my bad. I have forgot to remove these files.

No, the actual source is in the zip file I upload separately when I
upload Emacs+EmacsW32 (or in the diff file that comes Emacs+EmacsW32).
The zip files are here:

   http://ourcomments.org/Emacs/DL/EmacsW32/src/

It is required by GNU GPL that you make the whole sources available
somewhere and this is the C part of them (the elisp part comes with
Emacs+EmacsW32).

[garyo]

----- "Lennart Borgman" <lennart.borgman@...> wrote:

> Eh, or no. Is not the code below from an older version of
> emacsclient?

I just downloaded http://ourcomments.org/Emacs/DL/EmacsW32-only/EmacsW32-alone-1.56.zip and checked in there for \EmacsW32\gnuwin32\w32emacsclient.h and it looks the same as my copy.  Maybe that's not where I should be looking?

-- Gary

[Lennart Borgman (gmail)]

On Fri, Sep 25, 2009 at 1:02 AM, Gary Oberbrunner <garyo@...> wrote:
>
> ----- "Lennart Borgman" <lennart.borgman@...> wrote:
>
>> Eh, or no. Is not the code below from an older version of
>> emacsclient?
>
> I just downloaded http://ourcomments.org/Emacs/DL/EmacsW32-only/EmacsW32-alone-1.56.zip and checked in there for \EmacsW32\gnuwin32\w32emacsclient.h and it looks the same as my copy.  Maybe that's not where I should be looking?

No, please look in

   http://ourcomments.org/Emacs/DL/EmacsW32/

I am sorry for this confusion. These directories should have had
better names. I will change them if I get time to do it.

[garyo]

----- "Lennart Borgman" <lennart.borgman@...> wrote:
> No, please look in
>
>    http://ourcomments.org/Emacs/DL/EmacsW32/

I found the uptodate source in http://ourcomments.org/Emacs/DL/EmacsW32/src/emacs-CvsP090915.zip in emacs/lib-src/emacsclient.c and w32emacsclient.h (there's a "my" subdir with a different version, I assume that's irrelevant).  You're right it doesn't have the same bug.  finish_messages can still return an unset value if WINDOWSNT is not defined, but that's not the bug here.  I guess I don't know where it is then. :-(

In case it helps or anyone else wants to try, here's where it is when it exits; looks like it's exiting from an atexit func:

  msvcrt.dll!_exit()
> emacsclientw.exe!004050bc()
  ntdll.dll!_RtlFreeHeap@12()  + 0x130 bytes
  ntdll.dll!_RtlDebugSizeHeap@12()  + 0x9e bytes
  ntdll.dll!_RtlSizeHeap@12()  + 0x3a90a bytes
  msvcrt.dll!__msize()  + 0xb8 bytes
  msvcrt.dll!__unlockexit()  + 0x7 bytes
  msvcrt.dll!__onexit()  + 0x37 bytes
  msvcrt.dll!_atexit()  + 0xd bytes
  msvcrt.dll!_atexit()  + 0xd bytes
  emacsclientw.exe!0040124b()
  emacsclientw.exe!004012b8()
  kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes

Sorry to have to give up.  I'll just wrap it with a shell script that always returns 0.

-- Gary

[Kai Tetzlaff-2]

Gary Oberbrunner wrote:

> emacsclientw exits with a random exit status when called from a win32 window app (such as emacs itself).  The reason is an uninitialized variable in w32_teardown_window in w32emacsclient.h.  I suspect if "ret" is initialized to zero (exit status success) in this function it would just work.  I don't have mingw so I can't compile it here myself, sorry.
>
> This is on emacs 23.1.50, also happens on the latest CVS test version.  I'm using the EmacsW32 patched version on XP, but don't think that matters either.
>
> The symptom is easy to reproduce.  In a shell window inside emacs (I use cygwin zsh, but any shell will work), run
>   emacsclient foo || echo BAD
> then C-x # to close the server buffer, and then look back in the shell window:
> % emacsclientw foo || echo BAD
> Waiting for Emacs...
> BAD
> %
>
> (I'm sure you already know that "emacsclient", the non-windows version, is totally broken, gives "Unknown&_command:&"... but emacsclientw is fine so it doesn't really matter.)
>
> Here's the affected code:
> ===========
> int
> w32_teardown_window (int connected)
> {
>   int ret;                    <<<<<<<<<<====== FIX HERE to int ret=0;
>   if (w32_window_app ())
>     {
>       w32_check_not_synced();
>       w32_wait_threads_fin(connected);
>       ret = W32_SYNC_get_g_exit_value();
>       DeleteCriticalSection(&g_cs.cs);
>       return ret;
>     }
>   else
>     ret = g_exit_value;
>   return ret;
> }
> ============
>
>

I've also been running into this. Now, when looking at the code of what
i believe should be the patched version of emacsclient.c, the main
function looks like this:

int
main (argc, argv)
     int argc;
     char **argv;
{
  int i, rl, needlf = 0;
  char *cwd, *str;
  char string[BUFSIZ+1];
  int connected = 0;

  ...

  if ((emacs_socket = set_socket ( alternate_editor ||
(start_timeout_int > 0) , &islocal)) == INVALID_SOCKET)
    {
      ...
      connected = 1;
    }

  ...

  int exitval = finish_messages (connected);

  if (connected)
    exit(exitval);
  else
    exit(EXIT_FAILURE);
}

I.e. if connected is not set to a non-zero value somewhere after it gets
initialized, main will always exit with EXIT_FAILURE.

The only place in main which sets connected is the if block included
above. This block is only entered if set_socket returns INVALID_SOCKET
which seems to be the case only if the server has not been started yet.
So if you use emacsclient to send files to the server when it is already
running, it will always seem to be failing.

BR,
Kai

[Lennart Borgman (gmail)]

Hm, you are right ... ;-)

Did you find out how to fix it?


On Tue, Oct 13, 2009 at 1:03 AM, Kai Tetzlaff <kai.tetzlaff@...> wrote:

> Gary Oberbrunner wrote:
>> emacsclientw exits with a random exit status when called from a win32 window app (such as emacs itself).  The reason is an uninitialized variable in w32_teardown_window in w32emacsclient.h.  I suspect if "ret" is initialized to zero (exit status success) in this function it would just work.  I don't have mingw so I can't compile it here myself, sorry.
>>
>> This is on emacs 23.1.50, also happens on the latest CVS test version.  I'm using the EmacsW32 patched version on XP, but don't think that matters either.
>>
>> The symptom is easy to reproduce.  In a shell window inside emacs (I use cygwin zsh, but any shell will work), run
>>   emacsclient foo || echo BAD
>> then C-x # to close the server buffer, and then look back in the shell window:
>> % emacsclientw foo || echo BAD
>> Waiting for Emacs...
>> BAD
>> %
>>
>> (I'm sure you already know that "emacsclient", the non-windows version, is totally broken, gives "Unknown&_command:&"... but emacsclientw is fine so it doesn't really matter.)
>>
>> Here's the affected code:
>> ===========
>> int
>> w32_teardown_window (int connected)
>> {
>>   int ret;                    <<<<<<<<<<====== FIX HERE to int ret=0;
>>   if (w32_window_app ())
>>     {
>>       w32_check_not_synced();
>>       w32_wait_threads_fin(connected);
>>       ret = W32_SYNC_get_g_exit_value();
>>       DeleteCriticalSection(&g_cs.cs);
>>       return ret;
>>     }
>>   else
>>     ret = g_exit_value;
>>   return ret;
>> }
>> ============
>>
>>
>
> I've also been running into this. Now, when looking at the code of what
> i believe should be the patched version of emacsclient.c, the main
> function looks like this:
>
> int
> main (argc, argv)
>     int argc;
>     char **argv;
> {
>  int i, rl, needlf = 0;
>  char *cwd, *str;
>  char string[BUFSIZ+1];
>  int connected = 0;
>
>  ...
>
>  if ((emacs_socket = set_socket ( alternate_editor ||
> (start_timeout_int > 0) , &islocal)) == INVALID_SOCKET)
>    {
>      ...
>      connected = 1;
>    }
>
>  ...
>
>  int exitval = finish_messages (connected);
>
>  if (connected)
>    exit(exitval);
>  else
>    exit(EXIT_FAILURE);
> }
>
> I.e. if connected is not set to a non-zero value somewhere after it gets
> initialized, main will always exit with EXIT_FAILURE.
>
> The only place in main which sets connected is the if block included
> above. This block is only entered if set_socket returns INVALID_SOCKET
> which seems to be the case only if the server has not been started yet.
> So if you use emacsclient to send files to the server when it is already
> running, it will always seem to be failing.
>
> BR,
> Kai
>
>
>
>

[Kai Tetzlaff-2]

Hah, there's a lot of stuff in main which i did not yet have a closer
look at ;-) and i'm not really familiar with the code. But (as a quick
shot) how about checking emacs_socket in addition to connected:

if (connected || emacs_socket != INVALID_SOCKET) {
  exit(exitval);
else
  exit(EXIT_FAILURE);

Maybe even forgetting about connected at all...

Not sure though if this would work for all cases (or at all). If you
want i can have a closer look. But then i would probably also like to
set up a dev env to compile emacs on windows. Any good tips how to
start? I already have msys/mingw running and have been using it to port
some other stuff to windows ...

/Kai

> Hm, you are right ... ;-)
>
> Did you find out how to fix it?
>
>
> On Tue, Oct 13, 2009 at 1:03 AM, Kai Tetzlaff <kai.tetzlaff@...> wrote:
>> Gary Oberbrunner wrote:
>>> emacsclientw exits with a random exit status when called from a win32 window app (such as emacs itself).  The reason is an uninitialized variable in w32_teardown_window in w32emacsclient.h.  I suspect if "ret" is initialized to zero (exit status success) in this function it would just work.  I don't have mingw so I can't compile it here myself, sorry.
>>>
>>> This is on emacs 23.1.50, also happens on the latest CVS test version.  I'm using the EmacsW32 patched version on XP, but don't think that matters either.
>>>
>>> The symptom is easy to reproduce.  In a shell window inside emacs (I use cygwin zsh, but any shell will work), run
>>>   emacsclient foo || echo BAD
>>> then C-x # to close the server buffer, and then look back in the shell window:
>>> % emacsclientw foo || echo BAD
>>> Waiting for Emacs...
>>> BAD
>>> %
>>>
>>> (I'm sure you already know that "emacsclient", the non-windows version, is totally broken, gives "Unknown&_command:&"... but emacsclientw is fine so it doesn't really matter.)
>>>
>>> Here's the affected code:
>>> ===========
>>> int
>>> w32_teardown_window (int connected)
>>> {
>>>   int ret;                    <<<<<<<<<<====== FIX HERE to int ret=0;
>>>   if (w32_window_app ())
>>>     {
>>>       w32_check_not_synced();
>>>       w32_wait_threads_fin(connected);
>>>       ret = W32_SYNC_get_g_exit_value();
>>>       DeleteCriticalSection(&g_cs.cs);
>>>       return ret;
>>>     }
>>>   else
>>>     ret = g_exit_value;
>>>   return ret;
>>> }
>>> ============
>>>
>>>
>> I've also been running into this. Now, when looking at the code of what
>> i believe should be the patched version of emacsclient.c, the main
>> function looks like this:
>>
>> int
>> main (argc, argv)
>>     int argc;
>>     char **argv;
>> {
>>  int i, rl, needlf = 0;
>>  char *cwd, *str;
>>  char string[BUFSIZ+1];
>>  int connected = 0;
>>
>>  ...
>>
>>  if ((emacs_socket = set_socket ( alternate_editor ||
>> (start_timeout_int > 0) , &islocal)) == INVALID_SOCKET)
>>    {
>>      ...
>>      connected = 1;
>>    }
>>
>>  ...
>>
>>  int exitval = finish_messages (connected);
>>
>>  if (connected)
>>    exit(exitval);
>>  else
>>    exit(EXIT_FAILURE);
>> }
>>
>> I.e. if connected is not set to a non-zero value somewhere after it gets
>> initialized, main will always exit with EXIT_FAILURE.
>>
>> The only place in main which sets connected is the if block included
>> above. This block is only entered if set_socket returns INVALID_SOCKET
>> which seems to be the case only if the server has not been started yet.
>> So if you use emacsclient to send files to the server when it is already
>> running, it will always seem to be failing.
>>
>> BR,
>> Kai
>>
>>
>>
>>
>
>

[Lennart Borgman (gmail)]

Please look at EmacsW32 documentation at

  http://ourcomments.org/Emacs/EmacsW32Util.html

There is documentation about how to build Emacs on w32.


On Tue, Oct 13, 2009 at 1:52 AM, Kai Tetzlaff <kai.tetzlaff@...> wrote:

> Hah, there's a lot of stuff in main which i did not yet have a closer
> look at ;-) and i'm not really familiar with the code. But (as a quick
> shot) how about checking emacs_socket in addition to connected:
>
> if (connected || emacs_socket != INVALID_SOCKET) {
>  exit(exitval);
> else
>  exit(EXIT_FAILURE);
>
> Maybe even forgetting about connected at all...
>
> Not sure though if this would work for all cases (or at all). If you
> want i can have a closer look. But then i would probably also like to
> set up a dev env to compile emacs on windows. Any good tips how to
> start? I already have msys/mingw running and have been using it to port
> some other stuff to windows ...
>
> /Kai
>
>> Hm, you are right ... ;-)
>>
>> Did you find out how to fix it?
>>
>>
>> On Tue, Oct 13, 2009 at 1:03 AM, Kai Tetzlaff <kai.tetzlaff@...> wrote:
>>> Gary Oberbrunner wrote:
>>>> emacsclientw exits with a random exit status when called from a win32 window app (such as emacs itself).  The reason is an uninitialized variable in w32_teardown_window in w32emacsclient.h.  I suspect if "ret" is initialized to zero (exit status success) in this function it would just work.  I don't have mingw so I can't compile it here myself, sorry.
>>>>
>>>> This is on emacs 23.1.50, also happens on the latest CVS test version.  I'm using the EmacsW32 patched version on XP, but don't think that matters either.
>>>>
>>>> The symptom is easy to reproduce.  In a shell window inside emacs (I use cygwin zsh, but any shell will work), run
>>>>   emacsclient foo || echo BAD
>>>> then C-x # to close the server buffer, and then look back in the shell window:
>>>> % emacsclientw foo || echo BAD
>>>> Waiting for Emacs...
>>>> BAD
>>>> %
>>>>
>>>> (I'm sure you already know that "emacsclient", the non-windows version, is totally broken, gives "Unknown&_command:&"... but emacsclientw is fine so it doesn't really matter.)
>>>>
>>>> Here's the affected code:
>>>> ===========
>>>> int
>>>> w32_teardown_window (int connected)
>>>> {
>>>>   int ret;                    <<<<<<<<<<====== FIX HERE to int ret=0;
>>>>   if (w32_window_app ())
>>>>     {
>>>>       w32_check_not_synced();
>>>>       w32_wait_threads_fin(connected);
>>>>       ret = W32_SYNC_get_g_exit_value();
>>>>       DeleteCriticalSection(&g_cs.cs);
>>>>       return ret;
>>>>     }
>>>>   else
>>>>     ret = g_exit_value;
>>>>   return ret;
>>>> }
>>>> ============
>>>>
>>>>
>>> I've also been running into this. Now, when looking at the code of what
>>> i believe should be the patched version of emacsclient.c, the main
>>> function looks like this:
>>>
>>> int
>>> main (argc, argv)
>>>     int argc;
>>>     char **argv;
>>> {
>>>  int i, rl, needlf = 0;
>>>  char *cwd, *str;
>>>  char string[BUFSIZ+1];
>>>  int connected = 0;
>>>
>>>  ...
>>>
>>>  if ((emacs_socket = set_socket ( alternate_editor ||
>>> (start_timeout_int > 0) , &islocal)) == INVALID_SOCKET)
>>>    {
>>>      ...
>>>      connected = 1;
>>>    }
>>>
>>>  ...
>>>
>>>  int exitval = finish_messages (connected);
>>>
>>>  if (connected)
>>>    exit(exitval);
>>>  else
>>>    exit(EXIT_FAILURE);
>>> }
>>>
>>> I.e. if connected is not set to a non-zero value somewhere after it gets
>>> initialized, main will always exit with EXIT_FAILURE.
>>>
>>> The only place in main which sets connected is the if block included
>>> above. This block is only entered if set_socket returns INVALID_SOCKET
>>> which seems to be the case only if the server has not been started yet.
>>> So if you use emacsclient to send files to the server when it is already
>>> running, it will always seem to be failing.
>>>
>>> BR,
>>> Kai
>>>
>>>
>>>
>>>
>>
>>
>
>

[Kai Tetzlaff-2]

> Hah, there's a lot of stuff in main which i did not yet have a closer
> look at ;-) and i'm not really familiar with the code. But (as a quick
> shot) how about checking emacs_socket in addition to connected:
>
> if (connected || emacs_socket != INVALID_SOCKET) {
>   exit(exitval);
> else
>   exit(EXIT_FAILURE);
>
> Maybe even forgetting about connected at all...

I've bow compiled a version with the fix above. It's working in first
tests. I'll do some further testing and let you know how it goes. I can
also email the compiled binaries (emacsclient/emacsclientw) to anyone
who's interested.

>
> Not sure though if this would work for all cases (or at all). If you
> want i can have a closer look. But then i would probably also like to
> set up a dev env to compile emacs on windows. Any good tips how to
> start? I already have msys/mingw running and have been using it to port
> some other stuff to windows ...
>
> /Kai
>
>> Hm, you are right ... ;-)
>>
>> Did you find out how to fix it?
>>
>>
>> On Tue, Oct 13, 2009 at 1:03 AM, Kai Tetzlaff <kai.tetzlaff@...> wrote:
>>> Gary Oberbrunner wrote:
>>>> emacsclientw exits with a random exit status when called from a win32 window app (such as emacs itself).  The reason is an uninitialized variable in w32_teardown_window in w32emacsclient.h.  I suspect if "ret" is initialized to zero (exit status success) in this function it would just work.  I don't have mingw so I can't compile it here myself, sorry.
>>>>
>>>> This is on emacs 23.1.50, also happens on the latest CVS test version.  I'm using the EmacsW32 patched version on XP, but don't think that matters either.
>>>>
>>>> The symptom is easy to reproduce.  In a shell window inside emacs (I use cygwin zsh, but any shell will work), run
>>>>   emacsclient foo || echo BAD
>>>> then C-x # to close the server buffer, and then look back in the shell window:
>>>> % emacsclientw foo || echo BAD
>>>> Waiting for Emacs...
>>>> BAD
>>>> %
>>>>
>>>> (I'm sure you already know that "emacsclient", the non-windows version, is totally broken, gives "Unknown&_command:&"... but emacsclientw is fine so it doesn't really matter.)
>>>>
>>>> Here's the affected code:
>>>> ===========
>>>> int
>>>> w32_teardown_window (int connected)
>>>> {
>>>>   int ret;                    <<<<<<<<<<====== FIX HERE to int ret=0;
>>>>   if (w32_window_app ())
>>>>     {
>>>>       w32_check_not_synced();
>>>>       w32_wait_threads_fin(connected);
>>>>       ret = W32_SYNC_get_g_exit_value();
>>>>       DeleteCriticalSection(&g_cs.cs);
>>>>       return ret;
>>>>     }
>>>>   else
>>>>     ret = g_exit_value;
>>>>   return ret;
>>>> }
>>>> ============
>>>>
>>>>
>>> I've also been running into this. Now, when looking at the code of what
>>> i believe should be the patched version of emacsclient.c, the main
>>> function looks like this:
>>>
>>> int
>>> main (argc, argv)
>>>     int argc;
>>>     char **argv;
>>> {
>>>  int i, rl, needlf = 0;
>>>  char *cwd, *str;
>>>  char string[BUFSIZ+1];
>>>  int connected = 0;
>>>
>>>  ...
>>>
>>>  if ((emacs_socket = set_socket ( alternate_editor ||
>>> (start_timeout_int > 0) , &islocal)) == INVALID_SOCKET)
>>>    {
>>>      ...
>>>      connected = 1;
>>>    }
>>>
>>>  ...
>>>
>>>  int exitval = finish_messages (connected);
>>>
>>>  if (connected)
>>>    exit(exitval);
>>>  else
>>>    exit(EXIT_FAILURE);
>>> }
>>>
>>> I.e. if connected is not set to a non-zero value somewhere after it gets
>>> initialized, main will always exit with EXIT_FAILURE.
>>>
>>> The only place in main which sets connected is the if block included
>>> above. This block is only entered if set_socket returns INVALID_SOCKET
>>> which seems to be the case only if the server has not been started yet.
>>> So if you use emacsclient to send files to the server when it is already
>>> running, it will always seem to be failing.
>>>
>>> BR,
>>> Kai
>>>
>>>
>>>
>>>
>>
>
>
>
>

[Kai Tetzlaff-2]

Lennart Borgman wrote:
> Please look at EmacsW32 documentation at
>
>   http://ourcomments.org/Emacs/EmacsW32Util.html
>
> There is documentation about how to build Emacs on w32.

Thanks, that definitely helped to get started. I had some problems
getting the graphics libraries working. xpm needs some additional work
since simx.h (included by xpm.h) is only available in the source package
of libxpm/gnuwin32 and it's not installed by default in gnuwin32.

Also i'm still getting errors when compiling etags (s. below). But
emacsclient compiles fine and i started testing a changed version (s. my
other post in this thread).


gmake -Rrk  -C ../lib-src all
gmake[1]: Entering directory `C:/kt/Work/src/emacs/lib-src'
gcc -o oo-spd/i386/ctags.exe  -gdwarf-2 -g3    oo-spd/i386/ctags.o
oo-spd/i386/getopt.o oo-spd/i386/getopt1.o oo-spd/i38
6/ntlib.o oo-spd/i386/regex.o   -ladvapi32
oo-spd/i386/ctags.o: In function `readline':
C:\kt\Work\src\emacs\lib-src/ctags.c:6335: undefined reference to
`_imp__re_match'
oo-spd/i386/ctags.o: In function `add_regex':
C:\kt\Work\src\emacs\lib-src/ctags.c:5880: undefined reference to
`_imp__re_set_syntax'
C:\kt\Work\src\emacs\lib-src/ctags.c:5884: undefined reference to
`_imp__re_compile_pattern'
C:\kt\Work\src\emacs\lib-src/ctags.c:5882: undefined reference to
`_imp__re_set_syntax'
oo-spd/i386/ctags.o: In function `regex_tag_multiline':
C:\kt\Work\src\emacs\lib-src/ctags.c:6006: undefined reference to
`_imp__re_search'
collect2: ld returned 1 exit status
gmake[1]: *** [oo-spd/i386/ctags.exe] Error 1
gcc -o oo-spd/i386/etags.exe  -gdwarf-2 -g3    oo-spd/i386/etags.o
oo-spd/i386/getopt.o oo-spd/i386/getopt1.o oo-spd/i38
6/ntlib.o oo-spd/i386/regex.o   -ladvapi32
oo-spd/i386/etags.o: In function `readline':
C:\kt\Work\src\emacs\lib-src/etags.c:6335: undefined reference to
`_imp__re_match'
oo-spd/i386/etags.o: In function `add_regex':
C:\kt\Work\src\emacs\lib-src/etags.c:5880: undefined reference to
`_imp__re_set_syntax'
C:\kt\Work\src\emacs\lib-src/etags.c:5884: undefined reference to
`_imp__re_compile_pattern'
C:\kt\Work\src\emacs\lib-src/etags.c:5882: undefined reference to
`_imp__re_set_syntax'
oo-spd/i386/etags.o: In function `regex_tag_multiline':
C:\kt\Work\src\emacs\lib-src/etags.c:6006: undefined reference to
`_imp__re_search'
collect2: ld returned 1 exit status
gmake[1]: *** [oo-spd/i386/etags.exe] Error 1

>
>
> On Tue, Oct 13, 2009 at 1:52 AM, Kai Tetzlaff <kai.tetzlaff@...> wrote:
>> Hah, there's a lot of stuff in main which i did not yet have a closer
>> look at ;-) and i'm not really familiar with the code. But (as a quick
>> shot) how about checking emacs_socket in addition to connected:
>>
>> if (connected || emacs_socket != INVALID_SOCKET) {
>>  exit(exitval);
>> else
>>  exit(EXIT_FAILURE);
>>
>> Maybe even forgetting about connected at all...
>>
>> Not sure though if this would work for all cases (or at all). If you
>> want i can have a closer look. But then i would probably also like to
>> set up a dev env to compile emacs on windows. Any good tips how to
>> start? I already have msys/mingw running and have been using it to port
>> some other stuff to windows ...
>>
>> /Kai
>>
>>> Hm, you are right ... ;-)
>>>
>>> Did you find out how to fix it?
>>>
>>>
>>> On Tue, Oct 13, 2009 at 1:03 AM, Kai Tetzlaff <kai.tetzlaff@...> wrote:
>>>> Gary Oberbrunner wrote:
>>>>> emacsclientw exits with a random exit status when called from a win32 window app (such as emacs itself).  The reason is an uninitialized variable in w32_teardown_window in w32emacsclient.h.  I suspect if "ret" is initialized to zero (exit status success) in this function it would just work.  I don't have mingw so I can't compile it here myself, sorry.
>>>>>
>>>>> This is on emacs 23.1.50, also happens on the latest CVS test version.  I'm using the EmacsW32 patched version on XP, but don't think that matters either.
>>>>>
>>>>> The symptom is easy to reproduce.  In a shell window inside emacs (I use cygwin zsh, but any shell will work), run
>>>>>   emacsclient foo || echo BAD
>>>>> then C-x # to close the server buffer, and then look back in the shell window:
>>>>> % emacsclientw foo || echo BAD
>>>>> Waiting for Emacs...
>>>>> BAD
>>>>> %
>>>>>
>>>>> (I'm sure you already know that "emacsclient", the non-windows version, is totally broken, gives "Unknown&_command:&"... but emacsclientw is fine so it doesn't really matter.)
>>>>>
>>>>> Here's the affected code:
>>>>> ===========
>>>>> int
>>>>> w32_teardown_window (int connected)
>>>>> {
>>>>>   int ret;                    <<<<<<<<<<====== FIX HERE to int ret=0;
>>>>>   if (w32_window_app ())
>>>>>     {
>>>>>       w32_check_not_synced();
>>>>>       w32_wait_threads_fin(connected);
>>>>>       ret = W32_SYNC_get_g_exit_value();
>>>>>       DeleteCriticalSection(&g_cs.cs);
>>>>>       return ret;
>>>>>     }
>>>>>   else
>>>>>     ret = g_exit_value;
>>>>>   return ret;
>>>>> }
>>>>> ============
>>>>>
>>>>>
>>>> I've also been running into this. Now, when looking at the code of what
>>>> i believe should be the patched version of emacsclient.c, the main
>>>> function looks like this:
>>>>
>>>> int
>>>> main (argc, argv)
>>>>     int argc;
>>>>     char **argv;
>>>> {
>>>>  int i, rl, needlf = 0;
>>>>  char *cwd, *str;
>>>>  char string[BUFSIZ+1];
>>>>  int connected = 0;
>>>>
>>>>  ...
>>>>
>>>>  if ((emacs_socket = set_socket ( alternate_editor ||
>>>> (start_timeout_int > 0) , &islocal)) == INVALID_SOCKET)
>>>>    {
>>>>      ...
>>>>      connected = 1;
>>>>    }
>>>>
>>>>  ...
>>>>
>>>>  int exitval = finish_messages (connected);
>>>>
>>>>  if (connected)
>>>>    exit(exitval);
>>>>  else
>>>>    exit(EXIT_FAILURE);
>>>> }
>>>>
>>>> I.e. if connected is not set to a non-zero value somewhere after it gets
>>>> initialized, main will always exit with EXIT_FAILURE.
>>>>
>>>> The only place in main which sets connected is the if block included
>>>> above. This block is only entered if set_socket returns INVALID_SOCKET
>>>> which seems to be the case only if the server has not been started yet.
>>>> So if you use emacsclient to send files to the server when it is already
>>>> running, it will always seem to be failing.
>>>>
>>>> BR,
>>>> Kai
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>

[Lennart Borgman (gmail)]

On Thu, Oct 15, 2009 at 10:41 AM, Kai Tetzlaff <kai.tetzlaff@...> wrote:

> Lennart Borgman wrote:
>> Please look at EmacsW32 documentation at
>>
>>   http://ourcomments.org/Emacs/EmacsW32Util.html
>>
>> There is documentation about how to build Emacs on w32.
>
> Thanks, that definitely helped to get started. I had some problems
> getting the graphics libraries working. xpm needs some additional work
> since simx.h (included by xpm.h) is only available in the source package
> of libxpm/gnuwin32 and it's not installed by default in gnuwin32.
>
> Also i'm still getting errors when compiling etags (s. below). But
> emacsclient compiles fine and i started testing a changed version (s. my
> other post in this thread).

I might have forgotten something. Could you perhaps also read
emacs/nt/INSTALL in the source directory to see if that helps? (And
tell me what I have missed.)

[Kai Tetzlaff-2]

Kai Tetzlaff wrote:

>> Hah, there's a lot of stuff in main which i did not yet have a closer
>> look at ;-) and i'm not really familiar with the code. But (as a quick
>> shot) how about checking emacs_socket in addition to connected:
>>
>> if (connected || emacs_socket != INVALID_SOCKET) {
>>   exit(exitval);
>> else
>>   exit(EXIT_FAILURE);
>>
>> Maybe even forgetting about connected at all...
>
> I've bow compiled a version with the fix above. It's working in first
> tests. I'll do some further testing and let you know how it goes. I can
> also email the compiled binaries (emacsclient/emacsclientw) to anyone
> who's interested.

After a closer look to the sources of both the patched and the original
GNU version of emacsclient.c i would say that the following:

if (INVALID_SOCKET != emacs_socket) {
  exit(exitval);
else
  exit(EXIT_FAILURE);

is a bit simpler and should work exactly like my original proposal above
(if connected is different from 0, emacs_socket will always also be !=
INVALID_SOCKET). The original GNU version returns a non zero value only
when called without a file name. So by doing the socket check and by
using exitval the patched version is already doing more checking than
the GNU original.

(Actually i'm a bit curious: exitval has been added to the patched
version, but it currently seems to have no real function. It's using a
global/static variable g_exit_value which could be used to set exit
codes from anywhere in the sources. But this is actually never done.
g_exit_value gets initialized with EXIT_SUCCESS and that's about it as
far as i can tell. Its value is never changed afterwards.)

Both proposed changes will miss out on errors reported back from emacs
to emacsclient in:

  /* Now, wait for an answer and print any messages.  */
  trace ("before while.");
  while ((rl = recv (emacs_socket, string, BUFSIZ, 0)) > 0)
    {
      trace ("while rl");
      char *p;
      string[rl] = '\0';

      p = string + strlen (string) - 1;
      while (p > string && *p == '\n')
        *p-- = 0;

...
      else if (strprefix ("-error ", string))
        {
          /* -error DESCRIPTION: Signal an error on the terminal. */
          str = unquote_argument (string + strlen ("-error "));
          if (needlf)
            add_to_wait_message ("\n");
          fprintf (stderr, "*ERROR*: %s", str);
          add_to_wait_message ("*ERROR*: %s", str);
          needlf = str[0] == '\0' ? needlf : str[strlen (str) - 1] != '\n';
        }

...
      else
        {
          /* Unknown command. */
          if (needlf)
            add_to_wait_message ("\n");
          add_to_wait_message ("*ERROR*: Unknown message: %s", string);
          needlf = string[0] == '\0' ? needlf : string[strlen (string) -
1] != '\n';
        }
    }

I could provide a patch which improves on this a bit. But since the GNU
version also just ignores these errors and just prints them to the
terminal i guess we should do just the same and also keep ignoring those.

>
>> Not sure though if this would work for all cases (or at all). If you
>> want i can have a closer look. But then i would probably also like to
>> set up a dev env to compile emacs on windows. Any good tips how to
>> start? I already have msys/mingw running and have been using it to port
>> some other stuff to windows ...
>>
>> /Kai
>>
>>> Hm, you are right ... ;-)
>>>
>>> Did you find out how to fix it?
>>>
>>>
>>> On Tue, Oct 13, 2009 at 1:03 AM, Kai Tetzlaff <kai.tetzlaff@...> wrote:
>>>> Gary Oberbrunner wrote:
>>>>> emacsclientw exits with a random exit status when called from a win32 window app (such as emacs itself).  The reason is an uninitialized variable in w32_teardown_window in w32emacsclient.h.  I suspect if "ret" is initialized to zero (exit status success) in this function it would just work.  I don't have mingw so I can't compile it here myself, sorry.
>>>>>
>>>>> This is on emacs 23.1.50, also happens on the latest CVS test version.  I'm using the EmacsW32 patched version on XP, but don't think that matters either.
>>>>>
>>>>> The symptom is easy to reproduce.  In a shell window inside emacs (I use cygwin zsh, but any shell will work), run
>>>>>   emacsclient foo || echo BAD
>>>>> then C-x # to close the server buffer, and then look back in the shell window:
>>>>> % emacsclientw foo || echo BAD
>>>>> Waiting for Emacs...
>>>>> BAD
>>>>> %
>>>>>
>>>>> (I'm sure you already know that "emacsclient", the non-windows version, is totally broken, gives "Unknown&_command:&"... but emacsclientw is fine so it doesn't really matter.)
>>>>>
>>>>> Here's the affected code:
>>>>> ===========
>>>>> int
>>>>> w32_teardown_window (int connected)
>>>>> {
>>>>>   int ret;                    <<<<<<<<<<====== FIX HERE to int ret=0;
>>>>>   if (w32_window_app ())
>>>>>     {
>>>>>       w32_check_not_synced();
>>>>>       w32_wait_threads_fin(connected);
>>>>>       ret = W32_SYNC_get_g_exit_value();
>>>>>       DeleteCriticalSection(&g_cs.cs);
>>>>>       return ret;
>>>>>     }
>>>>>   else
>>>>>     ret = g_exit_value;
>>>>>   return ret;
>>>>> }
>>>>> ============
>>>>>
>>>>>
>>>> I've also been running into this. Now, when looking at the code of what
>>>> i believe should be the patched version of emacsclient.c, the main
>>>> function looks like this:
>>>>
>>>> int
>>>> main (argc, argv)
>>>>     int argc;
>>>>     char **argv;
>>>> {
>>>>  int i, rl, needlf = 0;
>>>>  char *cwd, *str;
>>>>  char string[BUFSIZ+1];
>>>>  int connected = 0;
>>>>
>>>>  ...
>>>>
>>>>  if ((emacs_socket = set_socket ( alternate_editor ||
>>>> (start_timeout_int > 0) , &islocal)) == INVALID_SOCKET)
>>>>    {
>>>>      ...
>>>>      connected = 1;
>>>>    }
>>>>
>>>>  ...
>>>>
>>>>  int exitval = finish_messages (connected);
>>>>
>>>>  if (connected)
>>>>    exit(exitval);
>>>>  else
>>>>    exit(EXIT_FAILURE);
>>>> }
>>>>
>>>> I.e. if connected is not set to a non-zero value somewhere after it gets
>>>> initialized, main will always exit with EXIT_FAILURE.
>>>>
>>>> The only place in main which sets connected is the if block included
>>>> above. This block is only entered if set_socket returns INVALID_SOCKET
>>>> which seems to be the case only if the server has not been started yet.
>>>> So if you use emacsclient to send files to the server when it is already
>>>> running, it will always seem to be failing.
>>>>
>>>> BR,
>>>> Kai
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
>
>
>

[Lennart Borgman (gmail)]

Hi Kai,

When you are satisfied with your changes, could you then please just
send them to me so I can include them?

I am thinking about setting up a repository on Launchpad so that it is
easier to get those changes for anyone who is interested.


On Fri, Oct 16, 2009 at 10:02 AM, Kai Tetzlaff <kai.tetzlaff@...> wrote:

> Kai Tetzlaff wrote:
>>> Hah, there's a lot of stuff in main which i did not yet have a closer
>>> look at ;-) and i'm not really familiar with the code. But (as a quick
>>> shot) how about checking emacs_socket in addition to connected:
>>>
>>> if (connected || emacs_socket != INVALID_SOCKET) {
>>>   exit(exitval);
>>> else
>>>   exit(EXIT_FAILURE);
>>>
>>> Maybe even forgetting about connected at all...
>>
>> I've bow compiled a version with the fix above. It's working in first
>> tests. I'll do some further testing and let you know how it goes. I can
>> also email the compiled binaries (emacsclient/emacsclientw) to anyone
>> who's interested.
>
> After a closer look to the sources of both the patched and the original
> GNU version of emacsclient.c i would say that the following:
>
> if (INVALID_SOCKET != emacs_socket) {
>  exit(exitval);
> else
>  exit(EXIT_FAILURE);
>
> is a bit simpler and should work exactly like my original proposal above
> (if connected is different from 0, emacs_socket will always also be !=
> INVALID_SOCKET). The original GNU version returns a non zero value only
> when called without a file name. So by doing the socket check and by
> using exitval the patched version is already doing more checking than
> the GNU original.
>
> (Actually i'm a bit curious: exitval has been added to the patched
> version, but it currently seems to have no real function. It's using a
> global/static variable g_exit_value which could be used to set exit
> codes from anywhere in the sources. But this is actually never done.
> g_exit_value gets initialized with EXIT_SUCCESS and that's about it as
> far as i can tell. Its value is never changed afterwards.)
>
> Both proposed changes will miss out on errors reported back from emacs
> to emacsclient in:
>
>  /* Now, wait for an answer and print any messages.  */
>  trace ("before while.");
>  while ((rl = recv (emacs_socket, string, BUFSIZ, 0)) > 0)
>    {
>      trace ("while rl");
>      char *p;
>      string[rl] = '\0';
>
>      p = string + strlen (string) - 1;
>      while (p > string && *p == '\n')
>        *p-- = 0;
>
> ...
>      else if (strprefix ("-error ", string))
>        {
>          /* -error DESCRIPTION: Signal an error on the terminal. */
>          str = unquote_argument (string + strlen ("-error "));
>          if (needlf)
>            add_to_wait_message ("\n");
>          fprintf (stderr, "*ERROR*: %s", str);
>          add_to_wait_message ("*ERROR*: %s", str);
>          needlf = str[0] == '\0' ? needlf : str[strlen (str) - 1] != '\n';
>        }
>
> ...
>      else
>        {
>          /* Unknown command. */
>          if (needlf)
>            add_to_wait_message ("\n");
>          add_to_wait_message ("*ERROR*: Unknown message: %s", string);
>          needlf = string[0] == '\0' ? needlf : string[strlen (string) -
> 1] != '\n';
>        }
>    }
>
> I could provide a patch which improves on this a bit. But since the GNU
> version also just ignores these errors and just prints them to the
> terminal i guess we should do just the same and also keep ignoring those.
>
>>
>>> Not sure though if this would work for all cases (or at all). If you
>>> want i can have a closer look. But then i would probably also like to
>>> set up a dev env to compile emacs on windows. Any good tips how to
>>> start? I already have msys/mingw running and have been using it to port
>>> some other stuff to windows ...
>>>
>>> /Kai
>>>
>>>> Hm, you are right ... ;-)
>>>>
>>>> Did you find out how to fix it?
>>>>
>>>>
>>>> On Tue, Oct 13, 2009 at 1:03 AM, Kai Tetzlaff <kai.tetzlaff@...> wrote:
>>>>> Gary Oberbrunner wrote:
>>>>>> emacsclientw exits with a random exit status when called from a win32 window app (such as emacs itself).  The reason is an uninitialized variable in w32_teardown_window in w32emacsclient.h.  I suspect if "ret" is initialized to zero (exit status success) in this function it would just work.  I don't have mingw so I can't compile it here myself, sorry.
>>>>>>
>>>>>> This is on emacs 23.1.50, also happens on the latest CVS test version.  I'm using the EmacsW32 patched version on XP, but don't think that matters either.
>>>>>>
>>>>>> The symptom is easy to reproduce.  In a shell window inside emacs (I use cygwin zsh, but any shell will work), run
>>>>>>   emacsclient foo || echo BAD
>>>>>> then C-x # to close the server buffer, and then look back in the shell window:
>>>>>> % emacsclientw foo || echo BAD
>>>>>> Waiting for Emacs...
>>>>>> BAD
>>>>>> %
>>>>>>
>>>>>> (I'm sure you already know that "emacsclient", the non-windows version, is totally broken, gives "Unknown&_command:&"... but emacsclientw is fine so it doesn't really matter.)
>>>>>>
>>>>>> Here's the affected code:
>>>>>> ===========
>>>>>> int
>>>>>> w32_teardown_window (int connected)
>>>>>> {
>>>>>>   int ret;                    <<<<<<<<<<====== FIX HERE to int ret=0;
>>>>>>   if (w32_window_app ())
>>>>>>     {
>>>>>>       w32_check_not_synced();
>>>>>>       w32_wait_threads_fin(connected);
>>>>>>       ret = W32_SYNC_get_g_exit_value();
>>>>>>       DeleteCriticalSection(&g_cs.cs);
>>>>>>       return ret;
>>>>>>     }
>>>>>>   else
>>>>>>     ret = g_exit_value;
>>>>>>   return ret;
>>>>>> }
>>>>>> ============
>>>>>>
>>>>>>
>>>>> I've also been running into this. Now, when looking at the code of what
>>>>> i believe should be the patched version of emacsclient.c, the main
>>>>> function looks like this:
>>>>>
>>>>> int
>>>>> main (argc, argv)
>>>>>     int argc;
>>>>>     char **argv;
>>>>> {
>>>>>  int i, rl, needlf = 0;
>>>>>  char *cwd, *str;
>>>>>  char string[BUFSIZ+1];
>>>>>  int connected = 0;
>>>>>
>>>>>  ...
>>>>>
>>>>>  if ((emacs_socket = set_socket ( alternate_editor ||
>>>>> (start_timeout_int > 0) , &islocal)) == INVALID_SOCKET)
>>>>>    {
>>>>>      ...
>>>>>      connected = 1;
>>>>>    }
>>>>>
>>>>>  ...
>>>>>
>>>>>  int exitval = finish_messages (connected);
>>>>>
>>>>>  if (connected)
>>>>>    exit(exitval);
>>>>>  else
>>>>>    exit(EXIT_FAILURE);
>>>>> }
>>>>>
>>>>> I.e. if connected is not set to a non-zero value somewhere after it gets
>>>>> initialized, main will always exit with EXIT_FAILURE.
>>>>>
>>>>> The only place in main which sets connected is the if block included
>>>>> above. This block is only entered if set_socket returns INVALID_SOCKET
>>>>> which seems to be the case only if the server has not been started yet.
>>>>> So if you use emacsclient to send files to the server when it is already
>>>>> running, it will always seem to be failing.
>>>>>
>>>>> BR,
>>>>> Kai
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>

[Jason Rumney-4]

Kai Tetzlaff wrote:
> Thanks, that definitely helped to get started. I had some problems
> getting the graphics libraries working. xpm needs some additional work
> since simx.h (included by xpm.h) is only available in the source package
> of libxpm/gnuwin32 and it's not installed by default in gnuwin32.
>  
I'd recommend using the libxpm source package on
ftp.gnu.org/gnu/emacs/windows, as it is more up to date.

[Kai Tetzlaff-2]

Hi Lennard,

> Hi Kai,
>
> When you are satisfied with your changes, could you then please just
> send them to me so I can include them?

sorry for the late reply. Below is the fix i'm using now. So far there
have been no issues with it:

--- emacsclient-my.c 2009-10-04 21:56:34 +0200
+++ emacsclient-kt.c 2009-10-23 09:18:10 +0200
@@ -2103,7 +2103,7 @@

   int exitval = finish_messages (connected);

-  if (connected)
+  if (INVALID_SOCKET != emacs_socket)
     exit(exitval);
   else
     exit(EXIT_FAILURE);

>
> I am thinking about setting up a repository on Launchpad so that it is
> easier to get those changes for anyone who is interested.

This would be a good idea. I would definitely use it. An even better
option would be to get (some of) the fixes/add-ons integrated in GNU
emacs. But i guess you tried that already ;-).

BR,
Kai

[Kai Tetzlaff-2]

Jason Rumney wrote:
> Kai Tetzlaff wrote:
>> Thanks, that definitely helped to get started. I had some problems
>> getting the graphics libraries working. xpm needs some additional work
>> since simx.h (included by xpm.h) is only available in the source package
>> of libxpm/gnuwin32 and it's not installed by default in gnuwin32.
>>  
> I'd recommend using the libxpm source package on
> ftp.gnu.org/gnu/emacs/windows, as it is more up to date.

Thanks for this tip Jason. After the first problems i just stopped
trying (my main goal was a fix for emacsclient which did not actually
require emacs to compile). But i will probably give it another go over
the weekend...