Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sources.redhat.com
Message-ID: <004d01c0e669$152d0380$6800a8c0@dbca950>
From: "Dave Cook" <dcook@caveduck.com>
To: <cygwin-xfree@cygwin.com>, <cygwin@cygwin.com>
References: <002501c0e662$0ed24a60$6800a8c0@dbca950> <016b01c0e662$415f9320$0200a8c0@lifelesswks> <003d01c0e665$9e71aff0$6800a8c0@dbca950> <20010527003757.A12171@redhat.com>
Subject: Re: bluescreen during XF86/cygwin build
Date: Sat, 26 May 2001 21:54:16 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Chris Faylor wrote:
> >I realize that cygwin doesn't install any actual drivers, but it pushes
> >the filesystem in ways that W2K may not expect :)
>
> No, it doesn't actually.  It just uses standard Win32 API calls.
>
> With an OS like W2K there is really no way that Cygwin should be able to
> cause a blue screen.  If it does, it's an OS bug, not a Cygwin bug.

You can't necessarily just tell the customer "it's Microsoft's problem".  I'm a veteran of
those wars...we did an NT server product a couple of years back that ran into a Win32 call
that leaked ~1KB of nonpaged memory every time you used it in a certain perfectly legal
way.  Not harmful for normal apps, but fatal for a server that wanted to run for weeks.
From a customer centric view, if I can run command X on a normally configured Linux box
and it works, but the same supposedly supported command fails in Cygwin, then it's a
Cygwin problem (though perhaps technically not a Cygwin bug).

I'll shut up now :)

Regards,

Dave


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple