mingw-users Mailing List for MinGW - Minimalist GNU for Windows

Gang -

I was reading the ODBC SDK documentation in Microsoft's MSDN library (a 
dangerous thing, I know) and it mentioned that one way of using SQL in C was 
to use EXEC SQL and then terminate with a semi-colon (;) also known as 
embedded SQL. Does MINGW support this syntax, or am I limited to the CLI 
interface?

Thanks!

Chris

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

> > Yes, please give us some examples.  Given what Jackson Yee writes in
> > his outline above, it would seem that DirectX (regardless of version)
> > should work on all Windows platforms which have a C++ compiler, and yet
> > it does not.

I believe it works on all platforms that have the directX runtimes installed.
I use gcc C compiler though, which forces the rather ugly ->lpVtbl-> syntax.
(It's C rather than gcc which forces that).

> 
> I was not aware that MinGW was capable of linking to Microsoft's .lib files
> at all. I tried replacing libdxguid.a with dxguid.lib in my own project and
> it seems to work fine. I haven't had time to do any other testing (eg,
> DirectDrawCreate, DirectSoundCreate, new DX8 objects, etc.) since I only use
> the ID values and use LoadLibrary to load the DLLs and extract the function
> names.

I was also not aware of MinGW linking capability (thank you very much
to everyone responsible for it!!). I have not had a chance to try it out,
because I haven't been able to download the 100-odd MB of directX
SDK. I have been using the same LoadLibrary/GetProcAddress
method as Mike (which is even simpler in DX8 - For Direct 3D8
only one DLL and function is needed, and no GUIDs). The lib
linking will give me the chance to use the D3DX utility libs a lot
more easily.

DirectX might not be needed nor required for Mingw to function,
but this lib capability has made me seriously consider using it
for commercial software development. I'm just sorry I don't have
anything to put back into the project.

Martin.

On 30 Jul 2001, at 20:59, the Illustrious niceguy wrote:

> ---------- Original Message ----------------------------------
> From: "Lloyd Dupont" <ll...@ga...>
> Date: Tue, 31 Jul 2001 00:07:47 +0200
> 
> >Chris Marshall wrote:
> >> 
> >> Lloyd -
> >> 
> >> I'm going to stick my two cents in,
> >... i must admit that, though my name, i am french, and i understand 
> > the above line is just an expression not related to mingw, anyway,
> > what does it mean ?
> 
> The term 'two cents' refers to currency, and two cents in American
> currency isn't worth much.  So, to say you are 'putting your two cents
> in' means that you are going to offer some information, but it may not
> be very useful.

	Or it means it is just your personal opinion based on the information 
that you have available to you.  In essence, it is a way of saying, 
"for what it is worth" since for some, currency value is extremely 
relative.

	Always need to take it in context with the topic being discussed.  In 
this case the topic is COM, a Microsoft Specific method of handling 
things that don't really exist except as they are defined within the 
context of the source code itself (C or C++).  In fact, COM is nothing 
more than a collection of software constructs which are required for 
DirectX development.  Microsoft calls them Common Object Modules (I 
believe).  COM-Object is not to be confused with COM-Port as they are 
in fact two entirely different, and largely unrelated, concepts.

> 
> >
> >
> >> Assuming that you are correct that SafeArrayCreateEx() is a part of
> >> the oleaut32.dll, then it seems to me that you need to have an
> >> oleaut32.lib and an oleaut32.h somewhere ... perhaps obtained from
> >> the Microsoft SDK?
> >in fact oleaut32.dll is a standart DLL found in
> >C:\WINNT\System32\oleaut32.dll
> >(not specifically shipped with a dev env)
> >
> >it seems that SafeArrayCreateEx is new, as i have bought, in the
> >beginning of 98, Visual C++ 5, which is shipped with OLEAUTO.H which
> >has a definition for 'SafeArrayCreate' but not for 'SafeArrayCreateEx'
> 
> Generally, the functions with 'Ex' represent some difference between
> Windows 9x and Window NT/2000.  If you aren't targeting the 9x systems,
> the function without the 'Ex' is usually preferred.  The SDK
> documentation at the Microsoft site is very useful for determining which
> version should be used for which platform.  I have some COM code on my
> NT machine that uses 'SafeArrayCreate' and Mingw has no problems
> understanding it.

	This has to do with the fact that hardware/memory access under NT4 is 
