How to dynamic load a library?

[jj2007]

You may also like to look at this Stackoverflow thread. "How do I build against the UCRT with mingw-w64?"

"as far as I understand both VS 2015 and VS 2017 use the VCRUNTIME140.DLL" - is that available on all Windows versions, or do you have to ship it with the exe to your client? Btw what are the essential improvements of VCRUNTIME*.DLL over msvcrt.dll?

The Micros**t page is not very encouraging: "To take advantage of these changes, your existing code and project build systems must be updated" - that really sounds like the exact contrary of an "advantage" ;-)

If your code compiled cleanly when using an older version of the CRT but breaks when compiled using the UCRT, you must change your code to take advantage of these updates and features

Greetings to Redmond, you are funny guys ;-)

Overview of potential upgrade issues (Visual C++)
05/03/2019
18 minutes to read

... and 18 nights to fight ;-)

[systemctl]

You may also like to look at this Stackoverflow thread. "How do I build against the UCRT with mingw-w64?"

"as far as I understand both VS 2015 and VS 2017 use the VCRUNTIME140.DLL" - is that available on all Windows versions, or do you have to ship it with the exe to your client?

You have to ship them with your exe or ask your user to install Visual C++ redistribute package (approriate version).

This is the reason why we got this: https://www.techpowerup.com/download/vi ... ll-in-one/

[robert]

Quoting from an earlier post in the Martin Storsjö thread

And vcruntime140 doesn't matter either, you don't
need it (unless you are packaging an app for windows store).

The entire thread is here
https://sourceforge.net/p/mingw-w64/mai ... sg36620733

[caseih]

If Windows updates are done, the universal runtime dll should be present. Unlike earlier runtimes, this one is distributed through windows update.

[robert]

You may also like to look at this Stackoverflow thread. "How do I build against the UCRT with mingw-w64?"

Btw what are the essential improvements of VCRUNTIME*.DLL over msvcrt.dll?

The improvements are the corrections, improvements and additions to the C language since msvcrt.dll was created, the last update was years ago (in 2003 ???). That msvcrt.dll version is based on the 1989 ANSI C standard. Much has happened since then.

[robert]

You may also like to look at this Stackoverflow thread. "How do I build against the UCRT with mingw-w64?"

Btw what are the essential improvements of VCRUNTIME*.DLL over msvcrt.dll?

The improvements are the corrections, improvements and additions to the C language since msvcrt.dll was created, the last update was years ago (in 2003 ???). That msvcrt.dll version is based on the 1989 ANSI C standard. Much has happened since then.

Here is a simple example of a one of the deficiencies in one msvcrt.dll function, strftime.

Code: Select all

''=============================================================================
#include "crt.bi"
''=============================================================================
dim as integer diditwork
dim as tm ptr nowhere
dim as time_t t
dim as zstring*100 buffer

time_ @t
nowhere = localtime( @t )
diditwork = strftime( @buffer, 100, "%A %G-W%V-%u", nowhere )
if diditwork = 0 then
print "Did it work? No, the compiler is behind the times." 
else
print "Did it work? Yes, the Industrial Date Code is ";
print buffer
end if
sleep

The FreeBASIC code above compiled on my Linux Fedora Version 32 (x64) with FreeBASIC 1.0.8 x64 (gcc 10.0.1 backend) and then run outputs

Code: Select all

Did it work? Yes, the Industrial Date Code is Saturday 2020-W18-6

The FreeBASIC code above compiled on my Windows 10 (x64) with FreeBASIC 1.0.8 (gcc 10.0.1 backend) and then run outputs

Code: Select all

Did it work? No, the compiler is behind the times.

The Industrial Date Code and many other changes were added to strftime in the C Standard C99. You can see the extent of the C99 changes to the C strftime function in the Conversion Specifier column of the strftime documentation at

https://en.cppreference.com/w/c/chrono/strftime

