On 4/24/20 1:30 PM, sisyphus wrote:
> Bloody Hell,
> I know it's not really spam, but could you guys at least address something
> that I care about (eg https://sourceforge.net/p/mingw-w64/bugs/728 )
> instead of all the piffle that has been filling this list of late ??
>
> Or maybe I should just u
Updated.
From 5af537ca20daf3f4fb0e1867e0321e8b7f66c01d Mon Sep 17 00:00:00 2001
From: Biswapriyo Nath
Date: Wed, 22 Apr 2020 20:36:18 +0530
Subject: [PATCH] headers: update schannel.h
Signed-off-by: Biswapriyo Nath
---
mingw-w64-headers/include/schannel.h | 365 +--
1 fi
在 2020/4/22 23:08, Biswapriyo Nath 写道:
> +typedef struct _SecPkgCred_ClientCertPolicy {
> + DWORD dwFlags;
> + GUID guidPolicyId;
> + DWORD dwCertFlags;
> + DWORD dwUrlRetrievalTimeout;
> + BOOL fCheckRevocationFreshnessTime;
Please use `WINBOOL` in place of `BOOL` here.
--
Best regards,
LH
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 j
It's needed by:
- getlogin() in mingwex
GetEnvironmentVariableA("USERNAME") gives the same information (tested on
win10 in cmd.exe and PowerShell).
No implementation provided when building winstorecompat for win8 as
GetEnvironmentVariableA is not allowed and GetUserNameEx requires -lsecur32.
---
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 sho
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
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(-)
diff --git a/mingw-w64-crt/libsrc/wspiapi/WspiapiLoad.c
b/mingw-w64-crt/l
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-
On 2020-04-24 15:28, Jacek Caban wrote:
On 24.04.2020 15:14, Steve Lhomme wrote:
On 2020-04-24 15:11, Jacek Caban wrote:
On 24.04.2020 14:35, Steve Lhomme wrote:
On 2020-04-24 14:30, Jacek Caban wrote:
On 24.04.2020 14:26, Steve Lhomme wrote:
On 2020-04-24 14:24, Jacek Caban wrote:
On
On 2020-04-24 15:26, Martin Storsjö wrote:
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
Bloody Hell,
I know it's not really spam, but could you guys at least address something
that I care about (eg https://sourceforge.net/p/mingw-w64/bugs/728 )
instead of all the piffle that has been filling this list of late ??
Or maybe I should just unsubscribe. I'll accept such a view as valid
adv
On 24.04.2020 15:14, Steve Lhomme wrote:
On 2020-04-24 15:11, Jacek Caban wrote:
On 24.04.2020 14:35, Steve Lhomme wrote:
On 2020-04-24 14:30, Jacek Caban wrote:
On 24.04.2020 14:26, Steve Lhomme wrote:
On 2020-04-24 14:24, Jacek Caban wrote:
On 24.04.2020 13:43, Steve Lhomme wrote:
This a
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 allo
On 2020-04-24 15:11, Jacek Caban wrote:
On 24.04.2020 14:35, Steve Lhomme wrote:
On 2020-04-24 14:30, Jacek Caban wrote:
On 24.04.2020 14:26, Steve Lhomme wrote:
On 2020-04-24 14:24, Jacek Caban wrote:
On 24.04.2020 13:43, Steve Lhomme wrote:
This avoids relying on getenv() from winstoreco
On 24.04.2020 14:35, Steve Lhomme wrote:
On 2020-04-24 14:30, Jacek Caban wrote:
On 24.04.2020 14:26, Steve Lhomme wrote:
On 2020-04-24 14:24, Jacek Caban wrote:
On 24.04.2020 13:43, Steve Lhomme wrote:
This avoids relying on getenv() from winstorecompat that returns
NULL and can't
be reimpl
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/mi
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 U
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 j
On 2020-04-24 14:58, 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 compilin
On 2020-04-24 14:42, Martin Storsjö wrote:
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 ++--
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
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
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
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
On 2020-04-24 14:30, Jacek Caban wrote:
On 24.04.2020 14:26, Steve Lhomme wrote:
On 2020-04-24 14:24, Jacek Caban wrote:
On 24.04.2020 13:43, Steve Lhomme wrote:
This avoids relying on getenv() from winstorecompat that returns
NULL and can't
be reimplemented in a clean way.
What's the prob
On 24.04.2020 14:26, Steve Lhomme wrote:
On 2020-04-24 14:24, Jacek Caban wrote:
On 24.04.2020 13:43, Steve Lhomme wrote:
This avoids relying on getenv() from winstorecompat that returns
NULL and can't
be reimplemented in a clean way.
What's the problem with getenv()? Would using _wgetenv i
On 2020-04-24 14:24, Jacek Caban wrote:
On 24.04.2020 13:43, Steve Lhomme wrote:
This avoids relying on getenv() from winstorecompat that returns NULL
and can't
be reimplemented in a clean way.
What's the problem with getenv()? Would using _wgetenv instead help?
According to this page it's
On 24.04.2020 13:43, Steve Lhomme wrote:
This avoids relying on getenv() from winstorecompat that returns NULL and can't
be reimplemented in a clean way.
What's the problem with getenv()? Would using _wgetenv instead help?
Jacek
___
Mingw-w64-pu
On Fri, Apr 24, 2020, at 14:13, Steve Lhomme wrote:
> On 2020-04-24 14:03, Jean-Baptiste Kempf wrote:
> > Hello,
> >
> > Even with the correct capability, VirtualProtectFromApp will not work with
> > PAGE_EXECUTE_READWRITE parameter, according to the documentation.
>
> Ah, I missed that. I guess
On 2020-04-24 14:07, Jean-Baptiste Kempf wrote:
While I agree with the general idea, I find that defines like:
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) ||
defined(WINSTORECOMPAT) || defined(WINSTORECOMPAT10)
are quite ugly, tbh.
For API's provided by both variants it could be def
On 2020-04-24 14:03, Jean-Baptiste Kempf wrote:
Hello,
Even with the correct capability, VirtualProtectFromApp will not work with
PAGE_EXECUTE_READWRITE parameter, according to the documentation.
Ah, I missed that. I guess this patch can be discarded as
PAGE_EXECUTE_READWRITE is exactly what
I updated my branch with these patches (autoreconf is needed after
applying these) https://github.com/robUx4/mingw-w64/tree/winstore-cleaning
There are extra patches to :
- build winstorecompat/winstorecompatapp with blocked forbidden UWP
calls (requires to install the latest headers before bui
While I agree with the general idea, I find that defines like:
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) ||
defined(WINSTORECOMPAT) || defined(WINSTORECOMPAT10)
are quite ugly, tbh.
On Fri, Apr 24, 2020, at 13:43, Steve Lhomme wrote:
> The original libwinstorecompat is designed to b
Hello,
Even with the correct capability, VirtualProtectFromApp will not work with
PAGE_EXECUTE_READWRITE parameter, according to the documentation.
Best,
On Fri, Apr 24, 2020, at 13:43, Steve Lhomme wrote:
> By default winstorecompat is built without the need for this capability.
>
> VirtualPr
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/
It's needed by:
- getlogin() in mingwex
GetEnvironmentVariableA("USERNAME") gives the same information (tested on
win10 in cmd.exe and PowerShell).
No implementation provided when building winstorecompat for win8 as
GetEnvironmentVariableA is not allowed and GetUserNameEx requires -lsecur32.
---
If they are implemented in winstorecompat they should be available.
---
mingw-w64-headers/include/fileapi.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-headers/include/fileapi.h
b/mingw-w64-headers/include/fileapi.h
index 373ca9fb..2c0115f2 100644
--- a/min
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.
VirtualProtectFromAp
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
- WaitFor
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/inclu
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 t
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 | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git
This patchset changes the CRT and winstorecompat so that the CRT can build
correctly when forcing WINAPI_FAMILY_APP for win8 and win10. A few calls in the
CRT glu has been modified to use allowed UWP calls while still maintaining
XP compatibility.
VirtualProtect is not available in UWP. There is V
The stubs don't do anything but they are used by the crt.
---
mingw-w64-headers/include/processthreadsapi.h | 11 +++
mingw-w64-headers/include/winnt.h | 30 +--
2 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/mingw-w64-headers/include/processthread
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 -
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
47 matches
Mail list logo
