Re: [Mingw-w64-public] [PATCH v2 1/6] headers: allow blocking some C runtime APIs in winstore builds

[Martin Storsjö]

On Fri, 17 Apr 2020, Steve Lhomme wrote:


Based on this documentation some APIs are not allowed in UWP builds
https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps?view=vs-2019

The documentation is old and may not apply to Win10 but it's still the one
listed for UCRT compatibility :
https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=vs-2019
---
mingw-w64-headers/crt/corecrt.h | 5 +
1 file changed, 5 insertions(+)

diff --git a/mingw-w64-headers/crt/corecrt.h b/mingw-w64-headers/crt/corecrt.h
index 8f9f6b42..7694eb3c 100644
--- a/mingw-w64-headers/crt/corecrt.h
+++ b/mingw-w64-headers/crt/corecrt.h
@@ -491,6 +491,11 @@ typedef struct threadlocaleinfostruct {
#define __crt_typefix(ctype)
#endif

+#include 
+#if WINAPI_FAMILY_PARTITION (WINAPI_FAMILY_DESKTOP_APP)


This shouldn't use the end-user WINAPI_FAMILY_DESKTOP_APP, this should use 
WINAPI_PARTITION_DESKTOP - i.e. this:


#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)

Just like all the other headers in include/* use.

// Martin



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

Re: [Mingw-w64-public] [PATCH 1/5] headers: allow blocking some C runtime APIs in winstore builds

[Martin Storsjö]

On Fri, 17 Apr 2020, Steve Lhomme wrote:


On 2020-04-16 21:38, Martin Storsjö wrote:

On Thu, 16 Apr 2020, Steve Lhomme wrote:


Based on this documentation some APIs are not allowed in UWP builds

https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps?view=vs-2019 



The documentation is old and may not apply to Win10 but it's still the 
one

listed for UCRT compatibility :

https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=vs-2019 


---
mingw-w64-headers/crt/corecrt.h | 7 +++
1 file changed, 7 insertions(+)

diff --git a/mingw-w64-headers/crt/corecrt.h 
b/mingw-w64-headers/crt/corecrt.h

index 8f9f6b42..76bb2ebe 100644
--- a/mingw-w64-headers/crt/corecrt.h
+++ b/mingw-w64-headers/crt/corecrt.h
@@ -491,6 +491,13 @@ typedef struct threadlocaleinfostruct {
#define __crt_typefix(ctype)
#endif

+#include 
+#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP)
+#define _CRT_ALLOW_API_FAMILY_APP
+#elif WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
+#define _CRT_ALLOW_API_FAMILY_DESKTOP
+#endif


This doesn't seem right.

If WINAPI_FAMILY == WINAPI_FAMILY_DESKTOP_APP, then 
WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_APP) is true, and 
_CRT_ALLOW_API_FAMILY_DESKTOP never gets defined.


You're right. WINAPI_FAMILY_DESKTOP_APP matches both. So only 
_CRT_ALLOW_API_FAMILY_APP is defined.


The goal of _CRT_ALLOW_API_FAMILY_APP is to only select API's allowed 
for "apps" (WINAPI_PARTITION_APP), so the opposite of what 
WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP) provides. In the end I 
don't use it.


So I only need to define _CRT_ALLOW_API_FAMILY_DESKTOP which should be 
defined when we're not in WINAPI_FAMILY_APP. But the 
WINAPI_FAMILY_PARTITION() macro doesn't allow selecting only 
WINAPI_FAMILY_APP.




So in the end I need to switch the code to define 
_CRT_ALLOW_API_FAMILY_APP and then hide some API's when it's defined.


So you mean there's functions that are only available when WINAPI_FAMILY 
strictly is set to WINAPI_FAMILY_APP, despite the fact that 
WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_APP) is set even when targeting 
desktop? Which ones is that? The vast majority of "functions you should 
use when targeting the app subset" is available in desktop mode as well.


Btw why do you need to add this custom define at all - can't the crt code 
just use WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP) like the 
platform headers?


// Martin

___
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] Revert "headers: move the C++ check for interlocked API"

[Martin Storsjö]

This reverts commit 1013ae930cd6599dbfb181430996791731d18dc1.

This has been fixed properly now, that fix only hid the issue
when compiling in C mode.

Signed-off-by: Martin Storsjö 
---
 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 17025b301..d28b84be1 100644
--- a/mingw-w64-headers/include/winbase.h
+++ b/mingw-w64-headers/include/winbase.h
@@ -3051,7 +3051,7 @@ extern "C" {
 
 #if !defined (RC_INVOKED) && !defined (NOWINBASEINTERLOCK) && !defined 
(_NTOS_) && !defined 
(MICROSOFT_WINDOWS_WINBASE_INTERLOCKED_CPLUSPLUS_H_INCLUDED)
 #define MICROSOFT_WINDOWS_WINBASE_INTERLOCKED_CPLUSPLUS_H_INCLUDED
-#if !defined (__WIDL__) && defined (__cplusplus)
+#if !defined (__WIDL__)
 #if !defined 
(MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS)
 #if (_WIN32_WINNT >= 0x0502 || !defined (_WINBASE_))
 #define MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS 1
@@ -3059,7 +3059,7 @@ extern "C" {
 #define MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS 0
 #endif
 #endif
-#if MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS
+#if MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS && 
defined (__cplusplus)
 extern "C++" {
 #if defined(__x86_64__) && defined(__CYGWIN__)
 #define __MINGW_USE_INT64_INTERLOCKED_LONG
-- 
2.17.1



___
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: Don't have a define expand to something containing defined()

[Martin Storsjö]

The behaviour of a macro expanding to something containing defined()
is undefined.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-headers/include/winbase.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/mingw-w64-headers/include/winbase.h 
b/mingw-w64-headers/include/winbase.h
index 8abb610be..17025b301 100644
--- a/mingw-w64-headers/include/winbase.h
+++ b/mingw-w64-headers/include/winbase.h
@@ -3053,7 +3053,11 @@ extern "C" {
 #define MICROSOFT_WINDOWS_WINBASE_INTERLOCKED_CPLUSPLUS_H_INCLUDED
 #if !defined (__WIDL__) && defined (__cplusplus)
 #if !defined 
(MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS)
-#define MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS 
(_WIN32_WINNT >= 0x0502 || !defined (_WINBASE_))
+#if (_WIN32_WINNT >= 0x0502 || !defined (_WINBASE_))
+#define MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS 1
+#else
+#define MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS 0
+#endif
 #endif
 #if MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS
 extern "C++" {
-- 
2.17.1



___
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: Include codecapi.h in uuids.h and define UUID_GEN if INITGUID is defined

[Martin Storsjö]

Without this, the guids defined in codecapi.h essentially can't be
used.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-headers/include/uuids.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/mingw-w64-headers/include/uuids.h 
b/mingw-w64-headers/include/uuids.h
index ec93ec2a6..1af246a3d 100644
--- a/mingw-w64-headers/include/uuids.h
+++ b/mingw-w64-headers/include/uuids.h
@@ -363,6 +363,11 @@ 
OUR_GUID_ENTRY(CODECAPI_SETALLDEFAULTS,0x6c5e6a7c,0xacf8,0x4f55,0xa9,0x99,0x1a,0
 
OUR_GUID_ENTRY(CODECAPI_ALLSETTINGS,0x6a577e92,0x83e1,0x4113,0xad,0xc2,0x4f,0xce,0xc3,0x2f,0x83,0xa1)
 
OUR_GUID_ENTRY(CODECAPI_SUPPORTSEVENTS,0x0581af97,0x7693,0x4dbd,0x9d,0xca,0x3f,0x9e,0xbd,0x65,0x85,0xa1)
 
OUR_GUID_ENTRY(CODECAPI_CURRENTCHANGELIST,0x1cb14e83,0x7d72,0x4657,0x83,0xfd,0x47,0xa2,0xc5,0xb9,0xd1,0x3d)
+
+#ifdef INITGUID
+#define UUID_GEN
+#include 
+#endif
 #endif
 
 #undef OUR_GUID_ENTRY
-- 
2.17.1



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

[Mingw-w64-public] [PATCH 5/5] headers: Add a few more new guids to mftransform.idl

[Martin Storsjö]

There's many, many others missing, but these are the ones currently
used by one piece of code I'm working on.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-headers/include/mftransform.h   | 10 ++
 mingw-w64-headers/include/mftransform.idl | 10 ++
 2 files changed, 20 insertions(+)

diff --git a/mingw-w64-headers/include/mftransform.h 
b/mingw-w64-headers/include/mftransform.h
index f1a0c3083..7d397c20d 100644
--- a/mingw-w64-headers/include/mftransform.h
+++ b/mingw-w64-headers/include/mftransform.h
@@ -533,6 +533,16 @@ EXTERN_GUID(MFT_HW_TIMESTAMP_WITH_QPC_Attribute, 
0x8d030fb8,0xcc43,0x4258,0x
 EXTERN_GUID(MFT_FIELDOFUSE_UNLOCK_Attribute, 
0x8ec2e9fd,0x9148,0x410d,0x83,0x1e,0x70,0x24,0x39,0x46,0x1a,0x8e);
 EXTERN_GUID(MFT_CODEC_MERIT_Attribute,   
0x88a7cb15,0x7b07,0x4a34,0x91,0x28,0xe6,0x4c,0x67,0x3,0xc4,0xd3);
 EXTERN_GUID(MFT_ENUM_TRANSCODE_ONLY_ATTRIBUTE,   
0x111ea8cd,0xb62a,0x4bdb,0x89,0xf6,0x67,0xff,0xcd,0xc2,0x45,0x8b);
+EXTERN_GUID(MF_SA_REQUIRED_SAMPLE_COUNT_PROGRESSIVE,
0xb172d58e,0xfa77,0x4e48,0x8d,0x2a,0x1d,0xf2,0xd8,0x50,0xea,0xc2);
+EXTERN_GUID(MF_SA_MINIMUM_OUTPUT_SAMPLE_COUNT,  
0x851745d5,0xc3d6,0x476d,0x95,0x27,0x49,0x8e,0xf2,0xd1,0xd,0x18);
+EXTERN_GUID(MF_SA_MINIMUM_OUTPUT_SAMPLE_COUNT_PROGRESSIVE,  
0xf5523a5,0x1cb2,0x47c5,0xa5,0x50,0x2e,0xeb,0x84,0xb4,0xd1,0x4a);
+EXTERN_GUID(MF_SA_D3D11_BINDFLAGS,  
0xeacf97ad,0x065c,0x4408,0xbe,0xe3,0xfd,0xcb,0xfd,0x12,0x8b,0xe2);
+EXTERN_GUID(MF_SA_D3D11_USAGE,  
0xe85fe442,0x2ca3,0x486e,0xa9,0xc7,0x10,0x9d,0xda,0x60,0x98,0x80);
+EXTERN_GUID(MF_SA_D3D11_AWARE,  
0x206b4fc8,0xfcf9,0x4c51,0xaf,0xe3,0x97,0x64,0x36,0x9e,0x33,0xa0);
+EXTERN_GUID(MF_SA_D3D11_SHARED, 
0x7b8f32c3,0x6d96,0x4b89,0x92,0x3,0xdd,0x38,0xb6,0x14,0x14,0xf3 );
+EXTERN_GUID(MF_SA_D3D11_SHARED_WITHOUT_MUTEX,   
0x39dbd44d,0x2e44,0x4931,0xa4,0xc8,0x35,0x2d,0x3d,0xc4,0x21,0x15);
+EXTERN_GUID(MF_SA_D3D11_ALLOW_DYNAMIC_YUV_TEXTURE,  
0xce06d49f,0x613,0x4b9d,0x86,0xa6,0xd8,0xc4,0xf9,0xc1,0x0,0x75);
+EXTERN_GUID(MF_SA_D3D11_HW_PROTECTED,   
0x3a8ba9d9,0x92ca,0x4307,0xa3,0x91,0x69,0x99,0xdb,0xf3,0xb6,0xce);
 #if (WINVER >= 0x0601)
 HRESULT WINAPI MFCreateTransformActivate(IMFActivate **ppActivate);
 #endif /*(WINVER >= 0x0601)*/
diff --git a/mingw-w64-headers/include/mftransform.idl 
b/mingw-w64-headers/include/mftransform.idl
index cb0b14e4d..0d3a5a58f 100644
--- a/mingw-w64-headers/include/mftransform.idl
+++ b/mingw-w64-headers/include/mftransform.idl
@@ -168,6 +168,16 @@ 
cpp_quote("EXTERN_GUID(MFT_HW_TIMESTAMP_WITH_QPC_Attribute, 0x8d030fb8,0xcc4
 cpp_quote("EXTERN_GUID(MFT_FIELDOFUSE_UNLOCK_Attribute, 
0x8ec2e9fd,0x9148,0x410d,0x83,0x1e,0x70,0x24,0x39,0x46,0x1a,0x8e);")
 cpp_quote("EXTERN_GUID(MFT_CODEC_MERIT_Attribute,   
0x88a7cb15,0x7b07,0x4a34,0x91,0x28,0xe6,0x4c,0x67,0x3,0xc4,0xd3);")
 cpp_quote("EXTERN_GUID(MFT_ENUM_TRANSCODE_ONLY_ATTRIBUTE,   
0x111ea8cd,0xb62a,0x4bdb,0x89,0xf6,0x67,0xff,0xcd,0xc2,0x45,0x8b);")
+cpp_quote("EXTERN_GUID(MF_SA_REQUIRED_SAMPLE_COUNT_PROGRESSIVE,
0xb172d58e,0xfa77,0x4e48,0x8d,0x2a,0x1d,0xf2,0xd8,0x50,0xea,0xc2);")
+cpp_quote("EXTERN_GUID(MF_SA_MINIMUM_OUTPUT_SAMPLE_COUNT,  
0x851745d5,0xc3d6,0x476d,0x95,0x27,0x49,0x8e,0xf2,0xd1,0xd,0x18);")
+cpp_quote("EXTERN_GUID(MF_SA_MINIMUM_OUTPUT_SAMPLE_COUNT_PROGRESSIVE,  
0xf5523a5,0x1cb2,0x47c5,0xa5,0x50,0x2e,0xeb,0x84,0xb4,0xd1,0x4a);")
+cpp_quote("EXTERN_GUID(MF_SA_D3D11_BINDFLAGS,  
0xeacf97ad,0x065c,0x4408,0xbe,0xe3,0xfd,0xcb,0xfd,0x12,0x8b,0xe2);")
+cpp_quote("EXTERN_GUID(MF_SA_D3D11_USAGE,  
0xe85fe442,0x2ca3,0x486e,0xa9,0xc7,0x10,0x9d,0xda,0x60,0x98,0x80);")
+cpp_quote("EXTERN_GUID(MF_SA_D3D11_AWARE,  
0x206b4fc8,0xfcf9,0x4c51,0xaf,0xe3,0x97,0x64,0x36,0x9e,0x33,0xa0);")
+cpp_quote("EXTERN_GUID(MF_SA_D3D11_SHARED, 
0x7b8f32c3,0x6d96,0x4b89,0x92,0x3,0xdd,0x38,0xb6,0x14,0x14,0xf3 );")
+cpp_quote("EXTERN_GUID(MF_SA_D3D11_SHARED_WITHOUT_MUTEX,   
0x39dbd44d,0x2e44,0x4931,0xa4,0xc8,0x35,0x2d,0x3d,0xc4,0x21,0x15);")
+cpp_quote("EXTERN_GUID(MF_SA_D3D11_ALLOW_DYNAMIC_YUV_TEXTURE,  
0xce06d49f,0x613,0x4b9d,0x86,0xa6,0xd8,0xc4,0xf9,0xc1,0x0,0x75);")
+cpp_quote("EXTERN_GUID(MF_SA_D3D11_HW_PROTECTED,   
0x3a8ba9d9,0x92ca,0x4307,0xa3,0x91,0x69,0x99,0xdb,0xf3,0xb6,0xce);")
 
 
 cpp_quote("#if (WINVER >= 0x0601)")
-- 
2.17.1



___
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: Fix missing enum values in mfobjects.h

[Martin Storsjö]

The ifdefs (that aren't within cpp_quote()) in the idl file aren't
brought along as such, but are evaluated when widl interprets the
file, which means the enclosed declarations are left out, and the
ifdefs don't make it into the final header.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-headers/include/mfobjects.h   | 33 ++---
 mingw-w64-headers/include/mfobjects.idl |  6 -
 2 files changed, 24 insertions(+), 15 deletions(-)

diff --git a/mingw-w64-headers/include/mfobjects.h 
b/mingw-w64-headers/include/mfobjects.h
index f11afc136..e77b626a8 100644
--- a/mingw-w64-headers/include/mfobjects.h
+++ b/mingw-w64-headers/include/mfobjects.h
@@ -1,4 +1,4 @@
-/*** Autogenerated by WIDL 4.12.1 from include/mfobjects.idl - Do not edit ***/
+/*** Autogenerated by WIDL 5.0-rc1 from include/mfobjects.idl - Do not edit 
***/
 
 #ifdef _WIN32
 #ifndef __REQUIRED_RPCNDR_H_VERSION__
@@ -245,7 +245,7 @@ typedef struct tWAVEFORMATEX {
 typedef struct tWAVEFORMATEX *PWAVEFORMATEX;
 typedef struct tWAVEFORMATEX *NPWAVEFORMATEX;
 typedef struct tWAVEFORMATEX *LPWAVEFORMATEX;
-typedef struct __WIDL_mfobjects_generated_name_0013 {
+typedef struct __WIDL_mfobjects_generated_name_0027 {
 WORD wFormatTag;
 WORD nChannels;
 DWORD nSamplesPerSec;
@@ -257,7 +257,7 @@ typedef struct __WIDL_mfobjects_generated_name_0013 {
 DWORD dwChannelMask;
 GUID SubFormat;
 } WAVEFORMATEXTENSIBLE;
-typedef struct __WIDL_mfobjects_generated_name_0013 *PWAVEFORMATEXTENSIBLE;
+typedef struct __WIDL_mfobjects_generated_name_0027 *PWAVEFORMATEXTENSIBLE;
 #endif
 
 #if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_APP)
@@ -2620,7 +2620,7 @@ static FORCEINLINE const WAVEFORMATEX * 
IMFAudioMediaType_GetAudioFormat(IMFAudi
 #ifndef _WINGDI_
 typedef DWORD RGBQUAD;
 
-typedef struct __WIDL_mfobjects_generated_name_0014 {
+typedef struct __WIDL_mfobjects_generated_name_0028 {
 DWORD biSize;
 LONG biWidth;
 LONG biHeight;
@@ -2634,13 +2634,13 @@ typedef struct __WIDL_mfobjects_generated_name_0014 
{
 DWORD biClrImportant;
 } BITMAPINFOHEADER;
 
-typedef struct __WIDL_mfobjects_generated_name_0015 {
+typedef struct __WIDL_mfobjects_generated_name_0029 {
 BITMAPINFOHEADER bmiHeader;
 RGBQUAD bmiColors[1];
 } BITMAPINFO;
 #endif
 
-typedef struct __WIDL_mfobjects_generated_name_0016 {
+typedef struct __WIDL_mfobjects_generated_name_002A {
 GUID guidMajorType;
 GUID guidSubtype;
 } MFT_REGISTER_TYPE_INFO;
@@ -3696,6 +3696,13 @@ enum {
 MEAudioSessionDisconnected = 320,
 MEAudioSessionExclusiveModeOverride = 321,
 MESinkV1Anchor = MEAudioSessionExclusiveModeOverride,
+MECaptureAudioSessionVolumeChanged = 322,
+MECaptureAudioSessionDeviceRemoved = 323,
+MECaptureAudioSessionFormatChanged = 324,
+MECaptureAudioSessionDisconnected = 325,
+MECaptureAudioSessionExclusiveModeOverride = 326,
+MECaptureAudioSessionServerShutdown = 327,
+MESinkV2Anchor = MECaptureAudioSessionServerShutdown,
 METrustUnknown = 400,
 MEPolicyChanged = 401,
 MEContentProtectionMessage = 402,
@@ -3712,6 +3719,14 @@ enum {
 MEWMDRMLicenseStoreCleaned = 515,
 MEWMDRMRevocationDownloadCompleted = 516,
 MEWMDRMV1Anchor = MEWMDRMRevocationDownloadCompleted,
+METransformUnknown = 600,
+METransformNeedInput = 601,
+METransformHaveOutput = 602,
+METransformDrainComplete = 603,
+METransformMarker = 604,
+MEByteStreamCharacteristicsChanged = 700,
+MEVideoCaptureDeviceRemoved = 800,
+MEVideoCaptureDevicePreempted = 801,
 MEReservedMax = 1
 };
 
@@ -4814,13 +4829,13 @@ static FORCEINLINE HRESULT 
IMFByteStreamProxyClassFactory_CreateByteStreamProxy(
 #endif  /* __IMFByteStreamProxyClassFactory_INTERFACE_DEFINED__ */
 
 
-typedef enum __WIDL_mfobjects_generated_name_0017 {
+typedef enum __WIDL_mfobjects_generated_name_002B {
 MF_ACCESSMODE_READ = 1,
 MF_ACCESSMODE_WRITE = 2,
 MF_ACCESSMODE_READWRITE = 3
 } MF_FILE_ACCESSMODE;
 
-typedef enum __WIDL_mfobjects_generated_name_0018 {
+typedef enum __WIDL_mfobjects_generated_name_002C {
 MF_OPENMODE_FAIL_IF_NOT_EXIST = 0,
 MF_OPENMODE_FAIL_IF_EXIST = 1,
 MF_OPENMODE_RESET_IF_EXIST = 2,
@@ -4828,7 +4843,7 @@ typedef enum __WIDL_mfobjects_generated_name_0018 {
 MF_OPENMODE_DELETE_IF_EXIST = 4
 } MF_FILE_OPENMODE;
 
-typedef enum __WIDL_mfobjects_generated_name_0019 {
+typedef enum __WIDL_mfobjects_generated_name_002D {
 MF_FILEFLAGS_NONE = 0x0,
 MF_FILEFLAGS_NOBUFFERING = 0x1
 } MF_FILE_FLAGS;
diff --git a/mingw-w64-headers/include/mfobjects.idl 
b/mingw-w64-headers/include/mfobjects.idl
index 82462ff4c..29caf1944 100644
--- a/mingw-w64-headers/include/mfobjects.idl
+++ b/mingw-w64-headers/include/mfobjects.idl
@@ -582,7 +582,6 @@ enum {
   MEAudioSessionDisconnected = 320,
   MEAudioSessionExclusiveModeOverride = 321,
   MESinkV1Anchor = MEAudioSessionExclusiveModeOverride

[Mingw-w64-public] [PATCH 1/5] headers: Use EXTERN_GUID and DEFINE_PROPERTYKEY instead of a custom macro in mftransform.idl

[Martin Storsjö]

These macros achieve exactly the same as the custom macro. That macro
was added in 84b180158009d4210f72d76e3888214dae045dab to avoid compiler
warnings - earlier d551b7d85ec63c0fa33f1a51ec5157722709fc53 tried to
fix the same warnings as well with a different setup. But these standard
macros that are used elsewhere already take care of the same issue.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-headers/include/mftransform.h   | 58 +
 mingw-w64-headers/include/mftransform.idl | 62 +--
 2 files changed, 49 insertions(+), 71 deletions(-)

diff --git a/mingw-w64-headers/include/mftransform.h 
b/mingw-w64-headers/include/mftransform.h
index de9c3a7db..f1a0c3083 100644
--- a/mingw-w64-headers/include/mftransform.h
+++ b/mingw-w64-headers/include/mftransform.h
@@ -1,4 +1,4 @@
-/*** Autogenerated by WIDL 5.0-rc1 from ../include/mftransform.idl - Do not 
edit ***/
+/*** Autogenerated by WIDL 5.0-rc1 from include/mftransform.idl - Do not edit 
***/
 
 #ifdef _WIN32
 #ifndef __REQUIRED_RPCNDR_H_VERSION__
@@ -509,38 +509,30 @@ static FORCEINLINE HRESULT 
IMFTransform_ProcessOutput(IMFTransform* This,DWORD d
 
 #endif  /* __IMFTransform_INTERFACE_DEFINED__ */
 
-#ifndef __DEFINE_EXTERN_CONST
-#ifdef __cplusplus
-#define __DEFINE_EXTERN_CONST extern "C" const
-#else
-#define __DEFINE_EXTERN_CONST const
-#endif
-#endif
-
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CLSID = 
{{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x01};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CATEGORY = 
{{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x02 };
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY PROPERTYKEY 
MFPKEY_EXATTRIBUTE_SUPPORTED = 
{{0x456fe843,0x3c87,0x40c0,{0x94,0x9d,0x14,0x9,0xc9,0x7d,0xab,0x2c}}, 0x01};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY PROPERTYKEY 
MFPKEY_MULTICHANNEL_CHANNEL_MASK = 
{{0x58bdaf8c,0x3224,0x4692,{0x86,0xd0,0x44,0xd6,0x5c,0x5b,0xf8,0x2b}}, 0x01};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MF_SA_D3D_AWARE = 
{0xeaa35c29,0x775e,0x488e,{0x9b,0x61,0xb3,0x28,0x3e,0x49,0x58,0x3b}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MF_SA_REQUIRED_SAMPLE_COUNT = 
{0x18802c61,0x324b,0x4952,{0xab,0xd0,0x17,0x6f,0xf5,0xc6,0x96,0xff}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MF_TRANSFORM_ASYNC = 
{0xf81a699a,0x649a,0x497d,{0x8c,0x73,0x29,0xf8,0xfe,0xd6,0xad,0x7a}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MF_TRANSFORM_ASYNC_UNLOCK = 
{0xe5666d6b,0x3422,0x4eb6,{0xa4,0x21,0xda,0x7d,0xb1,0xf8,0xe2,0x7}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MF_TRANSFORM_FLAGS_Attribute = 
{0x9359bb7e,0x6275,0x46c4,{0xa0,0x25,0x1c,0x1,0xe4,0x5f,0x1a,0x86}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MF_TRANSFORM_CATEGORY_Attribute 
= {0xceabba49,0x506d,0x4757,{0xa6,0xff,0x66,0xc1,0x84,0x98,0x7e,0x4e}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MFT_TRANSFORM_CLSID_Attribute = 
{0x6821c42b,0x65a4,0x4e82,{0x99,0xbc,0x9a,0x88,0x20,0x5e,0xcd,0xc}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MFT_INPUT_TYPES_Attributes = 
{0x4276c9b1,0x759d,0x4bf3, {0x9c,0xd0,0xd,0x72,0x3d,0x13,0x8f,0x96}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MFT_OUTPUT_TYPES_Attributes = 
{0x8eae8cf3,0xa44f,0x4306,{0xba,0x5c,0xbf,0x5d,0xda,0x24,0x28,0x18}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MFT_ENUM_HARDWARE_URL_Attribute 
= {0x2fb866ac,0xb078,0x4942,{0xab,0x6c,0x0,0x3d,0x5,0xcd,0xa6,0x74}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MFT_FRIENDLY_NAME_Attribute = 
{0x314ffbae,0x5b41,0x4c95,{0x9c,0x19,0x4e,0x7d,0x58,0x6f,0xac,0xe3}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MFT_CONNECTED_STREAM_ATTRIBUTE  
= {0x71eeb820,0xa59f,0x4de2,{0xbc,0xec,0x38,0xdb,0x1d,0xd6,0x11,0xa4}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MFT_CONNECTED_TO_HW_STREAM = 
{0x34e6e728,0x6d6,0x4491,{0xa5,0x53,0x47,0x95,0x65,0xd,0xb9,0x12}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID 
MFT_PREFERRED_OUTPUTTYPE_Attribute = 
{0x7e700499,0x396a,0x49ee,{0xb1,0xb4,0xf6,0x28,0x2,0x1e,0x8c,0x9d}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MFT_PROCESS_LOCAL_Attribute = 
{0x543186e4,0x4649,0x4e65,{0xb5,0x88,0x4a,0xa3,0x52,0xaf,0xf3,0x79}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MFT_PREFERRED_ENCODER_PROFILE = 
{0x53004909,0x1ef5,0x46d7,{0xa1,0x8e,0x5a,0x75,0xf8,0xb5,0x90,0x5f}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID 
MFT_HW_TIMESTAMP_WITH_QPC_Attribute = 
{0x8d030fb8,0xcc43,0x4258,{0xa2,0x2e,0x92,0x10,0xbe,0xf8,0x9b,0xe4}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MFT_FIELDOFUSE_UNLOCK_Attribute 
= {0x8ec2e9fd,0x9148,0x410d,{0x83,0x1e,0x70,0x24,0x39,0x46,0x1a,0x8e}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID MFT_CODEC_MERIT_Attribute = 
{0x88a7cb15,0x7b07,0x4a34,{0x91,0x28,0xe6,0x4c,0x67,0x3,0xc4,0xd3}};
-__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY GUID 
MFT_ENUM_TRANSCODE_ONLY_ATTRIBUTE = 
{0x111ea8cd,0xb62a,0x4bdb,{0x89,0xf6,0x67,0xff,0xcd,0xc2,0x45,0x8b}};
+DEFINE_P

[Mingw-w64-public] [PATCH 4/5] headers: Add a few more guids and enums to codecapi.h

[Martin Storsjö]

There's many, many others missing, but these are the ones currently
used by one piece of code I'm working on.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-headers/include/codecapi.h | 41 
 1 file changed, 41 insertions(+)

diff --git a/mingw-w64-headers/include/codecapi.h 
b/mingw-w64-headers/include/codecapi.h
index a829b6217..fd849e970 100644
--- a/mingw-w64-headers/include/codecapi.h
+++ b/mingw-w64-headers/include/codecapi.h
@@ -61,6 +61,16 @@
 eAVEncH264VProfile_Extended   = 88 
   };
 
+  enum eAVEncCommonRateControlMode {
+eAVEncCommonRateControlMode_CBR= 0,
+eAVEncCommonRateControlMode_PeakConstrainedVBR = 1,
+eAVEncCommonRateControlMode_UnconstrainedVBR   = 2,
+eAVEncCommonRateControlMode_Quality= 3,
+eAVEncCommonRateControlMode_LowDelayVBR= 4,
+eAVEncCommonRateControlMode_GlobalVBR  = 5,
+eAVEncCommonRateControlMode_GlobalLowDelayVBR  = 6
+  };
+
 #define STATIC_CODECAPI_AVDecVideoThumbnailGenerationMode  
0x2efd8eee,0x1150,0x4328,0x9c,0xf5,0x66,0xdc,0xe9,0x33,0xfc,0xf4
 DEFINE_CODECAPI_GUID(AVDecVideoThumbnailGenerationMode, 
"2efd8eee-1150-4328-9cf5-66dce933fcf4", 0x2efd8eee,
  0x1150,0x4328,0x9c,0xf5,0x66,0xdc,0xe9,0x33,0xfc,0xf4)
@@ -125,6 +135,30 @@ DEFINE_CODECAPI_GUID(AVDecSoftwareDynamicFormatChange, 
"862e2f0a-507b-47ff-af47-
 DEFINE_CODECAPI_GUID(AVDecDisableVideoPostProcessing, 
"f8749193-667a-4f2c-a9e8-5d4af924f08f",
  
0xf8749193,0x667a,0x4f2c,0xa9,0xe8,0x5d,0x4a,0xf9,0x24,0xf0,0x8f);
 
+#define STATIC_CODECAPI_AVEncCommonMeanBitRate  
0xf7222374,0x2144,0x4815,0xb5,0x50,0xa3,0x7f,0x8e,0x12,0xee,0x52
+DEFINE_CODECAPI_GUID(AVEncCommonMeanBitRate, 
"f7222374-2144-4815-b550-a37f8e12ee52",
+ 
0xf7222374,0x2144,0x4815,0xb5,0x50,0xa3,0x7f,0x8e,0x12,0xee,0x52)
+
+#define STATIC_CODECAPI_AVEncCommonQuality  
0xfcbf57a3,0x7ea5,0x4b0c,0x96,0x44,0x69,0xb4,0x0c,0x39,0xc3,0x91
+DEFINE_CODECAPI_GUID(AVEncCommonQuality, 
"fcbf57a3-7ea5-4b0c-9644-69b40c39c391",
+ 
0xfcbf57a3,0x7ea5,0x4b0c,0x96,0x44,0x69,0xb4,0x0c,0x39,0xc3,0x91)
+
+#define STATIC_CODECAPI_AVEncCommonRateControlMode  
0x1c0608e9,0x370c,0x4710,0x8a,0x58,0xcb,0x61,0x81,0xc4,0x24,0x23
+DEFINE_CODECAPI_GUID(AVEncCommonRateControlMode, 
"1c0608e9-370c-4710-8a58-cb6181c42423",
+ 
0x1c0608e9,0x370c,0x4710,0x8a,0x58,0xcb,0x61,0x81,0xc4,0x24,0x23)
+
+#define STATIC_CODECAPI_AVEncVideoForceKeyFrame  
0x398c1b98,0x8353,0x475a,0x9e,0xf2,0x8f,0x26,0x5d,0x26,0x3,0x45
+DEFINE_CODECAPI_GUID(AVEncVideoForceKeyFrame, 
"398c1b98-8353-475a-9ef2-8f265d260345",
+ 
0x398c1b98,0x8353,0x475a,0x9e,0xf2,0x8f,0x26,0x5d,0x26,0x3,0x45)
+
+#define STATIC_CODECAPI_AVEncMPVDefaultBPictureCount  
0x8d390aac,0xdc5c,0x4200,0xb5,0x7f,0x81,0x4d,0x04,0xba,0xba,0xb2
+DEFINE_CODECAPI_GUID(AVEncMPVDefaultBPictureCount, 
"8d390aac-dc5c-4200-b57f-814d04babab2",
+ 
0x8d390aac,0xdc5c,0x4200,0xb5,0x7f,0x81,0x4d,0x04,0xba,0xba,0xb2)
+
+#define STATIC_CODECAPI_AVEncH264CABACEnable  
0xee6cad62,0xd305,0x4248,0xa5,0xe,0xe1,0xb2,0x55,0xf7,0xca,0xf8
+DEFINE_CODECAPI_GUID(AVEncH264CABACEnable, 
"ee6cad62-d305-4248-a50e-e1b255f7caf8",
+ 
0xee6cad62,0xd305,0x4248,0xa5,0xe,0xe1,0xb2,0x55,0xf7,0xca,0xf8)
+
 #ifndef UUID_GEN
 
 #define CODECAPI_AVDecVideoThumbnailGenerationMode  
DEFINE_CODECAPI_GUIDNAMED(AVDecVideoThumbnailGenerationMode)
@@ -143,6 +177,13 @@ DEFINE_CODECAPI_GUID(AVDecDisableVideoPostProcessing, 
"f8749193-667a-4f2c-a9e8-5
 #define CODECAPI_AVDecNumWorkerThreads  
DEFINE_CODECAPI_GUIDNAMED(AVDecNumWorkerThreads)
 #define CODECAPI_AVDecSoftwareDynamicFormatChange   
DEFINE_CODECAPI_GUIDNAMED(AVDecSoftwareDynamicFormatChange)
 #define CODECAPI_AVDecDisableVideoPostProcessing
DEFINE_CODECAPI_GUIDNAMED(AVDecDisableVideoPostProcessing)
+#define CODECAPI_AVEncCommonMeanBitRate 
DEFINE_CODECAPI_GUIDNAMED(AVEncCommonMeanBitRate)
+#define CODECAPI_AVEncCommonQuality 
DEFINE_CODECAPI_GUIDNAMED(AVEncCommonQuality)
+#define CODECAPI_AVEncCommonRateControlMode 
DEFINE_CODECAPI_GUIDNAMED(AVEncCommonRateControlMode)
+#define CODECAPI_AVEncVideoForceKeyFrame
DEFINE_CODECAPI_GUIDNAMED(AVEncVideoForceKeyFrame)
+#define CODECAPI_AVEncMPVDefaultBPictureCount   
DEFINE_CODECAPI_GUIDNAMED(AVEncMPVDefaultBPictureCount)
+#define CODECAPI_AVEncMPVDefaultBPictureCount   
DEFINE_CODECAPI_GUIDNAMED(AVEncMPVDefaultBPictureCount)
+#define CODECAPI_AVEncH264CABACEnable   
DEFINE_CODECAPI_GUIDNAMED(AVEncH264CABACEnable)
 
 #endif
 
-- 
2.17.1



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

Re: [Mingw-w64-public] [PATCH][winpthreads] Allow to use provided WINPTHREAD_API and small bugfix

[Martin Storsjö]

On Sun, 15 Mar 2020, Egor Pugin wrote:


The problem is that someone put all attributes after return value, but
windows declspec must be in front of everything.
Changing
void * WINPTHREAD_API pthread_timechange_handler_np(void * dummy);
to
WINPTHREAD_API
void *  pthread_timechange_handler_np(void * dummy);
fixes that declspec issue.


Thanks, that clears things up. I'm sure it'd be ok with a patch changing 
the placement, with e.g. this explanation:


---8<---
winpthreads: Move WINPTHREAD_API to the start of declarations

GCC, and Clang in mingw mode, expand __declspec(x) into 
__attribute__((x)), but MSVC and Clang in MSVC mode keep __declspec as is.


__attribute__(()) is allowed anywhere in the function declaration, while 
__declspec() (in MSVC and Clang in MSVC mode) only is allowed at the start 
of a declaration.


Therefore, move WINPTHREAD_API within declarations to fix compilation with 
MSVC and Clang in MSVC mode.

---8<---

The original part of that patch, allowing to manually override it, still 
potentialy could be useful, maybe - with the motivation to allow custom 
overrides in general.


// Martin




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

Re: [Mingw-w64-public] [PATCH][winpthreads] Allow to use provided WINPTHREAD_API and small bugfix

[Martin Storsjö]

On Sat, 14 Mar 2020, Egor Pugin wrote:


The first hunk seems harmless. But why would you like to define

`WINPTHREAD_API` yourself?

Custom build system. Building winpthreads under native win32 with
clang (not clang-cl) without msvc compat.
Clang in such mode requires __attribute__ ((dllexport) and
__attribute__ ((dllimport), not __declspecs.


That doesn't sound like the clang behaviour I know of.

What clang target do you use, a mingw32 or msvc one? (If you're using an 
official llvm release from llvm.org, it's a msvc target by default. If you 
specify anything custom with -target, that overrides it.)


In MSVC mode, __declspec() is a native construct that is understood 
directly as is. In MinGW mode (in clang, and GCC also does the same when 
targeting mingw), __declspec(x) is a macro that expands to 
__attribute__((x)), and I don't know of a way to even disable that builtin 
define.


So with which clang version and/or clang target do you manage to have 
__declspec(dllexport) not be understood?


// Martin



___
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: Move the msvcrt snprintf/vsnprintf aliases into separate object files

[Martin Storsjö]

This avoids duplicate definitions, if something refers to e.g.
__ms_vsnprintf, while the inline vsnprintf also has been instantiated
in C++ mode. (In C++ mode, the inline vsnprintf function isn't marked
static.)

This should fix https://github.com/msys2/MINGW-packages/issues/6271.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-crt/Makefile.am  |  2 ++
 mingw-w64-crt/stdio/snprintf.c | 15 +
 mingw-w64-crt/stdio/snprintf_unprefixed.c  | 25 ++
 mingw-w64-crt/stdio/vsnprintf.c| 14 +---
 mingw-w64-crt/stdio/vsnprintf_unprefixed.c | 19 
 5 files changed, 48 insertions(+), 27 deletions(-)
 create mode 100644 mingw-w64-crt/stdio/snprintf_unprefixed.c
 create mode 100644 mingw-w64-crt/stdio/vsnprintf_unprefixed.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 87bf70176..6241b1b7c 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -170,7 +170,9 @@ src_msvcrt_common=\
   misc/wcrtomb.c \
   stdio/acrt_iob_func.c \
   stdio/snprintf.c \
+  stdio/snprintf_unprefixed.c \
   stdio/vsnprintf.c \
+  stdio/vsnprintf_unprefixed.c \
   math/frexp.c
 
 src_msvcrt=\
diff --git a/mingw-w64-crt/stdio/snprintf.c b/mingw-w64-crt/stdio/snprintf.c
index ad9dd5678..0bb5556fe 100644
--- a/mingw-w64-crt/stdio/snprintf.c
+++ b/mingw-w64-crt/stdio/snprintf.c
@@ -3,19 +3,8 @@
  * This file is part of the mingw-w64 runtime package.
  * No warranty is given; refer to the file DISCLAIMER.PD within this package.
  */
-
-#include <_mingw.h>
 #include 
-#include 
-
-/* Intentionally not including stdio.h, as it unconditionally defines the
- * snprintf inline, and it can't be renamed with "#define snprintf othername"
- * either, as stdio.h contains "#undef snprintf". */
-
-_CRTIMP int __cdecl _vscprintf(const char * __restrict__ _Format,va_list 
_ArgList);
-_CRTIMP int __cdecl _vsnprintf(char * __restrict__ _Dest,size_t _Count,const 
char * __restrict__ _Format,va_list _Args);
-
-int __cdecl __ms_snprintf(char* buffer, size_t n, const char *format, ...);
+#include 
 
 int __cdecl __ms_snprintf(char* buffer, size_t n, const char *format, ...)
 {
@@ -47,5 +36,3 @@ int __cdecl __ms_snprintf(char* buffer, size_t n, const char 
*format, ...)
   va_end(argptr);
   return retval;
 }
-
-int __attribute__ ((alias ("__ms_snprintf"))) __cdecl snprintf(char*, size_t, 
const char *, ...);
diff --git a/mingw-w64-crt/stdio/snprintf_unprefixed.c 
b/mingw-w64-crt/stdio/snprintf_unprefixed.c
new file mode 100644
index 0..1c34114d3
--- /dev/null
+++ b/mingw-w64-crt/stdio/snprintf_unprefixed.c
@@ -0,0 +1,25 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+
+#include 
+#include 
+
+/* Intentionally not including stdio.h, as it unconditionally defines the
+ * snprintf inline, and it can't be renamed with "#define snprintf othername"
+ * either, as stdio.h contains "#undef snprintf". */
+
+int __cdecl __ms_vsnprintf(char *buffer, size_t n, const char *format, va_list 
arg);
+
+int __cdecl snprintf(char *buffer, size_t n, const char *format, ...)
+{
+  int retval;
+  va_list argptr;
+
+  va_start(argptr, format);
+  retval = __ms_vsnprintf(buffer, n, format, argptr);
+  va_end(argptr);
+  return retval;
+}
diff --git a/mingw-w64-crt/stdio/vsnprintf.c b/mingw-w64-crt/stdio/vsnprintf.c
index 9c4f83b96..364186702 100644
--- a/mingw-w64-crt/stdio/vsnprintf.c
+++ b/mingw-w64-crt/stdio/vsnprintf.c
@@ -4,18 +4,8 @@
  * No warranty is given; refer to the file DISCLAIMER.PD within this package.
  */
 #define __CRT__NO_INLINE
-#include <_mingw.h>
 #include 
-#include 
-
-/* Intentionally not including stdio.h, as it unconditionally defines the
- * vsnprintf inline, and it can't be renamed with "#define vsnprintf othername"
- * either, as stdio.h contains "#undef vsnprintf". */
-
-_CRTIMP int __cdecl _vscprintf(const char * __restrict__ _Format,va_list 
_ArgList);
-_CRTIMP int __cdecl _vsnprintf(char * __restrict__ _Dest,size_t _Count,const 
char * __restrict__ _Format,va_list _Args);
-
-int __cdecl __ms_vsnprintf (char *s,size_t n,const char *format,va_list arg);
+#include 
 
 int __cdecl __ms_vsnprintf (char *s,size_t n,const char *format,va_list arg)
 {
@@ -39,5 +29,3 @@ int __cdecl __ms_vsnprintf (char *s,size_t n,const char 
*format,va_list arg)
 
 return retval;
 }
-
-int __attribute__ ((alias ("__ms_vsnprintf"))) __cdecl vsnprintf(char*, 
size_t, const char *, va_list);
diff --git a/mingw-w64-crt/stdio/vsnprintf_unprefixed.c 
b/mingw-w64-crt/stdio/vsnprintf_unprefixed.c
new file mode 100644
index 0..8c7c9b930
--- /dev/null
+++ b/mingw-w64-crt/stdio/vsnprintf_unprefixed.c
@@ -0,0 +1,19 @@
+/**
+ * This file has no copyright assigned and is placed i

Re: [Mingw-w64-public] [PATCH] crt: Move the msvcrt snprintf/vsnprintf aliases into separate object files

[Martin Storsjö]

On Mon, 16 Mar 2020, Liu Hao wrote:


在 2020/3/16 5:30, Martin Storsjö 写道:

This avoids duplicate definitions, if something refers to e.g.
__ms_vsnprintf, while the inline vsnprintf also has been instantiated
in C++ mode. (In C++ mode, the inline vsnprintf function isn't marked
static.)

This should fix https://github.com/msys2/MINGW-packages/issues/6271.

Signed-off-by: Martin Storsjö 
---



This patch looks good to me. The testcase no longer fails.


Thanks, pushed (with a minor rename of the new files, to slightly better 
names).


// Martin



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

Re: [Mingw-w64-public] [PATCH] headers: memoryapi add Windows 10 functions

[Martin Storsjö]

On Thu, 2 Apr 2020, Biswapriyo Nath wrote:


...



Did you actually test this at all, in any way, whatsoever?

Because the newly added function declarations use the types 
MEM_EXTENDED_PARAMETER and PCFG_CALL_TARGET_INFO, that aren't declared 
anywhere in mingw-w64 headers.


This breaks building mingw-w64-crt.

It looks like you're adding things just for the sake of adding things, not 
for any use, if you haven't even tried using the addition.


Please fix it.

// Martin



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

Re: [Mingw-w64-public] [PATCH] headers: memoryapi add Windows 10 functions

[Martin Storsjö]

On Sat, 4 Apr 2020, Biswapriyo Nath wrote:


Yes, I have a patch for it. I am doing it one by one. I thought it will be
easier to patch one header at a time. Apology for any inconvenience.


Patching headers one at a time is ok in itself, but you have to make sure 
the tree actually works after each one you submit. There's lots of people 
who build and use the latest version from git, and it's in a broken state 
right now.


// Martin



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

Re: [Mingw-w64-public] [PATCH] headers: memoryapi add Windows 10 functions

[Martin Storsjö]

On Sat, 4 Apr 2020, Liu Hao wrote:


在 2020/4/4 16:28, Martin Storsjö 写道:


Did you actually test this at all, in any way, whatsoever?

Because the newly added function declarations use the types
MEM_EXTENDED_PARAMETER and PCFG_CALL_TARGET_INFO, that aren't declared
anywhere in mingw-w64 headers.




Hmm.. how could this compile with the following command:

```
gcc -xc -D_WIN32_WINNT=0x -include windows.h -std=c89 -Wall -Wextra
memoryapi.h
```

This is also what I use to verify each header that it actually compiles
before pushing those patches. I think I will have to run complete builds
hereafter.


In this case - I hadn't expected you to verify it before pushing, I had 
expected the patch author to try to use it - but if you do such checks 
before pushing, it's really commendable!


In this case, it turns out that it didn't pick up the issue, because 
windows.h in itself also includes memoryapi.h, and it will include 
windows.h from your compiler's default sysroot, and that one will 
transitively include memoryapi.h from there as well. After finishing 
including windows.h, it will try to include your new version of 
memoryapi.h and skip it due to the header guards.


By adding -I. or similar you would notice the issue. (Unfortunately, our 
headers are fairly noisy if used this way - the compilers normally silence 
a number of warnings stemming from "system headers" - but in this case, 
all the headers are picked from a directory specified by -I, which isn't 
treated as the compiler default sysroot, and thus all warnings are shown.)


// Martin

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

Re: [Mingw-w64-public] [PATCH] headers: winnt add structures for memory APIs

[Martin Storsjö]

On Sat, 4 Apr 2020, Liu Hao wrote:


在 2020/4/4 18:03, Biswapriyo Nath 写道:

...





The CRT built fine. I pushed this patch.


Thanks!

// Martin

___
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 unused/unnecessary declarations of _commode in internal.h

[Martin Storsjö]

Signed-off-by: Martin Storsjö 
---
 mingw-w64-crt/include/internal.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/mingw-w64-crt/include/internal.h b/mingw-w64-crt/include/internal.h
index 9439eafb3..205d30daa 100644
--- a/mingw-w64-crt/include/internal.h
+++ b/mingw-w64-crt/include/internal.h
@@ -18,12 +18,6 @@ extern "C" {
 
 #pragma pack(push,_CRT_PACKING)
 
-#if defined (SPECIAL_CRTEXE) && (defined (_DLL) || defined (__GNUC__))
-  extern int _commode;
-#else
-  __declspec(dllimport) extern int _commode;
-#endif
-
 #define __IOINFO_TM_ANSI 0
 #define __IOINFO_TM_UTF8 1
 #define __IOINFO_TM_UTF16LE 2
-- 
2.17.1



___
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] crt: Use __p__commode instead of __MINGW_IMP_SYMBOL(_commode) for initialization

[Martin Storsjö]

This matches what was done for _fmode in
2e64b9e4537d564478f17b873b2f655f518325ed. This fixes using a
crtexe.c built without optimizations with UCRT (and fixes UCRT
in general after the previous commit).

Signed-off-by: Martin Storsjö 
---
 mingw-w64-crt/Makefile.am |  4 
 mingw-w64-crt/crt/crtexe.c|  4 ++--
 mingw-w64-crt/misc/__p__commode.c | 17 +
 3 files changed, 23 insertions(+), 2 deletions(-)
 create mode 100644 mingw-w64-crt/misc/__p__commode.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 9a1fe0739..d38e524c8 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -257,6 +257,7 @@ src_msvcrt64=\
   $(src_msvcrt) \
   misc/__p___argv.c \
   misc/__p__acmdln.c \
+  misc/__p__commode.c \
   misc/__p__fmode.c \
   misc/__p__wcmdln.c \
   misc/_create_locale.c \
@@ -267,6 +268,7 @@ src_msvcrtarm32=\
   $(src_msvcrt) \
   misc/__p___argv.c \
   misc/__p__acmdln.c \
+  misc/__p__commode.c \
   misc/__p__fmode.c \
   misc/__p__wcmdln.c \
   misc/_getpid.c \
@@ -359,6 +361,7 @@ src_msvcrtarm64=\
   math/arm64/truncf.S \
   misc/__p___argv.c \
   misc/__p__acmdln.c \
+  misc/__p__commode.c \
   misc/__p__fmode.c \
   misc/__p__wcmdln.c \
   misc/_getpid.c \
@@ -368,6 +371,7 @@ src_msvcr80_64=\
   $(src_msvcrt_common) \
   misc/__p___argv.c \
   misc/__p__acmdln.c \
+  misc/__p__commode.c \
   misc/__p__fmode.c \
   misc/__p__wcmdln.c
 
diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index bea6c04a2..b730dc479 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/crt/crtexe.c
@@ -50,7 +50,7 @@ extern void _fpreset (void);
 #define SPACECHAR _T(' ')
 #define DQUOTECHAR _T('\"')
 
-extern int * __MINGW_IMP_SYMBOL(_commode);
+int *__cdecl __p__commode(void);
 
 #undef _fmode
 extern int _fmode;
@@ -142,7 +142,7 @@ pre_c_init (void)
 __set_app_type (_CONSOLE_APP);
 
   * __p__fmode() = _fmode;
-  * __MINGW_IMP_SYMBOL(_commode) = _commode;
+  * __p__commode() = _commode;
 
 #ifdef WPRFLAG
   _wsetargv();
diff --git a/mingw-w64-crt/misc/__p__commode.c 
b/mingw-w64-crt/misc/__p__commode.c
new file mode 100644
index 0..bd79f5af7
--- /dev/null
+++ b/mingw-w64-crt/misc/__p__commode.c
@@ -0,0 +1,17 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+
+#include <_mingw.h>
+
+extern int * __MINGW_IMP_SYMBOL(_commode);
+
+int *__cdecl __p__commode(void);
+int *__cdecl __p__commode(void)
+{
+return __MINGW_IMP_SYMBOL(_commode);
+}
+
+typeof(__p__commode) *__MINGW_IMP_SYMBOL(__p__commode) = __p__commode;
-- 
2.17.1



___
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] crt: Remove a leftover declaration of __MINGW_IMP_SYMBOL(_fmode)

[Martin Storsjö]

This became unused in 2e64b9e4537d564478f17b873b2f655f518325ed.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-crt/crt/crtexe.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index 361afd23a..528957542 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/crt/crtexe.c
@@ -50,7 +50,6 @@ extern void _fpreset (void);
 #define SPACECHAR _T(' ')
 #define DQUOTECHAR _T('\"')
 
-extern int * __MINGW_IMP_SYMBOL(_fmode);
 extern int * __MINGW_IMP_SYMBOL(_commode);
 
 #undef _fmode
-- 
2.17.1



___
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] crt: Fix the initialization of the _commode variable

[Martin Storsjö]

In pre_c_init, there's a statement intending to set the value of the
_commode variable in the CRT to the value of the _commode variable
defined in the local module (with a default fallback in libmingw32.a),
like this:

  * __MINGW_IMP_SYMBOL(_commode) = _commode;

However, due to the earlier _commode define,
  #define _commode (* __MINGW_IMP_SYMBOL(_commode))
the assignment statement evaluates to a no-op assigment. Fix this
by removing the define (and the duplicate declaration of
__MINGW_IMP_SYMBOL(_commode).)

Normally that whole assignment is optimized out altogether - but if
crtexe.c is built without optimization, the accesses to __imp__commode
are left intact.

This restores the intent of the code, initializing the CRT's _commode
variable, just like _fmode is initailized.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-crt/crt/crtexe.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index 528957542..bea6c04a2 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/crt/crtexe.c
@@ -54,8 +54,7 @@ extern int * __MINGW_IMP_SYMBOL(_commode);
 
 #undef _fmode
 extern int _fmode;
-extern int * __MINGW_IMP_SYMBOL(_commode);
-#define _commode (* __MINGW_IMP_SYMBOL(_commode))
+extern int _commode;
 extern int _dowildcard;
 
 extern _CRTIMP void __cdecl _initterm(_PVFV *, _PVFV *);
-- 
2.17.1



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

Re: [Mingw-w64-public] [PATCH 3/3] crt: Use __p__commode instead of __MINGW_IMP_SYMBOL(_commode) for initialization

[Martin Storsjö]

On Tue, 31 Mar 2020, Martin Storsjö wrote:


This matches what was done for _fmode in
2e64b9e4537d564478f17b873b2f655f518325ed. This fixes using a
crtexe.c built without optimizations with UCRT (and fixes UCRT
in general after the previous commit).

Signed-off-by: Martin Storsjö 
---
mingw-w64-crt/Makefile.am |  4 
mingw-w64-crt/crt/crtexe.c|  4 ++--
mingw-w64-crt/misc/__p__commode.c | 17 +
3 files changed, 23 insertions(+), 2 deletions(-)
create mode 100644 mingw-w64-crt/misc/__p__commode.c


This patchset was also OK'd by Jacek on irc - will push later today.

// Martin

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

Re: [Mingw-w64-public] [PATCH 8/9] winstorecompat: allow building with code that needs codeGeneration capability

[Martin Storsjö]

On Fri, 24 Apr 2020, Martin Storsjö wrote:

From when I implemented this in lld, I remember that it looked like there was 
an intention that the linker would reference the symbol 
_pei386_runtime_relocator (code in ld.bfd that tries to do that), to force 
pulling in the whole mechanism - but doing that wasn't really enough as is.


It would, at least, require changing crt/pseudo-reloc.c to add a 
_CRTALLOC(".CRT$") constructor for doing the fixup without being 
explicitly called.


So far in lld, I didn't implement that bit (trying to reference 
_pei386_runtime_relocator when we see that we need pseudo relocs).


I think, faintly, that it wasn't trivial to do it, due to how the lld code is 
structured. First it loads object files to satisfy all undefined symbols. 
When that's done, it tries to fix up all relocations, at which point it 
realizes it needs pseudo relocs for this. At that point, it would then need 
to go back to add another undefined reference to _pei386_runtime_relocator 
and iterate on loading more object files until there's no more undefined 
references again - and that'd be rather messy in that code base.


So for now, I didn't implement that aspect, as mingw-w64-crt currently calls 
_pei386_runtime_relocator unconditionally.


I tried looking into this again, and the main blocker isn't lld code 
itself (it should, after all, be fairly straightforward to implement 
this).


The issue seems to be that ld.bfd has the intention to do this - reference 
the symbol _pei386_runtime_relocator if it ends up using pseudo relocs. 
But if _pei386_runtime_relocator isn't already linked in due to a direct 
dependency pulling it in, this just ends up with an undefined reference, 
like this:


ertr01.o:(.rdata+0x0): undefined reference to `_pei386_runtime_relocator'

(This is the name of a linker synthesized object file - not one of the 
real ones from the toolchain.)


So to go down this route, we'd need to fix this issue in ld.bfd (going 
back to pull in more object files, when we realize we need pseudo relocs), 
and in lld, before we could decouple this bit.


To test that setup, apply 
https://martin.st/temp/0001-crt-Use-a-constructor-to-process-the-pseudo-relocati.patch
on mingw-w64, and then e.g. try to build 
https://github.com/mstorsjo/llvm-mingw/blob/master/test/autoimport-lib.c 
and 
https://github.com/mstorsjo/llvm-mingw/commit/5a70c3cb783a82416773cfbb94b24a568134e73c.


// Martin

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

Re: [Mingw-w64-public] [PATCH 4/9] winstorecompat: handle LoadLibraryA alongside LoadLibraryW

[Martin Storsjö]

On Mon, 27 Apr 2020, Jacek Caban wrote:


On 27.04.2020 11:46, Steve Lhomme wrote:

On 2020-04-24 14:44, Jacek Caban wrote:

On 24.04.2020 13:43, Steve Lhomme wrote:

It's needed by:
- __delayLoadHelper2() in mingwex



I'm not sure what are the exact compatibility considerations here, but for 
win8+ builds we could just use LdrResolveDelayLoadedAPI and make 
__delayLoadHelper2 just a thin wrapper. See how Wine handles it:


https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winecrt0/delay_load.c#l38 

If we consider UCRT builds to be win8+, we could do the same for UCRT 
builds.


I tried to play with that. But in the end that means building mingwex that 
can only be used with win8+ or not pass the store. 



We would need to move __delayLoadHelper2 to be defined in msvcrt importlib 
first. Then we could use different implementation for different crts. UCRT 
could use LdrResolveDelayLoadedAPI, but other msvcrt version could keep using 
the existing implementation.


Wasn't LdrResolveDelayLoadedAPI only available since Win 8? UCRT is 
runnable on Win 7, and I don't think we want to drop support for that 
combination. (Not that most users use delay loading, but anyway...)


// Martin



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

Re: [Mingw-w64-public] [PATCH 8/9] winstorecompat: allow building with code that needs codeGeneration capability

[Martin Storsjö]

On Mon, 27 Apr 2020, Jacek Caban wrote:


On 27.04.2020 12:10, Martin Storsjö wrote:

On Fri, 24 Apr 2020, Martin Storsjö wrote:

From when I implemented this in lld, I remember that it looked like there 
was an intention that the linker would reference the symbol 
_pei386_runtime_relocator (code in ld.bfd that tries to do that), to force 
pulling in the whole mechanism - but doing that wasn't really enough as 
is.


It would, at least, require changing crt/pseudo-reloc.c to add a 
_CRTALLOC(".CRT$") constructor for doing the fixup without being 
explicitly called.


So far in lld, I didn't implement that bit (trying to reference 
_pei386_runtime_relocator when we see that we need pseudo relocs).


I think, faintly, that it wasn't trivial to do it, due to how the lld code 
is structured. First it loads object files to satisfy all undefined 
symbols. When that's done, it tries to fix up all relocations, at which 
point it realizes it needs pseudo relocs for this. At that point, it would 
then need to go back to add another undefined reference to 
_pei386_runtime_relocator and iterate on loading more object files until 
there's no more undefined references again - and that'd be rather messy in 
that code base.


So for now, I didn't implement that aspect, as mingw-w64-crt currently 
calls _pei386_runtime_relocator unconditionally.


I tried looking into this again, and the main blocker isn't lld code itself 
(it should, after all, be fairly straightforward to implement this).


The issue seems to be that ld.bfd has the intention to do this - reference 
the symbol _pei386_runtime_relocator if it ends up using pseudo relocs. But 
if _pei386_runtime_relocator isn't already linked in due to a direct 
dependency pulling it in, this just ends up with an undefined reference, 
like this:


ertr01.o:(.rdata+0x0): undefined reference to 
`_pei386_runtime_relocator'


(This is the name of a linker synthesized object file - not one of the real 
ones from the toolchain.)


So to go down this route, we'd need to fix this issue in ld.bfd (going back 
to pull in more object files, when we realize we need pseudo relocs), and 
in lld, before we could decouple this bit. 



Oh, I see, thanks for looking at it and sorry for misleading.


No problem - it would indeed be very nice if this actually worked like it 
seems like it was intended to. I'd put it somewhere (rather far back) on 
my todo list, that it would be nice to make ld.bfd and ld.lld behave that 
way...


// Martin

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

Re: [Mingw-w64-public] [PATCH 8/9] winstorecompat: allow building with code that needs codeGeneration capability

[Martin Storsjö]

On Fri, 24 Apr 2020, Martin Storsjö wrote:


On Fri, 24 Apr 2020, Steve Lhomme wrote:


By default winstorecompat is built without the need for this capability.

VirtualProtect may be mapped to VirtualProtectFromApp but only if the app 
has

the codeGeneration capability. It is needed when compiling UNIX code with
relocatable sections that are relocated at runtime.


More precisely, it's used by the code for fixing up pseudo relocations.

Even if we do this mapping to VirtualProtectFromApp, the code in 
"mark_section_writable" won't actually work with VirtualProtectFromApp, 
because it tries to set the permission PAGE_EXECUTE_READWRITE.


Right now, the mark_section_writable tries to change the protection on a 
whole section at a time (e.g. in practice do it once for the whole .text 
section). But to make it work with VirtualProtectFromApp, one would have to 
change the permission from PAGE_EXECUTE_READ, to PAGE_READWRITE, do the 
fixups, and back to PAGE_EXECUTE_READ. But as the code that is executing 
right now also lives in the same text section, it would stop itself from 
running. So to make that work, it would be necessary to make the code in this 
file be placed in a different section (with the same properties as .text) - 
or do more granular calls to VirtualProtectFromApp, on a page level (and hope 
that none of the pseudo relocations happen to be in the same page as the code 
that fixes them up).


Actually - VirtualProtectFromApp will most probably work fine for these 
cases. If LLVM thinks a variable reference might be from another DLL (i.e. 
the variable definition isn't visible within the same translation unit), 
it will redirect all the accesses via a .refptr. stub. This means 
that at runtime, it won't need to do any fixups in the .text section, only 
in .rdata. So in practice, with code built by LLVM, it will only need to 
do VirtualProtect on .rdata, which should be fine.


But avoiding the whole feature is safest and sanest in general - I just 
sent a patch for implementing --disable-runtime-pseudo-reloc in LLD.


// Martin

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

Re: [Mingw-w64-public] [PATCH v3 10/10] winstorecompat: add libwinstorecompatapp to use with libwindowsapp

[Martin Storsjö]

On Mon, 27 Apr 2020, Steve Lhomme wrote:


The original libwinstorecompat is designed to be used with libmincore.

- _beginthread _beginthreadex _endthread _endthreadex are allowed
- CreateEventW is allowed
- CreateMutexW is allowed
- CreateSemaphoreW is allowed
- InitializeCriticalSection is allowed
- GetFileAttributes is allowed
- WaitForSingleObject is allowed
- GetTickCount is allowed
- SetUnhandledExceptionFilter is allowed
- TerminateProcess is allowed
- IsDBCSLeadByteEx is allowed
- SetErrorMode is allowed
- GetACP is allowed
- LocalAlloc/LocalFree are allowed
- Sleep/SleepEx are allowed
- SetFilePointer is allowed
- Tls functions are allowed
- GetConsoleOutputCP is allowed

https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis

To select the set of API's allowed by this library, define WINSTORECOMPAT
and build with _WIN32_WINNT >= _WIN32_WINNT_WIN10.
---
.../winstorecompat/Makefile.am| 25 ++-
1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/mingw-w64-libraries/winstorecompat/Makefile.am 
b/mingw-w64-libraries/winstorecompat/Makefile.am
index a1f79947..5cc71cd8 100644
--- a/mingw-w64-libraries/winstorecompat/Makefile.am
+++ b/mingw-w64-libraries/winstorecompat/Makefile.am
@@ -2,7 +2,8 @@ AUTOMAKE_OPTIONS = foreign subdir-objects

AM_CFLAGS = -Wall -Wstrict-aliasing=2 -pedantic

-lib_LIBRARIES = libwinstorecompat.a
+lib_LIBRARIES = libwinstorecompat.a \
+  libwinstorecompatapp.a


I'd still like this to be named e.g. winstorecompatuwp instead of -app.

Other than that, I don't think I have any objections to the other patches 
in the set - but I'd like to hear Jacek's ack as well.


// Martin


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

Re: [Mingw-w64-public] [PATCH v3 09/10] crt: compile the DLL Delay Loading code in delayimp

[Martin Storsjö]

On Mon, 27 Apr 2020, Steve Lhomme wrote:


The library already existed for projects correctly using it, but the actual
code was in libmingw32.
There is also a configure option to enable delay loading support (off by
default). So It's only built when it's enabled.
---
mingw-w64-crt/Makefile.am | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)


What's the practical motivation for this? There was an issue with this 
code using LoadLibraryA, while only LoadLibraryW is handled by 
winstorecompat?


If the codebase wasn't using delayimp before, it wouldn't have been linked 
in, right? And if it uses it, we'd still have to provide LoadLibraryA or 
make the delayimp code use LoadLibraryW directly.


Also commit message nitpick: I'd write it more like "crt: Move the DLL 
delay loading code to libdelayimp.a".


Jacek, Wine uses delayloaded DLLs a lot - does it use -ldelayimp properly? 
Or does it entirely use its own implementation of the helper function 
nowadays?


// Martin



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

Re: [Mingw-w64-public] [PATCH v3 09/10] crt: compile the DLL Delay Loading code in delayimp

[Martin Storsjö]

On Mon, 27 Apr 2020, Steve Lhomme wrote:


The library already existed for projects correctly using it, but the actual
code was in libmingw32.


So practically, this will most probably break all projects that use the 
feature, as they most probably haven't added -ldelayimp - as they haven't 
needed so far.



There is also a configure option to enable delay loading support (off by
default). So It's only built when it's enabled.


No, we should keep building the delayimp helper library regardless of that 
option.


That option controls whether a separate delayimport version of all import 
libraries are built. (They don't seem to be installed though - if they 
did, it'd inflate the size of the installation quite a bit as well.)


The concept of a separate delayimport library only exists with binutils - 
llvm-dlltool doesn't implement that option, and with lld (with msvc style 
import libs, which is what llvm-dlltool generates) you use the normal 
import libraries, just pass a separate option for linking a specific 
library in delayimport mode.


So for llvm based tools, we can't enable the --enable-delay-import-libs 
option as it is right now, but we'd still need libdelayimp.a.


And for binutils based tools, even if you don't enable that option (and 
even if you did, you didn't get those files installed), users may have 
cases where they just generate the delayimport libraries from a specific 
def file, without building the whole crt that way.


// Martin



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

Re: [Mingw-w64-public] [PATCH] crt: Don't use __mingw_init_ehandler on toolchains using SEH.

[Martin Storsjö]

On Thu, 23 Apr 2020, Jacek Caban wrote:


Signed-off-by: Jacek Caban 
---
mingw-w64-crt/crt/crt_handler.c | 2 +-
mingw-w64-crt/crt/crtdll.c  | 4 +++-
mingw-w64-crt/crt/crtexe.c  | 4 ++--
3 files changed, 6 insertions(+), 4 deletions(-)


LGTM too.

// Martin



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

Re: [Mingw-w64-public] [PATCH] crt: Remove the vestigial gs_support.c

[Martin Storsjö]

On Thu, 23 Apr 2020, Jacek Caban wrote:


Hi Martin,

This patch looks right to me. If it never really worked, backward 
compatibility is not an issue. If someone wants those features, using UCRT 
seems to be the right answer.


Ok - if there's no objections to it, I'd go ahead and push this one - as 
long as nobody is tagging a new release soon, we have time to revisit it 
in the highly unlikely event that it actually causes some issues.


// Martin



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

Re: [Mingw-w64-public] [PATCH 4/9] winstorecompat: handle LoadLibraryA alongside LoadLibraryW

[Martin Storsjö]

On Fri, 24 Apr 2020, Steve Lhomme wrote:


It's needed by:
- __delayLoadHelper2() in mingwex
- WspiapiLoad() in ws2_32
---
mingw-w64-headers/include/winbase.h  |  3 +--
.../winstorecompat/src/LoadLibraryW.c| 16 ++--
2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/mingw-w64-headers/include/winbase.h 
b/mingw-w64-headers/include/winbase.h
index 0dc07826..c83b84cb 100644
--- a/mingw-w64-headers/include/winbase.h
+++ b/mingw-w64-headers/include/winbase.h
@@ -1524,6 +1524,7 @@ extern "C" {
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || 
defined(WINSTORECOMPAT)
#define LoadLibrary __MINGW_NAME_AW(LoadLibrary)
  WINBASEAPI HMODULE WINAPI LoadLibraryW (LPCWSTR lpLibFileName);
+  WINBASEAPI HMODULE WINAPI LoadLibraryA (LPCSTR lpLibFileName);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
  WINBASEAPI HANDLE WINAPI OpenMutexA (DWORD dwDesiredAccess, WINBOOL 
bInheritHandle, LPCSTR lpName);
@@ -1537,7 +1538,6 @@ extern "C" {
#endif
  WINBASEAPI HANDLE WINAPI OpenFileMappingA (DWORD dwDesiredAccess, WINBOOL 
bInheritHandle, LPCSTR lpName);
  WINBASEAPI DWORD WINAPI GetLogicalDriveStringsA (DWORD nBufferLength, LPSTR 
lpBuffer);
-  WINBASEAPI HMODULE WINAPI LoadLibraryA (LPCSTR lpLibFileName);

#ifndef UNICODE
#define OpenMutex OpenMutexA
@@ -1549,7 +1549,6 @@ extern "C" {
#endif

#define CreateWaitableTimer __MINGW_NAME_AW(CreateWaitableTimer)
-#define LoadLibrary __MINGW_NAME_AW(LoadLibrary)


What happens to this define here? I don't see why it should be removed, 
that'd break any caller that calls it without suffix.



diff --git a/mingw-w64-libraries/winstorecompat/src/LoadLibraryW.c 
b/mingw-w64-libraries/winstorecompat/src/LoadLibraryW.c
index 633cbd24..39296572 100644
--- a/mingw-w64-libraries/winstorecompat/src/LoadLibraryW.c
+++ b/mingw-w64-libraries/winstorecompat/src/LoadLibraryW.c
@@ -25,8 +25,7 @@
#define _WIN32_WINNT 0x602 /* LoadPackagedLibrary is Win8 APP Family */

#define LoadLibraryW __LoadLibraryW
-#include 
-#include 
+#include 
#undef LoadLibraryW



Is the change of included files intentional (why?) or just a random 
collateral change?


Wouldn't the same define/undef procedure be needed as for LoadLibraryW 
here?



HMODULE WINAPI LoadLibraryW(LPCWSTR lpFileName)
@@ -34,8 +33,21 @@ HMODULE WINAPI LoadLibraryW(LPCWSTR lpFileName)
return LoadPackagedLibrary(lpFileName, 0);
}

+WINBASEAPI HMODULE WINAPI LoadLibraryA (LPCSTR lpFileName)
+{
+int len = MultiByteToWideChar(GetACP(), 0, lpFileName, -1, NULL, 0);
+if (len == 0)
+return NULL;
+
+wchar_t out[len];
+MultiByteToWideChar(GetACP(), 0, lpFileName, -1, out, len);
+return LoadLibraryW(out);


What do we think about VLAs here? All compilers support it so it should be 
fine that way, but I'd generally avoid using them anyway...


Can MultiByteToWideChar return negative values? Even if it would be 
documented that it can't, I'd at least add a check for it, before I use 
that as a VLA length.


// Martin



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

Re: [Mingw-w64-public] [PATCH 8/9] winstorecompat: allow building with code that needs codeGeneration capability

[Martin Storsjö]

On Fri, 24 Apr 2020, Jacek Caban wrote:


On 24.04.2020 13:43, Steve Lhomme wrote:

By default winstorecompat is built without the need for this capability.

VirtualProtect may be mapped to VirtualProtectFromApp but only if the app 
has

the codeGeneration capability. It is needed when compiling UNIX code with
relocatable sections that are relocated at runtime.

VirtualProtectFromApp is only available if compiled to target win10.



We should be able to avoid depending on VirtualProtect for builds that don't 
use pseudo relocs. My understanding is that linker will emit a call to 
_pei386_runtime_relocator if it uses pseudo relocations. We, however, 
unconditionally call it anyway from entry points. My guess would be that we 
do that for some backward compatibility. Could someone familiar with 
internals confirm that? If my understanding is correct, we could remove 
unconditional calls and depend on linker to emit them.


From when I implemented this in lld, I remember that it looked like there 
was an intention that the linker would reference the symbol 
_pei386_runtime_relocator (code in ld.bfd that tries to do that), to force 
pulling in the whole mechanism - but doing that wasn't really enough as 
is.


It would, at least, require changing crt/pseudo-reloc.c to add a 
_CRTALLOC(".CRT$") constructor for doing the fixup without being 
explicitly called.


So far in lld, I didn't implement that bit (trying to reference 
_pei386_runtime_relocator when we see that we need pseudo relocs).


I think, faintly, that it wasn't trivial to do it, due to how the lld code 
is structured. First it loads object files to satisfy all undefined 
symbols. When that's done, it tries to fix up all relocations, at which 
point it realizes it needs pseudo relocs for this. At that point, it would 
then need to go back to add another undefined reference to 
_pei386_runtime_relocator and iterate on loading more object files until 
there's no more undefined references again - and that'd be rather messy in 
that code base.


So for now, I didn't implement that aspect, as mingw-w64-crt currently 
calls _pei386_runtime_relocator unconditionally.


So I'd just recommend a plain stub VirtualProtect that returns an error 
here...


I should probably at least implement --disable-runtime-pseudo-reloc in 
lld, so you get a link time error if the code base needs pseudo relocs, 
instead of having it fail mysteriously at runtime.


// Martin




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

Re: [Mingw-w64-public] [PATCH 8/9] winstorecompat: allow building with code that needs codeGeneration capability

[Martin Storsjö]

On Fri, 24 Apr 2020, Steve Lhomme wrote:


By default winstorecompat is built without the need for this capability.

VirtualProtect may be mapped to VirtualProtectFromApp but only if the app has
the codeGeneration capability. It is needed when compiling UNIX code with
relocatable sections that are relocated at runtime.


More precisely, it's used by the code for fixing up pseudo relocations.

Even if we do this mapping to VirtualProtectFromApp, the code in 
"mark_section_writable" won't actually work with VirtualProtectFromApp, 
because it tries to set the permission PAGE_EXECUTE_READWRITE.


Right now, the mark_section_writable tries to change the protection on a 
whole section at a time (e.g. in practice do it once for the whole .text 
section). But to make it work with VirtualProtectFromApp, one would have 
to change the permission from PAGE_EXECUTE_READ, to PAGE_READWRITE, do the 
fixups, and back to PAGE_EXECUTE_READ. But as the code that is executing 
right now also lives in the same text section, it would stop itself from 
running. So to make that work, it would be necessary to make the code in 
this file be placed in a different section (with the same properties as 
.text) - or do more granular calls to VirtualProtectFromApp, on a page 
level (and hope that none of the pseudo relocations happen to be in the 
same page as the code that fixes them up).




diff --git a/mingw-w64-libraries/winstorecompat/src/VirtualProtect.c 
b/mingw-w64-libraries/winstorecompat/src/VirtualProtect.c
index 88fd06bc..5801a69d 100644
--- a/mingw-w64-libraries/winstorecompat/src/VirtualProtect.c
+++ b/mingw-w64-libraries/winstorecompat/src/VirtualProtect.c
@@ -22,6 +22,10 @@
DEALINGS IN THE SOFTWARE.
*/

+#ifdef HAVE_CONFIG_H
+# include "config.h"
+#endif
+
#define VirtualProtect __VirtualProtect
#include 
#include 
@@ -30,8 +34,17 @@

BOOL WINAPI VirtualProtect(LPVOID lpAddress, SIZE_T dwSize, DWORD flNewProtect, 
PDWORD lpflOldProtect)
{
+#if defined(HAVE_CODE_GENERATION) && _WIN32_WINNT >= _WIN32_WINNT_WIN10
+ULONG OldProtection;
+BOOL res = VirtualProtectFromApp(lpAddress, dwSize, flNewProtect,
+ lpflOldProtect ?  : NULL);


For code simplicity, one could also skip the conditional here and always 
pass 


// Martin



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

Re: [Mingw-w64-public] [PATCH 8/9] winstorecompat: allow building with code that needs codeGeneration capability

[Martin Storsjö]

On Fri, 24 Apr 2020, Steve Lhomme wrote:


On 2020-04-24 14:58, Martin Storsjö wrote:

On Fri, 24 Apr 2020, Steve Lhomme wrote:

diff --git a/mingw-w64-libraries/winstorecompat/src/VirtualProtect.c 
b/mingw-w64-libraries/winstorecompat/src/VirtualProtect.c

index 88fd06bc..5801a69d 100644
--- a/mingw-w64-libraries/winstorecompat/src/VirtualProtect.c
+++ b/mingw-w64-libraries/winstorecompat/src/VirtualProtect.c
@@ -22,6 +22,10 @@
    DEALINGS IN THE SOFTWARE.
*/

+#ifdef HAVE_CONFIG_H
+# include "config.h"
+#endif
+
#define VirtualProtect __VirtualProtect
#include 
#include 
@@ -30,8 +34,17 @@

BOOL WINAPI VirtualProtect(LPVOID lpAddress, SIZE_T dwSize, DWORD 
flNewProtect, PDWORD lpflOldProtect)

{
+#if defined(HAVE_CODE_GENERATION) && _WIN32_WINNT >= _WIN32_WINNT_WIN10
+    ULONG OldProtection;
+    BOOL res = VirtualProtectFromApp(lpAddress, dwSize, flNewProtect,
+ lpflOldProtect ?  
: NULL);


For code simplicity, one could also skip the conditional here and always 
pass 


The idea is to get the same error as if we were calling VirtualProtect. 
They both have this in the documentation:


"If this parameter is NULL or does not point to a valid variable, the 
function fails."


Oh, I see - then it makes perfect sense - sorry for the noise!

// Martin

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

Re: [Mingw-w64-public] [PATCH 9/9] winstorecompat: add libwinstorecompatapp to use with libwindowsapp

[Martin Storsjö]

On Fri, 24 Apr 2020, Steve Lhomme wrote:


The original libwinstorecompat is designed to be used with libmincore.

- _beginthread _beginthreadex _endthread _endthreadex are allowed
- CreateEventW is allowed
- CreateMutexW is allowed
- CreateSemaphoreW is allowed
- InitializeCriticalSection is allowed
- GetFileAttributes is allowed
- WaitForSingleObject is allowed
- GetTickCount is allowed
- SetUnhandledExceptionFilter is allowed
- TerminateProcess is allowed
- IsDBCSLeadByteEx is allowed
- SetErrorMode is allowed
- GetACP is allowed
- LocalAlloc/LocalFree are allowed
- Sleep/SleepEx are allowed
- SetFilePointer is allowed
- Tls functions are allowed
- CryptGenRandom and related are allowed
- GetConsoleOutputCP is allowed

https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis

To select the set of API's allowed by this library, define WINSTORECOMPATAPP
(similar to WINSTORECOMPAT used to add API's to mincore)
These API's become visible in headers when WINSTORECOMPATAPP is defined.

--
alternatively the same WINSTORECOMPAT could be used and have a different effect
depending on the value of _WIN32_WINNT:
- _WIN32_WINNT < 10 means using mincore and the current additional API's in 
winstorecompat
- _WIN32_WINNT >= 10 means using windowsapp and the new additional API's in 
winstorecompatapp
---
mingw-w64-headers/include/errhandlingapi.h|  2 +-
mingw-w64-headers/include/fileapi.h   |  2 +-
mingw-w64-headers/include/libloaderapi.h  |  2 +-
mingw-w64-headers/include/memoryapi.h |  2 +-
mingw-w64-headers/include/shlobj.h|  2 +-
.../include/threadpoollegacyapiset.h  |  2 +-
mingw-w64-headers/include/winbase.h   |  4 ++--
.../winstorecompat/Makefile.am| 24 ++-
8 files changed, 31 insertions(+), 9 deletions(-)



diff --git a/mingw-w64-libraries/winstorecompat/Makefile.am 
b/mingw-w64-libraries/winstorecompat/Makefile.am
index a1f79947..38514c4e 100644
--- a/mingw-w64-libraries/winstorecompat/Makefile.am
+++ b/mingw-w64-libraries/winstorecompat/Makefile.am
@@ -2,7 +2,8 @@ AUTOMAKE_OPTIONS = foreign subdir-objects

AM_CFLAGS = -Wall -Wstrict-aliasing=2 -pedantic

-lib_LIBRARIES = libwinstorecompat.a
+lib_LIBRARIES = libwinstorecompat.a \
+  libwinstorecompatapp.a


This looks great in general, to me.

Just a bikeshed-y question - why the suffix -app for this case? The old 
win8 case was similarly an "app" scenario (you'd have WINAPI_FAMILY_APP in 
that case as well), so to me, the suffix "app" doesn't distinguish 10 from 
8.


Not sure what a better suffix would be though - uwp, 10?

// Martin



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

Re: [Mingw-w64-public] [PATCH 8/9] winstorecompat: allow building with code that needs codeGeneration capability

[Martin Storsjö]

On Fri, 24 Apr 2020, Jacek Caban wrote:


On 24.04.2020 15:09, Martin Storsjö wrote:


So for now, I didn't implement that aspect, as mingw-w64-crt currently 
calls _pei386_runtime_relocator unconditionally.


So I'd just recommend a plain stub VirtualProtect that returns an error 
here...


I should probably at least implement --disable-runtime-pseudo-reloc in lld, 
so you get a link time error if the code base needs pseudo relocs, instead 
of having it fail mysteriously at runtime. 



I see, we need it then. With --disable-runtime-pseudo-reloc, we could place 
.drectve in compat lib to disable it without user interaction.


Hmm, that would be rather nice and neat. However, there's a fixed set of 
options that are allowed to be in .drectve, 
https://github.com/llvm/llvm-project/blob/master/lld/COFF/Driver.cpp#L370-L410.


It is possible to add exceptions to it with options that link.exe doesn't 
support though if a good reason can be argued for it though. When 
implementing --disable-runtime-pseudo-reloc in the MinGW frontend, a 
corresponding (lld private) link.exe style option is going to be needed as 
well, but I'm not sure if they'd want that one explicitly allowed in 
.drectve.


// Martin

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

Re: [Mingw-w64-public] [PATCH] crt: Split out __report_gsfailure from gs_support.c

[Martin Storsjö]

On Thu, 23 Apr 2020, Steve Lhomme wrote:


Hi,

I prefer this approach as it shouldn't break apps relying on the 
internal MSVC symbol, however wrong that sounds.


__security_init_cookie is documented (and it's OK to call it in some 
cases) but __report_gsfailure doesn't seem to be.


FWIW, I tested the other patch (removing all of gs_support) on my nightly 
build, and there were no issues with it - but I don't build a very diverse 
or large test set, just VLC for desktop, latest Qt and a bunch of smaller 
multimedia projects.


// Martin



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

Re: [Mingw-w64-public] [PATCH] crt: add a dummy RtlAddFunctionTable when linking with windowsapp

[Martin Storsjö]

On Wed, 22 Apr 2020, Steve Lhomme wrote:


I am not very familiar with all of this, so don't take my word for it.
It seems the .pdata section to be a Windows only thing
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-pdata-section
I don't know if gcc/clang/ld/lld handles it or mingw (I would bet on the 
former).


In mingw the RtlAddFunctionTable call is only done in libmingw32.a for:
#if defined(__x86_64__) && !defined(_MSC_VER)

So only x64 targets would need a hack.

I see three possibilities
- do not do this call anymore
- do a libmingw32app
- do a winstorecompatapp

#1 would be the cleanest/less invasive solution. Looking at the 
__mingw_init_ehandler() the call is only done if the PE headers doesn't 
have a .pdata section. If which case would the compiler/linker not 
generate such a section ?


The compiler doesn't generate .pdata sections if e.g. building with a 
toolchain that defaults to SJLJ exception handling - that's a common (not 
the most common, but still occurring) configuration.


Like I already wrote once, this is a catch-all handler for catching SEH 
exceptions (like crashes and similar) within the mingw code, if SEH isn't 
used for the C++ exception handling mechanism. As far as I see it, it's a 
nice-to-have feature for those cases.


Don't suggest just removing code, that someone else has contributed with 
some intention, just because you don't understand it.


I don't say that this code is vital for every use case - it isn't, but 
suggesting to flat out remove it just because you don't understand isn't 
nice. And it's not necessarily a very clean thing, but whoever wrote it 
surely had a reason.


Between #2 and #3 I would prefer #2 as for non-x64 the libmingw32app 
could just be the same (same binary installed twice) as libmingw32. And 
it doesn't force the caller to use winstorecompat (and -DWINSTORECOMPAT) 
whenever using libwindowsapp.a.


For this particular case, I don't see why a user would have to build 
anything with -DWINSTORECOMPAT - just linking to winstorecompat should be 
enough.


When linking with lld, just adding -lwinstorecompat should be enough - lld 
looks through libraries in the order they're specified. ld.bfd (GNU ld) 
works differently though, so there you'd have to make sure that 
-lwinstorecompat is specified after -lmingw32 (but for those cases, you 
already now need to edit and use custom spec files anyway).



The problem of #2 is that -lmingw32 is hardcoded in Clang:
https://github.com/llvm-project/clang/blob/master/lib/Driver/ToolChains/MinGW.cpp#L63
Same thing with the gcc spec files:
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/crtdll.h#L36
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/mingw32.h#L165

So instead of having libming32.a and libming32app.a we maybe have 
libming32.a and app/libming32.a
The linker have to use -L.../libs/app before -L.../libs to make sure it 
uses this one. That seems doable in Martin's mingw32uwp toolchain. 
Others using windowsapp would have to do it manually.


Out of these two, I _very_ much would prefer #3. I want as much common 
code shared between all the potential cases (different crt variants, 
desktop/uwp, etc) instead of making more tweaked versions of them.


To you it might seem that adding another copy is "just" a little bit extra 
work, but it does add up. And making it different between architectures 
(just a copy instead of adding one function) wouldn't be helping, that 
also creates even more mess and maintainance burden. The fewer differenes 
between architectures, the better.


So far, the intent has been that the base components (crt*.o, 
libmingw32.a, libmingwex.a) are common and work for all CRT choices, and 
the same should go for desktop/app subsets if winstorecompat is used.


// Martin



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

Re: [Mingw-w64-public] [PATCH] crt: add a dummy RtlAddFunctionTable when linking with windowsapp

[Martin Storsjö]

On Wed, 22 Apr 2020, Jacek Caban wrote:


On 22.04.2020 12:47, Martin Storsjö wrote:


The compiler doesn't generate .pdata sections if e.g. building with a 
toolchain that defaults to SJLJ exception handling - that's a common (not 
the most common, but still occurring) configuration.


Like I already wrote once, this is a catch-all handler for catching SEH 
exceptions (like crashes and similar) within the mingw code, if SEH isn't 
used for the C++ exception handling mechanism. As far as I see it, it's a 
nice-to-have feature for those cases. 



How reliably can we detect the condition when if compiler will generate 
.pdata sections? If it's something like #ifdef __SEH__, then we could 
probably use that to limit use of this code inside mingw32 to relevant 
builds. It would solve this problem as well and reduce statically linked code 
for users that don't need it. It would behave differently than now if other 
compiler is used to build crt and use the app using it, but such configs are 
shaky anyway.


I think with both Clang and GCC, that you should be able to check for 
__SEH__, yes.


That has a fairly high chance of retaining the intended behaviour - so 
that's good.


There's of course a chance that my guess for what the code was supposed to 
do is wrong, but in any case, if __SEH__ is defined, then both GCC and 
Clang do generate .pdata, and the checks would make the code no-op in any 
case.


(There's also potential corner cases of using a compiler that uses SEH for 
C++ exceptions, but building with -fno-unwind-tables (so that plain C code 
doesn't generate unwind info), so it would be possible to construct a 
SEH-configured executable without .pdata, but that's really splitting 
hairs and not a configuration I think we need to consider.)



// Martin

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

Re: [Mingw-w64-public] [PATCH] crt: add a dummy RtlAddFunctionTable when linking with windowsapp

[Martin Storsjö]

On Wed, 22 Apr 2020, Steve Lhomme wrote:


On 2020-04-22 12:47, Martin Storsjö wrote:

On Wed, 22 Apr 2020, Steve Lhomme wrote:


I am not very familiar with all of this, so don't take my word for it.
It seems the .pdata section to be a Windows only thing

https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-pdata-section 


I don't know if gcc/clang/ld/lld handles it or mingw (I would bet on 
the former).


In mingw the RtlAddFunctionTable call is only done in libmingw32.a for:
#if defined(__x86_64__) && !defined(_MSC_VER)

So only x64 targets would need a hack.

I see three possibilities
- do not do this call anymore
- do a libmingw32app
- do a winstorecompatapp

#1 would be the cleanest/less invasive solution. Looking at the 
__mingw_init_ehandler() the call is only done if the PE headers 
doesn't have a .pdata section. If which case would the compiler/linker 
not generate such a section ?


The compiler doesn't generate .pdata sections if e.g. building with a 
toolchain that defaults to SJLJ exception handling - that's a common 
(not the most common, but still occurring) configuration.


Like I already wrote once, this is a catch-all handler for catching SEH 
exceptions (like crashes and similar) within the mingw code, if SEH 
isn't used for the C++ exception handling mechanism. As far as I see it, 
it's a nice-to-have feature for those cases.


Don't suggest just removing code, that someone else has contributed with 
some intention, just because you don't understand it.


Indeed, I do not understand it, that's why we're having this discussion.

I don't say that this code is vital for every use case - it isn't, but 
suggesting to flat out remove it just because you don't understand isn't 
nice. And it's not necessarily a very clean thing, but whoever wrote it 
surely had a reason.


Between #2 and #3 I would prefer #2 as for non-x64 the libmingw32app 
could just be the same (same binary installed twice) as libmingw32. 
And it doesn't force the caller to use winstorecompat (and 
-DWINSTORECOMPAT) whenever using libwindowsapp.a.


For this particular case, I don't see why a user would have to build 
anything with -DWINSTORECOMPAT - just linking to winstorecompat should 
be enough.


Indeed, the app doesn't need -DWINSTORECOMPAT, only when compiling 
libmingw32.a


Now I don't understand.

You're saying you prefer #2, because with #3 you'd need to define 
-DWINSTORECOMPAT. And now you're saying that in order to compile 
libmingw32app.a which is what you want in #2, you would have to compile it 
with -DWINSTORECOMPAT?


Out of these two, I _very_ much would prefer #3. I want as much common 
code shared between all the potential cases (different crt variants, 
desktop/uwp, etc) instead of making more tweaked versions of them.


It's just odd that if the user links with -lwindowsapp (s)he would also 
need to add -lwinstorecompatapp when it could be totally hidden. If it 
can be hidden and still rely on -lwinstorecompatapp then fine.


The way I see it, -lwindowsapp is a replacement for -lkernel32 and others 
- including only the functions that are available there. Then 
winstorecompat.a contains stubs for forbidden functions (but it can also 
include minimal reimplementations of some functions - case in point 
EnumProcessModules). You'd probably practically use them together, but 
they are logically separate in my mind. But this isn't a hard blocker for 
bundling those object files into libwindowsapp.a - it's just that we 
already have these functions in a separate library, winstorecompat, and we 
could just build a different subset of it for the win10 case.


In any case, if it's necessary, one could consider also adding 
-lwinstorecompat via my uwp compiler wrappers, if winstorecompat is 
supposed to be used together with -lwindowsapp.


To you it might seem that adding another copy is "just" a little bit 
extra work, but it does add up. And making it different between 
architectures (just a copy instead of adding one function) wouldn't be 
helping, that also creates even more mess and maintainance burden. The 
fewer differenes between architectures, the better.


So far, the intent has been that the base components (crt*.o, 
libmingw32.a, libmingwex.a) are common and work for all CRT choices, and 
the same should go for desktop/app subsets if winstorecompat is used.


What about programs built with `-Wl,--no-seh` ? Like VLC for example.


I have absolutely _zero_ idea what you are trying to say here. And do you 
even know what the -Wl,--no-seh flag does, because I totally fail to see 
what connection it has to the discussion at hand here?


// Martin


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

Re: [Mingw-w64-public] [PATCH] crt: add a dummy RtlAddFunctionTable when linking with windowsapp

[Martin Storsjö]

On Wed, 22 Apr 2020, Steve Lhomme wrote:


On 2020-04-22 14:34, Martin Storsjö wrote:

On Wed, 22 Apr 2020, Steve Lhomme wrote:


On 2020-04-22 12:47, Martin Storsjö wrote:

On Wed, 22 Apr 2020, Steve Lhomme wrote:


I am not very familiar with all of this, so don't take my word for it.
It seems the .pdata section to be a Windows only thing



https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-pdata-section 




I don't know if gcc/clang/ld/lld handles it or mingw (I would bet on 
the former).


In mingw the RtlAddFunctionTable call is only done in libmingw32.a for:
#if defined(__x86_64__) && !defined(_MSC_VER)

So only x64 targets would need a hack.

I see three possibilities
- do not do this call anymore
- do a libmingw32app
- do a winstorecompatapp

#1 would be the cleanest/less invasive solution. Looking at the 
__mingw_init_ehandler() the call is only done if the PE headers 
doesn't have a .pdata section. If which case would the 
compiler/linker not generate such a section ?


The compiler doesn't generate .pdata sections if e.g. building with a 
toolchain that defaults to SJLJ exception handling - that's a common 
(not the most common, but still occurring) configuration.


Like I already wrote once, this is a catch-all handler for catching 
SEH exceptions (like crashes and similar) within the mingw code, if 
SEH isn't used for the C++ exception handling mechanism. As far as I 
see it, it's a nice-to-have feature for those cases.


Don't suggest just removing code, that someone else has contributed 
with some intention, just because you don't understand it.


Indeed, I do not understand it, that's why we're having this discussion.

I don't say that this code is vital for every use case - it isn't, 
but suggesting to flat out remove it just because you don't 
understand isn't nice. And it's not necessarily a very clean thing, 
but whoever wrote it surely had a reason.


Between #2 and #3 I would prefer #2 as for non-x64 the libmingw32app 
could just be the same (same binary installed twice) as libmingw32. 
And it doesn't force the caller to use winstorecompat (and 
-DWINSTORECOMPAT) whenever using libwindowsapp.a.


For this particular case, I don't see why a user would have to build 
anything with -DWINSTORECOMPAT - just linking to winstorecompat 
should be enough.


Indeed, the app doesn't need -DWINSTORECOMPAT, only when compiling 
libmingw32.a


Now I don't understand.

You're saying you prefer #2, because with #3 you'd need to define 
-DWINSTORECOMPAT.


No. I said I prefer #2 (app/libmingw32.a) because it doesn't force 
adding an extra library to link with. You just need to proper path to 
the libraries.
Whereas with #3 you need to put -lwinstorecompatapp and -lmingw32 in the 
right order.


No, with lld you don't need to put -lwinstorecompat after -lmingw32 - only 
with ld.bfd, and with gcc you need a custom spec file anyway.


And now you're saying that in order to compile 
libmingw32app.a which is what you want in #2, you would have to compile 
it with -DWINSTORECOMPAT?


I think so, in order to unhide then hidden API it calls, in order to 
later use windowstorecompatapp. So in the end that ends up compiling 
mingw32 twice anyway. The regular one and the one only calling allowed 
things and others via whatever winstorecompatapp does.


I don't see how that would be necessary. The normal libmingw32.a built 
with all APIs accessible would see the normal declaration of the 
problematic function, just as if it was built with 
-DWINAPI_FAMILY=WINAPI_FAMILY_APP -DWINSTORECOMPAT. You get the same 
declaration of it in either case.


The only thing that matters is if some lib (either the same or another 
one) then ends up providing an implementation of it.


I really do not want to have a separate copy of libmingw32.a.

Out of these two, I _very_ much would prefer #3. I want as much 
common code shared between all the potential cases (different crt 
variants, desktop/uwp, etc) instead of making more tweaked versions 
of them.


It's just odd that if the user links with -lwindowsapp (s)he would 
also need to add -lwinstorecompatapp when it could be totally hidden. 
If it can be hidden and still rely on -lwinstorecompatapp then fine.


The way I see it, -lwindowsapp is a replacement for -lkernel32 and 
others - including only the functions that are available there. Then 
winstorecompat.a contains stubs for forbidden functions (but it can also 
include minimal reimplementations of some functions - case in point 
EnumProcessModules). You'd probably practically use them together, but 
they are logically separate in my mind. But this isn't a hard blocker 
for bundling those object files into libwindowsapp.a - it's just that we 
already have these functions in a separate library, winstorecompat, and 
we could just build a different subset of it for the win10 case.


The library (with a different subset of forbidden functions) exist. But 
it exist for the host app which is fre

Re: [Mingw-w64-public] [PATCH] winstorecompat: add libwindowsappcompat to use with libwindowsapp

[Martin Storsjö]

On Wed, 29 Apr 2020, Steve Lhomme wrote:


The original libwinstorecompat is designed to be used with libmincore.

- CreateEventW is allowed
- CreateMutexW is allowed
- CreateSemaphoreW is allowed
- InitializeCriticalSection is allowed
- GetFileAttributes is allowed
- WaitForSingleObject is allowed
- GetTickCount is allowed
- SetUnhandledExceptionFilter is allowed
- TerminateProcess is allowed
- IsDBCSLeadByteEx is allowed
- SetErrorMode is allowed
- GetACP is allowed
- LocalAlloc/LocalFree are allowed
- Sleep/SleepEx are allowed
- SetFilePointer is allowed
- Tls functions are allowed
- GetConsoleOutputCP is allowed

https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis

To select the set of API's allowed by this library, define WINSTORECOMPAT
and build with _WIN32_WINNT >= _WIN32_WINNT_WIN10.
---
.../winstorecompat/Makefile.am| 24 ++-
1 file changed, 23 insertions(+), 1 deletion(-)


This patch looks ok to me - naming things is hard, especially as one 
doesn't know how the upstreams names will evolve (e.g. if there's a new 
different iteration of things later, will the name "windowsapp" still 
refer to that, or will it be something else at that point).


// Martin



___
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: Don't use the 'inline' attribute on Clang when targeting C89

[Martin Storsjö]

Move the defined(__clang__) into the condition next to
__MINGW_GNUC_PREREQ(4, 3) (which doesn't trigger for clang, as clang
presents itself as GCC 4.2).

This fixes building with Clang in C89 mode where we can't use the
'inline' attribute as such, but need to use __inline__ instead.

(This doesn't trigger when building without optimizations, because
__NO_INLINE__ is defined in those cases.)

Signed-off-by: Martin Storsjö 
---
 mingw-w64-headers/crt/_mingw.h.in | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mingw-w64-headers/crt/_mingw.h.in 
b/mingw-w64-headers/crt/_mingw.h.in
index c1caae633..01eff66fa 100644
--- a/mingw-w64-headers/crt/_mingw.h.in
+++ b/mingw-w64-headers/crt/_mingw.h.in
@@ -86,8 +86,7 @@ limitations in handling dllimport attribute.  */
 #elif defined(_MSC_VER)
 # define __CRT_INLINE __inline
 #else
-# if ( __MINGW_GNUC_PREREQ(4, 3)  &&  __STDC_VERSION__ >= 199901L) \
- || (defined (__clang__))
+# if ((__MINGW_GNUC_PREREQ(4, 3) || defined(__clang__)) && __STDC_VERSION__ >= 
199901L)
 #  define __CRT_INLINE extern inline __attribute__((__gnu_inline__))
 # else
 #  define __CRT_INLINE extern __inline__
-- 
2.17.1



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

Re: [Mingw-w64-public] [PATCH v3 05/10] winstorecompat: provide GetUserName

[Martin Storsjö]

On Mon, 27 Apr 2020, Jacek Caban wrote:


On 27.04.2020 19:55, Jean-Baptiste Kempf wrote:


On Mon, Apr 27, 2020, at 19:40, Jacek Caban wrote:

On 27.04.2020 16:31, Steve Lhomme wrote:

It's needed by:
- getlogin() in mingwex


Could we prohibit getlogin() on non-desktop in headers instead?

Or call directly GetEnvironment directly?



If it works on all relevant Windows versions, that sounds good.


Well, GetEnvironment isn't an exact replacement - you could (fairly) 
easily have an environment where USERNAME is missing or overwritten by 
something else. So I wouldn't like an unconditional replacement of 
GetUserName with GetEnvironment("USERNAME").


I think the current one approach is fine - if GetUserName is missing and 
something happens to call it, GetEnvironment is a decent fallback.


I presume that this only comes up now as Steve has tried to weed out all 
potentially forbidden function calls from libmingw*.a - even if no libs 
actually ever called getlogin() to begin with (because otherwise it would 
have been an issue with VLC/WinStore even on 8.x). So alternatively we 
could just ignore this for now - but I think the current approach is fine 
as well.


// Martin



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

Re: [Mingw-w64-public] [PATCH v3 09/10] crt: compile the DLL Delay Loading code in delayimp

[Martin Storsjö]

On Tue, 28 Apr 2020, Steve Lhomme wrote:


On 2020-04-27 19:22, Martin Storsjö wrote:

On Mon, 27 Apr 2020, Steve Lhomme wrote:

The library already existed for projects correctly using it, but the 
actual

code was in libmingw32.
There is also a configure option to enable delay loading support (off by
default). So It's only built when it's enabled.
---
mingw-w64-crt/Makefile.am | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)


What's the practical motivation for this? There was an issue with this 
code using LoadLibraryA, while only LoadLibraryW is handled by 
winstorecompat?


That's the original issue, yes. I build the whole CRT in winstore mode 
to detect forbidden calls.


If the codebase wasn't using delayimp before, it wouldn't have been 
linked in, right? 


Correct. But having code in mingwex that may not pass winstore 
certification without a workaround (apart from not being able to use 
delayed loading) doesn't seem right. Especially when the normal way is 
to use a separate library and there's even on for the winstore case.


Well moving it from mingwex to delayimp doesn't change a thing - either 
nobody calls it and it isn't an issue, or someone uses delay imports and 
it is still an issue, even if the code is in a different static library.


And if it uses it, we'd still have to provide 
LoadLibraryA or make the delayimp code use LoadLibraryW directly.


As said, providing a generic LoadLibraryA may not work because of 
varying codepages. The fact that this delay loading API is ANSI only is 
odd enough. It might not work with weird DLL names.


Should we use CP_ACP, CP_OEMCP, CP_UTF8, GetACP() to get the wide char 
name of the DLL ?


CP_ACP I would say - that's how the system would interpret the filename 
passed in LoadLibraryA anyway, no?


// Martin

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

Re: [Mingw-w64-public] [PATCH v3 09/10] crt: compile the DLL Delay Loading code in delayimp

[Martin Storsjö]

On Tue, 28 Apr 2020, Steve Lhomme wrote:

And if it uses it, we'd still have to provide 
LoadLibraryA or make the delayimp code use LoadLibraryW directly.


As said, providing a generic LoadLibraryA may not work because of 
varying codepages. The fact that this delay loading API is ANSI only is 
odd enough. It might not work with weird DLL names.


Also for the record, regarding this detail: The DLL name fields in the 
normal .idata sections are also just 8 bit filenames, without any 
indication about what codepage it is written in. And the delayimport 
mechanism operates on very similar data structures - so it's not strange 
to me that it uses LoadLibraryA.


// Martin



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

Re: [Mingw-w64-public] [PATCH v3 09/10] crt: compile the DLL Delay Loading code in delayimp

[Martin Storsjö]

On Tue, 28 Apr 2020, Steve Lhomme wrote:

It's currently impossible to build a mingwex that is guaranteed to pass 
the winstore certification.


You can't certify a static library. And even for the "known good" version 
of the library, it will contain calls to forbidden functions, that are 
stubbed out by the winstorecompat library.


And with the LoadLibraryA function in the winstorecompat library, as I 
think definitely should be there, this is no issue.


These files are one of the reasons and should have never been there in 
the first place.


Moving the code in the separate library is one step in a saner 
direction. It doesn't claim to solve the issue of delayed loading in 
winstore apps.


So this patch is just a - completely - orthogonal bit compared to the rest 
of the patchset, correctness for the sake of correctness, not intending to 
fix any use of forbidden apis. That's probably ok, but propose it as such 
then.


// Martin



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

Re: [Mingw-w64-public] [PATCH] Enable __USE_MINGW_ANSI_STDIO for C99 and C++11 when not using UCRT

[Martin Storsjö]

On Wed, 29 Apr 2020, Liu Hao wrote:


在 2020/4/28 15:22, Pali Rohár 写道:

C99 and C++11 standards requires printf ll modifier for long long type but
it does not work in WinXP system msvcrt.dll. It requires at least library
msvcr80.dll.

So when gcc is invoked with --std=c99 (or new) or --std=c++11 (or new) ansi
stdio macro needs to be enabled for printf ll modifier support.

It is already enabled for _ISOC99_SOURCE but apparently new version of gcc
set only __STDC_VERSION__ and __cplusplus numeric macros to version of
C/C++ standard. So enable __USE_MINGW_ANSI_STDIO based on them.

Also GNU version of printf supports ll modifier in C mode, so enable
__USE_MINGW_ANSI_STDIO also for _GNU_SOURCE C mode (not only C++).
---
 mingw-w64-headers/crt/_mingw.h.in | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)



Thanks, this patch should be safe to apply.  I pushed it to master.


This patch broke compiling mingw-w64-crt (with clang, but I'm fairly sure 
the same happens with gcc as well:


../misc/wcstof.c:20:7: error: redefinition of 'wcstof' float wcstof (const 
wchar_t * __restrict__ wcs, wchar_t ** __restrict__ wcse)
  ^ 
/opt/llvm-mingw/i686-w64-mingw32/include/stdlib.h:569:17: 
note: previous definition is here
  float __cdecl wcstof(const wchar_t * __restrict__ _Str,wchar_t ** 
__restrict__ _EndPtr){

^
1 error generated.


// Martin

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

Re: [Mingw-w64-public] [PATCH] Enable __USE_MINGW_ANSI_STDIO for C99 and C++11 when not using UCRT

[Martin Storsjö]

On Thu, 30 Apr 2020, Liu Hao wrote:


在 2020/4/30 13:17, Martin Storsjö 写道:


This patch broke compiling mingw-w64-crt (with clang, but I'm fairly
sure the same happens with gcc as well:

../misc/wcstof.c:20:7: error: redefinition of 'wcstof' float wcstof
(const wchar_t * __restrict__ wcs, wchar_t ** __restrict__ wcse)
  ^ /opt/llvm-mingw/i686-w64-mingw32/include/stdlib.h:569:17: note:
previous definition is here
  float __cdecl wcstof(const wchar_t * __restrict__ _Str,wchar_t **
__restrict__ _EndPtr){
    ^
1 error generated.




Oops, sorry for the trouble. The attached patch should fix this issue.


Thanks - this patch looks good to me on a quick glance.


(I would like to know whether there are any better macros than `_CRTBLD`
to check against.)


There's probably a lots of different ways of achieving the same, but 
_CRTBLD is fine with me.


// Martin

___
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: Sync changes from stdlib.h to wchar.h from a2feff99e4f

[Martin Storsjö]

This define machinery is duplicated betwen the headers, and should
stay in sync.

Also sync the ifdef surrounding the wcstof and wcstod functions.

This fixes building the crt for arm platforms.

On x86 platforms, the intrin headers end up including mm_malloc.h,
which includes stdlib.h implcitly - which makes stdlib.h end up
included before wchar.h, even if stdlib.h isn't explicitly included.
That explains why the build succeeded on one architecture but not
others.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-headers/crt/wchar.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-headers/crt/wchar.h b/mingw-w64-headers/crt/wchar.h
index 18e618d33..d9227efb3 100644
--- a/mingw-w64-headers/crt/wchar.h
+++ b/mingw-w64-headers/crt/wchar.h
@@ -9,7 +9,7 @@
 #include 
 #include 
 
-#if __USE_MINGW_ANSI_STDIO && !defined (__USE_MINGW_STRTOX)
+#if __USE_MINGW_ANSI_STDIO && !defined (__USE_MINGW_STRTOX) && 
!defined(_CRTBLD)
 #define __USE_MINGW_STRTOX 1
 #endif
 
@@ -1251,7 +1251,7 @@ int vsnwprintf (wchar_t *__stream, size_t __n, const 
wchar_t *__format, __builti
   float __cdecl __mingw_wcstof(const wchar_t * __restrict__ nptr, wchar_t ** 
__restrict__ endptr);
   long double __cdecl __mingw_wcstold(const wchar_t * __restrict__, wchar_t ** 
__restrict__);
 
-#if __USE_MINGW_ANSI_STDIO
+#if __USE_MINGW_STRTOX
   __mingw_ovr
   double __cdecl wcstod(const wchar_t * __restrict__ _Str,wchar_t ** 
__restrict__ _EndPtr){
 return __mingw_wcstod(_Str,_EndPtr);
-- 
2.17.1



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

Re: [Mingw-w64-public] [PATCH] headers: Sync changes from stdlib.h to wchar.h from a2feff99e4f

[Martin Storsjö]

On Thu, 30 Apr 2020, Liu Hao wrote:


在 04/30/2020 07:30 PM, Martin Storsjö 写道:

This define machinery is duplicated betwen the headers, and should
stay in sync.

Also sync the ifdef surrounding the wcstof and wcstod functions.

This fixes building the crt for arm platforms.

On x86 platforms, the intrin headers end up including mm_malloc.h,
which includes stdlib.h implcitly - which makes stdlib.h end up
included before wchar.h, even if stdlib.h isn't explicitly included.
That explains why the build succeeded on one architecture but not
others.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-headers/crt/wchar.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)




This patch looks good to me.


Thanks, pushed. Now my build for all 4 architectures is passing again.

// Martin

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

Re: [Mingw-w64-public] [PATCH] crt: add a dummy RtlAddFunctionTable when linking with windowsapp

[Martin Storsjö]

On Tue, 21 Apr 2020, Jacek Caban wrote:


Hi Steve,

On 21.04.2020 16:40, Steve Lhomme wrote:

windowsapp is meant to replace kernel32, user32, shell32, etc. These older
libraries should be used with it to avoid linking to entries that should 
not

be used in that context (apps working on all win10 devices)
https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis

When linking with just windowsapp (and a C runtime) there's a call in
mingw32 to RtlAddFunctionTable(). In practice this call has no effect as 
the

.pdata of the section takes predecence.
https://pmeerw.net/blog/programming/RtlAddFunctionTable.html

This function call is not allowed an not needed in this context, so we just
forward the call to an internal dummy version.


Well, the intent of this function call is to synthesize something 
corresponding to .pdata, with one huge RUNTIME_FUNCTION for each 
executable section in the module, if the executable didn't have any .pdata 
of its own, as a global catch-all.


I wouldn't say "is not needed in this context" - it's more like an 
optional nice-to-have feature which is totally ok to skip if the runtime 
doesn't allow it.



winstorecompat also has a similar function but it should not be used with
windowsapp as some functions replaced by winstorecompat are now allowed in
windowsapp.


Hm, wouldn't it make more sense to build separate versions of 
winstorecompat, one for 8.x and one for 10?


Not strictly opposed to adding things like into libwindowsapp.a, but as we 
have winstorecompat _exactly_ for this purpose, I'd prefer to keep such 
dummy fallbacks there, and then build things like libwinstorecompat10.a if 
there's a different set of functions to stub out.


We already have similar hacks in the tree already, so if others like it I 
won't stay in a way of the patch, but I think that this could be done better. 
We should be able to avoid the call in the first place. One way to achieve 
that would be to move crt_handler.c to msvcrt importlib. Then we can 
customize that for windowsapp crt and avoid problematic functions.


I don't think particularly that is a good idea here. windowsapp is a 
replacement for kernel32 and a few other dlls, but the CRT in this case is 
libucrt.a (which links against the api-ms-win-crt-*) which also can be 
used for normal desktop things.


// Martin



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

Re: [Mingw-w64-public] [PATCH] crt: add a dummy RtlAddFunctionTable when linking with windowsapp

[Martin Storsjö]

On Tue, 21 Apr 2020, Jacek Caban wrote:


On 21.04.2020 19:40, Martin Storsjö wrote:


I don't think particularly that is a good idea here. windowsapp is a 
replacement for kernel32 and a few other dlls, but the CRT in this case is 
libucrt.a (which links against the api-ms-win-crt-*) which also can be used 
for normal desktop things. 



What I'm suggesting would result in a separated crt, say libucrtapp.a, which 
you would use instead of libucrt.a. On build system side, we'd just use 
exactly the same sources as libucrt.a, except that we'd have a macro that 
we'd use to disable unavailable nice-to-have features like this.



The same thing can be done with other stubs from the compat code.


Sure, that'd work - although I'm not entirely convinced yet - the existing 
winstorecompat approach is rather nice (and modular) so if that'd work, 
I'd prefer sticking with that until there's a case where it doesn't.


// Martin

___
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: Split out __report_gsfailure from gs_support.c

[Martin Storsjö]

Modern CRTs already provide this function, so move the existing
implementation to the CRT specific import library for msvcrt and
msvcr80 (as it's present since msvcr90).

While the implementation in gs_support.c is incomplete and not
actually of any use with MinGW compilers, user code could,
potentially, have gotten to rely on these symbols (__security_cookie,
__security_init_cookie and __report_gsfailure) actually being
defined, so do keep them, but move __report_gsfailure to the
CRT import library.

In practice, nothing ever references the __report_gsfailure symbol
so it doesn't really end up getting linked in from the import library
(unless it was part of the same object file as __security_init_cookie).

Signed-off-by: Martin Storsjö 
---
This is one out of two alternative ways of handling the potentially
problematic function __report_gsfailure, which calls a number of
functions that aren't available for UWP apps - the other alternative
being to remove all those altogether as they aren't really functional
and don't serve much of a purpose anyway.
---
 mingw-w64-crt/Makefile.am  |  6 +++
 mingw-w64-crt/crt/gs_report.c  | 97 ++
 mingw-w64-crt/crt/gs_support.c | 82 
 3 files changed, 103 insertions(+), 82 deletions(-)
 create mode 100644 mingw-w64-crt/crt/gs_report.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 0f882ae2a..c521c50d1 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -177,6 +177,7 @@ src_msvcrt_common=\
 
 src_msvcrt=\
   $(src_msvcrt_common) \
+  crt/gs_report.c \
   misc/_configthreadlocale.c \
   misc/invalid_parameter_handler.c \
   misc/output_format.c \
@@ -368,8 +369,13 @@ src_msvcrtarm64=\
   misc/_getpid.c \
   stdio/gets.c
 
+src_msvcr80_32=\
+  $(src_msvcrt_common) \
+  crt/gs_report.c
+
 src_msvcr80_64=\
   $(src_msvcrt_common) \
+  crt/gs_report.c \
   misc/__p___argv.c \
   misc/__p__acmdln.c \
   misc/__p__commode.c \
diff --git a/mingw-w64-crt/crt/gs_report.c b/mingw-w64-crt/crt/gs_report.c
new file mode 100644
index 0..bb8995861
--- /dev/null
+++ b/mingw-w64-crt/crt/gs_report.c
@@ -0,0 +1,97 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+
+#ifndef WIN32_LEAN_AND_MEAN
+#define WIN32_LEAN_AND_MEAN
+#endif
+#define WIN32_NO_STATUS
+#include /* abort () */
+#include 
+#undef  WIN32_NO_STATUS
+#include   /* STATUS macros */
+#ifdef _WIN64
+#include 
+#endif
+
+/* Externals.  */
+
+typedef LONG NTSTATUS; /* same as in ntdef.h / winternl.h */
+
+#define UNW_FLAG_NHANDLER   0x0
+
+static EXCEPTION_RECORD GS_ExceptionRecord;
+static CONTEXT GS_ContextRecord;
+
+static const EXCEPTION_POINTERS GS_ExceptionPointers = {
+  _ExceptionRecord,_ContextRecord
+};
+
+extern UINT_PTR __security_cookie;
+extern UINT_PTR __security_cookie_complement;
+
+
+#if defined(__GNUC__) /* wrap msvc intrinsics onto gcc builtins */
+#undef  _ReturnAddress
+#undef  _AddressOfReturnAddress
+#define _ReturnAddress()   __builtin_return_address(0)
+#define _AddressOfReturnAddress()  __builtin_frame_address (0)
+#endif /* __GNUC__ */
+
+__declspec(noreturn) void __cdecl __report_gsfailure (ULONG_PTR);
+
+#define UNUSED_PARAM(x) { x = x; }
+__declspec(noreturn) void __cdecl
+__report_gsfailure (ULONG_PTR StackCookie)
+{
+  volatile UINT_PTR cookie[2] __MINGW_ATTRIB_UNUSED;
+#if defined(_WIN64) && !defined(__aarch64__)
+  ULONG64 controlPC, imgBase, establisherFrame;
+  PRUNTIME_FUNCTION fctEntry;
+  PVOID hndData;
+
+  RtlCaptureContext (_ContextRecord);
+  controlPC = GS_ContextRecord.Rip;
+  fctEntry = RtlLookupFunctionEntry (controlPC, , NULL);
+  if (fctEntry != NULL)
+{
+  RtlVirtualUnwind (UNW_FLAG_NHANDLER, imgBase, controlPC, fctEntry,
+   _ContextRecord, , , NULL);
+}
+  else
+#endif /* _WIN64 */
+{
+#if defined(__x86_64__) || defined(_AMD64_)
+  GS_ContextRecord.Rip = (ULONGLONG) _ReturnAddress();
+  GS_ContextRecord.Rsp = (ULONGLONG) _AddressOfReturnAddress() + 8;
+#elif defined(__i386__) || defined(_X86_)
+  GS_ContextRecord.Eip = (DWORD) _ReturnAddress();
+  GS_ContextRecord.Esp = (DWORD) _AddressOfReturnAddress() + 4;
+#elif defined(__arm__) || defined(_ARM_)
+  GS_ContextRecord.Pc = (DWORD) _ReturnAddress();
+  GS_ContextRecord.Sp = (DWORD) _AddressOfReturnAddress() + 4;
+#endif /* _WIN64 */
+}
+
+#if defined(__x86_64__) || defined(_AMD64_)
+  GS_ExceptionRecord.ExceptionAddress = (PVOID) GS_ContextRecord.Rip;
+  GS_ContextRecord.Rcx = StackCookie;
+#elif defined(__i386__) || defined(_X86_)
+  GS_ExceptionRecord.ExceptionAddress = (PVOID) GS_ContextRecord.Eip;
+  GS_ContextRecord.Ecx = StackCookie;
+#elif defined(__arm__) || defined(_ARM_)
+  GS_ExceptionRecord.ExceptionAddress = (PVOID) GS_ContextR

[Mingw-w64-public] [PATCH] crt: Remove the vestigial gs_support.c

[Martin Storsjö]

This was a partial (but incomplete!) support for the MSVC stack
cookie handling (under the MSVC option /GS, similar to GCC and
Clang/MinGW's -fstack-protector-strong). This contained the
stack cookie itself and the init function, and the error reporting
function, but not the checking function (__security_check_cookie).
And these functions would only end up being called by code generated
by MSVC anyway.

Signed-off-by: Martin Storsjö 
---
This is one out of two alternative ways of handling the potentially
problematic function __report_gsfailure, which calls a number of
functions that aren't available for UWP apps - the other alternative
is to keep the functions but move __report_gsfailure to the msvcrt
import library, as more modern msvcrt versions, and ucrt, does provide
their own versions of the function - and in normal cases, nothing
references the symbol so it won't end up linked in (unless it's in
the same object file as __security_init_cookie).
---
 mingw-w64-crt/Makefile.am   |   2 +-
 mingw-w64-crt/crt/crtdll.c  |   1 -
 mingw-w64-crt/crt/crtexe.c  |   2 -
 mingw-w64-crt/crt/gs_support.c  | 154 
 mingw-w64-headers/crt/process.h |  10 ---
 5 files changed, 1 insertion(+), 168 deletions(-)
 delete mode 100644 mingw-w64-crt/crt/gs_support.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 0f882ae2a..86b0b0d73 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -115,7 +115,7 @@ src_libntoskrnl=libsrc/memcmp.c
 
 src_libmingw32=include/oscalls.h include/internal.h include/sect_attribs.h \
   crt/crt0_c.ccrt/dll_argv.c  crt/gccmain.c crt/natstart.c  
crt/pseudo-reloc-list.c  crt/wildcard.c \
-  crt/charmax.c   crt/crt0_w.c crt/dllargv.c   crt/gs_support.c  
crt/_newmode.c  crt/tlssup.c crt/xncommod.c \
+  crt/charmax.c   crt/crt0_w.c crt/dllargv.c   crt/_newmode.c  
crt/tlssup.c crt/xncommod.c \
   crt/cinitexe.c  crt/crt0_w.c crt/merr.c  crt/pesect.c  
crt/udllargc.c  crt/xthdloc.ccrt/CRT_fp10.c \
   crt/mingw_custom.c  crt/mingw_helpers.c  \
   crt/pseudo-reloc.c  crt/udll_argv.c  \
diff --git a/mingw-w64-crt/crt/crtdll.c b/mingw-w64-crt/crt/crtdll.c
index 6187f10d2..797c1beeb 100644
--- a/mingw-w64-crt/crt/crtdll.c
+++ b/mingw-w64-crt/crt/crtdll.c
@@ -156,7 +156,6 @@ DllMainCRTStartup (HANDLE hDllHandle, DWORD dwReason, 
LPVOID lpreserved)
   mingw_app_type = 0;
   if (dwReason == DLL_PROCESS_ATTACH)
 {
-  __security_init_cookie ();
 #ifdef __x86_64__
   __mingw_init_ehandler ();
 #endif
diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index b730dc479..f521b54cd 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/crt/crtexe.c
@@ -189,7 +189,6 @@ int WinMainCRTStartup (void)
 );
 #endif
   mingw_app_type = 1;
-  __security_init_cookie ();
   ret = __tmainCRTStartup ();
 #ifdef SEH_INLINE_ASM
   asm ("\tnop\n"
@@ -217,7 +216,6 @@ int mainCRTStartup (void)
 );
 #endif
   mingw_app_type = 0;
-  __security_init_cookie ();
   ret = __tmainCRTStartup ();
 #ifdef SEH_INLINE_ASM
   asm ("\tnop\n"
diff --git a/mingw-w64-crt/crt/gs_support.c b/mingw-w64-crt/crt/gs_support.c
deleted file mode 100644
index 0c6ac68cd..0
--- a/mingw-w64-crt/crt/gs_support.c
+++ /dev/null
@@ -1,154 +0,0 @@
-/**
- * This file has no copyright assigned and is placed in the Public Domain.
- * This file is part of the mingw-w64 runtime package.
- * No warranty is given; refer to the file DISCLAIMER.PD within this package.
- */
-
-#ifndef WIN32_LEAN_AND_MEAN
-#define WIN32_LEAN_AND_MEAN
-#endif
-#define WIN32_NO_STATUS
-#include /* abort () */
-#include 
-#undef  WIN32_NO_STATUS
-#include   /* STATUS macros */
-#ifdef _WIN64
-#include 
-#endif
-
-#ifdef _WIN64
-#define DEFAULT_SECURITY_COOKIE 0x2B992DDFA232ll
-#else
-#define DEFAULT_SECURITY_COOKIE 0xBB40E64E
-#endif
-
-/* Externals.  */
-
-typedef LONG NTSTATUS; /* same as in ntdef.h / winternl.h */
-
-#define UNW_FLAG_NHANDLER   0x0
-
-typedef union
-{
-  unsigned __int64 ft_scalar;
-  FILETIME ft_struct;
-} FT;
-
-static EXCEPTION_RECORD GS_ExceptionRecord;
-static CONTEXT GS_ContextRecord;
-
-static const EXCEPTION_POINTERS GS_ExceptionPointers = {
-  _ExceptionRecord,_ContextRecord
-};
-
-DECLSPEC_SELECTANY UINT_PTR __security_cookie = DEFAULT_SECURITY_COOKIE;
-DECLSPEC_SELECTANY UINT_PTR __security_cookie_complement = 
~(DEFAULT_SECURITY_COOKIE);
-
-void __cdecl __security_init_cookie (void);
-
-void __cdecl
-__security_init_cookie (void)
-{
-  UINT_PTR cookie;
-  FT systime = { 0, };
-  LARGE_INTEGER perfctr;
-
-  if (__security_cookie != DEFAULT_SECURITY_COOKIE)
-{
-  __security_cookie_complement = ~__security_cookie;
-  return;
-}
-
-  GetSystemTimeAsFileTime (_struct);
-#ifdef _WIN64
-  cookie = systime.ft_scalar;
-#else
-  cookie = systime.ft_struct.dwLowDateTime;
-  cookie ^= systime.ft_s

Re: [Mingw-w64-public] [PATCH] winstorecompat: Avoid warnings about redefining _WIN32_WINNT in the Win10 library

[Martin Storsjö]

On Tue, 12 May 2020, Steve Lhomme wrote:


OK.


Thanks, pushed.

Shouldn't the XP ones be removed completely ? Isn't XP the default value 
? Are lower versions still supported ?


Yeah, you're right, ones that only declare the XP version probably should 
be removed.


// Martin



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

Re: [Mingw-w64-public] [PATCH 2/2] crt/wchar: Copy wide stdio functions from

[Martin Storsjö]

On Sun, 17 May 2020, Liu Hao wrote:


Signed-off-by: Liu Hao 
---
mingw-w64-headers/crt/wchar.h | 20 
1 file changed, 20 insertions(+)

diff --git a/mingw-w64-headers/crt/wchar.h b/mingw-w64-headers/crt/wchar.h
index d9227efb..1dbb4630 100644
--- a/mingw-w64-headers/crt/wchar.h
+++ b/mingw-w64-headers/crt/wchar.h
@@ -509,6 +509,26 @@ extern FILE (* __MINGW_IMP_SYMBOL(_iob))[];/* A
pointer to an array of FILE */
/* __attribute__((__format__ (gnu_wprintf, 2, 0))) */
__MINGW_ATTRIB_NONNULL(2)
  int __cdecl __mingw_vswprintf(wchar_t * __restrict__ , const wchar_t
* __restrict__ ,va_list);
+/* __attribute__((__format__ (ms_wscanf, 2, 3))) */
__MINGW_ATTRIB_NONNULL(2)
+  int __cdecl __ms_swscanf(const wchar_t * __restrict__ _Src,const
wchar_t * __restrict__ _Format,...);
+/* __attribute__((__format__ (ms_wscanf, 1, 2))) */
__MINGW_ATTRIB_NONNULL(1)
+  int __cdecl __ms_wscanf(const wchar_t * __restrict__ _Format,...);
+/* __attribute__((__format__ (ms_wscanf, 2, 3))) */
__MINGW_ATTRIB_NONNULL(2)
+  int __cdecl __ms_fwscanf(FILE * __restrict__ _File,const wchar_t *
__restrict__ _Format,...);
+
+/* __attribute__((__format__ (ms_wprintf, 2, 3))) */
__MINGW_ATTRIB_NONNULL(2)
+  int __cdecl __ms_fwprintf(FILE * __restrict__ _File,const wchar_t *
__restrict__ _Format,...);
+/* __attribute__((__format__ (ms_wprintf, 1, 2))) */
__MINGW_ATTRIB_NONNULL(1)
+  int __cdecl __ms_wprintf(const wchar_t * __restrict__ _Format,...);
+/* __attribute__((__format__ (ms_wprintf, 2, 0)))
*/__MINGW_ATTRIB_NONNULL(2)
+  int __cdecl __ms_vfwprintf(FILE * __restrict__ _File,const wchar_t *
__restrict__ _Format,va_list _ArgList);
+/*__attribute__((__format__ (ms_wprintf, 1, 0))) */
__MINGW_ATTRIB_NONNULL(1)
+  int __cdecl __ms_vwprintf(const wchar_t * __restrict__
_Format,va_list _ArgList);
+/* __attribute__((__format__ (ms_wprintf, 2, 3))) */
__MINGW_ATTRIB_NONNULL(2)
+  int __cdecl __ms_swprintf(wchar_t * __restrict__ , const wchar_t *
__restrict__ , ...);
+/* __attribute__((__format__ (ms_wprintf, 2, 0))) */
__MINGW_ATTRIB_NONNULL(2)
+  int __cdecl __ms_vswprintf(wchar_t * __restrict__ , const wchar_t *
__restrict__ ,va_list);
+
#ifdef _UCRT
  int __cdecl __stdio_common_vswprintf(unsigned __int64 options,
wchar_t *str, size_t len, const wchar_t *format, _locale_t locale,
va_list valist);
  int __cdecl __stdio_common_vfwprintf(unsigned __int64 options, FILE
*file, const wchar_t *format, _locale_t locale, va_list valist);
--
2.26.2


Looks good as well - thanks!

// Martin



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

Re: [Mingw-w64-public] [PATCH 1/2] crt/stdio: Restore `__ms_vw*scanf` wrappers

[Martin Storsjö]

On Sun, 17 May 2020, Liu Hao wrote:


I thought I moved them somewhere in e46c5521375dd28, but I didn't. Sorry.

As these are not MSVCRT functions I decide not to keep them together with
others above.

Signed-off-by: Liu Hao 
---
mingw-w64-headers/crt/stdio.h | 3 +++
1 file changed, 3 insertions(+)

diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index 47afb355..d7beb27a 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -1263,6 +1263,9 @@ int vsnwprintf (wchar_t *__stream, size_t __n,
const wchar_t *__format, __builti
  int __cdecl swscanf(const wchar_t * __restrict__ _Src,const wchar_t *
__restrict__ _Format,...) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
  int __cdecl wscanf(const wchar_t * __restrict__ _Format,...)
__MINGW_ATTRIB_DEPRECATED_SEC_WARN;
#ifndef __NO_ISOCEXT  /* externs in libmingwex.a */
+  int __cdecl __ms_vwscanf (const wchar_t * __restrict__ , va_list);
+  int __cdecl __ms_vfwscanf (FILE * __restrict__ ,const wchar_t *
__restrict__ ,va_list);
+  int __cdecl __ms_vswscanf (const wchar_t * __restrict__ ,const
wchar_t * __restrict__ ,va_list);
   __mingw_ovr
  __MINGW_ATTRIB_NONNULL(2)
--
2.26.2


Looks ok (didn't test myself yet).

// Martin



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

Re: [Mingw-w64-public] [PATCH 2/2] crt/stdio: Add declaration for `__ms_*` aliases

[Martin Storsjö]

On Fri, 15 May 2020, Liu Hao wrote:


@@ -1214,9 +1263,6 @@ int vsnwprintf (wchar_t *__stream, size_t __n,
const wchar_t *__format, __builti
  int __cdecl swscanf(const wchar_t * __restrict__ _Src,const wchar_t *
__restrict__ _Format,...) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
  int __cdecl wscanf(const wchar_t * __restrict__ _Format,...)
__MINGW_ATTRIB_DEPRECATED_SEC_WARN;
#ifndef __NO_ISOCEXT  /* externs in libmingwex.a */
-  int __cdecl __ms_vwscanf (const wchar_t * __restrict__ , va_list);
-  int __cdecl __ms_vfwscanf (FILE * __restrict__ ,const wchar_t *
__restrict__ ,va_list);
-  int __cdecl __ms_vswscanf (const wchar_t * __restrict__ ,const
wchar_t * __restrict__ ,va_list);
   __mingw_ovr
  __MINGW_ATTRIB_NONNULL(2)


Why are these declarations removed without readding them anywhere else? 
They are used by inline functions right below.


To reproduce a failure, make a test.cpp that only includes stdio.h, and 
build it with g++ -std=gnu++98.


Also note that wchar.h has got matching declarations, so these bits should 
be updated in sync (or refactoreded to remove the duplication).


// Martin



___
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: Fix include order of fvec.h/ivec.h/dvec.h referring to each other

[Martin Storsjö]

Previously, these headers expanded properly if dvec.h was included
first, but not if fvec.h or ivec. were included first.

Move the cyclical includes last, so that the bits that these headers
are expected to declare are declared before the next level header
is included.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-headers/crt/fvec.h | 4 +++-
 mingw-w64-headers/crt/ivec.h | 3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-headers/crt/fvec.h b/mingw-w64-headers/crt/fvec.h
index 120ff96fe..48a343cbf 100644
--- a/mingw-w64-headers/crt/fvec.h
+++ b/mingw-w64-headers/crt/fvec.h
@@ -13,7 +13,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #if defined(_ENABLE_VEC_DEBUG)
@@ -249,5 +248,8 @@ inline int F32vec1ToInt(const F32vec1 )
 
 #endif /* #ifdef __SSE__ */
 #pragma pack(pop)
+
+#include 
+
 #endif
 #endif
diff --git a/mingw-w64-headers/crt/ivec.h b/mingw-w64-headers/crt/ivec.h
index 7e09ca57e..70e8c5f3e 100644
--- a/mingw-w64-headers/crt/ivec.h
+++ b/mingw-w64-headers/crt/ivec.h
@@ -13,7 +13,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #pragma pack(push,_CRT_PACKING)
@@ -51,6 +50,8 @@ public:
 
 #endif /* ifdef __SSE__ */
 
+#include 
+
 #endif
 #endif
 
-- 
2.17.1



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

Re: [Mingw-w64-public] [PATCH 8/9] winstorecompat: allow building with code that needs codeGeneration capability

[Martin Storsjö]

On Wed, 6 May 2020, Jacek Caban wrote:


On 06.05.2020 15:17, Martin Storsjö wrote:


That lld patch is approved now FWIW, but I realized I want to refine it a 
bit further.


I also came to think about another trick I implemented in lld - for the 
cases where the address is in a .refptr$ stub, lld can actually 
swap that out for the IAT entry, so for all such cases, there won't even be 
any pseudo relocations to fix up. There's only cases with e.g. global 
variables initialized to the address of an auto imported variable that 
can't be fixed.



That limits usefulness of pseudo relocs even more. I'm tempted to suggest a 
bit more drastic solution and disable them by default. Instead of 
--disable-*, add --enable-runtime-pseudo-relocs, which could also 
unconditionally (my understanding is that it should be easy on linker side 
with command argument) reference _pei386_runtime_relocator and we could 
revisit the idea of making its linkage conditional.


Tempting - but I'm a little hesitant, it's both a bit drastic, and 
probably still breaks a number of commonly compiled packages. Also the 
feature of merging .refptr stubs into IAT entries and skipping the pseudo 
relocs for those entries is LLD specific I think.


And finally, linking _pei386_runtime_relocator conditionally doesn't work 
properly with ld.bfd at the moment (with the logic where ld.bfd tries to 
force the function to be loaded, unsuccessfully).


I tried to implement that feature in lld now though, and it's doable but a 
little bit more messy (we have to finish linking of a lot of things before 
we can evaluate whether auto imports actually need pseudo relocs or not), 
at which point we'd need to load more object files for 
_pei386_runtime_relocator.


But if we'd get ld.bfd fixed to conditionally pull in 
_pei386_runtime_relocator when needed, we could consider making it 
conditional in mingw-w64 at some point in the future (maybe with a linker 
test in configure?).


In a world where --disable-pseudo-relocs is the default, and anybody 
adding --enable-pseudo-relocs would need to pass -u 
_pei386_runtime_relocator at the same time, that's not an issue though. 
But that's also a rather huge breaking change for the ecosystem in general 
(especially with two supported linkers).


// Martin

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

[Mingw-w64-public] [PATCH] winstorecompat: Forward VirtualProtect to VirtualProtectFromApp on windows 10

[Martin Storsjö]

From: Steve Lhomme 

VirtualProtectFromApp is a fully functional replacement for cases when
not needing to touch code sections, and for other cases, the call
should fail - just like the previous stub that failed unconditionally.

This should be enough for fixing up runtime pseudo relocations for
code generated by LLVM (and possibly by GCC on x86_64), where all
fixed up references either are in normal data sections, or in .refptr
stubs.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-libraries/winstorecompat/src/VirtualProtect.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/mingw-w64-libraries/winstorecompat/src/VirtualProtect.c 
b/mingw-w64-libraries/winstorecompat/src/VirtualProtect.c
index acccf6519..b02dc0cb7 100644
--- a/mingw-w64-libraries/winstorecompat/src/VirtualProtect.c
+++ b/mingw-w64-libraries/winstorecompat/src/VirtualProtect.c
@@ -30,8 +30,17 @@
 
 BOOL WINAPI VirtualProtect(LPVOID lpAddress, SIZE_T dwSize, DWORD 
flNewProtect, PDWORD lpflOldProtect)
 {
+#if _WIN32_WINNT >= _WIN32_WINNT_WIN10
+ULONG OldProtection;
+BOOL res = VirtualProtectFromApp(lpAddress, dwSize, flNewProtect,
+ lpflOldProtect ?  : NULL);
+if (lpflOldProtect)
+*lpflOldProtect = OldProtection;
+return res;
+#else /* _WIN32_WINNT < _WIN32_WINNT_WIN10 */
 SetLastError(ERROR_ACCESS_DENIED);
 return FALSE;
+#endif /* _WIN32_WINNT < _WIN32_WINNT_WIN10 */
 }
 
 #ifdef _X86_
-- 
2.17.1



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

Re: [Mingw-w64-public] [PATCH v3 10/10] winstorecompat: add libwinstorecompatapp to use with libwindowsapp

[Martin Storsjö]

On Tue, 28 Apr 2020, Jean-Baptiste Kempf wrote:




On Tue, Apr 28, 2020, at 10:28, Steve Lhomme wrote:

On 2020-04-27 19:23, Martin Storsjö wrote:
> On Mon, 27 Apr 2020, Steve Lhomme wrote:
> 
>> The original libwinstorecompat is designed to be used with libmincore.

>>
>> - _beginthread _beginthreadex _endthread _endthreadex are allowed
>> - CreateEventW is allowed
>> - CreateMutexW is allowed
>> - CreateSemaphoreW is allowed
>> - InitializeCriticalSection is allowed
>> - GetFileAttributes is allowed
>> - WaitForSingleObject is allowed
>> - GetTickCount is allowed
>> - SetUnhandledExceptionFilter is allowed
>> - TerminateProcess is allowed
>> - IsDBCSLeadByteEx is allowed
>> - SetErrorMode is allowed
>> - GetACP is allowed
>> - LocalAlloc/LocalFree are allowed
>> - Sleep/SleepEx are allowed
>> - SetFilePointer is allowed
>> - Tls functions are allowed
>> - GetConsoleOutputCP is allowed
>>
>> https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis
>>
>> To select the set of API's allowed by this library, define WINSTORECOMPAT
>> and build with _WIN32_WINNT >= _WIN32_WINNT_WIN10.
>> ---
>> .../winstorecompat/Makefile.am    | 25 ++-
>> 1 file changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/mingw-w64-libraries/winstorecompat/Makefile.am 
>> b/mingw-w64-libraries/winstorecompat/Makefile.am

>> index a1f79947..5cc71cd8 100644
>> --- a/mingw-w64-libraries/winstorecompat/Makefile.am
>> +++ b/mingw-w64-libraries/winstorecompat/Makefile.am
>> @@ -2,7 +2,8 @@ AUTOMAKE_OPTIONS = foreign subdir-objects
>>
>> AM_CFLAGS = -Wall -Wstrict-aliasing=2 -pedantic
>>
>> -lib_LIBRARIES = libwinstorecompat.a
>> +lib_LIBRARIES = libwinstorecompat.a \
>> +  libwinstorecompatapp.a
> 
> I'd still like this to be named e.g. winstorecompatuwp instead of -app.


How about windowsappcompat ? It's shorter and hint at the combination 
with windowsapp.


I like that.


I'd be ok with pushing this patch after it's been updated with the 
suggested name.


// Martin

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

Re: [Mingw-w64-public] [PATCH v3 08/10] winstorecompat: allow building with code that needs codeGeneration capability

[Martin Storsjö]

On Thu, 7 May 2020, Martin Storsjö wrote:


On Thu, 7 May 2020, Steve Lhomme wrote:

Would there be any harm in removing the whole configure option? If I read 
MSDN correctly, only certain flags to VirtualProtectFromApp are disallowed 
(and some flags requires codeGeneration while others are totally fine) - 
so it should be fine to keep the function call. And as long as it actually 
isn't called at runtime, it's fine either way.


(I'm generally fine with the patch, but if it's possible to skip the 
configure option I'd prefer that. But I'd probably rewrite bits of the 
commit message before pushing.)


As far as the CRT goes, it only tries to set PAGE_EXECUTE_READWRITE (or 
restore what was there before). As you mentioned PAGE_EXECUTE_READWRITE 
will just return an error, even if the app has the proper capability. So We 
can compile this code without any care of the capability.


Oh, I had missed the fact that it always sets PAGE_EXECUTE_READWRITE 
regardless of what's really needed. For non-code sections it's quite enough 
to make it PAGE_READWRITE - and for that, mapping it straight to 
VirtualProtectFromApp works just fine.


I'll send a patch for that.

With that patch in place, I'd prefer if the default winstorecompat version of 
VirtualProtect just calls VirtualProtectFromApp. For any code built with 
LLVM, which doesn't place references to potentially autoimported variables in 
code segments, this should - as far as I can see - always work, without any 
codeGeneration capability.


Pushed that patch now, so now in practice, it will only ever call 
VirtualProtect(PAGE_READWRITE) at least for code built with clang. So that 
makes it, IMO, worthwhile to always forward VirtualProtect to 
VirtualProtectFromApp within winstorecompat at least.


But some obstruction in the header declaration of VirtualProtect, to 
discourage ported code from calling it probably would be good.


// Martin

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

Re: [Mingw-w64-public] [PATCH v2] winstorecompat: handle LoadLibraryA alongside LoadLibraryW

[Martin Storsjö]

On Thu, 7 May 2020, Martin Storsjö wrote:


On Thu, 7 May 2020, Steve Lhomme wrote:


---
mingw-w64-headers/include/winbase.h|  3 +--
.../winstorecompat/src/LoadLibraryW.c  | 18 --
2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/mingw-w64-headers/include/winbase.h 
b/mingw-w64-headers/include/winbase.h

index 1bc85317..8dd03dee 100644
--- a/mingw-w64-headers/include/winbase.h
+++ b/mingw-w64-headers/include/winbase.h
@@ -1524,6 +1524,7 @@ extern "C" {
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || 
defined(WINSTORECOMPAT)

#define LoadLibrary __MINGW_NAME_AW(LoadLibrary)
  WINBASEAPI HMODULE WINAPI LoadLibraryW (LPCWSTR lpLibFileName);
+  WINBASEAPI HMODULE WINAPI LoadLibraryA (LPCSTR lpLibFileName);
#endif
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
  WINBASEAPI HANDLE WINAPI OpenMutexA (DWORD dwDesiredAccess, WINBOOL 
bInheritHandle, LPCSTR lpName);

@@ -1537,7 +1538,6 @@ extern "C" {
#endif
  WINBASEAPI HANDLE WINAPI OpenFileMappingA (DWORD dwDesiredAccess, WINBOOL 
bInheritHandle, LPCSTR lpName);
  WINBASEAPI DWORD WINAPI GetLogicalDriveStringsA (DWORD nBufferLength, 
LPSTR lpBuffer);

-  WINBASEAPI HMODULE WINAPI LoadLibraryA (LPCSTR lpLibFileName);

#ifndef UNICODE
#define OpenMutex OpenMutexA
@@ -1549,7 +1549,6 @@ extern "C" {
#endif

#define CreateWaitableTimer __MINGW_NAME_AW(CreateWaitableTimer)
-#define LoadLibrary __MINGW_NAME_AW(LoadLibrary)

#if _WIN32_WINNT >= 0x0600
#ifndef UNICODE
diff --git a/mingw-w64-libraries/winstorecompat/src/LoadLibraryW.c 
b/mingw-w64-libraries/winstorecompat/src/LoadLibraryW.c

index 633cbd24..f405099a 100644
--- a/mingw-w64-libraries/winstorecompat/src/LoadLibraryW.c
+++ b/mingw-w64-libraries/winstorecompat/src/LoadLibraryW.c
@@ -25,17 +25,31 @@
#define _WIN32_WINNT 0x602 /* LoadPackagedLibrary is Win8 APP Family */

#define LoadLibraryW __LoadLibraryW
-#include 
-#include 
+#define LoadLibraryA __LoadLibraryA
+#include 
#undef LoadLibraryW
+#undef LoadLibraryA

HMODULE WINAPI LoadLibraryW(LPCWSTR lpFileName)
{
return LoadPackagedLibrary(lpFileName, 0);
}

+WINBASEAPI HMODULE WINAPI LoadLibraryA (LPCSTR lpFileName)
+{
+int len = MultiByteToWideChar(GetACP(), 0, lpFileName, -1, NULL, 0);
+if (len <= 0)
+return NULL;
+
+wchar_t *out = alloca(len);
+MultiByteToWideChar(GetACP(), 0, lpFileName, -1, out, len);
+return LoadLibraryW(out);
+}
+
#ifdef _X86_
HMODULE (WINAPI *__MINGW_IMP_SYMBOL(LoadLibraryW))(LPCWSTR lpFileName) 
asm("__imp__LoadLibraryW@4") = LoadLibraryW;
+HMODULE (WINAPI *__MINGW_IMP_SYMBOL(LoadLibraryA))(LPCWSTR lpFileName) 
asm("__imp__LoadLibraryA@4") = LoadLibraryA;

#else
HMODULE (WINAPI *__MINGW_IMP_SYMBOL(LoadLibraryW))(LPCWSTR lpFileName) 
asm("__imp_LoadLibraryW") = LoadLibraryW;
+HMODULE (WINAPI *__MINGW_IMP_SYMBOL(LoadLibraryA))(LPCWSTR lpFileName) 
asm("__imp_LoadLibraryA") = LoadLibraryA;

#endif
--
2.17.1


Thanks, this looks good to me, and I'd like to push this unless there's 
strong opposition to it.


Pushed this one, with a few minor fixups.

Out of curiousity, what's the practical difference between using GetACP() and 
just CP_ACP? Doesn't the latter internally map to whatever code page is set 
active anyway?


Still interested in a comment on this if someone cares to elaborate :-)

// Martin

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

Re: [Mingw-w64-public] [PATCH v4] winstorecompat: add libwindowsappcompat to use with libwindowsapp

[Martin Storsjö]

On Mon, 11 May 2020, Steve Lhomme wrote:


The original libwinstorecompat is designed to be used with libmincore.

- CreateEventW is allowed
- CreateMutexW is allowed
- CreateSemaphoreW is allowed
- InitializeCriticalSection is allowed
- GetFileAttributes is allowed
- WaitForSingleObject is allowed
- GetTickCount is allowed
- SetUnhandledExceptionFilter is allowed
- TerminateProcess is allowed
- IsDBCSLeadByteEx is allowed
- SetErrorMode is allowed
- GetACP is allowed
- LocalAlloc/LocalFree are allowed
- Sleep/SleepEx are allowed
- SetFilePointer is allowed
- Tls functions are allowed
- GetConsoleOutputCP is allowed

https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis

To select the set of API's allowed by this library, define WINSTORECOMPAT
and build with _WIN32_WINNT >= _WIN32_WINNT_WIN10.
---
.../winstorecompat/Makefile.am| 25 ++-
1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/mingw-w64-libraries/winstorecompat/Makefile.am 
b/mingw-w64-libraries/winstorecompat/Makefile.am
index a1f79947..028ac147 100644
--- a/mingw-w64-libraries/winstorecompat/Makefile.am
+++ b/mingw-w64-libraries/winstorecompat/Makefile.am
@@ -2,7 +2,8 @@ AUTOMAKE_OPTIONS = foreign subdir-objects

AM_CFLAGS = -Wall -Wstrict-aliasing=2 -pedantic

-lib_LIBRARIES = libwinstorecompat.a
+lib_LIBRARIES = libwinstorecompat.a \
+  libwindowsappcompat.a

libwinstorecompat_a_SOURCES = \
  src/beginthread.c \
@@ -43,3 +44,25 @@ libwinstorecompat_a_SOURCES = \
  src/RtlRestoreContext.c \
  src/GetUserName.c \
  $(NULL)
+
+libwindowsappcompat_a_SOURCES = \
+  src/beginthread.c \
+  src/GetModuleHandle.c \
+  src/LoadLibraryW.c \
+  src/CreateFileW.c \
+  src/UnhandledExceptionFilter.c \
+  src/VirtualProtect.c \
+  src/getenv.c \
+  src/GetFileSize.c \
+  src/SHGetFolderPathW.c \
+  src/QueueTimer.c \
+  src/Crypto.c \
+  src/GetStartupInfo.c \
+  src/EnumProcessModules.c \
+  src/RtlAddFunctionTable.c \
+  src/RtlCaptureContext.c \
+  src/RtlVirtualUnwind.c \
+  src/RtlRestoreContext.c \
+  src/GetUserName.c \
+  $(NULL)
+libwindowsappcompat_a_CFLAGS = $(AM_CFLAGS) -D_WIN32_WINNT=_WIN32_WINNT_WIN10
--
2.17.1


LGTM, I'll apply this tonight unless there's objections.

// Martin



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

Re: [Mingw-w64-public] [PATCH v2] winstorecompat: handle LoadLibraryA alongside LoadLibraryW

[Martin Storsjö]

On Mon, 11 May 2020, Liu Hao wrote:


在 2020/5/11 5:18, Martin Storsjö 写道:



Out of curiousity, what's the practical difference between using
GetACP() and just CP_ACP? Doesn't the latter internally map to
whatever code page is set active anyway?


Still interested in a comment on this if someone cares to elaborate :-)



AFAICT there is no difference.


Ok, so in that case it would be beneficial to just use CP_ACP I think, as 
there's one imported function less.


// Martin

___
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: Update libloaderapi.h to match winbase.h regarding LoadLibraryA/W

[Martin Storsjö]

Also factor out a duplication regarding the GetModuleHandleA/W function.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-headers/include/libloaderapi.h | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/mingw-w64-headers/include/libloaderapi.h 
b/mingw-w64-headers/include/libloaderapi.h
index b867164cd..d4c82ef8c 100644
--- a/mingw-w64-headers/include/libloaderapi.h
+++ b/mingw-w64-headers/include/libloaderapi.h
@@ -92,10 +92,6 @@ extern "C" {
   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 GetModuleHandleA (LPCSTR lpModuleName);
-  WINBASEAPI HMODULE WINAPI GetModuleHandleW (LPCWSTR lpModuleName);
-  WINBASEAPI HMODULE WINAPI LoadLibraryA(LPCSTR lpLibFileName);
-  WINBASEAPI HMODULE WINAPI LoadLibraryW(LPCWSTR lpLibFileName);
   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);
@@ -117,9 +113,7 @@ extern "C" {
 
 #define PGET_MODULE_HANDLE_EX __MINGW_NAME_AW(PGET_MODULE_HANDLE_EX)
 #define LoadString __MINGW_NAME_AW(LoadString)
-#define GetModuleHandle __MINGW_NAME_AW(GetModuleHandle)
 #define GetModuleHandleEx __MINGW_NAME_AW(GetModuleHandleEx)
-#define LoadLibrary __MINGW_NAME_AW(LoadLibrary)
 #define LoadLibraryEx __MINGW_NAME_AW(LoadLibraryEx)
 
 #define EnumResourceLanguages __MINGW_NAME_AW(EnumResourceLanguages)
@@ -140,10 +134,14 @@ extern "C" {
 #define EnumResourceNamesEx __MINGW_NAME_AW(EnumResourceNamesEx)
 #define EnumResourceTypesEx __MINGW_NAME_AW(EnumResourceTypesEx)
 #endif
-#elif defined(WINSTORECOMPAT)
+#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
 
 #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_APP)
-- 
2.17.1



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

Re: [Mingw-w64-public] [PATCH] headers: Update libloaderapi.h to match winbase.h regarding LoadLibraryA/W

[Martin Storsjö]

On Mon, 11 May 2020, Biswapriyo Nath wrote:


But in WinSDK, those are present in libloaderapi.h not in winbase.h.


I don't have time to go down the rabbit hole of trying to disentangle 
those. I applied a patch for winstorecompat, and now I'm trying to make 
the definitions consistent.


// Martin



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

Re: [Mingw-w64-public] [PATCH 1/2] widl: Compute relative binary to include dir path in configure.

[Martin Storsjö]

On Mon, 18 May 2020, Jacek Caban wrote:


Signed-off-by: Jacek Caban 
---

Wine has relocation support in widl now, which conflicts with mingw-w64 
relocation patch. Wine uses BIN_TO_INCLUDEDIR macro, which gets computed 
relative path. Wine has its own makedep, which takes care of computing that, 
but it would be a bit overkill to port that to mingw-w64. I used autoconf 
AX_COMPUTE_RELATIVE_PATH macro for that. This allows nice simplification of 
mingw-w64 - specific code.


AX_COMPUTE_RELATIVE_PATH doesn't seem to be available in the base autoconf 
distribution, so it'd be great to cache a copy of that in an m4 subdir, 
with the appropriate flags for including that dir.


Other than that, it looks good - I haven't tested the feature in detail 
but seems to work in general - and it looks like it's taking 
--with-widl-includedir into account, so that's good.


Same for other patch as well, looks good.

// Martin



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

Re: [Mingw-w64-public] [PATCH] winstorecompat: Forward VirtualProtect to VirtualProtectFromApp on windows 10

[Martin Storsjö]

On Mon, 11 May 2020, Steve Lhomme wrote:


OK with me


Pushed now.

// Martin



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

Re: [Mingw-w64-public] [PATCH] crt: add some missing libraries now found in windowsapp

[Martin Storsjö]

On Thu, 14 May 2020, Steve Lhomme wrote:


---
mingw-w64-crt/lib-common/mincore.mri | 78 ++--
1 file changed, 39 insertions(+), 39 deletions(-)

diff --git a/mingw-w64-crt/lib-common/mincore.mri 
b/mingw-w64-crt/lib-common/mincore.mri
index a7546ca4..5ed04648 100644
--- a/mingw-w64-crt/lib-common/mincore.mri
+++ b/mingw-w64-crt/lib-common/mincore.mri
@@ -1,74 +1,74 @@
CREATE libmincore.a
-; FIXME libapi-ms-win-core-com-l1-1-0.a
+ADDLIB libapi-ms-win-core-com-l1-1-0.a
ADDLIB libapi-ms-win-core-com-l1-1-1.a


Do these dependencies need to be expressed in Makefile.am as well, so it 
won't fail if trying to build this before all of the others have been 
built?


// Martin



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

[Mingw-w64-public] [PATCH] Revert "crt: Move stdio/[v]snprintf.c to libmsvcr*.a from libmingwex.a"

[Martin Storsjö]

This reverts commit ae95d7ca7320f6a6dd27cf1633188103af71c372.

That commit mentioned splitting the aliases to separate object files as
an alternative solution. In b46a25b433f5adf23418994df484b2e6b3f9e566,
this was done, so the __ms_[v]snprintf functions can be moved back to
libmingwex as they themselves are harmless there.

This avoids needing to build a separate copy of [v]snprintf.o for each
of the msvcr* libraries.

This should fix cases when linking some object files built against
headers in msvcrt mode against ucrt. This isn't a supported configuration,
one can't in general link object files built for one crt mode against
another crt. However, if the only mismatch is use of __ms_[v]snprintf,
linking that against ucrt should be mostly harmless.
---
 mingw-w64-crt/Makefile.am | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index c917b2ad4..ca7ebcf50 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -169,9 +169,7 @@ src_msvcrt_common=\
   misc/uchar_mbrtoc32.c \
   misc/wcrtomb.c \
   stdio/acrt_iob_func.c \
-  stdio/snprintf.c \
   stdio/snprintf_alias.c \
-  stdio/vsnprintf.c \
   stdio/vsnprintf_alias.c \
   math/frexp.c
 
@@ -468,9 +466,9 @@ src_libmingwex=\
   stdio/mingw_snprintfw.c  stdio/mingw_sprintf.c stdio/mingw_sprintfw.c   
stdio/mingw_sscanf.c  stdio/mingw_swscanf.c   \
   stdio/mingw_vfprintf.c   stdio/mingw_vfprintfw.c   stdio/mingw_vfscanf.c
stdio/mingw_vprintf.c stdio/mingw_vprintfw.c  \
   stdio/mingw_vsnprintf.c  stdio/mingw_vsnprintfw.c  stdio/mingw_vsprintf.c   
stdio/mingw_vsprintfw.c   stdio/mingw_wscanf.c\
-  stdio/mingw_wvfscanf.c   stdio/snwprintf.cstdio/strtof.c
stdio/truncate.c\
+  stdio/mingw_wvfscanf.c   stdio/snprintf.c  stdio/snwprintf.c
stdio/strtof.cstdio/truncate.c\
   stdio/ulltoa.c   stdio/ulltow.cstdio/vasprintf.c
stdio/vfscanf.c   stdio/vfwscanf.c\
-  stdio/vscanf.c   stdio/vsnwprintf.cstdio/vsscanf.c \
+  stdio/vscanf.c   stdio/vsnprintf.c stdio/vsnwprintf.c
stdio/vsscanf.c \
   stdio/vswscanf.c stdio/vwscanf.c   stdio/wtoll.c
stdio/mingw_asprintf.cstdio/mingw_vasprintf.c
 
 # these go into both 32 and 64 bit x86 versions:
-- 
2.17.1



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

Re: [Mingw-w64-public] [PATCH] Revert "crt: Move stdio/[v]snprintf.c to libmsvcr*.a from libmingwex.a"

[Martin Storsjö]

On Thu, 14 May 2020, Liu Hao wrote:


在 2020/5/14 18:48, Martin Storsjö 写道:

This reverts commit ae95d7ca7320f6a6dd27cf1633188103af71c372.

That commit mentioned splitting the aliases to separate object files as
an alternative solution. In b46a25b433f5adf23418994df484b2e6b3f9e566,
this was done, so the __ms_[v]snprintf functions can be moved back to
libmingwex as they themselves are harmless there.

This avoids needing to build a separate copy of [v]snprintf.o for each
of the msvcr* libraries.

This should fix cases when linking some object files built against
headers in msvcrt mode against ucrt. This isn't a supported configuration,
one can't in general link object files built for one crt mode against
another crt. However, if the only mismatch is use of __ms_[v]snprintf,
linking that against ucrt should be mostly harmless.
---
 mingw-w64-crt/Makefile.am | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)




LGTM.


Pushed, thanks.

// Martin

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

Re: [Mingw-w64-public] [PATCH 2/2] crt/stdio: Add declaration for `__ms_*` aliases

[Martin Storsjö]

On Fri, 15 May 2020, Liu Hao wrote:


Exhausive function list:

 __ms_printf
 __ms_wprintf
 __ms_fprintf
 __ms_fwprintf
 __ms_sprintf
 __ms_swprintf

 __ms_vprintf
 __ms_vwprintf
 __ms_vfprintf
 __ms_vfwprintf
 __ms_vsprintf
 __ms_vswprintf

 __ms_scanf
 __ms_wscanf
 __ms_fscanf
 __ms_fwscanf
 __ms_sscanf
 __ms_swscanf

Signed-off-by: Liu Hao 
---
mingw-w64-headers/crt/stdio.h | 52 +--
1 file changed, 49 insertions(+), 3 deletions(-)


I think these two patches look good, but I haven't studied it in detail.

// Martin



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

Re: [Mingw-w64-public] [PATCH] winstorecompat: provide getpid

[Martin Storsjö]

On Thu, 14 May 2020, Steve Lhomme wrote:


It's forbidden in any UWP app.
---
mingw-w64-headers/crt/process.h   | 10 +++--
mingw-w64-headers/crt/unistd.h|  6 +--
.../winstorecompat/Makefile.am|  2 +
.../winstorecompat/src/getpid.c   | 41 +++
4 files changed, 52 insertions(+), 7 deletions(-)
create mode 100644 mingw-w64-libraries/winstorecompat/src/getpid.c

diff --git a/mingw-w64-headers/crt/process.h b/mingw-w64-headers/crt/process.h
index 462a902d..e5ff9992 100644
--- a/mingw-w64-headers/crt/process.h
+++ b/mingw-w64-headers/crt/process.h
@@ -152,6 +152,12 @@ extern "C" {
#define WAIT_CHILD _WAIT_CHILD
#define WAIT_GRANDCHILD _WAIT_GRANDCHILD

+#if defined(_CRT_USE_WINAPI_FAMILY_DESKTOP_APP) || defined(WINSTORECOMPAT)
+#ifndef _CRT_GETPID_DEFINED
+#define _CRT_GETPID_DEFINED  /* Also in unistd.h */
+  int __cdecl getpid(void) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
+#endif
+#endif /* _CRT_USE_WINAPI_FAMILY_DESKTOP_APP || WINSTORECOMPAT */
#ifdef _CRT_USE_WINAPI_FAMILY_DESKTOP_APP
  intptr_t __cdecl cwait(int *_TermStat,intptr_t _ProcHandle,int _Action) 
__MINGW_ATTRIB_DEPRECATED_MSVC2005;
#ifdef __GNUC__
@@ -169,10 +175,6 @@ extern "C" {
  intptr_t __cdecl spawnle(int,const char *_Filename,const char *_ArgList,...) 
__MINGW_ATTRIB_DEPRECATED_MSVC2005;
  intptr_t __cdecl spawnlp(int,const char *_Filename,const char *_ArgList,...) 
__MINGW_ATTRIB_DEPRECATED_MSVC2005;
  intptr_t __cdecl spawnlpe(int,const char *_Filename,const char *_ArgList,...) 
__MINGW_ATTRIB_DEPRECATED_MSVC2005;
-#ifndef _CRT_GETPID_DEFINED
-#define _CRT_GETPID_DEFINED  /* Also in unistd.h */
-  int __cdecl getpid(void) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
-#endif
#ifdef __GNUC__
  /* Those methods are predefined by gcc builtins to return int. So to prevent
 stupid warnings, define them in POSIX way.  This is save, because those
diff --git a/mingw-w64-headers/crt/unistd.h b/mingw-w64-headers/crt/unistd.h
index 05512c53..af59cb96 100644
--- a/mingw-w64-headers/crt/unistd.h
+++ b/mingw-w64-headers/crt/unistd.h
@@ -93,12 +93,12 @@ __CRT_INLINE int ftruncate(int __fd, _off_t __length)
  void __cdecl swab(char *_Buf1,char *_Buf2,int _SizeInBytes) 
__MINGW_ATTRIB_DEPRECATED_MSVC2005;
#endif

-#ifdef _CRT_USE_WINAPI_FAMILY_DESKTOP_APP
+#if defined(_CRT_USE_WINAPI_FAMILY_DESKTOP_APP) || defined(WINSTORECOMPAT)
#ifndef _CRT_GETPID_DEFINED
-#define _CRT_GETPID_DEFINED /* Also in process.h */
+#define _CRT_GETPID_DEFINED  /* Also in process.h */
  int __cdecl getpid(void) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
#endif
-#endif /* _CRT_USE_WINAPI_FAMILY_DESKTOP_APP */
+#endif /* _CRT_USE_WINAPI_FAMILY_DESKTOP_APP || WINSTORECOMPAT */

#ifdef __cplusplus
}
diff --git a/mingw-w64-libraries/winstorecompat/Makefile.am 
b/mingw-w64-libraries/winstorecompat/Makefile.am
index 028ac147..e25359f6 100644
--- a/mingw-w64-libraries/winstorecompat/Makefile.am
+++ b/mingw-w64-libraries/winstorecompat/Makefile.am
@@ -43,6 +43,7 @@ libwinstorecompat_a_SOURCES = \
  src/RtlVirtualUnwind.c \
  src/RtlRestoreContext.c \
  src/GetUserName.c \
+  src/getpid.c \
  $(NULL)

libwindowsappcompat_a_SOURCES = \
@@ -64,5 +65,6 @@ libwindowsappcompat_a_SOURCES = \
  src/RtlVirtualUnwind.c \
  src/RtlRestoreContext.c \
  src/GetUserName.c \
+  src/getpid.c \
  $(NULL)
libwindowsappcompat_a_CFLAGS = $(AM_CFLAGS) -D_WIN32_WINNT=_WIN32_WINNT_WIN10
diff --git a/mingw-w64-libraries/winstorecompat/src/getpid.c 
b/mingw-w64-libraries/winstorecompat/src/getpid.c
new file mode 100644
index ..f269c81d
--- /dev/null
+++ b/mingw-w64-libraries/winstorecompat/src/getpid.c
@@ -0,0 +1,41 @@
+/*
+Copyright (c) 2020 mingw-w64 project
+
+Contributing authors: Steve Lhomme
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+*/
+
+#define getpid __getpid
+#include 
+#include 
+#undef getpid
+
+int getpid( void );
+
+int getpid( void );
+{
+return (int)GetCurrentProcessId();
+}
+

Re: [Mingw-w64-public] mingw-w64 and __attribute__((format(printf))) issue

[Martin Storsjö]

On Wed, 6 May 2020, Liu Hao wrote:


Due to a recent change in mingw-w64 master [1], libgomp ceases to build:

```
../../../gcc-git/libgomp/target.c:936:21: error: unknown conversion type
character 'l' in format [-Werror=format=]
 936 | gomp_fatal ("present clause: !acc_is_present (%p, "
 | ^~~
```


On line 29 of 'libgomp/libgomp.h' from GCC 9 branch I found this declaration

```
extern void gomp_fatal (const char *, ...)
   __attribute__ ((noreturn, format (printf, 1, 2)));
```

, which uses the `printf` attribute, but the `PRIu64` macro from
 expands to `%llu` because now GCC has `-std=gnu11` by
default, which is only valid with `gnu_printf`.

AFAICS there are three solutions:

1. Revert bfd33f6c0ec5e652cc9911857dd1492ece8d8383 in mingw-w64, or


This is generally the risk of this kind of commit - regardless of how 
right/wrong the status quo is, there's _a lot_ of code that relies on it 
behaving in a specific way, and changing that will certainly run into 
minor issues in a lot of places.



2. Make GCC treat `format(printf)` as `format(gnu_printf)` if C11 or
  C++11 is selected, or


I'm not very keen on that. The compiler should ideally not assume to much 
about what the platform headers do in detail, because it limits what we 
can change. (If we'd make that change in the compiler, and then for 
another reason end up reverting the commit, we'd have the same issue in 
reverse.)



3. Replace `format(printf)` with `format(gnu_printf)` in libgomp source.


This also kind of hardcodes too much; libgomp in general can't and 
shouldn't assume too much about which format kind it uses, unless libgomp 
itself hardcodes __USE_MINGW_ANSI_STDIO. Also, the whole gnu_printf format 
is something that only GCC supports, not Clang, but I guess libgomp is 
rather GCC specific anyway.


However we do have a define that should expand to the right thing - just 
like inttypes.h PRIu64 follows __USE_MINGW_ANSI_STDIO - we have 
__MINGW_PRINTF_FORMAT.


So something like this should work:

#ifdef __MINGW32__
#define PRINTF_FORMAT __MINGW_PRINTF_FORMAT
#else
#define PRINTF_FORMAT printf
#endif

__attribute__((format(PRINTF_FORMAT)))

Not very pretty, but should work without hardcoding any assumptions about 
which format actually is used.



// Martin



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

Re: [Mingw-w64-public] [PATCH] winstorecompat: add libwindowsappcompat to use with libwindowsapp

[Martin Storsjö]

On Wed, 6 May 2020, Steve Lhomme wrote:


Hello,

Any update on this ? Is there anything blocking ?


Sorry, I've been rather busy.

I'll try to have a look at the last version of the patchset now 
(today/tomorrow), test things I want to doublecheck, commit the bits where 
there's enough consensus, and ping/comment/post patch suggestions for the 
rest.


// Martin



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

[Mingw-w64-public] [PATCH] winstorecompat: Avoid warnings about redefining _WIN32_WINNT in the Win10 library

[Martin Storsjö]

Signed-off-by: Martin Storsjö 
---
 mingw-w64-libraries/winstorecompat/src/CreateFileW.c| 2 ++
 mingw-w64-libraries/winstorecompat/src/Crypto.c | 2 ++
 mingw-w64-libraries/winstorecompat/src/GetFileSize.c| 2 ++
 mingw-w64-libraries/winstorecompat/src/LoadLibraryW.c   | 2 ++
 .../winstorecompat/src/UnhandledExceptionFilter.c   | 2 ++
 mingw-w64-libraries/winstorecompat/src/beginthread.c| 2 ++
 6 files changed, 12 insertions(+)

diff --git a/mingw-w64-libraries/winstorecompat/src/CreateFileW.c 
b/mingw-w64-libraries/winstorecompat/src/CreateFileW.c
index b15378b3b..4771df7bd 100644
--- a/mingw-w64-libraries/winstorecompat/src/CreateFileW.c
+++ b/mingw-w64-libraries/winstorecompat/src/CreateFileW.c
@@ -22,7 +22,9 @@
 DEALINGS IN THE SOFTWARE.
 */
 
+#ifndef _WIN32_WINNT
 #define _WIN32_WINNT 0x602 /* CreateFile2 is Win8 APP Family */
+#endif
 
 #define CreateFileW __CreateFileW
 #include 
diff --git a/mingw-w64-libraries/winstorecompat/src/Crypto.c 
b/mingw-w64-libraries/winstorecompat/src/Crypto.c
index 8de50d489..2c3c218ad 100644
--- a/mingw-w64-libraries/winstorecompat/src/Crypto.c
+++ b/mingw-w64-libraries/winstorecompat/src/Crypto.c
@@ -22,7 +22,9 @@
 DEALINGS IN THE SOFTWARE.
 */
 
+#ifndef _WIN32_WINNT
 #define _WIN32_WINNT 0x602
+#endif
 
 #define CryptAcquireContextW __CryptAcquireContextW
 #define CryptAcquireContextA __CryptAcquireContextA
diff --git a/mingw-w64-libraries/winstorecompat/src/GetFileSize.c 
b/mingw-w64-libraries/winstorecompat/src/GetFileSize.c
index 5f798da97..8816a75d3 100644
--- a/mingw-w64-libraries/winstorecompat/src/GetFileSize.c
+++ b/mingw-w64-libraries/winstorecompat/src/GetFileSize.c
@@ -22,7 +22,9 @@
 DEALINGS IN THE SOFTWARE.
 */
 
+#ifndef _WIN32_WINNT
 #define _WIN32_WINNT 0x600 /* GetFileInformationByHandleEx is Vista+ */
+#endif
 
 #define GetFileSize __GetFileSize
 #include 
diff --git a/mingw-w64-libraries/winstorecompat/src/LoadLibraryW.c 
b/mingw-w64-libraries/winstorecompat/src/LoadLibraryW.c
index 9cbe21629..313126f06 100644
--- a/mingw-w64-libraries/winstorecompat/src/LoadLibraryW.c
+++ b/mingw-w64-libraries/winstorecompat/src/LoadLibraryW.c
@@ -22,7 +22,9 @@
 DEALINGS IN THE SOFTWARE.
 */
 
+#ifndef _WIN32_WINNT
 #define _WIN32_WINNT 0x602 /* LoadPackagedLibrary is Win8 APP Family */
+#endif
 
 #define LoadLibraryW __LoadLibraryW
 #define LoadLibraryA __LoadLibraryA
diff --git a/mingw-w64-libraries/winstorecompat/src/UnhandledExceptionFilter.c 
b/mingw-w64-libraries/winstorecompat/src/UnhandledExceptionFilter.c
index 5a35183cf..31674b011 100644
--- a/mingw-w64-libraries/winstorecompat/src/UnhandledExceptionFilter.c
+++ b/mingw-w64-libraries/winstorecompat/src/UnhandledExceptionFilter.c
@@ -22,7 +22,9 @@
 DEALINGS IN THE SOFTWARE.
 */
 
+#ifndef _WIN32_WINNT
 #define _WIN32_WINNT 0x501 /* UnhandledExceptionFilter is XP+ */
+#endif
 
 #define UnhandledExceptionFilter __UnhandledExceptionFilter
 #include 
diff --git a/mingw-w64-libraries/winstorecompat/src/beginthread.c 
b/mingw-w64-libraries/winstorecompat/src/beginthread.c
index f96d1f7ef..d3f39c502 100644
--- a/mingw-w64-libraries/winstorecompat/src/beginthread.c
+++ b/mingw-w64-libraries/winstorecompat/src/beginthread.c
@@ -22,7 +22,9 @@
 DEALINGS IN THE SOFTWARE.
 */
 
+#ifndef _WIN32_WINNT
 #define _WIN32_WINNT 0x501
+#endif
 
 #define _beginthreadex ___beginthreadex
 #define _endthreadex ___endthreadex
-- 
2.17.1



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

Re: [Mingw-w64-public] [PATCH v4] winstorecompat: add libwindowsappcompat to use with libwindowsapp

[Martin Storsjö]

On Mon, 11 May 2020, Martin Storsjö wrote:


On Mon, 11 May 2020, Steve Lhomme wrote:


The original libwinstorecompat is designed to be used with libmincore.

- CreateEventW is allowed
- CreateMutexW is allowed
- CreateSemaphoreW is allowed
- InitializeCriticalSection is allowed
- GetFileAttributes is allowed
- WaitForSingleObject is allowed
- GetTickCount is allowed
- SetUnhandledExceptionFilter is allowed
- TerminateProcess is allowed
- IsDBCSLeadByteEx is allowed
- SetErrorMode is allowed
- GetACP is allowed
- LocalAlloc/LocalFree are allowed
- Sleep/SleepEx are allowed
- SetFilePointer is allowed
- Tls functions are allowed
- GetConsoleOutputCP is allowed

https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis

To select the set of API's allowed by this library, define WINSTORECOMPAT
and build with _WIN32_WINNT >= _WIN32_WINNT_WIN10.
---
.../winstorecompat/Makefile.am| 25 ++-
1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/mingw-w64-libraries/winstorecompat/Makefile.am 
b/mingw-w64-libraries/winstorecompat/Makefile.am

index a1f79947..028ac147 100644
--- a/mingw-w64-libraries/winstorecompat/Makefile.am
+++ b/mingw-w64-libraries/winstorecompat/Makefile.am
@@ -2,7 +2,8 @@ AUTOMAKE_OPTIONS = foreign subdir-objects

AM_CFLAGS = -Wall -Wstrict-aliasing=2 -pedantic

-lib_LIBRARIES = libwinstorecompat.a
+lib_LIBRARIES = libwinstorecompat.a \
+  libwindowsappcompat.a

libwinstorecompat_a_SOURCES = \
  src/beginthread.c \
@@ -43,3 +44,25 @@ libwinstorecompat_a_SOURCES = \
  src/RtlRestoreContext.c \
  src/GetUserName.c \
  $(NULL)
+
+libwindowsappcompat_a_SOURCES = \
+  src/beginthread.c \
+  src/GetModuleHandle.c \
+  src/LoadLibraryW.c \
+  src/CreateFileW.c \
+  src/UnhandledExceptionFilter.c \
+  src/VirtualProtect.c \
+  src/getenv.c \
+  src/GetFileSize.c \
+  src/SHGetFolderPathW.c \
+  src/QueueTimer.c \
+  src/Crypto.c \
+  src/GetStartupInfo.c \
+  src/EnumProcessModules.c \
+  src/RtlAddFunctionTable.c \
+  src/RtlCaptureContext.c \
+  src/RtlVirtualUnwind.c \
+  src/RtlRestoreContext.c \
+  src/GetUserName.c \
+  $(NULL)
+libwindowsappcompat_a_CFLAGS = $(AM_CFLAGS) 
-D_WIN32_WINNT=_WIN32_WINNT_WIN10

--
2.17.1


LGTM, I'll apply this tonight unless there's objections.


And pushed.

// Martin

___
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] Revert "Avoid declaring something extern AND initializing it."

[Martin Storsjö]

This reverts commit d551b7d85ec63c0fa33f1a51ec5157722709fc53.

Redefining EXTERN_C to an empty string isn't the right thing here,
as that makes EXTERN_C wrong for any later header that is included
(omitting "extern" on variable declarations, which breaks with
GCC 10 and Clang 11, where -fno-common is set by default).

Signed-off-by: Martin Storsjö 
---
 mingw-w64-headers/include/mftransform.h   | 5 -
 mingw-w64-headers/include/mftransform.idl | 8 
 2 files changed, 13 deletions(-)

diff --git a/mingw-w64-headers/include/mftransform.h 
b/mingw-w64-headers/include/mftransform.h
index 5be048b0c..2e5877303 100644
--- a/mingw-w64-headers/include/mftransform.h
+++ b/mingw-w64-headers/include/mftransform.h
@@ -509,11 +509,6 @@ static FORCEINLINE HRESULT 
IMFTransform_ProcessOutput(IMFTransform* This,DWORD d
 
 #endif  /* __IMFTransform_INTERFACE_DEFINED__ */
 
-#if defined(__GNUC__) && !defined(__cplusplus)
-#undef EXTERN_C
-#define EXTERN_C
-#endif
-
 EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CLSID = 
{{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x01};
 EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CATEGORY = 
{{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x02 };
 EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_EXATTRIBUTE_SUPPORTED = 
{{0x456fe843,0x3c87,0x40c0,{0x94,0x9d,0x14,0x9,0xc9,0x7d,0xab,0x2c}}, 0x01};
diff --git a/mingw-w64-headers/include/mftransform.idl 
b/mingw-w64-headers/include/mftransform.idl
index bea0182dc..9b917367a 100644
--- a/mingw-w64-headers/include/mftransform.idl
+++ b/mingw-w64-headers/include/mftransform.idl
@@ -143,14 +143,6 @@ interface IMFTransform : IUnknown
   [out] DWORD *pdwStatus);
 }
 
-/* In gcc, declaring something 'extern' and then initializing it
-   generates a warning.  */
-cpp_quote("#if defined(__GNUC__) && !defined(__cplusplus)")
-cpp_quote("#undef EXTERN_C")
-cpp_quote("#define EXTERN_C")
-cpp_quote("#endif")
-cpp_quote("")
-
 cpp_quote("EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CLSID = 
{{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x01};")
 cpp_quote("EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CATEGORY = 
{{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x02 };")
 cpp_quote("EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY 
MFPKEY_EXATTRIBUTE_SUPPORTED = 
{{0x456fe843,0x3c87,0x40c0,{0x94,0x9d,0x14,0x9,0xc9,0x7d,0xab,0x2c}}, 0x01};")
-- 
2.17.1



___
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: Remove superfluous EXTERN_C when defining variables

[Martin Storsjö]

For C++, the generated .h encloses this block in 'extern "C" { .. }'
anyway, and as these are variable definitions (with DECLSPEC_SELECTANY,
avoiding duplicate definitions even though it's in a header), not
declarations, GCC (and possibly clang as well) warn when the definition
also contains the 'extern' attribute.

This fixes the same warning as d551b7d85ec63c0fa33f1a51ec5157722709fc53
tried to fix, without overriding the EXTERN_C macro, which affected
other headers.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-headers/include/mftransform.h   | 50 +++
 mingw-w64-headers/include/mftransform.idl | 48 +++---
 2 files changed, 49 insertions(+), 49 deletions(-)

diff --git a/mingw-w64-headers/include/mftransform.h 
b/mingw-w64-headers/include/mftransform.h
index 2e5877303..2420140da 100644
--- a/mingw-w64-headers/include/mftransform.h
+++ b/mingw-w64-headers/include/mftransform.h
@@ -1,4 +1,4 @@
-/*** Autogenerated by WIDL 4.12.1 from include/mftransform.idl - Do not edit 
***/
+/*** Autogenerated by WIDL 5.0-rc1 from include/mftransform.idl - Do not edit 
***/
 
 #ifdef _WIN32
 #ifndef __REQUIRED_RPCNDR_H_VERSION__
@@ -509,30 +509,30 @@ static FORCEINLINE HRESULT 
IMFTransform_ProcessOutput(IMFTransform* This,DWORD d
 
 #endif  /* __IMFTransform_INTERFACE_DEFINED__ */
 
-EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CLSID = 
{{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x01};
-EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CATEGORY = 
{{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x02 };
-EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_EXATTRIBUTE_SUPPORTED = 
{{0x456fe843,0x3c87,0x40c0,{0x94,0x9d,0x14,0x9,0xc9,0x7d,0xab,0x2c}}, 0x01};
-EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_MULTICHANNEL_CHANNEL_MASK 
 = {{0x58bdaf8c,0x3224,0x4692,{0x86,0xd0,0x44,0xd6,0x5c,0x5b,0xf8,0x2b}}, 0x01};
-EXTERN_C const DECLSPEC_SELECTANY GUID MF_SA_D3D_AWARE = 
{0xeaa35c29,0x775e,0x488e,{0x9b,0x61,0xb3,0x28,0x3e,0x49,0x58,0x3b}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MF_SA_REQUIRED_SAMPLE_COUNT = 
{0x18802c61,0x324b,0x4952,{0xab,0xd0,0x17,0x6f,0xf5,0xc6,0x96,0xff}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MF_TRANSFORM_ASYNC = 
{0xf81a699a,0x649a,0x497d,{0x8c,0x73,0x29,0xf8,0xfe,0xd6,0xad,0x7a}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MF_TRANSFORM_ASYNC_UNLOCK = 
{0xe5666d6b,0x3422,0x4eb6,{0xa4,0x21,0xda,0x7d,0xb1,0xf8,0xe2,0x7}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MF_TRANSFORM_FLAGS_Attribute = 
{0x9359bb7e,0x6275,0x46c4,{0xa0,0x25,0x1c,0x1,0xe4,0x5f,0x1a,0x86}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MF_TRANSFORM_CATEGORY_Attribute = 
{0xceabba49,0x506d,0x4757,{0xa6,0xff,0x66,0xc1,0x84,0x98,0x7e,0x4e}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_TRANSFORM_CLSID_Attribute = 
{0x6821c42b,0x65a4,0x4e82,{0x99,0xbc,0x9a,0x88,0x20,0x5e,0xcd,0xc}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_INPUT_TYPES_Attributes = 
{0x4276c9b1,0x759d,0x4bf3, {0x9c,0xd0,0xd,0x72,0x3d,0x13,0x8f,0x96}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_OUTPUT_TYPES_Attributes = 
{0x8eae8cf3,0xa44f,0x4306,{0xba,0x5c,0xbf,0x5d,0xda,0x24,0x28,0x18}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_ENUM_HARDWARE_URL_Attribute = 
{0x2fb866ac,0xb078,0x4942,{0xab,0x6c,0x0,0x3d,0x5,0xcd,0xa6,0x74}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_FRIENDLY_NAME_Attribute = 
{0x314ffbae,0x5b41,0x4c95,{0x9c,0x19,0x4e,0x7d,0x58,0x6f,0xac,0xe3}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_CONNECTED_STREAM_ATTRIBUTE  = 
{0x71eeb820,0xa59f,0x4de2,{0xbc,0xec,0x38,0xdb,0x1d,0xd6,0x11,0xa4}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_CONNECTED_TO_HW_STREAM = 
{0x34e6e728,0x6d6,0x4491,{0xa5,0x53,0x47,0x95,0x65,0xd,0xb9,0x12}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_PREFERRED_OUTPUTTYPE_Attribute = 
{0x7e700499,0x396a,0x49ee,{0xb1,0xb4,0xf6,0x28,0x2,0x1e,0x8c,0x9d}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_PROCESS_LOCAL_Attribute = 
{0x543186e4,0x4649,0x4e65,{0xb5,0x88,0x4a,0xa3,0x52,0xaf,0xf3,0x79}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_PREFERRED_ENCODER_PROFILE = 
{0x53004909,0x1ef5,0x46d7,{0xa1,0x8e,0x5a,0x75,0xf8,0xb5,0x90,0x5f}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_HW_TIMESTAMP_WITH_QPC_Attribute = 
{0x8d030fb8,0xcc43,0x4258,{0xa2,0x2e,0x92,0x10,0xbe,0xf8,0x9b,0xe4}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_FIELDOFUSE_UNLOCK_Attribute = 
{0x8ec2e9fd,0x9148,0x410d,{0x83,0x1e,0x70,0x24,0x39,0x46,0x1a,0x8e}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_CODEC_MERIT_Attribute = 
{0x88a7cb15,0x7b07,0x4a34,{0x91,0x28,0xe6,0x4c,0x67,0x3,0xc4,0xd3}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_ENUM_TRANSCODE_ONLY_ATTRIBUTE = 
{0x111ea8cd,0xb62a,0x4bdb,{0x89,0xf6,0x67,0xff,0xcd,0xc2,0x45,0x8b}};
+const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CLSID = 
{{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x01};
+const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CATEGORY = 
{{0xc57a84c0,0x1

Re: [Mingw-w64-public] [PATCH 2/2] headers: Remove superfluous EXTERN_C when defining variables

[Martin Storsjö]

On Thu, 19 Mar 2020, Liu Hao wrote:


在 2020/3/19 20:35, Martin Storsjö 写道:

For C++, the generated .h encloses this block in 'extern "C" { .. }'
anyway, and as these are variable definitions (with DECLSPEC_SELECTANY,
avoiding duplicate definitions even though it's in a header), not
declarations, GCC (and possibly clang as well) warn when the definition
also contains the 'extern' attribute.

This fixes the same warning as d551b7d85ec63c0fa33f1a51ec5157722709fc53
tried to fix, without overriding the EXTERN_C macro, which affected
other headers.

Signed-off-by: Martin Storsjö 
---



The first patch looks good - but it can't be pushed unless we find a
workaround for this issue.


Well, technically, if reverted we just get warnings - but right now with 
EXTERN_C being clobbered, I'm running into cases with duplicate 
definitions elsewhere, with compilers that default to -fno-common. So on 
its own, it trades brokenness for some warnings. But yeah, we want to fix 
the warnings.



In C++ a variable (object or reference) having namespace scope and being
declared with `const` and without `volatile` or `extern` has internal
linkage (as if it was declared `static const`) [1]. This is true
regardless whether it is inside an `extern "C"` block or not.


Oh, I didn't know this, thanks for catching it. Indeed, in this form, the 
header after my patches makes both GCC and Clang error out with errors 
like "error: ‘selectany’ attribute applies only to initialized variables 
with external linkage".



If these constant objects had internal linkage, then for example
`_CLSID` in two different source files will yield two different
values due to duplication.

From my experience the best solution would look like this, which works
both in C and C++:
```
extern const PROPERTYKEY MFPKEY_CLSID;
 // declaration with `extern`
DECLSPEC_SELECTANY const PROPERTYKEY MFPKEY_CLSID
 = { ... };  // definition with `__selectany__`
```

But this requires the declarator to be written twice.


A different alternative is to define a different macro to be used here, 
like this:


#ifndef __DEFINE_CONST_EXTERN
#ifdef __cplusplus
#define __DEFINE_CONST_EXTERN extern "C" const
#else
#define __DEFINE_CONST_EXTERN const
#endif
#endif

(A quick grep didn't find any preexisting define with that semantic.)

Right now, out of the combinations {GCC,Clang} x {C,C++}, only GCC in C 
mode warns on a line like "extern __declspec(selectany) const PROPERTYKEY 
MFPKEY_CLSID = { ... };". So if including extern only in C++ mode, due to 
the differing linkage rules for const variables, this should avoid all 
warnings and avoid duplicating the list of declarations.


What do you think, is that preferrable, or should we just bite the bullet 
and add explicit declarations?


// Martin

___
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 a custom macro for declaring extern const variables

[Martin Storsjö]

This fixes the same warning as d551b7d85ec63c0fa33f1a51ec5157722709fc53
(warnings due to declaring a variable as extern and initializing it
at the same time) tried to fix, without overriding the EXTERN_C macro,
which affected other headers.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-headers/include/mftransform.h   | 58 -
 mingw-w64-headers/include/mftransform.idl | 62 ++-
 2 files changed, 71 insertions(+), 49 deletions(-)

diff --git a/mingw-w64-headers/include/mftransform.h 
b/mingw-w64-headers/include/mftransform.h
index 2e5877303..de9c3a7db 100644
--- a/mingw-w64-headers/include/mftransform.h
+++ b/mingw-w64-headers/include/mftransform.h
@@ -1,4 +1,4 @@
-/*** Autogenerated by WIDL 4.12.1 from include/mftransform.idl - Do not edit 
***/
+/*** Autogenerated by WIDL 5.0-rc1 from ../include/mftransform.idl - Do not 
edit ***/
 
 #ifdef _WIN32
 #ifndef __REQUIRED_RPCNDR_H_VERSION__
@@ -509,30 +509,38 @@ static FORCEINLINE HRESULT 
IMFTransform_ProcessOutput(IMFTransform* This,DWORD d
 
 #endif  /* __IMFTransform_INTERFACE_DEFINED__ */
 
-EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CLSID = 
{{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x01};
-EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CATEGORY = 
{{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x02 };
-EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_EXATTRIBUTE_SUPPORTED = 
{{0x456fe843,0x3c87,0x40c0,{0x94,0x9d,0x14,0x9,0xc9,0x7d,0xab,0x2c}}, 0x01};
-EXTERN_C const DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_MULTICHANNEL_CHANNEL_MASK 
 = {{0x58bdaf8c,0x3224,0x4692,{0x86,0xd0,0x44,0xd6,0x5c,0x5b,0xf8,0x2b}}, 0x01};
-EXTERN_C const DECLSPEC_SELECTANY GUID MF_SA_D3D_AWARE = 
{0xeaa35c29,0x775e,0x488e,{0x9b,0x61,0xb3,0x28,0x3e,0x49,0x58,0x3b}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MF_SA_REQUIRED_SAMPLE_COUNT = 
{0x18802c61,0x324b,0x4952,{0xab,0xd0,0x17,0x6f,0xf5,0xc6,0x96,0xff}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MF_TRANSFORM_ASYNC = 
{0xf81a699a,0x649a,0x497d,{0x8c,0x73,0x29,0xf8,0xfe,0xd6,0xad,0x7a}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MF_TRANSFORM_ASYNC_UNLOCK = 
{0xe5666d6b,0x3422,0x4eb6,{0xa4,0x21,0xda,0x7d,0xb1,0xf8,0xe2,0x7}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MF_TRANSFORM_FLAGS_Attribute = 
{0x9359bb7e,0x6275,0x46c4,{0xa0,0x25,0x1c,0x1,0xe4,0x5f,0x1a,0x86}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MF_TRANSFORM_CATEGORY_Attribute = 
{0xceabba49,0x506d,0x4757,{0xa6,0xff,0x66,0xc1,0x84,0x98,0x7e,0x4e}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_TRANSFORM_CLSID_Attribute = 
{0x6821c42b,0x65a4,0x4e82,{0x99,0xbc,0x9a,0x88,0x20,0x5e,0xcd,0xc}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_INPUT_TYPES_Attributes = 
{0x4276c9b1,0x759d,0x4bf3, {0x9c,0xd0,0xd,0x72,0x3d,0x13,0x8f,0x96}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_OUTPUT_TYPES_Attributes = 
{0x8eae8cf3,0xa44f,0x4306,{0xba,0x5c,0xbf,0x5d,0xda,0x24,0x28,0x18}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_ENUM_HARDWARE_URL_Attribute = 
{0x2fb866ac,0xb078,0x4942,{0xab,0x6c,0x0,0x3d,0x5,0xcd,0xa6,0x74}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_FRIENDLY_NAME_Attribute = 
{0x314ffbae,0x5b41,0x4c95,{0x9c,0x19,0x4e,0x7d,0x58,0x6f,0xac,0xe3}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_CONNECTED_STREAM_ATTRIBUTE  = 
{0x71eeb820,0xa59f,0x4de2,{0xbc,0xec,0x38,0xdb,0x1d,0xd6,0x11,0xa4}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_CONNECTED_TO_HW_STREAM = 
{0x34e6e728,0x6d6,0x4491,{0xa5,0x53,0x47,0x95,0x65,0xd,0xb9,0x12}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_PREFERRED_OUTPUTTYPE_Attribute = 
{0x7e700499,0x396a,0x49ee,{0xb1,0xb4,0xf6,0x28,0x2,0x1e,0x8c,0x9d}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_PROCESS_LOCAL_Attribute = 
{0x543186e4,0x4649,0x4e65,{0xb5,0x88,0x4a,0xa3,0x52,0xaf,0xf3,0x79}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_PREFERRED_ENCODER_PROFILE = 
{0x53004909,0x1ef5,0x46d7,{0xa1,0x8e,0x5a,0x75,0xf8,0xb5,0x90,0x5f}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_HW_TIMESTAMP_WITH_QPC_Attribute = 
{0x8d030fb8,0xcc43,0x4258,{0xa2,0x2e,0x92,0x10,0xbe,0xf8,0x9b,0xe4}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_FIELDOFUSE_UNLOCK_Attribute = 
{0x8ec2e9fd,0x9148,0x410d,{0x83,0x1e,0x70,0x24,0x39,0x46,0x1a,0x8e}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_CODEC_MERIT_Attribute = 
{0x88a7cb15,0x7b07,0x4a34,{0x91,0x28,0xe6,0x4c,0x67,0x3,0xc4,0xd3}};
-EXTERN_C const DECLSPEC_SELECTANY GUID MFT_ENUM_TRANSCODE_ONLY_ATTRIBUTE = 
{0x111ea8cd,0xb62a,0x4bdb,{0x89,0xf6,0x67,0xff,0xcd,0xc2,0x45,0x8b}};
+#ifndef __DEFINE_EXTERN_CONST
+#ifdef __cplusplus
+#define __DEFINE_EXTERN_CONST extern "C" const
+#else
+#define __DEFINE_EXTERN_CONST const
+#endif
+#endif
+
+__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CLSID = 
{{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0xae}}, 0x01};
+__DEFINE_EXTERN_CONST DECLSPEC_SELECTANY PROPERTYKEY MFPKEY_CATEGORY = 
{{0xc57a84c0,0x1a80,0x40a3,{0x97,0xb5,0x92,0x72,0xa4,0x3,0xc8,0x

Re: [Mingw-w64-public] [PATCH v2 2/2] headers: Use a custom macro for declaring extern const variables

[Martin Storsjö]

On Thu, 19 Mar 2020, Liu Hao wrote:


在 2020/3/19 23:02, Martin Storsjö 写道:

This fixes the same warning as d551b7d85ec63c0fa33f1a51ec5157722709fc53
(warnings due to declaring a variable as extern and initializing it
at the same time) tried to fix, without overriding the EXTERN_C macro,
which affected other headers.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-headers/include/mftransform.h   | 58 -
 mingw-w64-headers/include/mftransform.idl | 62 ++-
 2 files changed, 71 insertions(+), 49 deletions(-)





LGTM.


Thanks, will push tomorrow unless my testing shows that anything trips up 
by it.



BTW, do we have to commit the generated header in a separated patch
other than the IDL itself?


I guess it'd be nicer to separate it into functional change and 
autogeneration, but the revert commit contains both in the same. It's at 
least more readable than Makefile.in changes...


// Martin

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

Re: [Mingw-w64-public] [PATCH v2 2/2] headers: Use a custom macro for declaring extern const variables

[Martin Storsjö]

On Fri, 20 Mar 2020, Martin Storsjö wrote:


On Thu, 19 Mar 2020, Liu Hao wrote:


在 2020/3/19 23:02, Martin Storsjö 写道:

This fixes the same warning as d551b7d85ec63c0fa33f1a51ec5157722709fc53
(warnings due to declaring a variable as extern and initializing it
at the same time) tried to fix, without overriding the EXTERN_C macro,
which affected other headers.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-headers/include/mftransform.h   | 58 -
 mingw-w64-headers/include/mftransform.idl | 62 ++-
 2 files changed, 71 insertions(+), 49 deletions(-)





LGTM.


Thanks, will push tomorrow unless my testing shows that anything trips up 
by it.



BTW, do we have to commit the generated header in a separated patch
other than the IDL itself?


I guess it'd be nicer to separate it into functional change and 
autogeneration, but the revert commit contains both in the same. It's at 
least more readable than Makefile.in changes...


Pushed with both .h and .idl in the same commit, for easier revertability 
in case there's other issues found in it.


// Martin

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

Re: [Mingw-w64-public] [PATCH] headers: Fix the return value for swprintf and vswprintf for UCRT

[Martin Storsjö]

On Tue, 10 Mar 2020, Liu Hao wrote:


在 2020/3/10 20:09, Martin Storsjö 写道:


Yes, it is. The UCRT in modern WinSDK doesn't have any vsnwprintf
function at all - so ideally we probably shouldn't have one either
(unless users of mingw-w64 have started using i).

In this case, the swprintf.inl header forwards calls from swprintf to
vswprintf, which forwards them onwards to vsnwprintf. These codepaths
are shared between msvcrt.dll and UCRT at the moment, with vsnwprintf
being the actual implementation for swprintf/vswprintf. So with that,
it's probably fine to have vsnwprintf have the behaviour of vswprintf.

Sorting out this mess probably would be welcome, but I think that's
orthogonal to this patch.



I suspect that `UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR` controls
what to return (the number of characters that would have been written in
case of insufficient space, or a negative value) and whether a null
terminator is added.


UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR affects the return value, 
whether it should return a negative value on overflow, or the needed full 
string length.


UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION affects whether the 
buffer is null terminated if the string didn't fit.


So for the case of swprintf(), where the standard says it should return a 
negative number on truncation, we achieve this by removing 
UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR.


The standard doesn't say whether the buffer should be null terminated in 
this case, but MSVC does null terminate it in swprintf(). To match this, 
we don't set UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION here.


May I ask, what is the purpose of normalization of negative return 
values to -1?


Primarily for consistency, as this is what the WinSDK UCRT inline 
functions do.


If UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR is left out, 
__stdio_common_vswprintf returns -1 if 
UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION is set, but returns -2 if 
UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION is left out. In WinSDK 
UCRT inline functions, this is then normalized back to -1 before 
returning.


// Martin

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

Re: [Mingw-w64-public] [PATCH v3 01/10] crt: use GetEnvironmentVariableW in getopt

[Martin Storsjö]

On Mon, 27 Apr 2020, Steve Lhomme wrote:


The API is available since Windows XP and available in UWP for win8 and win10.

This avoids relying on getenv() from winstorecompat that returns NULL and can't
be reimplemented in a clean way.
---
mingw-w64-crt/misc/getopt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mingw-w64-crt/misc/getopt.c b/mingw-w64-crt/misc/getopt.c
index ac1fda42..ac7f9fe1 100644
--- a/mingw-w64-crt/misc/getopt.c
+++ b/mingw-w64-crt/misc/getopt.c
@@ -345,7 +345,7 @@ getopt_internal(int nargc, char * const *nargv, const char 
*options,
 * optreset != 0 for GNU compatibility.
 */
if (posixly_correct == -1 || optreset != 0)
-   posixly_correct = (getenv("POSIXLY_CORRECT") != NULL);
+   posixly_correct = (GetEnvironmentVariableW(L"POSIXLY_CORRECT", 
NULL, 0) != 0);
if (*options == '-')
flags |= FLAG_ALLARGS;
else if (posixly_correct || *options == '+')
--
2.17.1


This looks good, so I pushed it.

// Martin



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

Re: [Mingw-w64-public] [PATCH v3 07/10] headers: allow some forbidden functions winstore calls with WINSTORECOMPAT

[Martin Storsjö]

On Mon, 27 Apr 2020, Steve Lhomme wrote:


The stubs don't do anything but they are used by the crt.
---
mingw-w64-headers/include/winnt.h | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)


I think these aren't used unconditionally by the crt any longer, since 
e6ac7e4230c9f075c1c243e9c2ce2ec56bbf900c and 
fd5d6c8fd13b9c32402e00daae9853495df04465, so I think this patch isn't 
really necessary any longer?


// Martin



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

Re: [Mingw-w64-public] [PATCH v3 06/10] headers: allow CreateFileW/GetFileSize in winstore builds

[Martin Storsjö]

On Mon, 27 Apr 2020, Steve Lhomme wrote:


They are implemented in winstorecompat so they should be available.
---
mingw-w64-headers/include/fileapi.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)


This looks good, so I pushed it.

// Martin



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

Re: [Mingw-w64-public] [PATCH v3 03/10] crt: use UWP allowed API's in __mingw_fwrite

[Martin Storsjö]

On Mon, 27 Apr 2020, Steve Lhomme wrote:


GetFileSize is not allowed.

Switching to GetFileSizeEx and SetFilePointerEx makes the types and comparison
cleaner.
Both API's are available in XP as the one they replace.
---
mingw-w64-crt/misc/mingw-fseek.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/mingw-w64-crt/misc/mingw-fseek.c b/mingw-w64-crt/misc/mingw-fseek.c
index 3ae7d856..c9f07305 100644
--- a/mingw-w64-crt/misc/mingw-fseek.c
+++ b/mingw-w64-crt/misc/mingw-fseek.c
@@ -39,30 +39,26 @@ __mingw_fwrite (const void *buffer, size_t size, size_t 
count, FILE *fp)
# undef fwrite
  if ((_osver & 0x8000) &&  __mingw_fseek_called)


Unrelated to this particular patch, but this seems to use _osver, which is 
a data member exported by msvcrt.dll, but not available in UCRT. So even 
if we fix this up, this particular object file wouldn't link successfully 
with UCRT.


We could try to change headers to use a different accessor for _osver 
(see e.g. 2e64b9e4537d564478f17b873b2f655f518325ed as example of that), 
and provide some fallback for it in crt/ucrtbase_compat.c.


However... I don't see a single reference to __mingw_fwrite anywhere in 
the source tree, same thing with __mingw_fseek. Is this expanded by some 
macro somewhere, e.g. concatenating "__mingw_" with "fwrite"? Or is it the 
case that this whole file is unreferenced by anything else and not 
declared in headers? In that case I think we should be able to just delete 
it outright.


// Martin




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

Re: [Mingw-w64-public] [PATCH v3 05/10] winstorecompat: provide GetUserName

[Martin Storsjö]

On Tue, 28 Apr 2020, Steve Lhomme wrote:


On 2020-04-27 19:59, Jacek Caban wrote:

On 27.04.2020 19:55, Jean-Baptiste Kempf wrote:


On Mon, Apr 27, 2020, at 19:40, Jacek Caban wrote:

On 27.04.2020 16:31, Steve Lhomme wrote:

It's needed by:
- getlogin() in mingwex


Could we prohibit getlogin() on non-desktop in headers instead?


It's doable. It is risky as some code may call it without including the 
appropriate header. So even if they are compiled with the right windows 
version/winapi family they might still not pick the right redirection.


I don't see that as a huge risk so I wouldn't mind that approach either. 
But there is some value in being able to verify that mingw-w64-crt doesn't 
use anything unsupported by building it in UWP mode, so I'm a little in 
favour of this patch anyway.



Or call directly GetEnvironment directly?



If it works on all relevant Windows versions, that sounds good.


MSDN says it's supported since XP so I suppose so, but I can't guarantee it. 
I can only test on windows 10 at the moment.


Did I understand it correctly (from the patch, which has the code within 
"#if _WIN32_WINNT >= _WIN32_WINNT_WIN10") that GetEnvironmentVariable is 
supported in UWP (10) but not WinStore on 8?


In that case, I'd prefer not to inline the call further up but just keep 
it winstorecompat - so that on Win 8 it'd be a stub function that just 
returns a failure.


(Also for patch 1/10 that I already pushed, which changed getenv() into 
GetEnvironmentVariable in misc/getopt.c, that's a bit unfortunate wrt Win 
8 - I hadn't thought about that aspect when I applied it. But on the other 
hand, we could add a GetEnvironmentVariable in winstorecompat that just 
returns errors, for Win 8.)



Jacek, can you follow up on the discussion above?

// Martin



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

Re: [Mingw-w64-public] [PATCH v3 08/10] winstorecompat: allow building with code that needs codeGeneration capability

[Martin Storsjö]

On Mon, 27 Apr 2020, Steve Lhomme wrote:


By default winstorecompat is built without the need for this capability.

VirtualProtect may be mapped to VirtualProtectFromApp but only if the app has
the codeGeneration capability. It is needed when compiling UNIX code with
relocatable sections that are relocated at runtime.

VirtualProtectFromApp is only available if compiled to target win10.

https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualprotectfromapp
https://docs.microsoft.com/en-us/windows/uwp/packaging/app-capability-declarations
---
.../winstorecompat/Makefile.in|  51 ++--
mingw-w64-libraries/winstorecompat/configure  | 254 +++---
.../winstorecompat/configure.ac   |  11 +
.../winstorecompat/src/VirtualProtect.c   |  13 +
4 files changed, 273 insertions(+), 56 deletions(-)



diff --git a/mingw-w64-libraries/winstorecompat/src/VirtualProtect.c 
b/mingw-w64-libraries/winstorecompat/src/VirtualProtect.c
index 88fd06bc..5801a69d 100644
--- a/mingw-w64-libraries/winstorecompat/src/VirtualProtect.c
+++ b/mingw-w64-libraries/winstorecompat/src/VirtualProtect.c
@@ -22,6 +22,10 @@
DEALINGS IN THE SOFTWARE.
*/

+#ifdef HAVE_CONFIG_H
+# include "config.h"
+#endif
+
#define VirtualProtect __VirtualProtect
#include 
#include 
@@ -30,8 +34,17 @@

BOOL WINAPI VirtualProtect(LPVOID lpAddress, SIZE_T dwSize, DWORD flNewProtect, 
PDWORD lpflOldProtect)
{
+#if defined(HAVE_CODE_GENERATION) && _WIN32_WINNT >= _WIN32_WINNT_WIN10
+ULONG OldProtection;
+BOOL res = VirtualProtectFromApp(lpAddress, dwSize, flNewProtect,
+ lpflOldProtect ?  : NULL);
+if (lpflOldProtect)
+*lpflOldProtect = OldProtection;
+return res;
+#else /* !HAVE_CODE_GENERATION */


Would there be any harm in removing the whole configure option? If I read 
MSDN correctly, only certain flags to VirtualProtectFromApp are disallowed 
(and some flags requires codeGeneration while others are totally fine) - 
so it should be fine to keep the function call. And as long as it actually 
isn't called at runtime, it's fine either way.


(I'm generally fine with the patch, but if it's possible to skip the 
configure option I'd prefer that. But I'd probably rewrite bits of the 
commit message before pushing.)


// Martin



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

Re: [Mingw-w64-public] [PATCH v3 04/10] crt: use WCHAR API's in WspiapiLoad

[Martin Storsjö]

On Mon, 27 Apr 2020, Steve Lhomme wrote:


They are more likely to be available in UWP and we already provide a
LoadLibraryW replacement otherwise.
---
mingw-w64-crt/libsrc/wspiapi/WspiapiLoad.c | 16 
1 file changed, 8 insertions(+), 8 deletions(-)


This looks ok with me in general, but I'm pretty strongly of the opinion 
that we should have a LoadLibraryA in winstorecompat anyway (for the delay 
load helper), so I'll hold off pushing this one.


// Martin



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

Re: [Mingw-w64-public] [PATCH v3 05/10] winstorecompat: provide GetUserName

[Martin Storsjö]

On Wed, 6 May 2020, Jacek Caban wrote:


On 06.05.2020 15:09, Martin Storsjö wrote:

Or call directly GetEnvironment directly?



If it works on all relevant Windows versions, that sounds good.


MSDN says it's supported since XP so I suppose so, but I can't 
guarantee it. I can only test on windows 10 at the moment.


Did I understand it correctly (from the patch, which has the code 
within "#if _WIN32_WINNT >= _WIN32_WINNT_WIN10") that 
GetEnvironmentVariable is supported in UWP (10) but not WinStore on 8?


In that case, I'd prefer not to inline the call further up but just 
keep it winstorecompat - so that on Win 8 it'd be a stub function that 
just returns a failure.



Sounds good to me.


Ok, great - then I'll apply this patch (with autogenerated changes split 
to a separate commit). It'll be for a bit later (tonight/tomorrow) though. 
And I'd like to have an ack from Steve on the fact that 
GetEnvironmentVariable indeed is available for "store" only in 10 aka UWP?


// Martin

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

Re: [Mingw-w64-public] [PATCH v3 02/10] crt: use UWP allowed API's in ftruncate64

[Martin Storsjö]

On Mon, 27 Apr 2020, Steve Lhomme wrote:


GetFileInformationByHandle, FindFirstVolumeW, FindNextVolumeW, FindVolumeClose
are not allowed.

GetFinalPathNameByHandleW is allowed in win8 and win10
https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis
https://docs.microsoft.com/en-us/windows/win32/apiindex/windows-8-api-sets

We read the path with a GUID which can then be truncated and used with
GetDiskFreeSpaceExW().

ftruncate64 is provided in mingwex
---
mingw-w64-crt/stdio/ftruncate64.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)

diff --git a/mingw-w64-crt/stdio/ftruncate64.c 
b/mingw-w64-crt/stdio/ftruncate64.c
index ec597e20..7991c2aa 100644
--- a/mingw-w64-crt/stdio/ftruncate64.c
+++ b/mingw-w64-crt/stdio/ftruncate64.c
@@ -134,9 +134,7 @@ checkfreespace (const HANDLE f, const ULONGLONG 
requiredspace)
  LPWSTR dirpath, volumeid, volumepath;
  ULARGE_INTEGER freespace;
  LARGE_INTEGER currentsize;
-  DWORD check, volumeserial;
-  BY_HANDLE_FILE_INFORMATION fileinfo;
-  HANDLE vol;
+  DWORD check;

  /* Get current size */
  check = GetFileSizeEx (f, );
@@ -191,34 +189,29 @@ checkfreespace (const HANDLE f, const ULONGLONG 
requiredspace)
#endif /* _CHECK_SPACE_BY_PSAPI_METHOD_ */

#if _CHECK_SPACE_BY_VOLUME_METHOD_
-  if(!GetFileInformationByHandle(f,)) {
+  DWORD size_needed = GetFinalPathNameByHandleW(f, NULL, 0, 
FILE_NAME_OPENED|VOLUME_NAME_GUID);
+  if (!size_needed) {
_set_errno(EINVAL);
return -1; /* Resolution failure */
  }

-  volumeid = calloc(51,sizeof(wchar_t));
-  volumepath = calloc(MAX_PATH+2,sizeof(wchar_t));
-  if(!volumeid || !volumepath) {
+  volumeid = malloc(size_needed*sizeof(wchar_t));
+  if(!volumeid) {
  _set_errno(EBADF);
return -1; /* Out of memory */
  }

  dirpath = NULL;

-  vol = FindFirstVolumeW(volumeid,50);
-  /* wprintf(L"%d - %ws\n",wcslen(volumeid),volumeid); */
-  do {
-check = 
GetVolumeInformationW(volumeid,volumepath,MAX_PATH+1,,NULL,NULL,NULL,0);
-/* wprintf(L"GetVolumeInformationW %d id %ws path %ws error 
%d\n",check,volumeid,volumepath,GetLastError()); */
-if(volumeserial == fileinfo.dwVolumeSerialNumber) {
-  dirpath = volumeid;
-  break;
+  if (GetFinalPathNameByHandleW(f, volumeid, size_needed, 
FILE_NAME_OPENED|VOLUME_NAME_GUID)) {
+volumepath = wcsstr(volumeid, L"}\\");
+if(volumepath) {
+  volumepath[2] = 0;
+  dirpath = volumeid;
}
-  } while (FindNextVolumeW(vol,volumeid,50));
-  FindVolumeClose(vol);
+  }

  if(!dirpath) free(volumeid); /* we found the volume */
-  free(volumepath);
#endif /* _CHECK_SPACE_BY_VOLUME_METHOD_ */

  /* Get available free space */
--
2.17.1


This essentially transforms the code within the 
_CHECK_SPACE_BY_VOLUME_METHOD_ block into what already is there, in the 
_CHECK_SPACE_BY_VISTA_METHOD_ block. Unfortunately, as that name implies, 
it uses vista-only functions, which we can't unfortunately use in 
mingw-w64-crt (yet).


Not sure what is the best way forward on this one... Maybe look into what 
_CHECK_SPACE_BY_PSAPI_METHOD_ does and why that wasn't used to begin with. 
(It looks like it might use some XP specific method, which might not have 
been ok to use back when this was written, but which is ok now?)


Emulating the GetFileInformationByHandle call in winstorecompat might be 
possible, but FindFirstVolumeW does look annoying, so that's clearly not 
ideal...



// Martin



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

Re: [Mingw-w64-public] [PATCH 8/9] winstorecompat: allow building with code that needs codeGeneration capability

[Martin Storsjö]

On Mon, 27 Apr 2020, Martin Storsjö wrote:


On Fri, 24 Apr 2020, Martin Storsjö wrote:


On Fri, 24 Apr 2020, Steve Lhomme wrote:


By default winstorecompat is built without the need for this capability.

VirtualProtect may be mapped to VirtualProtectFromApp but only if the app 
has

the codeGeneration capability. It is needed when compiling UNIX code with
relocatable sections that are relocated at runtime.


More precisely, it's used by the code for fixing up pseudo relocations.

Even if we do this mapping to VirtualProtectFromApp, the code in 
"mark_section_writable" won't actually work with VirtualProtectFromApp, 
because it tries to set the permission PAGE_EXECUTE_READWRITE.


Right now, the mark_section_writable tries to change the protection on a 
whole section at a time (e.g. in practice do it once for the whole .text 
section). But to make it work with VirtualProtectFromApp, one would have to 
change the permission from PAGE_EXECUTE_READ, to PAGE_READWRITE, do the 
fixups, and back to PAGE_EXECUTE_READ. But as the code that is executing 
right now also lives in the same text section, it would stop itself from 
running. So to make that work, it would be necessary to make the code in 
this file be placed in a different section (with the same properties as 
.text) - or do more granular calls to VirtualProtectFromApp, on a page 
level (and hope that none of the pseudo relocations happen to be in the 
same page as the code that fixes them up).


Actually - VirtualProtectFromApp will most probably work fine for these 
cases. If LLVM thinks a variable reference might be from another DLL (i.e. 
the variable definition isn't visible within the same translation unit), it 
will redirect all the accesses via a .refptr. stub. This means that at 
runtime, it won't need to do any fixups in the .text section, only in .rdata. 
So in practice, with code built by LLVM, it will only need to do 
VirtualProtect on .rdata, which should be fine.


But avoiding the whole feature is safest and sanest in general - I just sent 
a patch for implementing --disable-runtime-pseudo-reloc in LLD.


That lld patch is approved now FWIW, but I realized I want to refine it a 
bit further.


I also came to think about another trick I implemented in lld - for the 
cases where the address is in a .refptr$ stub, lld can 
actually swap that out for the IAT entry, so for all such cases, there 
won't even be any pseudo relocations to fix up. There's only cases with 
e.g. global variables initialized to the address of an auto imported 
variable that can't be fixed.


// Martin

___
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 the unused mingw-fseek.c

[Martin Storsjö]

The functions in this file, __mingw_fseek/__mingw_fseeko64/__mingw_fwrite
haven't ever been used within mingw-w64 throughout the SCM history,
but were originally intended to work around issues with seeking past
the end of files on Win9x.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-crt/Makefile.am|   2 +-
 mingw-w64-crt/misc/mingw-fseek.c | 104 ---
 2 files changed, 1 insertion(+), 105 deletions(-)
 delete mode 100644 mingw-w64-crt/misc/mingw-fseek.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 86b0b0d73..03db86c3a 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -442,7 +442,7 @@ src_libmingwex=\
   misc/feraiseexcept.c   misc/fesetenv.cmisc/fesetexceptflag.c  
misc/fesetround.cmisc/fetestexcept.c\
   misc/feupdateenv.c misc/ftruncate.c   misc/fwide.c
misc/getlogin.c  misc/getopt.c  \
   misc/gettimeofday.cmisc/imaxabs.c misc/imaxdiv.c  
misc/isblank.c   misc/iswblank.c\
-  misc/mempcpy.c misc/mingw-aligned-malloc.c misc/mingw-fseek.c \
+  misc/mempcpy.c misc/mingw-aligned-malloc.c \
   misc/mingw_matherr.c   misc/mingw_mbwc_convert.c  misc/mingw_usleep.c 
misc/mingw_wcstod.c  misc/mingw_wcstof.c\
   misc/mingw_wcstold.c   misc/mkstemp.c misc/seterrno.c 
misc/sleep.c  \
   misc/strnlen.c misc/strsafe.c \
diff --git a/mingw-w64-crt/misc/mingw-fseek.c b/mingw-w64-crt/misc/mingw-fseek.c
deleted file mode 100644
index 3ae7d8567..0
--- a/mingw-w64-crt/misc/mingw-fseek.c
+++ /dev/null
@@ -1,104 +0,0 @@
-/**
- * This file has no copyright assigned and is placed in the Public Domain.
- * This file is part of the mingw-w64 runtime package.
- * No warranty is given; refer to the file DISCLAIMER.PD within this package.
- */
-#include 
-#include 
-#include 
-#include 
-
-#define ZEROBLOCKSIZE 512
-static int __mingw_fseek_called;
-
-int __mingw_fseek (FILE *fp, int offset, int whence);
-
-int
-__mingw_fseek (FILE *fp, int offset, int whence)
-{
-# undef fseek 
-  __mingw_fseek_called = 1;
-  return fseek (fp, offset, whence);
-}
-
-int __mingw_fseeko64 (FILE *fp, long offset, int whence);
-
-int
-__mingw_fseeko64 (FILE *fp, long offset, int whence)
-{
-# undef fseeko64
-  __mingw_fseek_called = 1;
-  return fseeko64 (fp, offset, whence);
-}
-
-size_t __mingw_fwrite (const void *buffer, size_t size, size_t count, FILE 
*fp);
-
-size_t
-__mingw_fwrite (const void *buffer, size_t size, size_t count, FILE *fp)
-{
-# undef fwrite 
-  if ((_osver & 0x8000) &&  __mingw_fseek_called)
-{
-  ULARGE_INTEGER actual_length;
-  LARGE_INTEGER current_position;
-
-  memset (_position, 0, sizeof (LARGE_INTEGER));
-  __mingw_fseek_called = 0;
-  fflush (fp);
-  actual_length.LowPart = GetFileSize ((HANDLE) _get_osfhandle (fileno 
(fp)), 
-  _length.HighPart);
-  if (actual_length.LowPart == 0x 
-  && GetLastError() != NO_ERROR )
-return -1;
-  current_position.LowPart = SetFilePointer ((HANDLE) _get_osfhandle 
(fileno (fp)),
-current_position.LowPart,
-_position.HighPart,
-FILE_CURRENT);
-  if (current_position.LowPart == 0x
-  && GetLastError() != NO_ERROR )
-return -1;
-
-#ifdef DEBUG
-  printf ("__mingw_fwrite: current %I64u, actual %I64u\n", 
- current_position.QuadPart, actual_length.QuadPart);
-#endif /* DEBUG */
-  if ((size_t)current_position.QuadPart > (size_t)actual_length.QuadPart)
-   {
- static char __mingw_zeros[ZEROBLOCKSIZE];
- long long numleft;
-
- SetFilePointer ((HANDLE) _get_osfhandle (fileno (fp)), 
- 0, 0, FILE_END);
- numleft = current_position.QuadPart - actual_length.QuadPart;
-
-#ifdef DEBUG
- printf ("__mingw_fwrite: Seeking %I64d bytes past end\n", numleft);
-#endif /* DEBUG */
- while (numleft > 0LL)
-   {
- DWORD nzeros = (numleft > ZEROBLOCKSIZE)
-? ZEROBLOCKSIZE : numleft;
- DWORD written;
- if (! WriteFile ((HANDLE) _get_osfhandle (fileno (fp)),
-  __mingw_zeros, nzeros, , NULL))
-   {
- /* Best we can hope for, or at least DJ says so. */
- SetFilePointer ((HANDLE) _get_osfhandle (fileno (fp)), 
- 0, 0, FILE_BEGIN);
- return -1;
-   }
- if (written < nzeros)
-   {
- /* Likewise. */
- SetFilePointer ((HANDLE) _get_osfhandle (filen

Re: [Mingw-w64-public] [PATCH v3 05/10] winstorecompat: provide GetUserName

[Martin Storsjö]

On Thu, 7 May 2020, Steve Lhomme wrote:


On 2020-05-06 15:27, Martin Storsjö wrote:

On Wed, 6 May 2020, Jacek Caban wrote:


On 06.05.2020 15:09, Martin Storsjö wrote:

Or call directly GetEnvironment directly?



If it works on all relevant Windows versions, that sounds good.


MSDN says it's supported since XP so I suppose so, but I can't 
guarantee it. I can only test on windows 10 at the moment.


Did I understand it correctly (from the patch, which has the code 
within "#if _WIN32_WINNT >= _WIN32_WINNT_WIN10") that 
GetEnvironmentVariable is supported in UWP (10) but not WinStore on 8?


In that case, I'd prefer not to inline the call further up but just 
keep it winstorecompat - so that on Win 8 it'd be a stub function 
that just returns a failure.



Sounds good to me.


Ok, great - then I'll apply this patch (with autogenerated changes split 
to a separate commit). It'll be for a bit later (tonight/tomorrow) 
though. And I'd like to have an ack from Steve on the fact that 
GetEnvironmentVariable indeed is available for "store" only in 10 aka UWP?


You understood correctly. It's allowed in UWP since Windows 10.


Thanks, I pushed this one.

I made a small fixup before pushing, I had to remove WINADVAPI from the 
function definition, as it otherwise errored out with "error: dllimport 
cannot be applied to non-inline function definition" when building.


// Martin

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