I have only the .dll file (no header files).
how can I explore it and find out what are it's exported functions/classes.
I need it because I have a .dll file that controls a device and I want
to find out what are it's methods so I can maybe write a program in VB
or C++ that use it.
the platform I am talking about is win2000. |
Request for Question Clarification by
mathtalk-ga
on
17 Jul 2004 07:50 PDT
Hi, sharon_de_salmon-ga:
The approach for a "mere" Win32 DLL would be different from a DLL that
supports COM (ActiveX) functionality, and different again for one that
supports .Net functionality.
Given the limited price offered for this Question, it would be helpful
if you could be more specific about the type of DLL, if it is known.
regards, mathtalk-ga
|
Clarification of Question by
sharon_de_salmon-ga
on
17 Jul 2004 11:03 PDT
I assume it is win32 dll.
it does not end with .ocx
I tried to add reference to it in VB and got message "cant add
reference to the specified file".
I think it is from 1998 so i don't think it is .NET dll.
win32 answer will be fine.
|
Clarification of Question by
sharon_de_salmon-ga
on
17 Jul 2004 11:35 PDT
I menaged to open the file with "PE explorer"
maybe I can determine from there if it is ActiveX, win32 or .NET .
anyway it doesn't say what parameters the functions get and what type they return.
|
Clarification of Question by
sharon_de_salmon-ga
on
18 Jul 2004 14:03 PDT
here is how the function look after dissassembler:
function1@4
push ebp
mov ebp,esp
mov edx,[ebp+08h]
mov eax,[Lxxxxxx]
call SUB_xxxxx
pop ebp
retn 0004h
anothe function that do not get arguments:
function2@0
mov eax,[Lxxxxxx]
call SUB_yyyyyy
ret
I think it is the __stdcall calling convention.
I tried to call it from VB but with no success.
I need a simple code example how to call it from VC++ if that is what needed
if you think I suppose to be able to call it from VB I want to know how
|
Request for Question Clarification by
mathtalk-ga
on
18 Jul 2004 17:30 PDT
The reason for distributing *.LIB files to developers along with
*.DLLs is precisely because there is no reliable means to determine
the calling arguments expected by the entry points of a Win32 DLL. If
it were intended to make the unauthorized use of a DLL especially
difficult, the DLL might be stripped so that entry points would only
be located by "ordinal" information, without even (fairly cryptic)
linker names as guideposts.
Absent a .LIB file for a vanilla Win32 DLL, I can only foresee
frustration in trying to master its functions. Of course you may be
able (starting from the properties that it exposes in Windows
Explorer, e.g. name, company, version, etc.) to search out substantial
assistance for this particular DLL on the Web, assuming that you are
following in the footsteps of others.
A DLL that implements COM interfaces is a much more tractable
exercise. In particular there would need to be a provision for the
DLL to have the GUIDs of its supported interfaces stored in the
Windows registry.
If you dynamically load the DLL, and if it is a COM component, it is
quite likely that it will contain "self-registration" code that will
go into effect.
I would try this (any DLL may be loaded from a VC or VB program, even
if none of its entry points are known), and then retry adding a
reference to the DLL in a VB project.
If you feel especially sneaky, you might take a snapshot of your
registry beforehand, so that you can delta out any differences that
are attributable to loading the DLL.
regards, mathtalk-ga
|
