Re: wsprintf I64 - how to get it to include a plus sign ? Wrap-up

malxau,

>> My thanwhile C program was 30 KByte ... At that time my choice
> was clear.
>
> Let me guess: you were using QuickC?

That name doesn't ring a bell, but than again, it was a long time ago.

> QuickC always seemed shockingly bad, since it didn't have
> any optimizer and the linker would include any code from the
> compilation unit, so binaries ended up being both huge and
> full of unused, unreachable code.

At the time I assumed it was the printf function that was that big, but yes, 
later on I surmised it perhaps loaded /everything/ from that library, used 
or not.

> Here's what I've been doing, for reference:
> http://www.malsmith.net/blog/os2-family-zdir/

Looks good - even though I'm not a supporter of colored or otherwise 
touched-up output. It tends to distract me of what I am actually after.

> But still, it's a "real" program in much less than 30Kb.

Compilers have certainly evolved, become better at not including un-used 
parts of static libraries (besides the whole optimizing I mean).

> a 32 bit CPU can natively divide a 64 bit number by a 32 bit
> number,

I first thought so too, but realized it can't.  Its limitation is that the 
result must fit into 32 bits. If it doesn't (like dividing 1<< 32 by 1) the 
division will fail.

> My long division one is still deficient

You can do a 64-bit division with the aid of two 32-bit divisions :

;In: edx:eax = 64 bit dividend
; ecx = 32bit divisor
;Out: edx:eax = 64 bit quotient.
; ecx = reminder

 push eax
 mov eax, edx
 xor edx, edx
 div ecx
 xchg eax,[esp]
 div ecx
 xchg edx,[esp]
 pop ecx

And no, thats not my code. Just something I picked up somewhere (I don't 
like the usage of [esp] that way, I'd rather put it into a function and use 
local variable(s) (iow, referencing EBP).  Wastefull, I know :-) ).

>> You know that there are a number of RtlLargeInteger* functions
>> available in NTDLL ?  And as that one gets loaded as part of
>> KERNEL32 ...
>
> Heh I saw them but didn't use them.  You're right though, the
> assembly could just implement Visual C++'s funky calling convention,
> move everything around and make an OS function call.

Most all NTDLL functions are STDCALL.   No need to do such a conversion.

My assembler has made me lazy in that regard : all I have to do is to change 
the calling-convention indicator, and it will change the order the arguments 
are pushed in* and the way they are removed from the stack (by the caller or 
the function).

* when I provide the arguments on the same line as the function call 
ofcourse.

Regards,
Rudy Wieser