From: pgarceau AT teleport DOT com (Paul Garceau) Subject: Re: DirectX and mingw.. 26 Apr 1998 19:37:31 -0700 Message-ID: <199804262056.NAA06997.cygnus.gnu-win32@mail1.teleport.com> References: <3 DOT 0 DOT 3 DOT 32 DOT 19980426115941 DOT 00862350 AT mail DOT labyrinth DOT net DOT au> Reply-To: pgarceau AT teleport DOT com To: gnu-win32 AT cygnus DOT com Greetings, First some clarification...when I refer to mingw32 within the context of this email, unless otherwise noted, I am referring to the bare bones minimum mingw32 header upgrade that, under Cygwin32 b18, copied the Cygwin32 Win32 headers to the Mingw32 directory. The compiler used was the Cygwin32 compiler/linker combination...not a minimalist package. On 26 Apr 98 at 11:59, the Illustrious Factory wrote: > At 20:27 24/04/98 -0800, wrote: > > Problem is that the Directx available from the URL you referenced is set > >up for Cygwin32 b17 or b18 and doesn't link without Cygwin32.dll being > >somewhere on the path. > Erm I'm assuming you are referring to run-time linking as oppsed to > compile-time linking, which works fine. Well, it ran fine for me in both cases (under WinNT 4.0/Cygwin32 b18 using bare bones Mingw32-headers)...problem is that later, someone else with Win95 (I am assuming) attempted to use the directX stuff and couldn't get it to work at all. And of course, there was the problem you mentioned about the unnamed unions that came up when compiling for C++. I remember mentioning it here sometime before b19 was released. > > > Fortunately, the header files included for ddraw.h do work under > >Cygwin32. Unfortunately, you have to replace your ddraw.dll file on > >your computer with the ddraw.dll included as part of the DirectX > >stuff you downloaded. > > Erm the stuff I downloaded doesn't have a new .dll, only a .h file and > a > library file (libddraw.a). This is good to know. The same package used to come with a .dll, ddraw.def, ddraw.h and I believe, sample C source code. No lib files at all. If Rocky is watching, I am sure he would correct me...and I would be glad for it. > > > Fortunately, this is rather simple. Unfortunately, in order to get > >Mingw32 to work with the ddraw.h stuff, you must configure your system to > >support switching between Cygwin32 and Mingw32 and set your development > >environment to default to the cygwin32 gcc for all of your DirectX compile > >needs thus negating any positive effect you may have received by > >installing and using Mingw32. > Agreed, this is a Bad Thing (tm). :) > To clarify... > >Mingw32 and Cygwin32, out-of-the-box, do not as you proabably > >already know, support DirectX in any form. Here I was referencing Mingw32-gcc...not egcs. These are two different development environments. As far as I know, egcs is _not_ a minimalist package, though it can compile and link minimalist source. > Yes, and DirectX doesn't seem to support anything other than VC.. funny > that. Indeed...it has been a bane in my attempts at porting certain C++ source code that I need to port for WinNT 4.0. The actual facts, as I understand them are as follows: The MS Platform SDK (DirectX portion) is capable of being compiled and linked as C++ for _as long as you use one of the popular commercial compilers_ (MS/Borland/Watcom). If you do _not_ purchase MS/Borland/Watcom, then you _can not_ generate any DirectX based C++ code...even though MS says "a standard 32bit compiler" in their documentation. DJGPP (or course) does not support DirectX and supplements any graphics routines with custom graphics packages such as GFX and Allegro. Fact, Borland and Watcom have both paid MS gobs of money (in licensing fees, royalties, etc.) to continue to produce compatible compilers (both C and C++). > Mingw apparantly doesn't have much of a problem with the .h files from > directx, only a few of the unnamed unions need to be changed. Going by > what someone else has said here. Agreed...but without an indepth understanding of header formatting, you may as well forget it...The 'unnamed unions' referenced can not be modified, afaik, without manually going through and changing...for every DirectX API related header file that you wish to use, all of the "unnamed unions" mentioned. In effect, you must rewrite every single Win32 header file that comes with GCC before those MS .h files with "unnamed unions" will even be understood by GCC or any variation thereof, with few exceptions. As noted before, if you've got time to burn on converting MS headers for Gcc compatibility...I wish you the best. > > > Another possibility is that you could use a separate development > >environment for your C and C++ programs. I only suggest this because > >there is a non-Gnu C compiler that actually did convert all of the MS > >header files that it came with into something understandable by a non-Gnu > >compiler. Whether those files (libs and obj) may be properly linked > >via "ld" or any version of the Gnu linker remains to be seen. > > It is also rumored that the aforementioned non-Gnu compiler can actually > >convert all of the most recent MS Platform SDK headers into something that > >can be read by the aforementioned non-Gnu compiler. > Hmm I'm assuming that the rumours are about lcc :), but I really am a > bit > of C++ junkie.. :) You got it...lcc-win32 is a fine piece of work...almost artistic once you have an understanding of it. The problem, however, remains; lcc-win32 is not g++ compatible since it uses .lib files as opposed to .a files and is limited to C only. To make lcc-win32 C++ compatible, you must first be able to generate and link C object code from both lcc-win32 and gcc. Once that is accomplished, the next step is to seperately compile all of your C++ source via G++, generating only .obj code. Once you get the g++ .obj files and the lcc-win32 .obj files separately generated, "lcclnk", afaik, should (not tested by me yet) be able to link the two object types. [Jacob, are you listening/watching? You know I am happy to be corrected...so please, correct me if I am wrong..] > And that would be only useful if I actually had the SDK, which would > require sending dollars to MS, since they have decided that letting ppl > download the sdk off their site is not cost effective.. hmm... This seems strange...have you tried directly accessing the MS SDK via http://www.microsoft.com/msdn/sdk ? Of course, I am in the US so I haven't had any problems with that. You might want to give it a try... > > Incidentally someone else mailed me about the problem and he believes > the > problem is similar to a loader bug in egcs, hmm guess I'll have to wait > for b19 ported, it might fix my problem. Hmm...this is news...you aren't using mingw32-gcc? I guess I needed to be more specific...I am using mingw32-gcc, not egcs. Peace, Paul G. Information Systems Consultant NewDawn Productions http://www.teleport.com/~pgarceau/newdawn/ - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".