From Newsgroup: alt.windows7.general

Hello all,

OS XPsp3 :

I'm using wsprintfA (user32) with the format-string "%010I64d" to output
a provided 64-bit number. Which works.

The thing is that I would like to see a "+" sign for the positive numbers,
and I can't seem to do it. No matter where I put a "+" symbol in the format string the output breaks.

Question : is there a way to get wsprintfA to include a plus sign when displaying decimal numbers, and if so what is it ?

Remark : I've also tried sprintf (crtdll), but it doesn't seem to understand either "%I64d" or "%lld".

Remark #2 : wsprintfA doesn't understand "%+d" either. :-|

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Wed, 7 Jan 2026 09:35:45 +0100, R.Wieser wrote:

Hello all,

OS XPsp3 :

I'm using wsprintfA (user32) with the format-string "%010I64d" to output
a provided 64-bit number. Which works.

The thing is that I would like to see a "+" sign for the positive numbers, and I can't seem to do it. No matter where I put a "+" symbol in the format string the output breaks.

Question : is there a way to get wsprintfA to include a plus sign when displaying decimal numbers, and if so what is it ?

Remark : I've also tried sprintf (crtdll), but it doesn't seem to understand either "%I64d" or "%lld".

Remark #2 : wsprintfA doesn't understand "%+d" either. :-|

Regards,
Rudy Wieser

`+` is never part of format control string in the first place. It'd just be treated as literal text.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

JJ,

`+` is never part of format control string in the first place.
It'd just be treated as literal text.

When using wsprintfA I presume. Yes, it looks like it.

Any idea how to have sprintf (crtdll) print a 64-bit decimal value ?

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

JJ,

[quote=me]

Any idea how to have sprintf (crtdll) print a 64-bit decimal value ?

Scratch that question.

I don't know what I did wrong the first time I tried, but just now sprintf using "%lld" does exactly what it should do. And so does "%+010lld"

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

JJ,

[quote=me]

Scratch that question.

Scratch that. I'd forgotten that I had changed my test value, and caused it to fit into 4 bytes. Changing it back to 5E+10 the displayed result showed again a truncated 32-bit result

Strange that "%lld" was not rejected as unrecognised though ...

So, the question still stands :

Any idea how to have sprintf (crtdll) print a 64-bit decimal value ?

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Wed, 1/7/2026 3:14 PM, R.Wieser wrote:

JJ,

[quote=me]

Scratch that question.

Scratch that. I'd forgotten that I had changed my test value, and caused it to fit into 4 bytes. Changing it back to 5E+10 the displayed result showed again a truncated 32-bit result

Strange that "%lld" was not rejected as unrecognised though ...

So, the question still stands :

Any idea how to have sprintf (crtdll) print a 64-bit decimal value ?

Regards,
Rudy Wieser

I couldn't get my INT64_T to work, and I suspect I need to install
more packages in my mingw64 thingy. Adding the header files made no difference.

/* #include <stdint.h> */
/* #include <inttypes.h> */
#include <stdio.h>

/* gcc -std=c99 -o wide.exe wide.c */
/* gcc -m64 -std=c99 -o wide.exe wide.c */

int main( void )
{
wchar_t buf[100];
/* int64_t i; */
long long int i;

i = 5000000000000 ;

int len = swprintf( buf, 100, L"%s %+lld %s", L"Pack my box with ", i, L" liquor jugs" );
printf( "Generated %d characters\n\n", len );

wprintf(L"%ls\n\n", buf);
}

UCRT64 ~
$ ./wide
Generated 45 characters

Pack my box with +5000000000000 liquor jugs


UCRT64 ~

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Paul,

Generated 45 characters

Pack my box with +5000000000000 liquor jugs

Hmmm.... It works for you, but not for me. Did you use XP or some other, later version ?

By the way, quite the box you have there. :-)

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Thu, 1/8/2026 2:00 AM, R.Wieser wrote:

Paul,

Generated 45 characters

Pack my box with +5000000000000 liquor jugs

Hmmm.... It works for you, but not for me. Did you use XP or some other, later version ?

By the way, quite the box you have there. :-)

Regards,
Rudy Wieser

