Import of non-Windows XP API functions

[void2012]

Hi! A simple Hello World program using <iostream> imports WinAPI calls which aren't present on Windows XP, such as:
LCMapStringEx, LCIDToLocaleName, InitializeSListHead, InitializeCriticalSectionEx, GetLocaleInfoEx
VC-LTL version: msvcrt 5.1.2600.0 (support Windows XP/2003 or leater)
Visual Studio 2022 version: 17.12.3
Build tools: LLVM (clang-cl)
Linker minimum required option: 5.01
C++ standard: /std:c++latest
Runtime library: /MT
Code:
#include <iostream> int main() { std::cout << "Hello, World!\n"; }

[mingkuang-Chuyu]

Please install YY-Thunks, or install VC-LTL by nuget.

[void2012]

YY-thunks seems like a product of reverse engineering. I'm not complaining, but anti-viruses aren't happy with compiled binaries.

Maybe it's possible to fork MSVC STL and remove NT6+ dependencies?

[mingkuang-Chuyu]

@void2012 Hi, you can directly delete all the *.exe files, they are optional.

• YY.Depends.Analyzer.exe : Windows PE Depends Check Tool.
• MinimumRequiredVersionHelper.exe : Fix PE Minimum Required Version（Windows 2000 support only）

VC-LTL 3.0 is the implementation of stl, but with the passage of time, the STL version has become more and more with VS iterations. As a result, we need to maintain many versions, which is difficult to maintain continuously. At the same time, the VC-LTL is getting bigger and bigger...

[void2012]

No, the issue is not those executables. Rather, binaries compiled with VC-LTL and YY-thunks. I think there is a better approach than to reimplement NT calls with a questionable third-party reverse engineered thunk implementation.

MSVC STL was made open source in 2019 with the Apache license which allowed to use some code from llvm. Notably, from libc++.

libc++ uses three different flavors of threading system: pthreads, c11 threads and win32 threads. The latter two use NT6 WinAPI calls, while pthreads are implemented via winpthreads which has has support down to NT4.

I guess at this point we don't really care about the possible ABI change, I think one can simply reimplement MSVC STL threads with winpthreads implementation from libc++, as the license allows to do it.

An another point of interest is std::filesystem and parallel algorithms. https://github.com/gulrak/filesystem/tree/master/ implementation is fine, however symlink function is not supported prior to Windows Vista(I guess it's enough to have std::filesystem as whole but just without symlinks)

Parallel algorithms on MSVC STL work via Win32 threadpool functions, available since Windows 7. As of now, neither libc++ nor libstdc++ fully implement them but existing implementation work well with tbb library.

[MouriNaruto]

Actually, using Windows API shim instead of forking MSVC STL, will improve the source code maintenance experience and reduce the NuGet package size massively.

Kenji Mouri

[mingkuang-Chuyu]

1. We need a universal solution. And only stl compatible with Windows 7 does not have much practical value, and many libraries have abandoned compatibility with Windows 7. Who's going to be Windows 7 or XP compatible?

2. We don't have the energy to maintain those libraries. Whoever does it, but I can't.

3. Lower the barrier to entry, because ABI is fully compatible with Microsoft, and users don't have to rebuild when using VC-LTL.

In the light of the foregoing, this proposal is not considered.

[void2012]

I am considering doing my own fork of MSVC STL at this point. Can you add my fork as an optional dependency if I actually manage to implement it?

[mingkuang-Chuyu]

@void2012
Your solution is similar to VC-LTL 4. You may want to consider developing based on VC-LTL 4.

https://github.com/Chuyu-Team/VC-LTL/tree/master/VC