RE: new to-do item

["Michael D. Crawford" <crawford at goingware dot com>]

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/