Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: "Dave Korn" <dk AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: popups upon library errors.
Date: Tue, 30 Mar 2004 10:58:38 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <Pine.GSO.4.56.0403292235550.1185@slinky.cs.nyu.edu>
Message-ID: <NUTMEGmLAztxc1o8yfo000002a5@NUTMEG.CAM.ARTIMI.COM>


> -----Original Message-----
> From: cygwin-owner On Behalf Of Igor Pechtchanski
> Sent: 30 March 2004 04:40

> AFAIR, this popup appears whenever a DLL is in the PATH but 
> is not executable.  I don't think there's an easy way of 
> convincing Windows to keep control in the application after 
> this (short of using dlopen() for all dynamically linked 
> calls, and checking the return value -- which you don't 
> really want to do).  If you discover a way (MSDN would be a 
> good start), PTC.

SetDefaultErrorMode or do I mean SetHardErrorMode?

Ah, here we go:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/
seterrormode.asp


  It looks like a call to SetErrorMode(SEM_FAILCRITICALERRORS) might do the
trick.  This is a per-process setting, but it's inherited by child
processes, so it would suffice to set in the parent shell process.  However
I think that perhaps the best way to implement it might be to provide
another $CYGWIN option that controls the default error mode of all processes
launched under cygwin; the env var could be read and the call to
SetErrorMode made in the dll entry point at the time it gets the process
attach notification.

  Unless anyone has a better idea for how this functionality could be
exposed to the cygwin user?


and in another post,

> -----Original Message-----
> From: cygwin-owner On Behalf Of Robert Collins
> Sent: 30 March 2004 02:10
> On Tue, 2004-03-30 at 10:56, Edward S. Peschko wrote:
> > On Fri, Mar 26, 2004 at 10:12:05AM +0100, Corinna Vinschen wrote:

> > yes, I realize that it is a problem with my environment - what I'm 
> > suggesting is that no popups be created in response to the problem. 
> > That a text error is generated.  This would vastly increase the 
> > robustness of the cygwin environment
> > - I simply cannot afford to have an interactive error come 
> up during a 
> > batch process, and hang there. It is not a question of 
> specifics, its 
> > a question of how to deal with a generic problem.
> 
> Fix windows then. I'm sure MS will take a bug report happily.
> 
> Rob
> 
> P.S. I'm only being slightly facetious. This really is 
> outside of cygwin's purview. The only thing I can think of 
> that might help is to write a replace handler for these style 
> of errors. And I don't know if theres even a hook to do that.

  I don't think it's entirely out of Cygwin's purview; it's an architecture
dependent behaviour which it's entirely reasonable to say that cygwin should
expose an interface to.  After all, cygwin goes to all the trouble of
dealing with dos-style paths and windoze-specific device names; there's no
reason why it shouldn't consider windoze default error handling to be an
issue it has to deal with too.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/