Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Sun, 13 Jan 2002 11:53:33 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Windows XP and cygwin's heap Message-ID: <20020113165333.GD1957@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20020113042458 DOT GA26974 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23.1i On Sun, Jan 13, 2002 at 05:52:15AM -0500, Laurence F. Wood wrote: >What approach is being used in 1.3.7 or what module is responsible for this >in the cygwin1.dll? We use DLLs quite a bit and have experimented with a >variety of mechanisms to detect similar forms of DLL conflict. A small >amount of shared memory DLL intercommunication might work very nicely, >although the trick of course is detecting the really old stuff out their >that people include with their applications. I've seen a lot of open source >computational chemistry software that includes the cygwin1.dll. What is >your architectural approach to this right now? The error message function for the multiple cygwin problem is "multiple_cygwin_problem". It's in the file dcrt0.cc. Tracing back from that should show you what is happening. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/