Re: new user to cygwin32...

[Jonathan Lanier <jonathan at westwood dot com>]

> Hello all.  I just recently downloaded & installed the full distribution of
> cygwin32 (all 40 megs of it!) with the intent of learning something about
> windows programming.  From what I have seen, this library is largly intened
> for porting unix/gnu software to a windows environment, but how suitable is
> it for straight windows programming?  I bought the book Programming Windows
> 95 (by Charles Petzold) and the examples are designed to work with MS Visual
> C++.  Are there any particular things I should watch out for in compiling
> the VC++ programs under gcc?  (other than re-writing all the makefiles...)
> 
> Also, it seems that the standard set of cygwin32 header files are missing
> the SND_* macros...

My 2 cents (since I'm using both GNU Win32 and VC++, and am in the 
process of porting a heavy C++ multimedia program to GNU Win32):

If you just want to learn Windows programming, and you already bought the 
VC++ compiler, then until you become more familiar with Windows 
programming, I would stick with VC++ unless you are a masochist.  You'll 
have a much nicer, friendlier debugger (which you'll need) and a host of 
other tools, such as the heapwalk tool, the spy utility, a resource 
compiler and editor, and a bunch of other nifty Windows GUI-related tools 
that you don't get with GNU, although if you own them they will work with 
GNU.

If you are trying to use GNU because it's free, or because the idea of 
using a beta version of a compiler originally written for a UNIX as 
a Windows compiler, or the idea of using a C++ compiler that you are able to 
hack on or have access to the source code of excites and fascinates you, 
then you won't be disappointed with the GNU compiler. I suggest that for 
doing native windows programming, try using the minimalist GNU Win32 
headers.  That way you can build native Win32 apps that don't need the 
overhead of cygwin32. Using the mingw32 stuff lets you basically turn GNU 
Win32 into a native Windows compiler.  You can get it from 
"http://www.fu.is.saga-u.ac.jp/~colin/mingw32.html".

Here are the problems I've had doing Win32 native programming with GNU Win32:

* You can't use MS header files, and GNU can't distribute them for 
legalese reasons.  So, the mingw32 is an attempt to reverse-engineer the 
missing header files.  This sounds great, except for all these problems...

* These header files are a work in progress, just provided as-is by some 
dude (like you and I) free of charge.  Let the user beware.  I will tell 
you, they are not yet complete; although for doing native Win32 stuff 
(like samples in Petzold's book) it would be much better than Cygnus's 
headers, which are geared towards Unix compatibility.

* His header files use a slightly different naming convention (why, I 
don't know, you'll have to ask him) so you might need to change some of 
the #include statements.  He seems to assume that nobody would ever 
#inlcude anything but "windows.h".

* Because they use a different naming convention you will not have much 
luck mixing with other libraries, like DirectX, WinSock 2, etc; that 
assume certain #defines are set, or unset, or that they can #include 
other files, like winsock.h, etc.

* There is a BUG in the C++ version of the GNU Win32 compiler, that 
prevents the __attribute__ (()) directive from working when compiling in 
C++ if it comes before a function prototype that returns a pointer of any 
kind.  In this case for now you have to put it at the end.  The problem 
is, all the windows API funcs (even in the mingw32 stuff) all use 
#defines for return types like 'WINAPI' that include the __stdcall 
attribute (which is handled in GNU Win32 with __attribute__ (( stdcall ))...)
; so NONE of the header files work right now for doing C++, because 
WINAPI is the *return type*, so you have to edit every single prototype 
for every single API function to add the directive at the end, and remove 
it from the WINAPI #define, because if you remove it from the WINAPI 
#define the other, non-pointer-returning functions will be missing their 
attribute...
NOTE that this bug doesn't seem to affect C code, only code run through 
the C++ compiler; so if you're only going to do C, it's a non-issue.

* Since MFC is C++, to do VC++/MFC style programming, you'd have to
a) get a hold of the MFC include files, legally, from your own copy of VC++, 
and
b) hack them to be parseable by the buggy GNU compiler.  This is very 
annoying and I hope it gets fixed soon...  I myself have been hacking the 
files and it is a big pain; I still don't have everything working right 
and I've been messing with this for awhile.

* There is a BUG/MISFEATURE in GNU Win32.  You can't seem to apply the 
stdcall attribute (or any other one) to a virtual function in a class.  
This means that all the class library stuff for DDE/MFC/DirectX/ActiveX/etc. 
has to be done using #define CINTERFACE, which basically really takes out 
all of the fun of using a C++ compiler...

Having said the above, I HAVE built native Win32 apps with the mingw32 
stuff, and it's really cool...  If you opt for using CRTDLL as is 
suggested, your executables will be really small, and fairly fast.  You 
can get a resource compiler as well (check the web site for info), or use 
one of the ones that came with your other compilers, if you have them.  
You should easily be able to compile almost any non-MFC, non-DDE, and 
non-multimedia app with no problem (i.e., a straight Win32 console or 
regular GUI app).  Some of the DDE stuff is in the mingw32 headers, but 
it's not quite complete.  Winsock is mostly there but you have to either 
set a #define when you include windows.h, or #include 
<Windows32/Sockets.h> instead of the usual #include <winsock.h>.

I haven't tried them, but Petzold's Win95 tutorial apps should work just 
fine with this setup.

If anyone has any other comments, feel free to jump in...

- Jonathan Lanier
  jonathan@westwood.com

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".