WinApi+Asm Multithreading?

[qWord]

hi,

My function call from C looks something like that

asmFunction(float * pointer1, float * pointer2, ...);

you may try to assemble the following test-code and link the object file to you c program (console prog.):

Code Select Expand

include \masm32\include\masm32rt.inc

;// asmFunction(float *paf,int n);
asmFunction proto c paf: ptr REAL4,n:DWORD
.code
asmFunction proc c uses edi esi ebx paf: ptr REAL4,n:DWORD
LOCAL tmp:REAL4

mov esi,paf
xor ebx,ebx
.while ebx < n
fld REAL4 ptr [esi+ebx*4]
fmul FP4(100.0)
fstp tmp
print real4$(tmp),13,10
lea ebx,[ebx+1]
.endw

ret

asmFunction endp
end

[dedndave]

the address should be something like 00400000 +

[qWord]

the address should be something like 00400000 +

only if his system does not use ASLR. (or linker option: /FIXED)

[dedndave]

well - it won't be 1   :bg

i am guessing it may be a calling convention problem
like - his C compiler is trying to use C calling convention and the ASM code is trying to use StdCall
i don't play with C enough to know the ins and outs

[qWord]

you can call a C function as sdtcall and vice versa - the problem occurs after/while the function return: for C function the caller must  clean up the stack, stdcall-function must clean up the stack themself.

[tomson123]

Dave, get your firearms ready, because you will probably want to kill me for what I am about to say right now...
I found the solution (qWord has given me a clue with his code), and turns out the problem would be solved in 1 minute if I only sent you my code with externs for c/asm...

I have been passing my pointers as DWORD's since that's what my collegue did and it worked perfectly well for him (although he didn't use FPU...) Turns out that I should've taken a little time to think on my own and passed them as float * instead of just assuming that he was right. Thank you both for all your help, if not for you I would probably still be stuck :) I wish I could buy you a beer... :P

Still, i am happy that all of this happened, because i learned a lot from it. I hope I didn't waste too much of your time :/

[dedndave]

glad you fixed it   :U
in ASM, it would be proper to type that as an LPVOID (which is an alias for DWORD)

Code Select Expand

MyProcedure PROTO :LPVOID,:LPVOID

MyProcedure PROC USES ESI EDI srcArrayPointer:LPVOID,dstArrayPointer:LPVOID

        mov     esi,srcArrayPointer
        mov     edi,dstArrayPointer
        INVOKE  MessageBox,NULL,uhex$(esi),uhex$(edi),MB_OK
        mov     esi,[esi]
        mov     edi,[edi]
        INVOKE  MessageBox,NULL,uhex$(esi),uhex$(edi),MB_OK
        ret

MyProcedure ENDP

[tomson123]

Funny that, just recently I was searching for any information about LPVOID because of your suggestion concerning HeapAlloc, and until now, no one could give a percise answer ;)

[dedndave]

LP means it's a long pointer
LPVOID means it is a long pointer to some unknown data tpe
i dunno - there may be an LPREAL4 type   :P

the ASM code wasn't the problem, anyways

[tomson123]

Now that I think about it, LPVOID's name describes it's function pretty well :) Thank you again for all your help :)