Re: new to-do item

Re: new to-do item

[Chris Faylor]

On Sun, Dec 24, 2000 at 04:07:40PM -0500, Chuck Esterbrook wrote:
>FYI, I don't think CVS is going to do what I want. That is, translate 
>end-of-lines between a UNIX CVS server and a Windows CVS client, in the 
>same manner that FTP would.

If you use cygwin or cygwin-aware tools to do everything, then you can
and should just use binary mounts.  Relying on tools to "do the right
thing" with the CRLF line endings is asking for trouble.

>It would be nice in the future if the cygwin CVS could be configured
>(perhaps via an environment variable) for this behavior.

As you have previously noted, it is best to send these kind of
observations the cygwin mailing list.  Then the CVS maintainer can
answer your questions and respond to your suggestions.

I've Cc'ed cygwin@cygwin.com and redirected the reply-to accordingly.

cgf

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

Re: new to-do item

[Chuck Esterbrook]

At 04:41 PM 12/24/2000 -0500, Chris Faylor wrote:
>On Sun, Dec 24, 2000 at 04:07:40PM -0500, Chuck Esterbrook wrote:
> >FYI, I don't think CVS is going to do what I want. That is, translate
> >end-of-lines between a UNIX CVS server and a Windows CVS client, in the
> >same manner that FTP would.
>
>If you use cygwin or cygwin-aware tools to do everything, then you can
>and should just use binary mounts.  Relying on tools to "do the right
>thing" with the CRLF line endings is asking for trouble.

Maybe that's part of the problem. I use a non cygwin tool to edit my source 
code. I guess my 'ftp' would also be non-cygwin.

As far as "do the right thing" being trouble, that is the set up I 
previously had and I never had any trouble at all. On that basis, I'll go 
back to my "old" cvs.exe, while still using cygwin for all its other UNIX 
command line tools.


> >It would be nice in the future if the cygwin CVS could be configured
> >(perhaps via an environment variable) for this behavior.
>
>As you have previously noted, it is best to send these kind of
>observations the cygwin mailing list.  Then the CVS maintainer can
>answer your questions and respond to your suggestions.
>
>I've Cc'ed cygwin@cygwin.com and redirected the reply-to accordingly.
>
>cgf

Thanks.


-Chuck


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

Re: new to-do item

[Larry Hall (RFK Partners, Inc)]

At 12:30 PM 6/2/2002, Christopher Faylor wrote:
>Please check out the project web page for links to available information
>and ports:  http://cygwin.com/ .
>
>If you don't see what you need there, then the cygwin mailing list is
>the best place to make observations or get questions answered.
>Information on the mailing list is available at the project web page.
>
>For your convenience, I've reset the Reply-To: address to point to the
>cygwin mailing list.  I've also Cc'ed this reply there.
>
>
>On Sun, Jun 02, 2002 at 06:40:07AM -0800, Marc Gianzero wrote:
>>Chris,
>>
>>Hope you don't mind my emailing you directly, but that's all I have to go
>>with since there's no way for me to respond on the webpage.
>>
>>I don't want to "network" with another Linux box, I merely want to access my
>>Linux partitions on my SAME computer (it is dual boot).  My understanding is
>>Samba is for networking a Linux box to a Windows box, correct?

OK, I'll bite.  First, I'll say discussion of this is really off-topic for
this list.  Cygwin does not provide facilities (i.e. a driver) to access 
any file system.  It simply leverages the built-in understanding of file
systems from the underlying O/S.  From this, I think you can gather that
Cygwin will be able to access your local Linux partition if Windows can.
Now, although this is off-topic for this list, the discussion about 
available facilities which allow Windows to access your Linux partitions does
exist in the email archives for this list.  If you're curious, you can check 
this out to find the available Windows ext2 drivers and utilities.  What's 
there contains enough specifics that you should be able to find what you
need or at least find more appropriate pointers for this information.



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
838 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
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/

Re: new to-do item

[Christopher Faylor]

Please check out the project web page for links to available information
and ports:  http://cygwin.com/ .

If you don't see what you need there, then the cygwin mailing list is
the best place to make observations or get questions answered.
Information on the mailing list is available at the project web page.

For your convenience, I've reset the Reply-To: address to point to the
cygwin mailing list.  I've also Cc'ed this reply there.


On Sun, Jun 02, 2002 at 06:40:07AM -0800, Marc Gianzero wrote:
>Chris,
>
>Hope you don't mind my emailing you directly, but that's all I have to go
>with since there's no way for me to respond on the webpage.
>
>I don't want to "network" with another Linux box, I merely want to access my
>Linux partitions on my SAME computer (it is dual boot).  My understanding is
>Samba is for networking a Linux box to a Windows box, correct?
>
>Marc
>
>-----Original Message-----
>From: Christopher Faylor [mailto:cgf@redhat.com]
>Sent: Saturday, June 01, 2002 9:09 PM
>To: mgianzero@cox.net
>Cc: vinschen@redhat.com
>Subject: Re: new to-do item
>
>
>On Sun, Jun 02, 2002 at 04:54:45AM -0000, anonymous@sources.redhat.com
>wrote:
>><UNAPPROVED 1022993684>
>>mounting Linux partitions
>>2002-06-01	21:54:44	mgianzero@cox.net	Marc Gianzero	68.5.233.1
>>I am not sure if this request was already addressed in the "reparse
>>point support for symbolic links/mounting" but I would love the
>>capability to mount my linux partition (home directory) so that I may
>>access my user-created files under cygwin.  Is this a possibility?
>
>Use samba on linux - http://samba.org/ .
>
>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/

RE: new to-do item

[Julian Hall]

Michael D. Crawford wrote:

> You will have to use com to use drag and drop or the clipboard

I'd just like to point out that this isn't entirely true.  In fact, drag
and drop of files (although not of any other type of object) can be
achieved using the DragAcceptFiles() API and the WM_DROPFILES messages.
Also, the clipboard can be accessed using EnumClipboardFormats() and
GetClipboardData().  You can't however do OLE without COM, but DDE is
certainly possible (DDE predates the introduction of COM along with OLE
in Windows 3.1).




--
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/

RE: new to-do item

[Robert Collins]

> -----Original Message-----
> From: Fish [ mailto:fish@infidels.org ]
> Sent: Tuesday, July 17, 2001 2:49 PM
> To: cygwin@cygwin.com
> Subject: RE: new to-do item
> 
> > 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.
> 
> I think I now see the source of my original confusion. Cygwin 
> DLL code must
> obviously make certain Win32 API calls (in order to emulate 
> the *ix environment)
> and purely as a side effect of that, it allows one to write 
> code that makes the
> same API calls.

Nope. Wrong again.

Some terms - 
the cygwin dll - a dll that exposes a subset of the common unix API
calls.
Cygwin-the-distribution - a compiler,linker,many utilities and the
cygwin dll
 
> But the ability to have one's code be able to make Win32 API 
> calls isn't
> supported per se. It's simply one of the side effects. Is 
> that correct?

Nope. They are orthogonal. You make win32 API calls by linking against a
win32 API exposing dll - say msvcrt.dll or kernel32.dll. That is how you
make those calls _WHETHER OR NOT_ you link against cygwin1.dll.
 
> Thus, as you have now sufficiently explained, my original 
> request to include the
> ability to make a given Win32 API call was inappropriate for 
> the Cygwin DLL TODO
> list. I understand that now.

It's inappropriate for the cygwin dll TODO because it's an orthogonal
issue. It's like reporting a bug with vim on the TODO.

It is _entirely_ appropriate to discuss the missing export for the
open-source w32api package :]
 
Rob

--
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/

Re: new to-do item

[Christopher Faylor]

On Tue, Jul 17, 2001 at 12:43:34AM -0400, Greg Smith wrote:
>Christopher Faylor wrote:
>>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.
>
>Hello Chris,
>
>I think we've discussed this before.  The product is an IBM mainframe
>hardware emulator and is released under the QPL license.  The web-page,
>with the license, is at http://www.conmicro.cx/hercules ...
>Unfortunately, seems the cx (Christmas Island) ISP has gone bankrupt,
>and the dns entries may be screwed...  And next Monday is a big
>convention where the product will be highlighted.  You can try
> http://209.44.245.146

Oops.  That's right.  Forgot that this had been discussed.  Sorry.

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/

RE: new to-do item

[Fish]

> 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.

10-4.

<snip>

> 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?

Well, not quiiite......  >;->

<wiggles eyebrows mischievously as Chris begins having heart palpitations>

(ahem)  We've *already* produced an open source product.  >;-)

> If so, I applaud your efforts.

Thanks.

But I can't take credit for it.

I'm only one of many developers, and only became a part of the team just
recently (about a year ago?)

> If not, hmm... you've got problems, I think.

Relax. It's open source. :)

<snip>

> 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.

Understood!  (*Now* anyway.)  Sorry for the confusion.

> 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.

I think I now see the source of my original confusion. Cygwin DLL code must
obviously make certain Win32 API calls (in order to emulate the *ix environment)
and purely as a side effect of that, it allows one to write code that makes the
same API calls.

But the ability to have one's code be able to make Win32 API calls isn't
supported per se. It's simply one of the side effects. Is that correct?

Thus, as you have now sufficiently explained, my original request to include the
ability to make a given Win32 API call was inappropriate for the Cygwin DLL TODO
list. I understand that now.

Sorry, Chris. I'll stop bothering you now.

--
"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/

Re: new to-do item

[Greg Smith]

Christopher Faylor wrote:
> 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.

Hello Chris,

