On Saturday 19 October 2024 00:10:09 Martin Storsjö wrote: > On Fri, 18 Oct 2024, Pali Rohár wrote: > > > > Liu Hao presented another option in the discussion as well - we could also > > > define __MSVCRT_VERSION__ to another value inbetween, as it currently is > > > 0x700 for msvcr70.dll, we could set it to 0x7FF, so that existing > > > comparisons with <= and >= behave mostly the same as before, while we can > > > explicitly check for whether we mean msvcrt.dll or msvcr70.dll in the > > > places > > > where we want to. > > > > 0x7FF has drawback, that <= and >= does not work for symbols available > > in Vista+ msvcrt.dll but which are not available in msvcr70.dll and > > msvcr71.dll. > > Yes, if we'd use 0x7FF we would still need to explicitly check for 0x7FF, > e.g. (== 0x7FF && vista) || (>= 0x800). > > > > But you're right that technically, msvcrt.dll is more of a 6.0 than a 7.0 > > > msvcrt (although it has gotten many additions on top of the original one > > > from MSVC 6.0). I guess we could use 0x6FF as well, to allow us to > > > distinguish that we mean msvcrt.dll as shipped with an OS, including > > > possibly all the new stuff that come with it in newer versions, rather > > > than > > > the strict msvcrt.dll from MSVC 6.0. > > > > It is needed to have special value (like 0x6FF) for __MSVCRT_VERSION__ > > when doing system version check? Because at the same time it is always > > needed to check also for _WIN32_WINNT. > > > > As you pointed out, adding more values or macros just make it more > > complex. And another possible value for __MSVCRT_VERSION__ just increase > > complexity too. > > > > So in my opinion reusing 0x600 with _WIN32_WINNT could be enough: > > > > #if (__MSVCRT_VERSION__ == 0x600 && _WIN32_WINNT >= 0x0600) > > > > > > I think that special value like 0x6FF just increase complexity and still > > it would be needed to write code as: > > > > #if (__MSVCRT_VERSION__ == 0x6FF && _WIN32_WINNT >= 0x0600) > > Yes, it doesn't change anything wrt complexity, we'd still need the same > amount of conditions and everything. > > It's only about whether we want to be able to distinguish between strictly > the MSVC 6.0 msvcrt.dll and the newer OS-provided ones.
I think we do not need to distinguish between MSVC 6.0 msvcrt.dll and os-system version of msvcrt.dll. os-system version is backward compatible with MSVC 6.0 (and also with 5.0 and 4.2), it has same name and ABI. Also mingw-w64 does not provide import library for MSVC 6.0 msvcrt.dll (neither for older versions 5.0 and 4.2), so there is no use case for distinguishing between 6.0 and os-version. And I do not see reason for introducing strict 6.0/5.0/4.2 import library, as the import library for os-system version of msvcrt.dll covers also msvc 6.0, 5.0 and 4.2 versions, thanks to backward compatibility. > You may be right that we don't need to distinguish that, as the _WIN32_WINNT > checks already give that aspect. And if there is a need to distinguish between the msvc 6.0 and os-system version for Windows XP (or Vista+ or any other) then _WIN32_WINNT is enough. Because msvc 6.0 is Windows 98 SE os-system library. So _WIN32_WINNT can fully cover this hypothetical situation. I'm looking at this problem from the perspective to make it as simple as possible - so do not introduce a new value for __MSVCRT_VERSION__, just because any new value makes it more complex. > In any case, we'd need to revisit all the existing version checks, it only > changes what version numbers we'd put into those checks. > > // Martin _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
