[Mingw-w64-public] [PATCH] headers: allow GetNumaHighestNodeNumber in Win10 19H1 UWP builds

2023-06-07 Thread Steve Lhomme 
It is not allowed in older SDK. It won't compile or won't link. The target DLL
will likely not have the function, so it should not be used when targetting 
older
Windows 10 versions in UWP mode.
---
 mingw-w64-headers/include/systemtopologyapi.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mingw-w64-headers/include/systemtopologyapi.h 
b/mingw-w64-headers/include/systemtopologyapi.h
index d94e42fe6..c83548b61 100644
--- a/mingw-w64-headers/include/systemtopologyapi.h
+++ b/mingw-w64-headers/include/systemtopologyapi.h
@@ -14,9 +14,11 @@
 extern "C" {
 #endif
 
-#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >= 
NTDDI_WIN10_19H1
   WINBASEAPI WINBOOL WINAPI GetNumaHighestNodeNumber (PULONG 
HighestNodeNumber);
+#endif
 
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
 #if _WIN32_WINNT >= 0x0601
   WINBASEAPI WINBOOL WINAPI GetNumaNodeProcessorMaskEx (USHORT Node, 
PGROUP_AFFINITY ProcessorMask);
 #endif
-- 
2.39.2



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] configure: Use ucrt for msvcrt by default.

2023-06-07 Thread Martin Storsjö 

On Thu, 8 Jun 2023, LIU Hao wrote:


There are also builds with clang, but clang expects UCRT anyway


This statement is untrue.

 * MSYS2: 
https://github.com/msys2/MINGW-packages/blob/bf2ba8f4bba3d14fdaa2572cffb4abd4e6791246/mingw-w64-crt-git/PKGBUILD#L65


Yes, the msys2 "clang*" environments are UCRT based. But you can also 
install and use Clang in the msys2 "mingw64" environment just fine:


https://packages.msys2.org/package/mingw-w64-x86_64-clang?repo=mingw64

 * llvm-mingw: 
https://github.com/mstorsjo/llvm-mingw/blob/7e8bcdc43c8b68dd25d39e583cb41dc21a0d6c22/build-mingw-w64.sh#L20


This is just a default for when whoever builds it doesn't set another 
preference.


I regularly test llvm-mingw with msvcrt too; for my local nightly builds, 
I use a rotating schedule, alternating the --with-default-msvcrt option 
between ucrt, ucrtbase and msvcrt. So if there's blocking breakage within 
either of them, I'll run into it within 3 days at most.


This includes testing the armv7/aarch64 targets with msvcrt, even if 
that's a rather contrieved setup that nobody probably would use in 
practice. But the toolchains that are built to default to msvcrt, also 
work for armv7/aarch64.


I also do a subset of releases that are based on msvcrt:
https://github.com/mstorsjo/llvm-mingw/releases/tag/20230603

So Clang doesn't have any specific requirement assuming UCRT.

// Martin



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/2] headers: Add wia.idl

2023-06-07 Thread Biswapriyo Nath 
> It should be easy to add them to Wine.

Never experienced that "easy"-ness.

> Compatibility with Windows SDK seems better, otherwise we'd miss support
> for things like "#include ".

OK, I shall try.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] configure: Use ucrt for msvcrt by default.

2023-06-07 Thread LIU Hao 
I agree that those are valid concerns. However, there is little we can do about it and it's unlikely 
to change over time. Do we want msvcrt-os to remain the default forever?


For your information, this is a non-exhaustive list of distributions that do not specify 
`--with-default-msvcrt` and will be affected:


  * Debian: https://sources.debian.org/src/mingw-w64/10.0.0-3/debian/rules/#L131
  * Ubuntu (likely): https://launchpad.net/ubuntu/+source/mingw-w64/10.0.0-3
  * ArchLinux: 
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mingw-w64-crt-git#n49
  * w64devkit: 
https://github.com/skeeto/w64devkit/blob/2617b474334610abb7e82fc12f656abb3622723f/Dockerfile#L219



And this is a non-exhaustive list of distributions that specify `--with-default-msvcrt` and will not 
be affected:


  * MSYS2: 
https://github.com/msys2/MINGW-packages/blob/bf2ba8f4bba3d14fdaa2572cffb4abd4e6791246/mingw-w64-crt-git/PKGBUILD#L76
  * mingw-builds: 
https://github.com/niXman/mingw-builds/blob/7ff96692a8032d893781523b311ac9b6cbbda0a1/scripts/mingw-w64-crt.sh#L84
  * winlibs: 
https://github.com/brechtsanders/winlibs_recipes/blob/4c3f8b781e83ff4aaff17e6c9d26928f62059376/recipes/mingw-w64.winlib#L584



There are also builds with clang, but clang expects UCRT anyway, so will not be 
affected:

  * MSYS2: 
https://github.com/msys2/MINGW-packages/blob/bf2ba8f4bba3d14fdaa2572cffb4abd4e6791246/mingw-w64-crt-git/PKGBUILD#L65
  * llvm-mingw: 
https://github.com/mstorsjo/llvm-mingw/blob/7e8bcdc43c8b68dd25d39e583cb41dc21a0d6c22/build-mingw-w64.sh#L20




--
Best regards,
LIU Hao



OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/2] headers: Add wia.idl

2023-06-07 Thread Jacek Caban via Mingw-w64-public 

