Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

External DLLs and proper calling 1

Status
Not open for further replies.

CamaroLT

Programmer
Dec 16, 2002
159
CA
Can anyone direct me to a way I can see what kind of interfaces I have access to in any DLL on my machine?

Specifically, I want to hook into MOO.DLL (You IRC goers will know what I mean) to get some system stats of the machine. Problem is, I can't find ANY documentation on how to link into this, or any other DLL that I don't have the calling functions and procedures.

What I'd like is a running application that will show me a list of interfaces (Like version, cpuinfo, and uptime, and anything else thats available within moo.dll) and the type of parameters it takes, if any. I realize I won't get exact names for parameters, but, if I can find out if its a string, pchar, or int type, that'd be just fine.

The other option is, if anyone can show me how to get Delphi 7 to link to at least what I've mentioned above, I'd greatly appreciate it too. :)

You can find the MOO.DLL file at: [URL unfurl="true"]http://www.hm2k.org/projects/moo[/url]

Thanks in advance. :)

-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job
 
You can get the functions names with DEPENDS.EXE (ir comes with the SDK and some MS bundles) or with any dumper program (TDUMP.EXE comes with Delphi).

If the DLL is written in C++ and use mangled names, TDUMP will tell you what the params are. Try "TDUMP borlndmm.dll" in the Delphi Bin folder to see what I'm talking about: some exported functions will come with params, some others not.

Without mangled names, no tool can tell you what the params are.

In your case, mIRC have a well defined standard for add-on dlls (check the mIRC help); with the interface info (the $dll calls) and the mIRC doc you should be able to crack it open.

buho (A).

PS: have some info on the mIRC dll spec.
 
Addendum:

Mangled names are not SO usefull anyway. Lets say a dll function is receiving a pointer to a record: the dumper will tell you the parameter is a pointer, but you have no idea about the data structure (and no tool can guess it).

buho (A).
 
The information you gave me is invaluable. But I still seem to be having an issue calling the routine. The application keeps bombing out. Heres what I have:

Code:
function cpuinfo(mwnd:HWND; awnd:HWND; var Data:PChar; var Params:PChar; Show:boolean; NoPause:boolean):integer; external 'moo.dll'

And the function that calls this:

Code:
procedure TForm1.Button1Click(Sender: TObject);
var
  Res:integer;
  Ret:pchar;
  Parm:pchar;
begin
  Ret:='';
  parm:='';
  Res:=cpuinfo(0, 0, Ret, Parm, false, false);
end;

I did have the first two params of of cpuinfo to application.handle and form1.handle to no avail. :/

I've read through the mIRC help, and it stats that Ret and Parm are supposed to pass this info to the DLL. Kinda confused on that. The example:

Code:
$dll($mircdir $+ stat\dll\moo.dll,cpuinfo,_)

Returns what I expected:

Mirc Reply said:
2-Intel Pentium 4, 2798MHz, 512KB (0% Load)

What am I missing? The compiler runs an exception stating: Project raised exception class eAccessViolation with message 'Access violation at {address}. Read address {address}. I get that I'm reading something wrong, or I have the structure setup incorrectly in the defining function. I've tried passing in different things for ret and parm, all with different faults.

Thanks for more help!

-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job
 
Try:

Code:
function cpuinfo(mwnd:HWND; awnd:HWND; var Data:PChar; 
                 var Params:PChar; Show:boolean;
                 NoPause:boolean):integer; [COLOR=red][b]stdcall;[/b][/color]
                 external 'moo.dll'

buho (A)
 
Same kinda error crops up. *shakes his head*

I've been a developer for over 20 years, and have never really had the desire to link into other peoples code. I like to reinvent the wheel, so to speak, or use my own code that I've conjured up over the years. This error is QUITE frustrating!

I have linked into other DLLs, but they were all written under Delphi, and they all worked fine. Not sure why this ones being a pain. :(

-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job
 
You are managing the PChars wrong.

A PChar is a pointer, you need to assign space to it.

Code:
------------------
Pure PASCAL way:
------------------
var
  Ret  : PChar;
  Parm : PChar;
begin
  GetMem(Ret, 1024);   // Assign space
  GetMem(Parm, 1024);  // Assign space 
  Res := cpuinfo(0, 0, Ret, Parm, false, false);
  ...
  FreeMem(Ret);
  FreeMem(Parm);
end;

------------------
Delphi way:
------------------
var
  Ret  : AnsiString;
  Parm : AnsiString;
begin
  SetLength(Ret, 1024);
  SetLength(Parm, 1024);
  Res := cpuinfo(0, 0, @Ret[1], @Parm[1], false, false);
  ...
end;

buho (A).

 
Checking it. Not working.

Give me some time.

buho (A).
 
Ok, got it working.

The external declaration was still wrong. Use this one:

Code:
function cpuinfo(mwnd : HWND;    awnd   : HWND;
                 Data : PChar;   Params : PChar; 
                 Show : boolean; NoPause: boolean) : integer;
                 [COLOR=red]stdcall[/color]; external 'moo.dll'

{The PChar params are NOT var}

The Delphi approach works well; the PASCAL approach needs some polishing:

Code:
------------------
Pure PASCAL way:
------------------
  var
    Ret  : PChar;
    Parm : PChar;
    Res  : integer;
  begin
    GetMem(Ret, 1024);          // Assign space
    GetMem(Parm, 1024);         // Assign space
    FillChar(Ret^, 1024, 0);    // DO NOT use Ret := #0;
    FillChar(Parm^, 1024, 0);   // DO NOT use Ret := #0;
    Res := cpuinfo(0, 0, Ret, Parm, false, false);
    ...
    FreeMem(Ret);
    FreeMem(Parm);
  end;

buho (A).
 
Execellent. Managed to get the Delphi way working after you had mentioned that pchars aren't VAR.

Thanks for the time and effort. I do appreciate it. This drove me absolutly bonkers!

-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job
 
give the man a star then...



-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!
 
He's gone the extra mile...so I concur with whosrdaddy!!!

Clive
Runner_1Revised.gif

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"To err is human, but to really foul things up you need a computer." (Paul Ehrlich)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get the best answers from this forum see: faq102-5096
 
Done. :)

-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top