Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Thu, 3 Apr 2003 16:37:26 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Big Brother is Real
Message-ID: <20030403213726.GC18494@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <BF653A78FF4ED0468924C8721AC5EAE7026D2C82 AT df-muttley DOT dogfood>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BF653A78FF4ED0468924C8721AC5EAE7026D2C82@df-muttley.dogfood>
User-Agent: Mutt/1.4i

On Thu, Apr 03, 2003 at 10:37:19AM -0800, Stephan Mueller wrote:
>Can someone elaborate on exactly which APIs have changed incompatibly
>(in 64-bit Windows)?
>
>I'm only mildly familiar with the 64-bit story, but my understanding is
>that the the 64-bit APIs are basically the same as 32-bit (with the
>natural widening of types) but given that the 64-bit API is 'new' in
>that there's no legacy (shipped, binary) code base to support, this is
>probably the best time to make API changes (in 64-bit) that repair bad
>design decisions and bad interface bugs and so made earlier (in 32-bit
>API, or maybe even 16-bit).
>
>Regardless, how does this affect Cygwin at all?  The 32-bit subsystem on
>64-bit Windows OSes should run 32-bit apps with no semantic changes --
>that's its job, and I would be surprised if the behaviour of any 32-bit
>APIs was gratuitously different (although it's possible there are bugs
>-- worth reporting if that's the case).
>
>If you're trying to compile cygwin itself for 64-bit, well, you may need
>to make some cygwin source changes with #ifdefs, yes -- is that the
>objection here?

I wouldn't be surprised if some of the iffy decisions that cygwin makes
just break on the 64-bit Windows.  It's not Microsoft's fault if they
change an undocumented behavior.  Cygwin relies on a few undocumented-but-consistent
behaviors to do some of its magic.

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.

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/