DirectX and mingw..

Wed Apr 29 01:51:00 GMT 1998

Hi folks,

	Was glad to see this come through the email today...

On 28 Apr 98 at 12:27, the Illustrious Factory wrote:

> At 13:57 26/04/98 -0800, you wrote:
> >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.
> 
>   Hmm well I am using the mingw version from
> ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/

	Ok...that's EGCS...not Mingw32-gcc.

	Mingw32-gcc is a compiler based on release 2.8.x of the Gnu G/G++ 
compiler typically available from places such as Simtel.  It includes 
several modified tools, not limited to the actual compiler and linker that 
are included with Mingw32-gcc from:

	http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32/download.html

	EGCS has recently been upgraded to handle the Mingw32-header based 
compiles, links, etc. as far as I know.  EGCS is also based on Cygwin32, a 
non-minimalist Gnu-Win32 development environment.

> 
> >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.
> 
>   Hmm I thought egcs and gcc are the compilers for the (minimalist)
>   mingw32
> and the (non-minimalist) cygwin32..?

	You're right...EGCS, though, due to the fact that it can handle Cygwin32 
(UWIN) compiles/links is not considered a minimalist package.  There are 
different versions of GCC depending on which development package/toolset 
you're using.

	The Cygwin32 gcc is different than the Mingw32-gcc.  EGCS gcc is
different than either Cygwin32-gcc or Mingw32-gcc; even though EGCS is
now capable of compiling both Cygwin32 based source (UWIN) and the
Mingw32 packages (non-UWIN).  UWIN == Unix-Windows.

>   So the compiler shouldn't really matter so much, especially since the
> the l.dll problem doesn't seem to be a compiler problem at all.

	Ah, but this is where the confusion lies...since the different packages 
are using different compilers, than the outcome of a compile/link/build 
will vary from distribution to distribution when comparing EGCS, 
Mingw32-GCC/++ and Cygwin32.

	Commonalities between the three are that they all use a variation of the 
GCC compiler/linker to build executables.

	Commanalities between EGCS and Mingw32-GCC/++ are that both can use the
Mingw32-header files as provided by Colin Peters without having to convert
anything for compatibility.  The links to the original Mingw32 headers
are:

	http://www.geocities.com/Tokyo/Towers/6162/gcc.html (US Mirror Site)
	http://www.fu.is.saga-u.ac.jp/~colin/gcc.html

> >	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).
> 
>   Well afaik delphi users have to get their directx units from borland to
> use directx, MS doesn't support them either.

	This doesn't surprise me...MS doesn't support anyone who isn't paying 
them something, either in time or in energy.  This is why you have to get 
the DirectX portion of Delphi from Borland...the Borland compiler is 
suited specifically for Borland headers.

	Also, as I understand it, Borland has a utility, buried somewhere at
their corporate hq (likely under very heavy security), that converts the 
MS headers into something that the Borland compiler(s) can understand.

> 
> >	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.
>   Erm DJGPP is a dos compiler, I would be surprised if any dos
>   application
> could use the directx api.

	Actually, there is a rumor that someone is developing a DirectX
interface for djgpp -- though I haven't seen anything that resembles a
functioning utility/interface that would accomodate such an
interface...not sure how much sense it would make to create such an
interface in the first place...especially with Allegro and GFX being
freely available to handle any sort of Graphics development under djgpp. 
In essence, the Allegro and GFX packages are custom built DOS Graphic
APIs.

> 
> >	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++).
> 
>   Hmm I don't know about that, I think it's more like directx is made for
> VC and the other commercial compilers can afford to do the rest of the
> work to get it working for their compilers.

	This sounds like the most logical reasoning...even though Win32 was 
developed within a similar context.

> 
> >>   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...
> 
>   Yeah, that's exactly the site which I went to. They have completely
>   stop
> you from dling the sdk, athough it does come up with an order form for
> the sdk on cd.

	Grr...sometimes...(needless to say, such limitations being placed by MS 
definitely does not surprise me...in fact it only serves to re-inforce my 
resolve against them...believe me, this is not a pretty thing.)

> 
> >>   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.
> 
>   Ahh ignore that.. b19 is a version of cygwin, not mingw, which won't
>   help
> my problem, since cygwin doesn't get ported to mingw. They are completely
> different things.

	EGCS can take cygwin32 source or Mingw32 based source (now) and build
just about any sort of application you want to build...short of anything
remotely oriented towards DirectX with precious few exceptions.  If I 
wasn't such an ardent minimalist, I'd probably be using EGCS.

	My suggestion would be to get the EGCS toolset and use it.  That way 
you'll have the freedom and power to build/port both minimalist and 
non-minimalist applications depending on your whim.

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