Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Date: Thu, 3 Apr 2003 23:47:39 +0200 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Big Brother is Real Message-ID: <20030403214739.GW18138@cygbert.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20030403213726.GC18494@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030403213726.GC18494@redhat.com> User-Agent: Mutt/1.4.1i On Thu, Apr 03, 2003 at 04:37:26PM -0500, Christopher Faylor wrote: > I think the only problem is that Cygwin probably just needs to be debugged > to see what's going on. If someone wants to send me a nice 64 bit system > running WinXP 64 (or whatever it's called), I'll see what I can do. Coincidentally I was going to suggest something similar... I got a hint lately about stuff working different on 64bit. If a 32 bit application is called from a 64 bit application the stack is 0xc000 lower than if the same 32 bit application is called by another 32 bit application. E. g., the first bash is spawned from 64 bit cmd.exe, its stack is shifted 0xc000. A CreateProcess call from fork will now create a child with the stack at another location which breaks the longjmp. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin@cygwin.com Red Hat, Inc. -- 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/