capable of being strictly controlled (NT4 Access Control Language or 
ACL -- see MSDN library docs for more information), whereas under 
Win9x/Me they are not.  Has to do with system architectures being 
fundamentally different between Win9x/Me and NT4.

	So, if you require SafeArrayCreateEx, then you require the very latest 
release from Microsoft for oleauto32.dll (Win98/NT4 both have this).  
You can import this for Mingw .a files if you wish.

	Finally, I seem to remember someone putting together an OLE package 
for Mingw.  You might want to do a google search to determine where 
that package is at.

	Paul G.

----- Original Message -----
From: "Paul G." <pga...@qw...>
To: <min...@so...>
Sent: Tuesday, July 31, 2001 6:05 PM
Subject: Re: [Mingw-users] DirectX 8 libs for MingW32


>
>
> On 31 Jul 2001, at 14:11, the Illustrious Rob Light wrote:
>
> Jackson Yee, wrote:
>
> >
> > <snip>
> >
> > > Most people who use DirectX use the C++ interface because it's more
> > > precise and more efficient than using the Visual Basic interface, but
> > > DirectX itself is not a C++ library; it's a COM-based library where
> > > COM interfaces and pointers are the methods to access all functions
> > > and properties.  Because COM is a binary interface, the different
> > > name-mangling, memory allocation, and such issues between varying C++
> > > compilers don't matter, because they don't come into play.
> > >
> > > As far as the libraries themselves, all you're linking to is the
> > > definitions for the DirectX GUIDs.  There aren't any C++ classes or
> > > functions to link to.  As long as the compiler supports COM, DirectX
> > > can be used.
>
>
> >
> > Hmmm, that's interesting.  How exactly does this work?
>
> Yes, please give us some examples.  Given what Jackson Yee writes in
> his outline above, it would seem that DirectX (regardless of version)
> should work on all Windows platforms which have a C++ compiler, and yet
> it does not.

I was not aware that MinGW was capable of linking to Microsoft's .lib files
at all. I tried replacing libdxguid.a with dxguid.lib in my own project and
it seems to work fine. I haven't had time to do any other testing (eg,
DirectDrawCreate, DirectSoundCreate, new DX8 objects, etc.) since I only use
the ID values and use LoadLibrary to load the DLLs and extract the function
names.

- Mike

On 31 Jul 2001, at 14:11, the Illustrious Rob Light wrote:

Jackson Yee, wrote:

> 
> <snip>
> 
> > Most people who use DirectX use the C++ interface because it's more
> > precise and more efficient than using the Visual Basic interface, but
> > DirectX itself is not a C++ library; it's a COM-based library where
> > COM interfaces and pointers are the methods to access all functions
> > and properties.  Because COM is a binary interface, the different
> > name-mangling, memory allocation, and such issues between varying C++
> > compilers don't matter, because they don't come into play.
> > 
> > As far as the libraries themselves, all you're linking to is the
> > definitions for the DirectX GUIDs.  There aren't any C++ classes or
> > functions to link to.  As long as the compiler supports COM, DirectX
> > can be used.

	
> 
> Hmmm, that's interesting.  How exactly does this work?

	Yes, please give us some examples.  Given what Jackson Yee writes in 
his outline above, it would seem that DirectX (regardless of version) 
should work on all Windows platforms which have a C++ compiler, and yet 
it does not.

Rob Light wrote:

>  Can someone
> point me to some good reference material (on or offline) where I can
> learn how COM works?  I'd like to know how the compiler/linker
> "resolves" the COM symbols and what mechanism "links" the method calls
> to the right code run time.

	http://www.msdn.com

	Take a look at the MSDN library/documentation for COM.

