Microsoft UCRT + BCX

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

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


KERNEL32.dll
USER32.dll
ADVAPI32.dll

bed.exe :

Code Select Expand

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

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

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

Code Select Expand


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]

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,

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]

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.

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

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

Hope floats ...

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

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

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

Code Select Expand

Dump of hello.obj

File type: OBJ

        Linker directives:
        /DEFAULTLIB:MSVCRT
        /DEFAULTLIB:OLDNAMES

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

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

Hi Kevin,

Here is my test with Msys2 :

Thanks Erol ... but generally speaking, in order to be useful with BCX, g++ is needed, not gcc.

Lcc-Win32 and Pelles have C++ extensions that BCX has relied upon from the beginning, most
importantly, the ability to use default arguments in FUNCTION and SUBs. The gcc compiler does
not have a default arguments extension. That's too bad because BCX uses hundreds of them.

BED has used the g++ (GNU's c++ compiler) from the beginning.  It obviously works great when
using BCX commands and functions that require a c++ compiler, such as CLASSES, NAMESPACES,
etc.  But g++ also works well as a C compiler, commonly stated as "Using C++ as a better C"

[Vortex]

Hi Kevin,

Here is my test with Msys2 :

Starting the shell C:\msys64\ucrt64.exe :

Code Select Expand

User@Notebook UCRT64 ~
# cat hello.c
#include <stdio.h>

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

User@Notebook UCRT64 ~
# gcc hello.c -o hello-ucrt64.exe -s

User@Notebook UCRT64 ~
# ldd hello-ucrt64.exe
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x77720000)
        kernel32.dll => /c/Windows/system32/kernel32.dll (0x77500000)
        KERNELBASE.dll => /c/Windows/system32/KERNELBASE.dll (0x7fefd2a0000)
        api-ms-win-crt-environment-l1-1-0.dll => /c/Windows/system32/api-ms-win-crt-environment-l1-1-0.dll (0x7fef5610000)
        ucrtbase.DLL => /c/Windows/system32/ucrtbase.DLL (0x7fef56e0000)
        api-ms-win-core-timezone-l1-1-0.dll => /c/Windows/system32/api-ms-win-core-timezone-l1-1-0.dll (0x7fef56d0000)
        api-ms-win-core-file-l2-1-0.dll => /c/Windows/system32/api-ms-win-core-file-l2-1-0.dll (0x7fef56c0000)
        api-ms-win-core-localization-l1-2-0.dll => /c/Windows/system32/api-ms-win-core-localization-l1-2-0.dll (0x7fef56b0000)
        api-ms-win-core-synch-l1-2-0.dll => /c/Windows/system32/api-ms-win-core-synch-l1-2-0.dll (0x7fefae70000)
        api-ms-win-core-processthreads-l1-1-1.dll => /c/Windows/system32/api-ms-win-core-processthreads-l1-1-1.dll (0x7fef56a0000)
        api-ms-win-core-file-l1-2-0.dll => /c/Windows/system32/api-ms-win-core-file-l1-2-0.dll (0x7fef5690000)
        api-ms-win-crt-heap-l1-1-0.dll => /c/Windows/system32/api-ms-win-crt-heap-l1-1-0.dll (0x7fef5680000)
        api-ms-win-crt-math-l1-1-0.dll => /c/Windows/system32/api-ms-win-crt-math-l1-1-0.dll (0x7fef55f0000)
        api-ms-win-crt-private-l1-1-0.dll => /c/Windows/system32/api-ms-win-crt-private-l1-1-0.dll (0x7fefaed0000)
        api-ms-win-crt-runtime-l1-1-0.dll => /c/Windows/system32/api-ms-win-crt-runtime-l1-1-0.dll (0x7fef6330000)
        api-ms-win-crt-stdio-l1-1-0.dll => /c/Windows/system32/api-ms-win-crt-stdio-l1-1-0.dll (0x7fef5660000)
        api-ms-win-crt-string-l1-1-0.dll => /c/Windows/system32/api-ms-win-crt-string-l1-1-0.dll (0x7fef5670000)
        api-ms-win-crt-time-l1-1-0.dll => /c/Windows/system32/api-ms-win-crt-time-l1-1-0.dll (0x7fef5600000)

User@Notebook UCRT64 ~
# ls -l hello-ucrt64.exe
-rwxr-xr-x 1 User None 18432 Oct  4 23:02 hello-ucrt64.exe

User@Notebook UCRT64 ~
# ./hello-ucrt64.exe
Hello world!