Hi,
Using a disassembler, i am able to see the exported functions in a dll.

My question is, how do i make a call to those functions and compile my

code if i do not have the header? I am guessing i can use LoadLibrarry
and GetProcAddress, but how do i specify the parameters to the
function?

HMODULE hLib = LoadLibrary(_T("some.dll"));
FARPROC fp = GetProcAddress( hLib, _T("someFunction"));

Also, can anyone tell me what the type of the parameters might be for
the disassembled dll function below? i am guessing the parameters are
"var_4" and "arg_4"?


EXPORT GPSFind
GPSFind

var_4= -4
arg_4= 4

STR LR, [SP,#var_4]!
MOV LR, R0
LDR R3, [LR]
MOV R0, #0
CMP R3, #0x14
BNE loc_100021B0

* farseer:
GetProcAddress does not exist in Unicode version, use

FARPROC f = GetProcAddress( hLib, "someFunction" )

or your code will fail to compile with _UNICODE defined.


You need to know the expected parameters. When you do, just call the
function via the pointer. fp( arg1, arg2, arg3 ).


Ugh, what kind of disassembler is this?

Anyway, Google, and if that doesn't help, contact the supplier of the DLL.


--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

"farseer" <farseer@optonline.net> skrev i en meddelelse
news:1149314925.084713.85340@y43g2000cwc.googlegro ups.com...
Does not help you very much unless you know assembler.
And in this case there is no need to disassemble the dll
to retrive the information you need.

Create a header file your self, or use loadlibrary.
http://msdn.microsoft.com/library/de...dlldynamic.asp

Like any other. funcname(parms, ...);

It don't look like masm32 code, and it looks rather incomplete.
disassember is for pro people. and you dont need it at all to do
what you want. both borland and microsoft includes tools with
the development enviroment that can help you.

With visual studio you can see the exports of a dll from console
e.g.
dumpbin /exports mydll.dll

dumpbin can also create a definition file, wich can be used to
create a import library (.lib) for the dll.
Microsoft has some paper on msdn about this, you should be
able to find it with google.

//eric

it is ARM Assembly...I am trying to figure out what the parameters
might be to the function call.

Alf P. Steinbach wrote:

it is ARM Assembly...I am trying to figure out what the parameters
might be to the function call.

Alf P. Steinbach wrote:

i had shown the truncated and concise view of the function, thinking
enough of was there to help determine only the put parameter, but here
is the compelete listing of that function:

..text:10006304 ; Exported entry 16. GPSFind
..text:10006304
..text:10006304 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E
¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
..text:10006304
..text:10006304
..text:10006304 EXPORT GPSFind
..text:10006304 GPSFind ; DATA XREF:
..pdata:1000B1C8o
..text:10006304
..text:10006304 var_4 = -4
..text:10006304 arg_4 = 4
..text:10006304
..text:10006304 STR LR, [SP,#var_4]!
..text:10006308 MOV LR, R0
..text:1000630C LDR R3, [LR]
..text:10006310 MOV R0, #0
..text:10006314 CMP R3, #0x14
..text:10006318 BNE loc_10006330
..text:1000631C LDR R1, =unk_1000A220
..text:10006320 MOV R2, #0x14
..text:10006324 MOV R0, LR
..text:10006328 BL memcpy
..text:1000632C MOV R0, #1
..text:10006330
..text:10006330 loc_10006330 ; CODE XREF:
GPSFind+14j
..text:10006330 LDR LR, [SP],#arg_4
..text:10006334 BX LR
..text:10006334 ; End of function GPSFind
..text:10006334
..text:10006334 ;
---------------------------------------------------------------------------
..text:10006338 off_10006338 DCD unk_1000A220 ; DATA XREF:
GPSFind+18r


Alf P. Steinbach wrote:

attempting to use dumpbin from the cmd line results in "This
application has failed to start because mspdb80.dll was not founnd.
Re-installing the application may fix this problem". I ran this from
the \Microsoft Visual Studio\VC\bin directory. I've had issues like
this and i think when the command prompt is launched, it does not pick
up all the paths specified in enviroment PATH variable for some reason.

Eric Jensen wrote:

additionally, i am not sure if dumpbin would work on a windows mobile
or dll?

farseer wrote:

* farseer:
I've never done any ARM programming, let alone ARM assembly, but I can
/guess/:


Guess: Symbolic names assigned by the disassembler, probably standard,
probably means using one 4-byte local argument (var_4, guessing 4 bytes
because I'm guessing it's offset -4), with stack pointer adjustemnt arg_4.


Guess: storing the return address (content of register LR) on the stack
at SP-relative offset var_4, and adjusting stack pointer.


Guess: copying reg R0 to reg LR. Don't know what R0 is used for in ARM.
It could be some special purpose, or it could be an argument. I'd
guess R0 holds a pointer argument.


Guess: loading R3 with contents of what the pointer argument points to,
let's call that c.


Guess: comparing c to 20.

Guess: if BNE means Branch Not Equal, then presumably this means: if c
!= 20, just return without doing anything. I'd guess this means the
argument is a pointer to a structure that's 20 bytes, and has a 4-byte
length field c at the start, that must be initialized to 20. Or else.


Guess: doing some copying... It would not be surprising if that copying
is to the 20-byte structure mentioned above.



Guess: loading return address off stack + adjust stack pointer.


Guess: perform return by jumping to the return address.


--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Thank you Alf, i really appreciate your help. I have some follow up
questions

in SP offset by 4 bytes? Where is this actually storing the value. I
ask because it seems like it is storing it in LR, but right after that
it is moving R0 to LR...isn't that overwriting what was just stored in
LR?
What is the difference in STR, MOV and LDR anyway? they all seem to
copy from one register or memory location to another.

So you believe R0 may contain a pointer to the input parameter and
var_4/arg_4 are simply local arguements/contants? I think this is
right as i've read that r0 - r4 are used to pass the first 4 parameters
to a function in Arm Assembly. R0 is also used to return the value
from a function, so i am assuming that is why we see it being set to 0,
then to 1 before returning (presumeably to indicate failure/success).

If RO is the return, i can assume the functions return will be an int
or something like that. However, i am still not clear what the input
parameter structure is. I guess here i simply have to allocate some
memory and pass a pointer to that memory block in, correct? But a
pointer to what? these lines still has me confused:
.text:10006318 BNE loc_10006330
...
...
.text:10006338 off_10006338 DCD unk_1000A220 ; DATA
XREF:

So i am including the code from that address:

..data:1000A220 unk_1000A220 DCB 0x14 ; DATA XREF:
..textff_10006338 o
..data:1000A221 DCB 0
..data:1000A222 DCB 0
..data:1000A223 DCB 0
..data:1000A224 DCB 6
..data:1000A225 DCB 0
..data:1000A226 DCB 0
..data:1000A227 DCB 0
..data:1000A228 DCD off_1000A1D0
..data:1000A22C DCB 4
..data:1000A22D DCB 0
..data:1000A22E DCB 0
..data:1000A22F DCB 0
..data:1000A230 DCD sub_10006250
..data:1000A234 ALIGN 8
..data:1000A238 unk_1000A238 DCB 0xAA ; ¬ ; DATA XREF:
..data:1000A20C o

..data:1000A1D0 off_1000A1D0 DCD unk_1000A210 ; DATA XREF:
..data:1000A228 o
..data:1000A1D4 DCD unk_1000A200
..data:1000A1D8 DCD unk_1000A1F0
..data:1000A1DC DCD unk_1000A1E0
..data:1000A1E0 unk_1000A1E0 DCB 0 ; DATA XREF:
..data:1000A1DC o
..data:1000A1E1 DCB 0
..data:1000A1E2 DCB 0
..data:1000A1E3 DCB 0
..data:1000A1E4 DCB 0xF1 ; ±
..data:1000A1E5 DCB 0
..data:1000A1E6 DCB 0
..data:1000A1E7 DCB 0
..data:1000A1E8 DCB 0xF2 ; =
..data:1000A1E9 DCB 0
..data:1000A1EA DCB 0
..data:1000A1EB DCB 0
..data:1000A1EC DCD unk_1000A1CC
..data:1000A1F0 unk_1000A1F0 DCB 0 ; DATA XREF:
..data:1000A1D8 o
..data:1000A1F1 DCB 0x14
..data:1000A1F2 DCB 0xE1 ; ß
..data:1000A1F3 DCB 0
..data:1000A1F4 DCB 0x77 ; w
..data:1000A1F5 DCB 0x14
..data:1000A1F6 DCB 0xE1 ; ß
..data:1000A1F7 DCB 0
..data:1000A1F8 DCB 0x77 ; w
..data:1000A1F9 DCB 0x14
..data:1000A1FA DCB 0xE1 ; ß
..data:1000A1FB DCB 0
..data:1000A1FC DCD unk_1000A1C8
..data:1000A200 unk_1000A200 DCB 0 ; DATA XREF:
..data:1000A1D4 o
..data:1000A201 DCB 0xE0 ; a
..data:1000A202 DCB 0
..data:1000A203 DCB 0
..data:1000A204 DCB 0x10
..data:1000A205 DCB 0xE0 ; a
..data:1000A206 DCB 0
..data:1000A207 DCB 0
..data:1000A208 DCB 0x7E ; ~
..data:1000A209 DCB 0xE0 ; a
..data:1000A20A DCB 0
..data:1000A20B DCB 0
..data:1000A20C DCD unk_1000A238
..data:1000A210 unk_1000A210 DCB 0 ; DATA XREF:
..dataff_1000A1D0 o
..data:1000A211 DCB 0
..data:1000A212 DCB 0
..data:1000A213 DCB 0
..data:1000A214 DCB 1
..data:1000A215 DCB 0
..data:1000A216 DCB 0
..data:1000A217 DCB 0
..data:1000A218 DCB 0x84 ; ä
..data:1000A219 DCB 0
..data:1000A21A DCB 0
..data:1000A21B DCB 0
..data:1000A21C DCD unk_1000A2A8
..data:1000A220 unk_1000A220 DCB 0x14 ; DATA XREF:
..textff_10006338 o








Alf P. Steinbach wrote:

reading up a bit on ARM assembly, i answered my first question. LR is
stored at memory SP - 4, i think.

farseer wrote:

* farseer:
struct Something { unsigned nBytes; .... }; // Total 20 bytes.
// The last 4 bytes are possibly just filler, i.e. garbage.

extern bool GPSFind( Something* pResult );

int main()
{
Something result = {sizeof(Something)};
assert( result.nBytes == 20 );
if( GPSFind( &result ) )
{
// have data
}
}


If you're trying to use the DLL you need the appropriate header or at
least some documentation. Check out a VB driver (if you have one),
Google, contact the supplier. OTOH., if you're trying to investigate
some undocumented functionality, then I'm afraid you're on your own.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

"farseer" <farseer@optonline.net> skrev i en meddelelse
news:1149351896.709017.16850@f6g2000cwb.googlegrou ps.com...
When using VS from command line, it mostly required to run the batch file
vcvars32.bat or what ever its named. Or you can start->programs->visual
studio->tools->VC Commandline

That might help, if it dont re-installation might be a good idea, or simply
find that dll

//eric

"farseer" <farseer@optonline.net> wrote in message
news:1149352031.034842.12630@j55g2000cwa.googlegro ups.com...
dumpbin works with coff/pe format, borland has tools for omf/pe so does
masm32.
If its coff/pe it does - I have never worked with windows mobile
applications, but my guess it that it should work.

If you can store the dll on the www, so i can download it - I might be able
to retrive the information you need.

//eric

Thanks...this worked as far as being able to call the function:

typedef int ( *FUNCPTR )( int * );

HMODULE hLib = LoadLibrary(_T("some.dll"));
FUNCPTR fp = (FUNCPTR) GetProcAddress( hLib, _T("GPSFind"));
int val = 20;
int ret = fp( &val );

if val is set to something other than 20, the function returns a 0. If
it is set to 20, it returns a 1. This seems to confirm to the return
values of the assembly function. The only problem that in the case
where val = 20, while it returns with a 1, a split second later i get a
memory access violation. that memcpy is probably the culprit...

Alf P. Steinbach wrote: