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
在 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 :-)
>
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
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
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
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
The widl version in mingw-w64-tools is 5.0-rc1.Would you like to update it
to current version of wine repository? Here is what I have tried. There is
a 0001-relocatable.patch file which I have replaced with the attached one.
Then I test some IDL files and the produced header files are same as from
No, I didn't mean you should modify anything, just wondering why it's there.
On 5/10/20 8:50 PM, Biswapriyo Nath wrote:
widl could be improved to pad newlines automatically.
If it's possible then as you wish, I'll modify the patch.
___
> widl could be improved to pad newlines automatically.
If it's possible then as you wish, I'll modify the patch.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On 5/10/20 8:38 PM, Biswapriyo Nath wrote:
Yes, I will try to add those IDL files also.
Ok.
what's a deal with empty lines like 'cpp_quote("")', what are those for ?
Just matching with other IDL files. It adds a newline separation between
two symbols.
I see, but what for? If header
Yes, I will try to add those IDL files also.
> what's a deal with empty lines like 'cpp_quote("")', what are those for ?
Just matching with other IDL files. It adds a newline separation between
two symbols.
___
Mingw-w64-public mailing list
That's only useful if you're going to introduce d2d/dwrite idl's, and
even then you might as well import it from wine.
P.S. what's a deal with empty lines like 'cpp_quote("")', what are those
for ?
___
Mingw-w64-public mailing list
Opps... Forgot add in Makefile.am. Updated patch here.
From 705189ec3a90abb5159077b01c71b31ab9635442 Mon Sep 17 00:00:00 2001
From: Biswapriyo Nath
Date: Sun, 10 May 2020 21:58:59 +0530
Subject: [PATCH] headers: add dcommon.idl
move symbols from d2dbasetypes as dcommon will be
shared among d2d1
From d507a668fdd46b384c83eb6db5e1019c68fb6045 Mon Sep 17 00:00:00 2001
From: Biswapriyo Nath
Date: Sun, 10 May 2020 21:58:59 +0530
Subject: [PATCH] headers: add dcommon.idl
move symbols from d2dbasetypes as dcommon will be
shared among d2d1 and dwrite headers
Signed-off-by: Biswapriyo Nath
15 matches
Mail list logo
