Re: [Mingw-w64-public] msxml with mingw-w64 (for QuickFIX) (was: libxml2 with mingw-w64?)

[pavel <pa...@pa...>]

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 <pa...@pa...> 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 <msxml3.dll> 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 <msxml3.dll> 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 <atlbase.h>
> >>    #include <atlconv.h>
> >>
> >> 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
> >> ...
> 
> ------------------------------------------------------------------------------
> 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
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public