On 6/7/23 19:46, Biswapriyo Nath wrote:

Do we need to reimplement 'wia.idl', instead of importing 'wia_lh.idl' and 
'wia_xp.idl' from Wine?

wia_lh.idl and wia_xp.idl in wine are missing many declarations.



It should be easy to add them to Wine.



Besides, wia_xp.h is just a stripped down version of wia_lh.h in
Windows SDK. So, adding just wia.idl is good enough.



Compatibility with Windows SDK seems better, otherwise we'd miss support 
for things like "#include ".



Jacek



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/2] headers: Add wia.idl

2023-06-07 Thread Biswapriyo Nath 
> Do we need to reimplement 'wia.idl', instead of importing 'wia_lh.idl' and 
> 'wia_xp.idl' from Wine?

wia_lh.idl and wia_xp.idl in wine are missing many declarations.
Besides, wia_xp.h is just a stripped down version of wia_lh.h in
Windows SDK. So, adding just wia.idl is good enough.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Define FLS_MAXIMUM_AVAILABLE as 4080 for WIN10_19H1

2023-06-07 Thread Luca Bacci 
Yes, looks good!

Thanks,
Luca


Da: LIU Hao 
Inviato: mercoledì, giugno 7, 2023 5:07:07 PM
A: Luca Bacci ; mingw-w64-public@lists.sourceforge.net 

Oggetto: Re: [Mingw-w64-public] [PATCH] Define FLS_MAXIMUM_AVAILABLE as 4080 
for WIN10_19H1

在 2023-06-07 22:47, Luca Bacci 写道:
> Indeed it's quite a strange macro, reminds me of
> https://devblogs.microsoft.com/oldnewthing/20160613-00/?p=93655

The macro `TLS_MINIMUM_AVAILABLE` also does not make much sense because the 
indexes 0, 1, 4, 16 and
64 are pre-allocated and will be skipped by `TlsAlloc()`. The number of 
guaranteed TLS slots is a
bit fewer than that.

Anyway, does the attached patch look good to you?


--
Best regards,
LIU Hao



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Define FLS_MAXIMUM_AVAILABLE as 4080 for WIN10_19H1

2023-06-07 Thread LIU Hao 

在 2023-06-07 22:47, Luca Bacci 写道:
Indeed it's quite a strange macro, reminds me of 
https://devblogs.microsoft.com/oldnewthing/20160613-00/?p=93655 


The macro `TLS_MINIMUM_AVAILABLE` also does not make much sense because the indexes 0, 1, 4, 16 and 
64 are pre-allocated and will be skipped by `TlsAlloc()`. The number of guaranteed TLS slots is a 
bit fewer than that.


Anyway, does the attached patch look good to you?


--
Best regards,
LIU Hao

From de676492b9e099956d12c3b2fea3b50c63dc30ae Mon Sep 17 00:00:00 2001
From: LIU Hao 
Date: Wed, 7 Jun 2023 22:59:02 +0800
Subject: [PATCH] crt: Bump `FLS_MAXIMUM_AVAILABLE` since Windows 10 19H1

Reference: 
https://learn.microsoft.com/en-us/windows-insider/archive/new-in-19h1#fls-slot-limit-increase
Suggested-by: Luca Bacci 
Signed-off-by: LIU Hao 
---
 mingw-w64-headers/include/winnt.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/mingw-w64-headers/include/winnt.h 
b/mingw-w64-headers/include/winnt.h
index 257efdc1b..354836968 100644
--- a/mingw-w64-headers/include/winnt.h
+++ b/mingw-w64-headers/include/winnt.h
@@ -4413,7 +4413,11 @@ typedef BYTE SE_SIGNING_LEVEL, *PSE_SIGNING_LEVEL;
   DWORD Flags;
 } JOB_SET_ARRAY,*PJOB_SET_ARRAY;
 
+#if NTDDI_VERSION >= NTDDI_WIN10_19H1
+#define FLS_MAXIMUM_AVAILABLE 4080
+#else
 #define FLS_MAXIMUM_AVAILABLE 128
+#endif
 #define TLS_MINIMUM_AVAILABLE 64
 
 #ifndef __MINGW_EXCPT_DEFINE_PSDK
-- 
2.41.0



OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Define FLS_MAXIMUM_AVAILABLE as 4080 for WIN10_19H1

2023-06-07 Thread Luca Bacci 
Typo there: *0x0602* is Windows 8

Luca

Inviato da Outlook per Android

From: Luca Bacci 
Sent: Wednesday, June 7, 2023 4:47:43 PM
To: LIU Hao ; mingw-w64-public@lists.sourceforge.net 

Subject: Re: [Mingw-w64-public] [PATCH] Define FLS_MAXIMUM_AVAILABLE as 4080 
for WIN10_19H1

Indeed it's quite a strange macro, reminds me of 
https://devblogs.microsoft.com/oldnewthing/20160613-00/?p=93655 :)

While writing a few tests for fiber local storage I found that the Windows SDK 
had a different value, so thought about updating the mingw-w64 headers. But 
actually I don't have any use for it myself.

_WIN32_WINNT seems more appropriate, but it's quite coarse grained. For 
example, 0x0600 is Vista, 0x0601 is Windows 7, 0x0802 is Windows 8 and so on. 
An increase by 1 corresponds to a new OS and not a new OS patch release. 
However MS may break that convention for newer values.