Martin Storsjö at MinGW-64 adding libucrt.a and libucrtbase.a to link against api-ms-win-crt-*.dll and ucrtbase.dll made a great step in rectifying these deficiencies for Windows gcc users.

[jj2007]

I found a workaround for strftime:

Code: Select all

''=============================================================================
#include "crt.bi"
#include "windows.bi"
''=============================================================================
dim as integer diditwork
dim as tm ptr nowhere
dim as time_t t
dim as zstring*100 buffer
dim as zstring*100 buffer2

time_ @t
nowhere = localtime( @t )
' diditwork = strftime( @buffer, 100, "%A %G-W%V-%u", nowhere )
diditwork = strftime( @buffer, 100, "%d.%m.%y", nowhere)
if diditwork = 0 then
print "Did it work? No, the compiler is behind the times."
else
print "Did it work? Yes, the Industrial Date Code is ";
print buffer
end if
diditwork = GetDateFormatA(LOCALE_USER_DEFAULT, 0, 0, "dddd dd/MM/yy", @buffer2, 100)
if diditwork=0 then
print "Did it work? No, the compiler is behind the times."
else
print "Did it work? Yes, the Industrial Date Code is ";
print buffer2
end if
sleep

Output: Did it work? Yes, the Industrial Date Code is Sunday 03/05/20

But of course, it didn't work with the "%A %G-W%V-%u" format. So if I ever need this format, I'll have to study how to adapt myself to the UCRT. Thanks, Robert.

P.S.: To get the May 3, 2020 format of the forum, use "MMM dd, yyyy"

[robert]

I found a workaround for strftime:

Code: Select all

''=============================================================================
#include "crt.bi"
#include "windows.bi"
''=============================================================================
dim as integer diditwork
dim as tm ptr nowhere
dim as time_t t
dim as zstring*100 buffer
dim as zstring*100 buffer2

time_ @t
nowhere = localtime( @t )
' diditwork = strftime( @buffer, 100, "%A %G-W%V-%u", nowhere )
diditwork = strftime( @buffer, 100, "%d.%m.%y", nowhere)
if diditwork = 0 then
print "Did it work? No, the compiler is behind the times."
else
print "Did it work? Yes, the Industrial Date Code is ";
print buffer
end if
diditwork = GetDateFormatA(LOCALE_USER_DEFAULT, 0, 0, "dddd dd/MM/yy", @buffer2, 100)
if diditwork=0 then
print "Did it work? No, the compiler is behind the times."
else
print "Did it work? Yes, the Industrial Date Code is ";
print buffer2
end if
sleep

Output: Did it work? Yes, the Industrial Date Code is Sunday 03/05/20

But of course, it didn't work with the "%A %G-W%V-%u" format. So if I ever need this format, I'll have to study how to adapt myself to the UCRT. Thanks, Robert.

P.S.: To get the May 3, 2020 format of the forum, use "MMM dd, yyyy"

Hi jj2007:

Adapt? Yes !

“Intelligence is the ability to adapt to change.” – Stephen Hawking

Both, FreeBASIC-1.07.1-win32-gcc-8.1.0 and FreeBASIC-1.07.1-win64-gcc-8.1.0 contain the libucrtbase library. The simplest way to use it, until a complete up-to-date ucrtbase.bi is created, is to copy crt.bi to ucrtbase.bi and then, in the newly created ucrtbase.bi, change the line that reads

Code: Select all

# inclib "msvcrt"

to

Code: Select all

# inclib "ucrtbase"

and then in your programs that use C runtime functions, instead of using

Code: Select all

#include "crt.bi"

in your code, you can use

Code: Select all

#include "ucrtbase.bi"

If you are compiling fbc from source then you must remember to copy the libucrtbase library from your compiler to the appropriate fbc location and also if your compiler has libucrt, if you want to, also copy that library to the appropriate fbc location. The latest Nuwen compiler has both libraries, the latest MinGW-W64 has only libucrtbase. The latest Equation compilers have neither UCrt library.