Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: new to-do item X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Tue, 17 Jul 2001 14:04:59 +1000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new to-do item Thread-Index: AcEOdEhzHtbAL2s7TE+gRPl9odUtbAAAA+GA From: "Robert Collins" To: "Fish" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id AAA03040 > -----Original Message----- > From: Fish [mailto:fish AT infidels DOT org] > Sent: Tuesday, July 17, 2001 2:03 PM > To: cygwin AT cygwin DOT com > Subject: RE: new to-do item > > > > >Is this not a cygwin dll issue? > > > > No. The Cygwin DLL emulates *UNIX*, not Windows. > > Hmmm... Yes, I suppose you're right in that regard. I certainly hope Chris is right! > > We don't add Windows system calls to the Cygwin DLL. > > So what you're basically saying then is one can *only* use > Cygwin to develop > UNIX programs that should also be able to run on Windows > platforms as well, BUT, > even though these programs just so happen to be able to be > run under Windows, > they are not allowed to make use of *any* Windows API calls > whatsoever anywhere > in their code?? Is that correct? No. It wasn't implied either. You can link to windows .dll's and use windows API calls, but you need appropriate headers and import libraries. Along with cygwin, but not part of cygwin (like vim comes with cygwin but isn't part of it) you get a fairly complete set of windows hears and import libraries. > > >If it's not, then *WHO'S* issue is it?? > > > > It's either a header file or import library issue. > > > > I've cc'ed this email to the cygwin mailing list. Perhaps > > someone will be willing to research what needs to be > > done to add this missing function or macro. > > > > cgf > > Thanks. The development team of which I'm a part of (as is > Greg Smith too) has > been for the most part successful so far in developing a > product that, with > cygwin's help, runs as easily on Windows as it does on > Linux/Unix (*ix) > platforms. Unfortunately, however, it doesn't perform as well > under Windows as > it does under *ix. We attribute this poor performance for the > most part to the > cygwin code. Thanks :]. Seriously, cygwin *can* be optimised and made better. We are all volunteers however, and time constraints affect us all. Also profiling cygwin isn't easy, so it can be difficult to identify the performance bottleneck causing issues. However it's in *all* our interests to improve cygwin in preference to multiple software writers creating similar work-arounds. So for instance if you want to use critical sections in preference to win32 mutex's for syncronisation, we can (and I have on my todo list to do) use critical sections in prefernece to win32 mutexs for non-cross-process emulated unix mutex's. > We fully understand, of course, that emulating an *ix > environment on Windows is > no easy task, and applaud the cygwin people for doing as good > a job as they have > in accomplishing that end. > > But in order to reach the desired performance level under > Windows (*without* > having to rewrite it completely in native Win32 form), we > would like to > introduce on an as-needed basis certain Win32-specific logic > in a few places. > From what you're telling me, cygwin doesn't allow (support) that. Again, Chris didn't imply that. He stated the cygwin dll doesn't do that - not that the compiler and "cygwin-the-platform" doesn't. Cygwin _uses_ win32 code to do what it does however. > If we are unable to do that (i.e. make native Win32 API calls > wherever we feel > it's necessary) using the cygwin development environment, > then forgive me but > I'm at a total loss as to how to accomplish our desired goal > (short of rewriting > it completely in native Win32 using Microsnot's own tools; > i.e. developing a > custom "Win32-ONLY" version). > > Is there *any* way, using cygwin, to make calls to Win32 APIs? Yes. Do what you did - that particular call isn't in the win32 import library - so that particular package will need a patch generated to include the approprirate definition. I suspect the missing call is a windows 2000 only call - which certainly wouldn't be appropriate for a product that you want usable anywhere Win32 is available. > Thanks. > > (If there's a more appropriate email list or news group for > such questions, > please let me know. I know you're a busy man and I don't wish > to take up your > time if you're not the right person to be talking to > regarding this issue.) > > Sincerely, > -- > "Fish" (David B. Trout) > fish AT infidels DOT org > > > -- > 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/ > > -- 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/