[skip]

> TIA,
> Rob

	Paul G.
> 
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
> 
> You may change your MinGW Account Options at:
> http://lists.sourceforge.net/lists/listinfo/mingw-users
> 

Jackson Yee wrote:

<snip>

> Most people who use DirectX use the C++ interface because it's more precise
> and more efficient than using the Visual Basic interface, but DirectX itself
> is not a C++ library; it's a COM-based library where COM interfaces and
> pointers are the methods to access all functions and properties.  Because
> COM is a binary interface, the different name-mangling, memory allocation,
> and such issues between varying C++ compilers don't matter, because they
> don't come into play.
> 
> As far as the libraries themselves, all you're linking to is the definitions
> for the DirectX GUIDs.  There aren't any C++ classes or functions to link
> to.  As long as the compiler supports COM, DirectX can be used.

Hmmm, that's interesting.  How exactly does this work?  Can someone
point me to some good reference material (on or offline) where I can
learn how COM works?  I'd like to know how the compiler/linker
"resolves" the COM symbols and what mechanism "links" the method calls
to the right code run time.

<snip>

> The one catch is that since you're linking directly to the *.lib files, you
> must specify the *full* path of the .lib file.  Since you're not passing the
> library to ld via the -l option, ld won't know to search for it in any lib
> directories.  Since I only needed strmiids.lib, which contains the
> definitions for IID_IGraphBuilder, IID_IMediaControl, and IID_IMediaEvent,
> that doesn't affect me much, but it could be annoying if you're linking to
> multiple .lib files.  I haven't found any other problems, and my DirectShow
> based movie player is working great at this point.

What do the definitions for IID_IGraphBuilder, etc. contain?

And where do the symbols for CoInitialize(), CoCreateInstance(), and
CoUninitialize() reside?  Surely they must be available in some type of
library at link time, right?

TIA,
Rob

On 31 Jul 2001, at 2:29, Infidel - wrote:

> supposed to be shared between all running instances of the DLL. The
> syntax I have tried is what I have read in the GCC documentation:
> 
> int foo __attribute__((section ("shared"), shared)) = 1;

IMHO, it should be:

int __attribute__((section ("shared"), shared)) foo = 1;

or, copy&paste from a working app:

HHOOK __attribute__ ((section (".SHAREd"), shared)) hHook = 0;

>Subject: Re: [Mingw-users] about COM
>   From: "niceguy " <ni...@ab...>
>   Date: Mon, 30 Jul 2001 20:59:11 -0400
>     To: <min...@li...>
>
>---------- Original Message ----------------------------------
>Generally, the functions with 'Ex' represent some difference between Windows 9x and Window NT/2000.  If you aren't targeting the 9x systems, the function without the 'Ex' is usually preferred.  The SDK documentation at the Microsoft site is very useful for determining which version should be used for which platform.  I have some COM code on my NT machine that uses 'SafeArrayCreate' and Mingw has no problems understanding it.

That is not quite true. Most of the 'Ex'-functions in the Windows API is improved functions simular to the ones without the 'Ex'.
They came around when Windows 95 got out. So actually they are the difference between Windows 3x and Windows 4x.

The difference to the NT platforms is the 'A' and 'W' functions. They are both in Windows 95 for compatibility issues, but the major part of the 'W' in Windows 95 does nothing.

I wonder why the Unicode implementation wasn't in Windows 98. The were available from the NT4 kernel, so I cannot find a reason why they still are unimplementet in ME.

I know this is OT but have any of you ever lined up some of the latest Windows names? Check this one: CE+ME+NT equals what? "Windows CEMENT"
:-)

Regards
Chris Hansen

---------- Original Message ----------------------------------
From: "Lloyd Dupont" <ll...@ga...>
Date: Tue, 31 Jul 2001 00:07:47 +0200