Thanks!
Luca

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Define FLS_MAXIMUM_AVAILABLE as 4080 for WIN10_19H1

2023-06-07 Thread Luca Bacci 
Indeed it's quite a strange macro, reminds me of 
https://devblogs.microsoft.com/oldnewthing/20160613-00/?p=93655 :)

While writing a few tests for fiber local storage I found that the Windows SDK 
had a different value, so thought about updating the mingw-w64 headers. But 
actually I don't have any use for it myself.

_WIN32_WINNT seems more appropriate, but it's quite coarse grained. For 
example, 0x0600 is Vista, 0x0601 is Windows 7, 0x0802 is Windows 8 and so on. 
An increase by 1 corresponds to a new OS and not a new OS patch release. 
However MS may break that convention for newer values.

Thanks!
Luca

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 2/2] headers: Allow SetDllDirectoryW/A API in Win10 19H1 UWP builds

2023-06-07 Thread LIU Hao 

在 2023-06-07 15:46, Steve Lhomme 写道:

The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 18362 Windows SDK.

It is not allowed in older SDK. It won't compile or won't link.
The target DLL [1] will likely not have the function, so it should not
be used when targeting older Windows 10 versions in UWP mode.

We already have api-ms-win-core-kernel32-legacy-l1-1-1
in windowsapp.

[1] 
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-kernel32-legacy-l1-1-1dll
---
  mingw-w64-headers/include/winbase.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)


Thanks. Pushed now.

--
Best regards,
LIU Hao



OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/2] headers: Add wia.idl

2023-06-07 Thread LIU Hao 

在 2023-06-07 01:32, Biswapriyo Nath 写道:

 From da3f44c338b40c51d0f289d8aebcaf45e6770ce8 Mon Sep 17 00:00:00 2001
From: Biswapriyo Nath
Date: Tue, 6 Jun 2023 21:46:02 +0530
Subject: [PATCH 1/2] headers: Add wia.idl

Tested 
withhttps://learn.microsoft.com/en-us/windows/win32/wia/-wia-creating-a-wia-device-manager

Signed-off-by: Biswapriyo Nath
---
  mingw-w64-headers/Makefile.am |   1 +
  mingw-w64-headers/include/wia.idl | 842 ++
  2 files changed, 843 insertions(+)
  create mode 100644 mingw-w64-headers/include/wia.idl


Do we need to reimplement 'wia.idl', instead of importing 'wia_lh.idl' and 
'wia_xp.idl' from Wine?


--
Best regards,
LIU Hao



OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] crt: Add a missing dependency for libmincore.a

2023-06-07 Thread LIU Hao 

在 2023-06-07 14:54, Martin Storsjö 写道:

95d1c1045537158542424570a9ec57a543052aa1 included
libapi-ms-win-core-heap-l1-1-0.a into libmincore.a, but didn't
add the necessary dependency in Makefile.am.

Signed-off-by: Martin Storsjö 
---
  mingw-w64-crt/Makefile.am | 1 +
  1 file changed, 1 insertion(+)


LGTM. Thanks.


--
Best regards,
LIU Hao



OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Define FLS_MAXIMUM_AVAILABLE as 4080 for WIN10_19H1

2023-06-07 Thread LIU Hao 

在 2023-06-06 21:26, Luca Bacci 写道:

Hi! Right, the Windows SDK defines FLS_MAXIMUM_AVAILABLE unconditionally, let's 
do the same here.


Sorry here was some confusion. As this value has been increased only since Windows 10, there really 
should be an `#if` check.


I was a bit uncertain about which macro to check: Conventionally it should be `_WIN32_WINNT`, 
however everything since Windows 10 is identified as `0x0A00`, including all versions prior to 19H1. 
Or, should we follow recent patches, do check for `NTDDI_VERSION >= NTDDI_WIN10_19H1`?


Additionally, I am curious how this macro is supposed to be useful? It's undocumented and 
unreferenced by any public headers.


--
Best regards,
LIU Hao



OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [RFC] Make Windows 10 DLLs closer to documentation

2023-06-07 Thread Steve Lhomme 

On 2023-06-07 15:35, LIU Hao wrote:

在 2023-06-07 13:55, Steve Lhomme 写道:
Indeed. I made a tool (private as I'm not sure how legally safe it is) 
to generate the .def files from the WACK XML files. I used it to find 
which DLLs are needed to export some functions. However, it seems that 
this export doesn't match any version of WindowsApp.lib (from 10240 to 
22261). So it's correct to remove all these calls. In this case the 
MarkDown doc is incorrect [10].


Just noticed another issue: Some x86 DEF files are now out of sync with 
the common ones, for example `api-ms-win-core-winrt-error-l1-1-1.def`.


Does your tool detect such differences, or are they intentional?


Not really. The lib-common files are generated from 
SupportedAPIs-x64.xml and the lib32 files are generated from 
SupportedAPIs-x86.xml. There are a few differences between the two. I 
didn't check in WindowsApp.lib to check if the x64 and x86 are actually 
matching or not if there are actual differences.


In the end it doesn't really matter, if some API is not allowed in x86, 
it will not pass the WACK and so it should not be made usable.



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [RFC] Make Windows 10 DLLs closer to documentation

2023-06-07 Thread LIU Hao 

