RE: new to-do item

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

> -----Original Message-----
> From: Fish [mailto:fish@infidels.org]
> Sent: Tuesday, July 17, 2001 2:03 PM
> To: cygwin@cygwin.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@infidels.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/