Microsoft UCRT + BCX

[MrBcx]

The only reason that I can think of why an installer would bundle UCRT libraries is because someone is running an  outdated operating system like Windows XP, Windows 7, Windows 8, or Windows Vista, none of which is secure anymore.  Windows 10 will reach end-of-support on October 14, 2025.

As it pertains to BCX, my goal is keep as much old BCX source code, as possible, compiling and running on current Windows Operating Systems.  It's been like that since BCX was a MS-DOS app creating C code for Windows 95/98/ME before becoming a 32-bit app and generating C\C++ code for future generations of NT Operating Systems.

If we don't move knowledge forward, we stand still.

[Vortex]

Hi Kevin,

The same installer unpacks the same api-ms-win-*.dll file set on a Windows 10 system too. Probably, the manufacturer of the VPN client is expecting to maintaing the stability of the application with tested DLLs.

It looks like that Martin's UCRT MinGW does not depend on vcruntime140.dll avoiding the extra runtime library. That's good. Also, it's possible to bypass the api-ms-win-*.dll set , the trick is to link against ucrtbase.lib

[MrBcx]

 Also, it's possible to bypass the api-ms-win-*.dll set , the trick is to link against ucrtbase.lib

I'm certainly no expert on this subject but that seems like an unwise trick. 

The "D" in DLL is for "Dynamic".  The moment you statically link something, it is no longer
dynamic.  In this context, it seems like you've defeated the whole goal of UCRT which is to
prevent the need to supply specific, (out-of-date) libraries, in order for an app to run.

There is a lot of indecipherable stuff going on inside c:\program files (x86)\windows kits\10\
that I believe very few people fully understand.

[Vortex]

Hi Kevin,

The moment you statically link something, it is no longer
dynamic.  In this context, it seems like you've defeated the whole goal of UCRT which is to
prevent the need to supply specific, (out-of-date) libraries, in order for an app to run.

No, it's not about statically linking and no any attempt to defeat the UCRT. It's all about dynamical linking. Let me explain.

The purpose of the api-ms-win-*.dll files ( API set ) is to forward the original C library names to ucrtbase.dll acting very similar to the good old msvcrt.dll. This forwarding mechanism allows the implementation and versioning of the original C functions :

How to correctly link to UCRT (and why it works that way)

https://mingwpy.github.io/ucrt.html

Information on linking to the new Windows UCRT

https://gist.github.com/njsmith/08b1e52b65ea90427bfd

ChatGPT's explanation :

Versioning and Forward Compatibility: By using API sets, Microsoft can add new features or change the implementation of existing functions without affecting applications that rely on older versions of those functions. This helps ensure that software developed for one version of Windows can still run on newer versions without modification.

Let's consider this very simple BCX code :

Code: [Select]

puts("Hello world!")
Converted to :

Code: [Select]

.
.
.
int main(int argc, char *argv[])
{
  puts("Hello world!");
  return EXIT_SUCCESS;   // End of main program
  }

The purpose is to call the puts function exported by ucrtbase.dll

Building the import library :

Code: [Select]

\PellesC\bin\polib /MACHINE:x64 /OUT:ucrtbase.lib C:\Windows\System32\ucrtbase.dll
The resulting executable imports from ucrtbase.dll :

Code: [Select]

\PellesC\bin\podump.exe /IMPORTS Hello.exe | findstr ".dll"
        KERNEL32.dll
        ucrtbase.dll

To simplify the linkage procedure, I used my own mainCRTStartup module.

Of course, the documentation is strongly advising to link against the API set to maintain the compatibility if ucrtbase.dll will face significant modifications in the future. Again, the documentation is advising to link against VC runtime libraries instead of msvcrt.dll but MinGW uses directly msvcrt.dll instead of those VC libs. Maybe, the same can valid for ucrtbase.dll later.

[Vortex]

Hello,

In the batch file Build.bat, replacing this line :

Code: [Select]

%PellesFolder%\bin\polink %PolinkLIBS%  %PolinkOPTS% Hello.obj crt0cons.obj ucrtbase.lib
with this :

Code: [Select]

