Azu wrote:

revolution wrote:

To what end? It is only one function anyway. No need to invent a whole new calling convention for it.

They felt the need to make "a whole new calling convention" for this "one little function", so they may as well do it right..

No, they went with standard cdecl.

f0dder wrote:

Azu wrote:

revolution wrote:

To what end? It is only one function anyway. No need to invent a whole new calling convention for it.

They felt the need to make "a whole new calling convention" for this "one little function", so they may as well do it right..

No, they went with standard cdecl.

..which only exists for this one function.

Azu wrote:

f0dder wrote:

Azu wrote:

revolution wrote:

To what end? It is only one function anyway. No need to invent a whole new calling convention for it.

They felt the need to make "a whole new calling convention" for this "one little function", so they may as well do it right..

No, they went with standard cdecl.

..which only exists for this one function.

Get your head out of the bushes and look around

BTW why does this forum keep forgetting to notify me when a reply is posted? I have to keep re-checking the box over and over.. =/

I did. Couldn't find any other functions in Windows that don't clean up after themselves. Since you obviously know more then me, why don't you just save both of us time by naming them (if there really are any others)?

Couldn't find any other functions in Windows that don't clean up after themselves. Since you obviously know more then me, why don't you just save both of us time by naming them (if there really are any others)?

Quote:

BTW why does this forum keep forgetting to notify me when a reply is posted? I have to keep re-checking the box over and over.. =/

Go to your profile and enable "Always notify me of replies:"

Quote:

I did. Couldn't find any other functions in Windows that don't clean up after themselves. Since you obviously know more then me, why don't you just save both of us time by naming them (if there really are any others)?

All the functions in CRTDLL.DLL and MSVCRT.DLL for example. Microsoft haven't invented nothing, they used an already existing calling convention called cdecl because that one already handled varargs correctly. They even borrowed wsprintf from sprintf of C language (also available in the aforementioned DLLs), which turns out to be where cdecl comes from.

Azu wrote:

Couldn't find any other functions in Windows that don't clean up after themselves. Since you obviously know more then me, why don't you just save both of us time by naming them (if there really are any others)?

There is more to this world than just Windows.

You didn't really believe that MS invented CDECL just for one function? Did you?

Yes [I did think MS invented CDECL just for wsprintf].

And if not.. then all the more reason for it to be done right.

Azu wrote:

Yes [I think this is the only Windows function that acts this way].

In that case you need to read more and make less assumptions about things. Google is your friend.

Azu wrote:

And if not.. then all the more reason for it to be done right.

Only you are saying it is not "done right". Others have tried to explain to you why it can't be stdcall, but you keep coming back with the same thing saying that is it "wrong". It is not wrong, it was done because it was necessary. Anyhow, it is not worth so much argument, one function only, with an alternate stdcall version. It is a special case but

you don't have to use it if you don't want to. Ignore it, forget about it, don't think about it, don't use it, pretend it doesn't exist, there, problem solved.

Aren't those DLLs from the C++ redistributable package thing?

But you said you thought cdecl was invented by MS for this one function. It would seem reasonable to search google for cdecl history, not for more Windows functions. That way your assumption could have be quickly confirmed or refuted (in this case refuted).

One function is vararg, the other is not. vararg is not supported by stdcall, so the function can't be stdcall, it falls outside the stdcall standard. You can't implement vararg in stdcall, not possible with HLL code, can't be done. Tricky asm code could do it, but then that is not HLL anymore, so MS won't do it, not sensible to do, not portable to other systems.

As for the non-vararg version: no problem, falls within stdcall standard, easy in HLL. Nothing tricky required. But now YOU have to allocate memory and things to pass the arguments to the function, makes it not so convenient for you.

You code won't work. edi is the return address and you overwrite your code with stosb. The 'ret' jumps to somewhere not where you expect.

I think you clearly don't understand HOW an HLL works. Like I said, and it is not a mistake, HLL using a stdcall interface cannot implement a vararg function. Once you understand that you will see WHY wsprintf cannot be stdcall.

wsprintf(buff, person.showAge ? "Person %u works at %s, and is %u years old" : "Person %u works at %s. Age can't be disclosed",\
         person.id, person.department, person.age);    

.
.
.

fmtTab   dd fmtNoAge, fmtAge

fmtAge   db "Person %u works at %s, and is %u years old", 0
fmtNoAge db "Person %u works at %s. Age can't be disclosed", 0

.
.
.

      cmp     [person.printAge], 0
      setne   cl
      movzx   ecx, cl
      mov     ecx, [fmtTab+ecx*4]

      ccall   wsprintf, buff, ecx, [person.id], [person.department], [person.age]

.
.
.    

Dunno but they do. Try this

mov edi,esp
push 1
call Sleep
sub edi,esp
jnz Sleepy
int3
Sleepy:
push -1
call Sleep

It will crash every time. If the normal Windows functions didn't pop the args off, it would just sleep forever.

No, they went with standard cdecl.