在 2023-06-07 13:55, Steve Lhomme 写道:
Indeed. I made a tool (private as I'm not sure how legally safe it is) to generate the .def files 
from the WACK XML files. I used it to find which DLLs are needed to export some functions. However, 
it seems that this export doesn't match any version of WindowsApp.lib (from 10240 to 22261). So it's 
correct to remove all these calls. In this case the MarkDown doc is incorrect [10].


Just noticed another issue: Some x86 DEF files are now out of sync with the common ones, for example 
`api-ms-win-core-winrt-error-l1-1-1.def`.


Does your tool detect such differences, or are they intentional?


--
Best regards,
LIU Hao



OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [RFC] Make Windows 10 DLLs closer to documentation

2023-06-07 Thread Steve Lhomme 

Hi,

On 2023-06-07 7:55, Steve Lhomme wrote:

Hi,

On 2023-06-06 18:16, LIU Hao wrote:

Attached are some patches about APIs yesterday.




   3) The change against `api-ms-win-security-cryptoapi-l1-1-0.def` 
should
  probably be reverted, as in 
9464ea241865f218cdfee9784bb6dc1731a23647.


These are found in the WACK, in WindowsApp.lib since 16299 and in the 
MarkDown doc [11]. We should actually allow them in the headers for 
16299+ UWP builds. That will save me a few patches in VLC contribs.


Actually, maybe we should not enable this. The WACK is OK with the call, 
it's in WindowsApp.lib as well *but* the headers don't allow it for 
WINAPI_PARTITION_APP, only for WINAPI_PARTITION_DESKTOP and 
WINAPI_PARTITION_PHONE_RESTRICTED (and some more). We don't support the 
other ones, but it's definitely not in WINAPI_PARTITION_APP.



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [RFC] Make Windows 10 DLLs closer to documentation

2023-06-07 Thread Steve Lhomme 

On 2023-06-07 11:47, LIU Hao wrote:

在 2023/6/7 13:55, Steve Lhomme 写道:

   1) `GetFileVersionInfoW` isn't mentioned anywhere. According to its
  documentation [3] it should be imported from
  `api-ms-win-core-version-l1-1-0.dll` but that DLL exports no such
  function.


I think you mean api-ms-win-core-version-l1-1-1. This is how it's 
exported in the WACK XML files and also what WindowsApp.lib uses (in 
19041).


That was not a typo. Microsoft documentation says

   Requirements
   (... ...)
   DLL    Api-ms-win-core-version-l1-1-0.dll


As I said the WACK, WindowsApp.lib and the doc in [7] all agree on the 
proper DLL name allowed. The table of the "visible" documentation is 
just wrong.


If the policy is to follow the wrong doc, it's OK with me. At least with 
this function, neither VLC nor its contribs use it.


The changes in api-ms-win-core-winrt-error-l1-1-1 are documented as 
belonging there. For example, for RoClearError it doesn't show in the 
webpage but it does show in the MarkDown file, in the "api_location" 
element [9].


OK maybe we can take those Markdown references, but should we keep those 
undocumented exports? (esp. those cryptographic ones.)


The undocumented ones, no.

Indeed. I made a tool (private as I'm not sure how legally safe it is) 
to generate the .def files from the WACK XML files. I used it to find 
which DLLs are needed to export some functions. However, it seems that 
this export doesn't match any version of WindowsApp.lib (from 10240 to 
22261). So it's correct to remove all these calls. In this case the 
MarkDown doc is incorrect [10].


The question is probably whether we should remove those that have been 
documented as 'removed'. I suspect so, because they should be called via 
`GetProcAddress()`.


My understanding is that the API's are never removed from existing DLL. 
Newer DLLs with different names may not contain them.


For example if you take CLSIDFromString [1] it moved from 
api-ms-win-core-com-l1-1-1 to  api-ms-win-core-com-l1-1-0. This is also 
reflected in the WindowsApp.lib for 10240 and 16299. But if I look at my 
system, the format DLL doesn't exist, only the latter. So an app 
compiled for UWP before 16299 may not work properly in newer Windows 
versions. Maybe the UWP package needs to list these dependencies and 
MSVC add them.


In mingw-w64 it's defined in both and libwindowsapp.a and contains both. 
Not sure which one it will be when linking...


BTW, since the online doc is now generated from the MarkDown files in 
that sdk-api repo, would it make sense to put some tools in mingw-w64 
to parse those files and extract some data. I have some Python code 
that parses the frontmatter part of files to find various information. 
For example we could verify that the headers match the minimum allowed 
version for each API entry.


The issue about such a tool and recent patches is that the stdcall 
suffixes have to be checked manually. (`HSTRING_UserFree64` etc. at this 
moment does not have a correct suffix.)


For headers, I don't think it's possible to do a tool that changes the 
headers accordingly. I don't have one. It can just tell you which API is 
correct and which ones are not.


Things could get worse if Microsoft will remove more in the future. 
'minimum allowed version' might not even make much sense if something 
gets removed, and as a result there could have to be a 'maximum allowed 
version'.


I'm not aware of API removal nor API that used to be allowed in UWP and 
then removed. In the MS SDK it would just mean using different headers 
and WindowsApp.lib for that new SDK. In our case we can handle it with 
NTDDI_VERSION or _WIN32_WINNT in headers. In libwindowsapp.a it's 
trickier. We would need a different one for each SDK target.



--
Best regards,
LIU Hao