%PellesFolder%\bin\polink %PolinkLIBS%  %PolinkOPTS% Hello.obj crt0cons.obj "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\ucrt\x64\ucrt.lib"
produces the executable importing puts from api-ms-win-crt-stdio-l1-1-0.dll  This is the correct and secure approach :

Code: [Select]

\PellesC\bin\podump.exe /IMPORTS Hello.exe

Dump of Hello.exe

File type: EXE

        Imported symbols

        KERNEL32.dll

       140004068 import address table
       140004040 import name table
               0 time date stamp (Thu Jan  1 03:00:00 1970)
               0 index of first forwarder reference

        hint  name
           0  GetCommandLineA
           0  ExitProcess

        api-ms-win-crt-stdio-l1-1-0.dll

       140004080 import address table
       140004058 import name table
               0 time date stamp (Thu Jan  1 03:00:00 1970)
               0 index of first forwarder reference

        hint  name
          93  puts

[MrBcx]

Hi Erol,

That's all good information.  I'm genuinely interested in a Pelles C / UCRT relationship. 
However, I still want to learn more on this subject, starting with the following question.

Do you know, or have a theory, why Windows is maintaining multiple copies of UCRT ?
                                      ( See Attached Screenshot )

Intuitively, it would seem static linking ucrtbase.lib from any of those versions would be
uniquely tied to the dll's of that version. 

One problem I have taking this article:  https://mingwpy.github.io/ucrt.html  at face value
is that it was written at the same time UCRT made its debut.  Certainly something has
changed / matured / evolved in 8 years.

Please don't think I'm being adversarial, the years have simply make me a bit more cautious
and deliberative .

[Robert]

Hi MrBcx:

Where do you find ucrtbase.lib?

[MrBcx]

Hi MrBcx:

Where do you find ucrtbase.lib?

Hi Robert,

You won't find it, but on my PC, I find 13 versions of ucrtbase.dll under the \Windows Kits\ folder.

Vortex demonstrated to get ucrtbase.lib, do this:

C:\PellesC\bin\polib /MACHINE:x64 /OUT:ucrtbase.lib C:\Windows\System32\ucrtbase.dll


I should add, under C:\Windows\, I found 24 additional copies of ucrtbase.dll.
Some clearly different, some apparently clones.

I haven't messed with any of this stuff for Pelles C.  I am working on other things at this time.

[Robert]

Hi MrBcx:

Where do you find ucrtbase.lib?

Hi Robert,

You won't find it, but on my PC, I find 13 versions of ucrtbase.dll under the \Windows Kits\ folder.

Vortex demonstrated to get ucrtbase.lib, do this:

C:\PellesC\bin\polib /MACHINE:x64 /OUT:ucrtbase.lib C:\Windows\System32\ucrtbase.dll


I should add, under C:\Windows\, I found 24 additional copies of ucrtbase.dll.
Some clearly different, some apparently clones.

I haven't messed with any of this stuff for Pelles C.  I am working on other things at this time.

Thanks for that.

When I installed Visual Studio on Windows 11, I opted for installation of the VS140 C/C++ compiler so in my Windows Kits folder there is

10.0.10240.0 for VS 140 (2015) which I install for possible XP builds. I think VS 141 was the last XP capable.

and

10.0.22621.0 for VS 143 (2022)

which leads me to concur with your statement

Intuitively, it would seem static linking ucrtbase.lib from any of those versions would be
uniquely tied to the dll's of that version.

You've got three 10.0.xxxxx so maybe you installed two of the three available (VS 140 (2015), VS 141 (2017) and VS 142 (2019).

UCRT is Microsoft's very belated attempt at implementing an equivalent functionality to Linux glibc.

The Microsoft UCRT documentation is convoluted and to me seems to imply lack of understanding by the authors rather than the often mentioned "obfuscation" that critics attribute implying a malicious intent.

Lots to learn here. Keep moving forward.

Stasis is death. 

[MrBcx]

I asked ChatGPT the following:

