>>>  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