Subject: Re: DirectX and mingw..
From: [email-masked] (Factory)

25 Apr 1998 23:42:43 -0700
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [email-masked]

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.

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

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

>	Mingw32 and Cygwin32, out-of-the-box,  do not as you proabably already 
>know, support DirectX in any form.
  Yes, and DirectX doesn't seem to support anything other than VC.. funny
that.

>	I suppose that if you were ambitious enough and had an abundance of time 
>on your hands, you _could_ probably convert every single DirectX (ver 5 or 
>lower) API related header to something that Mingw32 could understand and 
>use.
  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.

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

  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.
- Factory (.sig under reconstruction)
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".