Re: [Mingw-w64-public] msxml with mingw-w64 (for QuickFIX) (was: libxml2 with mingw-w64?)
> Just fix MSYS Autotooling for the whole thing and use libxml2! > > ;-) Indeed...it's a new year and your hard-working dev system has earned a much needed upgrade ;) Here's another way of quickly getting an msys + mingw-w64 environment. First, download and extract these MSYS files, say to `C:\DevTools`: https://github.com/oneclick/rubyinstaller/blob/master/config/devkit.rb#L30-L68 Next, download and extract one of Ruben's 32 or 64bit toolchains https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingw64.rb into a newly created `C:\DevTools\mingw` (actually, just rename his `mingw32` or `mingw64` dir to `mingw`). Finally, add `C:\DevTools\bin` and `C:\DevTools\mingw\bin` to PATH and you've got a decent toolchain. Open up a Command Prompt and type `sh` and start using autohell. Better yet, create a desktop shortcut with a `Target:` of `C:\DevKit\msys.bat --mintty`, open it up and right-click -> Options... to set all kinds of eye candy like fonts, transparency, etc. This is begging for automation from a .ps1 or .py, but that's your chance to add value. mingwbuilds looks like they've built the killer monster truck msys binary with all sorts of awesomeness. Sadly, I haven't yet played with it. http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/ But your dev system won't be satisfied. It will next want a bunch of VirtualBox VM's; mine squawked until I gave it Arch, Ubuntu Server, and Snow Leopard VMs each with cross-build support. Good luck. Jon --- Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat. http://thecodeshop.github.com | http://jonforums.github.com/ twitter: @jonforums -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] msxml with mingw-w64 (for QuickFIX) (was: libxml2 with mingw-w64?)
Just fix MSYS Autotooling for the whole thing and use libxml2! ;-) On Thu, Jan 10, 2013 at 12:09 PM, pavel wrote: > Hi Frank, > > I think you should definitively use msxml2.h. I use msxml quite often in > my applications, but I have my own generated include file, which > contains the CLSIDs, IIDs and interface definitions. If I look at > msxml2.h, I can see that CLSID_DOMDocument is declared as extern and I > have no idea where the ID is actually stored. I suppose it must be in > some lib, but could not figure out which one it is. (Perhaps it is in > one of the system libraries which is always linked.) > > The difference between msxml and msxml2 is that msxml2 has richer > interfaces. So QuickFIX probably will not work with the older > interfaces. But this should be cleared out at the compilation time. > > The other two msxml headers only contains some defines, they are > probably included by the other headers. > > Pavel > > On Thu, 2013-01-10 at 06:12 -0500, K. Frank wrote: >> Hi Pavel! >> >> Thanks for your help. >> >> On Thu, Jan 10, 2013 at 3:56 AM, pavel wrote: >> > Hi Frank, >> > >> > I went again through your posts and if I understand well, you are trying >> > to adapt some code written for MS VC++ to MinGW, is that correct? >> >> Yes, precisely. >> >> > In this case, you would probably need to rewrite a small portion of the >> > code, unless you will get for libxml2 in the end. >> >> That is indeed what I am hoping. (I think it is a reasonable hope, >> but you never know.) >> >> > I know nothing about QuickFIX but from the code bellow I deduce that the >> > only you need is the initialized m_pDoc pointer. You can use the code >> > bellow, however you should avoid using stdafx.h, it is a header >> > generated by MS VS for each VC project. >> >> Yes, I understand how stdafx.h works, and how to get rid of it. >> >> > The atl* headers are headers for >> > MS Active Template Library, this is a support stuff for COM. I cannot >> > see these headers in my MinGW installation and I suggest you to also >> > drop these includes. >> >> Okay. Hopefully they aren't used (or aren't used in any essential >> way) by the QuickFIX code. >> >> > So what you basically need is to check whether CLSID_DOMDocument (or >> > something like this) is declared in some of the msxml header files >> > delivered with MinGW. >> >> I don't have it in front of me, but I believe it is. >> >> > I suppose it is, so you will include this header >> >> As mentioned in the other thread, there are four different msxml >> headers provided with mingw-w64. Would you have any guess >> which I should be suing? How might I go about figuring it out? >> >> > and use the CLSID constant declared there to create the m_pDoc instance >> > through the CoCreateInstance call. I suppose the MSXML_DOMDocument class >> > is only a cosmetic wrapper around m_pDoc, more precisely about >> > IXMLDOMDocument interface declared in MinGW's msxml.h or msxml2.h. >> >> Yes, MSXML_DOMDocument is basically just a wrapper. It has >> a sibling LIBXML_DOMDocument class to abstract away the >> msxml / libxml2 differences from the rest of the code. >> >> > So, I am not sure whether my explanation is clear enough. My conclusion >> > is that if you decide to go for msxml, you would need to manually update >> > the code a bit, however, it should not be difficult with the headers >> > provided by MinGW. >> >> Your explanation has been very helpful. As mentioned in the other >> thread, I do indeed need to update the code. So far it's been mostly >> straightforward donkey work (deciding which occurrences of _MSC_VER >> to replace with _WIN32). >> >> Any last thoughts on how to figure out which of the mingw-w64 >> msxml I need to include would be helpful. >> >> > Pavel >> >> Thanks again for your thoughts. >> >> >> K. Frank >> >> >> > On Wed, 2013-01-09 at 19:13 -0500, K. Frank wrote: >> >> Hi Pavel (and List)! >> >> >> >> (Since my follow-up to Pavel's comments are about msxml, I am starting >> >> a new thread here to separate the discussion from that about libxml2.) >> >> >> >> On Wed, Jan 9, 2013 at 8:48 AM, pavel <...> wrote: >> >> > Frank, see my comments bellow. >> >> > >> >> > On Wed, 2013-01-09 at 08:04 -0500, K. Frank wrote: >> >> >> I am hoping that all I need to do is translate the above code >> >> >> fragment, e.g.: >> >> >> >> >> >>#import raw_interfaces_only named_guids >> >> >> >> >> >> into the mingw-w64 world (without learning DCOM). >> >> >> >> >> >> Any suggestions or even educated guesses would be helpful. >> >> >> Should I just #include all four msxml headers? Include only >> >> >> one "master" header file? Something else? Might I have to >> >> >> manually add some msxml library to the link command? >> >> >> >> >> >> I'm speculating that the microsoft #import command is reading >> >> >> through the .dll to find and extract the function-prototype information >> >> >> that in the mingw-w64 world is in the #include header files. But >> >> >> that
Re: [Mingw-w64-public] msxml with mingw-w64 (for QuickFIX) (was: libxml2 with mingw-w64?)
Hi Frank, I think you should definitively use msxml2.h. I use msxml quite often in my applications, but I have my own generated include file, which contains the CLSIDs, IIDs and interface definitions. If I look at msxml2.h, I can see that CLSID_DOMDocument is declared as extern and I have no idea where the ID is actually stored. I suppose it must be in some lib, but could not figure out which one it is. (Perhaps it is in one of the system libraries which is always linked.) The difference between msxml and msxml2 is that msxml2 has richer interfaces. So QuickFIX probably will not work with the older interfaces. But this should be cleared out at the compilation time. The other two msxml headers only contains some defines, they are probably included by the other headers. Pavel On Thu, 2013-01-10 at 06:12 -0500, K. Frank wrote: > Hi Pavel! > > Thanks for your help. > > On Thu, Jan 10, 2013 at 3:56 AM, pavel wrote: > > Hi Frank, > > > > I went again through your posts and if I understand well, you are trying > > to adapt some code written for MS VC++ to MinGW, is that correct? > > Yes, precisely. > > > In this case, you would probably need to rewrite a small portion of the > > code, unless you will get for libxml2 in the end. > > That is indeed what I am hoping. (I think it is a reasonable hope, > but you never know.) > > > I know nothing about QuickFIX but from the code bellow I deduce that the > > only you need is the initialized m_pDoc pointer. You can use the code > > bellow, however you should avoid using stdafx.h, it is a header > > generated by MS VS for each VC project. > > Yes, I understand how stdafx.h works, and how to get rid of it. > > > The atl* headers are headers for > > MS Active Template Library, this is a support stuff for COM. I cannot > > see these headers in my MinGW installation and I suggest you to also > > drop these includes. > > Okay. Hopefully they aren't used (or aren't used in any essential > way) by the QuickFIX code. > > > So what you basically need is to check whether CLSID_DOMDocument (or > > something like this) is declared in some of the msxml header files > > delivered with MinGW. > > I don't have it in front of me, but I believe it is. > > > I suppose it is, so you will include this header > > As mentioned in the other thread, there are four different msxml > headers provided with mingw-w64. Would you have any guess > which I should be suing? How might I go about figuring it out? > > > and use the CLSID constant declared there to create the m_pDoc instance > > through the CoCreateInstance call. I suppose the MSXML_DOMDocument class > > is only a cosmetic wrapper around m_pDoc, more precisely about > > IXMLDOMDocument interface declared in MinGW's msxml.h or msxml2.h. > > Yes, MSXML_DOMDocument is basically just a wrapper. It has > a sibling LIBXML_DOMDocument class to abstract away the > msxml / libxml2 differences from the rest of the code. > > > So, I am not sure whether my explanation is clear enough. My conclusion > > is that if you decide to go for msxml, you would need to manually update > > the code a bit, however, it should not be difficult with the headers > > provided by MinGW. > > Your explanation has been very helpful. As mentioned in the other > thread, I do indeed need to update the code. So far it's been mostly > straightforward donkey work (deciding which occurrences of _MSC_VER > to replace with _WIN32). > > Any last thoughts on how to figure out which of the mingw-w64 > msxml I need to include would be helpful. > > > Pavel > > Thanks again for your thoughts. > > > K. Frank > > > > On Wed, 2013-01-09 at 19:13 -0500, K. Frank wrote: > >> Hi Pavel (and List)! > >> > >> (Since my follow-up to Pavel's comments are about msxml, I am starting > >> a new thread here to separate the discussion from that about libxml2.) > >> > >> On Wed, Jan 9, 2013 at 8:48 AM, pavel <...> wrote: > >> > Frank, see my comments bellow. > >> > > >> > On Wed, 2013-01-09 at 08:04 -0500, K. Frank wrote: > >> >> I am hoping that all I need to do is translate the above code > >> >> fragment, e.g.: > >> >> > >> >>#import raw_interfaces_only named_guids > >> >> > >> >> into the mingw-w64 world (without learning DCOM). > >> >> > >> >> Any suggestions or even educated guesses would be helpful. > >> >> Should I just #include all four msxml headers? Include only > >> >> one "master" header file? Something else? Might I have to > >> >> manually add some msxml library to the link command? > >> >> > >> >> I'm speculating that the microsoft #import command is reading > >> >> through the .dll to find and extract the function-prototype information > >> >> that in the mingw-w64 world is in the #include header files. But > >> >> that's just a guess, so any help would be appreciated. > >> >> > >> >> Again, I'm not asking how to use msxml. I just need to know how > >> >> to make msxml available to code that presumably already uses it > >> >> correctly by find
Re: [Mingw-w64-public] msxml with mingw-w64 (for QuickFIX) (was: libxml2 with mingw-w64?)
Hi Pavel! Thanks for your help. On Thu, Jan 10, 2013 at 3:56 AM, pavel wrote: > Hi Frank, > > I went again through your posts and if I understand well, you are trying > to adapt some code written for MS VC++ to MinGW, is that correct? Yes, precisely. > In this case, you would probably need to rewrite a small portion of the > code, unless you will get for libxml2 in the end. That is indeed what I am hoping. (I think it is a reasonable hope, but you never know.) > I know nothing about QuickFIX but from the code bellow I deduce that the > only you need is the initialized m_pDoc pointer. You can use the code > bellow, however you should avoid using stdafx.h, it is a header > generated by MS VS for each VC project. Yes, I understand how stdafx.h works, and how to get rid of it. > The atl* headers are headers for > MS Active Template Library, this is a support stuff for COM. I cannot > see these headers in my MinGW installation and I suggest you to also > drop these includes. Okay. Hopefully they aren't used (or aren't used in any essential way) by the QuickFIX code. > So what you basically need is to check whether CLSID_DOMDocument (or > something like this) is declared in some of the msxml header files > delivered with MinGW. I don't have it in front of me, but I believe it is. > I suppose it is, so you will include this header As mentioned in the other thread, there are four different msxml headers provided with mingw-w64. Would you have any guess which I should be suing? How might I go about figuring it out? > and use the CLSID constant declared there to create the m_pDoc instance > through the CoCreateInstance call. I suppose the MSXML_DOMDocument class > is only a cosmetic wrapper around m_pDoc, more precisely about > IXMLDOMDocument interface declared in MinGW's msxml.h or msxml2.h. Yes, MSXML_DOMDocument is basically just a wrapper. It has a sibling LIBXML_DOMDocument class to abstract away the msxml / libxml2 differences from the rest of the code. > So, I am not sure whether my explanation is clear enough. My conclusion > is that if you decide to go for msxml, you would need to manually update > the code a bit, however, it should not be difficult with the headers > provided by MinGW. Your explanation has been very helpful. As mentioned in the other thread, I do indeed need to update the code. So far it's been mostly straightforward donkey work (deciding which occurrences of _MSC_VER to replace with _WIN32). Any last thoughts on how to figure out which of the mingw-w64 msxml I need to include would be helpful. > Pavel Thanks again for your thoughts. K. Frank > On Wed, 2013-01-09 at 19:13 -0500, K. Frank wrote: >> Hi Pavel (and List)! >> >> (Since my follow-up to Pavel's comments are about msxml, I am starting >> a new thread here to separate the discussion from that about libxml2.) >> >> On Wed, Jan 9, 2013 at 8:48 AM, pavel <...> wrote: >> > Frank, see my comments bellow. >> > >> > On Wed, 2013-01-09 at 08:04 -0500, K. Frank wrote: >> >> I am hoping that all I need to do is translate the above code >> >> fragment, e.g.: >> >> >> >>#import raw_interfaces_only named_guids >> >> >> >> into the mingw-w64 world (without learning DCOM). >> >> >> >> Any suggestions or even educated guesses would be helpful. >> >> Should I just #include all four msxml headers? Include only >> >> one "master" header file? Something else? Might I have to >> >> manually add some msxml library to the link command? >> >> >> >> I'm speculating that the microsoft #import command is reading >> >> through the .dll to find and extract the function-prototype information >> >> that in the mingw-w64 world is in the #include header files. But >> >> that's just a guess, so any help would be appreciated. >> >> >> >> Again, I'm not asking how to use msxml. I just need to know how >> >> to make msxml available to code that presumably already uses it >> >> correctly by finding the mingw-w64 equivalent of the #import line. >> >> >> > MS #import command does not read in the .dll. It reads in a binary file >> > called type library, usually with extension .tlb (however, the type >> > library can be also linked as resource to any executable file, e.g. exe, >> > dll and ocx). There is public API for reading type libraries, so >> > virtually a support for #import could be implemented into MinGW, but I >> > am afraid that it would be quite a big job. >> > >> > You don't need to link any COM dll, it is useless. On the other hand, >> > you must link to ole32 (defines CoInitialize, CoUninitialize), oleauto32 >> > (defines CoCreateInstance) and possibly uuid (defines GUID_NULL). Then >> > you must call CoInitialize in the beginning of your code (definitively >> > prior trying to load a COM object) and call CoUninitialize in the end of >> > your application. This all is perhaps handled by the MS _WIN32_DCOM >> > definition, I am not sure. >> > >> > You then create a new instance of a COM object by calling the >> > Co
Re: [Mingw-w64-public] msxml with mingw-w64 (for QuickFIX) (was: libxml2 with mingw-w64?)
Hi Frank,
I went again through your posts and if I understand well, you are trying
to adapt some code written for MS VC++ to MinGW, is that correct?
In this case, you would probably need to rewrite a small portion of the
code, unless you will get for libxml2 in the end.
I know nothing about QuickFIX but from the code bellow I deduce that the
only you need is the initialized m_pDoc pointer. You can use the code
bellow, however you should avoid using stdafx.h, it is a header
generated by MS VS for each VC project. The atl* headers are headers for
MS Active Template Library, this is a support stuff for COM. I cannot
see these headers in my MinGW installation and I suggest you to also
drop these includes.
So what you basically need is to check whether CLSID_DOMDocument (or
something like this) is declared in some of the msxml header files
delivered with MinGW. I suppose it is, so you will include this header
and use the CLSID constant declared there to create the m_pDoc instance
through the CoCreateInstance call. I suppose the MSXML_DOMDocument class
is only a cosmetic wrapper around m_pDoc, more precisely about
IXMLDOMDocument interface declared in MinGW's msxml.h or msxml2.h.
So, I am not sure whether my explanation is clear enough. My conclusion
is that if you decide to go for msxml, you would need to manually update
the code a bit, however, it should not be difficult with the headers
provided by MinGW.
Pavel
On Wed, 2013-01-09 at 19:13 -0500, K. Frank wrote:
> Hi Pavel (and List)!
>
> (Since my follow-up to Pavel's comments are about msxml, I am starting
> a new thread here to separate the discussion from that about libxml2.)
>
> On Wed, Jan 9, 2013 at 8:48 AM, pavel <...> wrote:
> > Frank, see my comments bellow.
> >
> > On Wed, 2013-01-09 at 08:04 -0500, K. Frank wrote:
> >> I am hoping that all I need to do is translate the above code
> >> fragment, e.g.:
> >>
> >>#import raw_interfaces_only named_guids
> >>
> >> into the mingw-w64 world (without learning DCOM).
> >>
> >> Any suggestions or even educated guesses would be helpful.
> >> Should I just #include all four msxml headers? Include only
> >> one "master" header file? Something else? Might I have to
> >> manually add some msxml library to the link command?
> >>
> >> I'm speculating that the microsoft #import command is reading
> >> through the .dll to find and extract the function-prototype information
> >> that in the mingw-w64 world is in the #include header files. But
> >> that's just a guess, so any help would be appreciated.
> >>
> >> Again, I'm not asking how to use msxml. I just need to know how
> >> to make msxml available to code that presumably already uses it
> >> correctly by finding the mingw-w64 equivalent of the #import line.
> >>
> >
> > MS #import command does not read in the .dll. It reads in a binary file
> > called type library, usually with extension .tlb (however, the type
> > library can be also linked as resource to any executable file, e.g. exe,
> > dll and ocx). There is public API for reading type libraries, so
> > virtually a support for #import could be implemented into MinGW, but I
> > am afraid that it would be quite a big job.
> >
> > You don't need to link any COM dll, it is useless. On the other hand,
> > you must link to ole32 (defines CoInitialize, CoUninitialize), oleauto32
> > (defines CoCreateInstance) and possibly uuid (defines GUID_NULL). Then
> > you must call CoInitialize in the beginning of your code (definitively
> > prior trying to load a COM object) and call CoUninitialize in the end of
> > your application. This all is perhaps handled by the MS _WIN32_DCOM
> > definition, I am not sure.
> >
> > You then create a new instance of a COM object by calling the
> > CoCreateInstance function with appropriate arguments.
>
> Thank you for the overview. I do have a cartoon picture of how COM
> works, but nothing really more than that.
>
> I do see in the msxml.h file provided by mingw-w64 declarations of
> various xml interfaces. I'm guessing that's effectively the information
> that visual studio gets with its "#import" command.
>
> In the QuickFIX code (in MSXML_DOMDocument.cpp, for those who
> care) I see the following code:
>
> MSXML_DOMDocument::MSXML_DOMDocument() throw( ConfigError )
> : m_pDoc(NULL)
> {
> if(FAILED(CoInitializeEx( 0, COINIT_MULTITHREADED )))
> if(FAILED(CoInitializeEx( 0, COINIT_APARTMENTTHREADED )))
> throw ConfigError("Could not initialize COM");
>
> HRESULT hr = CoCreateInstance(
> MSXML2::CLSID_DOMDocument, NULL, CLSCTX_ALL, __uuidof(
> MSXML2::IXMLDOMDocument2 ),
> ( void ** ) & m_pDoc );
>
> if ( hr != S_OK )
> throw( ConfigError( "MSXML DOM Document could not be created" ) );
> }
>
> Maybe I'm being too optimistic, but I see the QuickFIX code calling
> CoInitialize and CoCreate, and so on. So I'm hoping that all of the
> COM stuff is already taken care of in the QuickFIX code, *if* *only*
> I can fi
[Mingw-w64-public] msxml with mingw-w64 (for QuickFIX) (was: libxml2 with mingw-w64?)
Hi Pavel (and List)!
(Since my follow-up to Pavel's comments are about msxml, I am starting
a new thread here to separate the discussion from that about libxml2.)
On Wed, Jan 9, 2013 at 8:48 AM, pavel <...> wrote:
> Frank, see my comments bellow.
>
> On Wed, 2013-01-09 at 08:04 -0500, K. Frank wrote:
>> I am hoping that all I need to do is translate the above code
>> fragment, e.g.:
>>
>>#import raw_interfaces_only named_guids
>>
>> into the mingw-w64 world (without learning DCOM).
>>
>> Any suggestions or even educated guesses would be helpful.
>> Should I just #include all four msxml headers? Include only
>> one "master" header file? Something else? Might I have to
>> manually add some msxml library to the link command?
>>
>> I'm speculating that the microsoft #import command is reading
>> through the .dll to find and extract the function-prototype information
>> that in the mingw-w64 world is in the #include header files. But
>> that's just a guess, so any help would be appreciated.
>>
>> Again, I'm not asking how to use msxml. I just need to know how
>> to make msxml available to code that presumably already uses it
>> correctly by finding the mingw-w64 equivalent of the #import line.
>>
>
> MS #import command does not read in the .dll. It reads in a binary file
> called type library, usually with extension .tlb (however, the type
> library can be also linked as resource to any executable file, e.g. exe,
> dll and ocx). There is public API for reading type libraries, so
> virtually a support for #import could be implemented into MinGW, but I
> am afraid that it would be quite a big job.
>
> You don't need to link any COM dll, it is useless. On the other hand,
> you must link to ole32 (defines CoInitialize, CoUninitialize), oleauto32
> (defines CoCreateInstance) and possibly uuid (defines GUID_NULL). Then
> you must call CoInitialize in the beginning of your code (definitively
> prior trying to load a COM object) and call CoUninitialize in the end of
> your application. This all is perhaps handled by the MS _WIN32_DCOM
> definition, I am not sure.
>
> You then create a new instance of a COM object by calling the
> CoCreateInstance function with appropriate arguments.
Thank you for the overview. I do have a cartoon picture of how COM
works, but nothing really more than that.
I do see in the msxml.h file provided by mingw-w64 declarations of
various xml interfaces. I'm guessing that's effectively the information
that visual studio gets with its "#import" command.
In the QuickFIX code (in MSXML_DOMDocument.cpp, for those who
care) I see the following code:
MSXML_DOMDocument::MSXML_DOMDocument() throw( ConfigError )
: m_pDoc(NULL)
{
if(FAILED(CoInitializeEx( 0, COINIT_MULTITHREADED )))
if(FAILED(CoInitializeEx( 0, COINIT_APARTMENTTHREADED )))
throw ConfigError("Could not initialize COM");
HRESULT hr = CoCreateInstance(
MSXML2::CLSID_DOMDocument, NULL, CLSCTX_ALL, __uuidof(
MSXML2::IXMLDOMDocument2 ),
( void ** ) & m_pDoc );
if ( hr != S_OK )
throw( ConfigError( "MSXML DOM Document could not be created" ) );
}
Maybe I'm being too optimistic, but I see the QuickFIX code calling
CoInitialize and CoCreate, and so on. So I'm hoping that all of the
COM stuff is already taken care of in the QuickFIX code, *if* *only*
I can figure out how to translate the
#define _WIN32_DCOM
#import raw_interfaces_only named_guids
using namespace MSXML2;
that appears in stdafx.h into mingw-w64 land (and get it out of
stdafx.h).
Is it reasonable to imagine #include'ing msxml2.h (or maybe
some of the other mingw-w64-provided msxml headers) into
the .cpp file in question (MSXML_DOMDocument.cpp)?
I should mention that the file in questions also includes:
#include
#include
which I recall hearing somewhere are COM-related.
To summarize, I don't know what I'm doing with COM, so I'm looking
for a recipe.
I am hoping that I can:
1) include one or more of the mingw-w64 msxml headers in the
file in question.
2) link to (following what Pavel said) ole32, oleauto32, and possibly uuid
3) remove the non-standard #import directive
Could this work? If it's close, are there a couple of other details I need
to add?
Or am I all wet here and the only way to port (the msxml part of) QuickFIX
to mingw-w64 would be to re-write it?
> Pavel
Thanks for any further advice.
K. Frank
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-pu
