|
Checking the first 4 bytes of the location pointed to by the interface pointer returned by CoCreateInstance() function might give you the address of vtable (I have not tried it). But why do you want to do this?
|
|
|
|
|
I need to call all the functions of COM Interface exposed methods at runtime.
For this I need to access vtable of COM coclass where all addresses of exposed methods of its interfaces are stored.
e.g Say
Math is COM object
and its exposed interface is "Operations"
and "Sum" is the method of this interface.
I need the address of "Sum", so that I can call it on run time. Just like you use loadlibrary for DLL and adter passing functional address, using GetProcAddress we can call function at runtime.
Here in COM same I need to do. But here no LoadLibrary , and no GetProcAddress. Just we need to iterate vtable and one by one we'll get the addresses of methods and we'll call these methods on run time.
Any Suggestions?
|
|
|
|
|
| Take a look at this article[^] which explains the basics of the COM vtable and pointers, it should help you understand how to get what you want. txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
|
Even if you get the function pointers this way, how to get the function signature (arguments and types)? You may have to use type library to get more details about the interface functions and supported interfaces.
|
|
|
|
|
a coclass will always have pointers to virtual tables (of all interfaces it implements) as its instance data. In CreateObject() function, coclass is instantiated, type casted to the interface ptr which we demands through CoCreaInstance and returned. so the returned ptr will be pointing to the virtual table of that interface. This virtual table ptr is used later in function calls to locate the correct implemented functions. Pls correct me if iam wrong..
|
|
|
|
|
Can we then be able to take its size as well?
I mean how many no of entries(addresses) that vtable would then have?
|
|
|
|
|
size of the returned interface ptr will be size of a pointer (4 bytes as any pointer). so in order to call the functions using that ptr, u need to have their declarations. Also for all com interfaces, first few entries in vtable will point to the implementation of functions from the base interfaces, such as QueryInterface, AddRef ... of IUnknown. So think whether ur plan is going to work our or not..
|
|
|
|
|
Here is a link to very extensive work & code concerning this, that is, dumping VTables and VPtrs...
http://www.jose.it-berater.org/smfforum/index.php?board=362.0
|
|
|
|
|
| You're going about things the wrong way. Getting the v-table's address is no problem. Doing something useful with it will be. All it is an array of function pointers. The pointers have no type information associated with them. It sounds like you should look into type libraries (see the ITypeLib[^] interface) or automation[^]. Steve
|
|
|
|
|
I have got the addresses of functions from vtable but in little wiered manner.
like typedef void (*FN)(void)
FN pFn=0
int* dwPtr= (int*)pSomeInterface;
pFn=(FN)*((int*)*(&dwPtr[Count])+1);//will give the address of QueryInterface
pFn=(FN)*((int*)*(&dwPtr[Count])+2);//will give the address of AddRef
pFn=(FN)*((int*)*(&dwPtr[Count])+3);say release
pFn=(FN)*((int*)*(&dwPtr[Count])+6);//and finally my method Sum
but this is all hardcoded stuff and little wiered.
I in a search of some generic usefull method to lookup their addresses and then I NEED their NAME as well so that which ever at runtime I give the name as function my app should traverse and call only that method
|
|
|
|
|
typedef void (*FN)(void)
using FN, how are you going to call those methods like QueryInterface, AddRef.. as they take various number of arguments? u may be able to call without errors, bt result will be unexpected. without having specific info about the functions in interface, u won't be able to proceed..
|
|
|
|
|
Yeah true.!!
but _asm patch helped me out in this regard.
_asm
{
push argument_1
push argument_2
call proc ;function address
}
Here suppose i have given all info (parameters or arguments) at run time for NOW(Which I have passed it on runtime console).
For future(might be later) I will load every thing from TLB's. e.g (How to know that QueryInterface taking 3 params of different type? This is ITypeLibe which provides information from TLB of that Component which I can query from registry to load specific TLB and give me specific function signature and types).
Hence I got all params and function names as well(Which I can decipher from signature working with RE's(regular expression)).
But Now I need to call the function, which would have specific address(NOT KNOWN) arguments(parameters) which I have collected from TLB, and name as well. How that address corresponds to that function name to which I am going to call.
For this I need to traverse vtable which is holding functional addresses, LASTLY need to correspond function address with NAME of that function. This is I dont know. How? More over one function with the same name may appear in vtable(Overloading case). In that case we need to distinguish function names w.r.t their addresses. How to tackle ?
|
|
|
|
|
I have some code in Visual Prolog compiled into a DLL.
I am hoping to build a GUI using C# that would interact with the DLL.
Visual Prolog supports COM.
Is COM the way to make my C# GUI interact with the Prolog DLL, or are there other ways?
|
|
|
|
|
Hello,
Can we use reflections to invoke the exposed methods of certain interfaces of COM Object?
Here we will be able to show all exposed methods of COM DLL or COM exe and and on run time, we can execute all of those methods, by passing parameters.
This is already done for Win32DLL here but any idea about COM?
Regards
Muhammad Usman Khalil
|
|
|
|
|
Afraid I don't understand exactly what it is you are asking, can you clarify or show what you are trying?
|
|
|
|
|
Can we call COM exposed interface METHODS at runtime one by one. This can be achieved in case of WIN32 DLL's using reflections. But SAME job need to be done with COM Dll or COM EXE. We'll be able to view all exposed methods of that COM DLL or COM EXE on client(say on MFC GUI) and ony by one we need to call all of those methods by just clicking "invoke or Execute".(Remember I need to call unmanaged code, purely written in VC++ unmanaged code) . That would not be .NET assembly.
e.g
I had COM DLL
-----------
it has mehods namely int Sum(int,x,int y);
Client should show in its combo the methods signature i.e Sum(int x,int y)
and when I click at invoke it should give me result say (2 OR any thing that would be sum of those x & y params).
this is done here but this is strictly for Win32 DLL's not for COM DLL or COM EXE's
Execute a function in any Win32 DLL - Reflection in Win32 DLL?[^]
|
|
|
|
|
| I think you can get the information you need from OLEViewer, which is distributed with the Windows SDK, in the tools section. txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
OLEView just facilitate to view information of interfaces, co-classes and other types and it might take these info's from TLB.
I need to call any exposed methods of COM object at RUN TIME using reflections just we can do the same job in Win32 DLL's.
|
|
|
|
|
| I don't think you can do this in COM or in WIN32 DLL as neither of them support reflection in the .NET sense. I know it is possible to figure out some aspects of functions from decorated function names, but if the names are undecorated (i.e. C style) then such information is not available. txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
|
| That may be true, but it is not reflection in the proper sense. Microsoft does not offer reflection in Win32 dll libraries, so anything you rely on may change in the future. .NET reflection is an official part of the .NET architecture and will be supported by Microsoft. txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
Yeah that's true.
That's not exactly reflection underway.It's effort to make the result similar what reflection facilitates programmer. So I need to get same behavior which's being done in that (Executing function in Win32 DLL by clicking "Execute"). Can we load COM DLL or COM EXE dynamically(in case of DLL its LoadLibrary) and get its functions/methods (in DLL by GetProcAddress.
One way which I sought out is to iterate over vtable which'll contain addresses of COM interface's virtual methods. But that technique only applicable with virtual functions(as they only go in vtable) .
What about simple(non-virtual) methods of COM interfaces.
Where we can get addresses of those methods(non-virtual).
|
|
|
|
|
glitteringsound wrote: Where we can get addresses of those methods(non-virtual).
Sorry, no idea; also I don't believe COM was ever designed with that in mind. My only suggestion is to try it and see what results you get.txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
Any body else that can help in this regard?
I think we need to lookup .data or .code sections of COM EXE or COM DLL then to lookup exaxct addresses of plain COM interfaces methods.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
