Can someone plz Explain it from the tutorial 15  "ThreadProc PROC USES ecx Param:DWORD"?
1. What is USES here ?
2 Why ecx ?
3.Param:DWORD ?
There is not much on proc declaration in Iczelion`s Tutorials.
Everything else is clear.
Thank You
Posted on 2005-11-17 12:12:32 by G`HOST
1) uses just help you preserve the register. MASM will add push ecx and pop ecx for you.
2) I don't know why he would want to preserve ecx, personally I don't think there is a need.
3) callback functions for CreateThread are defined like that, so that CreateThread can pass a parameter to the threadproc.
Posted on 2005-11-17 12:41:27 by roticv
I'd like to add 2 cents: As you may have read in the tutorials, every procedure needs to preserve ebx, esi, edi, and some other registers. "USES ebx" adds "push ebx" (at the beginning) and "pop ebx" at the end. This way the EBX register is being preserved. That's what "USES" is for. You can write "USES ebx esi edi" and this way all of them will be safely preserved (but of course, for "optimization" purposes, we preserve only those registers, which we use). I don't know why He's preserving ECX, since there's no need (except some really special cases, like fastcall convention) to preserve it.

ThreadProc is declared this way by Windows. Windows calls your Thread proc and passes you the specified params (actually only 1 param, called 'lparameter'). You can set the value of this param when you call CreateThread. This is for YOUR application's purposes, so if you pass '78' on CreateThread, then Windows will call your ThreadProc with parameter '78'. Usually programers use this value to tell the thread what it's supposed to do (it usually points to some structure with detailed job information).

Good Luck and good coding.
Posted on 2005-11-17 13:46:31 by ti_mo_n
It should normally be:


ThreadProc proc uses ebx esi edi lParam:LPARAM


The "uses" part may or may not be needed.
Posted on 2005-11-17 13:49:15 by QvasiModo
Only add registers to "uses" if you're modifying them - otherwise they're implicitly preserved.
Posted on 2005-11-18 00:25:17 by f0dder
...waste of time, only assume that registers you used before API (or your function) won't be the same after its execution ... and live in peace... with no concern about "USES"
Posted on 2005-12-21 16:17:57 by ramguru
huh? This way your proc will modify ebx,esi, or edi registers and result in a crash sooner or later.
Posted on 2005-12-21 17:58:37 by ti_mo_n
Never, if you know what you're doing :)
Posted on 2005-12-21 18:02:27 by ramguru
People who read Iczelion's Tutorials usually try to learn what they're doing, so it's better to leave the advanced 'register preservation' topics for later ;)
Posted on 2005-12-21 19:28:56 by ti_mo_n
ramguru, if you modify any of ebx,esi,edi in a threadproc without preserving their values ("uses" or manual push/pop), you will crash - that's just how life is.
Posted on 2005-12-22 03:09:10 by f0dder
I must admit I rarely use parallel stuff with assembler (rather with java, c++, btw recently I had task to integrate ThreadProc in my C++ class...and it wasn't a piece of cake :) ) f0dder no offence you're wrong. Be it callback be it whatever function there is nothing wrong not to preserve registers (I've tested it  8) )
Posted on 2005-12-22 03:46:57 by ramguru

I must admit I rarely use parallel stuff with assembler (rather with java, c++, btw recently I had task to integrate ThreadProc in my C++ class...and it wasn't a piece of cake :) ) f0der no offence you're wrong. Be it callback be it whatever function there is nothing wrong not to preserve registers (I've tested it  8) )


Have you tested this on all combinations of past, present and future windows versions and service packs? It sounds like you haven't :)
Posted on 2005-12-22 04:31:11 by f0dder
If I say "YES", would you believe me :) While we are here and now I see only a necessity to check my code with my OS box...if it works let it be...
Posted on 2005-12-22 04:47:40 by ramguru
ThreadProcs *might* work on current and past windows versions without register preservation, but you shouldn't depend on this. In the past, people have depended on register preservation not being necessary in callbacks, and that have bought them nothing but programs that crash on NT.
Posted on 2005-12-22 08:31:24 by f0dder
Some callbacks are wrapped to force register prevention, and to compensate for wrong calling conventions. This behavior is not dependable, nor implemented in all callbacks (or all versions of Windows). Besides that, sticking to the standards is good for future compatibility -- for example you might want your programs to work on Windows clones (if one is ever finished ;) ) or Windows emulators for other platforms (like wine for Linux).
Posted on 2005-12-22 10:40:12 by QvasiModo