>Chris Marshall wrote:
>> 
>> Lloyd -
>> 
>> I'm going to stick my two cents in,
>... i must admit that, though my name, i am french, and i understand 
> the above line is just an expression not related to mingw, anyway,
> what does it mean ?

The term 'two cents' refers to currency, and two cents in American currency isn't worth much.  So, to say you are 'putting your two cents in' means that you are going to offer some information, but it may not be very useful.

>
>
>> Assuming that you are correct that SafeArrayCreateEx() is a part
>> of the oleaut32.dll, then it seems to me that you need to have an
>> oleaut32.lib and an oleaut32.h somewhere ... 
>> perhaps obtained from the Microsoft SDK?
>in fact oleaut32.dll is a standart DLL found in
>C:\WINNT\System32\oleaut32.dll
>(not specifically shipped with a dev env)
>
>it seems that SafeArrayCreateEx is new, as i have bought, in the
>beginning of 98, Visual C++ 5, which is shipped with OLEAUTO.H which
>has a definition for 'SafeArrayCreate' but not for 'SafeArrayCreateEx'

Generally, the functions with 'Ex' represent some difference between Windows 9x and Window NT/2000.  If you aren't targeting the 9x systems, the function without the 'Ex' is usually preferred.  The SDK documentation at the Microsoft site is very useful for determining which version should be used for which platform.  I have some COM code on my NT machine that uses 'SafeArrayCreate' and Mingw has no problems understanding it.


Jim S.

Lloyd -

Je ne parle pas en francias bien, mais j'essayerai. J'ai obtenu l'aide de 
http://babelfish.altavista.com.

L'expression de "to stick my two cents in" pourrais également être écrit "je 
voudrais ajouter mes deux cents à cette discussion." ("I wish to add my two 
cents to this discussion.")

Un "cent" est la plus petite piece en le dollar, 1/100th. Je pense que il 
est equivalent au "centimme" (spelling?) en le franc francais?

Il signifie que l'information que je souhaite ajouter pourrait être de 
petite valeur, et je sais cela, mais je vais le dire de toute façon.

A tout

Chris

----Original Message Follows----

Chris Marshall wrote:
 >
 > Lloyd -
 >
 > I'm going to stick my two cents in,
... i must admit that, though my name, i am french, and i understand the
above line is just an expression not related to mingw, anyway, what does
it mean ?


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Chris Marshall wrote:
> 
> Lloyd -
> 
> I'm going to stick my two cents in,
... i must admit that, though my name, i am french, and i understand the
above line is just an expression not related to mingw, anyway, what does
it mean ?


> Assuming that you are correct that SafeArrayCreateEx() is a part
> of the oleaut32.dll, then it seems to me that you need to have an
> oleaut32.lib and an oleaut32.h somewhere ... 
> perhaps obtained from the Microsoft SDK?
in fact oleaut32.dll is a standart DLL found in
C:\WINNT\System32\oleaut32.dll
(not specifically shipped with a dev env)

it seems that SafeArrayCreateEx is new, as i have bought, in the
beginning of 98, Visual C++ 5, which is shipped with OLEAUTO.H which has
a definition for 'SafeArrayCreate' but not for 'SafeArrayCreateEx'


> Otherwise, you might have to build a libary from the .DLL by
> creating a .DEF
> file and then using dlltool (what I went through a couple of weeks
> ago). I  don't see how that procedure solves the problem of the
> missing .h file, however.
yeah, ...
the problem is that i allready try to download microsoft SDK just a few
week ago, but this download a 64 bit version of visual studio, CL
compiler and header.
it don't work on my machine and it is not shiped with ole*.h headers.
(maybe i missed something ?)

[Perhaps it won't be too far off topic to mention
a few gnu preprocessor FAQs here.
Please follow up somewhere like gnu.gcc.help.]

