- Forum
- Windows Programming
- Making a program using COM in windows
Making a program using COM in windows
I am trying to make a program using COM.
My final goal is being able to use COM objects by just knowing their ProgID and nothing else, like I have seen a scriping language do.
thanks
|
|
My final goal is being able to use COM objects by just knowing their ProgID and nothing else, like I have seen a scriping language do.
thanks
Last edited on
I'd recommend you test HRESULT hr for success/failure after each call to a function where an HRESULT is returned, e.g.,
Your specific problem above is that "InternetExplorer.Application" likely isn't an in process server as specified by CLSCTX_INPROC_SERVER, but rather an out of process local server, i.e., an exe.
However and for sure, the full functionality of Internet Explorer is contained within a COM dll or 'in process server' named ...
"Shell.Explorer"
You can look that up in RegEdit under HKEY_CLASSES_ROOT.
I have posted here already code that shows how to load Microsoft's Web Browser Control within a host app. I could find it for you or repost it I guess.
What you are trying to do though might work if you take care of the items I specified above.
|
|
Your specific problem above is that "InternetExplorer.Application" likely isn't an in process server as specified by CLSCTX_INPROC_SERVER, but rather an out of process local server, i.e., an exe.
However and for sure, the full functionality of Internet Explorer is contained within a COM dll or 'in process server' named ...
"Shell.Explorer"
You can look that up in RegEdit under HKEY_CLASSES_ROOT.
I have posted here already code that shows how to load Microsoft's Web Browser Control within a host app. I could find it for you or repost it I guess.
What you are trying to do though might work if you take care of the items I specified above.
Right now I'm posting this after creating a basic Win32 GUI Host app which hosts the "Shell.Explorer" ActiveX Control which is the heart of Microsoft Internet Explorer. I'm using that app to log in and post here - in other words. This is quite involved and will require several posts to complete, but I'll post all the code necessary. I used Mingw 4.4 from Code::Blocks 10.05 to create the executable. I did that on a Win64 machine with XP Mode installed, so its a 32 bit executable. Here's the code. First the Main.cpp main source code file...
|
|
Here is Main.h...
|
|
1st part of IWebBrowser.h...
|
|
2nd Part ...
|
|
Last part...
|
|
To get this to work, you need some version of AtlXX.dll, where XX is 71, 80, 90, or something. Don't believe I've ever got it to work with just Atl.dll, for whatever reason. If you look up in StartOLEProcess() near the top of Main.cpp you'll see I'm trying to do a LoadLibrary() call on Atl71.dll. Note the dll needs to be in the working or same directory where the exe is located.
The Atl.dll file provides something teermed an "ActiveX Control Container". In Win32 C or C++ projects where there is no visual designer involved one needs various routines to handle some of the negotiation that's involved between the siting of the ActiveX Control in the host, and the control itself.
Add link libraries ole32.lib, oleaut32.lib, and uuid.lib.
If the browser shows up, and you're connected to the internet, type a url in the text box at top and hit the 'Navigate' button.
The Atl.dll file provides something teermed an "ActiveX Control Container". In Win32 C or C++ projects where there is no visual designer involved one needs various routines to handle some of the negotiation that's involved between the siting of the ActiveX Control in the host, and the control itself.
Add link libraries ole32.lib, oleaut32.lib, and uuid.lib.
If the browser shows up, and you're connected to the internet, type a url in the text box at top and hit the 'Navigate' button.
Last edited on
But I havn't forgotten your original attempt to start the "InternetExplorer.Application". Here is how to do it. But note you still need my IWebBrowser.h file if you want the IExplorer.exe instance to become visible, because SetVisible is one of the methods of the IWebBrowser interface...
|
|
Thanks for quick response.
I tried the code in the last post, and made IWebBrowser.h. The code compiled on the first try and the application worked! Very nice!
Your code cleared much of the fog of COM objects. I see that I have to declare functions for changing properties of the object (such as SetVisible()).
However, one the things that threw me off while studying COM was that a scripting language I like to use (which is built in C++) is able to call COM without the need for anything except the ProgID. I'm not sure how they did that; I don't think the makers included a header file and information for each class of COM objects it supports on its own.
I will try to use your imbedded shell object example.
Another noob question:
Is there a way to get the Mingw version or do you just remember it from downloading it?
If case you do want to pursue the scripting language I'm talking about here is some information. The scripting language is called AutoHotkey and is made for doing easy windows automation but has lots of added other features as well.
http://ahkscript.org/docs/commands/ComObjCreate.htm - Command for creating COM objects (see example at the bottom)
http://www.autohotkey.com/board/topic/56987-com-object-reference-autohotkey-v11/page-2?&#entry362159 - a bigger InternetExplorer.Application example
https://github.com/Lexikos/AutoHotkey_L/ - the build for AutoHotkey (which is in C++), in case it might be helpful.
thank you again
I tried the code in the last post, and made IWebBrowser.h. The code compiled on the first try and the application worked! Very nice!
Your code cleared much of the fog of COM objects. I see that I have to declare functions for changing properties of the object (such as SetVisible()).
However, one the things that threw me off while studying COM was that a scripting language I like to use (which is built in C++) is able to call COM without the need for anything except the ProgID. I'm not sure how they did that; I don't think the makers included a header file and information for each class of COM objects it supports on its own.
I will try to use your imbedded shell object example.
Another noob question:
| freddie1 wrote: |
|---|
| I used Mingw 4.4 |
If case you do want to pursue the scripting language I'm talking about here is some information. The scripting language is called AutoHotkey and is made for doing easy windows automation but has lots of added other features as well.
http://ahkscript.org/docs/commands/ComObjCreate.htm - Command for creating COM objects (see example at the bottom)
http://www.autohotkey.com/board/topic/56987-com-object-reference-autohotkey-v11/page-2?&#entry362159 - a bigger InternetExplorer.Application example
https://github.com/Lexikos/AutoHotkey_L/ - the build for AutoHotkey (which is in C++), in case it might be helpful.
thank you again
However, one the things that threw me off while studying COM was that a scripting language I like to use (which is built in C++) is able to call COM without the need for anything except the ProgID. I'm not sure how they did that; I don't think the makers included a header file and information for each class of COM objects it supports on its own. |
A very basic and fundamental dichotomy one must face when dealing with utilizing COM components/objects is the distinction between making direct VTable calls on the object, such as I did above in calling pApp->SetVisible(1), and using the IDispatch OLE Automation interface. Many scripting languages such as JScript, VB Script, possibly the one you mentioned, are not able to call objects through the direct VTable interface, so the IDispatch form is used. One of the drawbacks to this is that in terms of in process dll servers it is like a hundred times slower than direct access.
Taking the example above of IExplorer.exe, using IDispatch access wouldn't make much difference in speed because the bottleneck there wouldn't be the function call itself so much as marshalling the function call across process boundaries. In your original program or the last one I posted, the compilation of that program results in an exe that essentially drives another exe, i.e., IExplorer.exe. So using direct VTable calls the calls nonetheless must be marshalled across process boundaries, which is fairly slow.
Now in that 1st version I posted, the resulting executable does not start IExplorer.exe, but rather loads the ActiveX Control ( "Shell.Explorer" ) right into its process space - its a dll that gets loaded, and can make direct VTable calls.
Now the situation with scripting languages being easier to use seemingly without the need for header files - well, that takes some explaining, and I'd recommend you study up on it if interested. But here is a whirlwind explanation. Microsoft intended COM to be a programming language agnostic object model. They wanted it to work in C, C++, Visual Basic, PowerBASIC, Auto-HotKey, whatever. One possible way of working towards that would have been to create seperate header files for each language declaring the method calls. However, they did something about a hundred times slicker than that. They created a seperate interface definition language ( IDL ) for describing the interfaces of an object, and they wrote a special compiler to compile this interface definition language into a binary form. This binary form is known as a Type Library. Here is an example of what the IDL looks like for the IWebBrowserApp Interface...
|
|
Note it looks kind of like C but not exactly. Here is what that interface looks like when actually converted to C/C++ code, as can be seen in IWebBrowser.h...
|
|
Do you see those hex numbers in the IDL, e.g., 0x0000012c for the Quit() method? Those are Dispatch IDs, and they are used in the IDispatch Interface to call the methods on the object instead of the direct function calls. The scripting languages in many cases make the translations behind the scenes so the user can manage it without having a clue as to how its really working. That's why its easy.
continued...
Last edited on
Then there's the issue of early binding verses late binding. Using 'late binding' its possible to make function calls on the object without any header file info.
Recently I posted a lot here at www.cplusplus.com where a user was attempting to automate Microsoft Excel. I'll find some of those links for you. They show how to automate Excel using the 'scripting' technique of IDispatch...
(I'll get link in a second...)
one link...
http://www.cplusplus.com/forum/windows/125996/
another more recent ...
http://www.cplusplus.com/forum/windows/164379/
At that last link andyweskin provided some good help which will work if you are using MS VC++.
Where that IWebBrowser.h file came from is that I wrote a lot of complex code to read an object's Type Library and create a C or C++ header file. If you want that code I can provide it. However, Microsoft's Visual Studio product contains the functionality to do that. My code is necessary if you are using the Mingw compiler however. I do it my way because I essentially do everything my way, and I don't care for the ugly convoluted outputs of the Microsoft products.
I have Code::Blocks 10.05 installed in XP Mode on my Win 7 x64 box. In the C:\Program Files\CodeBlocks\Mingw directory is the Mingw readme.txt file where the compiler version is mentioned. No doubt there is a compiler switch that reveals that too, but offhand I don't recall what it is. I think its 4.4 or 4.3 or somewhere around there.
On my x64 Win 7 I'm using Mingw 4.8, and I have the Code::Blocks IDE set up to produce x64 executables. I used my older Mingw 4.4 x86 compiler here for your code because I wasn't sure "Shell.Explorer" had a 64 bit version to be loaded by a 64 bit exe in my in process example above.
I'm big on writing small code. That's one reason I tend to use older compilers. That in process example above creates a 9 k executable above. Can you imagine that? A 9 K executable that uses Microsoft's Internet Explorer ActiveX Control! That's the app I used to actually post all this code.
Recently I posted a lot here at www.cplusplus.com where a user was attempting to automate Microsoft Excel. I'll find some of those links for you. They show how to automate Excel using the 'scripting' technique of IDispatch...
(I'll get link in a second...)
one link...
http://www.cplusplus.com/forum/windows/125996/
another more recent ...
http://www.cplusplus.com/forum/windows/164379/
At that last link andyweskin provided some good help which will work if you are using MS VC++.
Where that IWebBrowser.h file came from is that I wrote a lot of complex code to read an object's Type Library and create a C or C++ header file. If you want that code I can provide it. However, Microsoft's Visual Studio product contains the functionality to do that. My code is necessary if you are using the Mingw compiler however. I do it my way because I essentially do everything my way, and I don't care for the ugly convoluted outputs of the Microsoft products.
I have Code::Blocks 10.05 installed in XP Mode on my Win 7 x64 box. In the C:\Program Files\CodeBlocks\Mingw directory is the Mingw readme.txt file where the compiler version is mentioned. No doubt there is a compiler switch that reveals that too, but offhand I don't recall what it is. I think its 4.4 or 4.3 or somewhere around there.
On my x64 Win 7 I'm using Mingw 4.8, and I have the Code::Blocks IDE set up to produce x64 executables. I used my older Mingw 4.4 x86 compiler here for your code because I wasn't sure "Shell.Explorer" had a 64 bit version to be loaded by a 64 bit exe in my in process example above.
I'm big on writing small code. That's one reason I tend to use older compilers. That in process example above creates a 9 k executable above. Can you imagine that? A 9 K executable that uses Microsoft's Internet Explorer ActiveX Control! That's the app I used to actually post all this code.
Last edited on
No better way to make the distinction clear between COM and direct Vtable Access verses IDispatch access than with an example with which you are already familiar. In my last code post was this which required the IWebBrowser.h file so that the compiler could understand the pApp->SetVisible(1) call…
Here is what that program looks like using only the IDispatch part of the dual interface. Note the lack of include file IWebBrowser.h…
Using Mingw 4.4.1 I’m seeing a 7K executable on that. Not bad. If you’ve never faced this stuff before I expect its pretty intimidating. C++ programmers hate IDispatch calls. Actually, I’ve been doing this stuff for a pretty long time, and I still find it intimidating.
It can be made somewhat more palatable by wrapping the IDispatch stuff up into function calls like so…
If you are just starting this COM work and wish to continue, then two tools you should become familiar with are RegEdit.exe, which should be in your system directory, and OleView.exe, which used to be part of Microsoft’s older Visual Studio installations. Seems to me I heard or read somewhere that Microsoft wasn’t supplying OleView anymore with the newer VS versions. Shame on them if they aren’t. This is a must have for serious COM work.
|
|
Here is what that program looks like using only the IDispatch part of the dual interface. Note the lack of include file IWebBrowser.h…
|
|
Using Mingw 4.4.1 I’m seeing a 7K executable on that. Not bad. If you’ve never faced this stuff before I expect its pretty intimidating. C++ programmers hate IDispatch calls. Actually, I’ve been doing this stuff for a pretty long time, and I still find it intimidating.
It can be made somewhat more palatable by wrapping the IDispatch stuff up into function calls like so…
|
|
If you are just starting this COM work and wish to continue, then two tools you should become familiar with are RegEdit.exe, which should be in your system directory, and OleView.exe, which used to be part of Microsoft’s older Visual Studio installations. Seems to me I heard or read somewhere that Microsoft wasn’t supplying OleView anymore with the newer VS versions. Shame on them if they aren’t. This is a must have for serious COM work.
OleView is provided as part of the Windows SDK -- I can see both a x86 and x64 build of the tool in version 8.1 of the SDK.
Andy
Andy
I tried your IDispatch examples but got errors when I tried to compile them (the same errors from both).
I also tried your shell example above but also got errors
I have MinGW 4.9.2 and Orwell Dev-C++ 5.11 IDE.
I don't have any idea really of how to fix either of those. Would going to MinGW 4.4.1 make them work?
thanks
F:\C++\Dev-C++\COM test 9 IDispatch\Untitled2.o Untitled2.cpp:(.text+0xfa): undefined reference to `__imp_VariantInit' F:\C++\Dev-C++\COM test 9 IDispatch\Untitled2.o Untitled2.cpp:(.text+0x14a): undefined reference to `__imp_VariantInit' F:\C++\Dev-C++\COM test 9 IDispatch\Untitled2.o Untitled2.cpp:(.rdata$.refptr.GUID_NULL[.refptr.GUID_NULL]+0x0): undefined reference to `GUID_NULL' F:\C++\Dev-C++\COM test 9 IDispatch\collect2.exe [Error] ld returned 1 exit status 25 F:\C++\Dev-C++\COM test 9 IDispatch\Makefile.win recipe for target 'Project1.exe' failed |
I also tried your shell example above but also got errors
F:\C++\Dev-C++\Shell Example\main.cpp In function 'long int fnWndProc_OnCreate(lpWndEventArgs)': 61 49 F:\C++\Dev-C++\Shell Example\main.cpp [Error] cast from 'IUnknown*' to 'long int' loses precision [-fpermissive] 68 55 F:\C++\Dev-C++\Shell Example\main.cpp [Error] cast from 'IUnknown*' to 'long int' loses precision [-fpermissive] 71 58 F:\C++\Dev-C++\Shell Example\main.cpp [Error] cast from 'IWebBrowser*' to 'long int' loses precision [-fpermissive] F:\C++\Dev-C++\Shell Example\main.cpp In function 'long int fnWndProc_OnCommand(lpWndEventArgs)': 98 56 F:\C++\Dev-C++\Shell Example\main.cpp [Warning] cast to pointer from integer of different size [-Wint-to-pointer-cast] F:\C++\Dev-C++\Shell Example\main.cpp In function 'long int fnWndProc_OnDestroy(lpWndEventArgs)': 116 53 F:\C++\Dev-C++\Shell Example\main.cpp [Warning] cast to pointer from integer of different size [-Wint-to-pointer-cast] 119 52 F:\C++\Dev-C++\Shell Example\main.cpp [Warning] cast to pointer from integer of different size [-Wint-to-pointer-cast] 122 53 F:\C++\Dev-C++\Shell Example\main.cpp [Warning] cast to pointer from integer of different size [-Wint-to-pointer-cast] 28 F:\C++\Dev-C++\Shell Example\Makefile.win recipe for target 'main.o' failed |
I have MinGW 4.9.2 and Orwell Dev-C++ 5.11 IDE.
I don't have any idea really of how to fix either of those. Would going to MinGW 4.4.1 make them work?
thanks
Mingw 4.9 produces either x86 or x64 code depending on the switches fed into the compiler. Are you running x64? That's what those errors look like. For example, ...
cast from 'IUnknown*' to 'long int' loses precision
...sounds like an x64 8 byte pointer address being crunched into 4 bytes which I believe a long int is in x64.
In the case of my ActiveX Container example above, I specifically used the older compiler in XP Mode on my x64 box because I have MinGW 4.8 set up on my Code::Blocks installation to produce x64 binaries, and an x64 binary can't very easily load an x86 dll into its address space. And I really don't know what the situation is with "Shell.Explorer" (IE ActiveX Dll) on Win 7 installations in terms of whether there is both an x86 version for 32 bit exes and an x64 version for 64 bit exes, or whatever. I simply never cared to check. So to spare myself checking it out or researching the matter I opted to use my older 32 bit only Mingw.
If you are configured to be making x64 executables, it may solve those errors by reconfiguring to create x86 code. My remarks above relate strictly to the first code I posted where I'm using Atl and Shell.Explorer.
In terms of ...
undefined reference to `__imp_VariantInit
...that's a linker error. Are you linking against libole32.lib, liboleaut32.lib, and libuuid.lib? VariantInit() is in one of the 1st two I think.
Andy,
Thanks for the info on OleView. Don't remember how I came by that bad info. Glad to hear that's still included.
If it still won't work Firecannon, I'll try it on a Mingw 4.9 installation I have on my wife's little netbook. Oh! That's 64 bit only I just recalled. But I could compile it both ways to see if that's the issue.
If someone here wants to jump in here that has specific knowledge about the x86 verses x64 issue with "Shell.Explorer" I'd appreciate it. The other issue there is that example of mine is using Atl71.dll, or Atl80.dll, or Atl90.dll, or whatever as an ActiveX Control Container, so that would also have to exist in x64 binary form to work. And it might. I just don't know. Lot of iffs! Now maybe you see why I was so adament about producing a 32 bit executable example! Its kind of a can of worms.
cast from 'IUnknown*' to 'long int' loses precision
...sounds like an x64 8 byte pointer address being crunched into 4 bytes which I believe a long int is in x64.
In the case of my ActiveX Container example above, I specifically used the older compiler in XP Mode on my x64 box because I have MinGW 4.8 set up on my Code::Blocks installation to produce x64 binaries, and an x64 binary can't very easily load an x86 dll into its address space. And I really don't know what the situation is with "Shell.Explorer" (IE ActiveX Dll) on Win 7 installations in terms of whether there is both an x86 version for 32 bit exes and an x64 version for 64 bit exes, or whatever. I simply never cared to check. So to spare myself checking it out or researching the matter I opted to use my older 32 bit only Mingw.
If you are configured to be making x64 executables, it may solve those errors by reconfiguring to create x86 code. My remarks above relate strictly to the first code I posted where I'm using Atl and Shell.Explorer.
In terms of ...
undefined reference to `__imp_VariantInit
...that's a linker error. Are you linking against libole32.lib, liboleaut32.lib, and libuuid.lib? VariantInit() is in one of the 1st two I think.
Andy,
Thanks for the info on OleView. Don't remember how I came by that bad info. Glad to hear that's still included.
If it still won't work Firecannon, I'll try it on a Mingw 4.9 installation I have on my wife's little netbook. Oh! That's 64 bit only I just recalled. But I could compile it both ways to see if that's the issue.
If someone here wants to jump in here that has specific knowledge about the x86 verses x64 issue with "Shell.Explorer" I'd appreciate it. The other issue there is that example of mine is using Atl71.dll, or Atl80.dll, or Atl90.dll, or whatever as an ActiveX Control Container, so that would also have to exist in x64 binary form to work. And it might. I just don't know. Lot of iffs! Now maybe you see why I was so adament about producing a 32 bit executable example! Its kind of a can of worms.
| Mingw 4.9 produces either x86 or x64 code depending on the switches fed into the compiler. Are you running x64? That's what those errors look like. |
Now I'm using a x86 compiler. To be precise, I'm using TDM-GCC 4.9.2 32-bit Release.
| ...that's a linker error. Are you linking against libole32.lib, liboleaut32.lib, and libuuid.lib? VariantInit() is in one of the 1st two I think. |
However, switching to x86 gave me a bunch of errors when compiling the IDispatch example.
C:\Program Files (x86)\Dev-Cpp\MinGW64\x86_64-w64-mingw32\bin\ld.exe i386:x86-64 architecture of input file `Untitled2.o' is incompatible with i386 output F:\C++\Dev-C++\COM test 9 IDispatch\Untitled2.o Untitled2.cpp:(.text+0xc): undefined reference to `_main' F:\C++\Dev-C++\COM test 9 IDispatch\Untitled2.o Untitled2.cpp:(.text+0x86): undefined reference to `_imp_CoInitialize' F:\C++\Dev-C++\COM test 9 IDispatch\Untitled2.o Untitled2.cpp:(.text+0xca): undefined reference to `_imp_CoCreateInstance' F:\C++\Dev-C++\COM test 9 IDispatch\Untitled2.o Untitled2.cpp:(.text+0xfa): undefined reference to `_imp_VariantInit' F:\C++\Dev-C++\COM test 9 IDispatch\Untitled2.o Untitled2.cpp:(.text+0x103): undefined reference to `_imp_GetUserDefaultLCID' F:\C++\Dev-C++\COM test 9 IDispatch\Untitled2.o Untitled2.cpp:(.text+0x14a): undefined reference to `_imp_VariantInit' F:\C++\Dev-C++\COM test 9 IDispatch\Untitled2.o Untitled2.cpp:(.text+0x1a7): undefined reference to `getchar' F:\C++\Dev-C++\COM test 9 IDispatch\Untitled2.o Untitled2.cpp:(.text+0x1d3): undefined reference to `_imp_CoUninitialize' F:\C++\Dev-C++\COM test 9 IDispatch\Untitled2.o Untitled2.cpp:(.text+0x1e8): undefined reference to `getchar' F:\C++\Dev-C++\COM test 9 IDispatch\Untitled2.o Untitled2.cpp:(.text$_Z6printfPKcz[_Z6printfPKcz]+0x32): undefined reference to `_mingw_vprintf' F:\C++\Dev-C++\COM test 9 IDispatch\Untitled2.o Untitled2.cpp:(.rdata$.refptr.GUID_NULL[.refptr.GUID_NULL]+0x0): undefined reference to `GUID_NULL' C:\Program Files (x86)\Dev-Cpp\MinGW64\x86_64-w64-mingw32\lib32\libmingw32.a(lib32_libmingw32_a-crt0_c.o) In function `main': 18 C:\crossdev\src\mingw-w64-v3-git\mingw-w64-crt\crt\crt0_c.c undefined reference to `WinMain@16' F:\C++\Dev-C++\COM test 9 IDispatch\collect2.exe [Error] ld returned 1 exit status 25 F:\C++\Dev-C++\COM test 9 IDispatch\Makefile.win recipe for target 'Project1.exe' failed |
For more specifics, according to Dev-C++, there are no commands (flags) for the compiler, and the commands for the linker are
-static-libgcc -lole32 -loleaut32 -luuidthank you for your patience
Been working on it Firecannon. And thinking about it. Actually, that Shell.Explorer in process example is quite old and from long before I started working with 64 bit. Its absolutely solid 32 bit code though. I'll talk more about that later, as that's the one I'm most interested in seeing if I can get it working as 64 bit.
But right now you seem most interested in the IDispatch example, so I'll discuss that. I think you may be having difficulties with linking against the correct versions of the libs for the architecture you are using. It can get pretty confusing. Especially when using an IDE. Fact is, I have less trouble with it when compiling from the command line than when using an IDE, because when using the command line there is just a symbol or two difference between x86 compiles and x64, and when you feed in the proper symbol or two the compiler automatically links against the correct libs, which are in completely different locations for x86 and x64.
For example, here is what my mingw (4.8 I think) directory structure looks like...
C:\TDM-GCC-64
C:\TDM-GCC-64\x86_64-w64-mingw32
C:\TDM-GCC-64\x86_64-w64-mingw32\lib <<< 64 bit libs
C:\TDM-GCC-64\x86_64-w64-mingw32\lib32 <<< 32 bit libs
So however you do the setup using your IDE, you have to be really, really careful you're selecting the libs from the correct directory. You do realize that they are all duplicated don't you? For example, there are two libole32.a files - one 32 bit and one 64 bit. They are in different directories, naturally, because you can't have two files of the same name in the same directory.
But it can even get more confusing than that. Let me tell you about a situation I run into when using the Code::Blocks IDE. And I think some of this is going on with you too about that very top error message you just posted. The IDE gets obj files mixed up between 32 bit and 64 bit. Here's what happens to me. As you know, I have several mingw installations on my various computers of various vintages. I have found to my dismay that I can't copy a folder containing the various files that are part of a build from an x86 installation to an x64 installation. For one thing, as I said above, the lib paths are different. For another, any *.obj files in a folder from the other architecture are used by the architecture you've just changed to. So the IDE is mixing up x86 objs with x64 objs. It's pretty miserable.
To make a long story short, what I have found it best to do when moving projects between x86 and x64 is delete everything in the folder relating to the IDE and just leave the source code files, i.e., the *.cpp, *.h files, etc. Then copy the folder to another location where the IDE relating to that architecture will look for it. I don't know if that sounds bizarre to you or not. All I can say is that it works for me and that's what I do.
By the way, Microsoft's Visual Studio deals better with this, in that it creates unbelievably complicated directory schemes to handle it. I'm giving the devil his due here because I'm not a big fan of Microsoft programming products. I'm just being honest about it. I really think some of this stuff I've just mentioned is going on with your compilation/linkage problems, as I've seen all that stuff before in sorting out my woes. You need the patience of Job for this stuff.
I'll discuss some other issues tomorrow that I think I've resolved concerning converting my ActiveX Control Example to x64. I'm pretty sure I can do it.
But right now you seem most interested in the IDispatch example, so I'll discuss that. I think you may be having difficulties with linking against the correct versions of the libs for the architecture you are using. It can get pretty confusing. Especially when using an IDE. Fact is, I have less trouble with it when compiling from the command line than when using an IDE, because when using the command line there is just a symbol or two difference between x86 compiles and x64, and when you feed in the proper symbol or two the compiler automatically links against the correct libs, which are in completely different locations for x86 and x64.
For example, here is what my mingw (4.8 I think) directory structure looks like...
C:\TDM-GCC-64
C:\TDM-GCC-64\x86_64-w64-mingw32
C:\TDM-GCC-64\x86_64-w64-mingw32\lib <<< 64 bit libs
C:\TDM-GCC-64\x86_64-w64-mingw32\lib32 <<< 32 bit libs
So however you do the setup using your IDE, you have to be really, really careful you're selecting the libs from the correct directory. You do realize that they are all duplicated don't you? For example, there are two libole32.a files - one 32 bit and one 64 bit. They are in different directories, naturally, because you can't have two files of the same name in the same directory.
But it can even get more confusing than that. Let me tell you about a situation I run into when using the Code::Blocks IDE. And I think some of this is going on with you too about that very top error message you just posted. The IDE gets obj files mixed up between 32 bit and 64 bit. Here's what happens to me. As you know, I have several mingw installations on my various computers of various vintages. I have found to my dismay that I can't copy a folder containing the various files that are part of a build from an x86 installation to an x64 installation. For one thing, as I said above, the lib paths are different. For another, any *.obj files in a folder from the other architecture are used by the architecture you've just changed to. So the IDE is mixing up x86 objs with x64 objs. It's pretty miserable.
To make a long story short, what I have found it best to do when moving projects between x86 and x64 is delete everything in the folder relating to the IDE and just leave the source code files, i.e., the *.cpp, *.h files, etc. Then copy the folder to another location where the IDE relating to that architecture will look for it. I don't know if that sounds bizarre to you or not. All I can say is that it works for me and that's what I do.
By the way, Microsoft's Visual Studio deals better with this, in that it creates unbelievably complicated directory schemes to handle it. I'm giving the devil his due here because I'm not a big fan of Microsoft programming products. I'm just being honest about it. I really think some of this stuff I've just mentioned is going on with your compilation/linkage problems, as I've seen all that stuff before in sorting out my woes. You need the patience of Job for this stuff.
I'll discuss some other issues tomorrow that I think I've resolved concerning converting my ActiveX Control Example to x64. I'm pretty sure I can do it.
That IDispatch code I posted is absolutely solid Firecannon. Keep working with it fighting the lib thing and I'm sure you'll get it.
You know, this business of posting code here is tricky due to all the various IDEs, compilers, and such that folks use. For myself, I mostly work in 64 bit now, but I test just about everything I do with x86 and x64 with both mingw and MS VC++ - also x86 and x64. Drives me batty some times.
You know, this business of posting code here is tricky due to all the various IDEs, compilers, and such that folks use. For myself, I mostly work in 64 bit now, but I test just about everything I do with x86 and x64 with both mingw and MS VC++ - also x86 and x64. Drives me batty some times.
I got it working!
In the list of my directories for my libraries, there was an invalid path to a folder. That was it. It was a crazy lucky guess.
No, I didn't.
Update: Now the shell.explorer example compiles. It says can't load alt71.dll when it runs, but that's to be expected. I tried to reproduce the error by adding the invalid path to the library directory list, but it still compiled. Puzzling... I guess the moral of the story is that IDEs are not to be trusted.
I've also gone through and made sure that all the rest of the paths to directories are valid.
For the record, programming is new to me. I'm used to the scripting language I talked about earlier (AutoHotkey), and that's the only other programming language I really know, and its how I got started into programming. In AutoHotkey, the problems I have are completely different from the ones here. Most of them are runtime errors, since it is interpreted. This is new experience, so I can't see how many more problems in compilation there's going to be as much as will in say, 3 years from now (assuming I do lots of C++). That's why I keep wondering if there's some secret to getting programs to compile.
thanks
In the list of my directories for my libraries, there was an invalid path to a folder. That was it. It was a crazy lucky guess.
| You do realize that they are all duplicated don't you? |
Update: Now the shell.explorer example compiles. It says can't load alt71.dll when it runs, but that's to be expected. I tried to reproduce the error by adding the invalid path to the library directory list, but it still compiled. Puzzling... I guess the moral of the story is that IDEs are not to be trusted.
I've also gone through and made sure that all the rest of the paths to directories are valid.
For the record, programming is new to me. I'm used to the scripting language I talked about earlier (AutoHotkey), and that's the only other programming language I really know, and its how I got started into programming. In AutoHotkey, the problems I have are completely different from the ones here. Most of them are runtime errors, since it is interpreted. This is new experience, so I can't see how many more problems in compilation there's going to be as much as will in say, 3 years from now (assuming I do lots of C++). That's why I keep wondering if there's some secret to getting programs to compile.
thanks