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

In comp.os.ms-windows.programmer.win32 R.Wieser <[email protected]> wrote:
> I've been "at it" since DOS 3.3 .  My first "hello world" program was a few 
> hundred bytes.  My thanwhile C program was 30 KByte (and that in the time of 
> 720 KByte floppies!).  At that time my choice was clear.

Let me guess: you were using QuickC?

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.

It's funny now to see C 5.1 in the DOS 4 source code release and get to
see the experience that "real" developers had.  Binaries are still much
larger in C than assembly due to forcing each function call to a fixed
calling convention and having a tiny number of registers, so every call
is a pile of avoidable pushes and pops.  But C 5.1 binaries aren't
awful.

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

The "plain" OS/2 version is currently 13.6Kb, "plain" DOS version is
16.0Kb, and the "bound" DOS+OS/2 one is 22.8Kb.  The original assembly
HotDIR I'm emulating was ~4.5Kb.  But still, it's a "real" program in
much less than 30Kb.  Mine has to do more to support long file names,
different terminal widths, and it has more memory to support a larger
file count.

> :-) I did the same in my 16-bit time, and just updated it when the 32-bit 
> time arrived.   I think I still have the multiplication and division 
> routines for numbers of an arbitrary byte length.

Very cool.  My long division one is still deficient - a 32 bit CPU can
natively divide a 64 bit number by a 32 bit number, which is generally
sufficient for any program I want to write, but completely inexpressible
in C, and I never bothered to make a true 64 bit divide.

> 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.

- M