Paul Whitfield wrote:
> 
> Jason Craig wrote:
> >
> > #inlcude <string>
> > using namespace std;
> > int main()
> > {
> > //file is in c:\temp\
> > string file("abcde");
> > file.empty();
> > return 0;
> > }
>
> The problem is the trailing \
> 
> This causes the compiler to think that the
> comment continues onto the next line commenting out string
> file("abcde");
> 
> Checking in my ancient C++ ARM, the description of the pre-processor
> says that backslashes are processed BEFORE comments are removed.

The standard says the same thing [2.1/2].

Characters are mapped to the C character set (maybe
that's like EBCDIC to ASCII?), then trigraphs are
processed, then lines with trailing backslashes
are spliced before anything else.

Then the whole thing is parsed into preprocessing
tokens; string literals are recognized here, before
any preprocessing directives. That's why this
  #if 0
    This isn't valid
  #endif
is validly rejected by the gnu preprocessor, even
though many others accept it.

Finally, if you compile with -pedantic (I recommend it)
then make sure every source file ends in a newline.
The language has actually required this for more than
a decade.

i find a lot of documentation speaking of SAFEARRAY and how to create
them with 'SafeArrayCreate(..)' or 'SafeArrayCreateEx(..)' for user
defined struct.

unfortunately i see nowhere in mingw (header or library) where
'SafeArrayCreateEx()' is defined...
(but i see it is implemented in oleaut32.dll)

is it normal ? what could i do ?

BTW i found you use 'struct IRecordInfo *' in header (oaidl.h) but it is
never defined....
it's a problem for me too as it is needed by 'SafeArrayCreateEx(..)'.

James writes:

> I've been using mingw for a while, but I don't know how to statically =
> link libstdc++.a.  My goal is to distribute a program without having to =
> distribute the libstdc++.dll with it.  How do I go about this?  (linking =
> stdc++ statically)

Append this to your link command:

  -Wl,-Bstatic -lstdc++

If there are unresolved references, you might try recompiling your
sources with -static.

David

I've been using mingw for a while, but I don't know how to statically =
link libstdc++.a.  My goal is to distribute a program without having to =
distribute the libstdc++.dll with it.  How do I go about this?  (linking =
stdc++ statically)

Thanks,
James

(sorry for posting a basic question, I couldn't find info anywhere on =
the web or searching newsgroups)

----- Original Message -----
From: "Rob Light" <rl...@ar...>
To: <min...@li...>
Sent: Monday, July 30, 2001 11:52
Subject: Re: [Mingw-users] DirectX 8 libs for MingW32


> So GCC can link with the MS provided DX8 *.lib files directly.  How is
> this possible?  Is it because DX8 is C code?  If not, then how is it
> possible to link with a C++ *.lib files created with MSVC++?  Can you
> provide a simple example of a g++ command line linking together the
> *.lib files and creating a *.exe file?

Most people who use DirectX use the C++ interface because it's more precise
and more efficient than using the Visual Basic interface, but DirectX itself
is not a C++ library; it's a COM-based library where COM interfaces and
pointers are the methods to access all functions and properties.  Because
COM is a binary interface, the different name-mangling, memory allocation,
and such issues between varying C++ compilers don't matter, because they
don't come into play.

As far as the libraries themselves, all you're linking to is the definitions
for the DirectX GUIDs.  There aren't any C++ classes or functions to link
to.  As long as the compiler supports COM, DirectX can be used.

For some sample code from the DirectShow documentation for playing a movie:

main.cpp:
-----------------------------------------------------

#include <dshow.h>

int main(void)
{
    IGraphBuilder* pGraph(NULL);
    IMediaControl* pMediaControl(NULL);
    IMediaEvent* pEvent(NULL);

    CoInitialize(NULL);

    CoCreateInstance(CLSID_FilterGraph, NULL, CLSCTX_INPROC_SERVER,
                        IID_IGraphBuilder, (void **)&pGraph);
    pGraph->QueryInterface(IID_IMediaControl, (void **)&pMediaControl);
    pGraph->QueryInterface(IID_IMediaEvent, (void **)&pEvent);

    pGraph->RenderFile(L"[insert the location of a .avi file here]", NULL);

    pMediaControl->Run();

    long evCode;
    pEvent->WaitForCompletion(INFINITE, &evCode);

    pMediaControl->Release();
    pEvent->Release();
    pGraph->Release();

    CoUninitialize();
}

And the command line:

g++ main.cpp -o test.exe ../dx8/lib/strmiids.lib -lole32

The one catch is that since you're linking directly to the *.lib files, you
must specify the *full* path of the .lib file.  Since you're not passing the
library to ld via the -l option, ld won't know to search for it in any lib
directories.  Since I only needed strmiids.lib, which contains the
definitions for IID_IGraphBuilder, IID_IMediaControl, and IID_IMediaEvent,
that doesn't affect me much, but it could be annoying if you're linking to
multiple .lib files.  I haven't found any other problems, and my DirectShow
based movie player is working great at this point.

Regards,
Jackson Yee
http://jacksonyee.welcome.to/
E-mails for help will be ignored unless I had asked for them.  Please post
to the group.



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Hi,

I have been trying to compile a DLL with some global variables that are 
supposed to be shared between all running instances of the DLL. The syntax I 
have tried is what I have read in the GCC documentation:

int foo __attribute__((section ("shared"), shared)) = 1;

void func(void)
{
    foo = 3;
}

When I compile this as a simple test, the object file looks okay, having a 
section called "shared" that has the SHARED flag (according to objdump -h):

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000010  00000000  00000000  000000b4  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000000  2**2
                  ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000000  2**2
                  ALLOC
  3 shared        00000004  00000000  00000000  000000c4  2**2
                  CONTENTS, SHARED

But when I link this as a DLL with "gcc -shared", there is no "shared" 
section in the output DLL:

test.dll:     file format pei-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000200  10001000  10001000  00000400  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000200  10002000  10002000  00000600  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 .edata        00000200  10003000  10003000  00000800  2**2
                  CONTENTS
  3 .idata        00000200  10004000  10004000  00000a00  2**2
                  CONTENTS
  4 .reloc        00000200  10005000  10005000  00000c00  2**2
                  CONTENTS

Disassembling the reference to 'foo' gives:

10001053:       c7 05 00 00 00 00 03    movl   $0x3,0x0
1000105a:       00 00 00

Am I missing something? Is there a way to tell the linker not to omit the 
"shared" section in the output? If anyone has a working example I would 
appreciate seeing it.

Infidel


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Jackson Yee wrote:
> 
> ----- Original Message -----
> From: "Mike L" <mi...@sp...>
> To: <min...@so...>
> Sent: Sunday, July 29, 2001 21:05
> Subject: Re: [Mingw-users] DirectX 8 libs for MingW32
> > Apologies, I should have been specific with my question: As I understood
> it,
> > you needed to link to mingw-compatible libraries (libdxguid.a, etc) in the
> > past. Jackson Yee's message indicates you can just link directly to MS's
> > .lib files in MS's SDK with the new MinGW. I just wanted to know when this
> > became possible.
> >
> > I have a page with some MinGW/DirectX info, documenting my own
> experiences,
> > and I just wanted to try clarifying this issue so I could make some
> > corrections, Thanks.
> 
> The version that I'm using at the moment is 20010608.  I'm not sure how long
> ld has had this capability, but it definitely saved me a lot of work not
> having to convert the .lib files in order to use them.  Note that I haven't
> done anything other than to include the GUIDs in my program though, since
> the COM-based nature of DirectX means that the COM APIs do most of the work
> of locating, creating, and distributing method calls for you.

So GCC can link with the MS provided DX8 *.lib files directly.  How is
this possible?  Is it because DX8 is C code?  If not, then how is it
possible to link with a C++ *.lib files created with MSVC++?  Can you
provide a simple example of a g++ command line linking together the
*.lib files and creating a *.exe file?

TIA,
Rob

> 	Back to the subject at hand, Mingw development is
> focussed on Mingw 
> Development Tool Set, and DirectX is Not Needed nor
> Required for Mingw 
> to function regardless of how much Microsoft wants
> to hype their latest 
> and greatest DirectX release.

Errr... I would have thought MinGW development is
focused on being able to use the gcc compiler
effectively in a Win32 environment and that means
supporting the most important APIs one of which is
DirectX.  Not that I'm a fan of DirectX (I find it
quite painful actually), but MinGW is starting to
become a *REAL* alternative to commercial Windoze
compilers.

