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 Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-MimeOLE: Produced By Microsoft Exchange V6.5.6910.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RE: Big Brother is Real Date: Thu, 3 Apr 2003 16:12:24 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Stephan Mueller" To: "Timothy C Prince" Cc: X-OriginalArrivalTime: 04 Apr 2003 00:12:24.0516 (UTC) FILETIME=[DE5A2040:01C2FA3E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id h340Cq232162 Speaking only for myself, and not my employer (because I don't know what he thinks) I can only say that from everyone I've met, and everything I do know, it appears to me that API changes are always made with backwards compatibility in mind, and the goal is never to break existing apps -- indeed, the efforts made to remain compatible with existing apps are astounding. stephan(); -----Original Message----- From: Timothy C Prince [mailto:tprince AT myrealbox DOT com] Sent: Thursday, April 03, 2003 12:09 PM To: Stephan Mueller Cc: cygwin AT cygwin DOT com Subject: Re: RE: Big Brother is Real -----Original Message----- From: "Stephan Mueller" To: Date: Thu, 3 Apr 2003 10:37:19 -0800 Subject: RE: Big Brother is Real 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? stephan(); -----Original Message----- From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com] On Behalf Of Igor Pechtchanski Sent: Thursday, April 03, 2003 8:31 AM To: Andrew DeFaria Cc: cygwin AT cygwin DOT com Subject: Re: Big Brother is Real On Thu, 3 Apr 2003, Andrew DeFaria wrote: > Tim Prince wrote: > > > Lack of cygwin support has impeded the market penetration of Windows > > XP64, but it seems Microsoft would rather lose out to linux and HPUX > > than let their customers run cygwin. It may be they don't understand > > how many customers depend on cygwin, which is their fault too, since > > they don't support those customers, just collect the fees and forget > > them. > > How exactly does Microsoft stop their customers from running Cygwin? > I'm curious because as you even admit "many customers depend on > cygwin" so it is demonstrable that Microsoft has no power to stop > their customers from running Cygwin. Microsoft doesn't "stop their customers from running Cygwin", it introduces API changes that are incompatible with previous versions, and thus cause programs like Cygwin to not run. Whether this is deliberate or accidental remains debatable. Igor __________________________________________________ As I understand it, cygwin requires more compatibility than Microsoft guarantees between the 32-bit subsystem of WinXP64 and the 32-bit Windows OS, or even between beta and final versions of XP64. As Igor pointed out, we have no way of knowing whether breaking cygwin is deliberate or accidental. The price tag in $$ or volunteer hours to build a 64-bit native cygwin is more than anyone has been able to scrape up, so, yes, I'm talking about the 32-bit subsystem. It was quite useful at the time when it did support cygwin, even on those machines which have since had their anchor status confirmed. As even the native linux g77 for ia64 isn't competitive with g77 on XP32, or with gcc on ia64, I don't see any interest in a g77 cross compiler, and I'm not going there. I think each IA64 compiler development effort has far exceeded its initial budget. Tim Prince -- 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/