|
![](/i/fill.gif) |
>>> A DLL need not export its functions by name.
>>
>> But wouldn't that mean that there's no way to reach its functions?
>> (Unless you happen to know the exact base address - which will change
>> in the next version of the DLL...)
>
> You can export functions by ordinal (i.e. number).
And, indeed, a few DLLs show unamed functions exported (i.e., a number,
but no name).
But some DLLs appear to export *nothing*. Not even unamed functions. I
suppose they could contain "resouces", but...
>> I was under the (mistaken?) impression that COM methods are exported
>> as DLL functions, and the COM system runs on top of the underlying DLL
>> infrastructure.
>
> http://msdn.microsoft.com/en-us/library/ms694363(VS.85).aspx
> http://msdn.microsoft.com/en-us/library/ms682305(VS.85).aspx
> http://msdn.microsoft.com/en-us/library/ms686615(VS.85).aspx
That explains what some of the function calls are, but still doesn't
really say how it *works* internally.
Still, I guess you don't really need to know. I'm just curious about
such things.
More puzzling: CoGetClassObject() allows you to get hold of any class by
its ClassID. CoCreateInstance() creates any object given a ClassID and
an InterfaceID. This gives you a pointer to the object's interface. But
I cannot find any way of actually calling methods. If you have a DLL,
you can do GetProcAddress() to look up a function and call it. But if
you have an interface pointer, there doesn't seem to be any way to call
methods of the interface...
Post a reply to this message
|
![](/i/fill.gif) |