This is the mail archive of the
mailing list for the Cygwin project.
RE: new user to cygwin32...
- To: "'GNU-Win32'" <gnu-win32 at cygnus dot com>
- Subject: RE: new user to cygwin32...
- From: Colin Peters <colin at bird dot fu dot is dot saga-u dot ac dot jp>
- Date: Wed, 5 Mar 1997 16:52:16 +0900
Jonathan Lanier[SMTP:firstname.lastname@example.org] wrote:
>> 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...)
I think I already said something on this topic (maybe in another thread) and
I basically agree with Mr. Lanier: if you have VC++ then use it unless you
have a compelling financial reason or intellectual curiosity (or maybe some
kind of mental illness) that forces you to use gcc. Still, I wanted to add
a few points.
>overhead of cygwin32. Using the mingw32 stuff lets you basically turn GNU
>Win32 into a native Windows compiler. You can get it from
Just a little point but the URL has changed slightly (you'll get a
redirecting page if you go to the above). You can get the Mingw32 downloads
and info from either of the following two URLs:
http://www.fu.is.saga-u.ac.jp/~colin/gcc.html (in Japan)
http://www.geocities.com/Tokyo/Towers/6162/gcc.html (in the USA)
Be careful if you're using Netscape on Win32 to avoid downloading with the
"Save Link As" feature, because it corrupts .tar.gz files. I think it's ok
from Japan. Also I think it's ok if you simply click on the link.
>* 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".
I don't like the weird windows.h + Windows32 directory structure that
win32api-0.1.2 used (and was inherited by Cygwin32 and thus Mingw32)
very much actually. The original decision was Scott Christley's. Currently
Cygwin32 uses a bunch of stub files in place of the normal windows
include files which just include windows.h. Of course this occasionally
leads to trouble (as well as being inefficient in a lot of cases).
Mixing with other libraries (e.g. DirectX) is probably an exercise in
teeth-pulling-like pleasure (though it would be really cool if you
could eventually get it working).
>* 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
>; 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
Well, it's not quite *that* bad. Yes there is a bug and it is annoying
but the vast majority of Win32 API functions do not return pointers and
are not affected by this problem. In my experience there were a couple
of API functions in UnicodeFunctions.h and maybe a dozen in Sockets.h
to change. Also I just moved the WINAPI define in front of the return
type declaration. This may or may not be correct, but it seemed to
work way back when I tested it once.
>* 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++,
>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.
I'd say if you want to use MFC with gcc you are asking for a world of
hurt. It is probably not worth the trouble. There are a few other
application frameworks out there, and I think some of them are even
>I haven't tried them, but Petzold's Win95 tutorial apps should work just
>fine with this setup.
I think you might also have trouble with resource compilers. The best one
to use for Petzold is probably lrc from the lcc distribution (there's a
pointer on my web pages).
-- Colin Peters - email@example.com
-- Saga University Dept. of Information Science
For help on using this list, send a message to
"firstname.lastname@example.org" with one line of text: "help".