I'm confused. One touted benefit of the UCRT is the elimination of the need to redistribute specific versions of the Microsoft Visual C runtime. Suppose an earlier version of "printf" in the UCRT supports a specific application that was developed at the same time. Years pass, and "printf" is updated and no longer compatible with the now years-old application that depends on the old version of "printf". The app won't run with the current UCRT because the current "printf" is incompatible.

I thought the strategy behind the UCRT was to maintain all versions of the UCRT on all computers that use Windows after 2015, and that the operating system would check for UCRT DLL version information, locate the correct UCRT DLL, and then launch old and new apps using the UCRT DLLs that are specific to those apps. If it doesn't work that way, then what problem does the UCRT even fix?

ChatGPT responded:

I understand your confusion, and I'll try to clarify how the Universal C Runtime (UCRT) works and its purpose.

The UCRT is designed to address the problem of redistributing specific versions of the Microsoft Visual C++ runtime libraries with applications. Its primary goal is to provide a standardized set of runtime libraries with the Windows operating system, reducing the need for developers to include and manage these libraries with their applications.

Here's how the UCRT typically works:

    UCRT Versioning: The UCRT is versioned, and different versions of Windows include different UCRT versions. When an application is compiled, it links against a specific version of the UCRT.

    Redistributable UCRT: To ensure compatibility, older versions of the UCRT are made available as redistributable packages. This means that if an application depends on a specific version of the UCRT, the developer can include that specific redistributable package with the application installer. This ensures that the required UCRT version is available on the target system.

    System UCRT: While newer versions of the UCRT are included with Windows updates, the Windows operating system generally aims to maintain backward compatibility. This means that when an application built with an older UCRT version runs on a newer Windows system, it should continue to work because the system includes the necessary UCRT version. The Windows operating system can use manifest files to determine which version of the UCRT to load for each application.

However, there can be exceptions to this, especially if an application relies on specific behaviors or functions that have changed significantly between UCRT versions. In such cases, compatibility issues may arise.

In summary, the UCRT is intended to make it easier for developers to distribute their applications without worrying about bundling specific versions of runtime libraries. While the Windows operating system does provide backward compatibility to a certain extent, developers should still ensure that their applications are compatible with the UCRT version available on their target systems. This may involve including redistributable packages or implementing compatibility checks in the application itself.


MrBcx says:

So, in other other words, UCRT did not fix a damn thing.

[Added Later]
Opposing viewpoints might include that the UCRT library has improved in other ways.
And as long as what we do depends on the Windows operating system, it's probably
best to > assume < that viewpoint has merit.

[Robert]

 The UCRT supports a stable ABI based on C calling conventions, and it conforms closely to the ISO C99 standard, with only a few exceptions. It's no longer tied to a specific version of the compiler. You can use the UCRT on any version of Windows supported by Visual Studio 2015 or Visual Studio 2017. The benefit is that you no longer need to update your builds to target a new version of the CRT with every upgrade of Visual Studio.

Please see

https://learn.microsoft.com/en-us/cpp/porting/upgrade-your-code-to-the-universal-crt?view=msvc-170

C++ does not have a stable ABI.

[Vortex]

Hi Kevin,

No worries, we are here to support the evolution of science. It's good to be cautious and deliberative.

It looks like that we will continue to face the problem of DLL hell. Windows is becoming much more complicated.

[MrBcx]

 The UCRT supports a stable ABI based on C calling conventions, and it conforms closely to the ISO C99 standard, with only a few exceptions. It's no longer tied to a specific version of the compiler. You can use the UCRT on any version of Windows supported by Visual Studio 2015 or Visual Studio 2017. The benefit is that you no longer need to update your builds to target a new version of the CRT with every upgrade of Visual Studio.

Please see

https://learn.microsoft.com/en-us/cpp/porting/upgrade-your-code-to-the-universal-crt?view=msvc-170

C++ does not have a stable ABI.

Thanks Robert,

Those are worthwhile improvements and motivation enough to get onboard. 

Folks running out-of-cycle versions of Windows will likely be affected most,
if at all, when the UCRT dll's get updated.  I'm always in-cycle, so I'll just
not worry about that aspect anymore and move on.

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.

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

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