The routine you were using, was supposed to be a "legacy"
version with no floating point printout capability.
The "w" stands for "wombat" rather than "wide". That's what
a Google was telling me. So I switched to another print
variant that a couple of posts suggested would be
a successor to it.

I did my compiling in a mingw64 variant, because I wasn't sure whether
the original mingw had "c99".

If I could have copy/pasted any text examples using hex strings,
to flesh out the wide characters, I would have. But nothing
presented itself that I could copy.

The leading "+" as a sign indicator [ %+lld ], seems to work. Running
the program with a negative number, prints out a sign too.

$ ./wide
Generated 45 characters

Pack my box with -5000000000000 liquor jugs

*******

Using "history" in the terminal, it looks like the first sub-package
I populated was this one.

pacman -S mingw-w64-ucrt-x86_64-gcc

pacman -Ss gcc

So I added a couple more. These are in a way, cross compilers by
naming convention, but doing x86-to-x86 or something.

pacman -S mingw64/mingw-w64-x86_64-gcc
pacman -S mingw32/mingw-w64-i686-gcc

MINGW32 ~
$ gcc -m64 -std=c99 -o wide.exe wide.c
cc1.exe: sorry, unimplemented: 64-bit mode not compiled in

MINGW32 ~
$ gcc -m32 -std=c99 -o wide.exe wide.c

$ ./wide
Generated 18 characters

P -5000000000000

And then it doesn't work right.

MINGW64 ~
$ gcc -m64 -std=c99 -o wide.exe wide.c

MINGW64 ~
$ ./wide
Generated 18 characters

P -5000000000000

Nope. and gcc -m32 does not link there.

So whatever UCRT does, seems to work.

*******

If I take it over to the original MINGW, then only
one flavor would be supported.

gcc -std=c99 -o wide.exe wide.c

16 | int len = swprintf( buf, 100, L"%s %+lld %s", L"Pack my box with ", i, L" liquor jugs" );
| ^~~~~~~~
| snwprintf

Fixing that, gives

$ ./wide
Generated 45 characters

Pack my box with -5000000000000 liquor jugs

And the final program is:

/* #include <stdint.h> */
/* #include <inttypes.h> */
#include <stdio.h>

/* gcc -std=c99 -o wide.exe wide.c */

int main( void )
{
wchar_t buf[100];
/* int64_t i; */
long long int i;

i = -5000000000000 ;

int len = snwprintf( buf, 100, L"%s %+lld %s", L"Pack my box with ", i, L" liquor jugs" );
printf( "Generated %d characters\n\n", len );

wprintf(L"%ls\n\n", buf);
}

Paul








Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Paul,

The "w" stands for "wombat" rather than "wide".

I always wondered what that 'w" in "wsprintf" stood for. Not "wide", as
there where "A" and "W" postfix variants.

Its "wombat" you say ? I would have liked to read the story behind that,
but just now googling for it didn't get me any hits. :-|

So I switched to another print variant that a couple of posts suggested
would be a successor to it.

You made me remember something : NTDLL also has a version of sprintf, but I always assumed that the wsprintf one in USER32.DLL would be using it. It looks like it doesn't though.

So, I have two DLL functions with the same name. :-(

With some carefully re-ordering of my includes I got the program so far as
to use the NTDLL version of sprintf, instead of the CRTDLL one, which
accepts the "%+010I64d" format string and displays the value as I needed it
: +50000000000.

iow : thanks for making me remind that NTDLL function again. :-)

I'm currently re-researching how I can, in my sourcefile, call a function outof a specific DLL, but didn't find anything when I first tried some time ago. Oh well. I can always create libary and include files in which all function names are prefixed with the name of the DLL.

... now I think of it, thats not a bad idea at all. :-)

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general


I just did a few tests with CRTDLL sprintf, NTDDL sprintf and USER32
wsprintf, and I must say I did not extpect all three to behave differently - both what format strings they accepted, as well as what they returned when
it wasn't.

... or how much they sometimes ignored of the format string. :-|

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general


+ + + + + + + + + + + + + + + + + + + + + + + + + +
rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa
EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA
Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie
Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii
Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii
EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE
Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic
EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4
EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4







--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 10.01.2026 01:06, Emoji User wrote:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa
EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA
Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie
Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii
Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii
EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE
Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic
EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4
EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4

