RE: new user to cygwin32...

RE: new user to cygwin32...

[Colin Peters]

Jonathan Lanier[SMTP:jonathan@westwood.com] 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 - colin@bird.fu.is.saga-u.ac.jp
-- 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
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: new user to cygwin32...

[Jonathan Lanier]

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

RE: new user to cygwin32...

[Colin Peters]

Peter Amstutz[SMTP:amstpi@freenet.tlh.fl.us] 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...)

With either the Cygwin API or Mingw32 you should be able to do straight
Windows programming. I believe you might have less trouble with the Petzold
examples if you use Mingw32, but either one can be used for your own
coding.

There are some typos and missing macros in the Win32 API headers which will
cause you trouble with the Programming Windows 95 examples. Implementing
the fixes mentioned on my problem page ( http://www.geocities.com/Tokyo
/Towers/6162/gcc-problems.html) might help a little. You're also going to
have trouble with resource compilers I think. The resource compiler lrc 
from lcc ( http://www.remcomp.com/lcc-win32 ) might be your best bet, or
you might consider using lcc itself (since it's also free and a lot less
of a disk/processor hog) for all your programming.

Colin.

-- Colin Peters - colin@bird.fu.is.saga-u.ac.jp
-- 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
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: new user to cygwin32...

[Weiqi Gao]

Peter Amstutz 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...)
>
>Also, it seems that the standard set of cygwin32 header files are missing
>the SND_* macros...

If you are already familiar with the GNU C/C++ environment, then go ahead
and use cygwin32.  Otherwise use Microsoft Visual C++.  Cygwin32 should be
able to compile all the examples of the book, but figuring out how is going
to be a challenge, as documentations of the tools are at best sketchy.

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

new user to cygwin32...

[Peter Amstutz]

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

thanx,
******************* The one and only *****************
******************** Peter Amstutz *******************
***** All around computer whiz kid and nice guy. *****
************** amstpi@freenet.tlh.fl.us **************
************** <Tetron Vortex> has spoken! ***********

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