[Mingw-w64-public] [PATCH] headers: move PPROC_THREAD_ATTRIBUTE_LIST in PARTITION_APP
It's needed by CreateProcess (via STARTUPINFOEX) which is available in UWP apps. --- mingw-w64-headers/include/processthreadsapi.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mingw-w64-headers/include/processthreadsapi.h b/mingw-w64-headers/include/processthreadsapi.h index ec07a5fe3..334463436 100644 --- a/mingw-w64-headers/include/processthreadsapi.h +++ b/mingw-w64-headers/include/processthreadsapi.h @@ -199,12 +199,12 @@ DEFINE_ENUM_FLAG_OPERATORS(MACHINE_ATTRIBUTES); WINBASEAPI WINBOOL WINAPI SetThreadSelectedCpuSetMasks (HANDLE Thread, PGROUP_AFFINITY CpuSetMasks, USHORT CpuSetMaskCount); #endif + typedef struct _PROC_THREAD_ATTRIBUTE_LIST *PPROC_THREAD_ATTRIBUTE_LIST, *LPPROC_THREAD_ATTRIBUTE_LIST; + #endif /* WINAPI_PARTITION_APP */ #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) - typedef struct _PROC_THREAD_ATTRIBUTE_LIST *PPROC_THREAD_ATTRIBUTE_LIST, *LPPROC_THREAD_ATTRIBUTE_LIST; - WINBASEAPI HANDLE WINAPI CreateRemoteThread (HANDLE hProcess, LPSECURITY_ATTRIBUTES lpThreadAttributes, SIZE_T dwStackSize, LPTHREAD_START_ROUTINE lpStartAddress, LPVOID lpParameter, DWORD dwCreationFlags, LPDWORD lpThreadId); WINBASEAPI WINBOOL WINAPI TerminateThread (HANDLE hThread, DWORD dwExitCode); WINBASEAPI WINBOOL WINAPI SetProcessShutdownParameters (DWORD dwLevel, DWORD dwFlags); -- 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] headers: add WAVEFORMATEXTENSIBLE_IEC61937
This is used for HDMI passthrough [1].
[1]
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ksmedia/ns-ksmedia-waveformatextensible_iec61937
---
mingw-w64-headers/include/ksmedia.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/mingw-w64-headers/include/ksmedia.h
b/mingw-w64-headers/include/ksmedia.h
index cffb63800..8f6603005 100644
--- a/mingw-w64-headers/include/ksmedia.h
+++ b/mingw-w64-headers/include/ksmedia.h
@@ -722,6 +722,16 @@ typedef struct {
#define WAVE_FORMAT_EXTENSIBLE 0xFFFE
#endif
+#ifndef _WAVEFORMATEXTENSIBLE_IEC61937_
+#define _WAVEFORMATEXTENSIBLE_IEC61937_
+typedef struct {
+WAVEFORMATEXTENSIBLEFormatExt;
+DWORD dwEncodedSamplesPerSec;
+DWORD dwEncodedChannelCount;
+DWORD dwAverageBytesPerSec;
+} WAVEFORMATEXTENSIBLE_IEC61937, *PWAVEFORMATEXTENSIBLE_IEC61937;
+#endif /* _WAVEFORMATEXTENSIBLE_IEC61937_ */
+
typedef struct {
ULONG Flags;
ULONG Control;
--
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] headers: include some IEC61937 GUID
This is used for HDMI passthrough.
---
mingw-w64-headers/include/ksmedia.h | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/ksmedia.h
b/mingw-w64-headers/include/ksmedia.h
index c3f98a53b..cffb63800 100644
--- a/mingw-w64-headers/include/ksmedia.h
+++ b/mingw-w64-headers/include/ksmedia.h
@@ -652,8 +652,33 @@
DEFINE_GUIDSTRUCT("0002--0010-8000-00aa00389b71",KSDATAFORMAT_SUBTYPE_AD
DEFINE_WAVEFORMATEX_GUID(WAVE_FORMAT_MPEG)
DEFINE_GUIDSTRUCT("0050--0010-8000-00aa00389b71",KSDATAFORMAT_SUBTYPE_MPEG);
#define KSDATAFORMAT_SUBTYPE_MPEG DEFINE_GUIDNAMED(KSDATAFORMAT_SUBTYPE_MPEG)
+
+#define STATIC_KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL \
+ DEFINE_WAVEFORMATEX_GUID(WAVE_FORMAT_DOLBY_AC3_SPDIF)
+DEFINE_GUIDSTRUCT("0092--0010-8000-00aa00389b71",KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL);
+#define KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL
DEFINE_GUIDNAMED(KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL)
+
+#define STATIC_KSDATAFORMAT_SUBTYPE_IEC61937_DTS \
+ DEFINE_WAVEFORMATEX_GUID(WAVE_FORMAT_DOLBY_AC3_SPDIF)
+DEFINE_GUIDSTRUCT("0008--0010-8000-00aa00389b71",KSDATAFORMAT_SUBTYPE_IEC61937_DTS);
+#define KSDATAFORMAT_SUBTYPE_IEC61937_DTS
DEFINE_GUIDNAMED(KSDATAFORMAT_SUBTYPE_IEC61937_DTS)
#endif /* _INC_MMREG */
+#define STATIC_KSDATAFORMAT_SUBTYPE_IEC61937_DTS_HD\
+ 0x000b,0x0cea,0x0010,0x80,0x00,0x00,0xaa,0x00,0x38,0x9b 0x71
+DEFINE_GUIDSTRUCT("000b-0cea-0010-8000-00aa00389b71",KSDATAFORMAT_SUBTYPE_IEC61937_DTS_HD);
+#define KSDATAFORMAT_SUBTYPE_IEC61937_DTS_HD
DEFINE_GUIDNAMED(KSDATAFORMAT_SUBTYPE_IEC61937_DTS_HD)
+
+#define STATIC_KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL_PLUS\
+ 0x000a,0x0cea,0x0010,0x80,0x00,0x00,0xaa,0x00,0x38,0x9b,0x71
+DEFINE_GUIDSTRUCT("000a-0cea-0010-8000-00aa00389b71",KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL_PLUS);
+#define KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL_PLUS
DEFINE_GUIDNAMED(KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL_PLUS)
+
+#define STATIC_KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_MLP \
+ 0x000c,0x0cea,0x0010,0x80,0x00,0x00,0xaa,0x00,0x38,0x9b,0x71
+DEFINE_GUIDSTRUCT("000c-0cea-0010-8000-00aa00389b71",KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_MLP);
+#define KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_MLP
DEFINE_GUIDNAMED(KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_MLP)
+
#define STATIC_KSDATAFORMAT_SPECIFIER_VC_ID\
0xAD98D184,0xAAC3,0x11D0,0xA4,0x1C,0x00,0xA0,0xC9,0x22,0x31,0x96
DEFINE_GUIDSTRUCT("AD98D184-AAC3-11D0-A41C-00A0C9223196",KSDATAFORMAT_SPECIFIER_VC_ID);
@@ -4554,7 +4579,7 @@ typedef enum {
typedef enum _TunerDecoderLockType {
Tuner_LockType_None= 0x00,
Tuner_LockType_Within_Scan_Sensing_Range = 0x01,
- Tuner_LockType_Locked = 0x02
+ Tuner_LockType_Locked = 0x02
} TunerLockType;
#endif /*(_WIN32_WINNT >= 0x0601)*/
--
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] crt: Remove duplicates from api-ms-win-core-com
I didn't look at each function in each path, but in principile it should be OK. I originally added the functions based on what the WACK expects. But windowsapp only link to a single DLL in all versions of the Windows SDK and apparently always the same. On 2023-10-25 2:15, Mark Harmstone wrote: Signed-off-by: Mark Harmstone --- .../lib-common/api-ms-win-core-com-l1-1-1.def | 53 --- .../api-ms-win-core-com-l1-1-1_windowsapp.def | 53 --- .../lib32/api-ms-win-core-com-l1-1-1.def | 53 --- .../api-ms-win-core-com-l1-1-1_windowsapp.def | 53 --- 4 files changed, 212 deletions(-) diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-com-l1-1-1.def b/mingw-w64-crt/lib-common/api-ms-win-core-com-l1-1-1.def index b6c7448df..2b7189440 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-core-com-l1-1-1.def +++ b/mingw-w64-crt/lib-common/api-ms-win-core-com-l1-1-1.def @@ -2,58 +2,5 @@ LIBRARY api-ms-win-core-com-l1-1-1 EXPORTS -CLSIDFromProgID -CLSIDFromString -CoAddRefServerProcess -CoCreateFreeThreadedMarshaler -CoCreateGuid -CoCreateInstance -CoCreateInstanceEx -CoCreateInstanceFromApp -CoDecrementMTAUsage -CoDisconnectObject -CoFreeUnusedLibraries -CoFreeUnusedLibrariesEx -CoGetApartmentType -CoGetClassObject -CoGetContextToken -CoGetCurrentLogicalThreadId -CoGetInterfaceAndReleaseStream -CoGetMalloc -CoGetMarshalSizeMax -CoGetObjectContext -CoGetStandardMarshal -CoIncrementMTAUsage -CoInitializeEx -CoInitializeSecurity -CoLockObjectExternal -CoMarshalInterface -CoMarshalInterThreadInterfaceInStream CoRegisterActivationFilter -CoRegisterClassObject -CoRegisterPSClsid -CoReleaseMarshalData -CoReleaseServerProcess -CoResumeClassObjects -CoRevokeClassObject -CoSetProxyBlanket -CoSuspendClassObjects -CoSwitchCallContext -CoTaskMemAlloc -CoTaskMemFree -CoTaskMemRealloc -CoUninitialize -CoUnmarshalInterface -CoWaitForMultipleHandles -CoWaitForMultipleObjects -CreateStreamOnHGlobal -FreePropVariantArray -GetHGlobalFromStream -IIDFromString -ProgIDFromCLSID -PropVariantClear -PropVariantCopy RoGetAgileReference -StringFromCLSID -StringFromGUID2 -StringFromIID diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-com-l1-1-1_windowsapp.def b/mingw-w64-crt/lib-common/api-ms-win-core-com-l1-1-1_windowsapp.def index 2382640c8..98f5d0b44 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-core-com-l1-1-1_windowsapp.def +++ b/mingw-w64-crt/lib-common/api-ms-win-core-com-l1-1-1_windowsapp.def @@ -2,57 +2,4 @@ LIBRARY api-ms-win-core-com-l1-1-1 EXPORTS -CLSIDFromProgID -CLSIDFromString -CoAddRefServerProcess -CoCreateFreeThreadedMarshaler -CoCreateGuid -CoCreateInstance -CoCreateInstanceEx -CoCreateInstanceFromApp -CoDecrementMTAUsage -CoDisconnectObject -CoFreeUnusedLibraries -CoFreeUnusedLibrariesEx -CoGetApartmentType -CoGetClassObject -CoGetContextToken -CoGetCurrentLogicalThreadId -CoGetInterfaceAndReleaseStream -CoGetMalloc -CoGetMarshalSizeMax -CoGetObjectContext -CoGetStandardMarshal -CoIncrementMTAUsage -CoInitializeEx -CoInitializeSecurity -CoLockObjectExternal -CoMarshalInterface -CoMarshalInterThreadInterfaceInStream -CoRegisterClassObject -CoRegisterPSClsid -CoReleaseMarshalData -CoReleaseServerProcess -CoResumeClassObjects -CoRevokeClassObject -CoSetProxyBlanket -CoSuspendClassObjects -CoSwitchCallContext -CoTaskMemAlloc -CoTaskMemFree -CoTaskMemRealloc -CoUninitialize -CoUnmarshalInterface -CoWaitForMultipleHandles -CoWaitForMultipleObjects -CreateStreamOnHGlobal -FreePropVariantArray -GetHGlobalFromStream -IIDFromString -ProgIDFromCLSID -PropVariantClear -PropVariantCopy RoGetAgileReference -StringFromCLSID -StringFromGUID2 -StringFromIID diff --git a/mingw-w64-crt/lib32/api-ms-win-core-com-l1-1-1.def b/mingw-w64-crt/lib32/api-ms-win-core-com-l1-1-1.def index e59e1d0dc..15bd76222 100644 --- a/mingw-w64-crt/lib32/api-ms-win-core-com-l1-1-1.def +++ b/mingw-w64-crt/lib32/api-ms-win-core-com-l1-1-1.def @@ -2,58 +2,5 @@ LIBRARY api-ms-win-core-com-l1-1-1 EXPORTS -CLSIDFromProgID@8 -CLSIDFromString@8 -CoAddRefServerProcess@0 -CoCreateFreeThreadedMarshaler@8 -CoCreateGuid@4 -CoCreateInstance@20 -CoCreateInstanceEx@24 -CoCreateInstanceFromApp@24 -CoDecrementMTAUsage@4 -CoDisconnectObject@8 -CoFreeUnusedLibraries@0 -CoFreeUnusedLibrariesEx@8 -CoGetApartmentType@8 -CoGetClassObject@20 -CoGetContextToken@4 -CoGetCurrentLogicalThreadId@4 -CoGetInterfaceAndReleaseStream@12 -CoGetMalloc@8 -CoGetMarshalSizeMax@24 -CoGetObjectContext@8 -CoGetStandardMarshal@24 -CoIncrementMTAUsage@4 -CoInitializeEx@8 -CoInitializeSecurity@36 -CoLockObjectExternal@12 -CoMarshalInterface@24 -CoMarshalInterThreadInterfaceInStream@12 CoRegisterActivationFilter@4 -CoRegisterClassObject@20 -CoRegisterPSClsid@8 -CoReleaseMarshalData@4 -CoReleaseServerProcess@0 -CoResumeClassObjects@0 -CoRevokeClassObject@4 -CoSetProxyBlanket@32 -CoSuspendClassObjects@0 -CoSwitchCallContext@8 -CoTaskMemAlloc@4 -CoTaskMemFree@4 -CoTaskMemRealloc@8
Re: [Mingw-w64-public] [PATCH] crt: Add CancelSynchronousIo to api-ms-win-core-io
Hi, On 2023-10-13 2:58, Mark Harmstone wrote: I've just resent the patches, creating a new version for windowsapp where necessary to avoid pollution. I've sent them as a series because of Makefile.am, but they aren't actually interdependent. The "remove" patches are for the most part for b14caf2016, which added API set functions to mincore that should have been excluded from windowsapp. Steve, you might want to have a look at the psapi patch. You added K32QueryWorkingSet and K32QueryWorkingSetEx in 9cd1a0be3a a few months ago, but as far as I can see they're not in the official windowsapp, only mincore (version 10.0.19041.0). They are found in Windows 11 but not Windows 10. And also in Windows 8. And they are allowed by the WACK. ___ 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 CancelSynchronousIo to api-ms-win-core-io
On 2023-10-11 20:05, Mark Harmstone wrote: Thanks both. There's actually about 260 functions that "ought" to be in windowsapp.lib's API sets but aren't. CancelSynchronousIo was exposed in windowsapp in the Windows 8 SDK. But it hasn't been since then and is not allowed by the Windows App Certification Kit (WACK) either. If it's related to the WACK, that would certainly explain matters... though I do wish they'd make that clear in the documentation. If mincore and windowsapp linked DLL references keep being shared, windowsapp should have prevalence because it's still more or less valid, while mincore is dead. On the contrary, it looks like partial API sets are largely a windowsapp.lib problem, if you look at all the MS umbrella libraries (most of which aren't in mingw yet). So in this case I think CancelSynchronousIo should not be added to api-ms-win-core-io-l1-1-1. If someone really needs to link with that function, the documentation [1] says it's only available on desktop and should be linked through kernel32.lib. The documentation isn't to be trusted. CancelSynchronousIo is in onecore.lib, which is supposed to be the common subset of all Windows 10 OSes, as well as explicitly in windowscoreheadless.lib. If we can have onecore.lib then it's fine too. Martin, I suggest you ignore any of my patches that you haven't pushed so far. I'll resubmit, making sure not to pollute windowsapp. Thanks Mark ___ 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 CancelSynchronousIo to api-ms-win-core-io
Hi, On 2023-10-11 13:35, Martin Storsjö wrote: Hi, Explicitly pulling in Steve Lhomme to disuss this matter: On Tue, 3 Oct 2023, Mark Harmstone wrote: diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-io-l1-1-1.def b/mingw-w64-crt/lib-common/api-ms-win-core-io-l1-1-1.def index 9401e3d53..c13c4928b 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-core-io-l1-1-1.def +++ b/mingw-w64-crt/lib-common/api-ms-win-core-io-l1-1-1.def @@ -4,6 +4,7 @@ EXPORTS CancelIo CancelIoEx +CancelSynchronousIo CreateIoCompletionPort DeviceIoControl GetOverlappedResult So, the main issue is that both the mincore and windowsapp umbrella libraries link against api-ms-win-core-io-l1-1-1.dll. When linking with windowsapp, there's no CancelSynchronousIo symbol anywhere to link against, but when linking against mincore, this symbol does exist and is provided in that DLL. This means that if we apply this patch, our windowsapp import library also will expose CancelSynchronousIo even if the MS version doesn't. Steve, do you feel that this is ok? Or should we separate all the api-ms-win-* import libraries, into one version for mincore and one for windowsapp, to keep things strict and correct? I guess there's a potential risk, if there's e.g. a configure script, that tests whether the symbol can be linked, and uses it if available - such cases are broken if our umbrella import libraries export too many symbols. I guess there's also a risk, if e.g. windowsapp would be providing this symbol in another DLL; then our umbrella library would expose it in two forwarder DLLs, and it'd be up to the linker which one it ends up picking. What do you say Mark and Steve, is this ok with both of you? If it is, most of the rest of this patchset should be fine as well. If not, we'll need to spend a lot more effort on this... CancelSynchronousIo was exposed in windowsapp in the Windows 8 SDK. But it hasn't been since then and is not allowed by the Windows App Certification Kit (WACK) either. If mincore and windowsapp linked DLL references keep being shared, windowsapp should have prevalence because it's still more or less valid, while mincore is dead. So in this case I think CancelSynchronousIo should not be added to api-ms-win-core-io-l1-1-1. If someone really needs to link with that function, the documentation [1] says it's only available on desktop and should be linked through kernel32.lib. [1] https://learn.microsoft.com/en-us/windows/win32/fileio/cancelsynchronousio-func ___ 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] crt: Add missing API sets to windowsapp.lib
On 2023-09-29 10:33, Martin Storsjö wrote: On Fri, 29 Sep 2023, Steve Lhomme wrote: For the record, I some scripts to generate/update the files. Mostly using the "dumpbin /linkmember" results to generate them and check the changes depending on the Windows SDK version for each official Windows 10/11 builds. Yeah, I think I've got a script that does something similar to that as well. My main issue was that there was so many changes in the same patch making it hard to get an overview. As mentioned, there are many minor details that easily drown in the patches, like removal of RtlVirtualUnwind from lib-common, even if it does exist on x64 (but not x86). Anyway, Mark's patches reach essentially the same state as your patches, except for removals of symbols and def files. If those removals are important for your setup, let's handle them as separate patches later. Nope. Especially if they are wrong. // Martin ___ 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 2/2] crt: Add missing API sets to windowsapp.lib
For the record, I some scripts to generate/update the files. Mostly using the "dumpbin /linkmember" results to generate them and check the changes depending on the Windows SDK version for each official Windows 10/11 builds. The code is in a private repository as I'm not sure this is public information, especially the XML files from the Windows App Certification Kit to match what is allowed in UWP. But I can share it on demand. On 2023-09-27 15:05, Martin Storsjö wrote: On Mon, 25 Sep 2023, Mark Harmstone wrote: Some of these were added by the previous patch, and some are new. Signed-off-by: Mark Harmstone --- diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index 7f137b4f0..1b2caeab5 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -2029,6 +2029,7 @@ endif %/libapi-ms-win-core-com-l1-1-2.a \ %/libapi-ms-win-core-com-l1-1-3.a \ %/libapi-ms-win-core-com-midlproxystub-l1-1-0.a \ + %/libapi-ms-win-core-com-l1-1-0.a \ %/libapi-ms-win-core-comm-l1-1-0.a \ This is a stray change (it adds a duplicate l1-1-0.a dependency on mincore, while this patch touches windowsapp). Other than, I think this patchset looks good. Steve Lhomme sent a similar patchset on June 26th. I reviewed it (quite belatedly, sorry about that) on July 20th, where I requested it to be split into smaller pieces; that patchset both added new symbols and new def files, and removed other def files that weren't reachable with the mincore/windowsapp headers that he had compared with. I compared the end result of this patchset and Steve's, and this one should be a superset (after adding the extra two patches I just sent); there are still def files that might not be reachable with current MS import libraries, but if important, those can be pruned in a separate step. So if there aren't any objections to it, I would go ahead and push these two patches sometime soon. // Martin ___ 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
[Mingw-w64-public] [PATCH] include/process: fix bare DllMain/_CRT_INIT signature
The DWORD reason corresponds to an "unsigned long", not an "unsigned".
This is also how it's defined in the Windows SDK.
---
mingw-w64-headers/crt/process.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mingw-w64-headers/crt/process.h b/mingw-w64-headers/crt/process.h
index 08b73cf58..1ac39a064 100644
--- a/mingw-w64-headers/crt/process.h
+++ b/mingw-w64-headers/crt/process.h
@@ -138,10 +138,10 @@ extern "C" {
WINBOOL WINAPI _wCRT_INIT(HANDLE _HDllHandle,DWORD _Reason,LPVOID _Reserved);
extern WINBOOL (WINAPI *const _pRawDllMain)(HANDLE,DWORD,LPVOID);
#else
- int __stdcall DllMain(void *_HDllHandle,unsigned _Reason,void *_Reserved);
- int __stdcall _CRT_INIT(void *_HDllHandle,unsigned _Reason,void *_Reserved);
- int __stdcall _wCRT_INIT(void *_HDllHandle,unsigned _Reason,void *_Reserved);
- extern int (__stdcall *const _pRawDllMain)(void *,unsigned,void *);
+ int __stdcall DllMain(void *_HDllHandle,unsigned long _Reason,void
*_Reserved);
+ int __stdcall _CRT_INIT(void *_HDllHandle,unsigned long _Reason,void
*_Reserved);
+ int __stdcall _wCRT_INIT(void *_HDllHandle,unsigned long _Reason,void
*_Reserved);
+ extern int (__stdcall *const _pRawDllMain)(void *,unsigned long,void *);
#endif
#endif
--
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 v2 2/2] headers: use inline version of RtlSecureZeroMemory for UCRT builds
There's an intrinsic version in the kernel32 library. But it's not supposed
to be used with UCRT builds.
RtlSecureZeroMemory is not found in -O0 + UCRT builds without this fix.
In the Windows SDK it's a forced inline version no matter what.
(and there's an ARM version)
---
mingw-w64-headers/include/winnt.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mingw-w64-headers/include/winnt.h
b/mingw-w64-headers/include/winnt.h
index a49dd6ab8..7bd6d4bfe 100644
--- a/mingw-w64-headers/include/winnt.h
+++ b/mingw-w64-headers/include/winnt.h
@@ -8929,10 +8929,8 @@ typedef DWORD (WINAPI
*PRTL_RUN_ONCE_INIT_FN)(PRTL_RUN_ONCE, PVOID, PVOID *);
#define HEAP_PSEUDO_TAG_FLAG 0x8000
#define HEAP_TAG_SHIFT 18
-PVOID WINAPI RtlSecureZeroMemory(PVOID ptr,SIZE_T cnt);
-
-#if !defined (__CRT__NO_INLINE) && !defined (__WIDL__)
-__CRT_INLINE PVOID WINAPI RtlSecureZeroMemory(PVOID ptr,SIZE_T cnt) {
+#if (!defined (__CRT__NO_INLINE) || defined(_UCRT)) && !defined (__WIDL__)
+__forceinline PVOID RtlSecureZeroMemory(PVOID ptr,SIZE_T cnt) {
volatile char *vptr =(volatile char *)ptr;
#ifdef __x86_64
__stosb((PBYTE)((DWORD64)vptr),0,cnt);
@@ -8944,6 +8942,8 @@ typedef DWORD (WINAPI
*PRTL_RUN_ONCE_INIT_FN)(PRTL_RUN_ONCE, PVOID, PVOID *);
#endif /* __x86_64 */
return ptr;
}
+#else // intrinsic in kernel32
+PVOID WINAPI RtlSecureZeroMemory(PVOID ptr,SIZE_T cnt);
#endif /* !__CRT__NO_INLINE // !__WIDL__ */
/* Let this macro fail for non-desktop mode. AFAIU this should be better an
inline-function ... */
--
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 v2 1/2] headers: allow RtlSecureZeroMemory in all targets
It's usually an inline function doing native CPU calls. It's also unrestricted
in the Windows SDK since Windows 8, as well as SecureZeroMemory.
---
mingw-w64-headers/include/winnt.h | 35 ---
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/mingw-w64-headers/include/winnt.h
b/mingw-w64-headers/include/winnt.h
index 257efdc1b..a49dd6ab8 100644
--- a/mingw-w64-headers/include/winnt.h
+++ b/mingw-w64-headers/include/winnt.h
@@ -8928,6 +8928,24 @@ typedef DWORD (WINAPI
*PRTL_RUN_ONCE_INIT_FN)(PRTL_RUN_ONCE, PVOID, PVOID *);
#define HEAP_MAXIMUM_TAG 0x0FFF
#define HEAP_PSEUDO_TAG_FLAG 0x8000
#define HEAP_TAG_SHIFT 18
+
+PVOID WINAPI RtlSecureZeroMemory(PVOID ptr,SIZE_T cnt);
+
+#if !defined (__CRT__NO_INLINE) && !defined (__WIDL__)
+__CRT_INLINE PVOID WINAPI RtlSecureZeroMemory(PVOID ptr,SIZE_T cnt) {
+ volatile char *vptr =(volatile char *)ptr;
+#ifdef __x86_64
+ __stosb((PBYTE)((DWORD64)vptr),0,cnt);
+#else
+ while(cnt) {
+ *vptr++ = 0;
+ cnt--;
+ }
+#endif /* __x86_64 */
+ return ptr;
+}
+#endif /* !__CRT__NO_INLINE // !__WIDL__ */
+
/* Let this macro fail for non-desktop mode. AFAIU this should be better an
inline-function ... */
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
#define HEAP_MAKE_TAG_FLAGS(b,o) ((DWORD)((b) + ((o) << 18)))
@@ -8983,23 +9001,6 @@ typedef DWORD (WINAPI
*PRTL_RUN_ONCE_INIT_FN)(PRTL_RUN_ONCE, PVOID, PVOID *);
#define RtlFillMemory(Destination,Length,Fill)
memset((Destination),(Fill),(Length))
#define RtlZeroMemory(Destination,Length) memset((Destination),0,(Length))
-PVOID WINAPI RtlSecureZeroMemory(PVOID ptr,SIZE_T cnt);
-
-#if !defined (__CRT__NO_INLINE) && !defined (__WIDL__)
-__CRT_INLINE PVOID WINAPI RtlSecureZeroMemory(PVOID ptr,SIZE_T cnt) {
- volatile char *vptr =(volatile char *)ptr;
-#ifdef __x86_64
- __stosb((PBYTE)((DWORD64)vptr),0,cnt);
-#else
- while(cnt) {
- *vptr++ = 0;
- cnt--;
- }
-#endif /* __x86_64 */
- return ptr;
-}
-#endif /* !__CRT__NO_INLINE // !__WIDL__ */
-
typedef struct _MESSAGE_RESOURCE_ENTRY {
WORD Length;
WORD Flags;
--
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] headers: allow RtlSecureZeroMemory in all targets
It's usually an inline function doing native CPU calls. It's also unrestricted
in the Windows SDK since Windows 8, as well as SecureZeroMemory.
---
mingw-w64-headers/include/winnt.h | 35 ---
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/mingw-w64-headers/include/winnt.h
b/mingw-w64-headers/include/winnt.h
index 396580d1d..7da2f7870 100644
--- a/mingw-w64-headers/include/winnt.h
+++ b/mingw-w64-headers/include/winnt.h
@@ -8933,6 +8933,24 @@ typedef DWORD (WINAPI
*PRTL_RUN_ONCE_INIT_FN)(PRTL_RUN_ONCE, PVOID, PVOID *);
#define HEAP_MAXIMUM_TAG 0x0FFF
#define HEAP_PSEUDO_TAG_FLAG 0x8000
#define HEAP_TAG_SHIFT 18
+
+PVOID WINAPI RtlSecureZeroMemory(PVOID ptr,SIZE_T cnt);
+
+#if !defined (__CRT__NO_INLINE) && !defined (__WIDL__)
+__CRT_INLINE PVOID WINAPI RtlSecureZeroMemory(PVOID ptr,SIZE_T cnt) {
+ volatile char *vptr =(volatile char *)ptr;
+#ifdef __x86_64
+ __stosb((PBYTE)((DWORD64)vptr),0,cnt);
+#else
+ while(cnt) {
+ *vptr++ = 0;
+ cnt--;
+ }
+#endif /* __x86_64 */
+ return ptr;
+}
+#endif /* !__CRT__NO_INLINE // !__WIDL__ */
+
/* Let this macro fail for non-desktop mode. AFAIU this should be better an
inline-function ... */
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
#define HEAP_MAKE_TAG_FLAGS(b,o) ((DWORD)((b) + ((o) << 18)))
@@ -8988,23 +9006,6 @@ typedef DWORD (WINAPI
*PRTL_RUN_ONCE_INIT_FN)(PRTL_RUN_ONCE, PVOID, PVOID *);
#define RtlFillMemory(Destination,Length,Fill)
memset((Destination),(Fill),(Length))
#define RtlZeroMemory(Destination,Length) memset((Destination),0,(Length))
-PVOID WINAPI RtlSecureZeroMemory(PVOID ptr,SIZE_T cnt);
-
-#if !defined (__CRT__NO_INLINE) && !defined (__WIDL__)
-__CRT_INLINE PVOID WINAPI RtlSecureZeroMemory(PVOID ptr,SIZE_T cnt) {
- volatile char *vptr =(volatile char *)ptr;
-#ifdef __x86_64
- __stosb((PBYTE)((DWORD64)vptr),0,cnt);
-#else
- while(cnt) {
- *vptr++ = 0;
- cnt--;
- }
-#endif /* __x86_64 */
- return ptr;
-}
-#endif /* !__CRT__NO_INLINE // !__WIDL__ */
-
typedef struct _MESSAGE_RESOURCE_ENTRY {
WORD Length;
WORD Flags;
--
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 3/3] headers: allow some winnls API's in 19H1 UWP builds
On 2023-06-27 17:21, LIU Hao wrote: 在 2023-06-27 20:24, Steve Lhomme 写道: They're allowed by the WACK and available in windowsapp.lib since 19H1. They're not allowed by the Windows SDK headers. These functions can be found in api-ms-win-core-localization-l1-2-0. --- mingw-w64-headers/include/winnls.h | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) Are there any reasons why we should declare it while Microsoft do not? Are there any projects that use them? Technically the MS headers are not always the cleanest. They do restrict when something is restricted, however they sometimes go too far. I have found that reliable sources are windowsapp.lib and the WACK (in that order). It's always possible to access API's by doing something like, and in the end the code will link and be allowed by the WACK and work on all UWP platforms: #undef WINAPI_FAMILY #define WINAPI_FAMILY WINAPI_FAMILY_DESKTOP_APP That would be necessary to enable the code when built with MSVC. If Windows SDK headers do not declare these functions, then people shouldn't use them in that scenario, even they seem to pass WACK. Yes, but it's trickier to get those patches merged in various libs rather than having headers match windowsapp.lib and the WACK. Also such patch is not safe, it may enable some API that are actually not allowed. I enquiried MS regarding the odd wincrypt situation, in hope they will fix their headers. If that happens, I'll do the same with CreateFileW/A and these winnls functions. ___ 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/3] headers: allow CreateFileW/A in 19H1 UWP builds
It's allowed by the WACK and available in windowsapp.lib since 19H1. It's not allowed by the Windows SDK headers. CreateFileW/A can be found in api-ms-win-core-file-l1-1-0. CreateFileW was there even in Windows 8. We need to remove it from windowsappcompat to avoid double definition when linking. --- mingw-w64-headers/include/fileapi.h| 4 ++-- mingw-w64-libraries/winstorecompat/Makefile.am | 1 - 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/mingw-w64-headers/include/fileapi.h b/mingw-w64-headers/include/fileapi.h index a37b19366..20940806f 100644 --- a/mingw-w64-headers/include/fileapi.h +++ b/mingw-w64-headers/include/fileapi.h @@ -47,10 +47,11 @@ WINBASEAPI DWORD WINAPI SetFilePointer (HANDLE hFile, LONG lDistanceToMove, PLON } BY_HANDLE_FILE_INFORMATION, *PBY_HANDLE_FILE_INFORMATION, *LPBY_HANDLE_FILE_INFORMATION; WINBASEAPI WINBOOL WINAPI GetFileInformationByHandle (HANDLE hFile, LPBY_HANDLE_FILE_INFORMATION lpFileInformation); + WINBASEAPI HANDLE WINAPI CreateFileA (LPCSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile); + WINBASEAPI HANDLE WINAPI CreateFileW (LPCWSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile); #endif #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) - WINBASEAPI HANDLE WINAPI CreateFileA (LPCSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile); WINBASEAPI WINBOOL WINAPI DefineDosDeviceW (DWORD dwFlags, LPCWSTR lpDeviceName, LPCWSTR lpTargetPath); WINBASEAPI WINBOOL WINAPI FindCloseChangeNotification (HANDLE hChangeHandle); WINBASEAPI HANDLE WINAPI FindFirstChangeNotificationA (LPCSTR lpPathName, WINBOOL bWatchSubtree, DWORD dwNotifyFilter); @@ -61,7 +62,6 @@ WINBASEAPI DWORD WINAPI SetFilePointer (HANDLE hFile, LONG lDistanceToMove, PLON WINBASEAPI WINBOOL WINAPI FindVolumeClose (HANDLE hFindVolume); #endif #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || defined(WINSTORECOMPAT) - WINBASEAPI HANDLE WINAPI CreateFileW (LPCWSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile); WINBASEAPI DWORD WINAPI GetFileSize (HANDLE hFile, LPDWORD lpFileSizeHigh); #endif #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || _WIN32_WINNT >= _WIN32_WINNT_WIN10 diff --git a/mingw-w64-libraries/winstorecompat/Makefile.am b/mingw-w64-libraries/winstorecompat/Makefile.am index 55fb45841..70aa0d27f 100644 --- a/mingw-w64-libraries/winstorecompat/Makefile.am +++ b/mingw-w64-libraries/winstorecompat/Makefile.am @@ -50,7 +50,6 @@ libwinstorecompat_a_SOURCES = \ libwindowsappcompat_a_SOURCES = \ src/LoadLibraryW.c \ - src/CreateFileW.c \ src/UnhandledExceptionFilter.c \ src/VirtualProtect.c \ src/getenv.c \ -- 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 3/3] headers: allow some winnls API's in 19H1 UWP builds
They're allowed by the WACK and available in windowsapp.lib since 19H1.
They're not allowed by the Windows SDK headers.
These functions can be found in api-ms-win-core-localization-l1-2-0.
---
mingw-w64-headers/include/winnls.h | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/mingw-w64-headers/include/winnls.h
b/mingw-w64-headers/include/winnls.h
index cd8c6025b..ccbc199d8 100644
--- a/mingw-w64-headers/include/winnls.h
+++ b/mingw-w64-headers/include/winnls.h
@@ -1047,12 +1047,7 @@ extern "C" {
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
WINBASEAPI WINBOOL WINAPI SetUserGeoID (GEOID GeoId);
WINBASEAPI LCID WINAPI ConvertDefaultLocale (LCID Locale);
- WINBASEAPI LCID WINAPI GetThreadLocale (void);
WINBASEAPI WINBOOL WINAPI SetThreadLocale (LCID Locale);
- WINBASEAPI LANGID WINAPI GetSystemDefaultUILanguage (void);
- WINBASEAPI LANGID WINAPI GetSystemDefaultLangID (void);
- WINBASEAPI LCID WINAPI GetSystemDefaultLCID (void);
- WINBASEAPI LCID WINAPI GetUserDefaultLCID (void);
WINBASEAPI LANGID WINAPI SetThreadUILanguage (LANGID LangId);
WINBASEAPI WINBOOL WINAPI GetStringTypeA (LCID Locale, DWORD dwInfoType,
LPCSTR lpSrcStr, int cchSrc, LPWORD lpCharType);
WINBASEAPI int WINAPI FoldStringA (DWORD dwMapFlags, LPCSTR lpSrcStr, int
cchSrc, LPSTR lpDestStr, int cchDest);
@@ -1097,6 +1092,14 @@ extern "C" {
#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_19H1
+ WINBASEAPI LANGID WINAPI GetSystemDefaultLangID (void);
+ WINBASEAPI LCID WINAPI GetSystemDefaultLCID (void);
+ WINBASEAPI LANGID WINAPI GetSystemDefaultUILanguage (void);
+ WINBASEAPI LCID WINAPI GetThreadLocale (void);
+ WINBASEAPI LCID WINAPI GetUserDefaultLCID (void);
+#endif
+
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP)
WINBASEAPI WINBOOL WINAPI GetStringTypeExA (LCID Locale, DWORD dwInfoType,
LPCSTR lpSrcStr, int cchSrc, LPWORD lpCharType);
WINBASEAPI LANGID WINAPI GetUserDefaultUILanguage (void);
--
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/3] headers: allow GetFileSize in 19H1 UWP builds
It's allowed by the WACK and available in windowsapp.lib since 19H1. It's not allowed by the Windows SDK headers. GetFileSize can be found in api-ms-win-core-file-l1-1-0. We need to remove it from windowsappcompat to avoid double definition when linking. --- mingw-w64-headers/include/fileapi.h| 4 +--- mingw-w64-libraries/winstorecompat/Makefile.am | 1 - 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/mingw-w64-headers/include/fileapi.h b/mingw-w64-headers/include/fileapi.h index 20940806f..0edb4a5f1 100644 --- a/mingw-w64-headers/include/fileapi.h +++ b/mingw-w64-headers/include/fileapi.h @@ -49,6 +49,7 @@ WINBASEAPI DWORD WINAPI SetFilePointer (HANDLE hFile, LONG lDistanceToMove, PLON WINBASEAPI WINBOOL WINAPI GetFileInformationByHandle (HANDLE hFile, LPBY_HANDLE_FILE_INFORMATION lpFileInformation); WINBASEAPI HANDLE WINAPI CreateFileA (LPCSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile); WINBASEAPI HANDLE WINAPI CreateFileW (LPCWSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile); + WINBASEAPI DWORD WINAPI GetFileSize (HANDLE hFile, LPDWORD lpFileSizeHigh); #endif #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) @@ -61,9 +62,6 @@ WINBASEAPI DWORD WINAPI SetFilePointer (HANDLE hFile, LONG lDistanceToMove, PLON WINBASEAPI WINBOOL WINAPI FindNextVolumeW (HANDLE hFindVolume, LPWSTR lpszVolumeName, DWORD cchBufferLength); WINBASEAPI WINBOOL WINAPI FindVolumeClose (HANDLE hFindVolume); #endif -#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || defined(WINSTORECOMPAT) - WINBASEAPI DWORD WINAPI GetFileSize (HANDLE hFile, LPDWORD lpFileSizeHigh); -#endif #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || _WIN32_WINNT >= _WIN32_WINNT_WIN10 WINBASEAPI LONG WINAPI CompareFileTime (CONST FILETIME *lpFileTime1, CONST FILETIME *lpFileTime2); WINBASEAPI WINBOOL WINAPI DeleteVolumeMountPointW (LPCWSTR lpszVolumeMountPoint); diff --git a/mingw-w64-libraries/winstorecompat/Makefile.am b/mingw-w64-libraries/winstorecompat/Makefile.am index 70aa0d27f..d5758afdb 100644 --- a/mingw-w64-libraries/winstorecompat/Makefile.am +++ b/mingw-w64-libraries/winstorecompat/Makefile.am @@ -53,7 +53,6 @@ libwindowsappcompat_a_SOURCES = \ src/UnhandledExceptionFilter.c \ src/VirtualProtect.c \ src/getenv.c \ - src/GetFileSize.c \ src/SHGetFolderPathW.c \ src/QueueTimer.c \ src/GetStartupInfo.c \ -- 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 0/5] Update windowsapp to match the one in 20H1
Also, VLC (and all its contribs) builds with the 19H1 patch (ie without the 20H1) as well. Our current minimum for UWP is 19H1 which brought enough allowed API's to replace what we used in winstorecompat. On 2023-06-26 15:44, Steve Lhomme wrote: BTW I tested this on VLC build and it all links fine (once the Rtl functions are added). On 2023-06-26 15:31, Steve Lhomme wrote: windowsapp.lib and the target DLL for each API entry keeps evolving. So far the files and entries were mostly added manually when needed. This patchset creates the actual equivalent to what is found in windowsapp.lib. The previous mass edits were generated from a WACK to .def tool. This time instead of the WACK that is permitting more functions to define multiple times it's exactly the same DLL that windowsapp.lib uses and not multiple ones. A few Rtl function not found in windowsapp.lib were added because they are needed by libunwind. They are allowed by the WACK and found in that DLL on my system. But for some reason they are not in windowsapp.lib... There are a lot of inconsistencies between the WACK, windowsapp.lib, the windowsapp documentation [1] and the function documentation. The most restrictive is the windowsapp.lib. If a function is not in there, it should not link when building for UWP (we are lacking onecore.lib and onecoreuap.lib). So we should not allow the linking either in mingw-w64. [1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis Steve Lhomme (5): crt: don't generate libgamemode.a for windowsapp crt: order libs alphabetically in windowsapp crt: move some Rtl functions to rtlsupport-l1-1-0 crt: update windowsapp to the 18362/19H1 SDK crt: update windowsapp to the 19041/20H1 SDK mingw-w64-crt/Makefile.am | 168 +++--- .../api-ms-win-appmodel-runtime-l1-1-1.def | 20 --- .../api-ms-win-appmodel-runtime-l1-1-2.def | 12 ++ .../api-ms-win-appmodel-runtime-l1-1-3.def | 9 + .../api-ms-win-core-atoms-l1-1-0.def | 11 ++ .../lib-common/api-ms-win-core-com-l1-1-1.def | 53 -- .../api-ms-win-core-comm-l1-1-1.def | 18 -- .../api-ms-win-core-comm-l1-1-2.def | 19 -- .../api-ms-win-core-console-l1-1-0.def | 1 - .../api-ms-win-core-console-l1-2-0.def | 13 -- .../api-ms-win-core-console-l2-1-0.def | 5 - .../api-ms-win-core-console-l2-2-0.def | 33 .../api-ms-win-core-datetime-l1-1-1.def | 4 - .../api-ms-win-core-datetime-l1-1-2.def | 6 - .../api-ms-win-core-debug-l1-1-1.def | 4 - .../api-ms-win-core-delayload-l1-1-0.def | 5 + .../api-ms-win-core-delayload-l1-1-1.def | 1 - .../api-ms-win-core-errorhandling-l1-1-1.def | 7 - .../api-ms-win-core-errorhandling-l1-1-2.def | 5 + .../api-ms-win-core-errorhandling-l1-1-3.def | 10 -- .../api-ms-win-core-featurestaging-l1-1-1.def | 5 - .../api-ms-win-core-fibers-l1-1-0.def | 8 + .../api-ms-win-core-fibers-l1-1-1.def | 4 - .../api-ms-win-core-fibers-l2-1-0.def | 7 + .../api-ms-win-core-fibers-l2-1-1.def | 3 - .../api-ms-win-core-file-l1-1-0.def | 1 - .../api-ms-win-core-file-l1-2-0.def | 73 .../api-ms-win-core-file-l1-2-1.def | 81 - .../api-ms-win-core-file-l1-2-2.def | 77 .../api-ms-win-core-file-l2-1-1.def | 15 -- .../api-ms-win-core-file-l2-1-2.def | 11 -- .../api-ms-win-core-heap-l1-1-0.def | 1 - .../api-ms-win-core-heap-l1-2-0.def | 19 -- .../api-ms-win-core-heap-obsolete-l1-1-0.def | 5 - .../api-ms-win-core-interlocked-l1-1-0.def | 6 + .../api-ms-win-core-interlocked-l1-2-0.def | 5 - .../lib-common/api-ms-win-core-io-l1-1-1.def | 7 - .../lib-common/api-ms-win-core-job-l2-1-0.def | 7 + ...api-ms-win-core-kernel32-legacy-l1-1-0.def | 15 -- ...api-ms-win-core-kernel32-legacy-l1-1-1.def | 35 ...api-ms-win-core-kernel32-legacy-l1-1-2.def | 8 + ...api-ms-win-core-kernel32-legacy-l1-1-5.def | 5 + .../api-ms-win-core-libraryloader-l1-2-1.def | 23 --- .../api-ms-win-core-libraryloader-l1-2-2.def | 5 + .../api-ms-win-core-localization-l1-2-1.def | 58 -- .../api-ms-win-core-localization-l1-2-2.def | 59 -- ...-win-core-localization-obsolete-l1-2-0.def | 2 - .../api-ms-win-core-memory-l1-1-1.def | 16 -- .../api-ms-win-core-memory-l1-1-2.def | 26 --- .../api-ms-win-core-memory-l1-1-3.def | 29 --- .../api-ms-win-core-memory-l1-1-5.def | 33 .../api-ms-win-core-memory-l1-1-6.def | 35 .../api-ms-win-core-memory-l1-1-7.def | 37 .../api-ms-win-core-namedpipe-ansi-l1-1-1.def | 3 - .../api-ms-win-core-namedpipe-l1-2-1.def | 10 -- .../api-ms-win-core-namedpipe-l1-2-2.def | 12 -- .../api-ms-win
Re: [Mingw-w64-public] [PATCH 0/5] Update windowsapp to match the one in 20H1
BTW I tested this on VLC build and it all links fine (once the Rtl functions are added). On 2023-06-26 15:31, Steve Lhomme wrote: windowsapp.lib and the target DLL for each API entry keeps evolving. So far the files and entries were mostly added manually when needed. This patchset creates the actual equivalent to what is found in windowsapp.lib. The previous mass edits were generated from a WACK to .def tool. This time instead of the WACK that is permitting more functions to define multiple times it's exactly the same DLL that windowsapp.lib uses and not multiple ones. A few Rtl function not found in windowsapp.lib were added because they are needed by libunwind. They are allowed by the WACK and found in that DLL on my system. But for some reason they are not in windowsapp.lib... There are a lot of inconsistencies between the WACK, windowsapp.lib, the windowsapp documentation [1] and the function documentation. The most restrictive is the windowsapp.lib. If a function is not in there, it should not link when building for UWP (we are lacking onecore.lib and onecoreuap.lib). So we should not allow the linking either in mingw-w64. [1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis Steve Lhomme (5): crt: don't generate libgamemode.a for windowsapp crt: order libs alphabetically in windowsapp crt: move some Rtl functions to rtlsupport-l1-1-0 crt: update windowsapp to the 18362/19H1 SDK crt: update windowsapp to the 19041/20H1 SDK mingw-w64-crt/Makefile.am | 168 +++--- .../api-ms-win-appmodel-runtime-l1-1-1.def| 20 --- .../api-ms-win-appmodel-runtime-l1-1-2.def| 12 ++ .../api-ms-win-appmodel-runtime-l1-1-3.def| 9 + .../api-ms-win-core-atoms-l1-1-0.def | 11 ++ .../lib-common/api-ms-win-core-com-l1-1-1.def | 53 -- .../api-ms-win-core-comm-l1-1-1.def | 18 -- .../api-ms-win-core-comm-l1-1-2.def | 19 -- .../api-ms-win-core-console-l1-1-0.def| 1 - .../api-ms-win-core-console-l1-2-0.def| 13 -- .../api-ms-win-core-console-l2-1-0.def| 5 - .../api-ms-win-core-console-l2-2-0.def| 33 .../api-ms-win-core-datetime-l1-1-1.def | 4 - .../api-ms-win-core-datetime-l1-1-2.def | 6 - .../api-ms-win-core-debug-l1-1-1.def | 4 - .../api-ms-win-core-delayload-l1-1-0.def | 5 + .../api-ms-win-core-delayload-l1-1-1.def | 1 - .../api-ms-win-core-errorhandling-l1-1-1.def | 7 - .../api-ms-win-core-errorhandling-l1-1-2.def | 5 + .../api-ms-win-core-errorhandling-l1-1-3.def | 10 -- .../api-ms-win-core-featurestaging-l1-1-1.def | 5 - .../api-ms-win-core-fibers-l1-1-0.def | 8 + .../api-ms-win-core-fibers-l1-1-1.def | 4 - .../api-ms-win-core-fibers-l2-1-0.def | 7 + .../api-ms-win-core-fibers-l2-1-1.def | 3 - .../api-ms-win-core-file-l1-1-0.def | 1 - .../api-ms-win-core-file-l1-2-0.def | 73 .../api-ms-win-core-file-l1-2-1.def | 81 - .../api-ms-win-core-file-l1-2-2.def | 77 .../api-ms-win-core-file-l2-1-1.def | 15 -- .../api-ms-win-core-file-l2-1-2.def | 11 -- .../api-ms-win-core-heap-l1-1-0.def | 1 - .../api-ms-win-core-heap-l1-2-0.def | 19 -- .../api-ms-win-core-heap-obsolete-l1-1-0.def | 5 - .../api-ms-win-core-interlocked-l1-1-0.def| 6 + .../api-ms-win-core-interlocked-l1-2-0.def| 5 - .../lib-common/api-ms-win-core-io-l1-1-1.def | 7 - .../lib-common/api-ms-win-core-job-l2-1-0.def | 7 + ...api-ms-win-core-kernel32-legacy-l1-1-0.def | 15 -- ...api-ms-win-core-kernel32-legacy-l1-1-1.def | 35 ...api-ms-win-core-kernel32-legacy-l1-1-2.def | 8 + ...api-ms-win-core-kernel32-legacy-l1-1-5.def | 5 + .../api-ms-win-core-libraryloader-l1-2-1.def | 23 --- .../api-ms-win-core-libraryloader-l1-2-2.def | 5 + .../api-ms-win-core-localization-l1-2-1.def | 58 -- .../api-ms-win-core-localization-l1-2-2.def | 59 -- ...-win-core-localization-obsolete-l1-2-0.def | 2 - .../api-ms-win-core-memory-l1-1-1.def | 16 -- .../api-ms-win-core-memory-l1-1-2.def | 26 --- .../api-ms-win-core-memory-l1-1-3.def | 29 --- .../api-ms-win-core-memory-l1-1-5.def | 33 .../api-ms-win-core-memory-l1-1-6.def | 35 .../api-ms-win-core-memory-l1-1-7.def | 37 .../api-ms-win-core-namedpipe-ansi-l1-1-1.def | 3 - .../api-ms-win-core-namedpipe-l1-2-1.def | 10 -- .../api-ms-win-core-namedpipe-l1-2-2.def | 12 -- .../api-ms-win-core-privateprofile-l1-1-0.def | 9 + .../api-ms-win-core-privateprofile-l1-1-1.def | 5 + ...in-core-processenvironment-ansi-l1-1-0.def | 5 + ...-ms-win-core-processenvironment-l1-2-0.def | 21 --- ...api-ms-win-core-processsnapshot-l1-1-0.def | 14
[Mingw-w64-public] [PATCH 5/5] crt: update windowsapp to the 19041/20H1 SDK
This includes the API's made available for UWP 20H1. A lot of the added functions need to be enabled in UWP for NTDDI_WIN10_VB. For now they can be linked accurately when WINAPI_FAMILY_DESKTOP_APP is forced during compilation. Some functions were exported twice api-ms-win-core-version-l1-1-1: - GetFileVersionInfoExW - GetFileVersionInfoSizeExW - VerQueryValueW --- mingw-w64-crt/Makefile.am | 10 ++ .../api-ms-win-appmodel-runtime-l1-1-0.def| 12 .../api-ms-win-appmodel-runtime-l1-1-1.def| 8 .../api-ms-win-appmodel-runtime-l1-1-2.def| 12 .../api-ms-win-appmodel-runtime-l1-1-3.def| 9 + .../api-ms-win-core-errorhandling-l1-1-0.def | 1 + .../api-ms-win-core-file-ansi-l1-1-0.def | 3 +++ .../api-ms-win-core-file-ansi-l2-1-0.def | 2 ++ .../api-ms-win-core-file-l1-1-0.def | 13 + .../api-ms-win-core-file-l1-2-0.def | 1 + .../api-ms-win-core-file-l2-1-0.def | 3 +++ .../api-ms-win-core-heap-l1-1-0.def | 3 +++ .../api-ms-win-core-libraryloader-l1-2-0.def | 5 + ...i-ms-win-core-localization-ansi-l1-1-0.def | 3 +++ .../api-ms-win-core-localization-l1-2-0.def | 19 +++ .../api-ms-win-core-memory-l1-1-0.def | 2 ++ ...in-core-processenvironment-ansi-l1-1-0.def | 5 + ...-ms-win-core-processenvironment-l1-1-0.def | 1 + ...api-ms-win-core-processsnapshot-l1-1-0.def | 14 ++ .../api-ms-win-core-processthreads-l1-1-0.def | 10 ++ .../api-ms-win-core-processthreads-l1-1-1.def | 1 + ...api-ms-win-core-processtopology-l1-1-0.def | 6 ++ .../api-ms-win-core-rtlsupport-l1-2-0.def | 1 + .../api-ms-win-core-synch-l1-2-0.def | 3 +++ .../api-ms-win-core-sysinfo-l1-1-0.def| 2 ++ .../api-ms-win-core-sysinfo-l1-2-6.def| 5 + .../api-ms-win-core-timezone-l1-1-0.def | 2 ++ .../api-ms-win-core-util-l1-1-0.def | 2 ++ .../api-ms-win-core-version-l1-1-1.def| 5 + .../api-ms-win-core-versionansi-l1-1-1.def| 5 + .../api-ms-win-eventlog-legacy-l1-1-0.def | 7 +++ .../api-ms-win-security-cpwl-l1-1-0.def | 5 + mingw-w64-crt/lib-common/windowsapp.mri | 10 ++ .../api-ms-win-appmodel-runtime-l1-1-0.def| 12 .../api-ms-win-appmodel-runtime-l1-1-1.def| 8 .../api-ms-win-appmodel-runtime-l1-1-2.def| 12 .../api-ms-win-appmodel-runtime-l1-1-3.def| 9 + .../api-ms-win-core-errorhandling-l1-1-0.def | 1 + .../api-ms-win-core-file-ansi-l1-1-0.def | 3 +++ .../api-ms-win-core-file-ansi-l2-1-0.def | 2 ++ .../lib32/api-ms-win-core-file-l1-1-0.def | 13 + .../lib32/api-ms-win-core-file-l1-2-0.def | 1 + .../lib32/api-ms-win-core-file-l2-1-0.def | 3 +++ .../lib32/api-ms-win-core-heap-l1-1-0.def | 3 +++ .../api-ms-win-core-libraryloader-l1-2-0.def | 5 + ...i-ms-win-core-localization-ansi-l1-1-0.def | 3 +++ .../api-ms-win-core-localization-l1-2-0.def | 19 +++ .../lib32/api-ms-win-core-memory-l1-1-0.def | 2 ++ ...in-core-processenvironment-ansi-l1-1-0.def | 5 + ...-ms-win-core-processenvironment-l1-1-0.def | 1 + ...api-ms-win-core-processsnapshot-l1-1-0.def | 14 ++ .../api-ms-win-core-processthreads-l1-1-0.def | 10 ++ .../api-ms-win-core-processthreads-l1-1-1.def | 1 + ...api-ms-win-core-processtopology-l1-1-0.def | 6 ++ .../api-ms-win-core-rtlsupport-l1-2-0.def | 1 + .../lib32/api-ms-win-core-synch-l1-2-0.def| 3 +++ .../lib32/api-ms-win-core-sysinfo-l1-1-0.def | 2 ++ .../lib32/api-ms-win-core-sysinfo-l1-2-6.def | 5 + .../lib32/api-ms-win-core-timezone-l1-1-0.def | 2 ++ .../lib32/api-ms-win-core-util-l1-1-0.def | 2 ++ .../lib32/api-ms-win-core-version-l1-1-1.def | 5 + .../api-ms-win-core-versionansi-l1-1-1.def| 5 + .../api-ms-win-eventlog-legacy-l1-1-0.def | 7 +++ .../lib32/api-ms-win-security-cpwl-l1-1-0.def | 5 + 64 files changed, 360 insertions(+) create mode 100644 mingw-w64-crt/lib-common/api-ms-win-appmodel-runtime-l1-1-2.def create mode 100644 mingw-w64-crt/lib-common/api-ms-win-appmodel-runtime-l1-1-3.def create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-processenvironment-ansi-l1-1-0.def create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-processsnapshot-l1-1-0.def create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-processtopology-l1-1-0.def create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-sysinfo-l1-2-6.def create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-version-l1-1-1.def create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-versionansi-l1-1-1.def create mode 100644 mingw-w64-crt/lib-common/api-ms-win-eventlog-legacy-l1-1-0.def create mode 100644
[Mingw-w64-public] [PATCH 2/5] crt: order libs alphabetically in windowsapp
This is also the order reported by dumpbin and nm. Using sort -o windowsapp.mri windowsapp.mri and placing back the mri commands in their place. No functional changes. --- mingw-w64-crt/Makefile.am | 118 mingw-w64-crt/lib-common/windowsapp.mri | 114 +++ 2 files changed, 117 insertions(+), 115 deletions(-) diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index e00ebb945..efe62903b 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -2186,150 +2186,151 @@ endif $(RANLIB) $@ %/libwindowsapp.a: lib-common/windowsapp.mri \ + %/libapi-ms-win-appmodel-runtime-l1-1-0.a \ + %/libapi-ms-win-appmodel-runtime-l1-1-1.a \ + %/libapi-ms-win-core-com-l1-1-0.a \ %/libapi-ms-win-core-com-l1-1-1.a \ %/libapi-ms-win-core-com-l2-1-1.a \ %/libapi-ms-win-core-com-midlproxystub-l1-1-0.a \ %/libapi-ms-win-core-comm-l1-1-0.a \ + %/libapi-ms-win-core-comm-l1-1-1.a \ + %/libapi-ms-win-core-comm-l1-1-2.a \ %/libapi-ms-win-core-console-l1-1-0.a \ + %/libapi-ms-win-core-console-l1-2-0.a \ + %/libapi-ms-win-core-console-l2-1-0.a \ + %/libapi-ms-win-core-console-l2-2-0.a \ + %/libapi-ms-win-core-console-l3-2-0.a \ %/libapi-ms-win-core-datetime-l1-1-0.a \ %/libapi-ms-win-core-datetime-l1-1-1.a \ %/libapi-ms-win-core-datetime-l1-1-2.a \ + %/libapi-ms-win-core-debug-l1-1-0.a \ %/libapi-ms-win-core-debug-l1-1-1.a \ %/libapi-ms-win-core-delayload-l1-1-1.a \ + %/libapi-ms-win-core-enclave-l1-1-0.a \ + %/libapi-ms-win-core-errorhandling-l1-1-0.a \ %/libapi-ms-win-core-errorhandling-l1-1-1.a \ %/libapi-ms-win-core-errorhandling-l1-1-3.a \ + %/libapi-ms-win-core-featurestaging-l1-1-0.a \ + %/libapi-ms-win-core-featurestaging-l1-1-1.a \ %/libapi-ms-win-core-fibers-l1-1-1.a \ %/libapi-ms-win-core-fibers-l2-1-1.a \ + %/libapi-ms-win-core-file-ansi-l1-1-0.a \ %/libapi-ms-win-core-file-ansi-l2-1-0.a \ + %/libapi-ms-win-core-file-fromapp-l1-1-0.a \ + %/libapi-ms-win-core-file-l1-1-0.a \ %/libapi-ms-win-core-file-l1-2-0.a \ %/libapi-ms-win-core-file-l1-2-1.a \ %/libapi-ms-win-core-file-l1-2-2.a \ %/libapi-ms-win-core-file-l2-1-0.a \ %/libapi-ms-win-core-file-l2-1-1.a \ + %/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-heap-l2-1-0.a \ + %/libapi-ms-win-core-heap-obsolete-l1-1-0.a \ + %/libapi-ms-win-core-interlocked-l1-1-0.a \ %/libapi-ms-win-core-interlocked-l1-2-0.a \ %/libapi-ms-win-core-io-l1-1-0.a \ %/libapi-ms-win-core-io-l1-1-1.a \ + %/libapi-ms-win-core-kernel32-legacy-ansi-l1-1-0.a \ %/libapi-ms-win-core-kernel32-legacy-l1-1-0.a \ %/libapi-ms-win-core-kernel32-legacy-l1-1-1.a \ %/libapi-ms-win-core-largeinteger-l1-1-0.a \ %/libapi-ms-win-core-libraryloader-l1-2-0.a \ + %/libapi-ms-win-core-libraryloader-l1-2-1.a \ %/libapi-ms-win-core-libraryloader-l2-1-0.a \ %/libapi-ms-win-core-localization-ansi-l1-1-0.a \ + %/libapi-ms-win-core-localization-l1-2-0.a \ %/libapi-ms-win-core-localization-l1-2-1.a \ %/libapi-ms-win-core-localization-l1-2-2.a \ %/libapi-ms-win-core-localization-l2-1-0.a \ + %/libapi-ms-win-core-localization-obsolete-l1-2-0.a \ + %/libapi-ms-win-core-memory-l1-1-0.a \ + %/libapi-ms-win-core-memory-l1-1-1.a \ %/libapi-ms-win-core-memory-l1-1-2.a \ %/libapi-ms-win-core-memory-l1-1-3.a \ + %/libapi-ms-win-core-memory-l1-1-5.a \ + %/libapi-ms-win-core-memory-l1-1-6.a \ + %/libapi-ms-win-core-memory-l1-1-7.a \ %/libapi-ms-win-core-namedpipe-ansi-l1-1-0.a \ %/libapi-ms-win-core-namedpipe-ansi-l1-1-1.a \ %/libapi-ms-win-core-namedpipe-l1-1-0.a \ %/libapi-ms-win-core-namedpipe-l1-2-1.a \ %/libapi-ms-win-core-namedpipe-l1-2-2.a \ + %/libapi-ms-win-core-namespace-ansi-l1-1-0.a \ + %/libapi-ms-win-core-namespace-l1-1-0.a \
[Mingw-w64-public] [PATCH 1/5] crt: don't generate libgamemode.a for windowsapp
Followup to e7e9894ef641960480355489635a81e21a1406a4 --- mingw-w64-crt/Makefile.am | 1 - 1 file changed, 1 deletion(-) diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index 963df274e..e00ebb945 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -2186,7 +2186,6 @@ endif $(RANLIB) $@ %/libwindowsapp.a: lib-common/windowsapp.mri \ - %/libgamemode.a \ %/libapi-ms-win-core-com-l1-1-1.a \ %/libapi-ms-win-core-com-l2-1-1.a \ %/libapi-ms-win-core-com-midlproxystub-l1-1-0.a \ -- 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 0/5] Update windowsapp to match the one in 20H1
windowsapp.lib and the target DLL for each API entry keeps evolving. So far the files and entries were mostly added manually when needed. This patchset creates the actual equivalent to what is found in windowsapp.lib. The previous mass edits were generated from a WACK to .def tool. This time instead of the WACK that is permitting more functions to define multiple times it's exactly the same DLL that windowsapp.lib uses and not multiple ones. A few Rtl function not found in windowsapp.lib were added because they are needed by libunwind. They are allowed by the WACK and found in that DLL on my system. But for some reason they are not in windowsapp.lib... There are a lot of inconsistencies between the WACK, windowsapp.lib, the windowsapp documentation [1] and the function documentation. The most restrictive is the windowsapp.lib. If a function is not in there, it should not link when building for UWP (we are lacking onecore.lib and onecoreuap.lib). So we should not allow the linking either in mingw-w64. [1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis Steve Lhomme (5): crt: don't generate libgamemode.a for windowsapp crt: order libs alphabetically in windowsapp crt: move some Rtl functions to rtlsupport-l1-1-0 crt: update windowsapp to the 18362/19H1 SDK crt: update windowsapp to the 19041/20H1 SDK mingw-w64-crt/Makefile.am | 168 +++--- .../api-ms-win-appmodel-runtime-l1-1-1.def| 20 --- .../api-ms-win-appmodel-runtime-l1-1-2.def| 12 ++ .../api-ms-win-appmodel-runtime-l1-1-3.def| 9 + .../api-ms-win-core-atoms-l1-1-0.def | 11 ++ .../lib-common/api-ms-win-core-com-l1-1-1.def | 53 -- .../api-ms-win-core-comm-l1-1-1.def | 18 -- .../api-ms-win-core-comm-l1-1-2.def | 19 -- .../api-ms-win-core-console-l1-1-0.def| 1 - .../api-ms-win-core-console-l1-2-0.def| 13 -- .../api-ms-win-core-console-l2-1-0.def| 5 - .../api-ms-win-core-console-l2-2-0.def| 33 .../api-ms-win-core-datetime-l1-1-1.def | 4 - .../api-ms-win-core-datetime-l1-1-2.def | 6 - .../api-ms-win-core-debug-l1-1-1.def | 4 - .../api-ms-win-core-delayload-l1-1-0.def | 5 + .../api-ms-win-core-delayload-l1-1-1.def | 1 - .../api-ms-win-core-errorhandling-l1-1-1.def | 7 - .../api-ms-win-core-errorhandling-l1-1-2.def | 5 + .../api-ms-win-core-errorhandling-l1-1-3.def | 10 -- .../api-ms-win-core-featurestaging-l1-1-1.def | 5 - .../api-ms-win-core-fibers-l1-1-0.def | 8 + .../api-ms-win-core-fibers-l1-1-1.def | 4 - .../api-ms-win-core-fibers-l2-1-0.def | 7 + .../api-ms-win-core-fibers-l2-1-1.def | 3 - .../api-ms-win-core-file-l1-1-0.def | 1 - .../api-ms-win-core-file-l1-2-0.def | 73 .../api-ms-win-core-file-l1-2-1.def | 81 - .../api-ms-win-core-file-l1-2-2.def | 77 .../api-ms-win-core-file-l2-1-1.def | 15 -- .../api-ms-win-core-file-l2-1-2.def | 11 -- .../api-ms-win-core-heap-l1-1-0.def | 1 - .../api-ms-win-core-heap-l1-2-0.def | 19 -- .../api-ms-win-core-heap-obsolete-l1-1-0.def | 5 - .../api-ms-win-core-interlocked-l1-1-0.def| 6 + .../api-ms-win-core-interlocked-l1-2-0.def| 5 - .../lib-common/api-ms-win-core-io-l1-1-1.def | 7 - .../lib-common/api-ms-win-core-job-l2-1-0.def | 7 + ...api-ms-win-core-kernel32-legacy-l1-1-0.def | 15 -- ...api-ms-win-core-kernel32-legacy-l1-1-1.def | 35 ...api-ms-win-core-kernel32-legacy-l1-1-2.def | 8 + ...api-ms-win-core-kernel32-legacy-l1-1-5.def | 5 + .../api-ms-win-core-libraryloader-l1-2-1.def | 23 --- .../api-ms-win-core-libraryloader-l1-2-2.def | 5 + .../api-ms-win-core-localization-l1-2-1.def | 58 -- .../api-ms-win-core-localization-l1-2-2.def | 59 -- ...-win-core-localization-obsolete-l1-2-0.def | 2 - .../api-ms-win-core-memory-l1-1-1.def | 16 -- .../api-ms-win-core-memory-l1-1-2.def | 26 --- .../api-ms-win-core-memory-l1-1-3.def | 29 --- .../api-ms-win-core-memory-l1-1-5.def | 33 .../api-ms-win-core-memory-l1-1-6.def | 35 .../api-ms-win-core-memory-l1-1-7.def | 37 .../api-ms-win-core-namedpipe-ansi-l1-1-1.def | 3 - .../api-ms-win-core-namedpipe-l1-2-1.def | 10 -- .../api-ms-win-core-namedpipe-l1-2-2.def | 12 -- .../api-ms-win-core-privateprofile-l1-1-0.def | 9 + .../api-ms-win-core-privateprofile-l1-1-1.def | 5 + ...in-core-processenvironment-ansi-l1-1-0.def | 5 + ...-ms-win-core-processenvironment-l1-2-0.def | 21 --- ...api-ms-win-core-processsnapshot-l1-1-0.def | 14 ++ .../api-ms-win-core-processthreads-l1-1-1.def | 49 - .../api-ms-win-core-processthreads-l1-1-2.def | 63 --- .../api-ms-win-core-processthreads-l1-1-3.def | 67 --- ...api-ms-win
[Mingw-w64-public] [PATCH 3/5] crt: move some Rtl functions to rtlsupport-l1-1-0
They have moved there in 16299 [1]. Some functions were removed but they are still allowed by the WACK. Some function were never in windowsapp.lib: * RtlAddFunctionTable * RtlDeleteFunctionTable * RtlInstallFunctionTableCallback * RtlVirtualUnwind [1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-rtlsupport-l1-2-0dll --- mingw-w64-crt/Makefile.am | 1 + .../lib-common/api-ms-win-core-rtlsupport-l1-1-0.def | 10 ++ .../lib-common/api-ms-win-core-rtlsupport-l1-2-0.def | 11 --- mingw-w64-crt/lib-common/windowsapp.mri | 1 + .../lib32/api-ms-win-core-rtlsupport-l1-1-0.def | 10 ++ .../lib32/api-ms-win-core-rtlsupport-l1-2-0.def | 7 --- 6 files changed, 22 insertions(+), 18 deletions(-) create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-1-0.def create mode 100644 mingw-w64-crt/lib32/api-ms-win-core-rtlsupport-l1-1-0.def diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index efe62903b..181bd46a5 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -2279,6 +2279,7 @@ endif %/libapi-ms-win-core-realtime-l1-1-2.a \ %/libapi-ms-win-core-registry-l1-1-0.a \ %/libapi-ms-win-core-registry-l2-1-0.a \ + %/libapi-ms-win-core-rtlsupport-l1-1-0.a \ %/libapi-ms-win-core-rtlsupport-l1-2-0.a \ %/libapi-ms-win-core-slapi-l1-1-0.a \ %/libapi-ms-win-core-string-l1-1-0.a \ diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-1-0.def new file mode 100644 index 0..e1d7002b4 --- /dev/null +++ b/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-1-0.def @@ -0,0 +1,10 @@ +LIBRARY api-ms-win-core-rtlsupport-l1-1-0 + +EXPORTS + +RtlCaptureContext +RtlCaptureStackBackTrace +RtlUnwind +RtlRestoreContext +RtlUnwindEx +RtlLookupFunctionEntry diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-2-0.def b/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-2-0.def index 89e8d2de1..d070d60d8 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-2-0.def +++ b/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-2-0.def @@ -2,16 +2,5 @@ LIBRARY api-ms-win-core-rtlsupport-l1-2-0 EXPORTS -RtlAddFunctionTable -RtlCaptureContext -RtlCaptureStackBackTrace -RtlCompareMemory -RtlDeleteFunctionTable -RtlInstallFunctionTableCallback -RtlLookupFunctionEntry RtlPcToFileHeader RtlRaiseException -RtlRestoreContext -RtlUnwind -RtlUnwindEx -RtlVirtualUnwind diff --git a/mingw-w64-crt/lib-common/windowsapp.mri b/mingw-w64-crt/lib-common/windowsapp.mri index 73e8ab470..64a6e745d 100644 --- a/mingw-w64-crt/lib-common/windowsapp.mri +++ b/mingw-w64-crt/lib-common/windowsapp.mri @@ -92,6 +92,7 @@ ADDLIB libapi-ms-win-core-realtime-l1-1-1.a ADDLIB libapi-ms-win-core-realtime-l1-1-2.a ADDLIB libapi-ms-win-core-registry-l1-1-0.a ADDLIB libapi-ms-win-core-registry-l2-1-0.a +ADDLIB libapi-ms-win-core-rtlsupport-l1-1-0.a ADDLIB libapi-ms-win-core-rtlsupport-l1-2-0.a ADDLIB libapi-ms-win-core-slapi-l1-1-0.a ADDLIB libapi-ms-win-core-string-l1-1-0.a diff --git a/mingw-w64-crt/lib32/api-ms-win-core-rtlsupport-l1-1-0.def b/mingw-w64-crt/lib32/api-ms-win-core-rtlsupport-l1-1-0.def new file mode 100644 index 0..29e0bb7b7 --- /dev/null +++ b/mingw-w64-crt/lib32/api-ms-win-core-rtlsupport-l1-1-0.def @@ -0,0 +1,10 @@ +LIBRARY api-ms-win-core-rtlsupport-l1-1-0 + +EXPORTS + +RtlCaptureContext@4 +RtlCaptureStackBackTrace@16 +RtlUnwind@16 +RtlRestoreContext@8 +RtlUnwindEx@24 +RtlLookupFunctionEntry@16 diff --git a/mingw-w64-crt/lib32/api-ms-win-core-rtlsupport-l1-2-0.def b/mingw-w64-crt/lib32/api-ms-win-core-rtlsupport-l1-2-0.def index c3d634df6..6846475aa 100644 --- a/mingw-w64-crt/lib32/api-ms-win-core-rtlsupport-l1-2-0.def +++ b/mingw-w64-crt/lib32/api-ms-win-core-rtlsupport-l1-2-0.def @@ -2,12 +2,5 @@ LIBRARY api-ms-win-core-rtlsupport-l1-2-0 EXPORTS -RtlCaptureContext@4 -RtlCaptureStackBackTrace@16 -RtlCompareMemory@12 -RtlLookupFunctionEntry RtlPcToFileHeader@8 RtlRaiseException@4 -RtlUnwind@16 -RtlUnwindEx -RtlVirtualUnwind -- 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: remove libgamemode from windowsapp
The 3 API's exported are found in api-ms-win-gaming-expandedresources-l1-1-0 which is part of windowsapp. This is the proper location accessing these API's from windowsapp [1]. That document says it was introduced in 16299/RS3 but it's actually found there in the 15063/RS2 SDK. Technically windowsapp also exports/redirects to a lot of non api-ms-*** DLLs, but not this one. [1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-gaming-expandedresources-l1-1-0dll --- mingw-w64-crt/lib-common/windowsapp.mri | 1 - 1 file changed, 1 deletion(-) diff --git a/mingw-w64-crt/lib-common/windowsapp.mri b/mingw-w64-crt/lib-common/windowsapp.mri index d1445a4a7..0df24d44c 100644 --- a/mingw-w64-crt/lib-common/windowsapp.mri +++ b/mingw-w64-crt/lib-common/windowsapp.mri @@ -1,5 +1,4 @@ CREATE libwindowsapp.a -ADDLIB libgamemode.a ADDLIB libapi-ms-win-core-com-l1-1-1.a ADDLIB libapi-ms-win-core-com-l2-1-1.a ADDLIB libapi-ms-win-core-com-midlproxystub-l1-1-0.a -- 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 v4 4/5] headers: allow more wincrypt API's in Win10 19H1 UWP builds
The API's are allowed in windowsapp since 19H1 and are allowed by the WACK.
Only the MS header don't specify it properly for WINAPI_FAMILY_PC_APP
but since the DLL is on all WINAPI_FAMILY_DESKTOP_APP and allowed by the
WACK this always works.
---
mingw-w64-headers/include/wincrypt.h | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index 4bcc3ff70..475ef7883 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -785,22 +785,17 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptReleaseContext (HCRYPTPROV hProv, DWORD dwFlags);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
-#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
#define CryptEnumProviderTypes __MINGW_NAME_AW(CryptEnumProviderTypes)
#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
#define CryptSetProviderEx __MINGW_NAME_AW(CryptSetProviderEx)
WINIMPM WINBOOL WINAPI CryptHashSessionKey (HCRYPTHASH hHash, HCRYPTKEY
hKey, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptSetProviderA (LPCSTR pszProvName, DWORD
dwProvType);
- WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
WINIMPM WINBOOL WINAPI CryptSetProviderExA (LPCSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptSetProviderExW (LPCWSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptEnumProviderTypesA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szTypeName, DWORD
*pcbTypeName);
WINIMPM WINBOOL WINAPI CryptEnumProviderTypesW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szTypeName, DWORD
*pcbTypeName);
- WINIMPM WINBOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szProvName, DWORD
*pcbProvName);
- WINIMPM WINBOOL WINAPI CryptEnumProvidersW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szProvName, DWORD
*pcbProvName);
WINIMPM WINBOOL WINAPI CryptContextAddRef (HCRYPTPROV hProv, DWORD
*pdwReserved, DWORD dwFlags);
- WINIMPM WINBOOL WINAPI CryptDuplicateKey (HCRYPTKEY hKey, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTKEY *phKey);
WINIMPM WINBOOL WINAPI CryptDuplicateHash (HCRYPTHASH hHash, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTHASH *phHash);
#if NTDDI_VERSION >= NTDDI_WS03
WINBOOL __cdecl GetEncSChannel (BYTE **pData, DWORD *dwDecSize);
@@ -845,6 +840,15 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptGetDefaultProviderW (DWORD dwProvType, DWORD
*pdwReserved, DWORD dwFlags, LPWSTR pszProvName, DWORD *pcbProvName);
#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_19H1
+ WINIMPM WINBOOL WINAPI CryptDuplicateKey (HCRYPTKEY hKey, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTKEY *phKey);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
+
+#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
+#endif
+
#ifndef _DDK_DRIVER_
typedef ULONG_PTR HCRYPTPROV_OR_NCRYPT_KEY_HANDLE;
typedef ULONG_PTR HCRYPTPROV_LEGACY;
--
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 v4 3/5] headers: allow more wincrypt API's in Win10 RS4 UWP builds
The API's are allowed in windowsapp since RS4 and are allowed by the WACK.
Only the MS header don't specify it properly for WINAPI_FAMILY_PC_APP
but since the DLL is on all WINAPI_FAMILY_DESKTOP_APP and allowed by the
WACK this always works.
CMS_DH_KEY_INFO is needed by CryptSetKeyParam().
---
mingw-w64-headers/include/wincrypt.h | 42 +++-
1 file changed, 23 insertions(+), 19 deletions(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index 05fd577fb..4bcc3ff70 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -785,6 +785,29 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptReleaseContext (HCRYPTPROV hProv, DWORD dwFlags);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
+#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
+#define CryptEnumProviderTypes __MINGW_NAME_AW(CryptEnumProviderTypes)
+#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
+#define CryptSetProviderEx __MINGW_NAME_AW(CryptSetProviderEx)
+
+ WINIMPM WINBOOL WINAPI CryptHashSessionKey (HCRYPTHASH hHash, HCRYPTKEY
hKey, DWORD dwFlags);
+ WINIMPM WINBOOL WINAPI CryptSetProviderA (LPCSTR pszProvName, DWORD
dwProvType);
+ WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
+ WINIMPM WINBOOL WINAPI CryptSetProviderExA (LPCSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
+ WINIMPM WINBOOL WINAPI CryptSetProviderExW (LPCWSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
+ WINIMPM WINBOOL WINAPI CryptEnumProviderTypesA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szTypeName, DWORD
*pcbTypeName);
+ WINIMPM WINBOOL WINAPI CryptEnumProviderTypesW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szTypeName, DWORD
*pcbTypeName);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptContextAddRef (HCRYPTPROV hProv, DWORD
*pdwReserved, DWORD dwFlags);
+ WINIMPM WINBOOL WINAPI CryptDuplicateKey (HCRYPTKEY hKey, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTKEY *phKey);
+ WINIMPM WINBOOL WINAPI CryptDuplicateHash (HCRYPTHASH hHash, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTHASH *phHash);
+#if NTDDI_VERSION >= NTDDI_WS03
+ WINBOOL __cdecl GetEncSChannel (BYTE **pData, DWORD *dwDecSize);
+#endif
+#endif
+
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_RS4
typedef struct _CMS_DH_KEY_INFO {
DWORD dwVersion;
ALG_ID Algid;
@@ -795,11 +818,7 @@ extern "C" {
#define CryptSignHash __MINGW_NAME_AW(CryptSignHash)
#define CryptVerifySignature __MINGW_NAME_AW(CryptVerifySignature)
-#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
-#define CryptSetProviderEx __MINGW_NAME_AW(CryptSetProviderEx)
#define CryptGetDefaultProvider __MINGW_NAME_AW(CryptGetDefaultProvider)
-#define CryptEnumProviderTypes __MINGW_NAME_AW(CryptEnumProviderTypes)
-#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
WINIMPM WINBOOL WINAPI CryptGenKey (HCRYPTPROV hProv, ALG_ID Algid, DWORD
dwFlags, HCRYPTKEY *phKey);
WINIMPM WINBOOL WINAPI CryptDeriveKey (HCRYPTPROV hProv, ALG_ID Algid,
HCRYPTHASH hBaseData, DWORD dwFlags, HCRYPTKEY *phKey);
@@ -817,28 +836,13 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptDecrypt (HCRYPTKEY hKey, HCRYPTHASH hHash,
WINBOOL Final, DWORD dwFlags, BYTE *pbData, DWORD *pdwDataLen);
WINIMPM WINBOOL WINAPI CryptCreateHash (HCRYPTPROV hProv, ALG_ID Algid,
HCRYPTKEY hKey, DWORD dwFlags, HCRYPTHASH *phHash);
WINIMPM WINBOOL WINAPI CryptHashData (HCRYPTHASH hHash, CONST BYTE *pbData,
DWORD dwDataLen, DWORD dwFlags);
- WINIMPM WINBOOL WINAPI CryptHashSessionKey (HCRYPTHASH hHash, HCRYPTKEY
hKey, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptDestroyHash (HCRYPTHASH hHash);
WINIMPM WINBOOL WINAPI CryptSignHashA (HCRYPTHASH hHash, DWORD dwKeySpec,
LPCSTR szDescription, DWORD dwFlags, BYTE *pbSignature, DWORD *pdwSigLen);
WINIMPM WINBOOL WINAPI CryptSignHashW (HCRYPTHASH hHash, DWORD dwKeySpec,
LPCWSTR szDescription, DWORD dwFlags, BYTE *pbSignature, DWORD *pdwSigLen);
WINIMPM WINBOOL WINAPI CryptVerifySignatureA (HCRYPTHASH hHash, CONST BYTE
*pbSignature, DWORD dwSigLen, HCRYPTKEY hPubKey, LPCSTR szDescription, DWORD
dwFlags);
WINIMPM WINBOOL WINAPI CryptVerifySignatureW (HCRYPTHASH hHash, CONST BYTE
*pbSignature, DWORD dwSigLen, HCRYPTKEY hPubKey, LPCWSTR szDescription, DWORD
dwFlags);
- WINIMPM WINBOOL WINAPI CryptSetProviderA (LPCSTR pszProvName, DWORD
dwProvType);
- WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
- WINIMPM WINBOOL
[Mingw-w64-public] [PATCH v4 5/5] crt: use wincrypt API from windowsapp in Windows 10
The hidden API are found in windowsapp since the RS4/19H1 SDK. They are also allowed by the WACK in api-ms-win-security-cryptoapi-l1-1-0. That DLL has been on all Windows 10 versions [1]. It's better to use the real API than using CCryptography winrt API just for these calls. Crypto.c is kept in the old winstorecompat when targetting Windows 8. Apps targetting UWP before 19H1 and using CryptGenRandom may not work if api-ms-win-security-cryptoapi-l1-1-0.dll on older Windows doesn't contain the entry. [1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-security-cryptoapi-l1-1-0dll --- .../api-ms-win-security-cryptoapi-l1-1-0.def | 12 .../lib32/api-ms-win-security-cryptoapi-l1-1-0.def | 12 mingw-w64-libraries/winstorecompat/Makefile.am | 1 - 3 files changed, 8 insertions(+), 17 deletions(-) diff --git a/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def index 08bd2c35e..ebeeda2c5 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def +++ b/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def @@ -2,10 +2,8 @@ LIBRARY api-ms-win-security-cryptoapi-l1-1-0 EXPORTS -; Implemented in windowsappcompat -;CryptAcquireContextA -; Implemented in windowsappcompat -;CryptAcquireContextW +CryptAcquireContextA +CryptAcquireContextW CryptCreateHash CryptDecrypt CryptDeriveKey @@ -17,8 +15,7 @@ CryptEnumProvidersA CryptEnumProvidersW CryptExportKey CryptGenKey -; Implemented in windowsappcompat -;CryptGenRandom +CryptGenRandom CryptGetDefaultProviderA CryptGetDefaultProviderW CryptGetHashParam @@ -27,8 +24,7 @@ CryptGetProvParam CryptGetUserKey CryptHashData CryptImportKey -; Implemented in windowsappcompat -;CryptReleaseContext +CryptReleaseContext CryptSetHashParam CryptSetKeyParam CryptSetProviderW diff --git a/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def b/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def index c851a41c9..2590c143c 100644 --- a/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def +++ b/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def @@ -2,10 +2,8 @@ LIBRARY api-ms-win-security-cryptoapi-l1-1-0 EXPORTS -; Implemented in windowsappcompat -;CryptAcquireContextA@20 -; Implemented in windowsappcompat -;CryptAcquireContextW@20 +CryptAcquireContextA@20 +CryptAcquireContextW@20 CryptCreateHash@20 CryptDecrypt@24 CryptDeriveKey@20 @@ -17,8 +15,7 @@ CryptEnumProvidersA@24 CryptEnumProvidersW@24 CryptExportKey@24 CryptGenKey@16 -; Implemented in windowsappcompat -;CryptGenRandom@12 +CryptGenRandom@12 CryptGetDefaultProviderA@20 CryptGetDefaultProviderW@20 CryptGetHashParam@20 @@ -27,8 +24,7 @@ CryptGetProvParam@20 CryptGetUserKey@12 CryptHashData@16 CryptImportKey@24 -; Implemented in windowsappcompat -;CryptReleaseContext@8 +CryptReleaseContext@8 CryptSetHashParam@16 CryptSetKeyParam@16 CryptSetProviderW@8 diff --git a/mingw-w64-libraries/winstorecompat/Makefile.am b/mingw-w64-libraries/winstorecompat/Makefile.am index 99016a051..55fb45841 100644 --- a/mingw-w64-libraries/winstorecompat/Makefile.am +++ b/mingw-w64-libraries/winstorecompat/Makefile.am @@ -57,7 +57,6 @@ libwindowsappcompat_a_SOURCES = \ src/GetFileSize.c \ src/SHGetFolderPathW.c \ src/QueueTimer.c \ - src/Crypto.c \ src/GetStartupInfo.c \ src/EnumProcessModules.c \ src/RtlAddFunctionTable.c \ -- 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 v4 1/5] headers: allow CryptAcquireContext in Win10 RS4 UWP builds
It's allowed by the WACK and in api-ms-win-security-cryptoapi-l1-1-0
since the 16299/RS4 SDK.
---
mingw-w64-headers/include/wincrypt.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index 8c719b1c5..e60e3cd23 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -773,10 +773,12 @@ extern "C" {
#endif
#endif
-#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) ||
defined(WINSTORECOMPAT)
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_RS4 || defined(WINSTORECOMPAT)
WINIMPM WINBOOL WINAPI CryptAcquireContextA (HCRYPTPROV *phProv, LPCSTR
szContainer, LPCSTR szProvider, DWORD dwProvType, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptAcquireContextW (HCRYPTPROV *phProv, LPCWSTR
szContainer, LPCWSTR szProvider, DWORD dwProvType, DWORD dwFlags);
#define CryptAcquireContext __MINGW_NAME_AW(CryptAcquireContext)
+#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) ||
defined(WINSTORECOMPAT)
WINIMPM WINBOOL WINAPI CryptGenRandom (HCRYPTPROV hProv, DWORD dwLen, BYTE
*pbBuffer);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP)
--
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 v4 2/5] headers: allow CryptGenRandom in Win10 19H1 UWP builds
It's allowed by the WACK and in api-ms-win-security-cryptoapi-l1-1-0
since the 18362/19H1 SDK.
---
mingw-w64-headers/include/wincrypt.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index e60e3cd23..05fd577fb 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -778,7 +778,7 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptAcquireContextW (HCRYPTPROV *phProv, LPCWSTR
szContainer, LPCWSTR szProvider, DWORD dwProvType, DWORD dwFlags);
#define CryptAcquireContext __MINGW_NAME_AW(CryptAcquireContext)
#endif
-#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) ||
defined(WINSTORECOMPAT)
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_19H1 || defined(WINSTORECOMPAT)
WINIMPM WINBOOL WINAPI CryptGenRandom (HCRYPTPROV hProv, DWORD dwLen, BYTE
*pbBuffer);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP)
--
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 4/5] headers: allow more wincrypt API's in Win10 19H1 UWP builds
On 2023-06-22 15:07, Steve Lhomme wrote: Hi, On 2023-06-22 15:00, LIU Hao wrote: 在 2023-06-22 17:15, Steve Lhomme 写道: The API's are allowed in windowsapp since 19H1 and are allowed by the WACK. Only the MS header don't specify it properly for WINAPI_FAMILY_PC_APP but since the DLL is on all WINAPI_FAMILY_DESKTOP_APP and allowed by the WACK this always works. --- mingw-w64-headers/include/wincrypt.h | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) There are now duplicate definitions of `CryptSetProvider`; is this intentional? No it's not. I forgot to remove the first one in my rebase. BTW I would like to know whether ANSI APIs are allowed in APPs. It looks a bit strange that there is only the ANSI variant `CryptEnumProvidersA` but not others. A lot of ANSI API's are allowed now. But not all of them. Sometimes they are not exported from the same DLL. For example SetVolumeLabelA vs SetVolumeLabelW in [1]. However I overlooked CryptEnumProvidersA. It is in fact allowed since 19H1, just like CryptEnumProvidersW. So it could be moved as well. Would you like me to send again that patch ? And I should read more carefully. This was about CryptSetProviderA, which is in fact *not* allowed in UWP. Expect v4 anytime soon... [1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis -- Best regards, LIU Hao ___ 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
[Mingw-w64-public] [PATCH v3 5/5] crt: use wincrypt API from windowsapp in Windows 10
The hidden API are found in windowsapp since the RS4/19H1 SDK. They are also allowed by the WACK in api-ms-win-security-cryptoapi-l1-1-0. That DLL has been on all Windows 10 versions [1]. It's better to use the real API than using CCryptography winrt API just for these calls. Crypto.c is kept in the old winstorecompat when targetting Windows 8. Apps targetting UWP before 19H1 and using CryptGenRandom may not work if api-ms-win-security-cryptoapi-l1-1-0.dll on older Windows doesn't contain the entry. [1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-security-cryptoapi-l1-1-0dll --- .../api-ms-win-security-cryptoapi-l1-1-0.def | 12 .../lib32/api-ms-win-security-cryptoapi-l1-1-0.def | 12 mingw-w64-libraries/winstorecompat/Makefile.am | 1 - 3 files changed, 8 insertions(+), 17 deletions(-) diff --git a/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def index 08bd2c35e..ebeeda2c5 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def +++ b/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def @@ -2,10 +2,8 @@ LIBRARY api-ms-win-security-cryptoapi-l1-1-0 EXPORTS -; Implemented in windowsappcompat -;CryptAcquireContextA -; Implemented in windowsappcompat -;CryptAcquireContextW +CryptAcquireContextA +CryptAcquireContextW CryptCreateHash CryptDecrypt CryptDeriveKey @@ -17,8 +15,7 @@ CryptEnumProvidersA CryptEnumProvidersW CryptExportKey CryptGenKey -; Implemented in windowsappcompat -;CryptGenRandom +CryptGenRandom CryptGetDefaultProviderA CryptGetDefaultProviderW CryptGetHashParam @@ -27,8 +24,7 @@ CryptGetProvParam CryptGetUserKey CryptHashData CryptImportKey -; Implemented in windowsappcompat -;CryptReleaseContext +CryptReleaseContext CryptSetHashParam CryptSetKeyParam CryptSetProviderW diff --git a/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def b/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def index c851a41c9..2590c143c 100644 --- a/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def +++ b/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def @@ -2,10 +2,8 @@ LIBRARY api-ms-win-security-cryptoapi-l1-1-0 EXPORTS -; Implemented in windowsappcompat -;CryptAcquireContextA@20 -; Implemented in windowsappcompat -;CryptAcquireContextW@20 +CryptAcquireContextA@20 +CryptAcquireContextW@20 CryptCreateHash@20 CryptDecrypt@24 CryptDeriveKey@20 @@ -17,8 +15,7 @@ CryptEnumProvidersA@24 CryptEnumProvidersW@24 CryptExportKey@24 CryptGenKey@16 -; Implemented in windowsappcompat -;CryptGenRandom@12 +CryptGenRandom@12 CryptGetDefaultProviderA@20 CryptGetDefaultProviderW@20 CryptGetHashParam@20 @@ -27,8 +24,7 @@ CryptGetProvParam@20 CryptGetUserKey@12 CryptHashData@16 CryptImportKey@24 -; Implemented in windowsappcompat -;CryptReleaseContext@8 +CryptReleaseContext@8 CryptSetHashParam@16 CryptSetKeyParam@16 CryptSetProviderW@8 diff --git a/mingw-w64-libraries/winstorecompat/Makefile.am b/mingw-w64-libraries/winstorecompat/Makefile.am index 99016a051..55fb45841 100644 --- a/mingw-w64-libraries/winstorecompat/Makefile.am +++ b/mingw-w64-libraries/winstorecompat/Makefile.am @@ -57,7 +57,6 @@ libwindowsappcompat_a_SOURCES = \ src/GetFileSize.c \ src/SHGetFolderPathW.c \ src/QueueTimer.c \ - src/Crypto.c \ src/GetStartupInfo.c \ src/EnumProcessModules.c \ src/RtlAddFunctionTable.c \ -- 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 v3 3/5] headers: allow more wincrypt API's in Win10 RS4 UWP builds
The API's are allowed in windowsapp since RS4 and are allowed by the WACK.
Only the MS header don't specify it properly for WINAPI_FAMILY_PC_APP
but since the DLL is on all WINAPI_FAMILY_DESKTOP_APP and allowed by the
WACK this always works.
CMS_DH_KEY_INFO is needed by CryptSetKeyParam().
---
mingw-w64-headers/include/wincrypt.h | 42 +++-
1 file changed, 23 insertions(+), 19 deletions(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index 05fd577fb..4bcc3ff70 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -785,6 +785,29 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptReleaseContext (HCRYPTPROV hProv, DWORD dwFlags);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
+#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
+#define CryptEnumProviderTypes __MINGW_NAME_AW(CryptEnumProviderTypes)
+#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
+#define CryptSetProviderEx __MINGW_NAME_AW(CryptSetProviderEx)
+
+ WINIMPM WINBOOL WINAPI CryptHashSessionKey (HCRYPTHASH hHash, HCRYPTKEY
hKey, DWORD dwFlags);
+ WINIMPM WINBOOL WINAPI CryptSetProviderA (LPCSTR pszProvName, DWORD
dwProvType);
+ WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
+ WINIMPM WINBOOL WINAPI CryptSetProviderExA (LPCSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
+ WINIMPM WINBOOL WINAPI CryptSetProviderExW (LPCWSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
+ WINIMPM WINBOOL WINAPI CryptEnumProviderTypesA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szTypeName, DWORD
*pcbTypeName);
+ WINIMPM WINBOOL WINAPI CryptEnumProviderTypesW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szTypeName, DWORD
*pcbTypeName);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptContextAddRef (HCRYPTPROV hProv, DWORD
*pdwReserved, DWORD dwFlags);
+ WINIMPM WINBOOL WINAPI CryptDuplicateKey (HCRYPTKEY hKey, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTKEY *phKey);
+ WINIMPM WINBOOL WINAPI CryptDuplicateHash (HCRYPTHASH hHash, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTHASH *phHash);
+#if NTDDI_VERSION >= NTDDI_WS03
+ WINBOOL __cdecl GetEncSChannel (BYTE **pData, DWORD *dwDecSize);
+#endif
+#endif
+
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_RS4
typedef struct _CMS_DH_KEY_INFO {
DWORD dwVersion;
ALG_ID Algid;
@@ -795,11 +818,7 @@ extern "C" {
#define CryptSignHash __MINGW_NAME_AW(CryptSignHash)
#define CryptVerifySignature __MINGW_NAME_AW(CryptVerifySignature)
-#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
-#define CryptSetProviderEx __MINGW_NAME_AW(CryptSetProviderEx)
#define CryptGetDefaultProvider __MINGW_NAME_AW(CryptGetDefaultProvider)
-#define CryptEnumProviderTypes __MINGW_NAME_AW(CryptEnumProviderTypes)
-#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
WINIMPM WINBOOL WINAPI CryptGenKey (HCRYPTPROV hProv, ALG_ID Algid, DWORD
dwFlags, HCRYPTKEY *phKey);
WINIMPM WINBOOL WINAPI CryptDeriveKey (HCRYPTPROV hProv, ALG_ID Algid,
HCRYPTHASH hBaseData, DWORD dwFlags, HCRYPTKEY *phKey);
@@ -817,28 +836,13 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptDecrypt (HCRYPTKEY hKey, HCRYPTHASH hHash,
WINBOOL Final, DWORD dwFlags, BYTE *pbData, DWORD *pdwDataLen);
WINIMPM WINBOOL WINAPI CryptCreateHash (HCRYPTPROV hProv, ALG_ID Algid,
HCRYPTKEY hKey, DWORD dwFlags, HCRYPTHASH *phHash);
WINIMPM WINBOOL WINAPI CryptHashData (HCRYPTHASH hHash, CONST BYTE *pbData,
DWORD dwDataLen, DWORD dwFlags);
- WINIMPM WINBOOL WINAPI CryptHashSessionKey (HCRYPTHASH hHash, HCRYPTKEY
hKey, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptDestroyHash (HCRYPTHASH hHash);
WINIMPM WINBOOL WINAPI CryptSignHashA (HCRYPTHASH hHash, DWORD dwKeySpec,
LPCSTR szDescription, DWORD dwFlags, BYTE *pbSignature, DWORD *pdwSigLen);
WINIMPM WINBOOL WINAPI CryptSignHashW (HCRYPTHASH hHash, DWORD dwKeySpec,
LPCWSTR szDescription, DWORD dwFlags, BYTE *pbSignature, DWORD *pdwSigLen);
WINIMPM WINBOOL WINAPI CryptVerifySignatureA (HCRYPTHASH hHash, CONST BYTE
*pbSignature, DWORD dwSigLen, HCRYPTKEY hPubKey, LPCSTR szDescription, DWORD
dwFlags);
WINIMPM WINBOOL WINAPI CryptVerifySignatureW (HCRYPTHASH hHash, CONST BYTE
*pbSignature, DWORD dwSigLen, HCRYPTKEY hPubKey, LPCWSTR szDescription, DWORD
dwFlags);
- WINIMPM WINBOOL WINAPI CryptSetProviderA (LPCSTR pszProvName, DWORD
dwProvType);
- WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
- WINIMPM WINBOOL
[Mingw-w64-public] [PATCH v3 1/5] headers: allow CryptAcquireContext in Win10 RS4 UWP builds
It's allowed by the WACK and in api-ms-win-security-cryptoapi-l1-1-0
since the 16299/RS4 SDK.
---
mingw-w64-headers/include/wincrypt.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index 8c719b1c5..e60e3cd23 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -773,10 +773,12 @@ extern "C" {
#endif
#endif
-#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) ||
defined(WINSTORECOMPAT)
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_RS4 || defined(WINSTORECOMPAT)
WINIMPM WINBOOL WINAPI CryptAcquireContextA (HCRYPTPROV *phProv, LPCSTR
szContainer, LPCSTR szProvider, DWORD dwProvType, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptAcquireContextW (HCRYPTPROV *phProv, LPCWSTR
szContainer, LPCWSTR szProvider, DWORD dwProvType, DWORD dwFlags);
#define CryptAcquireContext __MINGW_NAME_AW(CryptAcquireContext)
+#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) ||
defined(WINSTORECOMPAT)
WINIMPM WINBOOL WINAPI CryptGenRandom (HCRYPTPROV hProv, DWORD dwLen, BYTE
*pbBuffer);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP)
--
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 v3 4/5] headers: allow more wincrypt API's in Win10 19H1 UWP builds
The API's are allowed in windowsapp since 19H1 and are allowed by the WACK.
Only the MS header don't specify it properly for WINAPI_FAMILY_PC_APP
but since the DLL is on all WINAPI_FAMILY_DESKTOP_APP and allowed by the
WACK this always works.
---
mingw-w64-headers/include/wincrypt.h | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index 4bcc3ff70..474e56642 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -785,22 +785,15 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptReleaseContext (HCRYPTPROV hProv, DWORD dwFlags);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
-#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
#define CryptEnumProviderTypes __MINGW_NAME_AW(CryptEnumProviderTypes)
-#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
#define CryptSetProviderEx __MINGW_NAME_AW(CryptSetProviderEx)
WINIMPM WINBOOL WINAPI CryptHashSessionKey (HCRYPTHASH hHash, HCRYPTKEY
hKey, DWORD dwFlags);
- WINIMPM WINBOOL WINAPI CryptSetProviderA (LPCSTR pszProvName, DWORD
dwProvType);
- WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
WINIMPM WINBOOL WINAPI CryptSetProviderExA (LPCSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptSetProviderExW (LPCWSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptEnumProviderTypesA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szTypeName, DWORD
*pcbTypeName);
WINIMPM WINBOOL WINAPI CryptEnumProviderTypesW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szTypeName, DWORD
*pcbTypeName);
- WINIMPM WINBOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szProvName, DWORD
*pcbProvName);
- WINIMPM WINBOOL WINAPI CryptEnumProvidersW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szProvName, DWORD
*pcbProvName);
WINIMPM WINBOOL WINAPI CryptContextAddRef (HCRYPTPROV hProv, DWORD
*pdwReserved, DWORD dwFlags);
- WINIMPM WINBOOL WINAPI CryptDuplicateKey (HCRYPTKEY hKey, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTKEY *phKey);
WINIMPM WINBOOL WINAPI CryptDuplicateHash (HCRYPTHASH hHash, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTHASH *phHash);
#if NTDDI_VERSION >= NTDDI_WS03
WINBOOL __cdecl GetEncSChannel (BYTE **pData, DWORD *dwDecSize);
@@ -845,6 +838,17 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptGetDefaultProviderW (DWORD dwProvType, DWORD
*pdwReserved, DWORD dwFlags, LPWSTR pszProvName, DWORD *pcbProvName);
#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_19H1
+ WINIMPM WINBOOL WINAPI CryptDuplicateKey (HCRYPTKEY hKey, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTKEY *phKey);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
+ WINIMPM WINBOOL WINAPI CryptSetProviderA (LPCSTR pszProvName, DWORD
dwProvType);
+
+#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
+#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
+#endif
+
#ifndef _DDK_DRIVER_
typedef ULONG_PTR HCRYPTPROV_OR_NCRYPT_KEY_HANDLE;
typedef ULONG_PTR HCRYPTPROV_LEGACY;
--
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 v3 2/5] headers: allow CryptGenRandom in Win10 19H1 UWP builds
It's allowed by the WACK and in api-ms-win-security-cryptoapi-l1-1-0
since the 18362/19H1 SDK.
---
mingw-w64-headers/include/wincrypt.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index e60e3cd23..05fd577fb 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -778,7 +778,7 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptAcquireContextW (HCRYPTPROV *phProv, LPCWSTR
szContainer, LPCWSTR szProvider, DWORD dwProvType, DWORD dwFlags);
#define CryptAcquireContext __MINGW_NAME_AW(CryptAcquireContext)
#endif
-#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) ||
defined(WINSTORECOMPAT)
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_19H1 || defined(WINSTORECOMPAT)
WINIMPM WINBOOL WINAPI CryptGenRandom (HCRYPTPROV hProv, DWORD dwLen, BYTE
*pbBuffer);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP)
--
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 v2 4/5] headers: allow more wincrypt API's in Win10 19H1 UWP builds
On 2023-06-23 7:42, Steve Lhomme wrote:
The API's are allowed in windowsapp since 19H1 and are allowed by the WACK.
Only the MS header don't specify it properly for WINAPI_FAMILY_PC_APP
but since the DLL is on all WINAPI_FAMILY_DESKTOP_APP and allowed by the
WACK this always works.
---
mingw-w64-headers/include/wincrypt.h | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index 1f05a3587..cc1fab35d 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -788,19 +788,13 @@ extern "C" {
#define CryptSetProviderEx __MINGW_NAME_AW(CryptSetProviderEx)
#define CryptEnumProviderTypes __MINGW_NAME_AW(CryptEnumProviderTypes)
#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
Oops, another stray one...
-#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
WINIMPM WINBOOL WINAPI CryptHashSessionKey (HCRYPTHASH hHash, HCRYPTKEY hKey, DWORD dwFlags);
- WINIMPM WINBOOL WINAPI CryptSetProviderA (LPCSTR pszProvName, DWORD
dwProvType);
- WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
WINIMPM WINBOOL WINAPI CryptSetProviderExA (LPCSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptSetProviderExW (LPCWSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptEnumProviderTypesA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szTypeName, DWORD
*pcbTypeName);
WINIMPM WINBOOL WINAPI CryptEnumProviderTypesW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szTypeName, DWORD
*pcbTypeName);
- WINIMPM WINBOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szProvName, DWORD
*pcbProvName);
- WINIMPM WINBOOL WINAPI CryptEnumProvidersW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szProvName, DWORD
*pcbProvName);
WINIMPM WINBOOL WINAPI CryptContextAddRef (HCRYPTPROV hProv, DWORD
*pdwReserved, DWORD dwFlags);
- WINIMPM WINBOOL WINAPI CryptDuplicateKey (HCRYPTKEY hKey, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTKEY *phKey);
WINIMPM WINBOOL WINAPI CryptDuplicateHash (HCRYPTHASH hHash, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTHASH *phHash);
#if NTDDI_VERSION >= NTDDI_WS03
WINBOOL __cdecl GetEncSChannel (BYTE **pData, DWORD *dwDecSize);
@@ -845,6 +839,17 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptGetDefaultProviderW (DWORD dwProvType, DWORD
*pdwReserved, DWORD dwFlags, LPWSTR pszProvName, DWORD *pcbProvName);
#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >= NTDDI_WIN10_19H1
+ WINIMPM WINBOOL WINAPI CryptDuplicateKey (HCRYPTKEY hKey, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTKEY *phKey);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
+ WINIMPM WINBOOL WINAPI CryptSetProviderA (LPCSTR pszProvName, DWORD
dwProvType);
+
+#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
+#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
+#endif
+
#ifndef _DDK_DRIVER_
typedef ULONG_PTR HCRYPTPROV_OR_NCRYPT_KEY_HANDLE;
typedef ULONG_PTR HCRYPTPROV_LEGACY;
--
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 mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH v2 4/5] headers: allow more wincrypt API's in Win10 19H1 UWP builds
The API's are allowed in windowsapp since 19H1 and are allowed by the WACK.
Only the MS header don't specify it properly for WINAPI_FAMILY_PC_APP
but since the DLL is on all WINAPI_FAMILY_DESKTOP_APP and allowed by the
WACK this always works.
---
mingw-w64-headers/include/wincrypt.h | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index 1f05a3587..cc1fab35d 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -788,19 +788,13 @@ extern "C" {
#define CryptSetProviderEx __MINGW_NAME_AW(CryptSetProviderEx)
#define CryptEnumProviderTypes __MINGW_NAME_AW(CryptEnumProviderTypes)
#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
-#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
WINIMPM WINBOOL WINAPI CryptHashSessionKey (HCRYPTHASH hHash, HCRYPTKEY
hKey, DWORD dwFlags);
- WINIMPM WINBOOL WINAPI CryptSetProviderA (LPCSTR pszProvName, DWORD
dwProvType);
- WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
WINIMPM WINBOOL WINAPI CryptSetProviderExA (LPCSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptSetProviderExW (LPCWSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptEnumProviderTypesA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szTypeName, DWORD
*pcbTypeName);
WINIMPM WINBOOL WINAPI CryptEnumProviderTypesW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szTypeName, DWORD
*pcbTypeName);
- WINIMPM WINBOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szProvName, DWORD
*pcbProvName);
- WINIMPM WINBOOL WINAPI CryptEnumProvidersW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szProvName, DWORD
*pcbProvName);
WINIMPM WINBOOL WINAPI CryptContextAddRef (HCRYPTPROV hProv, DWORD
*pdwReserved, DWORD dwFlags);
- WINIMPM WINBOOL WINAPI CryptDuplicateKey (HCRYPTKEY hKey, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTKEY *phKey);
WINIMPM WINBOOL WINAPI CryptDuplicateHash (HCRYPTHASH hHash, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTHASH *phHash);
#if NTDDI_VERSION >= NTDDI_WS03
WINBOOL __cdecl GetEncSChannel (BYTE **pData, DWORD *dwDecSize);
@@ -845,6 +839,17 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptGetDefaultProviderW (DWORD dwProvType, DWORD
*pdwReserved, DWORD dwFlags, LPWSTR pszProvName, DWORD *pcbProvName);
#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_19H1
+ WINIMPM WINBOOL WINAPI CryptDuplicateKey (HCRYPTKEY hKey, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTKEY *phKey);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
+ WINIMPM WINBOOL WINAPI CryptSetProviderA (LPCSTR pszProvName, DWORD
dwProvType);
+
+#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
+#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
+#endif
+
#ifndef _DDK_DRIVER_
typedef ULONG_PTR HCRYPTPROV_OR_NCRYPT_KEY_HANDLE;
typedef ULONG_PTR HCRYPTPROV_LEGACY;
--
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 v2 2/5] headers: allow CryptGenRandom in Win10 19H1 UWP builds
It's allowed by the WACK and in api-ms-win-security-cryptoapi-l1-1-0
since the 18362/19H1 SDK.
---
mingw-w64-headers/include/wincrypt.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index e60e3cd23..05fd577fb 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -778,7 +778,7 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptAcquireContextW (HCRYPTPROV *phProv, LPCWSTR
szContainer, LPCWSTR szProvider, DWORD dwProvType, DWORD dwFlags);
#define CryptAcquireContext __MINGW_NAME_AW(CryptAcquireContext)
#endif
-#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) ||
defined(WINSTORECOMPAT)
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_19H1 || defined(WINSTORECOMPAT)
WINIMPM WINBOOL WINAPI CryptGenRandom (HCRYPTPROV hProv, DWORD dwLen, BYTE
*pbBuffer);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP)
--
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 v2 1/5] headers: allow CryptAcquireContext in Win10 RS4 UWP builds
It's allowed by the WACK and in api-ms-win-security-cryptoapi-l1-1-0
since the 16299/RS4 SDK.
---
mingw-w64-headers/include/wincrypt.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index 8c719b1c5..e60e3cd23 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -773,10 +773,12 @@ extern "C" {
#endif
#endif
-#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) ||
defined(WINSTORECOMPAT)
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_RS4 || defined(WINSTORECOMPAT)
WINIMPM WINBOOL WINAPI CryptAcquireContextA (HCRYPTPROV *phProv, LPCSTR
szContainer, LPCSTR szProvider, DWORD dwProvType, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptAcquireContextW (HCRYPTPROV *phProv, LPCWSTR
szContainer, LPCWSTR szProvider, DWORD dwProvType, DWORD dwFlags);
#define CryptAcquireContext __MINGW_NAME_AW(CryptAcquireContext)
+#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) ||
defined(WINSTORECOMPAT)
WINIMPM WINBOOL WINAPI CryptGenRandom (HCRYPTPROV hProv, DWORD dwLen, BYTE
*pbBuffer);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP)
--
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 v2 5/5] crt: use wincrypt API from windowsapp in Windows 10
The hidden API are found in windowsapp since the RS4/19H1 SDK. They are also allowed by the WACK in api-ms-win-security-cryptoapi-l1-1-0. That DLL has been on all Windows 10 versions [1]. It's better to use the real API than using CCryptography winrt API just for these calls. Crypto.c is kept in the old winstorecompat when targetting Windows 8. Apps targetting UWP before 19H1 and using CryptGenRandom may not work if api-ms-win-security-cryptoapi-l1-1-0.dll on older Windows doesn't contain the entry. [1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-security-cryptoapi-l1-1-0dll --- .../api-ms-win-security-cryptoapi-l1-1-0.def | 12 .../lib32/api-ms-win-security-cryptoapi-l1-1-0.def | 12 mingw-w64-libraries/winstorecompat/Makefile.am | 1 - 3 files changed, 8 insertions(+), 17 deletions(-) diff --git a/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def index 08bd2c35e..ebeeda2c5 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def +++ b/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def @@ -2,10 +2,8 @@ LIBRARY api-ms-win-security-cryptoapi-l1-1-0 EXPORTS -; Implemented in windowsappcompat -;CryptAcquireContextA -; Implemented in windowsappcompat -;CryptAcquireContextW +CryptAcquireContextA +CryptAcquireContextW CryptCreateHash CryptDecrypt CryptDeriveKey @@ -17,8 +15,7 @@ CryptEnumProvidersA CryptEnumProvidersW CryptExportKey CryptGenKey -; Implemented in windowsappcompat -;CryptGenRandom +CryptGenRandom CryptGetDefaultProviderA CryptGetDefaultProviderW CryptGetHashParam @@ -27,8 +24,7 @@ CryptGetProvParam CryptGetUserKey CryptHashData CryptImportKey -; Implemented in windowsappcompat -;CryptReleaseContext +CryptReleaseContext CryptSetHashParam CryptSetKeyParam CryptSetProviderW diff --git a/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def b/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def index c851a41c9..2590c143c 100644 --- a/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def +++ b/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def @@ -2,10 +2,8 @@ LIBRARY api-ms-win-security-cryptoapi-l1-1-0 EXPORTS -; Implemented in windowsappcompat -;CryptAcquireContextA@20 -; Implemented in windowsappcompat -;CryptAcquireContextW@20 +CryptAcquireContextA@20 +CryptAcquireContextW@20 CryptCreateHash@20 CryptDecrypt@24 CryptDeriveKey@20 @@ -17,8 +15,7 @@ CryptEnumProvidersA@24 CryptEnumProvidersW@24 CryptExportKey@24 CryptGenKey@16 -; Implemented in windowsappcompat -;CryptGenRandom@12 +CryptGenRandom@12 CryptGetDefaultProviderA@20 CryptGetDefaultProviderW@20 CryptGetHashParam@20 @@ -27,8 +24,7 @@ CryptGetProvParam@20 CryptGetUserKey@12 CryptHashData@16 CryptImportKey@24 -; Implemented in windowsappcompat -;CryptReleaseContext@8 +CryptReleaseContext@8 CryptSetHashParam@16 CryptSetKeyParam@16 CryptSetProviderW@8 diff --git a/mingw-w64-libraries/winstorecompat/Makefile.am b/mingw-w64-libraries/winstorecompat/Makefile.am index 99016a051..55fb45841 100644 --- a/mingw-w64-libraries/winstorecompat/Makefile.am +++ b/mingw-w64-libraries/winstorecompat/Makefile.am @@ -57,7 +57,6 @@ libwindowsappcompat_a_SOURCES = \ src/GetFileSize.c \ src/SHGetFolderPathW.c \ src/QueueTimer.c \ - src/Crypto.c \ src/GetStartupInfo.c \ src/EnumProcessModules.c \ src/RtlAddFunctionTable.c \ -- 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 v2 3/5] headers: allow more wincrypt API's in Win10 RS4 UWP builds
The API's are allowed in windowsapp since RS4 and are allowed by the WACK.
Only the MS header don't specify it properly for WINAPI_FAMILY_PC_APP
but since the DLL is on all WINAPI_FAMILY_DESKTOP_APP and allowed by the
WACK this always works.
CMS_DH_KEY_INFO is needed by CryptSetKeyParam().
---
mingw-w64-headers/include/wincrypt.h | 42 +++-
1 file changed, 23 insertions(+), 19 deletions(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index 05fd577fb..1f05a3587 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -785,6 +785,29 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptReleaseContext (HCRYPTPROV hProv, DWORD dwFlags);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
+#define CryptSetProviderEx __MINGW_NAME_AW(CryptSetProviderEx)
+#define CryptEnumProviderTypes __MINGW_NAME_AW(CryptEnumProviderTypes)
+#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
+#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
+
+ WINIMPM WINBOOL WINAPI CryptHashSessionKey (HCRYPTHASH hHash, HCRYPTKEY
hKey, DWORD dwFlags);
+ WINIMPM WINBOOL WINAPI CryptSetProviderA (LPCSTR pszProvName, DWORD
dwProvType);
+ WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
+ WINIMPM WINBOOL WINAPI CryptSetProviderExA (LPCSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
+ WINIMPM WINBOOL WINAPI CryptSetProviderExW (LPCWSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
+ WINIMPM WINBOOL WINAPI CryptEnumProviderTypesA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szTypeName, DWORD
*pcbTypeName);
+ WINIMPM WINBOOL WINAPI CryptEnumProviderTypesW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szTypeName, DWORD
*pcbTypeName);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptContextAddRef (HCRYPTPROV hProv, DWORD
*pdwReserved, DWORD dwFlags);
+ WINIMPM WINBOOL WINAPI CryptDuplicateKey (HCRYPTKEY hKey, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTKEY *phKey);
+ WINIMPM WINBOOL WINAPI CryptDuplicateHash (HCRYPTHASH hHash, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTHASH *phHash);
+#if NTDDI_VERSION >= NTDDI_WS03
+ WINBOOL __cdecl GetEncSChannel (BYTE **pData, DWORD *dwDecSize);
+#endif
+#endif
+
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_RS4
typedef struct _CMS_DH_KEY_INFO {
DWORD dwVersion;
ALG_ID Algid;
@@ -795,11 +818,7 @@ extern "C" {
#define CryptSignHash __MINGW_NAME_AW(CryptSignHash)
#define CryptVerifySignature __MINGW_NAME_AW(CryptVerifySignature)
-#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
-#define CryptSetProviderEx __MINGW_NAME_AW(CryptSetProviderEx)
#define CryptGetDefaultProvider __MINGW_NAME_AW(CryptGetDefaultProvider)
-#define CryptEnumProviderTypes __MINGW_NAME_AW(CryptEnumProviderTypes)
-#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
WINIMPM WINBOOL WINAPI CryptGenKey (HCRYPTPROV hProv, ALG_ID Algid, DWORD
dwFlags, HCRYPTKEY *phKey);
WINIMPM WINBOOL WINAPI CryptDeriveKey (HCRYPTPROV hProv, ALG_ID Algid,
HCRYPTHASH hBaseData, DWORD dwFlags, HCRYPTKEY *phKey);
@@ -817,28 +836,13 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptDecrypt (HCRYPTKEY hKey, HCRYPTHASH hHash,
WINBOOL Final, DWORD dwFlags, BYTE *pbData, DWORD *pdwDataLen);
WINIMPM WINBOOL WINAPI CryptCreateHash (HCRYPTPROV hProv, ALG_ID Algid,
HCRYPTKEY hKey, DWORD dwFlags, HCRYPTHASH *phHash);
WINIMPM WINBOOL WINAPI CryptHashData (HCRYPTHASH hHash, CONST BYTE *pbData,
DWORD dwDataLen, DWORD dwFlags);
- WINIMPM WINBOOL WINAPI CryptHashSessionKey (HCRYPTHASH hHash, HCRYPTKEY
hKey, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptDestroyHash (HCRYPTHASH hHash);
WINIMPM WINBOOL WINAPI CryptSignHashA (HCRYPTHASH hHash, DWORD dwKeySpec,
LPCSTR szDescription, DWORD dwFlags, BYTE *pbSignature, DWORD *pdwSigLen);
WINIMPM WINBOOL WINAPI CryptSignHashW (HCRYPTHASH hHash, DWORD dwKeySpec,
LPCWSTR szDescription, DWORD dwFlags, BYTE *pbSignature, DWORD *pdwSigLen);
WINIMPM WINBOOL WINAPI CryptVerifySignatureA (HCRYPTHASH hHash, CONST BYTE
*pbSignature, DWORD dwSigLen, HCRYPTKEY hPubKey, LPCSTR szDescription, DWORD
dwFlags);
WINIMPM WINBOOL WINAPI CryptVerifySignatureW (HCRYPTHASH hHash, CONST BYTE
*pbSignature, DWORD dwSigLen, HCRYPTKEY hPubKey, LPCWSTR szDescription, DWORD
dwFlags);
- WINIMPM WINBOOL WINAPI CryptSetProviderA (LPCSTR pszProvName, DWORD
dwProvType);
- WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
- WINIMPM WINBOOL
Re: [Mingw-w64-public] [PATCH 4/5] headers: allow more wincrypt API's in Win10 19H1 UWP builds
Hi, On 2023-06-22 15:00, LIU Hao wrote: 在 2023-06-22 17:15, Steve Lhomme 写道: The API's are allowed in windowsapp since 19H1 and are allowed by the WACK. Only the MS header don't specify it properly for WINAPI_FAMILY_PC_APP but since the DLL is on all WINAPI_FAMILY_DESKTOP_APP and allowed by the WACK this always works. --- mingw-w64-headers/include/wincrypt.h | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) There are now duplicate definitions of `CryptSetProvider`; is this intentional? No it's not. I forgot to remove the first one in my rebase. BTW I would like to know whether ANSI APIs are allowed in APPs. It looks a bit strange that there is only the ANSI variant `CryptEnumProvidersA` but not others. A lot of ANSI API's are allowed now. But not all of them. Sometimes they are not exported from the same DLL. For example SetVolumeLabelA vs SetVolumeLabelW in [1]. However I overlooked CryptEnumProvidersA. It is in fact allowed since 19H1, just like CryptEnumProvidersW. So it could be moved as well. Would you like me to send again that patch ? [1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis -- Best regards, LIU Hao ___ 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/5] headers: allow CryptAcquireContext in Win10 RS4 UWP builds
It's allowed by the WACK and in api-ms-win-security-cryptoapi-l1-1-0
since the 16299/RS4 SDK.
---
mingw-w64-headers/include/wincrypt.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index 8c719b1c5..e60e3cd23 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -773,10 +773,12 @@ extern "C" {
#endif
#endif
-#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) ||
defined(WINSTORECOMPAT)
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_RS4 || defined(WINSTORECOMPAT)
WINIMPM WINBOOL WINAPI CryptAcquireContextA (HCRYPTPROV *phProv, LPCSTR
szContainer, LPCSTR szProvider, DWORD dwProvType, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptAcquireContextW (HCRYPTPROV *phProv, LPCWSTR
szContainer, LPCWSTR szProvider, DWORD dwProvType, DWORD dwFlags);
#define CryptAcquireContext __MINGW_NAME_AW(CryptAcquireContext)
+#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) ||
defined(WINSTORECOMPAT)
WINIMPM WINBOOL WINAPI CryptGenRandom (HCRYPTPROV hProv, DWORD dwLen, BYTE
*pbBuffer);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP)
--
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 4/5] headers: allow more wincrypt API's in Win10 19H1 UWP builds
The API's are allowed in windowsapp since 19H1 and are allowed by the WACK.
Only the MS header don't specify it properly for WINAPI_FAMILY_PC_APP
but since the DLL is on all WINAPI_FAMILY_DESKTOP_APP and allowed by the
WACK this always works.
---
mingw-w64-headers/include/wincrypt.h | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index 675f6d618..e2fdcbe9b 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -792,15 +792,11 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptHashSessionKey (HCRYPTHASH hHash, HCRYPTKEY
hKey, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptSetProviderA (LPCSTR pszProvName, DWORD
dwProvType);
- WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
WINIMPM WINBOOL WINAPI CryptSetProviderExA (LPCSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptSetProviderExW (LPCWSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptEnumProviderTypesA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szTypeName, DWORD
*pcbTypeName);
WINIMPM WINBOOL WINAPI CryptEnumProviderTypesW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szTypeName, DWORD
*pcbTypeName);
- WINIMPM WINBOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szProvName, DWORD
*pcbProvName);
- WINIMPM WINBOOL WINAPI CryptEnumProvidersW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szProvName, DWORD
*pcbProvName);
WINIMPM WINBOOL WINAPI CryptContextAddRef (HCRYPTPROV hProv, DWORD
*pdwReserved, DWORD dwFlags);
- WINIMPM WINBOOL WINAPI CryptDuplicateKey (HCRYPTKEY hKey, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTKEY *phKey);
WINIMPM WINBOOL WINAPI CryptDuplicateHash (HCRYPTHASH hHash, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTHASH *phHash);
#if NTDDI_VERSION >= NTDDI_WS03
WINBOOL __cdecl GetEncSChannel (BYTE **pData, DWORD *dwDecSize);
@@ -818,9 +814,7 @@ extern "C" {
#define CryptSignHash __MINGW_NAME_AW(CryptSignHash)
#define CryptVerifySignature __MINGW_NAME_AW(CryptVerifySignature)
-#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
#define CryptGetDefaultProvider __MINGW_NAME_AW(CryptGetDefaultProvider)
-#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
WINIMPM WINBOOL WINAPI CryptGenKey (HCRYPTPROV hProv, ALG_ID Algid, DWORD
dwFlags, HCRYPTKEY *phKey);
WINIMPM WINBOOL WINAPI CryptDeriveKey (HCRYPTPROV hProv, ALG_ID Algid,
HCRYPTHASH hBaseData, DWORD dwFlags, HCRYPTKEY *phKey);
@@ -847,6 +841,16 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptGetDefaultProviderW (DWORD dwProvType, DWORD
*pdwReserved, DWORD dwFlags, LPWSTR pszProvName, DWORD *pcbProvName);
#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_19H1
+ WINIMPM WINBOOL WINAPI CryptDuplicateKey (HCRYPTKEY hKey, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTKEY *phKey);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
+
+#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
+#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
+#endif
+
#ifndef _DDK_DRIVER_
typedef ULONG_PTR HCRYPTPROV_OR_NCRYPT_KEY_HANDLE;
typedef ULONG_PTR HCRYPTPROV_LEGACY;
--
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/5] headers: allow CryptGenRandom in Win10 19H1 UWP builds
It's allowed by the WACK and in api-ms-win-security-cryptoapi-l1-1-0
since the 18362/19H1 SDK.
---
mingw-w64-headers/include/wincrypt.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index e60e3cd23..05fd577fb 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -778,7 +778,7 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptAcquireContextW (HCRYPTPROV *phProv, LPCWSTR
szContainer, LPCWSTR szProvider, DWORD dwProvType, DWORD dwFlags);
#define CryptAcquireContext __MINGW_NAME_AW(CryptAcquireContext)
#endif
-#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) ||
defined(WINSTORECOMPAT)
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_19H1 || defined(WINSTORECOMPAT)
WINIMPM WINBOOL WINAPI CryptGenRandom (HCRYPTPROV hProv, DWORD dwLen, BYTE
*pbBuffer);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP)
--
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 3/5] headers: allow more wincrypt API's in Win10 RS4 UWP builds
The API's are allowed in windowsapp since RS4 and are allowed by the WACK.
Only the MS header don't specify it properly for WINAPI_FAMILY_PC_APP
but since the DLL is on all WINAPI_FAMILY_DESKTOP_APP and allowed by the
WACK this always works.
CMS_DH_KEY_INFO is needed by CryptSetKeyParam().
---
mingw-w64-headers/include/wincrypt.h | 40
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/mingw-w64-headers/include/wincrypt.h
b/mingw-w64-headers/include/wincrypt.h
index 05fd577fb..675f6d618 100644
--- a/mingw-w64-headers/include/wincrypt.h
+++ b/mingw-w64-headers/include/wincrypt.h
@@ -785,6 +785,29 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptReleaseContext (HCRYPTPROV hProv, DWORD dwFlags);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
+#define CryptSetProviderEx __MINGW_NAME_AW(CryptSetProviderEx)
+#define CryptEnumProviderTypes __MINGW_NAME_AW(CryptEnumProviderTypes)
+#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
+#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
+
+ WINIMPM WINBOOL WINAPI CryptHashSessionKey (HCRYPTHASH hHash, HCRYPTKEY
hKey, DWORD dwFlags);
+ WINIMPM WINBOOL WINAPI CryptSetProviderA (LPCSTR pszProvName, DWORD
dwProvType);
+ WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
+ WINIMPM WINBOOL WINAPI CryptSetProviderExA (LPCSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
+ WINIMPM WINBOOL WINAPI CryptSetProviderExW (LPCWSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
+ WINIMPM WINBOOL WINAPI CryptEnumProviderTypesA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szTypeName, DWORD
*pcbTypeName);
+ WINIMPM WINBOOL WINAPI CryptEnumProviderTypesW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szTypeName, DWORD
*pcbTypeName);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptEnumProvidersW (DWORD dwIndex, DWORD
*pdwReserved, DWORD dwFlags, DWORD *pdwProvType, LPWSTR szProvName, DWORD
*pcbProvName);
+ WINIMPM WINBOOL WINAPI CryptContextAddRef (HCRYPTPROV hProv, DWORD
*pdwReserved, DWORD dwFlags);
+ WINIMPM WINBOOL WINAPI CryptDuplicateKey (HCRYPTKEY hKey, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTKEY *phKey);
+ WINIMPM WINBOOL WINAPI CryptDuplicateHash (HCRYPTHASH hHash, DWORD
*pdwReserved, DWORD dwFlags, HCRYPTHASH *phHash);
+#if NTDDI_VERSION >= NTDDI_WS03
+ WINBOOL __cdecl GetEncSChannel (BYTE **pData, DWORD *dwDecSize);
+#endif
+#endif
+
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_RS4
typedef struct _CMS_DH_KEY_INFO {
DWORD dwVersion;
ALG_ID Algid;
@@ -796,9 +819,7 @@ extern "C" {
#define CryptSignHash __MINGW_NAME_AW(CryptSignHash)
#define CryptVerifySignature __MINGW_NAME_AW(CryptVerifySignature)
#define CryptSetProvider __MINGW_NAME_AW(CryptSetProvider)
-#define CryptSetProviderEx __MINGW_NAME_AW(CryptSetProviderEx)
#define CryptGetDefaultProvider __MINGW_NAME_AW(CryptGetDefaultProvider)
-#define CryptEnumProviderTypes __MINGW_NAME_AW(CryptEnumProviderTypes)
#define CryptEnumProviders __MINGW_NAME_AW(CryptEnumProviders)
WINIMPM WINBOOL WINAPI CryptGenKey (HCRYPTPROV hProv, ALG_ID Algid, DWORD
dwFlags, HCRYPTKEY *phKey);
@@ -817,28 +838,13 @@ extern "C" {
WINIMPM WINBOOL WINAPI CryptDecrypt (HCRYPTKEY hKey, HCRYPTHASH hHash,
WINBOOL Final, DWORD dwFlags, BYTE *pbData, DWORD *pdwDataLen);
WINIMPM WINBOOL WINAPI CryptCreateHash (HCRYPTPROV hProv, ALG_ID Algid,
HCRYPTKEY hKey, DWORD dwFlags, HCRYPTHASH *phHash);
WINIMPM WINBOOL WINAPI CryptHashData (HCRYPTHASH hHash, CONST BYTE *pbData,
DWORD dwDataLen, DWORD dwFlags);
- WINIMPM WINBOOL WINAPI CryptHashSessionKey (HCRYPTHASH hHash, HCRYPTKEY
hKey, DWORD dwFlags);
WINIMPM WINBOOL WINAPI CryptDestroyHash (HCRYPTHASH hHash);
WINIMPM WINBOOL WINAPI CryptSignHashA (HCRYPTHASH hHash, DWORD dwKeySpec,
LPCSTR szDescription, DWORD dwFlags, BYTE *pbSignature, DWORD *pdwSigLen);
WINIMPM WINBOOL WINAPI CryptSignHashW (HCRYPTHASH hHash, DWORD dwKeySpec,
LPCWSTR szDescription, DWORD dwFlags, BYTE *pbSignature, DWORD *pdwSigLen);
WINIMPM WINBOOL WINAPI CryptVerifySignatureA (HCRYPTHASH hHash, CONST BYTE
*pbSignature, DWORD dwSigLen, HCRYPTKEY hPubKey, LPCSTR szDescription, DWORD
dwFlags);
WINIMPM WINBOOL WINAPI CryptVerifySignatureW (HCRYPTHASH hHash, CONST BYTE
*pbSignature, DWORD dwSigLen, HCRYPTKEY hPubKey, LPCWSTR szDescription, DWORD
dwFlags);
- WINIMPM WINBOOL WINAPI CryptSetProviderA (LPCSTR pszProvName, DWORD
dwProvType);
- WINIMPM WINBOOL WINAPI CryptSetProviderW (LPCWSTR pszProvName, DWORD
dwProvType);
- WINIMPM WINBOOL WINAPI CryptSetProviderExA (LPCSTR pszProvName, DWORD
dwProvType, DWORD *pdwReserved, DWORD dwFlags);
- WINIMPM WINBOOL WINAPI
[Mingw-w64-public] [PATCH 5/5] crt: use wincrypt API from windowsapp in Windows 10
The hidden API are found in windowsapp since the RS4/19H1 SDK. They are also allowed by the WACK in api-ms-win-security-cryptoapi-l1-1-0. That DLL has been on all Windows 10 versions [1]. It's better to use the real API than using CCryptography winrt API just for these calls. Crypto.c is kept in the old winstorecompat when targetting Windows 8. Apps targetting UWP before 19H1 and using CryptGenRandom may not work if api-ms-win-security-cryptoapi-l1-1-0.dll on older Windows doesn't contain the entry. [1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-security-cryptoapi-l1-1-0dll --- .../lib-common/api-ms-win-security-cryptoapi-l1-1-0.def | 9 - .../lib32/api-ms-win-security-cryptoapi-l1-1-0.def | 9 - mingw-w64-libraries/winstorecompat/Makefile.am | 1 - 3 files changed, 8 insertions(+), 11 deletions(-) diff --git a/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def index 93bdb91e6..ebeeda2c5 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def +++ b/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def @@ -2,9 +2,8 @@ LIBRARY api-ms-win-security-cryptoapi-l1-1-0 EXPORTS -; Implemented in windowsappcompat -;CryptAcquireContextA -;CryptAcquireContextW +CryptAcquireContextA +CryptAcquireContextW CryptCreateHash CryptDecrypt CryptDeriveKey @@ -16,7 +15,7 @@ CryptEnumProvidersA CryptEnumProvidersW CryptExportKey CryptGenKey -;CryptGenRandom +CryptGenRandom CryptGetDefaultProviderA CryptGetDefaultProviderW CryptGetHashParam @@ -25,7 +24,7 @@ CryptGetProvParam CryptGetUserKey CryptHashData CryptImportKey -;CryptReleaseContext +CryptReleaseContext CryptSetHashParam CryptSetKeyParam CryptSetProviderW diff --git a/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def b/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def index e175547ec..2590c143c 100644 --- a/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def +++ b/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def @@ -2,9 +2,8 @@ LIBRARY api-ms-win-security-cryptoapi-l1-1-0 EXPORTS -; Implemented in windowsappcompat -;CryptAcquireContextA@20 -;CryptAcquireContextW@20 +CryptAcquireContextA@20 +CryptAcquireContextW@20 CryptCreateHash@20 CryptDecrypt@24 CryptDeriveKey@20 @@ -16,7 +15,7 @@ CryptEnumProvidersA@24 CryptEnumProvidersW@24 CryptExportKey@24 CryptGenKey@16 -;CryptGenRandom@12 +CryptGenRandom@12 CryptGetDefaultProviderA@20 CryptGetDefaultProviderW@20 CryptGetHashParam@20 @@ -25,7 +24,7 @@ CryptGetProvParam@20 CryptGetUserKey@12 CryptHashData@16 CryptImportKey@24 -;CryptReleaseContext@8 +CryptReleaseContext@8 CryptSetHashParam@16 CryptSetKeyParam@16 CryptSetProviderW@8 diff --git a/mingw-w64-libraries/winstorecompat/Makefile.am b/mingw-w64-libraries/winstorecompat/Makefile.am index 8b3312312..469b28b19 100644 --- a/mingw-w64-libraries/winstorecompat/Makefile.am +++ b/mingw-w64-libraries/winstorecompat/Makefile.am @@ -59,7 +59,6 @@ libwindowsappcompat_a_SOURCES = \ src/GetFileSize.c \ src/SHGetFolderPathW.c \ src/QueueTimer.c \ - src/Crypto.c \ src/GetStartupInfo.c \ src/EnumProcessModules.c \ src/RtlAddFunctionTable.c \ -- 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] headers: allow FORMAT_MESSAGE_ALLOCATE_BUFFER in UWP
FormatMessageA/W are allowed, so the flag should be allowed too.
---
mingw-w64-headers/include/winbase.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mingw-w64-headers/include/winbase.h
b/mingw-w64-headers/include/winbase.h
index b68c8ed1d..6faf6ac97 100644
--- a/mingw-w64-headers/include/winbase.h
+++ b/mingw-w64-headers/include/winbase.h
@@ -1448,6 +1448,7 @@ typedef enum FILE_FLUSH_MODE {
#define FORMAT_MESSAGE_FROM_SYSTEM 0x1000
#define FORMAT_MESSAGE_ARGUMENT_ARRAY 0x2000
#define FORMAT_MESSAGE_MAX_WIDTH_MASK 0x00ff
+#define FORMAT_MESSAGE_ALLOCATE_BUFFER 0x0100
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
@@ -1465,8 +1466,6 @@ typedef enum FILE_FLUSH_MODE {
#define FILE_READ_ONLY 8
#define FILE_DIR_DISALLOWED 9
-#define FORMAT_MESSAGE_ALLOCATE_BUFFER 0x0100
-
#define EFS_USE_RECOVERY_KEYS (0x1)
#define CREATE_FOR_IMPORT (1)
--
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] headers: restrict winscard to Desktop builds
It's not allowed in UWP.
---
mingw-w64-headers/include/winscard.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/mingw-w64-headers/include/winscard.h
b/mingw-w64-headers/include/winscard.h
index 7373d1915..1ecabb881 100644
--- a/mingw-w64-headers/include/winscard.h
+++ b/mingw-w64-headers/include/winscard.h
@@ -14,6 +14,8 @@
#include "SCardErr.h"
#endif
+#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
+
#ifdef __cplusplus
extern "C" {
#endif
@@ -436,4 +438,7 @@ LONG WINAPI SCardWriteCacheW(
#ifdef __cplusplus
}
#endif
+
+#endif
+
#endif
--
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: consistently hide winstorecompat wincrypt API's
The x86 bits version hides them, but not the common version. It should always be hidden as in 9464ea241865f218cdfee9784bb6dc1731a23647. They are now part of WindowsApp.lib but only enabled for desktop builds. Desktop users using libwindowsapp.a or libmincore.a won't be able to use the actual system calls. --- .../api-ms-win-security-cryptoapi-l1-1-0.def | 12 .../lib32/api-ms-win-security-cryptoapi-l1-1-0.def | 3 +++ 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def index ebeeda2c5..08bd2c35e 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def +++ b/mingw-w64-crt/lib-common/api-ms-win-security-cryptoapi-l1-1-0.def @@ -2,8 +2,10 @@ LIBRARY api-ms-win-security-cryptoapi-l1-1-0 EXPORTS -CryptAcquireContextA -CryptAcquireContextW +; Implemented in windowsappcompat +;CryptAcquireContextA +; Implemented in windowsappcompat +;CryptAcquireContextW CryptCreateHash CryptDecrypt CryptDeriveKey @@ -15,7 +17,8 @@ CryptEnumProvidersA CryptEnumProvidersW CryptExportKey CryptGenKey -CryptGenRandom +; Implemented in windowsappcompat +;CryptGenRandom CryptGetDefaultProviderA CryptGetDefaultProviderW CryptGetHashParam @@ -24,7 +27,8 @@ CryptGetProvParam CryptGetUserKey CryptHashData CryptImportKey -CryptReleaseContext +; Implemented in windowsappcompat +;CryptReleaseContext CryptSetHashParam CryptSetKeyParam CryptSetProviderW diff --git a/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def b/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def index e175547ec..c851a41c9 100644 --- a/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def +++ b/mingw-w64-crt/lib32/api-ms-win-security-cryptoapi-l1-1-0.def @@ -4,6 +4,7 @@ EXPORTS ; Implemented in windowsappcompat ;CryptAcquireContextA@20 +; Implemented in windowsappcompat ;CryptAcquireContextW@20 CryptCreateHash@20 CryptDecrypt@24 @@ -16,6 +17,7 @@ CryptEnumProvidersA@24 CryptEnumProvidersW@24 CryptExportKey@24 CryptGenKey@16 +; Implemented in windowsappcompat ;CryptGenRandom@12 CryptGetDefaultProviderA@20 CryptGetDefaultProviderW@20 @@ -25,6 +27,7 @@ CryptGetProvParam@20 CryptGetUserKey@12 CryptHashData@16 CryptImportKey@24 +; Implemented in windowsappcompat ;CryptReleaseContext@8 CryptSetHashParam@16 CryptSetKeyParam@16 -- 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 some missing CRT entries
According to the WACK. --- .../lib-common/api-ms-win-crt-filesystem-l1-1-0.def | 5 + mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def | 1 + mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def | 1 + 3 files changed, 7 insertions(+) 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..f5ccd2161 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 @@ -27,6 +27,9 @@ _fstat32i64 _fstat64 _fstat64i32 _fullpath +_getcwd +getcwd == _getcwd +_getdcwd _getdiskfree _getdrive _getdrives @@ -62,6 +65,8 @@ _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 fd793fe82..8a00f801c 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 @@ -25,6 +25,7 @@ _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-stdio-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def index d59859ced..e1020e2ef 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 @@ -179,6 +179,7 @@ getwc getwchar putc putchar +putenv puts putwc putwchar -- 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] crt: remove some API's not officially exported/documented
They are not mentioned in the Windows Application Certification Kit so they should not be used anyway in windowsapp/mincore. --- mingw-w64-crt/lib-common/api-ms-win-core-winrt-error-l1-1-0.def | 1 - mingw-w64-crt/lib32/api-ms-win-core-version-l1-1-1.def | 1 - mingw-w64-crt/lib32/api-ms-win-core-winrt-error-l1-1-0.def | 1 - mingw-w64-crt/lib32/api-ms-win-core-winrt-error-l1-1-1.def | 2 -- 4 files changed, 5 deletions(-) diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-winrt-error-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-core-winrt-error-l1-1-0.def index e84af147f..18a607b8a 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-core-winrt-error-l1-1-0.def +++ b/mingw-w64-crt/lib-common/api-ms-win-core-winrt-error-l1-1-0.def @@ -8,7 +8,6 @@ RoFailFastWithErrorContext RoGetErrorReportingFlags RoOriginateError RoOriginateErrorW -RoResolveRestrictedErrorInfoReference RoSetErrorReportingFlags RoTransformError RoTransformErrorW diff --git a/mingw-w64-crt/lib32/api-ms-win-core-version-l1-1-1.def b/mingw-w64-crt/lib32/api-ms-win-core-version-l1-1-1.def index 4ed3c5966..8b43bb5a4 100644 --- a/mingw-w64-crt/lib32/api-ms-win-core-version-l1-1-1.def +++ b/mingw-w64-crt/lib32/api-ms-win-core-version-l1-1-1.def @@ -5,5 +5,4 @@ EXPORTS GetFileVersionInfoExW@20 GetFileVersionInfoSizeExW@12 GetFileVersionInfoW@16 -VerFindFileW@32 VerQueryValueW@16 diff --git a/mingw-w64-crt/lib32/api-ms-win-core-winrt-error-l1-1-0.def b/mingw-w64-crt/lib32/api-ms-win-core-winrt-error-l1-1-0.def index a5a341d22..2a52414c2 100644 --- a/mingw-w64-crt/lib32/api-ms-win-core-winrt-error-l1-1-0.def +++ b/mingw-w64-crt/lib32/api-ms-win-core-winrt-error-l1-1-0.def @@ -8,7 +8,6 @@ RoFailFastWithErrorContext@4 RoGetErrorReportingFlags@4 RoOriginateError@8 RoOriginateErrorW@12 -RoResolveRestrictedErrorInfoReference@8 RoSetErrorReportingFlags@4 RoTransformError@12 RoTransformErrorW@16 diff --git a/mingw-w64-crt/lib32/api-ms-win-core-winrt-error-l1-1-1.def b/mingw-w64-crt/lib32/api-ms-win-core-winrt-error-l1-1-1.def index 3be66b015..7dc623ada 100644 --- a/mingw-w64-crt/lib32/api-ms-win-core-winrt-error-l1-1-1.def +++ b/mingw-w64-crt/lib32/api-ms-win-core-winrt-error-l1-1-1.def @@ -9,8 +9,6 @@ RoClearError@0 RoFailFastWithErrorContext@4 RoGetErrorReportingFlags@4 RoGetMatchingRestrictedErrorInfo@8 -RoInspectCapturedStackBackTrace@24 -RoInspectThreadErrorInfo@20 RoOriginateError@8 RoOriginateErrorW@12 RoOriginateLanguageException@12 -- 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 1/2] crt: add missing GetFileVersionInfoW in lib32 version-l1-1-1
It's already found in the common version. --- mingw-w64-crt/lib32/api-ms-win-core-version-l1-1-1.def | 1 + 1 file changed, 1 insertion(+) diff --git a/mingw-w64-crt/lib32/api-ms-win-core-version-l1-1-1.def b/mingw-w64-crt/lib32/api-ms-win-core-version-l1-1-1.def index 9a6bea936..4ed3c5966 100644 --- a/mingw-w64-crt/lib32/api-ms-win-core-version-l1-1-1.def +++ b/mingw-w64-crt/lib32/api-ms-win-core-version-l1-1-1.def @@ -4,5 +4,6 @@ EXPORTS GetFileVersionInfoExW@20 GetFileVersionInfoSizeExW@12 +GetFileVersionInfoW@16 VerFindFileW@32 VerQueryValueW@16 -- 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] headers: allow GetNumaHighestNodeNumber in Win10 19H1 UWP builds
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] [RFC] Make Windows 10 DLLs closer to documentation
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
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
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
[Mingw-w64-public] [PATCH 1/2] headers: enabled LoadLibraryEx flags in Win10 19H1 UWP builds
---
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
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
Re: [Mingw-w64-public] [PATCH 1/2] crt: add new found API entries api-ms-win-*.def
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 +_resetstkofl
Re: [Mingw-w64-public] [PATCH] crt: Revert changes to api-ms-win-crt-*.def
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
Re: [Mingw-w64-public] [RFC] Make Windows 10 DLLs closer to documentation
Hi, On 2023-06-06 18:16, LIU Hao wrote: Attached are some patches about APIs yesterday. This is an attempt to make these import libraries closer to MS documentation [1] [2], but: 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). The MS documentation is not 100% reliable. I started trying to update the doc with what is available in UWP 19H1 (what we target in VLC) but it turns out everything that has been added since RS5 is not mentioned in any doc. Check the last 2 commits in [5]. I sent patches upstream to see if they are willing to update the doc. This single change [6] for *all* Win10 UWP is still pending... I have little hope going forward... For GetFileVersionInfoW it is documented to be in api-ms-win-core-version-l1-1-1, but in the MarkDown version of the documentation [7] under the "api_location" list. So I suggest relying on the markdown files, rather than the published version. VerFindFileW is documented in the MarkDown file [8]. 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]. 2) `HSTRING_UserFree64` is documented as removed in 10.0.16299 [1] and should be imported from `combase.dll` [4]; and likewise others. 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 entries in api-ms-win-ro-typeresolution-l1-1-1 are present in the DLLs and WindowsApp.lib but only since the 22000 SDK. They are not in sdk-api, so they can be removed. 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. 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. It would also be possible to make a tool that checks that we don't export any undocumented API, as your current patches do. [1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis [2] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-extension-apis [3] https://learn.microsoft.com/en-us/windows/win32/api/winver/nf-winver-getfileversioninfow [4] https://learn.microsoft.com/en-us/windows/win32/api/inspectable/nf-inspectable-hstring_userfree64 [5] https://github.com/robUx4/sdk-api/commits/uwp-allowed-19041 [6] https://github.com/MicrosoftDocs/sdk-api/pull/1555 [7] https://github.com/MicrosoftDocs/sdk-api/blob/780ec86ec4992638894e184beed82690d84b0308/sdk-api-src/content/winver/nf-winver-getfileversioninfow.md?plain=1#L42 [8] https://github.com/MicrosoftDocs/sdk-api/blob/780ec86ec4992638894e184beed82690d84b0308/sdk-api-src/content/winver/nf-winver-verfindfilew.md?plain=1#L42 [9] https://github.com/MicrosoftDocs/sdk-api/blob/780ec86ec4992638894e184beed82690d84b0308/sdk-api-src/content/roerrorapi/nf-roerrorapi-roclearerror.md?plain=1#L41 [10] https://github.com/MicrosoftDocs/sdk-api/blob/780ec86ec4992638894e184beed82690d84b0308/sdk-api-src/content/inspectable/nf-inspectable-hstring_userfree64.md?plain=1#L42 [11] https://github.com/MicrosoftDocs/sdk-api/blob/780ec86ec4992638894e184beed82690d84b0308/sdk-api-src/content/wincrypt/nf-wincrypt-cryptacquirecontexta.md?plain=1#L42 -- 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 1/2] crt: add new found API entries api-ms-win-*.def
Hi, On 2023-06-05 17:34, LIU Hao wrote: 在 2023-06-05 23:17, Steve Lhomme 写道: Correct as well. The linkermember output says @16 as well. Well there are more references with the wrong size specifiers... not sure where they came from. Fixed all. Thanks for these patches. Pushed with some fixups. Please have a proofread. Thanks for merging this. I'll have some more updates coming soon. I found more things available. Also it seems windowsapp should contain a lot more than the api-ms- redirections. It seems the MS one is a placeholder for pretty much everything you can legally link with, including D3D11. ___ 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
Hi, On 2023-06-05 17:11, LIU Hao wrote: 在 2023-06-01 21:34, Steve Lhomme 写道: diff --git a/mingw-w64-crt/lib32/api-ms-win-appmodel-runtime-l1-1-0.def b/mingw-w64-crt/lib32/api-ms-win-appmodel-runtime-l1-1-0.def index c86df8743..0de46872c 100644 --- a/mingw-w64-crt/lib32/api-ms-win-appmodel-runtime-l1-1-0.def +++ b/mingw-w64-crt/lib32/api-ms-win-appmodel-runtime-l1-1-0.def @@ -2,9 +2,21 @@ LIBRARY api-ms-win-appmodel-runtime-l1-1-0 (... ...) +GetPackagePath@24 Likewise, this should be 16 I guess? Correct as well. The linkermember output says @16 as well. ___ 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 some missing sizes
Hi, On 2023-06-05 16:41, LIU Hao wrote: 在 2023-06-01 21:31, Steve Lhomme 写道: diff --git a/mingw-w64-crt/lib32/api-ms-win-core-realtime-l1-1-2.def b/mingw-w64-crt/lib32/api-ms-win-core-realtime-l1-1-2.def index d5b90e035..1831a82d9 100644 --- a/mingw-w64-crt/lib32/api-ms-win-core-realtime-l1-1-2.def +++ b/mingw-w64-crt/lib32/api-ms-win-core-realtime-l1-1-2.def @@ -4,7 +4,7 @@ EXPORTS ConvertAuxiliaryCounterToPerformanceCounter@16 ConvertPerformanceCounterToAuxiliaryCounter@16 -QueryAuxiliaryCounterFrequency@ +QueryAuxiliaryCounterFrequency@8 Its parameter is `PULONGLONG` so this should be 4 I suspect? You're right. I just check the linkermember export and it says @4. Not sure how I got the @8 in there. ___ 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 missing lib32/api-ms-win-security-systemfunctions-l1-1-0.def
On 2023-06-01 15:54, LIU Hao wrote: 在 2023-06-01 21:35, Steve Lhomme 写道: Missing from 6892eb7dca5237d81f8afd05bf511f7743b1045a which only had the common version ? --- .../lib32/api-ms-win-security-systemfunctions-l1-1-0.def | 5 + 1 file changed, 5 insertions(+) create mode 100644 mingw-w64-crt/lib32/api-ms-win-security-systemfunctions-l1-1-0.def It seems that this file is only for Windows Apps? There is no such DLL on a desktop Windows. `SystemFunction036` is exported from ADVAPI32.DLL according to documentation [1], which has it as an alias from CRYPTBASE.DLL. We already have the same file in lib-common. It's just to add it to x86 with the proper parameter size. [1] https://learn.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-rtlgenrandom -- Best regards, LIU Hao ___ 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 missing lib32/api-ms-win-security-systemfunctions-l1-1-0.def
Missing from 6892eb7dca5237d81f8afd05bf511f7743b1045a which only had the common version ? --- .../lib32/api-ms-win-security-systemfunctions-l1-1-0.def | 5 + 1 file changed, 5 insertions(+) create mode 100644 mingw-w64-crt/lib32/api-ms-win-security-systemfunctions-l1-1-0.def diff --git a/mingw-w64-crt/lib32/api-ms-win-security-systemfunctions-l1-1-0.def b/mingw-w64-crt/lib32/api-ms-win-security-systemfunctions-l1-1-0.def new file mode 100644 index 0..0e5e6e715 --- /dev/null +++ b/mingw-w64-crt/lib32/api-ms-win-security-systemfunctions-l1-1-0.def @@ -0,0 +1,5 @@ +LIBRARY api-ms-win-security-systemfunctions-l1-1-0 + +EXPORTS + +SystemFunction036@8 -- 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] headers: check which version of UWP Windows contains Virtual functions
* VirtualFree is always available in UWP
* VirtualAlloc is only available since 19H1/18362 SDK
* VirtualAllocEx is only available since 20H1/19041 SDK
They are all found in api-ms-win-core-memory-l1-1-0 which is in mincore
and windowsapp. It's one of the target DLLs [1]
[1]
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-memory-l1-1-0dll
---
mingw-w64-headers/include/memoryapi.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/memoryapi.h
b/mingw-w64-headers/include/memoryapi.h
index 152671c18..889c2a504 100644
--- a/mingw-w64-headers/include/memoryapi.h
+++ b/mingw-w64-headers/include/memoryapi.h
@@ -29,9 +29,13 @@ extern "C" {
#endif
#if (WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP) && _WIN32_WINNT >=
_WIN32_WINNT_WIN10) || WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
+WINBASEAPI WINBOOL WINAPI VirtualFree (LPVOID lpAddress, SIZE_T dwSize,
DWORD dwFreeType);
+#endif
+#if (WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP) && NTDDI_VERSION >=
NTDDI_WIN10_19H1) || WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
WINBASEAPI LPVOID WINAPI VirtualAlloc (LPVOID lpAddress, SIZE_T dwSize,
DWORD flAllocationType, DWORD flProtect);
+#endif
+#if (WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP) && NTDDI_VERSION >=
NTDDI_WIN10_VB) || WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
WINBASEAPI LPVOID WINAPI VirtualAllocEx (HANDLE hProcess, LPVOID
lpAddress, SIZE_T dwSize, DWORD flAllocationType, DWORD flProtect);
-WINBASEAPI WINBOOL WINAPI VirtualFree (LPVOID lpAddress, SIZE_T dwSize,
DWORD dwFreeType);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP)
--
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 GetVolumeNameForVolumeMountPointW in Win10 20H1 UWP builds
The documentation doesn't say it's allowed but they are allowed by the Windows Application Certification Kit and the 19041 Windows SDK. It is not allowed in older SDK. It won't compile or won't link. The target DLL api-ms-win-core-file-l1-2-0 will likely not have the function, so it should not be used when targeting older Windows 10 versions in UWP mode. We now have api-ms-win-core-file-l1-2-0 in windowsapp. --- mingw-w64-headers/include/fileapi.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mingw-w64-headers/include/fileapi.h b/mingw-w64-headers/include/fileapi.h index 280f1ab34..a37b19366 100644 --- a/mingw-w64-headers/include/fileapi.h +++ b/mingw-w64-headers/include/fileapi.h @@ -88,12 +88,14 @@ WINBASEAPI DWORD WINAPI SetFilePointer (HANDLE hFile, LONG lDistanceToMove, PLON #endif #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || (NTDDI_VERSION >= NTDDI_WIN10_VB) + WINBASEAPI WINBOOL WINAPI GetVolumeNameForVolumeMountPointW (LPCWSTR lpszVolumeMountPoint, LPWSTR lpszVolumeName, DWORD cchBufferLength); WINBASEAPI WINBOOL WINAPI GetVolumePathNameW (LPCWSTR lpszFileName, LPWSTR lpszVolumePathName, DWORD cchBufferLength); WINBASEAPI WINBOOL WINAPI ReadFileScatter (HANDLE hFile, FILE_SEGMENT_ELEMENT aSegmentArray[], DWORD nNumberOfBytesToRead, LPDWORD lpReserved, LPOVERLAPPED lpOverlapped); WINBASEAPI WINBOOL WINAPI SetFileValidData (HANDLE hFile, LONGLONG ValidDataLength); WINBASEAPI WINBOOL WINAPI WriteFileGather (HANDLE hFile, FILE_SEGMENT_ELEMENT aSegmentArray[], DWORD nNumberOfBytesToWrite, LPDWORD lpReserved, LPOVERLAPPED lpOverlapped); #ifdef UNICODE #define GetVolumePathName GetVolumePathNameW +#define GetVolumeNameForVolumeMountPoint GetVolumeNameForVolumeMountPointW #endif #endif @@ -101,7 +103,6 @@ WINBASEAPI DWORD WINAPI SetFilePointer (HANDLE hFile, LONG lDistanceToMove, PLON WINBASEAPI DWORD WINAPI GetLogicalDriveStringsW (DWORD nBufferLength, LPWSTR lpBuffer); WINBASEAPI DWORD WINAPI GetShortPathNameW (LPCWSTR lpszLongPath, LPWSTR lpszShortPath, DWORD cchBuffer); WINBASEAPI DWORD WINAPI QueryDosDeviceW (LPCWSTR lpDeviceName, LPWSTR lpTargetPath, DWORD ucchMax); - WINBASEAPI WINBOOL WINAPI GetVolumeNameForVolumeMountPointW (LPCWSTR lpszVolumeMountPoint, LPWSTR lpszVolumeName, DWORD cchBufferLength); WINBASEAPI WINBOOL WINAPI GetVolumePathNamesForVolumeNameW (LPCWSTR lpszVolumeName, LPWCH lpszVolumePathNames, DWORD cchBufferLength, PDWORD lpcchReturnLength); #ifdef UNICODE -- 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 1/2] crt: add api-ms-win-core-file-l1-2-0.def
These are needed to enable GetVolumeNameForVolumeMountPointW available in UWP. Add the target DLL to windowsapp, but not mincore (Win8) where it doesn't exist. --- mingw-w64-crt/Makefile.am | 1 + .../api-ms-win-core-file-l1-2-0.def | 81 +++ mingw-w64-crt/lib-common/windowsapp.mri | 1 + .../lib32/api-ms-win-core-file-l1-2-0.def | 81 +++ 4 files changed, 164 insertions(+) create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-file-l1-2-0.def create mode 100644 mingw-w64-crt/lib32/api-ms-win-core-file-l1-2-0.def diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index 586c499ac..874382cfc 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -2201,6 +2201,7 @@ endif %/libapi-ms-win-core-fibers-l1-1-1.a \ %/libapi-ms-win-core-fibers-l2-1-1.a \ %/libapi-ms-win-core-file-ansi-l2-1-0.a \ + %/libapi-ms-win-core-file-l1-2-0.a \ %/libapi-ms-win-core-file-l1-2-1.a \ %/libapi-ms-win-core-file-l1-2-2.a \ %/libapi-ms-win-core-file-l2-1-0.a \ diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-file-l1-2-0.def b/mingw-w64-crt/lib-common/api-ms-win-core-file-l1-2-0.def new file mode 100644 index 0..ca65d12a9 --- /dev/null +++ b/mingw-w64-crt/lib-common/api-ms-win-core-file-l1-2-0.def @@ -0,0 +1,81 @@ +LIBRARY api-ms-win-core-file-l1-2-0 + +EXPORTS + +CompareFileTime +CreateDirectoryA +CreateDirectoryW +CreateFile2 +CreateFileA +CreateFileW +DeleteFileA +DeleteFileW +DeleteVolumeMountPointW +FileTimeToLocalFileTime +FindClose +FindCloseChangeNotification +FindFirstChangeNotificationA +FindFirstChangeNotificationW +FindFirstFileA +FindFirstFileExA +FindFirstFileExW +FindFirstFileW +FindFirstVolumeW +FindNextChangeNotification +FindNextFileA +FindNextFileW +FindNextVolumeW +FindVolumeClose +FlushFileBuffers +GetDiskFreeSpaceA +GetDiskFreeSpaceExA +GetDiskFreeSpaceExW +GetDiskFreeSpaceW +GetDriveTypeA +GetDriveTypeW +GetFileAttributesA +GetFileAttributesExA +GetFileAttributesExW +GetFileAttributesW +GetFileInformationByHandle +GetFileSize +GetFileSizeEx +GetFileTime +GetFileType +GetFinalPathNameByHandleA +GetFinalPathNameByHandleW +GetFullPathNameA +GetFullPathNameW +GetLogicalDrives +GetLogicalDriveStringsW +GetLongPathNameA +GetLongPathNameW +GetShortPathNameW +GetTempFileNameW +GetTempPathW +GetVolumeInformationByHandleW +GetVolumeInformationW +GetVolumeNameForVolumeMountPointW +GetVolumePathNamesForVolumeNameW +GetVolumePathNameW +LocalFileTimeToFileTime +LockFile +LockFileEx +ReadFile +ReadFileEx +ReadFileScatter +RemoveDirectoryA +RemoveDirectoryW +SetEndOfFile +SetFileAttributesA +SetFileAttributesW +SetFileInformationByHandle +SetFilePointer +SetFilePointerEx +SetFileTime +SetFileValidData +UnlockFile +UnlockFileEx +WriteFile +WriteFileEx +WriteFileGather diff --git a/mingw-w64-crt/lib-common/windowsapp.mri b/mingw-w64-crt/lib-common/windowsapp.mri index d1445a4a7..c624d5613 100644 --- a/mingw-w64-crt/lib-common/windowsapp.mri +++ b/mingw-w64-crt/lib-common/windowsapp.mri @@ -15,6 +15,7 @@ ADDLIB libapi-ms-win-core-errorhandling-l1-1-3.a ADDLIB libapi-ms-win-core-fibers-l1-1-1.a ADDLIB libapi-ms-win-core-fibers-l2-1-1.a ADDLIB libapi-ms-win-core-file-ansi-l2-1-0.a +ADDLIB libapi-ms-win-core-file-l1-2-0.a ADDLIB libapi-ms-win-core-file-l1-2-1.a ADDLIB libapi-ms-win-core-file-l1-2-2.a ADDLIB libapi-ms-win-core-file-l2-1-0.a diff --git a/mingw-w64-crt/lib32/api-ms-win-core-file-l1-2-0.def b/mingw-w64-crt/lib32/api-ms-win-core-file-l1-2-0.def new file mode 100644 index 0..a935308cb --- /dev/null +++ b/mingw-w64-crt/lib32/api-ms-win-core-file-l1-2-0.def @@ -0,0 +1,81 @@ +LIBRARY api-ms-win-core-file-l1-2-0 + +EXPORTS + +CompareFileTime@8 +CreateDirectoryA@8 +CreateDirectoryW@8 +CreateFile2@20 +CreateFileA@28 +CreateFileW@28 +DeleteFileA@4 +DeleteFileW@4 +DeleteVolumeMountPointW@4 +FileTimeToLocalFileTime@8 +FindClose@4 +FindCloseChangeNotification@4 +FindFirstChangeNotificationA@12 +FindFirstChangeNotificationW@12 +FindFirstFileA@8 +FindFirstFileExA@24 +FindFirstFileExW@24 +FindFirstFileW@8 +FindFirstVolumeW@8 +FindNextChangeNotification@4 +FindNextFileA@8 +FindNextFileW@8 +FindNextVolumeW@12 +FindVolumeClose@4 +FlushFileBuffers@4 +GetDiskFreeSpaceA@20 +GetDiskFreeSpaceExA@16 +GetDiskFreeSpaceExW@16 +GetDiskFreeSpaceW@20 +GetDriveTypeA@4 +GetDriveTypeW@4 +GetFileAttributesA@4 +GetFileAttributesExA@12 +GetFileAttributesExW@12 +GetFileAttributesW@4 +GetFileInformationByHandle@8 +GetFileSize@8 +GetFileSizeEx@8 +GetFileTime@16 +GetFileType@4 +GetFinalPathNameByHandleA@16 +GetFinalPathNameByHandleW@16 +GetFullPathNameA@16 +GetFullPathNameW@16 +GetLogicalDrives@0 +GetLogicalDriveStringsW@8 +GetLongPathNameA@12 +GetLongPathNameW@12 +GetShortPathNameW@12 +GetTempFileNameW@16 +GetTempPathW@8 +GetVolumeInformationByHandleW@32 +GetVolumeInformationW@32
[Mingw-w64-public] [PATCH 1/2] crt: add new found API entries api-ms-win-*.def
The parameters size in lib32 were generated from values found in other .def files of lib32. --- .../api-ms-win-appmodel-runtime-l1-1-0.def| 12 +++ .../api-ms-win-appmodel-runtime-l1-1-1.def| 20 .../api-ms-win-core-errorhandling-l1-1-0.def | 1 + .../api-ms-win-core-errorhandling-l1-1-1.def | 1 + .../api-ms-win-core-errorhandling-l1-1-3.def | 1 + .../api-ms-win-core-file-ansi-l1-1-0.def | 3 + .../api-ms-win-core-file-ansi-l2-1-0.def | 2 + .../api-ms-win-core-file-l1-1-0.def | 13 +++ .../api-ms-win-core-file-l1-2-1.def | 14 +++ .../api-ms-win-core-file-l1-2-2.def | 14 +++ .../api-ms-win-core-file-l2-1-0.def | 3 + .../api-ms-win-core-file-l2-1-1.def | 3 + .../api-ms-win-core-file-l2-1-2.def | 3 + .../api-ms-win-core-heap-l1-2-0.def | 3 + .../api-ms-win-core-libraryloader-l1-2-0.def | 5 + .../api-ms-win-core-libraryloader-l1-2-1.def | 5 + ...i-ms-win-core-localization-ansi-l1-1-0.def | 3 + .../api-ms-win-core-localization-l1-2-0.def | 19 .../api-ms-win-core-localization-l1-2-1.def | 19 .../api-ms-win-core-localization-l1-2-2.def | 19 .../api-ms-win-core-memory-l1-1-0.def | 2 + .../api-ms-win-core-memory-l1-1-1.def | 2 + .../api-ms-win-core-memory-l1-1-2.def | 2 + .../api-ms-win-core-memory-l1-1-3.def | 2 + .../api-ms-win-core-memory-l1-1-5.def | 2 + .../api-ms-win-core-memory-l1-1-6.def | 2 + .../api-ms-win-core-memory-l1-1-7.def | 2 + ...-ms-win-core-processenvironment-l1-1-0.def | 1 + ...-ms-win-core-processenvironment-l1-2-0.def | 1 + .../api-ms-win-core-processthreads-l1-1-0.def | 10 ++ .../api-ms-win-core-processthreads-l1-1-1.def | 11 +++ .../api-ms-win-core-processthreads-l1-1-2.def | 11 +++ .../api-ms-win-core-processthreads-l1-1-3.def | 11 +++ .../api-ms-win-core-psapi-l1-1-0.def | 2 + .../api-ms-win-core-registry-l1-1-0.def | 94 +-- .../api-ms-win-core-registry-l2-1-0.def | 74 +++ .../api-ms-win-core-rtlsupport-l1-2-0.def | 5 + .../api-ms-win-core-synch-l1-2-0.def | 3 + .../api-ms-win-core-synch-l1-2-1.def | 3 + .../api-ms-win-core-sysinfo-l1-1-0.def| 2 + .../api-ms-win-core-sysinfo-l1-2-0.def| 2 + .../api-ms-win-core-sysinfo-l1-2-1.def| 2 + .../api-ms-win-core-sysinfo-l1-2-3.def| 2 + .../api-ms-win-core-timezone-l1-1-0.def | 2 + .../api-ms-win-core-timezone-l1-1-1.def | 2 + .../api-ms-win-core-util-l1-1-0.def | 2 + .../api-ms-win-core-version-l1-1-1.def| 2 +- .../api-ms-win-core-winrt-error-l1-1-1.def| 2 - .../api-ms-win-core-winrt-string-l1-1-0.def | 1 - .../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 ++--- .../api-ms-win-eventing-controller-l1-1-0.def | 1 - .../api-ms-win-ro-typeresolution-l1-1-1.def | 2 + .../api-ms-win-security-cryptoapi-l1-1-0.def | 9 +- .../api-ms-win-appmodel-runtime-l1-1-0.def| 12 +++ .../api-ms-win-appmodel-runtime-l1-1-1.def| 20 .../api-ms-win-core-errorhandling-l1-1-0.def | 1 + .../api-ms-win-core-errorhandling-l1-1-1.def | 1 + .../api-ms-win-core-errorhandling-l1-1-3.def | 1 + .../api-ms-win-core-file-ansi-l1-1-0.def | 3 + .../api-ms-win-core-file-ansi-l2-1-0.def | 2 + .../lib32/api-ms-win-core-file-l1-1-0.def | 13 +++ .../lib32/api-ms-win-core-file-l1-2-1.def | 14 +++ .../lib32/api-ms-win-core-file-l1-2-2.def | 14 +++ .../lib32/api-ms-win-core-file-l2-1-0.def | 3 + .../lib32/api-ms-win-core-file-l2-1-1.def | 3 + .../lib32/api-ms-win-core-file-l2-1-2.def | 3 + .../lib32/api-ms-win-core-heap-l1-2-0.def | 3 + .../api-ms-win-core-libraryloader-l1-2-0.def | 5 + .../api-ms-win-core-libraryloader-l1-2-1.def | 5 + ...i-ms-win-core-localization-ansi-l1-1-0.def | 3 + .../api-ms-win-core-localization-l1-2-0.def | 19 .../api-ms-win-core-localization-l1-2-1.def | 19 .../api-ms-win-core-localization-l1-2-2.def | 19 .../lib32/api-ms-win-core-memory-l1-1-0.def | 2 + .../lib32/api-ms-win-core-memory-l1-1-1.def | 2 + .../lib32/api-ms-win-core-memory-l1-1-2.def | 2 + .../lib32/api-ms-win-core-memory-l1-1-3.def | 2 + .../lib32/api-ms-win-core-memory-l1-1-4.def | 2 + .../lib32/api-ms-win-core-memory-l1-1-5.def | 2 + .../lib32/api-ms-win-core-memory-l1-1-6.def | 2 + .../lib32/api-ms-win-core-memory-l1-1-7.def | 2 + ...-ms-win-core-processenvironment-l1-1-0.def | 1 + ...-ms-win-core-processenvironment-l1-2-0.def | 1 +
[Mingw-w64-public] [PATCH 2/2] headers: Allow some file API in Win10 20H1 UWP builds
The documentation doesn't say it's allowed but they are allowed by the Windows Application Certification Kit and the 19041 Windows SDK. It is not allowed in older SDK. It won't compile or won't link. The target DLL api-ms-win-core-file-l1-1-0 will likely not have the function, so it should not be used when targeting older Windows 10 versions in UWP mode. The API entries have been added to api-ms-win-core-file-l1-1-0. --- mingw-w64-headers/include/fileapi.h | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/mingw-w64-headers/include/fileapi.h b/mingw-w64-headers/include/fileapi.h index 8124bd5cc..280f1ab34 100644 --- a/mingw-w64-headers/include/fileapi.h +++ b/mingw-w64-headers/include/fileapi.h @@ -81,19 +81,26 @@ WINBASEAPI DWORD WINAPI SetFilePointer (HANDLE hFile, LONG lDistanceToMove, PLON WINBASEAPI DWORD WINAPI GetFullPathNameA (LPCSTR lpFileName, DWORD nBufferLength, LPSTR lpBuffer, LPSTR *lpFilePart); WINBASEAPI DWORD WINAPI GetFullPathNameW (LPCWSTR lpFileName, DWORD nBufferLength, LPWSTR lpBuffer, LPWSTR *lpFilePart); WINBASEAPI DWORD WINAPI GetLogicalDrives (VOID); - WINBASEAPI WINBOOL WINAPI GetVolumePathNameW (LPCWSTR lpszFileName, LPWSTR lpszVolumePathName, DWORD cchBufferLength); #define FindFirstFile __MINGW_NAME_AW(FindFirstFile) #define GetDiskFreeSpace __MINGW_NAME_AW(GetDiskFreeSpace) #define GetDriveType __MINGW_NAME_AW(GetDriveType) #define GetFullPathName __MINGW_NAME_AW(GetFullPathName) #endif + +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || (NTDDI_VERSION >= NTDDI_WIN10_VB) + WINBASEAPI WINBOOL WINAPI GetVolumePathNameW (LPCWSTR lpszFileName, LPWSTR lpszVolumePathName, DWORD cchBufferLength); + WINBASEAPI WINBOOL WINAPI ReadFileScatter (HANDLE hFile, FILE_SEGMENT_ELEMENT aSegmentArray[], DWORD nNumberOfBytesToRead, LPDWORD lpReserved, LPOVERLAPPED lpOverlapped); + WINBASEAPI WINBOOL WINAPI SetFileValidData (HANDLE hFile, LONGLONG ValidDataLength); + WINBASEAPI WINBOOL WINAPI WriteFileGather (HANDLE hFile, FILE_SEGMENT_ELEMENT aSegmentArray[], DWORD nNumberOfBytesToWrite, LPDWORD lpReserved, LPOVERLAPPED lpOverlapped); +#ifdef UNICODE +#define GetVolumePathName GetVolumePathNameW +#endif +#endif + #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) WINBASEAPI DWORD WINAPI GetLogicalDriveStringsW (DWORD nBufferLength, LPWSTR lpBuffer); WINBASEAPI DWORD WINAPI GetShortPathNameW (LPCWSTR lpszLongPath, LPWSTR lpszShortPath, DWORD cchBuffer); WINBASEAPI DWORD WINAPI QueryDosDeviceW (LPCWSTR lpDeviceName, LPWSTR lpTargetPath, DWORD ucchMax); - WINBASEAPI WINBOOL WINAPI ReadFileScatter (HANDLE hFile, FILE_SEGMENT_ELEMENT aSegmentArray[], DWORD nNumberOfBytesToRead, LPDWORD lpReserved, LPOVERLAPPED lpOverlapped); - WINBASEAPI WINBOOL WINAPI SetFileValidData (HANDLE hFile, LONGLONG ValidDataLength); - WINBASEAPI WINBOOL WINAPI WriteFileGather (HANDLE hFile, FILE_SEGMENT_ELEMENT aSegmentArray[], DWORD nNumberOfBytesToWrite, LPDWORD lpReserved, LPOVERLAPPED lpOverlapped); WINBASEAPI WINBOOL WINAPI GetVolumeNameForVolumeMountPointW (LPCWSTR lpszVolumeMountPoint, LPWSTR lpszVolumeName, DWORD cchBufferLength); WINBASEAPI WINBOOL WINAPI GetVolumePathNamesForVolumeNameW (LPCWSTR lpszVolumeName, LPWCH lpszVolumePathNames, DWORD cchBufferLength, PDWORD lpcchReturnLength); @@ -105,7 +112,6 @@ WINBASEAPI DWORD WINAPI SetFilePointer (HANDLE hFile, LONG lDistanceToMove, PLON #define GetLogicalDriveStrings GetLogicalDriveStringsW #define GetShortPathName GetShortPathNameW #define GetVolumeInformation GetVolumeInformationW -#define GetVolumePathName GetVolumePathNameW #define QueryDosDevice QueryDosDeviceW #define GetVolumeNameForVolumeMountPoint GetVolumeNameForVolumeMountPointW #define GetVolumePathNamesForVolumeName GetVolumePathNamesForVolumeNameW -- 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] headers: enable FindResourceW in Win10 19H1 UWP builds
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-libraryloader-l1-2-1 in mincore and windowsapp.
[1]
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-libraryloader-l1-2-1dll
---
mingw-w64-headers/include/libloaderapi.h | 9 +++--
mingw-w64-headers/include/winbase.h | 8 ++--
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/mingw-w64-headers/include/libloaderapi.h
b/mingw-w64-headers/include/libloaderapi.h
index 26f957131..6a84aa1c9 100644
--- a/mingw-w64-headers/include/libloaderapi.h
+++ b/mingw-w64-headers/include/libloaderapi.h
@@ -80,13 +80,19 @@ extern "C" {
#define GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT (0x2)
#define GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS (0x4)
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || _WIN32_WINNT >=
0x0A00
+ WINBASEAPI HRSRC WINAPI FindResourceW(HMODULE hModule, LPCWSTR lpName,
LPCWSTR lpType);
+#ifdef UNICODE
+#define FindResource FindResourceW
+#endif
+#endif
+
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
#define ENUMRESLANGPROC __MINGW_NAME_AW(ENUMRESLANGPROC)
#define ENUMRESNAMEPROC __MINGW_NAME_AW(ENUMRESNAMEPROC)
#define ENUMRESTYPEPROC __MINGW_NAME_AW(ENUMRESTYPEPROC)
WINBASEAPI WINBOOL WINAPI EnumResourceNamesW(HMODULE hModule, LPCWSTR
lpType, ENUMRESNAMEPROCW lpEnumFunc, LONG_PTR lParam);
- WINBASEAPI HRSRC WINAPI FindResourceW(HMODULE hModule, LPCWSTR lpName,
LPCWSTR lpType);
WINBASEAPI WINBOOL WINAPI FreeResource (HGLOBAL hResData);
WINBASEAPI HGLOBAL WINAPI LoadResource (HMODULE hModule, HRSRC hResInfo);
WINBASEAPI LPVOID WINAPI LockResource (HGLOBAL hResData);
@@ -96,7 +102,6 @@ extern "C" {
#ifdef UNICODE
#define EnumResourceNames EnumResourceNamesW
-#define FindResource FindResourceW
#endif
#define EnumResourceLanguages __MINGW_NAME_AW(EnumResourceLanguages)
diff --git a/mingw-w64-headers/include/winbase.h
b/mingw-w64-headers/include/winbase.h
index 0f1ed28c0..2b10e19e8 100644
--- a/mingw-w64-headers/include/winbase.h
+++ b/mingw-w64-headers/include/winbase.h
@@ -2015,7 +2015,6 @@ typedef enum FILE_FLUSH_MODE {
WINBASEAPI VOID WINAPI FatalAppExitW (UINT uAction, LPCWSTR lpMessageText);
WINBASEAPI VOID WINAPI GetStartupInfoA (LPSTARTUPINFOA lpStartupInfo);
WINBASEAPI HRSRC WINAPI FindResourceA (HMODULE hModule, LPCSTR lpName,
LPCSTR lpType);
- WINBASEAPI HRSRC WINAPI FindResourceW (HMODULE hModule, LPCWSTR lpName,
LPCWSTR lpType);
WINBASEAPI HRSRC WINAPI FindResourceExA (HMODULE hModule, LPCSTR lpType,
LPCSTR lpName, WORD wLanguage);
WINBASEAPI WINBOOL WINAPI EnumResourceTypesA (HMODULE hModule,
ENUMRESTYPEPROCA lpEnumFunc, LONG_PTR lParam);
WINBASEAPI WINBOOL WINAPI EnumResourceTypesW (HMODULE hModule,
ENUMRESTYPEPROCW lpEnumFunc, LONG_PTR lParam);
@@ -2082,7 +2081,6 @@ typedef enum FILE_FLUSH_MODE {
#define FatalAppExit __MINGW_NAME_AW(FatalAppExit)
#define GetFirmwareEnvironmentVariable
__MINGW_NAME_AW(GetFirmwareEnvironmentVariable)
#define SetFirmwareEnvironmentVariable
__MINGW_NAME_AW(SetFirmwareEnvironmentVariable)
-#define FindResource __MINGW_NAME_AW(FindResource)
#define EnumResourceTypes __MINGW_NAME_AW(EnumResourceTypes)
#define EnumResourceNames __MINGW_NAME_AW(EnumResourceNames)
#define EnumResourceLanguages __MINGW_NAME_AW(EnumResourceLanguages)
@@ -2168,6 +2166,12 @@ typedef enum FILE_FLUSH_MODE {
#endif /* WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP) */
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_19H1
+ WINBASEAPI HRSRC WINAPI FindResourceW (HMODULE hModule, LPCWSTR lpName,
LPCWSTR lpType);
+
+#define FindResource __MINGW_NAME_AW(FindResource)
+#endif
+
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_VB
WINBASEAPI WINBOOL WINAPI CreateDirectoryExA (LPCSTR lpTemplateDirectory,
LPCSTR lpNewDirectory, LPSECURITY_ATTRIBUTES lpSecurityAttributes);
WINBASEAPI WINBOOL WINAPI CreateDirectoryExW (LPCWSTR lpTemplateDirectory,
LPCWSTR lpNewDirectory, LPSECURITY_ATTRIBUTES lpSecurityAttributes);
--
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] headers: Allow CreateDirectoryExW/A in Win10 20H1 UWP builds
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 19041 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-file-l2-1-0 in mincore and windowsapp.
[1]
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-file-l2-1-0dll
---
mingw-w64-headers/include/winbase.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/winbase.h
b/mingw-w64-headers/include/winbase.h
index 6e114e28f..0f1ed28c0 100644
--- a/mingw-w64-headers/include/winbase.h
+++ b/mingw-w64-headers/include/winbase.h
@@ -2168,12 +2168,14 @@ typedef enum FILE_FLUSH_MODE {
#endif /* WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP) */
-#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_VB
WINBASEAPI WINBOOL WINAPI CreateDirectoryExA (LPCSTR lpTemplateDirectory,
LPCSTR lpNewDirectory, LPSECURITY_ATTRIBUTES lpSecurityAttributes);
WINBASEAPI WINBOOL WINAPI CreateDirectoryExW (LPCWSTR lpTemplateDirectory,
LPCWSTR lpNewDirectory, LPSECURITY_ATTRIBUTES lpSecurityAttributes);
#define CreateDirectoryEx __MINGW_NAME_AW(CreateDirectoryEx)
+#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
#if _WIN32_WINNT >= 0x0600
WINBASEAPI WINBOOL WINAPI CreateDirectoryTransactedA (LPCSTR
lpTemplateDirectory, LPCSTR lpNewDirectory, LPSECURITY_ATTRIBUTES
lpSecurityAttributes, HANDLE hTransaction);
WINBASEAPI WINBOOL WINAPI CreateDirectoryTransactedW (LPCWSTR
lpTemplateDirectory, LPCWSTR lpNewDirectory, LPSECURITY_ATTRIBUTES
lpSecurityAttributes, HANDLE hTransaction);
--
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] headers: Allow some Heap API in Win10 20H1 UWP builds
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 19041 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-heap-l1-1-0 and api-ms-win-core-heap-l1-2-0
in mincore and windowsapp.
[1]
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-heap-l1-2-0dll
---
mingw-w64-headers/include/heapapi.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/mingw-w64-headers/include/heapapi.h
b/mingw-w64-headers/include/heapapi.h
index fe937f301..6c9ee9243 100644
--- a/mingw-w64-headers/include/heapapi.h
+++ b/mingw-w64-headers/include/heapapi.h
@@ -27,9 +27,6 @@ extern "C" {
WINBASEAPI WINBOOL WINAPI HeapValidate (HANDLE hHeap, DWORD dwFlags, LPCVOID
lpMem);
WINBOOL WINAPI HeapSummary (HANDLE hHeap, DWORD dwFlags, LPHEAP_SUMMARY
lpSummary);
- WINBASEAPI DWORD WINAPI GetProcessHeaps (DWORD NumberOfHeaps, PHANDLE
ProcessHeaps);
- WINBASEAPI WINBOOL WINAPI HeapLock (HANDLE hHeap);
- WINBASEAPI WINBOOL WINAPI HeapUnlock (HANDLE hHeap);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_19H1
@@ -37,6 +34,12 @@ extern "C" {
WINBASEAPI WINBOOL WINAPI HeapQueryInformation (HANDLE HeapHandle,
HEAP_INFORMATION_CLASS HeapInformationClass, PVOID HeapInformation, SIZE_T
HeapInformationLength, PSIZE_T ReturnLength);
#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_VB
+ WINBASEAPI DWORD WINAPI GetProcessHeaps (DWORD NumberOfHeaps, PHANDLE
ProcessHeaps);
+ WINBASEAPI WINBOOL WINAPI HeapLock (HANDLE hHeap);
+ WINBASEAPI WINBOOL WINAPI HeapUnlock (HANDLE hHeap);
+#endif
+
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP)
WINBASEAPI HANDLE WINAPI HeapCreate (DWORD flOptions, SIZE_T dwInitialSize,
SIZE_T dwMaximumSize);
WINBASEAPI SIZE_T WINAPI HeapCompact (HANDLE hHeap, DWORD dwFlags);
--
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 1/2] crt: add missing api-ms-win-core-heap-l1-1-0
It was supposed to be in mincore already. The parameters size in lib32 were generated from values found in other .def files of lib32. --- mingw-w64-crt/Makefile.am | 1 + .../api-ms-win-core-heap-l1-1-0.def | 20 +++ mingw-w64-crt/lib-common/mincore.mri | 2 +- mingw-w64-crt/lib-common/windowsapp.mri | 1 + .../lib32/api-ms-win-core-heap-l1-1-0.def | 20 +++ 5 files changed, 43 insertions(+), 1 deletion(-) create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-heap-l1-1-0.def create mode 100644 mingw-w64-crt/lib32/api-ms-win-core-heap-l1-1-0.def diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index 3a93db9ff..586c499ac 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -2206,6 +2206,7 @@ endif %/libapi-ms-win-core-file-l2-1-0.a \ %/libapi-ms-win-core-file-l2-1-1.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-2-0.a \ %/libapi-ms-win-core-io-l1-1-0.a \ diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-heap-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-core-heap-l1-1-0.def new file mode 100644 index 0..202bce3ac --- /dev/null +++ b/mingw-w64-crt/lib-common/api-ms-win-core-heap-l1-1-0.def @@ -0,0 +1,20 @@ +LIBRARY api-ms-win-core-heap-l1-1-0 + +EXPORTS + +GetProcessHeap +GetProcessHeaps +HeapAlloc +HeapCompact +HeapCreate +HeapDestroy +HeapFree +HeapLock +HeapQueryInformation +HeapReAlloc +HeapSetInformation +HeapSize +HeapSummary +HeapUnlock +HeapValidate +HeapWalk diff --git a/mingw-w64-crt/lib-common/mincore.mri b/mingw-w64-crt/lib-common/mincore.mri index 7073eeb8d..27f5f50c9 100644 --- a/mingw-w64-crt/lib-common/mincore.mri +++ b/mingw-w64-crt/lib-common/mincore.mri @@ -38,7 +38,7 @@ ADDLIB libapi-ms-win-core-file-l2-1-2.a ; FIXME libapi-ms-win-core-file-l2-1-3.a ADDLIB libapi-ms-win-core-firmware-l1-1-0.a ADDLIB libapi-ms-win-core-handle-l1-1-0.a -; FIXME libapi-ms-win-core-heap-l1-1-0.a +ADDLIB libapi-ms-win-core-heap-l1-1-0.a ADDLIB libapi-ms-win-core-heap-l1-2-0.a ADDLIB libapi-ms-win-core-interlocked-l1-1-0.a ADDLIB libapi-ms-win-core-interlocked-l1-2-0.a diff --git a/mingw-w64-crt/lib-common/windowsapp.mri b/mingw-w64-crt/lib-common/windowsapp.mri index 2496280a5..d1445a4a7 100644 --- a/mingw-w64-crt/lib-common/windowsapp.mri +++ b/mingw-w64-crt/lib-common/windowsapp.mri @@ -20,6 +20,7 @@ ADDLIB libapi-ms-win-core-file-l1-2-2.a ADDLIB libapi-ms-win-core-file-l2-1-0.a ADDLIB libapi-ms-win-core-file-l2-1-1.a ADDLIB libapi-ms-win-core-handle-l1-1-0.a +ADDLIB libapi-ms-win-core-heap-l1-1-0.a ADDLIB libapi-ms-win-core-heap-l1-2-0.a ADDLIB libapi-ms-win-core-interlocked-l1-2-0.a ADDLIB libapi-ms-win-core-io-l1-1-0.a diff --git a/mingw-w64-crt/lib32/api-ms-win-core-heap-l1-1-0.def b/mingw-w64-crt/lib32/api-ms-win-core-heap-l1-1-0.def new file mode 100644 index 0..419896a62 --- /dev/null +++ b/mingw-w64-crt/lib32/api-ms-win-core-heap-l1-1-0.def @@ -0,0 +1,20 @@ +LIBRARY api-ms-win-core-heap-l1-1-0 + +EXPORTS + +GetProcessHeap@0 +GetProcessHeaps@8 +HeapAlloc@12 +HeapCompact@8 +HeapCreate@12 +HeapDestroy@4 +HeapFree@12 +HeapLock@4 +HeapQueryInformation@20 +HeapReAlloc@16 +HeapSetInformation@16 +HeapSize@12 +HeapSummary@12 +HeapUnlock@4 +HeapValidate@12 +HeapWalk@8 -- 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 some Heap API in Win10 19H1 UWP builds
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-heap-l1-1-0 and api-ms-win-core-heap-l1-2-0
in mincore and windowsapp.
[1]
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-heap-l1-2-0dll
---
mingw-w64-headers/include/heapapi.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mingw-w64-headers/include/heapapi.h
b/mingw-w64-headers/include/heapapi.h
index b150e1056..fe937f301 100644
--- a/mingw-w64-headers/include/heapapi.h
+++ b/mingw-w64-headers/include/heapapi.h
@@ -30,6 +30,9 @@ extern "C" {
WINBASEAPI DWORD WINAPI GetProcessHeaps (DWORD NumberOfHeaps, PHANDLE
ProcessHeaps);
WINBASEAPI WINBOOL WINAPI HeapLock (HANDLE hHeap);
WINBASEAPI WINBOOL WINAPI HeapUnlock (HANDLE hHeap);
+#endif
+
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_19H1
WINBASEAPI WINBOOL WINAPI HeapWalk (HANDLE hHeap, LPPROCESS_HEAP_ENTRY
lpEntry);
WINBASEAPI WINBOOL WINAPI HeapQueryInformation (HANDLE HeapHandle,
HEAP_INFORMATION_CLASS HeapInformationClass, PVOID HeapInformation, SIZE_T
HeapInformationLength, PSIZE_T ReturnLength);
#endif
--
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] headers: allow Get/SetHandleInformation in Win10 19H1 UWP builds
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-handle-l1-1-0 in mincore and windowsapp.
[1]
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-handle-l1-1-0dll
---
mingw-w64-headers/include/handleapi.h | 2 +-
mingw-w64-headers/include/winbase.h | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/mingw-w64-headers/include/handleapi.h
b/mingw-w64-headers/include/handleapi.h
index 9f814f151..f33ceef71 100644
--- a/mingw-w64-headers/include/handleapi.h
+++ b/mingw-w64-headers/include/handleapi.h
@@ -23,7 +23,7 @@ extern "C" {
#endif
#endif
-#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_19H1
WINBASEAPI WINBOOL WINAPI GetHandleInformation (HANDLE hObject, LPDWORD
lpdwFlags);
WINBASEAPI WINBOOL WINAPI SetHandleInformation (HANDLE hObject, DWORD
dwMask, DWORD dwFlags);
#endif
diff --git a/mingw-w64-headers/include/winbase.h
b/mingw-w64-headers/include/winbase.h
index c6c34ed3b..6e114e28f 100644
--- a/mingw-w64-headers/include/winbase.h
+++ b/mingw-w64-headers/include/winbase.h
@@ -1346,6 +1346,8 @@ typedef enum FILE_FLUSH_MODE {
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || _WIN32_WINNT >=
_WIN32_WINNT_WIN10
WINBASEAPI DWORD WINAPI WaitForMultipleObjects (DWORD nCount, CONST HANDLE
*lpHandles, WINBOOL bWaitAll, DWORD dwMilliseconds);
+#define HANDLE_FLAG_INHERIT 0x1
+#define HANDLE_FLAG_PROTECT_FROM_CLOSE 0x2
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
@@ -1357,9 +1359,6 @@ typedef enum FILE_FLUSH_MODE {
DEPTotalPolicyCount
} DEP_SYSTEM_POLICY_TYPE;
-#define HANDLE_FLAG_INHERIT 0x1
-#define HANDLE_FLAG_PROTECT_FROM_CLOSE 0x2
-
#define HINSTANCE_ERROR 32
#define GET_TAPE_MEDIA_INFORMATION 0
--
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] headers: allow GetErrorMode in Win10 20H1 UWP builds
The documentation doesn't say it's allowed but they are allowed by the Windows Application Certification Kit and the 19041 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-errorhandling-l1-1-0 in mincore and windowsapp. [1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-errorhandling-l1-1-0dll --- mingw-w64-headers/include/errhandlingapi.h | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/mingw-w64-headers/include/errhandlingapi.h b/mingw-w64-headers/include/errhandlingapi.h index 806f7c968..1496b21d1 100644 --- a/mingw-w64-headers/include/errhandlingapi.h +++ b/mingw-w64-headers/include/errhandlingapi.h @@ -26,9 +26,6 @@ typedef PTOP_LEVEL_EXCEPTION_FILTER LPTOP_LEVEL_EXCEPTION_FILTER; WINBASEAPI ULONG WINAPI RemoveVectoredExceptionHandler (PVOID Handle); WINBASEAPI PVOID WINAPI AddVectoredContinueHandler (ULONG First, PVECTORED_EXCEPTION_HANDLER Handler); WINBASEAPI ULONG WINAPI RemoveVectoredContinueHandler (PVOID Handle); -#if _WIN32_WINNT >= 0x0600 - WINBASEAPI UINT WINAPI GetErrorMode (VOID); -#endif #if !defined (RC_INVOKED) && defined (WINBASE_DECLARE_RESTORE_LAST_ERROR) WINBASEAPI VOID WINAPI RestoreLastError (DWORD dwErrCode); @@ -42,6 +39,10 @@ typedef PTOP_LEVEL_EXCEPTION_FILTER LPTOP_LEVEL_EXCEPTION_FILTER; #endif +#if _WIN32_WINNT >= 0x0600 && (WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >= NTDDI_WIN10_VB) + WINBASEAPI UINT WINAPI GetErrorMode (VOID); +#endif + #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP) WINBASEAPI VOID WINAPI RaiseException (DWORD dwExceptionCode, DWORD dwExceptionFlags, DWORD nNumberOfArguments, CONST ULONG_PTR *lpArguments); WINBASEAPI UINT WINAPI SetErrorMode (UINT uMode); -- 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] headers: only enable GetFileInformationByHandle for 19H1 UWP builds
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/fileapi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/fileapi.h
b/mingw-w64-headers/include/fileapi.h
index e9e0c647f..8124bd5cc 100644
--- a/mingw-w64-headers/include/fileapi.h
+++ b/mingw-w64-headers/include/fileapi.h
@@ -32,7 +32,7 @@ WINBASEAPI DWORD WINAPI GetFileAttributesW (LPCWSTR
lpFileName);
#define GetFileAttributes __MINGW_NAME_AW(GetFileAttributes)
WINBASEAPI DWORD WINAPI SetFilePointer (HANDLE hFile, LONG lDistanceToMove,
PLONG lpDistanceToMoveHigh, DWORD dwMoveMethod);
#endif
-#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || _WIN32_WINNT >=
_WIN32_WINNT_WIN10
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_19H1 || defined(WINSTORECOMPAT)
typedef struct _BY_HANDLE_FILE_INFORMATION {
DWORD dwFileAttributes;
FILETIME ftCreationTime;
--
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 some missing sizes
The sizes come from dumping /exports on x86/windowsapp.lib. --- mingw-w64-crt/lib32/api-ms-win-core-com-l1-1-0.def | 6 +++--- mingw-w64-crt/lib32/api-ms-win-core-com-l1-1-1.def | 6 +++--- mingw-w64-crt/lib32/api-ms-win-core-comm-l1-1-1.def | 2 +- mingw-w64-crt/lib32/api-ms-win-core-comm-l1-1-2.def | 4 ++-- mingw-w64-crt/lib32/api-ms-win-core-memory-l1-1-5.def | 4 ++-- mingw-w64-crt/lib32/api-ms-win-core-realtime-l1-1-2.def | 2 +- .../lib32/api-ms-win-core-windowserrorreporting-l1-1-2.def | 2 +- mingw-w64-crt/lib32/api-ms-win-gaming-tcui-l1-1-4.def | 2 +- 8 files changed, 14 insertions(+), 14 deletions(-) diff --git a/mingw-w64-crt/lib32/api-ms-win-core-com-l1-1-0.def b/mingw-w64-crt/lib32/api-ms-win-core-com-l1-1-0.def index 0070f09ed..f694582ac 100644 --- a/mingw-w64-crt/lib32/api-ms-win-core-com-l1-1-0.def +++ b/mingw-w64-crt/lib32/api-ms-win-core-com-l1-1-0.def @@ -10,7 +10,7 @@ CoCreateGuid@4 CoCreateInstance@20 CoCreateInstanceEx@24 CoCreateInstanceFromApp@24 -CoDecrementMTAUsage +CoDecrementMTAUsage@4 CoDisconnectObject@8 CoFreeUnusedLibraries@0 CoFreeUnusedLibrariesEx@8 @@ -23,7 +23,7 @@ CoGetMalloc@8 CoGetMarshalSizeMax@24 CoGetObjectContext@8 CoGetStandardMarshal@24 -CoIncrementMTAUsage +CoIncrementMTAUsage@4 CoInitializeEx@8 CoInitializeSecurity@36 CoLockObjectExternal@12 @@ -44,7 +44,7 @@ CoTaskMemRealloc@8 CoUninitialize@0 CoUnmarshalInterface@12 CoWaitForMultipleHandles@20 -CoWaitForMultipleObjects +CoWaitForMultipleObjects@20 CreateStreamOnHGlobal@12 FreePropVariantArray@8 GetHGlobalFromStream@8 diff --git a/mingw-w64-crt/lib32/api-ms-win-core-com-l1-1-1.def b/mingw-w64-crt/lib32/api-ms-win-core-com-l1-1-1.def index e2519dce5..76cc5f4c6 100644 --- a/mingw-w64-crt/lib32/api-ms-win-core-com-l1-1-1.def +++ b/mingw-w64-crt/lib32/api-ms-win-core-com-l1-1-1.def @@ -10,7 +10,7 @@ CoCreateGuid@4 CoCreateInstance@20 CoCreateInstanceEx@24 CoCreateInstanceFromApp@24 -CoDecrementMTAUsage +CoDecrementMTAUsage@4 CoDisconnectObject@8 CoFreeUnusedLibraries@0 CoFreeUnusedLibrariesEx@8 @@ -23,7 +23,7 @@ CoGetMalloc@8 CoGetMarshalSizeMax@24 CoGetObjectContext@8 CoGetStandardMarshal@24 -CoIncrementMTAUsage +CoIncrementMTAUsage@4 CoInitializeEx@8 CoInitializeSecurity@36 CoLockObjectExternal@12 @@ -44,7 +44,7 @@ CoTaskMemRealloc@8 CoUninitialize@0 CoUnmarshalInterface@12 CoWaitForMultipleHandles@20 -CoWaitForMultipleObjects +CoWaitForMultipleObjects@20 CreateStreamOnHGlobal@12 FreePropVariantArray@8 GetHGlobalFromStream@8 diff --git a/mingw-w64-crt/lib32/api-ms-win-core-comm-l1-1-1.def b/mingw-w64-crt/lib32/api-ms-win-core-comm-l1-1-1.def index 66b7c52fd..8e117dd13 100644 --- a/mingw-w64-crt/lib32/api-ms-win-core-comm-l1-1-1.def +++ b/mingw-w64-crt/lib32/api-ms-win-core-comm-l1-1-1.def @@ -11,7 +11,7 @@ GetCommModemStatus@8 GetCommProperties@8 GetCommState@8 GetCommTimeouts@8 -OpenCommPort@ +OpenCommPort@12 PurgeComm@8 SetCommBreak@4 SetCommConfig@12 diff --git a/mingw-w64-crt/lib32/api-ms-win-core-comm-l1-1-2.def b/mingw-w64-crt/lib32/api-ms-win-core-comm-l1-1-2.def index 2ef835d9b..da35c9e0f 100644 --- a/mingw-w64-crt/lib32/api-ms-win-core-comm-l1-1-2.def +++ b/mingw-w64-crt/lib32/api-ms-win-core-comm-l1-1-2.def @@ -8,11 +8,11 @@ EscapeCommFunction@8 GetCommConfig@12 GetCommMask@8 GetCommModemStatus@8 -GetCommPorts@ +GetCommPorts@12 GetCommProperties@8 GetCommState@8 GetCommTimeouts@8 -OpenCommPort@ +OpenCommPort@12 PurgeComm@8 SetCommBreak@4 SetCommConfig@12 diff --git a/mingw-w64-crt/lib32/api-ms-win-core-memory-l1-1-5.def b/mingw-w64-crt/lib32/api-ms-win-core-memory-l1-1-5.def index 45cd2bfb2..ed591333a 100644 --- a/mingw-w64-crt/lib32/api-ms-win-core-memory-l1-1-5.def +++ b/mingw-w64-crt/lib32/api-ms-win-core-memory-l1-1-5.def @@ -18,10 +18,10 @@ OpenFileMappingW@12 ReadProcessMemory@20 ReclaimVirtualMemory@8 ResetWriteWatch@8 -SetProcessValidCallTargets +SetProcessValidCallTargets@20 SetProcessWorkingSetSizeEx@16 UnmapViewOfFile@4 -UnmapViewOfFile2@ +UnmapViewOfFile2@12 UnmapViewOfFileEx@8 VirtualAlloc@16 VirtualAllocFromApp@16 diff --git a/mingw-w64-crt/lib32/api-ms-win-core-realtime-l1-1-2.def b/mingw-w64-crt/lib32/api-ms-win-core-realtime-l1-1-2.def index d5b90e035..1831a82d9 100644 --- a/mingw-w64-crt/lib32/api-ms-win-core-realtime-l1-1-2.def +++ b/mingw-w64-crt/lib32/api-ms-win-core-realtime-l1-1-2.def @@ -4,7 +4,7 @@ EXPORTS ConvertAuxiliaryCounterToPerformanceCounter@16 ConvertPerformanceCounterToAuxiliaryCounter@16 -QueryAuxiliaryCounterFrequency@ +QueryAuxiliaryCounterFrequency@8 QueryInterruptTime@4 QueryInterruptTimePrecise@4 QueryThreadCycleTime@8 diff --git a/mingw-w64-crt/lib32/api-ms-win-core-windowserrorreporting-l1-1-2.def b/mingw-w64-crt/lib32/api-ms-win-core-windowserrorreporting-l1-1-2.def index e03b94824..70499805c 100644 --- a/mingw-w64-crt/lib32/api-ms-win-core-windowserrorreporting-l1-1-2.def +++
[Mingw-w64-public] [PATCH] headers: enable LoadStringW/A in Win10 20H1 UWP builds
The documentation doesn't say it's allowed but they are allowed by the
Windows Application Certification Kit and the 19041 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-libraryloader-l1-2-0 in mincore and windowsapp.
[1]
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-libraryloader-l1-2-0dll
---
mingw-w64-headers/include/libloaderapi.h | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/mingw-w64-headers/include/libloaderapi.h
b/mingw-w64-headers/include/libloaderapi.h
index 25bacfd29..26f957131 100644
--- a/mingw-w64-headers/include/libloaderapi.h
+++ b/mingw-w64-headers/include/libloaderapi.h
@@ -89,8 +89,6 @@ extern "C" {
WINBASEAPI HRSRC WINAPI FindResourceW(HMODULE hModule, LPCWSTR lpName,
LPCWSTR lpType);
WINBASEAPI WINBOOL WINAPI FreeResource (HGLOBAL hResData);
WINBASEAPI HGLOBAL WINAPI LoadResource (HMODULE hModule, HRSRC hResInfo);
- WINUSERAPI int WINAPI LoadStringA (HINSTANCE hInstance, UINT uID, LPSTR
lpBuffer, int cchBufferMax);
- WINUSERAPI int WINAPI LoadStringW (HINSTANCE hInstance, UINT uID, LPWSTR
lpBuffer, int cchBufferMax);
WINBASEAPI LPVOID WINAPI LockResource (HGLOBAL hResData);
WINBASEAPI DLL_DIRECTORY_COOKIE WINAPI AddDllDirectory (PCWSTR NewDirectory);
WINBASEAPI WINBOOL WINAPI RemoveDllDirectory (DLL_DIRECTORY_COOKIE Cookie);
@@ -101,8 +99,6 @@ extern "C" {
#define FindResource FindResourceW
#endif
-#define LoadString __MINGW_NAME_AW(LoadString)
-
#define EnumResourceLanguages __MINGW_NAME_AW(EnumResourceLanguages)
WINBASEAPI WINBOOL WINAPI EnumResourceLanguagesA(HMODULE hModule,LPCSTR
lpType,LPCSTR lpName,ENUMRESLANGPROCA lpEnumFunc,LONG_PTR lParam);
WINBASEAPI WINBOOL WINAPI EnumResourceLanguagesW(HMODULE hModule,LPCWSTR
lpType,LPCWSTR lpName,ENUMRESLANGPROCW lpEnumFunc,LONG_PTR lParam);
@@ -186,6 +182,13 @@ typedef const REDIRECTION_DESCRIPTOR
*PCREDIRECTION_DESCRIPTOR;
#define PGET_MODULE_HANDLE_EX __MINGW_NAME_AW(PGET_MODULE_HANDLE_EX)
#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_VB
+ WINUSERAPI int WINAPI LoadStringA (HINSTANCE hInstance, UINT uID, LPSTR
lpBuffer, int cchBufferMax);
+ WINUSERAPI int WINAPI LoadStringW (HINSTANCE hInstance, UINT uID, LPWSTR
lpBuffer, int cchBufferMax);
+
+#define LoadString __MINGW_NAME_AW(LoadString)
+#endif
+
#ifdef __cplusplus
}
#endif
--
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 v2 1/2] crt: add api-ms-core-registry-* def files
These are needed to enable the registry API calls available in UWP. Add the target DLL to windowsapp, but not mincore (Win8) where it doesn't exist. --- mingw-w64-crt/Makefile.am | 2 + .../api-ms-win-core-registry-l1-1-0.def | 47 +++ .../api-ms-win-core-registry-l2-1-0.def | 37 +++ mingw-w64-crt/lib-common/windowsapp.mri | 2 + 4 files changed, 88 insertions(+) create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-registry-l1-1-0.def create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-registry-l2-1-0.def diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index a4a1ed922..3a93db9ff 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -2237,6 +2237,8 @@ endif %/libapi-ms-win-core-profile-l1-1-0.a \ %/libapi-ms-win-core-realtime-l1-1-0.a \ %/libapi-ms-win-core-realtime-l1-1-1.a \ + %/libapi-ms-win-core-registry-l1-1-0.a \ + %/libapi-ms-win-core-registry-l2-1-0.a \ %/libapi-ms-win-core-rtlsupport-l1-2-0.a \ %/libapi-ms-win-core-string-l1-1-0.a \ %/libapi-ms-win-core-synch-ansi-l1-1-0.a \ diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-registry-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-core-registry-l1-1-0.def new file mode 100644 index 0..5cb72046b --- /dev/null +++ b/mingw-w64-crt/lib-common/api-ms-win-core-registry-l1-1-0.def @@ -0,0 +1,47 @@ +LIBRARY api-ms-win-core-registry-l1-1-0 + +EXPORTS + +RegCloseKey +RegCopyTreeW +RegCreateKeyExA +RegCreateKeyExW +RegDeleteKeyExA +RegDeleteKeyExW +RegDeleteTreeA +RegDeleteTreeW +RegDeleteValueA +RegDeleteValueW +RegDisablePredefinedCacheEx +RegEnumKeyExA +RegEnumKeyExW +RegEnumValueA +RegEnumValueW +RegFlushKey +RegGetKeySecurity +RegGetValueA +RegGetValueW +RegLoadAppKeyA +RegLoadAppKeyW +RegLoadKeyA +RegLoadKeyW +RegLoadMUIStringA +RegLoadMUIStringW +RegNotifyChangeKeyValue +RegOpenCurrentUser +RegOpenKeyExA +RegOpenKeyExW +RegOpenUserClassesRoot +RegQueryInfoKeyA +RegQueryInfoKeyW +RegQueryValueExA +RegQueryValueExW +RegRestoreKeyA +RegRestoreKeyW +RegSaveKeyExA +RegSaveKeyExW +RegSetKeySecurity +RegSetValueExA +RegSetValueExW +RegUnLoadKeyA +RegUnLoadKeyW diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-registry-l2-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-core-registry-l2-1-0.def new file mode 100644 index 0..3e05bbf74 --- /dev/null +++ b/mingw-w64-crt/lib-common/api-ms-win-core-registry-l2-1-0.def @@ -0,0 +1,37 @@ +LIBRARY api-ms-win-core-registry-l2-1-0 + +EXPORTS + +RegConnectRegistryA +RegConnectRegistryW +RegCopyTreeA +RegCreateKeyA +RegCreateKeyTransactedA +RegCreateKeyTransactedW +RegCreateKeyW +RegDeleteKeyA +RegDeleteKeyTransactedA +RegDeleteKeyTransactedW +RegDeleteKeyValueA +RegDeleteKeyValueW +RegDeleteKeyW +RegDisablePredefinedCache +RegEnumKeyA +RegEnumKeyW +RegOpenKeyA +RegOpenKeyTransactedA +RegOpenKeyTransactedW +RegOpenKeyW +RegOverridePredefKey +RegQueryMultipleValuesA +RegQueryMultipleValuesW +RegQueryValueA +RegQueryValueW +RegReplaceKeyA +RegReplaceKeyW +RegSaveKeyA +RegSaveKeyW +RegSetKeyValueA +RegSetKeyValueW +RegSetValueA +RegSetValueW diff --git a/mingw-w64-crt/lib-common/windowsapp.mri b/mingw-w64-crt/lib-common/windowsapp.mri index 8e0e3d888..2496280a5 100644 --- a/mingw-w64-crt/lib-common/windowsapp.mri +++ b/mingw-w64-crt/lib-common/windowsapp.mri @@ -51,6 +51,8 @@ ADDLIB libapi-ms-win-core-psapi-ansi-l1-1-0.a ADDLIB libapi-ms-win-core-profile-l1-1-0.a ADDLIB libapi-ms-win-core-realtime-l1-1-0.a ADDLIB libapi-ms-win-core-realtime-l1-1-1.a +ADDLIB libapi-ms-win-core-registry-l1-1-0.a +ADDLIB libapi-ms-win-core-registry-l2-1-0.a ADDLIB libapi-ms-win-core-rtlsupport-l1-2-0.a ADDLIB libapi-ms-win-core-string-l1-1-0.a ADDLIB libapi-ms-win-core-synch-ansi-l1-1-0.a -- 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 v2 2/2] headers: enable some Registry API calls in Win10 19H1 UWP builds
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 api-ms-win-core-registry-l1-1-0 will likely not have the
function, so it should not be used when targeting older Windows 10 versions
in UWP mode.
We now have api-ms-win-core-registry-l1-1-0 in windowsapp.
---
mingw-w64-headers/include/winreg.h | 92 --
1 file changed, 49 insertions(+), 43 deletions(-)
diff --git a/mingw-w64-headers/include/winreg.h
b/mingw-w64-headers/include/winreg.h
index dab9324e8..2f340fa92 100644
--- a/mingw-w64-headers/include/winreg.h
+++ b/mingw-w64-headers/include/winreg.h
@@ -131,31 +131,20 @@ extern "C" {
#define RegConnectRegistry __MINGW_NAME_AW(RegConnectRegistry)
#define RegConnectRegistryEx __MINGW_NAME_AW(RegConnectRegistryEx)
#define RegCreateKey __MINGW_NAME_AW(RegCreateKey)
-#define RegCreateKeyEx __MINGW_NAME_AW(RegCreateKeyEx)
#define RegDeleteKey __MINGW_NAME_AW(RegDeleteKey)
-#define RegDeleteKeyEx __MINGW_NAME_AW(RegDeleteKeyEx)
-#define RegDeleteValue __MINGW_NAME_AW(RegDeleteValue)
#define RegEnumKey __MINGW_NAME_AW(RegEnumKey)
-#define RegEnumKeyEx __MINGW_NAME_AW(RegEnumKeyEx)
-#define RegEnumValue __MINGW_NAME_AW(RegEnumValue)
#define RegLoadKey __MINGW_NAME_AW(RegLoadKey)
#define RegOpenKey __MINGW_NAME_AW(RegOpenKey)
-#define RegOpenKeyEx __MINGW_NAME_AW(RegOpenKeyEx)
-#define RegQueryInfoKey __MINGW_NAME_AW(RegQueryInfoKey)
#define RegQueryValue __MINGW_NAME_AW(RegQueryValue)
#define RegQueryMultipleValues __MINGW_NAME_AW(RegQueryMultipleValues)
-#define RegQueryValueEx __MINGW_NAME_AW(RegQueryValueEx)
#define RegReplaceKey __MINGW_NAME_AW(RegReplaceKey)
#define RegRestoreKey __MINGW_NAME_AW(RegRestoreKey)
#define RegSaveKey __MINGW_NAME_AW(RegSaveKey)
#define RegSetValue __MINGW_NAME_AW(RegSetValue)
-#define RegSetValueEx __MINGW_NAME_AW(RegSetValueEx)
#define RegUnLoadKey __MINGW_NAME_AW(RegUnLoadKey)
-#define RegGetValue __MINGW_NAME_AW(RegGetValue)
#define InitiateSystemShutdown __MINGW_NAME_AW(InitiateSystemShutdown)
#define AbortSystemShutdown __MINGW_NAME_AW(AbortSystemShutdown)
- WINADVAPI LONG WINAPI RegCloseKey(HKEY hKey);
WINADVAPI LONG WINAPI RegOverridePredefKey(HKEY hKey,HKEY hNewHKey);
WINADVAPI LONG WINAPI RegOpenUserClassesRoot(HANDLE hToken,DWORD
dwOptions,REGSAM samDesired,PHKEY phkResult);
WINADVAPI LONG WINAPI RegOpenCurrentUser(REGSAM samDesired,PHKEY phkResult);
@@ -167,40 +156,23 @@ extern "C" {
WINADVAPI LONG WINAPI RegConnectRegistryExW(LPCWSTR lpMachineName,HKEY
hKey,ULONG Flags,PHKEY phkResult);
WINADVAPI LONG WINAPI RegCreateKeyA(HKEY hKey,LPCSTR lpSubKey,PHKEY
phkResult);
WINADVAPI LONG WINAPI RegCreateKeyW(HKEY hKey,LPCWSTR lpSubKey,PHKEY
phkResult);
- WINADVAPI LONG WINAPI RegCreateKeyExA(HKEY hKey,LPCSTR lpSubKey,DWORD
Reserved,LPSTR lpClass,DWORD dwOptions,REGSAM samDesired,LPSECURITY_ATTRIBUTES
lpSecurityAttributes,PHKEY phkResult,LPDWORD lpdwDisposition);
- WINADVAPI LONG WINAPI RegCreateKeyExW(HKEY hKey,LPCWSTR lpSubKey,DWORD
Reserved,LPWSTR lpClass,DWORD dwOptions,REGSAM samDesired,LPSECURITY_ATTRIBUTES
lpSecurityAttributes,PHKEY phkResult,LPDWORD lpdwDisposition);
WINADVAPI LONG WINAPI RegDeleteKeyA(HKEY hKey,LPCSTR lpSubKey);
WINADVAPI LONG WINAPI RegDeleteKeyW(HKEY hKey,LPCWSTR lpSubKey);
- WINADVAPI LONG WINAPI RegDeleteKeyExA(HKEY hKey,LPCSTR lpSubKey,REGSAM
samDesired,DWORD Reserved);
- WINADVAPI LONG WINAPI RegDeleteKeyExW(HKEY hKey,LPCWSTR lpSubKey,REGSAM
samDesired,DWORD Reserved);
WINADVAPI LONG WINAPI RegDisableReflectionKey(HKEY hBase);
WINADVAPI LONG WINAPI RegEnableReflectionKey(HKEY hBase);
WINADVAPI LONG WINAPI RegQueryReflectionKey(HKEY hBase,WINBOOL
*bIsReflectionDisabled);
- WINADVAPI LONG WINAPI RegDeleteValueA(HKEY hKey,LPCSTR lpValueName);
- WINADVAPI LONG WINAPI RegDeleteValueW(HKEY hKey,LPCWSTR lpValueName);
WINADVAPI LONG WINAPI RegEnumKeyA(HKEY hKey,DWORD dwIndex,LPSTR lpName,DWORD
cchName);
WINADVAPI LONG WINAPI RegEnumKeyW(HKEY hKey,DWORD dwIndex,LPWSTR
lpName,DWORD cchName);
- WINADVAPI LONG WINAPI RegEnumKeyExA(HKEY hKey,DWORD dwIndex,LPSTR
lpName,LPDWORD lpcchName,LPDWORD lpReserved,LPSTR lpClass,LPDWORD
lpcchClass,PFILETIME lpftLastWriteTime);
- WINADVAPI LONG WINAPI RegEnumKeyExW(HKEY hKey,DWORD dwIndex,LPWSTR
lpName,LPDWORD lpcchName,LPDWORD lpReserved,LPWSTR lpClass,LPDWORD
lpcchClass,PFILETIME lpftLastWriteTime);
- WINADVAPI LONG WINAPI RegEnumValueA(HKEY hKey,DWORD dwIndex,LPSTR
lpValueName,LPDWORD lpcchValueName,LPDWORD lpReserved,LPDWORD lpType,LPBYTE
lpData,LPDWORD lpcbData);
- WINADVAPI LONG WINAPI RegEnumValueW(HKEY hKey,DWORD dwIndex,LPWSTR
lpValueName,LPDWORD lpcchValueName,LPDWORD lpReserved,LPDWORD lpType,LPBYTE
lpData,LPDWORD lpcbData);
WINADVAPI LONG WINAPI RegFlushKey(HKEY hKey);
WINADVAPI LONG WINAPI RegGetKeySecurity(HKEY
[Mingw-w64-public] [PATCH v2 3/3] winstorecompat: remove GetModuleHandle() from windowsappcompat
It's allowed now in Windows 10. Keep it forbidden in winstorecompat (Win8). --- mingw-w64-libraries/winstorecompat/Makefile.am | 1 - 1 file changed, 1 deletion(-) diff --git a/mingw-w64-libraries/winstorecompat/Makefile.am b/mingw-w64-libraries/winstorecompat/Makefile.am index 3cddebb0a..99016a051 100644 --- a/mingw-w64-libraries/winstorecompat/Makefile.am +++ b/mingw-w64-libraries/winstorecompat/Makefile.am @@ -49,7 +49,6 @@ libwinstorecompat_a_SOURCES = \ $(NULL) libwindowsappcompat_a_SOURCES = \ - src/GetModuleHandle.c \ src/LoadLibraryW.c \ src/CreateFileW.c \ src/UnhandledExceptionFilter.c \ -- 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 v2 1/3] headers: enable more module API in Win10 19H1 UWP builds
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-libraryloader-l1-2-0 in mincore and windowsapp.
[1]
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-libraryloader-l1-2-0dll
---
mingw-w64-headers/include/libloaderapi.h | 44 ++--
1 file changed, 26 insertions(+), 18 deletions(-)
diff --git a/mingw-w64-headers/include/libloaderapi.h
b/mingw-w64-headers/include/libloaderapi.h
index d4c82ef8c..c96e1a07b 100644
--- a/mingw-w64-headers/include/libloaderapi.h
+++ b/mingw-w64-headers/include/libloaderapi.h
@@ -37,11 +37,6 @@ extern "C" {
typedef FARPROC ENUMRESLANGPROCW;
#endif
-#ifndef RC_INVOKED
- typedef WINBOOL (WINAPI *PGET_MODULE_HANDLE_EXA) (DWORD dwFlags, LPCSTR
lpModuleName, HMODULE *phModule);
- typedef WINBOOL (WINAPI *PGET_MODULE_HANDLE_EXW) (DWORD dwFlags, LPCWSTR
lpModuleName, HMODULE *phModule);
-#endif
-
typedef PVOID DLL_DIRECTORY_COOKIE, *PDLL_DIRECTORY_COOKIE;
#define FIND_RESOURCE_DIRECTORY_TYPES (0x0100)
@@ -90,31 +85,21 @@ extern "C" {
WINBASEAPI WINBOOL WINAPI EnumResourceNamesW(HMODULE hModule, LPCWSTR
lpType, ENUMRESNAMEPROCW lpEnumFunc, LONG_PTR lParam);
WINBASEAPI HRSRC WINAPI FindResourceW(HMODULE hModule, LPCWSTR lpName,
LPCWSTR lpType);
- WINBASEAPI HRSRC WINAPI FindResourceExW (HMODULE hModule, LPCWSTR lpType,
LPCWSTR lpName, WORD wLanguage);
WINBASEAPI WINBOOL WINAPI FreeResource (HGLOBAL hResData);
- WINBASEAPI HMODULE WINAPI LoadLibraryExA (LPCSTR lpLibFileName, HANDLE
hFile, DWORD dwFlags);
- WINBASEAPI HMODULE WINAPI LoadLibraryExW (LPCWSTR lpLibFileName, HANDLE
hFile, DWORD dwFlags);
WINBASEAPI HGLOBAL WINAPI LoadResource (HMODULE hModule, HRSRC hResInfo);
WINUSERAPI int WINAPI LoadStringA (HINSTANCE hInstance, UINT uID, LPSTR
lpBuffer, int cchBufferMax);
WINUSERAPI int WINAPI LoadStringW (HINSTANCE hInstance, UINT uID, LPWSTR
lpBuffer, int cchBufferMax);
WINBASEAPI LPVOID WINAPI LockResource (HGLOBAL hResData);
- WINBASEAPI DWORD WINAPI SizeofResource (HMODULE hModule, HRSRC hResInfo);
WINBASEAPI DLL_DIRECTORY_COOKIE WINAPI AddDllDirectory (PCWSTR NewDirectory);
WINBASEAPI WINBOOL WINAPI RemoveDllDirectory (DLL_DIRECTORY_COOKIE Cookie);
WINBASEAPI WINBOOL WINAPI SetDefaultDllDirectories (DWORD DirectoryFlags);
- WINBASEAPI WINBOOL WINAPI GetModuleHandleExA (DWORD dwFlags, LPCSTR
lpModuleName, HMODULE *phModule);
- WINBASEAPI WINBOOL WINAPI GetModuleHandleExW (DWORD dwFlags, LPCWSTR
lpModuleName, HMODULE *phModule);
#ifdef UNICODE
#define EnumResourceNames EnumResourceNamesW
#define FindResource FindResourceW
-#define FindResourceEx FindResourceExW
#endif
-#define PGET_MODULE_HANDLE_EX __MINGW_NAME_AW(PGET_MODULE_HANDLE_EX)
#define LoadString __MINGW_NAME_AW(LoadString)
-#define GetModuleHandleEx __MINGW_NAME_AW(GetModuleHandleEx)
-#define LoadLibraryEx __MINGW_NAME_AW(LoadLibraryEx)
#define EnumResourceLanguages __MINGW_NAME_AW(EnumResourceLanguages)
WINBASEAPI WINBOOL WINAPI EnumResourceLanguagesA(HMODULE hModule,LPCSTR
lpType,LPCSTR lpName,ENUMRESLANGPROCA lpEnumFunc,LONG_PTR lParam);
@@ -136,11 +121,8 @@ extern "C" {
#endif
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) ||
defined(WINSTORECOMPAT)
-WINBASEAPI HMODULE WINAPI GetModuleHandleA (LPCSTR lpModuleName);
-WINBASEAPI HMODULE WINAPI GetModuleHandleW (LPCWSTR lpModuleName);
WINBASEAPI HMODULE WINAPI LoadLibraryA(LPCSTR lpLibFileName);
WINBASEAPI HMODULE WINAPI LoadLibraryW(LPCWSTR lpLibFileName);
-#define GetModuleHandle __MINGW_NAME_AW(GetModuleHandle)
#define LoadLibrary __MINGW_NAME_AW(LoadLibrary)
#endif
@@ -176,6 +158,32 @@ typedef const REDIRECTION_DESCRIPTOR
*PCREDIRECTION_DESCRIPTOR;
#endif
#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_19H1
+ WINBASEAPI HRSRC WINAPI FindResourceExW (HMODULE hModule, LPCWSTR lpType,
LPCWSTR lpName, WORD wLanguage);
+ WINBASEAPI HMODULE WINAPI GetModuleHandleA (LPCSTR lpModuleName);
+ WINBASEAPI HMODULE WINAPI GetModuleHandleW (LPCWSTR lpModuleName);
+ WINBASEAPI WINBOOL WINAPI GetModuleHandleExA (DWORD dwFlags, LPCSTR
lpModuleName, HMODULE *phModule);
+ WINBASEAPI WINBOOL WINAPI GetModuleHandleExW (DWORD dwFlags, LPCWSTR
lpModuleName, HMODULE *phModule);
+ WINBASEAPI HMODULE WINAPI LoadLibraryExA (LPCSTR lpLibFileName, HANDLE
hFile, DWORD dwFlags);
+ WINBASEAPI HMODULE WINAPI LoadLibraryExW (LPCWSTR lpLibFileName, HANDLE
hFile, DWORD dwFlags);
+ WINBASEAPI DWORD WINAPI SizeofResource (HMODULE hModule, HRSRC hResInfo);
+
+#ifdef UNICODE
+#define FindResourceEx FindResourceExW
+#endif
+
+#define GetModuleHandle
[Mingw-w64-public] [PATCH v2 2/3] headers: enable GET_MODULE_HANDLE_EX_xxx defines in UWP builds
It's available in the Windows 11 SDK for all builds targeting FAMILY_APP and
more.
---
mingw-w64-headers/include/libloaderapi.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mingw-w64-headers/include/libloaderapi.h
b/mingw-w64-headers/include/libloaderapi.h
index c96e1a07b..25bacfd29 100644
--- a/mingw-w64-headers/include/libloaderapi.h
+++ b/mingw-w64-headers/include/libloaderapi.h
@@ -74,11 +74,13 @@ extern "C" {
#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)
#define GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT (0x2)
#define GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS (0x4)
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
#define ENUMRESLANGPROC __MINGW_NAME_AW(ENUMRESLANGPROC)
#define ENUMRESNAMEPROC __MINGW_NAME_AW(ENUMRESNAMEPROC)
#define ENUMRESTYPEPROC __MINGW_NAME_AW(ENUMRESTYPEPROC)
--
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 v2] headers: enable CreateHardLinkW in Win10 19H1 UWP builds
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-file-l2-1-0 in mincore and windowsapp.
[1]
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-file-l2-1-0dll
---
mingw-w64-headers/include/winbase.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/winbase.h
b/mingw-w64-headers/include/winbase.h
index 82c8b7cc3..c6c34ed3b 100644
--- a/mingw-w64-headers/include/winbase.h
+++ b/mingw-w64-headers/include/winbase.h
@@ -2464,9 +2464,11 @@ typedef enum FILE_FLUSH_MODE {
WINBASEAPI WINBOOL WINAPI ReplaceFileA (LPCSTR lpReplacedFileName, LPCSTR
lpReplacementFileName, LPCSTR lpBackupFileName, DWORD dwReplaceFlags, LPVOID
lpExclude, LPVOID lpReserved);
WINBASEAPI WINBOOL WINAPI ReplaceFileW (LPCWSTR lpReplacedFileName, LPCWSTR
lpReplacementFileName, LPCWSTR lpBackupFileName, DWORD dwReplaceFlags, LPVOID
lpExclude, LPVOID lpReserved);
#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || NTDDI_VERSION >=
NTDDI_WIN10_19H1
+ WINBASEAPI WINBOOL WINAPI CreateHardLinkW (LPCWSTR lpFileName, LPCWSTR
lpExistingFileName, LPSECURITY_ATTRIBUTES lpSecurityAttributes);
+#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
WINBASEAPI WINBOOL WINAPI CreateHardLinkA (LPCSTR lpFileName, LPCSTR
lpExistingFileName, LPSECURITY_ATTRIBUTES lpSecurityAttributes);
- WINBASEAPI WINBOOL WINAPI CreateHardLinkW (LPCWSTR lpFileName, LPCWSTR
lpExistingFileName, LPSECURITY_ATTRIBUTES lpSecurityAttributes);
#define ReplaceFile __MINGW_NAME_AW(ReplaceFile)
#define CreateHardLink __MINGW_NAME_AW(CreateHardLink)
--
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 2/2] add api-ms-core-registry-* def files
Actually it should be added to mincore, which is the library to use with Windows 8. On 2023-05-31 7:45, Steve Lhomme wrote: These are needed to enable the registry API calls available in UWP. --- mingw-w64-crt/Makefile.am | 4 ++ .../api-ms-win-core-registry-l1-1-0.def | 47 +++ .../api-ms-win-core-registry-l2-1-0.def | 37 +++ mingw-w64-crt/lib-common/mincore.mri | 3 +- mingw-w64-crt/lib-common/windowsapp.mri | 2 + 5 files changed, 92 insertions(+), 1 deletion(-) create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-registry-l1-1-0.def create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-registry-l2-1-0.def diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index a4a1ed922..6087f050e 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -2104,6 +2104,8 @@ endif %/libapi-ms-win-core-realtime-l1-1-0.a \ %/libapi-ms-win-core-realtime-l1-1-1.a \ %/libapi-ms-win-core-realtime-l1-1-2.a \ + %/libapi-ms-win-core-registry-l1-1-0.a \ + %/libapi-ms-win-core-registry-l2-1-0.a \ %/libapi-ms-win-core-rtlsupport-l1-2-0.a \ %/libapi-ms-win-core-string-l1-1-0.a \ %/libapi-ms-win-core-synch-l1-1-0.a \ @@ -2237,6 +2239,8 @@ endif %/libapi-ms-win-core-profile-l1-1-0.a \ %/libapi-ms-win-core-realtime-l1-1-0.a \ %/libapi-ms-win-core-realtime-l1-1-1.a \ + %/libapi-ms-win-core-registry-l1-1-0.a \ + %/libapi-ms-win-core-registry-l2-1-0.a \ %/libapi-ms-win-core-rtlsupport-l1-2-0.a \ %/libapi-ms-win-core-string-l1-1-0.a \ %/libapi-ms-win-core-synch-ansi-l1-1-0.a \ diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-registry-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-core-registry-l1-1-0.def new file mode 100644 index 0..5cb72046b --- /dev/null +++ b/mingw-w64-crt/lib-common/api-ms-win-core-registry-l1-1-0.def @@ -0,0 +1,47 @@ +LIBRARY api-ms-win-core-registry-l1-1-0 + +EXPORTS + +RegCloseKey +RegCopyTreeW +RegCreateKeyExA +RegCreateKeyExW +RegDeleteKeyExA +RegDeleteKeyExW +RegDeleteTreeA +RegDeleteTreeW +RegDeleteValueA +RegDeleteValueW +RegDisablePredefinedCacheEx +RegEnumKeyExA +RegEnumKeyExW +RegEnumValueA +RegEnumValueW +RegFlushKey +RegGetKeySecurity +RegGetValueA +RegGetValueW +RegLoadAppKeyA +RegLoadAppKeyW +RegLoadKeyA +RegLoadKeyW +RegLoadMUIStringA +RegLoadMUIStringW +RegNotifyChangeKeyValue +RegOpenCurrentUser +RegOpenKeyExA +RegOpenKeyExW +RegOpenUserClassesRoot +RegQueryInfoKeyA +RegQueryInfoKeyW +RegQueryValueExA +RegQueryValueExW +RegRestoreKeyA +RegRestoreKeyW +RegSaveKeyExA +RegSaveKeyExW +RegSetKeySecurity +RegSetValueExA +RegSetValueExW +RegUnLoadKeyA +RegUnLoadKeyW diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-registry-l2-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-core-registry-l2-1-0.def new file mode 100644 index 0..3e05bbf74 --- /dev/null +++ b/mingw-w64-crt/lib-common/api-ms-win-core-registry-l2-1-0.def @@ -0,0 +1,37 @@ +LIBRARY api-ms-win-core-registry-l2-1-0 + +EXPORTS + +RegConnectRegistryA +RegConnectRegistryW +RegCopyTreeA +RegCreateKeyA +RegCreateKeyTransactedA +RegCreateKeyTransactedW +RegCreateKeyW +RegDeleteKeyA +RegDeleteKeyTransactedA +RegDeleteKeyTransactedW +RegDeleteKeyValueA +RegDeleteKeyValueW +RegDeleteKeyW +RegDisablePredefinedCache +RegEnumKeyA +RegEnumKeyW +RegOpenKeyA +RegOpenKeyTransactedA +RegOpenKeyTransactedW +RegOpenKeyW +RegOverridePredefKey +RegQueryMultipleValuesA +RegQueryMultipleValuesW +RegQueryValueA +RegQueryValueW +RegReplaceKeyA +RegReplaceKeyW +RegSaveKeyA +RegSaveKeyW +RegSetKeyValueA +RegSetKeyValueW +RegSetValueA +RegSetValueW diff --git a/mingw-w64-crt/lib-common/mincore.mri b/mingw-w64-crt/lib-common/mincore.mri index 7073eeb8d..03f4b4c37 100644 --- a/mingw-w64-crt/lib-common/mincore.mri +++ b/mingw-w64-crt/lib-common/mincore.mri @@ -85,7 +85,8 @@ ADDLIB libapi-ms-win-core-psapi-ansi-l1-1-0.a ADDLIB libapi-ms-win-core-realtime-l1-1-0.a ADDLIB libapi-ms-win-core-realtime-l1-1-1.a ADDLIB libapi-ms-win-core-realtime-l1-1-2.a -; FIXME libapi-ms-win-core-registry-l1-1-0.a +ADDLIB libapi-ms-win-core-registry-l1-1-0.a +ADDLIB libapi-ms-win-core-registry-l2-1-0.a ; FIXME libapi-ms-win-core-registry-l1-1-1.a ; FIXME libapi-ms-win-core-registry-l1-1-2.a ; FIXME libapi-ms-win-core-rtlsupport-l1-1-0.a diff --git a/mingw-w64-crt/lib-common/windowsapp.mri b/mingw-w64-crt/lib-common/windowsapp.mri index 8e0e3d888..2496280a5 100644 --- a/mingw-w64-crt/lib-common/windowsapp.mri +++ b/mingw-w64-crt/lib-common/windowsapp.mri @@ -51,6 +51,8 @@ ADDLIB libapi-ms-win-core-psapi-ansi-l1-1-0.a ADDLIB libapi-ms-win-core-profile-l1-1-0.a ADDLIB libapi-ms-win-core-realtime-l1-1-0.a ADDLIB libapi-ms-win-core-realtime-l1-1-1.a +ADDLIB libapi-ms-win
[Mingw-w64-public] [PATCH 2/2] add api-ms-core-registry-* def files
These are needed to enable the registry API calls available in UWP. --- mingw-w64-crt/Makefile.am | 4 ++ .../api-ms-win-core-registry-l1-1-0.def | 47 +++ .../api-ms-win-core-registry-l2-1-0.def | 37 +++ mingw-w64-crt/lib-common/mincore.mri | 3 +- mingw-w64-crt/lib-common/windowsapp.mri | 2 + 5 files changed, 92 insertions(+), 1 deletion(-) create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-registry-l1-1-0.def create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-registry-l2-1-0.def diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index a4a1ed922..6087f050e 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -2104,6 +2104,8 @@ endif %/libapi-ms-win-core-realtime-l1-1-0.a \ %/libapi-ms-win-core-realtime-l1-1-1.a \ %/libapi-ms-win-core-realtime-l1-1-2.a \ + %/libapi-ms-win-core-registry-l1-1-0.a \ + %/libapi-ms-win-core-registry-l2-1-0.a \ %/libapi-ms-win-core-rtlsupport-l1-2-0.a \ %/libapi-ms-win-core-string-l1-1-0.a \ %/libapi-ms-win-core-synch-l1-1-0.a \ @@ -2237,6 +2239,8 @@ endif %/libapi-ms-win-core-profile-l1-1-0.a \ %/libapi-ms-win-core-realtime-l1-1-0.a \ %/libapi-ms-win-core-realtime-l1-1-1.a \ + %/libapi-ms-win-core-registry-l1-1-0.a \ + %/libapi-ms-win-core-registry-l2-1-0.a \ %/libapi-ms-win-core-rtlsupport-l1-2-0.a \ %/libapi-ms-win-core-string-l1-1-0.a \ %/libapi-ms-win-core-synch-ansi-l1-1-0.a \ diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-registry-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-core-registry-l1-1-0.def new file mode 100644 index 0..5cb72046b --- /dev/null +++ b/mingw-w64-crt/lib-common/api-ms-win-core-registry-l1-1-0.def @@ -0,0 +1,47 @@ +LIBRARY api-ms-win-core-registry-l1-1-0 + +EXPORTS + +RegCloseKey +RegCopyTreeW +RegCreateKeyExA +RegCreateKeyExW +RegDeleteKeyExA +RegDeleteKeyExW +RegDeleteTreeA +RegDeleteTreeW +RegDeleteValueA +RegDeleteValueW +RegDisablePredefinedCacheEx +RegEnumKeyExA +RegEnumKeyExW +RegEnumValueA +RegEnumValueW +RegFlushKey +RegGetKeySecurity +RegGetValueA +RegGetValueW +RegLoadAppKeyA +RegLoadAppKeyW +RegLoadKeyA +RegLoadKeyW +RegLoadMUIStringA +RegLoadMUIStringW +RegNotifyChangeKeyValue +RegOpenCurrentUser +RegOpenKeyExA +RegOpenKeyExW +RegOpenUserClassesRoot +RegQueryInfoKeyA +RegQueryInfoKeyW +RegQueryValueExA +RegQueryValueExW +RegRestoreKeyA +RegRestoreKeyW +RegSaveKeyExA +RegSaveKeyExW +RegSetKeySecurity +RegSetValueExA +RegSetValueExW +RegUnLoadKeyA +RegUnLoadKeyW diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-registry-l2-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-core-registry-l2-1-0.def new file mode 100644 index 0..3e05bbf74 --- /dev/null +++ b/mingw-w64-crt/lib-common/api-ms-win-core-registry-l2-1-0.def @@ -0,0 +1,37 @@ +LIBRARY api-ms-win-core-registry-l2-1-0 + +EXPORTS + +RegConnectRegistryA +RegConnectRegistryW +RegCopyTreeA +RegCreateKeyA +RegCreateKeyTransactedA +RegCreateKeyTransactedW +RegCreateKeyW +RegDeleteKeyA +RegDeleteKeyTransactedA +RegDeleteKeyTransactedW +RegDeleteKeyValueA +RegDeleteKeyValueW +RegDeleteKeyW +RegDisablePredefinedCache +RegEnumKeyA +RegEnumKeyW +RegOpenKeyA +RegOpenKeyTransactedA +RegOpenKeyTransactedW +RegOpenKeyW +RegOverridePredefKey +RegQueryMultipleValuesA +RegQueryMultipleValuesW +RegQueryValueA +RegQueryValueW +RegReplaceKeyA +RegReplaceKeyW +RegSaveKeyA +RegSaveKeyW +RegSetKeyValueA +RegSetKeyValueW +RegSetValueA +RegSetValueW diff --git a/mingw-w64-crt/lib-common/mincore.mri b/mingw-w64-crt/lib-common/mincore.mri index 7073eeb8d..03f4b4c37 100644 --- a/mingw-w64-crt/lib-common/mincore.mri +++ b/mingw-w64-crt/lib-common/mincore.mri @@ -85,7 +85,8 @@ ADDLIB libapi-ms-win-core-psapi-ansi-l1-1-0.a ADDLIB libapi-ms-win-core-realtime-l1-1-0.a ADDLIB libapi-ms-win-core-realtime-l1-1-1.a ADDLIB libapi-ms-win-core-realtime-l1-1-2.a -; FIXME libapi-ms-win-core-registry-l1-1-0.a +ADDLIB libapi-ms-win-core-registry-l1-1-0.a +ADDLIB libapi-ms-win-core-registry-l2-1-0.a ; FIXME libapi-ms-win-core-registry-l1-1-1.a ; FIXME libapi-ms-win-core-registry-l1-1-2.a ; FIXME libapi-ms-win-core-rtlsupport-l1-1-0.a diff --git a/mingw-w64-crt/lib-common/windowsapp.mri b/mingw-w64-crt/lib-common/windowsapp.mri index 8e0e3d888..2496280a5 100644 --- a/mingw-w64-crt/lib-common/windowsapp.mri +++ b/mingw-w64-crt/lib-common/windowsapp.mri @@ -51,6 +51,8 @@ ADDLIB libapi-ms-win-core-psapi-ansi-l1-1-0.a ADDLIB libapi-ms-win-core-profile-l1-1-0.a ADDLIB libapi-ms-win-core-realtime-l1-1-0.a ADDLIB libapi-ms-win-core-realtime-l1-1-1.a +ADDLIB libapi-ms-win-core-registry-l1-1-0.a +ADDLIB libapi-ms-win-core-registry-l2-1-0.a ADDLIB libapi-ms-win-core-rtlsupport-l1-2-0.a ADDLIB
[Mingw-w64-public] [PATCH 1/2] headers: enable some Registry API calls in UWP 8.1+ builds
The documentation doesn't say it's allowed, but the WIndows SDK allow it since
22000 and
the Windows App Certification as well. It is not restricted to Win11 in both
cases. It's even allowed for 8.1 in api-ms-win-core-registry-l1-1-0.dll.
---
mingw-w64-headers/include/winreg.h | 92 --
1 file changed, 49 insertions(+), 43 deletions(-)
diff --git a/mingw-w64-headers/include/winreg.h
b/mingw-w64-headers/include/winreg.h
index dab9324e8..6c5743a28 100644
--- a/mingw-w64-headers/include/winreg.h
+++ b/mingw-w64-headers/include/winreg.h
@@ -131,31 +131,20 @@ extern "C" {
#define RegConnectRegistry __MINGW_NAME_AW(RegConnectRegistry)
#define RegConnectRegistryEx __MINGW_NAME_AW(RegConnectRegistryEx)
#define RegCreateKey __MINGW_NAME_AW(RegCreateKey)
-#define RegCreateKeyEx __MINGW_NAME_AW(RegCreateKeyEx)
#define RegDeleteKey __MINGW_NAME_AW(RegDeleteKey)
-#define RegDeleteKeyEx __MINGW_NAME_AW(RegDeleteKeyEx)
-#define RegDeleteValue __MINGW_NAME_AW(RegDeleteValue)
#define RegEnumKey __MINGW_NAME_AW(RegEnumKey)
-#define RegEnumKeyEx __MINGW_NAME_AW(RegEnumKeyEx)
-#define RegEnumValue __MINGW_NAME_AW(RegEnumValue)
#define RegLoadKey __MINGW_NAME_AW(RegLoadKey)
#define RegOpenKey __MINGW_NAME_AW(RegOpenKey)
-#define RegOpenKeyEx __MINGW_NAME_AW(RegOpenKeyEx)
-#define RegQueryInfoKey __MINGW_NAME_AW(RegQueryInfoKey)
#define RegQueryValue __MINGW_NAME_AW(RegQueryValue)
#define RegQueryMultipleValues __MINGW_NAME_AW(RegQueryMultipleValues)
-#define RegQueryValueEx __MINGW_NAME_AW(RegQueryValueEx)
#define RegReplaceKey __MINGW_NAME_AW(RegReplaceKey)
#define RegRestoreKey __MINGW_NAME_AW(RegRestoreKey)
#define RegSaveKey __MINGW_NAME_AW(RegSaveKey)
#define RegSetValue __MINGW_NAME_AW(RegSetValue)
-#define RegSetValueEx __MINGW_NAME_AW(RegSetValueEx)
#define RegUnLoadKey __MINGW_NAME_AW(RegUnLoadKey)
-#define RegGetValue __MINGW_NAME_AW(RegGetValue)
#define InitiateSystemShutdown __MINGW_NAME_AW(InitiateSystemShutdown)
#define AbortSystemShutdown __MINGW_NAME_AW(AbortSystemShutdown)
- WINADVAPI LONG WINAPI RegCloseKey(HKEY hKey);
WINADVAPI LONG WINAPI RegOverridePredefKey(HKEY hKey,HKEY hNewHKey);
WINADVAPI LONG WINAPI RegOpenUserClassesRoot(HANDLE hToken,DWORD
dwOptions,REGSAM samDesired,PHKEY phkResult);
WINADVAPI LONG WINAPI RegOpenCurrentUser(REGSAM samDesired,PHKEY phkResult);
@@ -167,40 +156,23 @@ extern "C" {
WINADVAPI LONG WINAPI RegConnectRegistryExW(LPCWSTR lpMachineName,HKEY
hKey,ULONG Flags,PHKEY phkResult);
WINADVAPI LONG WINAPI RegCreateKeyA(HKEY hKey,LPCSTR lpSubKey,PHKEY
phkResult);
WINADVAPI LONG WINAPI RegCreateKeyW(HKEY hKey,LPCWSTR lpSubKey,PHKEY
phkResult);
- WINADVAPI LONG WINAPI RegCreateKeyExA(HKEY hKey,LPCSTR lpSubKey,DWORD
Reserved,LPSTR lpClass,DWORD dwOptions,REGSAM samDesired,LPSECURITY_ATTRIBUTES
lpSecurityAttributes,PHKEY phkResult,LPDWORD lpdwDisposition);
- WINADVAPI LONG WINAPI RegCreateKeyExW(HKEY hKey,LPCWSTR lpSubKey,DWORD
Reserved,LPWSTR lpClass,DWORD dwOptions,REGSAM samDesired,LPSECURITY_ATTRIBUTES
lpSecurityAttributes,PHKEY phkResult,LPDWORD lpdwDisposition);
WINADVAPI LONG WINAPI RegDeleteKeyA(HKEY hKey,LPCSTR lpSubKey);
WINADVAPI LONG WINAPI RegDeleteKeyW(HKEY hKey,LPCWSTR lpSubKey);
- WINADVAPI LONG WINAPI RegDeleteKeyExA(HKEY hKey,LPCSTR lpSubKey,REGSAM
samDesired,DWORD Reserved);
- WINADVAPI LONG WINAPI RegDeleteKeyExW(HKEY hKey,LPCWSTR lpSubKey,REGSAM
samDesired,DWORD Reserved);
WINADVAPI LONG WINAPI RegDisableReflectionKey(HKEY hBase);
WINADVAPI LONG WINAPI RegEnableReflectionKey(HKEY hBase);
WINADVAPI LONG WINAPI RegQueryReflectionKey(HKEY hBase,WINBOOL
*bIsReflectionDisabled);
- WINADVAPI LONG WINAPI RegDeleteValueA(HKEY hKey,LPCSTR lpValueName);
- WINADVAPI LONG WINAPI RegDeleteValueW(HKEY hKey,LPCWSTR lpValueName);
WINADVAPI LONG WINAPI RegEnumKeyA(HKEY hKey,DWORD dwIndex,LPSTR lpName,DWORD
cchName);
WINADVAPI LONG WINAPI RegEnumKeyW(HKEY hKey,DWORD dwIndex,LPWSTR
lpName,DWORD cchName);
- WINADVAPI LONG WINAPI RegEnumKeyExA(HKEY hKey,DWORD dwIndex,LPSTR
lpName,LPDWORD lpcchName,LPDWORD lpReserved,LPSTR lpClass,LPDWORD
lpcchClass,PFILETIME lpftLastWriteTime);
- WINADVAPI LONG WINAPI RegEnumKeyExW(HKEY hKey,DWORD dwIndex,LPWSTR
lpName,LPDWORD lpcchName,LPDWORD lpReserved,LPWSTR lpClass,LPDWORD
lpcchClass,PFILETIME lpftLastWriteTime);
- WINADVAPI LONG WINAPI RegEnumValueA(HKEY hKey,DWORD dwIndex,LPSTR
lpValueName,LPDWORD lpcchValueName,LPDWORD lpReserved,LPDWORD lpType,LPBYTE
lpData,LPDWORD lpcbData);
- WINADVAPI LONG WINAPI RegEnumValueW(HKEY hKey,DWORD dwIndex,LPWSTR
lpValueName,LPDWORD lpcchValueName,LPDWORD lpReserved,LPDWORD lpType,LPBYTE
lpData,LPDWORD lpcbData);
WINADVAPI LONG WINAPI RegFlushKey(HKEY hKey);
WINADVAPI LONG WINAPI RegGetKeySecurity(HKEY hKey,SECURITY_INFORMATION
SecurityInformation,PSECURITY_DESCRIPTOR pSecurityDescriptor,LPDWORD
lpcbSecurityDescriptor);
WINADVAPI LONG WINAPI RegLoadKeyA(HKEY hKey,LPCSTR lpSubKey,LPCSTR
[Mingw-w64-public] [PATCH 2/3] headers: enable GET_MODULE_HANDLE_EX_xxx defines in UWP builds
It's available in the Windows 11 SDK for all builds targeting FAMILY_APP and
more.
---
mingw-w64-headers/include/libloaderapi.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mingw-w64-headers/include/libloaderapi.h
b/mingw-w64-headers/include/libloaderapi.h
index 288e78d9f..b74d8775a 100644
--- a/mingw-w64-headers/include/libloaderapi.h
+++ b/mingw-w64-headers/include/libloaderapi.h
@@ -74,11 +74,13 @@ extern "C" {
#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)
#define GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT (0x2)
#define GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS (0x4)
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
#define ENUMRESLANGPROC __MINGW_NAME_AW(ENUMRESLANGPROC)
#define ENUMRESNAMEPROC __MINGW_NAME_AW(ENUMRESNAMEPROC)
#define ENUMRESTYPEPROC __MINGW_NAME_AW(ENUMRESTYPEPROC)
--
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 3/3] winstorecompat: remove GetModuleHandle() from windowsappcompat
It's allowed now in Windows 10. Keep it forbidden in winstorecompat (Win8). --- mingw-w64-libraries/winstorecompat/Makefile.am | 1 - 1 file changed, 1 deletion(-) diff --git a/mingw-w64-libraries/winstorecompat/Makefile.am b/mingw-w64-libraries/winstorecompat/Makefile.am index a668efb25..c3c4f65ee 100644 --- a/mingw-w64-libraries/winstorecompat/Makefile.am +++ b/mingw-w64-libraries/winstorecompat/Makefile.am @@ -50,7 +50,6 @@ libwinstorecompat_a_SOURCES = \ libwindowsappcompat_a_SOURCES = \ src/beginthread.c \ - src/GetModuleHandle.c \ src/LoadLibraryW.c \ src/CreateFileW.c \ src/UnhandledExceptionFilter.c \ -- 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 1/3] headers: enable more module API in Win10 UWP builds
The documentation doesn't say they're allowed, but the WIndows SDK allow it
since 22000 and the Windows App Certification as well.
It is not restricted to Win11 in both cases but applies when targeting Win10
as well.
---
mingw-w64-headers/include/libloaderapi.h | 51 ++--
1 file changed, 29 insertions(+), 22 deletions(-)
diff --git a/mingw-w64-headers/include/libloaderapi.h
b/mingw-w64-headers/include/libloaderapi.h
index d4c82ef8c..288e78d9f 100644
--- a/mingw-w64-headers/include/libloaderapi.h
+++ b/mingw-w64-headers/include/libloaderapi.h
@@ -37,11 +37,6 @@ extern "C" {
typedef FARPROC ENUMRESLANGPROCW;
#endif
-#ifndef RC_INVOKED
- typedef WINBOOL (WINAPI *PGET_MODULE_HANDLE_EXA) (DWORD dwFlags, LPCSTR
lpModuleName, HMODULE *phModule);
- typedef WINBOOL (WINAPI *PGET_MODULE_HANDLE_EXW) (DWORD dwFlags, LPCWSTR
lpModuleName, HMODULE *phModule);
-#endif
-
typedef PVOID DLL_DIRECTORY_COOKIE, *PDLL_DIRECTORY_COOKIE;
#define FIND_RESOURCE_DIRECTORY_TYPES (0x0100)
@@ -90,32 +85,18 @@ extern "C" {
WINBASEAPI WINBOOL WINAPI EnumResourceNamesW(HMODULE hModule, LPCWSTR
lpType, ENUMRESNAMEPROCW lpEnumFunc, LONG_PTR lParam);
WINBASEAPI HRSRC WINAPI FindResourceW(HMODULE hModule, LPCWSTR lpName,
LPCWSTR lpType);
- WINBASEAPI HRSRC WINAPI FindResourceExW (HMODULE hModule, LPCWSTR lpType,
LPCWSTR lpName, WORD wLanguage);
WINBASEAPI WINBOOL WINAPI FreeResource (HGLOBAL hResData);
- WINBASEAPI HMODULE WINAPI LoadLibraryExA (LPCSTR lpLibFileName, HANDLE
hFile, DWORD dwFlags);
- WINBASEAPI HMODULE WINAPI LoadLibraryExW (LPCWSTR lpLibFileName, HANDLE
hFile, DWORD dwFlags);
WINBASEAPI HGLOBAL WINAPI LoadResource (HMODULE hModule, HRSRC hResInfo);
- WINUSERAPI int WINAPI LoadStringA (HINSTANCE hInstance, UINT uID, LPSTR
lpBuffer, int cchBufferMax);
- WINUSERAPI int WINAPI LoadStringW (HINSTANCE hInstance, UINT uID, LPWSTR
lpBuffer, int cchBufferMax);
WINBASEAPI LPVOID WINAPI LockResource (HGLOBAL hResData);
- WINBASEAPI DWORD WINAPI SizeofResource (HMODULE hModule, HRSRC hResInfo);
WINBASEAPI DLL_DIRECTORY_COOKIE WINAPI AddDllDirectory (PCWSTR NewDirectory);
WINBASEAPI WINBOOL WINAPI RemoveDllDirectory (DLL_DIRECTORY_COOKIE Cookie);
WINBASEAPI WINBOOL WINAPI SetDefaultDllDirectories (DWORD DirectoryFlags);
- WINBASEAPI WINBOOL WINAPI GetModuleHandleExA (DWORD dwFlags, LPCSTR
lpModuleName, HMODULE *phModule);
- WINBASEAPI WINBOOL WINAPI GetModuleHandleExW (DWORD dwFlags, LPCWSTR
lpModuleName, HMODULE *phModule);
#ifdef UNICODE
#define EnumResourceNames EnumResourceNamesW
#define FindResource FindResourceW
-#define FindResourceEx FindResourceExW
#endif
-#define PGET_MODULE_HANDLE_EX __MINGW_NAME_AW(PGET_MODULE_HANDLE_EX)
-#define LoadString __MINGW_NAME_AW(LoadString)
-#define GetModuleHandleEx __MINGW_NAME_AW(GetModuleHandleEx)
-#define LoadLibraryEx __MINGW_NAME_AW(LoadLibraryEx)
-
#define EnumResourceLanguages __MINGW_NAME_AW(EnumResourceLanguages)
WINBASEAPI WINBOOL WINAPI EnumResourceLanguagesA(HMODULE hModule,LPCSTR
lpType,LPCSTR lpName,ENUMRESLANGPROCA lpEnumFunc,LONG_PTR lParam);
WINBASEAPI WINBOOL WINAPI EnumResourceLanguagesW(HMODULE hModule,LPCWSTR
lpType,LPCWSTR lpName,ENUMRESLANGPROCW lpEnumFunc,LONG_PTR lParam);
@@ -136,11 +117,8 @@ extern "C" {
#endif
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) ||
defined(WINSTORECOMPAT)
-WINBASEAPI HMODULE WINAPI GetModuleHandleA (LPCSTR lpModuleName);
-WINBASEAPI HMODULE WINAPI GetModuleHandleW (LPCWSTR lpModuleName);
WINBASEAPI HMODULE WINAPI LoadLibraryA(LPCSTR lpLibFileName);
WINBASEAPI HMODULE WINAPI LoadLibraryW(LPCWSTR lpLibFileName);
-#define GetModuleHandle __MINGW_NAME_AW(GetModuleHandle)
#define LoadLibrary __MINGW_NAME_AW(LoadLibrary)
#endif
@@ -176,6 +154,35 @@ typedef const REDIRECTION_DESCRIPTOR
*PCREDIRECTION_DESCRIPTOR;
#endif
#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || _WIN32_WINNT >=
0x0A00
+ WINBASEAPI HRSRC WINAPI FindResourceExW (HMODULE hModule, LPCWSTR lpType,
LPCWSTR lpName, WORD wLanguage);
+ WINBASEAPI HMODULE WINAPI GetModuleHandleA (LPCSTR lpModuleName);
+ WINBASEAPI HMODULE WINAPI GetModuleHandleW (LPCWSTR lpModuleName);
+ WINBASEAPI WINBOOL WINAPI GetModuleHandleExA (DWORD dwFlags, LPCSTR
lpModuleName, HMODULE *phModule);
+ WINBASEAPI WINBOOL WINAPI GetModuleHandleExW (DWORD dwFlags, LPCWSTR
lpModuleName, HMODULE *phModule);
+ WINBASEAPI HMODULE WINAPI LoadLibraryExA (LPCSTR lpLibFileName, HANDLE
hFile, DWORD dwFlags);
+ WINBASEAPI HMODULE WINAPI LoadLibraryExW (LPCWSTR lpLibFileName, HANDLE
hFile, DWORD dwFlags);
+ WINUSERAPI int WINAPI LoadStringA (HINSTANCE hInstance, UINT uID, LPSTR
lpBuffer, int cchBufferMax);
+ WINUSERAPI int WINAPI LoadStringW (HINSTANCE hInstance, UINT uID, LPWSTR
lpBuffer, int cchBufferMax);
+ WINBASEAPI DWORD WINAPI SizeofResource (HMODULE hModule, HRSRC hResInfo);
+
+#ifdef UNICODE
+#define FindResourceEx FindResourceExW
+#endif
+
+#define
[Mingw-w64-public] [PATCH] winstorecompat: remove _beginthread() from windowsappcompat
It's allowed now in Windows 10. Keep it forbidden in winstorecompat (Win8) as it's forbidden there [1]. Win10 UWP builds will use the version in api-ms-win-crt-runtime-l1-1-0.dll via windowsapp. [1] https://learn.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps?view=msvc-160#windows-8x-store-apps-and-windows-phone-8x-apps --- mingw-w64-libraries/winstorecompat/Makefile.am | 1 - 1 file changed, 1 deletion(-) diff --git a/mingw-w64-libraries/winstorecompat/Makefile.am b/mingw-w64-libraries/winstorecompat/Makefile.am index c3c4f65ee..99016a051 100644 --- a/mingw-w64-libraries/winstorecompat/Makefile.am +++ b/mingw-w64-libraries/winstorecompat/Makefile.am @@ -49,7 +49,6 @@ libwinstorecompat_a_SOURCES = \ $(NULL) libwindowsappcompat_a_SOURCES = \ - src/beginthread.c \ src/LoadLibraryW.c \ src/CreateFileW.c \ src/UnhandledExceptionFilter.c \ -- 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] headers: enable GetVolumePathNameW in Win10 UWP builds
Hi, On 2023-05-28 10:51, LIU Hao wrote: 在 2023-05-27 18:05, Steve Lhomme 写道: The documentation doesn't say it's allowed, but the WIndows SDK allow it and the Windows App Certification as well. The official page for allowed API's also doesn't say it's allowed [1] but the DLL that contains it is there. [1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-file-l2-1-0dll --- mingw-w64-headers/include/fileapi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Compiling a program that calls it: With Windows 10 SDK 10.0.18362.0 this function is not declared for APP (only for DESKTOP), but with 10.0.22621.0 it is indeed declared. It might have changed inbetween so maybe we could have an `_WIN32_WINNT >= _WIN32_WINNT_` there? Indeed, here I have it in DESKTOP since 19041. So that's still a Windows 10 SDK (20H1), the latest being 19045 [1]. The API is not hidden by a NTDDI_VERSION check, so it should apply to all Windows 10 versions. And since the Windows App Certification doesn't differentiate between the Windows 10 versions, I think we can use it in all Windows 10 versions. The definition is moved into a code block that is inside: #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || _WIN32_WINNT >= _WIN32_WINNT_WIN10 So I think it's OK like that. [1] https://en.wikipedia.org/wiki/Windows_10_version_history -- Best regards, LIU Hao ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] headers: enable GetVolumePathNameW in Win10 UWP builds
The documentation doesn't say it's allowed, but the WIndows SDK allow it and the Windows App Certification as well. The official page for allowed API's also doesn't say it's allowed [1] but the DLL that contains it is there. [1] https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-file-l2-1-0dll --- mingw-w64-headers/include/fileapi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mingw-w64-headers/include/fileapi.h b/mingw-w64-headers/include/fileapi.h index 8ea09f6c9..e9e0c647f 100644 --- a/mingw-w64-headers/include/fileapi.h +++ b/mingw-w64-headers/include/fileapi.h @@ -81,6 +81,7 @@ WINBASEAPI DWORD WINAPI SetFilePointer (HANDLE hFile, LONG lDistanceToMove, PLON WINBASEAPI DWORD WINAPI GetFullPathNameA (LPCSTR lpFileName, DWORD nBufferLength, LPSTR lpBuffer, LPSTR *lpFilePart); WINBASEAPI DWORD WINAPI GetFullPathNameW (LPCWSTR lpFileName, DWORD nBufferLength, LPWSTR lpBuffer, LPWSTR *lpFilePart); WINBASEAPI DWORD WINAPI GetLogicalDrives (VOID); + WINBASEAPI WINBOOL WINAPI GetVolumePathNameW (LPCWSTR lpszFileName, LPWSTR lpszVolumePathName, DWORD cchBufferLength); #define FindFirstFile __MINGW_NAME_AW(FindFirstFile) #define GetDiskFreeSpace __MINGW_NAME_AW(GetDiskFreeSpace) #define GetDriveType __MINGW_NAME_AW(GetDriveType) @@ -89,7 +90,6 @@ WINBASEAPI DWORD WINAPI SetFilePointer (HANDLE hFile, LONG lDistanceToMove, PLON #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) WINBASEAPI DWORD WINAPI GetLogicalDriveStringsW (DWORD nBufferLength, LPWSTR lpBuffer); WINBASEAPI DWORD WINAPI GetShortPathNameW (LPCWSTR lpszLongPath, LPWSTR lpszShortPath, DWORD cchBuffer); - WINBASEAPI WINBOOL WINAPI GetVolumePathNameW (LPCWSTR lpszFileName, LPWSTR lpszVolumePathName, DWORD cchBufferLength); WINBASEAPI DWORD WINAPI QueryDosDeviceW (LPCWSTR lpDeviceName, LPWSTR lpTargetPath, DWORD ucchMax); WINBASEAPI WINBOOL WINAPI ReadFileScatter (HANDLE hFile, FILE_SEGMENT_ELEMENT aSegmentArray[], DWORD nNumberOfBytesToRead, LPDWORD lpReserved, LPOVERLAPPED lpOverlapped); WINBASEAPI WINBOOL WINAPI SetFileValidData (HANDLE hFile, LONGLONG ValidDataLength); -- 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] headers: enable CreateHardLinkW in Win10 UWP builds
The documentation doesn't say it's allowed, but the WIndows SDK allow it and
the Windows App Certification as well.
The official page for allowed API's also doesn't say it's allowed [1]
but the DLL that contains it is there.
[1]
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-file-l2-1-0dll
---
mingw-w64-headers/include/winbase.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/winbase.h
b/mingw-w64-headers/include/winbase.h
index 82c8b7cc3..94f5df309 100644
--- a/mingw-w64-headers/include/winbase.h
+++ b/mingw-w64-headers/include/winbase.h
@@ -2464,9 +2464,11 @@ typedef enum FILE_FLUSH_MODE {
WINBASEAPI WINBOOL WINAPI ReplaceFileA (LPCSTR lpReplacedFileName, LPCSTR
lpReplacementFileName, LPCSTR lpBackupFileName, DWORD dwReplaceFlags, LPVOID
lpExclude, LPVOID lpReserved);
WINBASEAPI WINBOOL WINAPI ReplaceFileW (LPCWSTR lpReplacedFileName, LPCWSTR
lpReplacementFileName, LPCWSTR lpBackupFileName, DWORD dwReplaceFlags, LPVOID
lpExclude, LPVOID lpReserved);
#endif
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || _WIN32_WINNT >=
_WIN32_WINNT_WIN10
+ WINBASEAPI WINBOOL WINAPI CreateHardLinkW (LPCWSTR lpFileName, LPCWSTR
lpExistingFileName, LPSECURITY_ATTRIBUTES lpSecurityAttributes);
+#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
WINBASEAPI WINBOOL WINAPI CreateHardLinkA (LPCSTR lpFileName, LPCSTR
lpExistingFileName, LPSECURITY_ATTRIBUTES lpSecurityAttributes);
- WINBASEAPI WINBOOL WINAPI CreateHardLinkW (LPCWSTR lpFileName, LPCWSTR
lpExistingFileName, LPSECURITY_ATTRIBUTES lpSecurityAttributes);
#define ReplaceFile __MINGW_NAME_AW(ReplaceFile)
#define CreateHardLink __MINGW_NAME_AW(CreateHardLink)
--
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] headers: enable VirtualAlloc(Ex) in Win10 UWP builds
It is now officially allowed [1].
[1]
https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc
---
mingw-w64-headers/include/memoryapi.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-headers/include/memoryapi.h
b/mingw-w64-headers/include/memoryapi.h
index 0f2b4ae79..152671c18 100644
--- a/mingw-w64-headers/include/memoryapi.h
+++ b/mingw-w64-headers/include/memoryapi.h
@@ -29,6 +29,8 @@ extern "C" {
#endif
#if (WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP) && _WIN32_WINNT >=
_WIN32_WINNT_WIN10) || WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
+WINBASEAPI LPVOID WINAPI VirtualAlloc (LPVOID lpAddress, SIZE_T dwSize,
DWORD flAllocationType, DWORD flProtect);
+WINBASEAPI LPVOID WINAPI VirtualAllocEx (HANDLE hProcess, LPVOID
lpAddress, SIZE_T dwSize, DWORD flAllocationType, DWORD flProtect);
WINBASEAPI WINBOOL WINAPI VirtualFree (LPVOID lpAddress, SIZE_T dwSize,
DWORD dwFreeType);
#endif
@@ -78,8 +80,6 @@ extern "C" {
#define FILE_CACHE_MIN_HARD_ENABLE 0x0004
#define FILE_CACHE_MIN_HARD_DISABLE 0x0008
- WINBASEAPI LPVOID WINAPI VirtualAlloc (LPVOID lpAddress, SIZE_T dwSize,
DWORD flAllocationType, DWORD flProtect);
- WINBASEAPI LPVOID WINAPI VirtualAllocEx (HANDLE hProcess, LPVOID lpAddress,
SIZE_T dwSize, DWORD flAllocationType, DWORD flProtect);
WINBASEAPI WINBOOL WINAPI VirtualProtectEx (HANDLE hProcess, LPVOID
lpAddress, SIZE_T dwSize, DWORD flNewProtect, PDWORD lpflOldProtect);
WINBASEAPI SIZE_T WINAPI VirtualQueryEx (HANDLE hProcess, LPCVOID lpAddress,
PMEMORY_BASIC_INFORMATION lpBuffer, SIZE_T dwLength);
WINBASEAPI WINBOOL WINAPI ReadProcessMemory (HANDLE hProcess, LPCVOID
lpBaseAddress, LPVOID lpBuffer, SIZE_T nSize, SIZE_T *lpNumberOfBytesRead);
--
2.39.2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
