Re: DirectX and mingw..

["Paul Garceau" <pgarceau at teleport 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@cygnus.com" with one line of text: "help".