NoFriLLz's guide to using C runtime libraries

Every assembly programmer gets to a point in his/her life when they realise that there has to be another way to display or retrieve numbers in a readable form, or a string. GetDlgItemInt and SetDlgItemInt can do the job alright, as can wsprintf(), but the dialog functions require the use of a dialog box, and wsprintf can't convert a string back into a useable number, in fact the only reason it exists is to provide unicode capabilities to the existing sprintf() currently in use in everyday C programming. To top it all off, none of them have any floating-point support. This is where we can either spend our next 200 hours of programming time making algos to convert hex to string, string to hex, float to string, string to float, signed int to string, string to signed int etc etc etc. If this is for you, then I wish you luck, this tutorial is not for you. However there is another option for those of us willing to bite the bullet and resort to using the C runtime libraries.

The main problem with this option is the way the C libraries mess around with ESP. After calling a C function, you may find that any RET commands crash the program, sending it to some offset in a galaxy far, far away. This is what kept me from using the functions, but I have found the answer, so simple I’m surprised I didn’t think of it at first. All that is necessary is increasing ESP by the number of bytes pushed onto the stack to call the function, so if I called sprintf(offset buffer, “%lu”,1234) and ended up pushing 3 dwords onto the stack, it would be a case of adding 3*4=12 to esp, so the call would be followed by a MOV esp,12. It could be possible to make a macro for masm32 to tidy everything up, if anybody does please email it to me in the suggestion box on the main page and I would be eternally grateful.

Just a couple of finer points, some C commands have an underscore as a suffix, such as ftol (_ftol). To make sure your command names are right, it would pay to check out the export table of crtdll (I use Napalm’s Export Viewer). Another thing is that it seems that the floating point manipulating functions all use REAL8 variables, so that requires pushing the variable in two halves.

Hope this is helpful
NoFriLLz