Content-Transfer-Encoding: 8bit

LOL

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 10.01.2026 04:43, Schugo wrote:

On 10.01.2026 01:06, Emoji User wrote:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa >> EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA
Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie
Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii
Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii
EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE
Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic
EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4
EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4

Content-Transfer-Encoding: 8bit

LOL

err..
Content-Type: text/plain;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 10.01.2026 04:46, Schugo wrote:

On 10.01.2026 04:43, Schugo wrote:

On 10.01.2026 01:06, Emoji User wrote:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa >>> EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA
Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie
Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii
Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii
EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE
Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic
EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4
EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4

Content-Transfer-Encoding: 8bit

LOL

err..
Content-Type: text/plain;

this should work better:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 10.01.2026 01:06, Emoji User wrote:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
|o+orCa |o+orCa |o+orCa |o+orCa |o+orCa |o+orCa |o+orCa |o+orCa |o+orCa |o+orCa |o+orCa |o+orCa |o+orCa |o+orCa |o+orCa |o+orCa |o+orCa |o+orCa |o+orCa
|#++-i++ |#++-i++ |#++-i++ |#++-i++ |#++-i++ |#++-i++ |#++-i++ |#++-i++ |#++-i++ |#++-i++ |#++-i++ |#++-i++ |#++-i++ |#++-i++ |#++-i++ |#++-i++ |#++-i++ |#++-i++ |#++-i++
|#++-i+a |#++-i+a |#++-i+a |#++-i+a |#++-i+a |#++-i+a |#++-i+a |#++-i+a |#++-i+a |#++-i+a |#++-i+a |#++-i+a |#++-i+a |#++-i+a |#++-i+a |#++-i+a |#++-i+a |#++-i+a |#++-i+a |#++-i+a
|#++-i+A |#++-i+A |#++-i+A |#++-i+A |#++-i+A |#++-i+A |#++-i+A |#++-i+A |#++-i+A |#++-i+A |#++-i+A |#++-i+A |#++-i+A |#++-i+A |#++-i+A |#++-i+A |#++-i+A |#++-i+A |#++-i+A |#++-i+A
|#++-irC| |#++-irC| |#++-irC| |#++-irC| |#++-irC| |#++-irC| |#++-irC| |#++-irC| |#++-irC| |#++-irC| |#++-irC| |#++-irC| |#++-irC| |#++-irC| |#++-irC| |#++-irC| |#++-irC| |#++-irC| |#++-irC| |#++-irC|
|#++-i-E |#++-i-E |#++-i-E |#++-i-E |#++-i-E |#++-i-E |#++-i-E |#++-i-E |#++-i-E |#++-i-E |#++-i-E |#++-i-E |#++-i-E |#++-i-E |#++-i-E |#++-i-E |#++-i-E |#++-i-E |#++-i-E |#++-i-E
|#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi |#++-irCi
|#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4
|#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4 |#++-orCy|ore4-i|#++rCY-4

EfiCEfai EfiCEfai EfiCEfai

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Emoji User schrieb einmal:

+ + + + + + + + + + + + + + + + + + + + + + + + + +

Da hast du UTF-8 zu setzen vergessen.

+ + + + + + + + + + + + + + + + + + + + + + + + + + rLarLarLarLarLarLarLarLarLarLarLarLarLarLarLarLarLarLarLa EfiAEfiAEfiAEfiAEfiAEfiAEfiAEfiAEfiAEfiAEfiAEfiAEfiAEfiAEfiAEfiAEfiAEfiAEfiA EfieEfieEfieEfieEfieEfieEfieEfieEfieEfieEfieEfieEfieEfieEfieEfieEfieEfieEfieEfie
EfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfii
EfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfiiEfii
EfiEEfiEEfiEEfiEEfiEEfiEEfiEEfiEEfiEEfiEEfiEEfiEEfiEEfiEEfiEEfiEEfiEEfiEEfiEEfiE
EficEficEficEficEficEficEficEficEficEficEficEficEficEficEficEficEficEficEficEficEfic
EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4EfoarCiEfo4

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Nym Mailer wrote in alt.comp.os.windows-xp,alt.windows7.general,de.test:

Da hast du UTF-8 zu setzen vergessen.

Dass ich zum Erbfeind |+berlaufe, hei|ft ja nicht, dass ich meine
Muttersprache vergesserCa Beruhigt mich doch mal.

Hat sich was an der Grammatik.., der grammatikalischen Leitkultur
oder er Akzeptanzschwelle bei rCa so Duden und Zeuch. Ups. Verb
vergessen: ge|nndert?

Zusammengesetzte Zeiten etc.

Verwirrt,

Michael
f'up de.test
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Sat, 10 Jan 2026 04:46:12 +0100, Schugo wrote:

On 10.01.2026 04:43, Schugo wrote:

On 10.01.2026 01:06, Emoji User wrote:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa rLa >>> EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA EfiA
Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie Efie
Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii
Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii Efii
EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE EfiE
Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic Efic
EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4
EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4 EfoarCiEfo4

Content-Transfer-Encoding: 8bit

LOL

err..
Content-Type: text/plain;

Bad usenet client?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

In comp.os.ms-windows.programmer.win32 R.Wieser <address@is.invalid> wrote:

I just did a few tests with CRTDLL sprintf, NTDDL sprintf and USER32 wsprintf, and I must say I did not extpect all three to behave differently -

Are you really using CRTDLL, not MSVCRT?

CRTDLL is the version from 1993, NT 3.1. The compiler at that time did
not support 64 bit integers - that came later with Visual C++ 2.0 and MSVCRT20.DLL. So I'm not surprised that CRTDLL wouldn't recognize these
format strings.

The reason for keeping CRTDLL.DLL today is to provide compatibility with programs written to expect its semantics.

(Ever wonder why we have LARGE_INTEGER? Yeah.)

- M
--- Synchronet 3.21e-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

malxau,

Are you really using CRTDLL, not MSVCRT?

Yep, I am.

CRTDLL is the version from 1993, NT 3.1. The compiler at that
time did not support 64 bit integers.

But for some reason or another they only support 64-bit floats, not 32-bit ones.

Also, my version has a timestamp of september 2001. Young enough to be
aware of the existance of 64-bit integers.

that came later with Visual C++ 2.0 and MSVCRT20.DLL.

Those are specific programming-language related DLLs. I normally do not bother to even look at those. But it seems I got three versions of that one on my machine.

... I might even take a peek at them.

So I'm not surprised that CRTDLL wouldn't recognize these
format strings.

I'm surprised (not really) that CRTDLL was never upgraded to support larger numbers (and smaller floats, see above).

For the record : I'm an Assembly programmer. :-)

Regards,
Rudy Wieser


--- Synchronet 3.21e-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

In comp.os.ms-windows.programmer.win32 R.Wieser <address@is.invalid> wrote:

Also, my version has a timestamp of september 2001. Young enough to be aware of the existance of 64-bit integers.

These DLLs are constructed by forwarding any unchanged implementation to
a "current" DLL, while containing "old" implementations as local to
CRTDLL. In other words, it's rebuilt along with every version of
Windows, but is aiming to achieve 1993 functionality.

Unfortunately (and I never noticed until now) the NT 3.1 SDK didn't
distribute the CRT sources, nor did the 32 bit Visual C++ 1.1, nor were
they posted on the ftp site. So sources are available for 16 bit C 7.0
and Visual C++ 1.x, and for 32 bit Visual C++ 2.x, but this one is
missing. (Or if you know where it is, please let me know.)

Those are specific programming-language related DLLs.

Yeah, I know why you'd feel that way, but...they're part of Windows now. MSVCRT.DLL in particular became the canonical CRT in Windows for a long
time - it was updated long past Visual C++ 6.0 functionality and most OS components linked to it.

Note for example that there's no 64 bit CRTDLL, because it made no sense
to have a frozen-in-time 1993 version for an ABI that launched in 2005.
There is a 64 bit MSVCRT, even though it also makes no sense to have a frozen-in-time 1998 version for an ABI launched in 2005...but that one
wasn't frozen in time and is really a 2005 era CRT. The original 2003
SP1 SDK includes 64 bit support and uses this DLL, despite being a
compiler from partway between Visual C++ 2003 and 2005.

