sprintf_s in masm ?

[jj2007]

Dll hell in the 21st Century, isn't it lovely?

Code Select Expand

C:\Windows\System32\msvcrt.dll
C:\Windows\System32\msvcr100_clr0400.dll
C:\Windows\System32\msvcr120_clr0400.dll
C:\Windows\System32\msvcrt20.dll
C:\Windows\System32\msvcrt40.dll
C:\Windows\System32\msvcr71.dll
C:\Windows\System32\msvcr80.dll
C:\Windows\System32\msvcr100.dll
There is a simple solution:
- find out what's the latest msvcr*.dll
- use LoadLibrary and GetProcAddress

[alCoPaUL]

Dll hell in the 21st Century, isn't it lovely?

Code Select Expand

C:\Windows\System32\msvcrt.dll
C:\Windows\System32\msvcr100_clr0400.dll
C:\Windows\System32\msvcr120_clr0400.dll
C:\Windows\System32\msvcrt20.dll
C:\Windows\System32\msvcrt40.dll
C:\Windows\System32\msvcr71.dll
C:\Windows\System32\msvcr80.dll
C:\Windows\System32\msvcr100.dll
There is a simple solution:
- find out what's the latest msvcr*.dll
- use LoadLibrary and GetProcAddress

m$ tactics - either for the $$ or from old school m$ guises who don't want all the os versions to be swiped by malware so they grouped the default development software for the os via different redistributable runtime files..

anyway, attached is similar code that i previously posted with 3 C Standard lib functions but it's written in another assembler. you can easily format this to masm32 assembly src file using the previous code that i shared as template..

splitted the zip (file size restrictions) so just rename faxx.jpg to faxx.z01...

[alCoPaUL]

StrLen() must be sanitized by checking if it's FFFFFFFEh to get the Maxed Capacity.

But the Primacy of the 999426 DUP(0) buffer is upheld so StrLen(data), by practice, is wayyy smaller than the function's Maxed Capacity.

And since I posted the 64-bit version, now it's clear why the size of the buffer in 64-bit sprintf_s can be ommited coz the maxed capacity of StrLen(data), to suffice the length of the inputted data to sprintf_s, Ideally, is effing FFFFFFFFFFFFFFFEh bytes.