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
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
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
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
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
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
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
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
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
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
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)
-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 |
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
- 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
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
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
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
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
(__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
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
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
---
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
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
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
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
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
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.
>>
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
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
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
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
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
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.
//
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
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
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
---
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
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
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
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
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 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
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
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
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/mft
o 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 +++
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
de
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
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
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
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
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
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
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
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
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
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
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
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 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
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 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
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
901 - 1000 of 1807 matches
Mail list logo
