 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> 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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