[1] 
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-com-l1-1-1dll
[2] 
https://github.com/MicrosoftDocs/sdk-api/blob/780ec86ec4992638894e184beed82690d84b0308/sdk-api-src/content/winver/nf-winver-getfileversioninfow.md?plain=1#L42



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [RFC] Make Windows 10 DLLs closer to documentation

2023-06-07 Thread LIU Hao 

在 2023/6/7 13:55, Steve Lhomme 写道:

   1) `GetFileVersionInfoW` isn't mentioned anywhere. According to its
  documentation [3] it should be imported from
  `api-ms-win-core-version-l1-1-0.dll` but that DLL exports no such
  function.


I think you mean api-ms-win-core-version-l1-1-1. This is how it's exported in the WACK XML files and 
also what WindowsApp.lib uses (in 19041).


That was not a typo. Microsoft documentation says

  Requirements
  (... ...)
  DLL   Api-ms-win-core-version-l1-1-0.dll


The changes in api-ms-win-core-winrt-error-l1-1-1 are documented as belonging there. For example, 
for RoClearError it doesn't show in the webpage but it does show in the MarkDown file, in the 
"api_location" element [9].


OK maybe we can take those Markdown references, but should we keep those undocumented exports? (esp. 
those cryptographic ones.)



Indeed. I made a tool (private as I'm not sure how legally safe it is) to generate the .def files 
from the WACK XML files. I used it to find which DLLs are needed to export some functions. However, 
it seems that this export doesn't match any version of WindowsApp.lib (from 10240 to 22261). So it's 
correct to remove all these calls. In this case the MarkDown doc is incorrect [10].


The question is probably whether we should remove those that have been documented as 'removed'. I 
suspect so, because they should be called via `GetProcAddress()`.



BTW, since the online doc is now generated from the MarkDown files in that sdk-api repo, would it 
make sense to put some tools in mingw-w64 to parse those files and extract some data. I have some 
Python code that parses the frontmatter part of files to find various information. For example we 
could verify that the headers match the minimum allowed version for each API entry.


The issue about such a tool and recent patches is that the stdcall suffixes have to be checked 
manually. (`HSTRING_UserFree64` etc. at this moment does not have a correct suffix.)


Things could get worse if Microsoft will remove more in the future. 'minimum allowed version' might 
not even make much sense if something gets removed, and as a result there could have to be a 
'maximum allowed version'.



--
Best regards,
LIU Hao



OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 1/2] headers: enabled LoadLibraryEx flags in Win10 19H1 UWP builds

2023-06-07 Thread Steve Lhomme 
---
 mingw-w64-headers/include/libloaderapi.h | 48 
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/mingw-w64-headers/include/libloaderapi.h 
b/mingw-w64-headers/include/libloaderapi.h
index 00aa50f2a..6a5f59ed4 100644
--- a/mingw-w64-headers/include/libloaderapi.h
+++ b/mingw-w64-headers/include/libloaderapi.h
@@ -50,30 +50,6 @@ extern "C" {
 #define RESOURCE_ENUM_MODULE_EXACT (0x0010)
 
 #define SUPPORT_LANG_NUMBER 32
-
-#define DONT_RESOLVE_DLL_REFERENCES 0x1
-#define LOAD_LIBRARY_AS_DATAFILE 0x2
-#define LOAD_WITH_ALTERED_SEARCH_PATH 0x8
-#define LOAD_IGNORE_CODE_AUTHZ_LEVEL 0x10
-#define LOAD_LIBRARY_AS_IMAGE_RESOURCE 0x20
-#define LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE 0x40
-#define LOAD_LIBRARY_REQUIRE_SIGNED_TARGET 0x80
-#define LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR 0x100
-#define LOAD_LIBRARY_SEARCH_APPLICATION_DIR 0x200
-#define LOAD_LIBRARY_SEARCH_USER_DIRS 0x400
-#define LOAD_LIBRARY_SEARCH_SYSTEM32 0x800
-#define LOAD_LIBRARY_SEARCH_DEFAULT_DIRS 0x1000
-
-#if (NTDDI_VERSION >= NTDDI_WIN10_RS1)
-#define LOAD_LIBRARY_SAFE_CURRENT_DIRS 0x2000
-#define LOAD_LIBRARY_SEARCH_SYSTEM32_NO_FORWARDER 0x4000
-#else
-#define LOAD_LIBRARY_SEARCH_SYSTEM32_NO_FORWARDER LOAD_LIBRARY_SEARCH_SYSTEM32
-#endif
-
-#if (NTDDI_VERSION >= NTDDI_WIN10_RS2)
-#define LOAD_LIBRARY_OS_INTEGRITY_CONTINUITY 0x8000
-#endif
 #endif /* WINAPI_PARTITION_DESKTOP */
 
 #define GET_MODULE_HANDLE_EX_FLAG_PIN (0x1)
@@ -166,6 +142,30 @@ typedef const REDIRECTION_DESCRIPTOR 
*PCREDIRECTION_DESCRIPTOR;
 #endif
 
 #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >= 
NTDDI_WIN10_19H1
+#define DONT_RESOLVE_DLL_REFERENCES 0x1
+#define LOAD_LIBRARY_AS_DATAFILE 0x2
+#define LOAD_WITH_ALTERED_SEARCH_PATH 0x8
+#define LOAD_IGNORE_CODE_AUTHZ_LEVEL 0x10
+#define LOAD_LIBRARY_AS_IMAGE_RESOURCE 0x20
+#define LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE 0x40
+#define LOAD_LIBRARY_REQUIRE_SIGNED_TARGET 0x80
+#define LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR 0x100
+#define LOAD_LIBRARY_SEARCH_APPLICATION_DIR 0x200
+#define LOAD_LIBRARY_SEARCH_USER_DIRS 0x400
+#define LOAD_LIBRARY_SEARCH_SYSTEM32 0x800
+#define LOAD_LIBRARY_SEARCH_DEFAULT_DIRS 0x1000
+
+#if (NTDDI_VERSION >= NTDDI_WIN10_RS1)
+#define LOAD_LIBRARY_SAFE_CURRENT_DIRS 0x2000
+#define LOAD_LIBRARY_SEARCH_SYSTEM32_NO_FORWARDER 0x4000
+#else
+#define LOAD_LIBRARY_SEARCH_SYSTEM32_NO_FORWARDER LOAD_LIBRARY_SEARCH_SYSTEM32
+#endif
+
+#if (NTDDI_VERSION >= NTDDI_WIN10_RS2)
+#define LOAD_LIBRARY_OS_INTEGRITY_CONTINUITY 0x8000
+#endif
+
   WINBASEAPI HRSRC WINAPI FindResourceExW (HMODULE hModule, LPCWSTR lpType, 
LPCWSTR lpName, WORD wLanguage);
   WINBASEAPI HMODULE WINAPI GetModuleHandleA (LPCSTR lpModuleName);
   WINBASEAPI HMODULE WINAPI GetModuleHandleW (LPCWSTR lpModuleName);
-- 
2.39.2



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 2/2] headers: Allow SetDllDirectoryW/A API in Win10 19H1 UWP builds

