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 the way
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 compatibility
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
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
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 "ca
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
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 currently
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
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
)
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
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
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
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
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 unused
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
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 modification
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++)
*
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,
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 =>
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 ++
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
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,
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
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
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
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
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.
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
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
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
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
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 the exact
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
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
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
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
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
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 using _wgetenv
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
___
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
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
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 common
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
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)
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
Hi Steve,
Yeah, winrt IDLs in mingw-w64 are a mess right now. They are invalid and
they required hacked widl version to generate. Long term solution is
finishing winrt support in upstream widl (I did some work on that, but
more is needed) and rewrite those IDLs. If you need a quicker
On 01.04.2020 14:14, Martin Storsjö wrote:
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/include/internal.h | 6 --
1 file changed, 6 deletions(-)
Looks good to me.
Thanks,
Jacek
___
Mingw-w64-public mailing list
On 10/03/2020 12:48, Steve Lhomme wrote:
On 2020-03-10 11:31, Jacek Caban wrote:
On 10/03/2020 07:34, Steve Lhomme wrote:
You mean squash all 5 patches into one or just the first two ?
In general I prefer to split commits so if something breaks it's
easier to know what is wrong
On 09/03/2020 21:59, Martin Storsjö wrote:
On Mon, 9 Mar 2020, Jacek Caban wrote:
Signed-off-by: Jacek Caban
---
mingw-w64-headers/crt/corecrt_stdio_config.h | 30
mingw-w64-headers/crt/stdio.h | 2 +-
2 files changed, 31 insertions(+), 1 deletion(-)
create
On 10/03/2020 07:34, Steve Lhomme wrote:
You mean squash all 5 patches into one or just the first two ?
In general I prefer to split commits so if something breaks it's
easier to know what is wrong in a particular commit and possibly
revert it, without losing all changes.
Splitting
On 09/03/2020 22:48, Martin Storsjö wrote:
On Mon, 9 Mar 2020, Jacek Caban wrote:
Hi Martin,
On 09.03.2020 10:43, Martin Storsjö wrote:
According to standard C99, the swprintf and vswprintf functions
return a negative value if the buffer is insufficient (contrary to
snprintf
Hi Steve,
On 04.03.2020 15:27, Steve Lhomme wrote:
Use the generated dxvahd.h
---
mingw-w64-headers/Makefile.am| 1 +
mingw-w64-headers/include/dxvahd.h | 841 ++-
mingw-w64-headers/include/dxvahd.idl | 427 ++
3 files changed, 990
Signed-off-by: Jacek Caban
---
mingw-w64-headers/crt/corecrt_stdio_config.h | 30
mingw-w64-headers/crt/stdio.h| 2 +-
2 files changed, 31 insertions(+), 1 deletion(-)
create mode 100644 mingw-w64-headers/crt/corecrt_stdio_config.h
diff --git a/mingw-w64
On 09.03.2020 10:41, Martin Storsjö wrote:
The libmingwex implementation of asprintf requires a _vscprintf now,
and that implementation is supposed to be agnostic of the underlying
CRT type.
The patch looks good to me.
Thanks,
Jacek
___
Hi Martin,
On 09.03.2020 10:43, Martin Storsjö wrote:
According to standard C99, the swprintf and vswprintf functions
return a negative value if the buffer is insufficient (contrary to
snprintf), and the contents of the buffer is undefined in this case.
Both swprintf and vswprintf functions
On 04.03.2020 18:39, Biswapriyo Nath wrote:
The vmr9.idl file seems to be imported from wine headers but it's not
present in wine-import.sh script. Can the vmr9.idl be added in
wine-import script as well?
Yes, after Nikolay's patch is committed to Wine.
Thanks,
Jacek
On 24.02.2020 12:46, Jacek Caban wrote:
On 24.02.2020 12:28, Martin Storsjö wrote:
On Mon, 24 Feb 2020, Jacek Caban wrote:
Still, the problematic commit tries to solve some problems that are
already solved when using mingw-w64 *printf implementation. Since
non-underscored does not exist
On 24.02.2020 12:28, Martin Storsjö wrote:
On Mon, 24 Feb 2020, Jacek Caban wrote:
Still, the problematic commit tries to solve some problems that are
already solved when using mingw-w64 *printf implementation. Since
non-underscored does not exist in msvcrt.dll, it's our extension
anyway. So
Hi,
I think that the best way forward is UCRT. When using UCRT, there is
already no issue. We should probably revisit making that a default
configuration.
I don't agree with us trying to limit use to VC6 subset. Microsoft does
not intentionally break applications and I'm pretty sure that
Hi Biswapriyo,
Sorry for the delay.
On 07.02.2020 15:36, Biswapriyo Nath wrote:
There is no regression, I have check it.
I found a regression in wine-gecko build:
/home/jacek/mozilla/wine-gecko-git/dom/media/platforms/wmf/WMFUtils.cpp:
In function ‘HRESULT
Hi Martin,
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 Alex,
On 27/01/2020 06:32, Alex Henrie wrote:
Signed-off-by: Alex Henrie
---
The name of the library was already correct inside the def files
themselves and also in the rstrtmgr.def file for libarm32.
---
mingw-w64-crt/Makefile.in | 4 ++--
On 26/01/2020 16:25, Biswapriyo Nath wrote:
* Cause:
- The dxva2api.idl in mingw-w64 is not complete.
- Many definitions are required for msys2/vlc. Though the actual VLC
repository imports it from wine.
* Asking this because:
- The copyright is different.
- The diff seems to be
Hi,
I just pushed an update from Wine containing those changes to git. There
is no need for separated patches here. Updates from Wine are
pre-approved and will be done as soon as someone (usually me) runs the
script and pushes it. I do that one in a while, unless we have a
particular reason
This is the final part of direct-x header move series. Please review.
Signed-off-by: Jacek Caban
---
mingw-w64-headers/Makefile.am | 2 --
mingw-w64-headers/configure.ac | 20 +---
2 files changed, 5 insertions(+), 17 deletions(-)
diff --git a/mingw-w64-headers/Makefile.am
On 20.01.2020 15:25, Liu Hao wrote:
在 2020/1/8 23:39, Jacek Caban 写道:
It's no longer needed, it's always available.
Signed-off-by: Jacek Caban
---
mingw-w64-headers/include/d2d1.h | 121 ---
mingw-w64-headers/include/ddrawgdi.h | 3 -
mingw-w64-headers
On 09.01.2020 10:05, Biswapriyo Nath wrote:
* Required for msys2/Blender.
* Makefile.in and configure script are not updated.
Sorry for the delay. The patch looks good, I pushed it.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Signed-off-by: Jacek Caban
---
I plan to amend git rm -f direct-x to this patch before pushing it.
mingw-w64-headers/Makefile.am | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/mingw-w64-headers/Makefile.am b/mingw-w64-headers/Makefile.am
index 9a8e3cc0..6bbf5bb7
It's no longer needed, it's always available.
Signed-off-by: Jacek Caban
---
mingw-w64-headers/include/d2d1.h | 121 ---
mingw-w64-headers/include/ddrawgdi.h | 3 -
mingw-w64-headers/include/strmif.idl | 17
3 files changed, 141 deletions(-)
diff --git
It's no longer needed.
Signed-off-by: Jacek Caban
---
mingw-w64-headers/Makefile.am| 7 ++-
mingw-w64-headers/crt/_mingw.h.in| 1 -
mingw-w64-headers/crt/sdks/_mingw_directx.h.in | 16
mingw-w64-headers/defaults/generate.sh
101 - 200 of 813 matches
Mail list logo
