Subject: RE: new user to cygwin32...
From: [email-masked] (Colin Peters)

5 Mar 1997 02:05:26 -0800
Approved: [email-masked]
Distribution: cygnus
Message-ID: <01BC2985.95AD8F20.cygnus.gnu-win32@gbird0>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Original-To: "'GNU-Win32'" <[email-masked]>
Original-Sender: [email-masked]

Jonathan Lanier[SMTP:[email-masked]] 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.

[snip]
>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".

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 
[snip]
>; 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...

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

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

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

-- Colin Peters - [email-masked]
-- Saga University Dept. of Information Science
-- http://www.fu.is.saga-u.ac.jp/~colin/index.html
-- http://www.geocities.com/Tokyo/Towers/6162/

-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".