Also, afaik, DirectX 8 is now available for all the
incarnations of Windows on the desktop (except the
'deprecated' ones of course).

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

----- Original Message -----
From: "Mike L" <mi...@sp...>
To: <min...@so...>
Sent: Sunday, July 29, 2001 21:05
Subject: Re: [Mingw-users] DirectX 8 libs for MingW32
> Apologies, I should have been specific with my question: As I understood
it,
> you needed to link to mingw-compatible libraries (libdxguid.a, etc) in the
> past. Jackson Yee's message indicates you can just link directly to MS's
> .lib files in MS's SDK with the new MinGW. I just wanted to know when this
> became possible.
>
> I have a page with some MinGW/DirectX info, documenting my own
experiences,
> and I just wanted to try clarifying this issue so I could make some
> corrections, Thanks.

The version that I'm using at the moment is 20010608.  I'm not sure how long
ld has had this capability, but it definitely saved me a lot of work not
having to convert the .lib files in order to use them.  Note that I haven't
done anything other than to include the GUIDs in my program though, since
the COM-based nature of DirectX means that the COM APIs do most of the work
of locating, creating, and distributing method calls for you.

Regards,
Jackson Yee
http://jacksonyee.welcome.to/
E-mails for help will be ignored unless I had asked for them.  Please post
to the group.



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Hi Jason,

