Mail Archives: cygwin/2001/07/17/00:26:54
On Mon, Jul 16, 2001 at 09:03:20PM -0700, Fish wrote:
>>>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.
>
>>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?
What I am saying is that if you add a to-do list entry which has
nothing to do with the Cygwin DLL, it will be rejected.
>>>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.
>
>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.
I'm wondering how you are going to release this product given cygwin's
requirement that you must open source your product when it is released.
Are you going to be producing an open source product? If so, I applaud
your efforts. If not, hmm... you've got problems, I think.
>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.
I'm saying no such thing. I am only correcting your erroneous use of
the Cygwin to-do list. Why do you think I redirected your email to the
cygwin mailing list if it wasn't possible to do what you wanted? It
would be off-topic here if that was the case.
As I said, this is a missing header file or import library issue. The
header files and libraries come with the cygwin distribution but they
are not related to the Cygwin DLL.
>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?
Of course. You demonstrated the possibility in your test case.
>(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.)
I redirected your request to the cygwin mailing list. Why would I
redirect it to a less-than-appropriate forum?
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/
- Raw text -