Microsoft UCRT + BCX

[Robert]

Test file:

#include <stdio.h>

int main()
{
 printf("Hello world!");
 return 0;
}

Using Visual Studio Community 2022 with MrBcx's compiler command

cl.exe /std:c++20 /permissive /O2 /c /Gd /W4 -D NTDDI_VERSION=0x0A000000 -D_WIN32_WINNT=0x0A000000 /MD /EHsc /Tp hello_ucrt.cpp

and MrBcx's linker command

link hello_ucrt.obj /OUT:WithUCRTLIB.exe UCRT.LIB

Running git bash ldd on the .exe outputs

$ ldd WithUCRTLIB.exe
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ffc0d010000)
        KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x7ffc0c790000)
        KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x7ffc0a850000)
        apphelp.dll => /c/Windows/SYSTEM32/apphelp.dll (0x7ffc07720000)
        ucrtbase.dll => /c/Windows/System32/ucrtbase.dll (0x7ffc0a390000)
        VCRUNTIME140.dll => /c/Windows/SYSTEM32/VCRUNTIME140.dll (0x7ffbf8090000
   
linking without UCRT.LIB on the linker command line, that is,

link hello_ucrt.obj /OUT:WithoutUCRTLIB.exe,

running git bash ldd on the .exe produces

 ldd WithoutUCRTLIB.exe
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ffc0d010000)
        KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x7ffc0c790000)
        KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x7ffc0a850000)
        apphelp.dll => /c/Windows/SYSTEM32/apphelp.dll (0x7ffc07720000)
        ucrtbase.dll => /c/Windows/System32/ucrtbase.dll (0x7ffc0a390000)
        VCRUNTIME140.dll => /c/Windows/SYSTEM32/VCRUNTIME140.dll (0x7ffbf8090000
      
 the same git bash ldd output as is produced with UCRT.LIB on the linker command line.          

[MrBcx]

Thanks for that Robert.

Bard says this:
Do not explicitly link to ucrt.lib.
This can cause problems if you are deploying your application to older versions of Windows

I have updated BED's MSVC UCRT batch files accordingly.

[Added later]

In my testing, if -lucrt is not included in the Mingw build process, the resulting .EXE contains no
references to the UCRT.  Therefore, unsurprisingly, I've added it to the new BED Mingw UCRT batch files.

[Vortex]

Hello,

VCRUNTIME140.dll means that you need to install the Microsoft Visual C++ Redistributable to distribute the compiled executable :

https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

The default libraries specified by the option /MD :

Code: [Select]

\PellesC\bin\podump.exe /Directives hello.obj

Code: [Select]

Dump of hello.obj

File type: OBJ

        Linker directives:
        /DEFAULTLIB:MSVCRT
        /DEFAULTLIB:OLDNAMES

[MrBcx]

While helping Ad Rienks with a problem today, I inadvertently stumbled on a serious UCRT problem.

I provided Ad with a short demo that uses DIM DYNAMIC on a UDT.  The sample that I provided to
Ad is fine.  It is instructive, it compiles with everything, it runs correctly.  No Worries.

ALMOST.

I decided to test it with the new Visual C UCRT and MINGW UCRT assembly.  Both compiled Ad's sample with no warnings or errors.  But when I attempted to RUN the sample, bad things showed up.  The executable produced by the MSVC UCRT batch file displayed garbage on the screen where the reallocated -blank- cells should have been.

The executable produced by the Mingw UCRT batch file simply crashed on impact.

I conferred with OpenAI and Bard and came up with a revised version of BCX's dynamic allocation engine.  That revision simply added a handful of memset commands right after the calloc and realloc commands.  In other words, I was EXPLICITLY zeroing the new memory.  That didn't help.

This suddenly all went in the opposite direction of the UCRT promises of increased security, etc.  I'm frustrated at this point and I'm not going to waste anymore effort on UCRT at this time. 

The work I did to BED, adding support for MSVC UCRT and MINGW UCRT, will be undone.

[MrBcx]

The governor just granted the new BED a temporary stay of execution.

Hope floats ...

[MrBcx]

After installing this Mingw package by Martin Storsjo, I used the existing Mingw batch files from BED.

https://github.com/mstorsjo/llvm-mingw/releases/download/20231003/llvm-mingw-20231003-ucrt-x86_64.zip

I didn't have to change a thing.  The batch files automagically link to UCRT.

I'm not going to include a Mingw UCRT button on BED. If you want UCRT use the link above, otherwise use whatever MINGW package that turns you on.

I will keep both MSVC and the MSVC UCRT on BED's BUILD dialog since both options work.

My earlier report about memory corruption / screen garbage turned out to be not related to
UCRT at all.  Through testing, I learned that MSVC and MINGW do not like char buffers less than 256 bytes.

TYPE AccountStructure
    AccountName[256] AS CHAR  'In BCX,  MSVC needs [256] & Mingw [512] with DIM DYNAMIC
    AccountBalance AS LONG       'otherwise memory corruption. Lcc & Pelles do not suffer this quirk.
END TYPE

I feel optimistic again ...

[MrBcx]

I've tested Martin Storsjo's Mingw/LLVM package several times in the past but always concluded that it just wasn't ready for prime time, as the saying goes. 

Now having spent a few hours with the current version, I have to say that I am genuinely impressed and believe it's time for me to say "Adios!" to Equation Solution.

[Vortex]

Hi Kevin,

Thanks for your research. MinGW is the most complicated C\C++ compiler. I am not surprised to see the results. MS VC is better for the UCRT stuff.

After all of those deliberate UCRT \ MS VC run-time complications , I must to say that Mr. Pelle Orinius is the hero. A very nice toolset following the keep it simple rule. The Linux systems does not suffer from the DLL hell issue.

[MrBcx]

MS VC is better for the UCRT stuff.

One hopes that would be the case Erol, considering it's their Frankenstein. 
I don't know whether any BCX user will ever realize a UCRT inspired dividend but
much has been invested in its development, so it's prudent to pay attention to it. 

Martin's UCRT Mingw package builds BCX, BED, and scores more quickly and
seemingly without flaws.  I'll enjoy having it in my digital toolbox.

[Vortex]

Hi Kevin,

I rebuilt the simple hello world code with Martin's UCRT MinGW package. The dependencies of the compiled executable are :

Code: [Select]

api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-private-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
KERNEL32.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll

Except kernel32.dll, all the other DLLs are the members of the Universal C Runtime.

[MrBcx]

The next release and future versions of BED will use the UCRT:

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

And these Non-UCRT libraries:

COMCTL32.dll
COMDLG32.dll
GDI32.dll
KERNEL32.dll
ole32.dll
SHELL32.dll
USER32.dll
VCRUNTIME140.dll

BCX compiled with UCRT has similar dependencies.

I'm certain that as we become accustomed to building with the UCRT,
the shine will rub off and we'll stop focusing our attention on it. 

[Vortex]

Hi Kevin,

Kindly, please keep BCX \ bc.exe and BED simple. The current versions are depending only on the system DLLs :

bc.ece :

Code: [Select]

KERNEL32.dll
USER32.dll
ADVAPI32.dll
bed.exe :

Code: [Select]

KERNEL32.dll
USER32.dll
GDI32.dll
COMCTL32.dll
COMDLG32.dll
ole32.dll
SHELL32.dll

[MrBcx]

Hi Kevin,

Kindly, please keep BCX \ bc.exe and BED simple. The current versions are depending only on the system DLLs :

The UCRT libraries -> are <- system DLL's, if your system is Windows 10 or Windows 11. 
The UCRT libraries came into existence in 2015, as you probably know.
 
From Google BARD:

Microsoft is still updating non-UCRT system DLLs. For example, on August 9, 2023, Microsoft released an update that fixes a security vulnerability in the Windows Printer Driver Host (PrintHost.exe). This update is available for Windows 10, Windows 11, and Windows Server.

However, the frequency of updates for non-UCRT system DLLs has decreased in recent years. This is because Microsoft is now focusing on developing and maintaining the UCRT, which is a single CRT library that is used by all Windows applications. The UCRT is updated more frequently than non-UCRT system DLLs, and it includes all of the latest security fixes and performance improvements.

If you are using a Windows application that relies on a non-UCRT system DLL, it is important to keep your system up to date so that you can receive the latest security fixes. You can do this by enabling automatic updates or by manually checking for updates on a regular basis.

Here are some of the reasons why Microsoft may still need to update non-UCRT system DLLs:

    To fix security vulnerabilities.
    To improve performance or reliability.
    To add new features or functionality.
    To support new hardware or software.

Microsoft will continue to update non-UCRT system DLLs as needed, but the focus is now on the UCRT.
If you are developing new Windows applications, it is recommended that you use the UCRT instead
of non-UCRT system DLLs.

[Robert]

Hi Kevin,

Kindly, please keep BCX \ bc.exe and BED simple. The current versions are depending only on the system DLLs :

bc.ece :

Code: [Select]

KERNEL32.dll
USER32.dll
ADVAPI32.dll
bed.exe :

Code: [Select]

KERNEL32.dll
USER32.dll
GDI32.dll
COMCTL32.dll
COMDLG32.dll
ole32.dll
SHELL32.dll

Hi Vortex:

Why

Visual Studio 2015 and later versions of Visual Studio all use one Universal CRT.

The UCRT is available by using Windows Update on older operating systems.

Really, why

[Vortex]

Hi Robert,

You are asking why :  I always advocate the keep it simple principle :

You will need to copy all of the DLLs with your app (note that the set of DLLs are necessary is different on different versions of Windows, so you must include all of the DLLs in order for your program to run on all supported versions of Windows)

https://devblogs.microsoft.com/cppblog/introducing-the-universal-crt/

As an example, I am using the VPN client of the firewall of the company where I work. The firewall is a well known brand. The installer comes with 40 api-ms-win-*.dll files forwarding all the CRT functions to ucrtbase.dll :

Code: [Select]

E:\PellesC\bin\podump.exe /EXPORTS "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\ucrt\x86\ucrt.lib"

Code: [Select]

File type: LIB
api-ms-win-crt-conio-l1-1-0.dll: __conio_common_vcprintf (___conio_common_vcprintf)
api-ms-win-crt-conio-l1-1-0.dll: __conio_common_vcprintf_p (___conio_common_vcprintf_p)
api-ms-win-crt-conio-l1-1-0.dll: __conio_common_vcprintf_s (___conio_common_vcprintf_s)
api-ms-win-crt-conio-l1-1-0.dll: __conio_common_vcscanf (___conio_common_vcscanf)
api-ms-win-crt-conio-l1-1-0.dll: __conio_common_vcwprintf (___conio_common_vcwprintf)
api-ms-win-crt-conio-l1-1-0.dll: __conio_common_vcwprintf_p (___conio_common_vcwprintf_p)
api-ms-win-crt-conio-l1-1-0.dll: __conio_common_vcwprintf_s (___conio_common_vcwprintf_s)
api-ms-win-crt-conio-l1-1-0.dll: __conio_common_vcwscanf (___conio_common_vcwscanf)
api-ms-win-crt-conio-l1-1-0.dll: _cgets (__cgets)
api-ms-win-crt-conio-l1-1-0.dll: _cgets_s (__cgets_s)
api-ms-win-crt-conio-l1-1-0.dll: _cgetws (__cgetws)
api-ms-win-crt-conio-l1-1-0.dll: _cgetws_s (__cgetws_s)
api-ms-win-crt-conio-l1-1-0.dll: _cputs (__cputs)
api-ms-win-crt-conio-l1-1-0.dll: _cputws (__cputws)
api-ms-win-crt-conio-l1-1-0.dll: _getch (__getch)
api-ms-win-crt-conio-l1-1-0.dll: _getch_nolock (__getch_nolock)
api-ms-win-crt-conio-l1-1-0.dll: _getche (__getche)
api-ms-win-crt-conio-l1-1-0.dll: _getche_nolock (__getche_nolock)
api-ms-win-crt-conio-l1-1-0.dll: _getwch (__getwch)
api-ms-win-crt-conio-l1-1-0.dll: _getwch_nolock (__getwch_nolock)
api-ms-win-crt-conio-l1-1-0.dll: _getwche (__getwche)
api-ms-win-crt-conio-l1-1-0.dll: _getwche_nolock (__getwche_nolock)
api-ms-win-crt-conio-l1-1-0.dll: _putch (__putch)
api-ms-win-crt-conio-l1-1-0.dll: _putch_nolock (__putch_nolock)
api-ms-win-crt-conio-l1-1-0.dll: _putwch (__putwch)
api-ms-win-crt-conio-l1-1-0.dll: _putwch_nolock (__putwch_nolock)
api-ms-win-crt-conio-l1-1-0.dll: _ungetch (__ungetch)
api-ms-win-crt-conio-l1-1-0.dll: _ungetch_nolock (__ungetch_nolock)
api-ms-win-crt-conio-l1-1-0.dll: _ungetwch (__ungetwch)
api-ms-win-crt-conio-l1-1-0.dll: _ungetwch_nolock (__ungetwch_nolock)
api-ms-win-crt-convert-l1-1-0.dll: __toascii (___toascii)
api-ms-win-crt-convert-l1-1-0.dll: _atodbl (__atodbl)
api-ms-win-crt-convert-l1-1-0.dll: _atodbl_l (__atodbl_l)
api-ms-win-crt-convert-l1-1-0.dll: _atof_l (__atof_l)
api-ms-win-crt-convert-l1-1-0.dll: _atoflt (__atoflt)
api-ms-win-crt-convert-l1-1-0.dll: _atoflt_l (__atoflt_l)
api-ms-win-crt-convert-l1-1-0.dll: _atoi64 (__atoi64)
api-ms-win-crt-convert-l1-1-0.dll: _atoi64_l (__atoi64_l)
.
.
.

Do we need all those complications?