Hi Pavel! Thanks for your help.
On Thu, Jan 10, 2013 at 3:56 AM, pavel <[email protected]> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