The problem is the trailing \

This causes the compiler to think that the
comment continues onto the next line commenting out string
file("abcde");

Checking in my ancient C++ ARM, the description of the pre-processor
says that backslashes are processed BEFORE comments are removed.

Thus GCC is doing "The Right Thing"!

So it looks like it is time to suspend your disbelief!

Jason Craig wrote:
> 
> I know that this isn't specific to MinGW, I actually looked up the code in
> the GCC sources, as I was in disbelief.
> 
> #inlcude <string>
> using namespace std;
> int main()
> {
> //file is in c:\temp\
> string file("abcde");
> file.empty();
> return 0;
> }
> 
> #include <string>
> using namespace std;
> int main()
> {
> //"file is in c:\temp\"
> string file("abcde");
> file.empty();
> return 0;
> }
> 
> Example one does not compile, the second was does just fine.  Of course,
> when -Wcomments is turned on, the compiler gives a warning.  (and then fails
> to compile.)  As I have demonstrated by the seemingly innocent use off a
> comment above, this can be very strange behavior.  This cannot actually be a
> feature of the C++ standard can it?  Surely GCC goes its own way here?  It
> took me a good while to track down a bug with this exact same type of
> problem, except the compiler made no complaints, just run-time behavior was
> wacko.
> 
> --Jason Craig
> 
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
> 
> You may change your MinGW Account Options at:
> http://lists.sourceforge.net/lists/listinfo/mingw-users

-- 
-------------------------------------------------------
Paul Whitfield
Senior Software Engineer
Microsol (Aust) Ltd

Phone: (+61) 08 9473 6646
Fax:   (+61) 08 9473 6699

I know that this isn't specific to MinGW, I actually looked up the code in
the GCC sources, as I was in disbelief.

#inlcude <string>
using namespace std;
int main()
{
//file is in c:\temp\
string file("abcde");
file.empty();
return 0;
}

#include <string>
using namespace std;
int main()
{
//"file is in c:\temp\"
string file("abcde");
file.empty();
return 0;
}

