>> OK, so here's a question: I think I understand how to load a DLL and 
>> call the functions it exports, but... how do you find out what functions 
>> a DLL exports?
> 
>   That's what headers are for.

Or documentation, for that matter.

OTOH, if you don't have either of these...

Post a reply to this message

On Mon, 12 Oct 2009 15:11:47 +0200, Invisible <voi### [at] devnull> wrote:
> I found several other DLLs which apparently export... absolutely
> nothing. (Why do they exist then?)

A DLL need not export its functions by name.



> Some DLLs for highly complex tasks appear to export a tiny amount of  
> stuff, so clearly there's something I'm not seeing.

A COM-based DLL need only expose a single function, one that returns a COM  
interface pointer. The complex stuff is then reached through that  
interface.



> And then there are huge, huge numbers of DLLs on the system which aren't  
> registered anywhere.

Not all DLLs are COM servers.



> And who says that staring into a screen full of code numbers is a good  
> way to learn stuff? ;-)

I don’t even see the code anymore; all I see now is blonde, brunette,  
redhead...



-- 
FE

Post a reply to this message

>> I found several other DLLs which apparently export... absolutely
>> nothing. (Why do they exist then?)
> 
> 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...)

>> Some DLLs for highly complex tasks appear to export a tiny amount of 
>> stuff, so clearly there's something I'm not seeing.
> 
> A COM-based DLL need only expose a single function, one that returns a 
> COM interface pointer. The complex stuff is then reached through that 
> interface.

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.

> Not all DLLs are COM servers.

Indeed.

And even the ones that are don't actually need to be registered; just 
the ones that lots of people might want to find by ClassID. You can 
access a COM server by its file path instead...

> I don’t even see the code anymore; all I see now is blonde, brunette, 
> redhead...

WIN!

Post a reply to this message

On Mon, 12 Oct 2009 16:09:14 +0200, Invisible <voi### [at] devnull> wrote:
>>  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).



> 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



-- 
FE

Post a reply to this message

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

Invisible <voi### [at] devnull> wrote:
> Or documentation, for that matter.

> OTOH, if you don't have either of these...

  If someone releases a dll but not headers or documentation for it, you'll
probably better avoid using that dll. You can't expect for its interface to
not to change in the future.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   If someone releases a dll but not headers or documentation for it, you'll
> probably better avoid using that dll. You can't expect for its interface to
> not to change in the future.

I'm thinking more about writing plugins, but where I don't have any 
documentation that says what functions it's supposed to export. If you 
can find a working plugin, you can find out what it exports.

Of course, with no clue what parameters each such function takes, or 
what the hell it's supposed to do, it's still pretty hopeless I guess...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I'm thinking more about writing plugins, but where I don't have any 
> documentation that says what functions it's supposed to export.

  Do you really want to write a plugin for a completely undocumented system?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Do you really want to write a plugin for a completely undocumented system?

Well, in the case of VST, it's not that it's undocumented, just that you 
have to pay money for the documentation...

...but yeah, I guess it's pretty much a non-starter.

Post a reply to this message

On Mon, 12 Oct 2009 17:09:06 +0200, Invisible <voi### [at] devnull> wrote:
> 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...

An "interface" is a list of function pointers. In C and C++ the layout of  
an interface is typically described in a header file.



-- 
FE

Post a reply to this message