Microsoft UCRT + BCX

[Quin]

I'd just like to chime in here with my praze for the new UCRT and its usage with BCX, I now get super tiny binaries out of it every time. Nothing beats PellesC for simplicity, but this is incredibly well done

[MrBcx]

api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll

Here's a little more info on these mysterious files.

These (and more) are what Microsoft calls API Sets.  Vortex called them forwarders,
and he's not wrong about that, but its better to think of them as proxies to the actual
functions contained in the UCRT. 

Api Sets help abstract the actual implementation, ensuring that different versions
of Windows provide the same function interface. Kind of like a COM Interface, if you
look at it sideways.  So, besides routing function calls, the Api Sets are sensitive to the
version of Windows that the calling apps are running on.

That right there tells me it's wise to not avoid them.

When Microsoft add new features or bug fixes to the UCRT, they could change the actual
coding of one or more runtime functions. But it is the API Sets that mostly eliminate the
need to recompile apps that are tied to UCRT functions. The version of the API Sets that are
tied  to an app stays the same (apparently embeded in the app's executable). Windows will
direct function calls to the correct version of UCRT.  (I suppose that's true, as long as the
required UCRT version is installed on the machine that needs it.)

So, that's the way it's supposed to work.  Even if you have an app linked to an older UCRT,
it will likely still run on a newer version of Windows and even with a newer version of the UCRT. 

There ... clear as mud!

[jbk]

thanks Vortex 

[Vortex]

Hi jbk,

The all-in-one UCRT DLL is ucrtbase.dll. The api-ms-win-* DLLs are forwarders.

[MrBcx]

if only MS hadn't split UCRT into so many DLL's, would be nice to have an all-in-one UCRT DLL

The all-in-one dll is what got them into trouble in the first place. 

I've come to believe the individual dll's makes a lot more sense, from a maintenance and user impact standpoint.

[jbk]

if only MS hadn't split UCRT into so many DLL's, would be nice to have an all-in-one UCRT DLL

[MrBcx]

MrBcx, UCRT might be the default/recommended way in the future but for the present I think that msvcrt is good enough or better option

If you subtract 8 years from 2023 then simple arithmetic says that we are now living in the future.

"Beginning in Visual Studio 2015, it's no longer the case. Visual Studio 2015 and later versions of Visual Studio all use one Universal CRT."

https://learn.microsoft.com/en-us/cpp/windows/universal-crt-deployment?view=msvc-170

[jbk]

MrBcx, UCRT might be the default/recommended way in the future but for the present I think that msvcrt is good enough or better option

[MrBcx]

What am I missing here?
The latest 8.0.6 64bit Bc.exe was compiled with MS VC++ so it already uses the ucrt?

James

No.

Traditional compiling with MSVC-2022 contains these import references inside Bc.exe (8.0.6):

ADVAPI32.dll
KERNEL32.dll
USER32.dll

Compiling for UCRT, Bc.exe (8.0.6) contains those same dll imports:

ADVAPI32.dll
KERNEL32.dll
USER32.dll

But wait, there's MORE!

VCRUNTIME140.dll

api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll

[jcfuller]

What am I missing here?
The latest 8.0.6 64bit Bc.exe was compiled with MS VC++ so it already uses the ucrt?

James

[Vortex]

Hello,

We can try the static builds suggested by Robert. This will avoid all that DLL mess at least for now.

[dgarner]

I have no idea, but if you think it makes sense, I'd say give it a try and see what happens.

If users have issues, and they can't be easily fixed, you can always go back to the previous way of doing things.

Thanks for chasing this, and all the other, rabbit(s).

[jbk]

I'd like to turn this topic slightly to the question:

Should I upload future binaries (BED, BCX, BMFD, etc) linked to UCRT or not?

And before anyone asks, no I'm not going to upload both versions.

I am inclined to say yes

[Robert]

I'd like to turn this topic slightly to the question:

Should I upload future binaries (BED, BCX, BMFD, etc) linked to UCRT or not?

And before anyone asks, no I'm not going to upload both versions.

Hi MrBcx:

No .exes.

Source code only. With Build.bat. Your choice of compilers. If someone needs another flavor of Build.bat they can ask.

For BCX, if there is a radical change, include the C file.

This is a programming group.

The above was written with the assumption that anyone downloading BED, BCX, BMFD would have an installed version of BCX.exe, at least, a version from the Installer on the BCXBASICCoders homepage. But it occurred to me that the version of BCX.exe in the installer would not be able to translate a current version.

So, in short, forget my suggestion.

I just compiled a static build (/MT) of BCX 8.0.6. 64 bit using the Microsoft cl.exe compiler (2022) and ran it successfully on Windows 7.

On the Microsoft 2022 Visual Studio the default static builds are UCRT, same as it has been since 2015.

[Robert]

I'd like to turn this topic slightly to the question:

Should I upload future binaries (BED, BCX, BMFD, etc) linked to UCRT or not?

And before anyone asks, no I'm not going to upload both versions.

Hi MrBcx:

No .exes.

Source code only. With Build.bat. Your choice of compilers. If someone needs another flavor of Build.bat they can ask.

For BCX, if there is a radical change, include the C file.

This is a programming group.