addpm.c: DdeConnect() without timeout

addpm.c: DdeConnect() without timeout

[Dhruva Krishnamurthy]

Hello,
 I had reported a problem with addpm.exe on W2K. I am building CVS HEAD
 using MinGW-GCC and MSVC6 and face the same problem of addpm.exe getting
 stuck duing "nmake (gmake) install".
I found that it is getting stuck in DdeConnect(). I am not aware of DDE
mechanism but feel we should have a time out. Since "addpm.exe" is trivia
and does not affect the working of GNU Emacs, the install should progress
even if "addpm.exe" fails.

 Also, I noticed "gmake info" failes on MinGW-GCC on W2K. The problem is
 with backslash ("\") in makefile.w32-in at target "info:". Changing it
 to forward slashes "/", fixes this problem.

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: addpm.c: DdeConnect() without timeout

[Jason Rumney]

"Dhruva Krishnamurthy" <devel@member.fsf.org> writes:

> Hello,
>  I had reported a problem with addpm.exe on W2K. I am building CVS HEAD
>  using MinGW-GCC and MSVC6 and face the same problem of addpm.exe getting
>  stuck duing "nmake (gmake) install".
> I found that it is getting stuck in DdeConnect(). I am not aware of DDE
> mechanism but feel we should have a time out. Since "addpm.exe" is trivia
> and does not affect the working of GNU Emacs, the install should progress
> even if "addpm.exe" fails.

If you can find where in the addpm code it is failing, we can catch
whatever problem it is and do something appropriate.

Could it be due to access rights to the Start Menu or registry?

>  Also, I noticed "gmake info" failes on MinGW-GCC on W2K. The problem is
>  with backslash ("\") in makefile.w32-in at target "info:". Changing it
>  to forward slashes "/", fixes this problem.

nmake seems to accept either, so I've installed this fix.

gmake info: makefile patch

[Dhruva Krishnamurthy]

> >  Also, I noticed "gmake info" failes on MinGW-GCC on W2K. The problem is
> >  with backslash ("\") in makefile.w32-in at target "info:". Changing it
> >  to forward slashes "/", fixes this problem.
> 
> nmake seems to accept either, so I've installed this fix.

It has to be done in emacs/nt/makefile.w32-in file (not in
man/makefile.w32-in). Sorry for not being more specific.

-dhruva

Diff for original versus modified [diff -p
\tmp\cvs\emacs\nt\makefile.w32-in makefile.w32-in]

*** \tmp\cvs\emacs\nt\makefile.w32-in   Fri Apr 23 09:16:57 2004
--- makefile.w32-in     Mon May  3 12:59:23 2004
*************** force-info:
*** 218,226 ****
  # put the info files in $(infodir),
  # so we can do ok running make in the build dir.
  info: force-info
!       (cd ..\man && $(MAKE) $(MFLAGS) info)
!       (cd ..\lispref && $(MAKE) $(MFLAGS) info)
!       (cd ..\lispintro && $(MAKE) $(MFLAGS) info)

  #
  # Maintenance
--- 218,226 ----
  # put the info files in $(infodir),
  # so we can do ok running make in the build dir.
  info: force-info
!       (cd ../man && $(MAKE) $(MFLAGS) info)
!       (cd ../lispref && $(MAKE) $(MFLAGS) info)
!       (cd ../lispintro && $(MAKE) $(MFLAGS) info)

  #
  # Maintenance
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: addpm.c: DdeConnect() without timeout

[Dhruva Krishnamurthy]

On Mon, 03 May 2004 06:45:15 +0000, "Jason Rumney" <jasonr@gnu.org> said:
> "Dhruva Krishnamurthy" <devel@member.fsf.org> writes:

> > face the same problem of addpm.exe getting
> >  stuck duing "nmake (gmake) install".
> > I found that it is getting stuck in DdeConnect(). I am not aware of DDE
> > mechanism but feel we should have a time out. Since "addpm.exe" is trivia
> > and does not affect the working of GNU Emacs, the install should progress
> > even if "addpm.exe" fails.

> If you can find where in the addpm code it is failing, we can catch
> whatever problem it is and do something appropriate.
>
> Could it be due to access rights to the Start Menu or registry?

I think it was due to some registry corruption, I am not sure of what
though. I ran a registry cleaning utility. I am now able to run
"addpm.exe" and it works as it used to earlier. So, there is no problem.
However, this is the second time I am facing this problem and I feel we
should have a time out mechanism if supported by DdeConnect(). There is 1
call to DdeConnect() in addpm.c at line:184. It gets stuck there when I
faced the problem. Calls to DdeInitialize() returns a successfull code.
It might be a good idea to check that too to make it a little more
robust.
Ex: 
if(DMLERR_NO_ERROR!=DdeInitialize())
  return(1); // Some non zero error value

-dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: addpm.c: DdeConnect() without timeout

[Benjamin Riefenstahl]

Hi Jason, all,


> "Dhruva Krishnamurthy" <devel@member.fsf.org> writes:
>> I found that it is getting stuck in DdeConnect(). I am not aware of
>> DDE mechanism but feel we should have a time out. [...]

Jason Rumney <jasonr@gnu.org> writes:
> [...]
> Could it be due to access rights to the Start Menu or registry?

If I may put in some of my own experience with DDE here:

The usual place where DDE connections block is during service
discovery.  The DDE mechanism will broadcast a message to find its
peer and it will wait for all applications to answer.

If any thread in any application has a message queue, it gets the
broadcast message regardless whether it's actually doing DDE or not.
Normally, even if the application doesn't handle the message itself,
it will pass it on to the Windows default handler and that will do the
right thing.  But if the thread doesn't handle the message at all, the
DDE discovery is stuck at that point.

A message queue gets installed automatically, once a thread calls
GetMessage() for the first time.  Some applications do that only
temporarily (e.g. like for a message box) and after that they never
service their queue again.  Curiously, the docs for
MsgWaitForMultipleObjects() seem to be the only place in MSDN that
actually mentions this problem.  Of course that page just says, "don't
do that."

DDE was designed for the cooperative 16-bit Windows system where such
an application would have brought the system to a complete halt
anyway, so there was no propblem there.  In the preemptive 32-bit
Windows environment DDE is not a reliable IPC mechanism.

Consequences: Use a timeout and abort the operation.  I'm not sure how
to do that with DDEML.  Probably a separate thread would have to be
used to interrupt the call to DdeConnect().  For an installation
program this is probably overkill, though.  From the user side, if the
user runs into the problem, he can try to stop all non-essential
processes and call the installation process again.


benny

bug#202: marked as done (addpm.c: DdeConnect() without timeout)

[Emacs bug Tracking System]

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


Your message dated Thu, 15 Jan 2009 23:10:36 +0800
with message-id <496F51EC.3050104@gnu.org>
and subject line bug#202: addpm.c: DdeConnect() without timeout
has caused the Emacs bug report #202,
regarding addpm.c: DdeConnect() without timeout
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
202: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=202
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 5809 bytes --]

From: "Dhruva Krishnamurthy" <devel@member.fsf.org>
To: "Emacs Devel" <emacs-devel@gnu.org>
Subject: addpm.c: DdeConnect() without timeout
Date: Mon, 03 May 2004 11:37:15 +0530
Message-ID: <1083564435.20498.185520391@webmail.messagingengine.com>

Hello,
 I had reported a problem with addpm.exe on W2K. I am building CVS HEAD
 using MinGW-GCC and MSVC6 and face the same problem of addpm.exe getting
 stuck duing "nmake (gmake) install".
I found that it is getting stuck in DdeConnect(). I am not aware of DDE
mechanism but feel we should have a time out. Since "addpm.exe" is trivia
and does not affect the working of GNU Emacs, the install should progress
even if "addpm.exe" fails.

 Also, I noticed "gmake info" failes on MinGW-GCC on W2K. The problem is
 with backslash ("\") in makefile.w32-in at target "info:". Changing it
 to forward slashes "/", fixes this problem.

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel



[-- Attachment #3: Type: message/rfc822, Size: 2743 bytes --]

From: Jason Rumney <jasonr@gnu.org>
To: 202-done@emacsbugs.donarmstrong.com
Subject: bug#202: addpm.c: DdeConnect() without timeout
Date: Thu, 15 Jan 2009 23:10:36 +0800
Message-ID: <496F51EC.3050104@gnu.org>


I decided to fix this by creating the Shortcuts using the Shell API 
where possible, only falling back on the deprecated DDE ProgMan 
interface when that fails (which should only happen on copies of Windows 
95 and NT 4.0 that have not been updated since 1996).