2023-06-07 Thread Steve Lhomme 
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 18362 Windows SDK.

It is not allowed in older SDK. It won't compile or won't link.
The target DLL [1] will likely not have the function, so it should not
be used when targeting older Windows 10 versions in UWP mode.

We already have api-ms-win-core-kernel32-legacy-l1-1-1
in windowsapp.

[1] 
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-kernel32-legacy-l1-1-1dll
---
 mingw-w64-headers/include/winbase.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-headers/include/winbase.h 
b/mingw-w64-headers/include/winbase.h
index 050c5e7d4..ad8f069c4 100644
--- a/mingw-w64-headers/include/winbase.h
+++ b/mingw-w64-headers/include/winbase.h
@@ -2136,8 +2136,6 @@ typedef enum FILE_FLUSH_MODE {
 #define GET_SYSTEM_WOW64_DIRECTORY_NAME_T_T 
__MINGW_NAME_UAW_EXT(GET_SYSTEM_WOW64_DIRECTORY_NAME,T)
 #endif
 
-  WINBASEAPI WINBOOL WINAPI SetDllDirectoryA (LPCSTR lpPathName);
-  WINBASEAPI WINBOOL WINAPI SetDllDirectoryW (LPCWSTR lpPathName);
   WINBASEAPI DWORD WINAPI GetDllDirectoryA (DWORD nBufferLength, LPSTR 
lpBuffer);
   WINBASEAPI DWORD WINAPI GetDllDirectoryW (DWORD nBufferLength, LPWSTR 
lpBuffer);
 
@@ -2167,6 +2165,8 @@ typedef enum FILE_FLUSH_MODE {
 
 
 #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >= 
NTDDI_WIN10_19H1
+  WINBASEAPI WINBOOL WINAPI SetDllDirectoryA (LPCSTR lpPathName);
+  WINBASEAPI WINBOOL WINAPI SetDllDirectoryW (LPCWSTR lpPathName);
   WINBASEAPI HRSRC WINAPI FindResourceW (HMODULE hModule, LPCWSTR lpName, 
LPCWSTR lpType);
 
 #define FindResource __MINGW_NAME_AW(FindResource)
-- 
2.39.2



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] crt: Add a missing dependency for libmincore.a

2023-06-07 Thread Martin Storsjö 
95d1c1045537158542424570a9ec57a543052aa1 included
libapi-ms-win-core-heap-l1-1-0.a into libmincore.a, but didn't
add the necessary dependency in Makefile.am.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-crt/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 874382cfc..963df274e 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -2066,6 +2066,7 @@ endif
%/libapi-ms-win-core-file-l2-1-2.a \
%/libapi-ms-win-core-firmware-l1-1-0.a \
%/libapi-ms-win-core-handle-l1-1-0.a \
+   %/libapi-ms-win-core-heap-l1-1-0.a \
%/libapi-ms-win-core-heap-l1-2-0.a \
%/libapi-ms-win-core-interlocked-l1-1-0.a \
%/libapi-ms-win-core-interlocked-l1-2-0.a \
-- 
2.34.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/2] crt: add new found API entries api-ms-win-*.def

2023-06-07 Thread Steve Lhomme 

On 2023-06-06 10:26, Martin Storsjö wrote:

On Thu, 1 Jun 2023, Steve Lhomme wrote:

The parameters size in lib32 were generated from values found in other 
.def

files of lib32.
---


I'm sorry to say, but this patch removed a lot of manual handmade 
customizations to the api-ms-win-crt-*.def files.