I think we've discussed this before.  The product is an IBM mainframe
hardware emulator and is released under the QPL license.  The web-page,
with the license, is at http://www.conmicro.cx/hercules ... Unfortunately,
seems the cx (Christmas Island) ISP has gone bankrupt, and the dns entries
may be screwed... And next Monday is a big convention where the product
will be highlighted.  You can try http://209.44.245.146 

Best regards,

Greg Smith

--
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/

RE: new to-do item

[Michael D. Crawford]

You can do Win32 programming under CygWin.  I've been using CygWin to make
purely Win32 applications for a couple of weeks.  I don't see a problem with
mixing the Unix and Win32 apis, so long as you don't try to do one sort of thing
in two ways - for example, using CygWin stdio mixed with Win32
ReadFile/WriteFile would corrupt your I/O stream.

Here's the faq about it:

http://www.cygwin.com/faq/faq_4.html#SEC85

If you just want to use CygWin as a Win32 development system, you can even avoid
linking against CygWin.dll altogether.  Read the other FAQs in the neighborhood
of the above for info on how to do such things.

HOWEVER.

The Win32 header files that are provided in the /usr/include/w32api directory
are independently developed from the Visual C++ header files, as Microsoft's
license does not allow free redistribution of their proprietary header files.  I
guess the ones that are there were written from the published specification of
the Win32 api as well as observed behavior of existing c and c++ code meant to
work on Windows.

My experience though, is that the header files are not completely compatible
with Visual C++ or Metrowerks CodeWarrior for Windows header files.  To get your
code to compile, you will need to include a different set of headers to get some
code to compile.

It is helpful to write a header for your sourcebase that identifies both the
platform the code is being compiled for and the compiler in use, and set some
handy preprocessor symbol that lets you make conditional choices of the header
files if you're using GCC for Windows as opposed to Visual C++ for Windows, or
compiling for Win32 as opposed to POSIX.

I haven't experienced a problem yet, but the linking libraries used to make your
code work on Win32 may be incomplete or built wrong.  If that's the case, that's
a bug.  When your application is actually run, the DLL's that it will use will
be the ones supplied by Microsoft for your user's Windows installation.  It's
just that the library you link with was developed by the CygWin folks, again
like the headers to allow their redistribution.

(When you use a DLL on Windows, there are two libraries involved, one your
application links against that basically just declares a bunch of entry points,
and the one actually used at runtime that has the actual code in it).

A further unpleasant complication is that if you want to use COM, you have to
give the, I think it is, -fvtable-thunks option on the command line.  This is
unpleasant because it will require your application to be linked with a runtime
library that is also built this way because it changes the ABI of your code. 
You will have to use com to use drag and drop or the clipboard.  I ran into this
over the weekend and ended up downloading the GCC/CygWin source code so I could
make a runtime library to use when linking ZooLib applications, although I
haven't built it yet.

Regards,

Mike
-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com
crawford@goingware.com

  Tilting at Windmills for a Better Tomorrow.

--
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/

Re: new to-do item

[Christopher Faylor]

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/

RE: new to-do item

[Robert Collins]

> -----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/

RE: new to-do item

[Fish]

> >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?

> >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.

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.

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?

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/

Re: new to-do item

[Christopher Faylor]

[This email is the result of a rejected to-do list entry which asked
for a new windows function]

On Mon, Jul 16, 2001 at 08:15:28PM -0700, Fish wrote:
>Then please explain why, when I compile the following test program within the
>cygwin shell environment:
>
>============
>#include <windows.h>
>
>CRITICAL_SECTION  cs;
>
>int main (int argc, char *argv[])
>{
>	InitializeCriticalSection(&cs);
>	InitializeCriticalSectionAndSpinCount(&cs,4000);
>
>	return 0;
>}
>============
>
>I get the following error:
>
>============
>gcc -I/usr/Pthreads -Wall -fomit-frame-pointer -DNO_ATTR_REGPARM -DNO_IEEE_SUPPO
>RT -DWIN32 -D__LITTLE_ENDIAN=1234 -D__BYTE_ORDER=1234 -DNO_BYTESWAP_H -O3 -malig
>n-double -march=pentium -DCCKD_BZIP2 -DHET_BZIP2 -o fishtest.o -c fishtest.c
>
>fishtest.c: In function `main':
>fishtest.c:8: warning: implicit declaration of function
>`InitializeCriticalSectionAndSpinCount'
>
>gcc -I/usr/Pthreads -o fishtest
>fishtest.o -L/usr/DLL -lpthreadw32 -lz -lbz2 -XLinker --cref -Xlinker -Map -Xlin
>ker fishtest.map
>
>fishtest.o(.text+0x23):fishtest.c: undefined reference to
>`InitializeCriticalSectionAndSpinCount'
>
>collect2: ld returned 1 exit status
>make: *** [fishtest] Error 1
>============
>
>
>Is this not a cygwin dll issue?

No.  The Cygwin DLL emulates *UNIX*, not Windows.  We don't add Windows
system calls to the Cygwin DLL.

>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

--
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/