From: colin AT bird DOT fu DOT is DOT saga-u DOT ac DOT jp (Colin Peters) Subject: RE: new user to cygwin32... 5 Mar 1997 02:05:26 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com 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'" Original-Sender: owner-gnu-win32 AT cygnus DOT com Jonathan Lanier[SMTP:jonathan AT westwood DOT 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 AT bird DOT fu DOT is DOT saga-u DOT ac DOT 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 AT cygnus DOT com" with one line of text: "help".