Example one does not compile, the second was does just fine.  Of course,
when -Wcomments is turned on, the compiler gives a warning.  (and then fails
to compile.)  As I have demonstrated by the seemingly innocent use off a
comment above, this can be very strange behavior.  This cannot actually be a
feature of the C++ standard can it?  Surely GCC goes its own way here?  It
took me a good while to track down a bug with this exact same type of
problem, except the compiler made no complaints, just run-time behavior was
wacko.

--Jason Craig

i want to create a SAFEARRAY, some kind of microsoft managed array

i include
#include <windows.h>

it appears it was not sufficient. so i try to include

#include <windows.h>
#include <oleauto.h>

i get so a lot of parse error....
which file should i, in fact, include ?

----- Original Message -----
From: "Paul G." <pga...@qw...>
To: <min...@so...>
Sent: Sunday, July 29, 2001 8:02 PM
Subject: Re: [Mingw-users] DirectX 8 libs for MingW32


>
>
> On 29 Jul 2001, at 18:33, the Illustrious Mike L wrote:
>
> > ----- Original Message -----
> > From: "Jackson Yee" <jac...@ya...>
> > To: <min...@li...>
> > Sent: Saturday, July 28, 2001 3:07 PM
> > Subject: Re: [Mingw-users] DirectX 8 libs for MingW32
> >
> > > I don't know where Peter's site has gone, but if you want to use
> > > DirectX
> > 8,
> > > you can download the DirectX SDK from MSDN and use it directly with
> > > the latest stable release of MinGW.
> >
> > Is this the first version (Mingw-1.0.1-20010726) of MinGW to support
> > this?
>
> Nope.  DirectX has been minimally supported since it was available on
> the net for review (documentation, etc.).  The first version of Dx
> which I used in a Mingw application was actually Dx3.  Most NT4
> developers prefer OpenGL since OpenGL is supported across all Windows
> based (win32api) platforms.  DirectX, especially the latest versions,
> are not.

Apologies, I should have been specific with my question: As I understood it,
you needed to link to mingw-compatible libraries (libdxguid.a, etc) in the
past. Jackson Yee's message indicates you can just link directly to MS's
.lib files in MS's SDK with the new MinGW. I just wanted to know when this
became possible.

I have a page with some MinGW/DirectX info, documenting my own experiences,
and I just wanted to try clarifying this issue so I could make some
corrections, Thanks.

- Mike

On 29 Jul 2001, at 18:33, the Illustrious Mike L wrote:

> ----- Original Message -----
> From: "Jackson Yee" <jac...@ya...>
> To: <min...@li...>
> Sent: Saturday, July 28, 2001 3:07 PM
> Subject: Re: [Mingw-users] DirectX 8 libs for MingW32
> 
> > I don't know where Peter's site has gone, but if you want to use
> > DirectX
> 8,
> > you can download the DirectX SDK from MSDN and use it directly with
> > the latest stable release of MinGW.
> 
> Is this the first version (Mingw-1.0.1-20010726) of MinGW to support
> this?

	Nope.  DirectX has been minimally supported since it was available on 
the net for review (documentation, etc.).  The first version of Dx 
which I used in a Mingw application was actually Dx3.  Most NT4 
developers prefer OpenGL since OpenGL is supported across all Windows 
based (win32api) platforms.  DirectX, especially the latest versions, 
are not.

	Incidentally, the movie, "Final Fantasy:  The Spriits Within" was 
created using SGIs' Silicon Graphics Onyx, Octane and 2000 servers to 
name only a few (OpenGL is standard on most, if not all SGI machines).  
Alias/Wavefront Maya and Pixar Renderman (Linux) were used for CG 
development.

	See http://www.sgi.com/features/2001/july/fantasy/ for more on this.

	Back to the subject at hand, Mingw development is focussed on Mingw 
Development Tool Set, and DirectX is Not Needed nor Required for Mingw 
to function regardless of how much Microsoft wants to hype their latest 
and greatest DirectX release.

	Paul G.