In particular, this now shows up as linker errors when trying to 
bootstrap a new toolchain:


     ld.lld: error: duplicate symbol: __tzset
     >>> defined at ../crt/ucrtbase_compat.c:135
     >>>
libmsvcrt.a(lib32_libucrt_extra_a-ucrtbase_compat.o)

     >>> defined at api-ms-win-crt-time-l1-1-0.dll

Let's have a look at the questionable bits here:

diff --git 
a/mingw-w64-crt/lib-common/api-ms-win-core-version-l1-1-1.def 
b/mingw-w64-crt/lib-common/api-ms-win-core-version-l1-1-1.def

index ddbdd1d6c..a4901802f 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-core-version-l1-1-1.def
+++ b/mingw-w64-crt/lib-common/api-ms-win-core-version-l1-1-1.def
@@ -4,5 +4,5 @@ EXPORTS

GetFileVersionInfoExW
GetFileVersionInfoSizeExW
-VerFindFileW
+GetFileVersionInfoW
VerQueryValueW


This removes a function that used to be here. Is that right/expected?


VerFindFileW may be in there, the doc [1] says it's in 
Api-ms-win-core-version-l1-1-0. Although the markdown says it's in 
api-ms-win-core-version-l1-1-1 as well [2]. But it's not part of any 
WindowsApp.lib at all. IMO it should only be winver.def. I think 
WindowsApp.lib is the more accurate doc of all (see other email about 
bogus doc).


We may decide to add the API's that are actually in the DLLs on our 
system. But then that means that our libwindowsapp.a allows more API 
than the MS one.


diff --git 
a/mingw-w64-crt/lib-common/api-ms-win-core-winrt-error-l1-1-1.def 
b/mingw-w64-crt/lib-common/api-ms-win-core-winrt-error-l1-1-1.def

index bd5ef539c..2c70f3d9b 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-core-winrt-error-l1-1-1.def
+++ b/mingw-w64-crt/lib-common/api-ms-win-core-winrt-error-l1-1-1.def
@@ -9,8 +9,6 @@ RoClearError
RoFailFastWithErrorContext
RoGetErrorReportingFlags
RoGetMatchingRestrictedErrorInfo
-RoInspectCapturedStackBackTrace
-RoInspectThreadErrorInfo
RoOriginateError
RoOriginateErrorW
RoOriginateLanguageException


This removes functions, is that right/expected?


Yes, they are not in any WindowsApp.lib.

diff --git 
a/mingw-w64-crt/lib-common/api-ms-win-core-winrt-string-l1-1-0.def 
b/mingw-w64-crt/lib-common/api-ms-win-core-winrt-string-l1-1-0.def

index c1636e1c6..127d74961 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-core-winrt-string-l1-1-0.def
+++ b/mingw-w64-crt/lib-common/api-ms-win-core-winrt-string-l1-1-0.def
@@ -19,7 +19,6 @@ WindowsDeleteStringBuffer
WindowsDuplicateString
WindowsGetStringLen
WindowsGetStringRawBuffer
-WindowsInspectString
WindowsIsStringEmpty
WindowsPreallocateStringBuffer
WindowsPromoteStringBuffer


Also a removal.


Also not in any WindowsApp.lib.

diff --git 
a/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def 
b/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def

index 45ae728ba..8d70bd626 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def
@@ -3,8 +3,7 @@ LIBRARY api-ms-win-crt-filesystem-l1-1-0
EXPORTS

_access
-; access is provided as an alias for __mingw_access
-; access == _access
+access == _access


Here we explicitly say that this is commented out, manually, for 
specific reasons. Please don't undo such things!


Yes, sorry about that. My script had fixes for some of them, but not all 
of them. My intention was to updated things for libwindowsapp.a. I 
didn't realize a lot of these are used for ucrt instead.



_access_s
_chdir
chdir == _chdir
@@ -12,12 +11,12 @@ _chdrive
_chmod
chmod == _chmod
_findclose
-_findfirst == _findfirst64
+_findfirst == _findfirst32


These are intentionally set to the 64 bit version, since our UCRT 
environments default to 64 bit time_t, iirc. Lots of similar changes below.



_fstat64i32
_fullpath
+_getcwd
+getcwd == _getcwd
+_getdcwd
_getdiskfree


These symbols are in api-ms-win-crt-stdio-l1-1-0.def already, are they 
duplicated in api-ms-win-crt-filesystem-l1-1-0.def now too?


Given these 2 DLLs are part of ucrt, I suppose a duplicate is not good 
there. So these duplicates should be reverted. Basically, anything that 
is not included in windowsapp should be reverted for now.


diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def 
b/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def

index fd793fe82..344acd56e 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def
@@ -18,13 +18,13 @@ _get_heap_handle
_heapchk
_heapmin
_heapwalk
-heapwalk == _heapwalk


This was a manually set up alias, don't remove.


_malloc_base
_msize
_query_new_handler
_query_new_mode
_realloc_base
_recalloc
+_resetstkoflw
_set_new_mode
calloc
free

Re: [Mingw-w64-public] [PATCH] crt: Revert changes to api-ms-win-crt-*.def

2023-06-07 Thread Steve Lhomme 

Sorry about that, my "tool" has a few bugs. I didn't notice these changes.

On 2023-06-06 10:27, Martin Storsjö wrote:

These removed lots of manual modifications from these CRT specific
import libraries, modifications that are essential to how the UCRT
is linked.