For the record : I'm an Assembly programmer. :-)

I've been having a lot of fun with 16 bit assembly recently too, but
rarely needed to in 32 bit. All my 32 bit assembly is to implement 64
bit math so I don't need Microsoft's CRT :)
--- Synchronet 3.21e-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

malxau,

These DLLs are constructed by forwarding any unchanged implementation
to a "current" DLL, while containing "old" implementations as local
to CRTDLL.

I've seen enough DLLs do something like that, yes. I've always wondered
about it : why using forwarding (in the Dll or its library), and not just directly call the old function in the old DLL ?

Than again, I've also seen dummy functions (always returning True or False), or multiple names for the same code. Very funny when I, in W98, tried to do
a wide-string compare for a sorting routine and it refused to sort. :-(

Those are specific programming-language related DLLs.

Yeah, I know why you'd feel that way, but...they're part
of Windows now.

As is CRTDLL. But as said, I didn't want to go near to those, apparently, language-specific DLLs. Heck, my define-file (extracted from a DLL) to Library converter can't even handle some of those "mangled" (and often unreadable) function names. ??2@YAPAXI@Z anyone ? :-\

Note for example that there's no 64 bit CRTDLL, because it made
no sense to have a frozen-in-time 1993 version for an ABI that
launched in 2005.

Other DLLs /have/ been updated thru the times though. I had to do a lot of searching and re-writing of include files (and programs) when I switched to XP, because function signatures changed or required a specific alignment of and in the structures they accepted as arguments.

I think what irks me is that they included /language-specific/ DLLs in the
OS, instead of either upgrading the old one or provide a new *generic*
version of it.

For the record : I'm an Assembly programmer. :-)

I've been having a lot of fun with 16 bit assembly recently too,
but rarely needed to in 32 bit.

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. Although at times I've used other programming languages, I've always returned to Assembly. Knowing that what I write is exactly what gets executed does a lot for me.

All my 32 bit assembly is to implement 64 bit math so I don't
need Microsoft's CRT :)

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

All my 32 bit assembly is to implement 64 bit math so I don't
need Microsoft's CRT :)

You know that there are a number of RtlLargeInteger* functions available in NTDLL ? And as that one gets loaded as part of KERNEL32 ...

Regards,
Rudy Wieser


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

In comp.os.ms-windows.programmer.win32 R.Wieser <address@is.invalid> 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
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

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


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Fri, 20 Mar 2026 22:26:13 -0000 (UTC)
malxau <address@is.invalid> wrote:

In comp.os.ms-windows.programmer.win32 R.Wieser <address@is.invalid> wrote:

[]

For the record : I'm an Assembly programmer. :-)

I've been having a lot of fun with 16 bit assembly recently too, but

Super! xpost ought to be to alt.lang.asm, but 3 xposts is plenty.

rarely needed to in 32 bit. All my 32 bit assembly is to implement 64
bit math so I don't need Microsoft's CRT :)

--
Bah, and indeed Humbug.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

In comp.os.ms-windows.programmer.win32 R.Wieser <address@is.invalid> wrote:

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

Ouch, you're right; turns out I did that and forgot.

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

The problem is that Visual C++ emits function calls for extended
arithmetic that aren't stdcall. If C code performs a divide nearby a
mod, for example, it can emit a call to _aulldvrm, which returns two 64
bit values in four 32 bit registers. The shift functions pass the shift
width in cl, because that's what the CPU would normally use, etc.

- M
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

malxau,

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

Ouch, you're right; turns out I did that and forgot.

:-) I have been generating source-code long enough to have that happen to
me too.

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

The problem is that Visual C++ emits function calls for
extended arithmetic that aren't stdcall.

[snip]

Ackk... Forgot all about that approach. I read about it but have seldom encountered it. Yep, in that case wrappers are needed.

Hmmm. I was just thinking of directly putting the mchine-code byte-values
of a call into the program (followed by an address), but that could be a clumsier solution than the calling convention translation you spoke of.

Also, is there perhaps a possibility you can override that "by register" calling convention ? Using standard windows API funcions isn't really an un-common thing to do.

Regards,
Rudy Wieser


--- Synchronet 3.21f-Linux NewsLink 1.2