On 9/5/21 4:54 PM, LIU Hao wrote:
在 2021-09-04 23:53, JonY via Mingw-w64-public 写道:
I am OK with updating them to use double quotes but have no strong
preference anyway since it has been using angular brackets for a long
time.
So this change is okay, but... I have noticed that wtypes.h i
Hi Jonathan,
On 9/3/21 11:48 PM, Jonathan Marler wrote:
Been another 4 days, anyone able to bring this patch in or review?
Your patch never arrived to the mailing list, it looks like the
attachment is missing.
Jacek
___
Mingw-w64-public maili
On 7/20/21 4:58 PM, John Warburton wrote:
On Tue, 20 Jul 2021 at 15:09, Biswapriyo Nath
wrote:
Apology for my mistake. It has been fixed today in wine by Jacek Caban
in this commit[1].
Thank you for checking this.
I am testing a build now.
Whoops. I forgot. That's Wine -- will wai
On 7/12/21 9:15 AM, LIU Hao wrote:
在 7/12/21 2:44 PM, Biswapriyo Nath 写道:
Would you like to upstream that change? I am not the author of that
commit and don't know why it was added. qt6-multimedia compiles fine
without that NTSTATUS re-definition.
FWIW, that typedef thing is a declaration, r
On 7/11/21 3:26 PM, Biswapriyo Nath wrote:
Option 1: Import propvarutil.h from wine. But that reverts this commit
propvarutil.h: Added NTSTATUS declaration (d603db2). Before that
commit propvarutil.h was imported from wine. I have compiled
qt6-multimedia without that NTSTATUS declaration.
Option
On 6/11/21 3:51 AM, Liu Hao wrote:
在 6/11/21 4:09 AM, Martin Storsjö 写道:
Since the initial commit of mingw-w64, there's a call (in a
constructor in crt/charmax.c, pulled in via the mingw_initcharmax
variable) to __lconv_init(), which reconfigures the CRT's lconv
info to unsigned char mode - but
On 20/05/2021 17:46, Liu Hao wrote:
在 2021-05-20 22:40, Jacek Caban 写道:
We could #undef __cpuid just after including cpuid.h.
Updated patch is attached.
The whole thing is really a hack, but I don't see a better solution, so
it looks fine to me.
Thanks,
On 5/20/21 4:37 PM, Liu Hao wrote:
在 2021-05-20 22:29, Jacek Caban 写道:
On 5/20/21 4:21 PM, Liu Hao wrote:
+#if (!defined(__GNUC__) || __GNUC__ < 11)
__MACHINEI(void __cpuid(int a[4],int b))
+#endif
__cpuid is a macro in both older GCCs and clang, so it will probably
not work th
On 5/20/21 4:21 PM, Liu Hao wrote:
+#if (!defined(__GNUC__) || __GNUC__ < 11)
__MACHINEI(void __cpuid(int a[4],int b))
+#endif
__cpuid is a macro in both older GCCs and clang, so it will probably not
work there. It's also present in intrin-impl.h.
Jacek
Hi Liu,
On 5/10/21 6:45 PM, Liu Hao wrote:
Subject: [PATCH] include/intrin-impl: Don't define `__cpuidex` for GCC 11
GCC 11 has this as a static inline function without any indicative
macros.
Reference:https://github.com/gcc-mirror/gcc/blob/23855a176609fe8dda6abaf2b21846b4517966eb/gcc/config/i
On 5/14/21 11:20 AM, Biswapriyo Nath wrote:
If an interface declaration is moved inside a namespace
__CRT_UUID_DECL produces error. The error is: explicit specialization
of 'template const GUID& __mingw_uuidof()' outside its
namespace must use a nested-name-specifier [-fpermissive].
A simple rep
On 15/05/2021 04:24, lhmouse wrote:
在 5/15/21 1:27 AM, Jacek Caban 写道:
I think that the decision was unfortunate on GCC side, but there is little we
can do. We will
probably need to provide it in msvcrt importlibs. Please try the attached
patch, it should help.
Doesn't GCC transform
Hi Alex,
On 5/14/21 3:01 AM, Alex Xu (Hello71) wrote:
Hi,
I tried building wine 6.8 with mingw. All fine, just one problem, it
reports error "undefined reference to `sincos'". Why, you may ask, since
wine never calls sincos function? Well, it seems to be because mingw gcc
11 enables sincos opti
On 5/3/21 2:52 PM, Martin Storsjö wrote:
On Mon, 3 May 2021, Christian Franke wrote:
Would plain '... = 0' without cast also work ? IIRC it should since
C89 :-)
That doesn't work either - clang seems to consider the cast (either
implicit or explicit) between a integer or pointer-to-integer a
On 31.03.2021 15:12, Martin Storsjö wrote:
On Wed, 31 Mar 2021, Liu Hao wrote:
在 2021/3/31 下午7:46, Martin Storsjö 写道:
Hmm, if MSVC defaults to a 64 bit time_t in 32 bit mode these days,
I think we should too, for UCRT. (Technically I guess it's an ABI
break, but I'd be quite comfortable doi
On 26/03/2021 12:22, Martin Storsjö wrote:
As there's no code that could be using the new UCRT spelling using any
public headers, there's nothing we can try to remain compatible with
in that case, so we'd only be setting new predecent (i.e. if building
with mingw headers, and iff targeting UCR
Hi Steve,
On 09.03.2021 15:03, Steve Lhomme wrote:
.../include/windows.foundation.collections.idl| 6 --
mingw-w64-headers/include/windows.foundation.idl | 8
2 files changed, 8 insertions(+), 6 deletions(-)
windows.foundation.collections.idl is imported
On 05.02.2021 13:14, Liu Hao wrote:
在 2021-02-05 15:16, JonY via Mingw-w64-public 写道:
Your attached patch seems fine to me, please go ahead and push.
Thanks, pushed. What about the others?
They all look good to me.
Thanks,
Jacek
___
Mingw
Hi,
Looks good to me, I pushed it.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On 11.01.2021 18:37, Biswapriyo Nath wrote:
Hmmm why aren't those IDLs imported from Wine?
1. Huge confusion. IExtractIcon is in -- shlobj_core.h in WinSDK,
shlobjidl.idl in wine, shlobj.h in mingw-w64.
2. Files differ largely between mingw-w64 and wine.
We still may import them, it's just mo
Hi Martin,
Sorry for the delay.
On 04.01.2021 21:16, Martin Storsjö wrote:
Hi,
On Mon, 4 Jan 2021, Jacek Caban wrote:
FWIW, I think that the attached patch should do the right thing on
VLC (but I don't really have setup to test it).
Thanks, looks like that could be enough - I'
On 31.12.2020 21:31, Martin Storsjö wrote:
On Thu, 31 Dec 2020, Jacek Caban wrote:
Yes, but the critical part is the very first sentence, which says
that 'you can specify which versions of Windows your code can run
on.'. Note the difference between *can* and *need*. When using
ming
On 28.12.2020 23:23, Martin Storsjö wrote:
On Mon, 28 Dec 2020, Jacek Caban wrote:
As long as the application does not use new APIs, its compatibility
with older Windows will not change.
And this bit:
This value is commonly mistaken with 'minimum version supported in
runtime'
On 28.12.2020 03:39, Liu Hao wrote:
在 2020/12/27 上午5:44, Martin Storsjö 写道:
I'm not entierely sure I agree with this - I think different ecosystems have
different expectations
here. (It'd be interesting to e.g. rebuild all of msys2's mingw package
repository with such
headers, and see how many
On 26.12.2020 22:44, Martin Storsjö wrote:
On Sat, 26 Dec 2020, Jacek Caban wrote:
Signed-off-by: Jacek Caban
---
I think it's reasonable to assume that the current default value of
Windows XP does not reflect reality. The new value deserves some
considerations. I propose to go all th
Signed-off-by: Jacek Caban
---
I think it's reasonable to assume that the current default value of
Windows XP does not reflect reality. The new value deserves some
considerations. I propose to go all the way to Windows 10 and match
Windows SDK.
The main concern about this is compatib
Hi Martin,
On 20.12.2020 10:14, Martin Storsjö wrote:
diff --git a/mingw-w64-tools/widl/include/windef.h
b/mingw-w64-tools/widl/include/windef.h
index b8e5ed692..a7dd5ce6a 100644
--- a/mingw-w64-tools/widl/include/windef.h
+++ b/mingw-w64-tools/widl/include/windef.h
@@ -74,7 +74,7 @@ extern "C"
Hi Biswapriyo,
Looks good, I pushed it.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On 13.12.2020 12:53, Liu Hao wrote:
They are declared in 'intrin.h' but were not defined anywhere.
The implementations might be imperfect: If the second argument is <= zero
or is >= the width of the first parameter, one of the shift counts will be
out of range and cause undefined behavior. Some
Hi Steve,
I pushed those patches and widl update. All IDLs can be successfully
regenerated now, thanks!
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Hi Steve,
On 15.12.2020 16:33, Steve Lhomme wrote:
Otherwise it results in a compilation error with widl 6.0-rc1:
include/bdatypes.h:43: error: 'PBDA_EVENT_ID': [v1_enum] attribute applied
to non-enum type
The code generated without this [v1_enum] is the same but we can keep this
informatio
On 15.12.2020 08:26, Steve Lhomme wrote:
On 2020-12-14 22:10, Jacek Caban wrote:
On 14.12.2020 09:30, Steve Lhomme wrote:
widl 6.0-rc1 doesn't generate them.
The IUnknown_QueryInterface_Proxy() is already hardcoded in
unknwnbase.idl.
Some methods still generate a proxy entry using &qu
Hi Steve,
On 14.12.2020 09:30, Steve Lhomme wrote:
widl 6.0-rc1 reports the following error:
include/wincrypt.idl:17: error: calling convention applied to non-function
type
FARPROC is not used in any IDL file anyway.
---
mingw-w64-headers/include/wincrypt.idl | 2 ++
1 file changed, 2 in
Signed-off-by: Jacek Caban
---
mingw-w64-headers/Makefile.am | 4
1 file changed, 4 insertions(+)
diff --git a/mingw-w64-headers/Makefile.am b/mingw-w64-headers/Makefile.am
index 68021a99..c7646998 100644
--- a/mingw-w64-headers/Makefile.am
+++ b/mingw-w64-headers/Makefile.am
@@ -274,6
Signed-off-by: Jacek Caban
---
So that msinkaut_i.c is regenerated.
mingw-w64-headers/Makefile.am | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-headers/Makefile.am b/mingw-w64-headers/Makefile.am
index 0b3aed0f..68021a99 100644
--- a/mingw-w64-headers
Hi Steve,
I extracted winrt part from the series and pushed it. Thanks!
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On 14.12.2020 09:30, Steve Lhomme wrote:
widl 6.0-rc1 doesn't generate them.
The IUnknown_QueryInterface_Proxy() is already hardcoded in unknwnbase.idl.
Some methods still generate a proxy entry using "call_as" in the IDL file.
---
mingw-w64-headers/include/bdaiface.h | 1865
On 14.12.2020 09:30, Steve Lhomme wrote:
It results in a compilation error with widl 6.0-rc1:
include/bdatypes.h:43: error: 'PBDA_EVENT_ID': [v1_enum] attribute applied
to non-enum type
It looks like a widl bug, [v1_enum] should be there, as far as I can see.
Jacek
___
Hi Steve,
Please rebase the series. Patch 2 and 3 should be fixed in git since
yesterday.
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On 11.12.2020 12:42, Steve Lhomme wrote:
On 2020-12-11 1:02, Jacek Caban wrote:
Hi Steve,
Hi Jacek,
It's great to see work on getting those IDLs to be in a form that we
can regenerate them again. Thanks!
Yes. For now I call widl manually because it seems that many of the
IDLs curr
Hi Steve,
It's great to see work on getting those IDLs to be in a form that we can
regenerate them again. Thanks!
There is recently an active (well, except for Wine code freeze) work on
Wine side to improve support for winrt widl mode by Rémi Bernon.
Hopefully widl will be able to properly
Hi Biswapriyo,
Looks good, I pushed it.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On 04/11/2020 10:31, Biswapriyo Nath wrote:
I would like to avoid the manual editing of d2d1 header files. I tried
to import d2d1.idl and d2d1_1.idl from wine. widl produces the
corresponding headers file without any errors. But while compiling
crt, it conflicts with `namespace D2D1` in d2d1help
)
PS: I removed the sign-off as I altered the patch
On 2020-10-13 20:57, Jacek Caban wrote:
Signed-off-by: Jacek Caban
---
This patch should fix the problem discussed in the other thread. It
also came out recently in Mozilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=1667423
mingw-w64-headers
Signed-off-by: Jacek Caban
---
This patch should fix the problem discussed in the other thread. It also
came out recently in Mozilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=1667423
mingw-w64-headers/include/dcomp.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a
Hi,
I sent this as a patch earlier, but it got stuck on moderation due to
the size. Please review commit:
https://github.com/cjacek/mingw-w64/commit/c073fb0c62a785cc5524e660568e85a89de2c0d5
This is suboptimal, but a better solution is unclear and I think that we
should deal with the regres
On 23.09.2020 11:32, Biswapriyo Nath wrote:
If you don't need ID3D11On12Device1 and ID3D11On12Device2 interfaces
that d3d11on12.idl file could be imported from wine as is. /cc. Jacek
C.
Sure, I pushed import as 50bcd814eab58db7cb3e2238c6a2e6ba5e1fb400.
Jacek
___
On 20/09/2020 14:02, Liu Hao wrote:
在 2020/9/20 19:45, Jean Pierre Cimalando 写道:
Le Sun, 20 Sep 2020 19:18:51 +0800,
Liu Hao a écrit :
It is now imported from Wine. Perhaps it's a necessary trade-off,
because not having a suffix would cause errors in C.
The header has distinct interfaces f
On 07.09.2020 04:10, Liu Hao wrote:
[Please include the list when replying, for example, by clicking 'reply to all'
or 'reply to list' instead of 'reply'.]
在 2020/9/6 上午7:25, Jean Pierre Cimalando 写道:
Le Sat, 5 Sep 2020 22:47:19 +0800,
Liu Hao a écrit :
+DWRITE_FONT_PROPERTY_ID_TOTAL,
On 22.07.2020 16:28, Liu Hao wrote:
It's neither called in this file nor declared or referenced elsewhere.
Signed-off-by: Liu Hao
Both patches look good to me.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge
On 21.07.2020 19:05, Liu Hao wrote:
在 2020/7/22 0:13, Jacek Caban 写道:
Oh, right. The problem with fsetpos is that the way fseeko is implemented is
not thread safe, but maybe it's not too bad.
fseeko64 is not really long (the file looks more complicated than it is because
of an u
On 21.07.2020 17:19, Liu Hao wrote:
在 2020/7/21 23:07, Jacek Caban 写道:
Sorry for joining the discussion late. How about implementing them directly on
top of msvcrt functions? Would something like:
return _telli64(_fileno(stream));
be enough for _ftelli64? Similarly:
return _lseeki64(_fileno
On 17.07.2020 21:41, Martin Storsjö wrote:
On Fri, 17 Jul 2020, Liu Hao wrote:
在 2020/7/17 22:28, Martin Storsjö 写道:
Sorry for the late reply, I started looking at this earlier but got
sidetracked back then.
In this case, _fseeki64 is a function in libmsvcrt-os.a while
fseeko64 is in libm
Signed-off-by: Jacek Caban
---
mingw-w64-headers/include/winnt.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/mingw-w64-headers/include/winnt.h b/mingw-w64-headers/include/winnt.h
index c47dc7fd..13ba6c42 100644
--- a/mingw-w64-headers/include/winnt.h
+++ b/mingw-w64-headers/include
On 12.06.2020 15:07, Jacek Caban wrote:
FWIW, my plan is to change the code in Wine to make mingw-w64
redundant, so whatever we do now will be temporary.
I meant 'mingw-w64 *patch* redundant' ;-) We should be able to import
the widl source code from Wine to mingw-w64 without mo
On 12.06.2020 14:38, Biswapriyo Nath wrote:
Question. The removal of `int i` declaration may be added with
wine-import.sh shell script by mistake. In wine, the int i variable is used
in for loop. IMHO, how about editing the wine/widl code?
* Now: for (i = 0; i < ARRAY_SIZE(incl_dirs); i++)
* Edi
Hi Martin,
Both patches look good to me.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Hi Martin,
The idea of a separated crt library for UWP seems reasonable to be. It
could also potentially help with some other UWP compatibility problems.
Having to implement a number of string functions is not really optimal,
but it looks like we need it. Long term, as we discussed lately, we
Signed-off-by: Jacek Caban
---
mingw-w64-headers/crt/conio.h | 37 +++--
mingw-w64-headers/crt/sec_api/stdio_s.h | 26 -
mingw-w64-headers/crt/sec_api/wchar_s.h | 12 ++--
mingw-w64-headers/crt/stdio.h | 59 ++--
mingw-w64-headers/crt/wchar.h
Signed-off-by: Jacek Caban
---
mingw-w64-crt/crt/ucrtbase_compat.c| 2 +-
mingw-w64-crt/stdio/ucrt__vscprintf.c | 2 +-
mingw-w64-crt/stdio/ucrt__vsnprintf.c | 2 +-
mingw-w64-crt/stdio/ucrt__vsnwprintf.c | 2 +-
mingw-w64-crt/stdio/ucrt_snprintf.c| 2 +-
mingw-w64-crt/stdio
On 04.06.2020 20:28, Martin Storsjö wrote:
On Thu, 4 Jun 2020, Jacek Caban wrote:
On 04.06.2020 15:33, Jacek Caban wrote:
On 04.06.2020 08:32, Martin Storsjö wrote:
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/Makefile.am | 2 +-
mingw-w64-crt/misc/{longjmp.S
On 04.06.2020 15:33, Jacek Caban wrote:
On 04.06.2020 08:32, Martin Storsjö wrote:
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/Makefile.am | 2 +-
mingw-w64-crt/misc/{longjmp.S => mingw_longjmp.S} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
ren
On 04.06.2020 08:32, Martin Storsjö wrote:
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/Makefile.am | 2 +-
mingw-w64-crt/misc/{longjmp.S => mingw_longjmp.S} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename mingw-w64-crt/misc/{longjmp.S => mingw_longjmp
On 04.06.2020 08:32, Martin Storsjö wrote:
This requires adding libucrt.a to a DATA target in automake, instead
of LIBRARIES.
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/Makefile.am | 58 ---
mingw-w64-crt/lib-common/ucrt.mri | 19 ++
mingw-w6
Hi Björn,
On 02.05.2020 09:42, Björn Schäpers | MIMOT GmbH wrote:
Then I learned there is widl and tried that. But the generated files are no
good to me:
Error: wine/exception.h: No such file or directory
As far as I can tell, there is no package within msys2 where I could get
wine/exception.
On 19.05.2020 10:34, Martin Storsjö wrote:
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
Signed-off-by: Jacek Caban
---
mingw-w64-tools/widl/include/pathtools.h | 31 --
mingw-w64-tools/widl/src/pathtools.c | 434 ---
2 files changed, 465 deletions(-)
diff --git a/mingw-w64-tools/widl/include/pathtools.h b/mingw-w64-tools/widl/include/pathtools.h
index
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
On 08.05.2020 12:18, Ruslan Garipov wrote:
-enum DWRITE_BASELINE
+typedef enum DWRITE_BASELINE
{
DWRITE_BASELINE_DEFAULT,
DWRITE_BASELINE_ROMAN,
@@ -25,40 +70,40 @@ enum DWRITE_BASELINE
DWRITE_BASELINE_IDEOGRAPHIC_TOP,
DWRITE_BASELINE_MINIMUM,
DWRITE_BASELINE_MAXIM
Hi Ruslan,
The patch looks good to me, I pushed it.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Hi Biswapriyo,
On 08.05.2020 22:32, Biswapriyo Nath wrote:
mingw-w64-crt/Makefile.am | 18 +++
mingw-w64-crt/libsrc/netcfg-uuid.c | 37 ++
2 files changed, 46 insertions(+), 9 deletions(-)
create mode 100644 mingw-w64-crt/libsrc/netcfg-uuid.
On 07.05.2020 18:45, Biswapriyo Nath wrote:
Main goal is to update the devguid.c in libsrc folder for libuuid.a. There
are two options I guess:
1. Copy the new GUIDs from devguid.h to devguid.c.
2. Include devguid.h in devguid.c.
Option 2 is done in the attached patch file. Because if a new GUI
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
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 i
Pushed to git.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On 28.04.2020 23:27, Thomas Dineen wrote:
000b:fixme:winediag:__wine_start_process Wine Staging 5.0 is a testing
version containing experimental patches.
000b:fixme:winediag:__wine_start_process Please mention your exact
version when filing bug reports on winehq.org.
002b:err:module:__wine_proce
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 dir
On 27.04.2020 19:23, Martin Storsjö wrote:
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.
Other than comments I just sent, I don't have an
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?
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://list
On 27.04.2020 19:22, Martin Storsjö wrote:
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?
Wine will always use its own implementation (that just forwards the call
to ResolveDelayLoaded
On 27.04.2020 12:14, Martin Storsjö wrote:
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
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
forc
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 coul
Looks good, pushed.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
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 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
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'
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 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 usin
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
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(-)
diff --git a/mingw-w64-crt/crt/crt_handler.c b/mingw-w64-crt/crt/crt_handler.c
index
On 23.04.2020 10:19, Steve Lhomme wrote:
This worked. The forbidden RtlAddFunctionTable calls are not done
anymore.
Thanks for testing, it passed my usual testing as well.
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourcefor
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.
Thanks,
Jacek
On 22.04.2020 23:00, Martin Storsjö wrote:
This was a partial (but incomplete!) support for the
On 22.04.2020 14:03, Martin Storsjö wrote:
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 c
On 22.04.2020 13:28, Jacek Caban wrote:
How reliably can we detect the condition when if compiler will
generate .pdata sections?
I meant s/when/when building crt/.
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
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 handl
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.
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/
On 18.04.2020 14:51, Liu Hao wrote:
在 2020/4/17 20:25, Steve Lhomme 写道:
So we can restrict some C runtime APIs based on the target family.
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-wind
101 - 200 of 918 matches
Mail list logo