Signed-off-by: Martin Storsjö 
---
  .../api-ms-win-crt-filesystem-l1-1-0.def  | 12 ---
  .../lib-common/api-ms-win-crt-heap-l1-1-0.def |  2 +-
  .../api-ms-win-crt-multibyte-l1-1-0.def   |  3 ++-
  .../api-ms-win-crt-process-l1-1-0.def | 17 +++
  .../api-ms-win-crt-stdio-l1-1-0.def   |  5 -
  .../api-ms-win-crt-string-l1-1-0.def  | 11 --
  .../lib-common/api-ms-win-crt-time-l1-1-0.def | 21 +--
  7 files changed, 52 insertions(+), 19 deletions(-)

diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def 
b/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def
index 8d70bd626..45ae728ba 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def
@@ -3,7 +3,8 @@ LIBRARY api-ms-win-crt-filesystem-l1-1-0
  EXPORTS
  
  _access

-access == _access
+; access is provided as an alias for __mingw_access
+; access == _access
  _access_s
  _chdir
  chdir == _chdir
@@ -11,12 +12,12 @@ _chdrive
  _chmod
  chmod == _chmod
  _findclose
-_findfirst == _findfirst32
+_findfirst == _findfirst64
  _findfirst32
  _findfirst32i64
  _findfirst64
  _findfirst64i32
-_findnext == _findnext32
+_findnext == _findnext64
  _findnext32
  _findnext32i64
  _findnext64
@@ -26,9 +27,6 @@ _fstat32i64
  _fstat64
  _fstat64i32
  _fullpath
-_getcwd
-getcwd == _getcwd
-_getdcwd
  _getdiskfree
  _getdrive
  _getdrives
@@ -64,8 +62,6 @@ _wfindnext32i64
  _wfindnext64
  _wfindnext64i32
  _wfullpath
-_wgetcwd
-_wgetdcwd
  _wmakepath
  _wmakepath_s
  _wmkdir
diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def 
b/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def
index 344acd56e..fd793fe82 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def
@@ -18,13 +18,13 @@ _get_heap_handle
  _heapchk
  _heapmin
  _heapwalk
+heapwalk == _heapwalk
  _malloc_base
  _msize
  _query_new_handler
  _query_new_mode
  _realloc_base
  _recalloc
-_resetstkoflw
  _set_new_mode
  calloc
  free
diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-multibyte-l1-1-0.def 
b/mingw-w64-crt/lib-common/api-ms-win-crt-multibyte-l1-1-0.def
index 9ae47af16..86d22500b 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-multibyte-l1-1-0.def
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-multibyte-l1-1-0.def
@@ -70,7 +70,8 @@ _mbbtombc
  _mbbtombc_l
  _mbbtype
  _mbbtype_l
-_mbcasemap
+; DATA added manually
+_mbcasemap DATA
  _mbccpy
  _mbccpy_l
  _mbccpy_s
diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-process-l1-1-0.def 
b/mingw-w64-crt/lib-common/api-ms-win-crt-process-l1-1-0.def
index a3ad9d75f..dafa456a5 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-process-l1-1-0.def
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-process-l1-1-0.def
@@ -4,23 +4,40 @@ EXPORTS
  
  _beep

  _cwait
+cwait == _cwait
  _execl
+execl == _execl
  _execle
+execle == _execle
  _execlp
+execlp == _execlp
  _execlpe
+execlpe == _execlpe
  _execv
+execv == _execv
  _execve
+execve == _execve
  _execvp
+execvp == _execvp
  _execvpe
+execvpe == _execvpe
  _loaddll
  _spawnl
+spawnl == _spawnl
  _spawnle
+spawnle == _spawnle
  _spawnlp
+spawnlp == _spawnlp
  _spawnlpe
+spawnlpe == _spawnlpe
  _spawnv
+spawnv == _spawnv
  _spawnve
+spawnve == _spawnve
  _spawnvp
+spawnvp == _spawnvp
  _spawnvpe
+spawnvpe == _spawnvpe
  _unloaddll
  _wexecl
  _wexecle
diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def 
b/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def
index 460fd12ef..d59859ced 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def
@@ -85,6 +85,7 @@ _getws_s
  _isatty
  isatty == _isatty
  _kbhit
+kbhit == _kbhit
  _locking
  _lseek
  lseek == _lseek
@@ -96,8 +97,10 @@ _open
  open == _open
  _open_osfhandle
  _pclose
+pclose == _pclose
  _pipe
  _popen
+popen == _popen
  _putc_nolock
  _putw
  putw == _putw
@@ -134,6 +137,7 @@ _wmktemp
  _wmktemp_s
  _wopen
  _wpopen
+wpopen == _wpopen
  _write
  write == _write
  _wsopen
@@ -175,7 +179,6 @@ getwc
  getwchar
  putc
  putchar
-putenv
  puts
  putwc
  putwchar
diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-string-l1-1-0.def 
b/mingw-w64-crt/lib-common/api-ms-win-crt-string-l1-1-0.def
index 78c9d163c..dcce58dbc 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-string-l1-1-0.def
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-string-l1-1-0.def
@@ -51,7 +51,10 @@ _strcoll_l
  _strdup
  strdup == _strdup
  _stricmp
+_strcmpi == _stricmp
+strcmpi == _stricmp
  stricmp == _stricmp
+strcasecmp == _stricmp