On 26.09.2024 15:00, Martin Storsjö wrote:
Modern GCC and Clang warn for these casts, with warnings like these:
../secapi/_chsize_s.c:20:6:
warning: cast from 'FARPROC' (aka 'long long (*)()') to 'errno_t
((*))(int, long long) __attribute__((cdecl))' (aka 'int (*)(int, lo
ng long)') converts t
Looks 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
On 19.09.2024 21:45, Pali Rohár wrote:
On Friday 20 September 2024 01:11:16 Biswapriyo Nath wrote:
Some of the IDL and headers are imported from wine project. Those
should be sent to wine project first. Also, do not add header files in
patch which are generated from IDL files. Those are generate
On 18.09.2024 16:16, LIU Hao wrote:
Maybe, but in practice it's pretty well defined behavior.
Yes; my suggestion about casting via `intptr_t` also just happens to
work in practice.
So far there are two compilers which are known to warn sometimes about
conversion between a function pointer a
On 18.09.2024 15:25, LIU Hao wrote:
在 2024-09-18 21:02, Martin Storsjö 写道:
Hmm, can you give a godbolt example or similar, for where the
compilers diverge about warnings here?
With Clang, I don't seem to be able to get any warnings for either
casts via (void(*)(void)) or (void*), with either
On 18.09.2024 14:06, Martin Storsjö wrote:
This avoids warnings from Clang, pointing out that this function
could be marked noreturn.
---
mingw-w64-crt/misc/wassert.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mingw-w64-crt/misc/wassert.c b/mingw-w64-crt/misc/wassert.c
index d342048ec
On 18.09.2024 14:06, Martin Storsjö wrote:
Modern GCC and Clang warn for these casts, with warnings like these:
../secapi/_chsize_s.c:20:6:
warning: cast from 'FARPROC' (aka 'long long (*)()') to 'errno_t
((*))(int, long long) __attribute__((cdecl))' (aka 'int (*)(int, lo
ng long)') converts t
Hi all,
I’ve just pushed an update to widl, syncing it with the current Wine
version. This update carries a bit more risk than usual for mingw-w64,
as it required adjustments to align with the upstream relocatable
installation. I’ve ensured that the Wine version handles all the cases
covered
Pushed without to master without __imp_ symbol as
37a5ac28da2cea20ded46c24dd4938162d4a6be8.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On 7.09.2024 00:00, Pali Rohár wrote:
So maybe the imp symbol could be included only for gcc/binutils builds?
I think that we don't want to introduce differences like that. Ideally,
we should be able to mix tools with crt builds with another tools (so,
for example, use crt built with GCC wit
On 4.09.2024 13:41, Martin Storsjö wrote:
This was added in UCRT 10.0.19041.0.
Signed-off-by: Martin Storsjö
The series looks good to me.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sour
On 4.09.2024 12:42, Sharadh Rajaraman wrote:
Additionally, there are missing headers compared to the MSVC Windows SDK:
- WIL requires WeakReference.h
(https://github.com/microsoft/wil/blob/eb9eb355d6de431311d7f5ea3590c72d53741ccc/include/wil/com.h#L16)
- Azure C++ SDK requires WebServices.h
(http
On 3.09.2024 23:15, Pali Rohár wrote:
On Wednesday 28 August 2024 15:51:46 Jacek Caban wrote:
On 27.08.2024 23:35, Pali Rohár wrote:
On Tuesday 27 August 2024 23:20:23 Jacek Caban wrote:
On 27.08.2024 21:16, Pali Rohár wrote:
+/* define just import symbol, function itself is in crtexe.c and
On 28.08.2024 13:42, Martin Storsjö wrote:
From: Pali Rohár
---
I tried removing some of the extra verbosity, while keeping the core of
the added information, and adjusting wording a little bit.
Looks good to me.
Thanks,
Jacek
___
Mingw-w64-publ
On 27.08.2024 23:35, Pali Rohár wrote:
On Tuesday 27 August 2024 23:20:23 Jacek Caban wrote:
On 27.08.2024 21:16, Pali Rohár wrote:
+/* define just import symbol, function itself is in crtexe.c and crtdll.c
files */
+int (__cdecl *__MINGW_IMP_SYMBOL(atexit))(void (__cdecl *)(void)) = atexit
On 27.08.2024 21:16, Pali Rohár wrote:
+/* define just import symbol, function itself is in crtexe.c and crtdll.c
files */
+int (__cdecl *__MINGW_IMP_SYMBOL(atexit))(void (__cdecl *)(void)) = atexit;
The patch looks mostly good to me, but do we need this __imp_ symbol at
all? We already decl
On 27.08.2024 21:14, Pali Rohár wrote:
-ucrt (utilizing ucrtbase.dll) and msvcrt (utilizing msvcrt.dll).
+ucrt (utilizing api-ms-win-crt-*.dll) and msvcrt (utilizing msvcrt.dll).
In my opinion mentioning api-ms-* stuff does not make it any cleaner.
Ultimately, it's utilizing ucrtbase.dll, tha
On 22.08.2024 17:08, Pali Rohár wrote:
On Thursday 22 August 2024 18:05:17 Martin Storsjö wrote:
On Thu, 22 Aug 2024, Pali Rohár wrote:
On Thursday 22 August 2024 13:24:32 Martin Storsjö wrote:
This reverts parts of 52c98b1273a61b7a3e1fc93142fa4b5e4c3ee5ab.
While powf indeed is available in
On 22.08.2024 12:24, Martin Storsjö wrote:
This reverts parts of 52c98b1273a61b7a3e1fc93142fa4b5e4c3ee5ab.
While powf indeed is available in UCRT on i386 too, it's missing
in Wine's i386 ucrtbase.dll (as of Wine 9.15). This probably stems
from the same mistake originally. (Most of the float math
On 19.08.2024 22:04, Martin Storsjö wrote:
On Mon, 19 Aug 2024, Pali Rohár wrote:
What about attribute naked? For I386 it is supported since gcc 8.
I think it may be ok. I have very little experience with this
attribute myself though.
It seems like Wine are using this attribute, in some se
On 11.08.2024 23:05, Martin Storsjö wrote:
If the user has hardcoded WINVER to a version number less than
0x0602, while _WIN32_WINNT is set to 0xA00, and NTDDI_VERSION
is larger than NTDDI_WIN10_RS3, we would earlier hide the
definition of POINTER_INPUT_TYPE, but include the declarations
of funct
On 9.08.2024 16:05, Martin Storsjö wrote:
On Fri, 9 Aug 2024, Jacek Caban wrote:
On 9.08.2024 13:26, Martin Storsjö wrote:
On Fri, 2 Aug 2024, Pali Rohár wrote:
mingw-w64-crt/crt/ contains mostly startup files which are part of the
libmingw32.a library or crtX.o object files. But there are
On 9.08.2024 13:26, Martin Storsjö wrote:
On Fri, 2 Aug 2024, Pali Rohár wrote:
mingw-w64-crt/crt/ contains mostly startup files which are part of the
libmingw32.a library or crtX.o object files. But there are also few
files
which are either part of libmingwex.a or some CRT import library.
D
On 7.08.2024 16:50, LIU Hao wrote:
在 2024-08-07 19:53, Martin Storsjö 写道:
This matches what WinSDK headers do these days. We always have
_WIN32_WINNT set to a default value of our choice, and there's
no value we can set _WIN32_WINNT to, that would set NTDDI_VERSION
to include the features from n
On 5.06.2024 09:44, Martin Storsjö wrote:
mingw-w64-headers/crt/time.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Looks good to me.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https:/
On 29.05.2024 22:53, Martin Storsjö wrote:
What do others think about this?
Those are old crts at this point. If we were fine without them so far, I
don't see any future demand for them coming, so they don't seem to
justify complicating the code base to me. But if others see value in it,
Hi,
The series looks 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
On 8.05.2024 14:22, Martin Storsjö wrote:
Prior to 1652e9241b5d8a5a779c6582b1c3c4f4a7cc66e5, the inline
functions always were static. Due to reexporting such symbols
in C++20 modules (for the C++23 std module), the reexported symbols
must not be static, so the inline functions were changed
from s
On 26.04.2024 21:43, Pali Rohár wrote:
I played a bit with different msvc 19.x versions and 32-bit x86 variant
recognize time symbol and maps it to _time32 at link time. First
compiler maps time symbol to _time and then linker maps _time to
__time32. It means that msvc import libraries have symbo
On 25.04.2024 23:11, Pali Rohár wrote:
And also it would allow to create object file which
calls "_findfirst" symbol and then link it with any mingw-w64 CRT import
library.
Mixing crts is problematic for many reasons, this is just one of them.
And if one really needs to go that far, it's bett
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
On 23.04.2024 13:39, Martin Storsjö wrote:
On Tue, 16 Apr 2024, Jacek Caban wrote:
But in this particular case, I think we may improve things on
mingw-w64-crt side and move __sinl_internal to msvcr* importlibs.
Something like the attached (untested) patch should help.
Unfortunately, we
On 16.04.2024 17:29, philippe renon wrote:
Note that there are more math functions involved (not just sin).
See the commit that introduced the issue for a full list:
https://github.com/mingw-w64/mingw-w64/commit/a64c1f4b969cff5f9e81c9a760117dc1b92d6ee1
I know, but only the ones that depend o
On 16.04.2024 15:51, philippe renon via Mingw-w64-public wrote:
The error seems to happen because Rust pulls in lgamma from
libmingwex.a, which pulls in sin from libmsvcrt.a, which in turn tries
to pull in __sinl_internal from libmingwex.a and fails because of how
Rust links MinGW libs:
let mingw
Looks good, I pushed the series.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On 6.02.2024 13:22, Martin Storsjö wrote:
By hardcoding the use of -Werror, we risk that the build can break
on any newer (or older) toolchain which can give warnings for
unexpected issues.
Fixing such issues is of course desired, but we shouldn't be breaking
the build universally, unless the us
On 5.02.2024 23:27, Martin Storsjö wrote:
Clang 18.x was meant to implement __cpuidex (a version was merged
during the development of Clang 17.x, but it was reverted and backed
out before Clang 17.x was completed) - however it was never merged
before Clang 18.x was branched after all. For further
On 20.12.2023 14:32, Martin Storsjö wrote:
For definitions like _BSD_SOURCE, the most failsafe solution
generally is to define them before including any header, to avoid
this kind of issue. However, allowing getopt.h to react to
being reincluded with _BSD_SOURCE defined, is quite straightforward.
On 29.11.2023 18:35, Nikolay Sivov wrote:
import "mfobjects.idl";
+import "mftransform.idl";
cpp_quote("#include ") // FIXME: import "mftransform.idl";
This cpp_quote should be removed now. I fixed that and pushed.
Thanks,
Jacek
___
Mingw-w6
On 30.10.2023 22:09, Martin Storsjö wrote:
On Mon, 30 Oct 2023, Jacek Caban wrote:
GetTickCount64 is used only for _pthread_wait_for_*_objects wrappers,
where the timeout is 32-bit anyway, so it should be possible to use
GetTickCount unconditionally and avoid the whole problem. It would
need
On 30.10.2023 16:39, Martin Storsjö wrote:
On Mon, 30 Oct 2023, LIU Hao wrote:
在 2023-10-30 18:54, Martin Storsjö 写道:
FWIW, this is what we already had before
cb7f42e05b94cbb1d94edcebdbfb47b652a45484; we used GetTickCount64
unconditionally if _WIN32_WINNT was set to target vista or above.
S
On 27/10/2023 16:51, LIU Hao wrote:
在 2023-10-26 19:15, Martin Storsjö 写道:
fabsf is available in UCRT on arm32/arm64, but not on x86.
nexttowardf is available in UCRT on all architectures, but this
functions takes two parameters, and the second parameter is a long
^
There is a typo
On 9/21/23 16:50, LIU Hao wrote:
在 2023-09-20 04:57, Martin Storsjö 写道:
The version of d3d12.idl in vkd3d has been completed further now,
and has been synced back to Wine; restore mingw-w64-headers to
include this header in future syncs from wine.
This synchronizes the d3d12.idl header from Win
Patches look good to me, I pushed to master.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On 9/8/23 13:48, Martin Storsjö wrote:
Ideally the d3d12.idl in wine will be brought up to sync at some point,
but for now, exclude this header and sync it manually from vkd3d
instead.
Yes, we will want to re-sync all of that and I'm happy to help with that
if needed. The patch itself looks g
On 9/8/23 13:48, Martin Storsjö wrote:
This header is appropriately licensed with a compatible open source
license, the University of Illinois Open Source License (a BSD-like
license).
It looks good to me. It's nice to see Microsoft open sourcing at least
parts of their SDK.
Thanks,
Jacek
On 8/8/23 16:30, LIU Hao wrote:
在 2023-08-08 20:40, Jacek Caban via Mingw-w64-public 写道:
Fixes regression from 3638d5e9a6f2 reported:
https://bugzilla.mozilla.org/show_bug.cgi?id=1847683
Those guards are not present in Wine and Windows SDK for a reason: if
INITGUID is changed, it should be
Fixes regression from 3638d5e9a6f2 reported:
https://bugzilla.mozilla.org/show_bug.cgi?id=1847683
Those guards are not present in Wine and Windows SDK for a reason: if
INITGUID is changed, it should be reflected in DEFINE_PROPERTYKEY macro.
---
mingw-w64-headers/include/propkeydef.h | 9 --
On 7/23/23 13:04, LIU Hao wrote:
在 2023-07-23 18:43, Jacek Caban via Mingw-w64-public 写道:
The commit is missing some files generated from IDLs, so current tree
doesn't build.
I tried building headers and regenerated all of them from IDL. It was
necessary to use an up-to-date WIDL,
On 7/23/23 11:58, LIU Hao wrote:
在 2023-07-23 13:57, Biswapriyo Nath 写道:
From 2a64bfe452a92a5197b2e102f5d46c28d14a7631 Mon Sep 17 00:00:00 2001
From: Biswapriyo Nath
Date: Sun, 23 Jul 2023 11:17:05 +0530
Subject: [PATCH 3/3] headers: Define D2D1FORCEINLINE where needed
Signed-off-by: Biswapriy
Hi all,
I just pushed a change to out build system to use UCRT by default.
Bellow is a copy of more detailed informations, it can be also found in
git in mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt.
Thanks,
Jacek
== Summary ==
Starting from mingw-w64 version 12 and onwards, UCRT (Unive
On 6/25/23 16:32, LIU Hao wrote:
在 2023-06-19 20:43, Jacek Caban via Mingw-w64-public 写道:
---
mingw-w64-crt/configure.ac | 4 +-
mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt | 58
mingw-w64-headers/configure.ac | 12 ++--
3 files
On 6/20/23 20:27, Biswapriyo Nath wrote:
Is it possible to provide any hit why the widl crashed? Or is there
any way to troubleshoot the issue?
You may incrementally revert parts of your changes until it works. It
should give a good idea where to look. Please file a bug if you need
more assi
On 6/20/23 19:39, Biswapriyo Nath wrote:
Is it possible to add the file in mingw-w64? It has been a week and I
get no response in wine merge request.
It crashes widl during the build, so it's pretty obvious why it's not
merged.
Jacek
___
Mingw
---
mingw-w64-crt/configure.ac | 4 +-
mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt | 58
mingw-w64-headers/configure.ac | 12 ++--
3 files changed, 66 insertions(+), 8 deletions(-)
create mode 100644 mingw-w64-doc/howto-build/ucrt-vs-msvcrt.
On 6/19/23 14:20, Martin Storsjö wrote:
On Mon, 19 Jun 2023, Jacek Caban via Mingw-w64-public wrote:
v2 includes changes suggested by Martin. It also includes a
documentation change to clarify the situation.
---
mingw-w64-crt/configure.ac | 4 +-
mingw-w64-doc/howto-build
v2 includes changes suggested by Martin. It also includes a
documentation change to clarify the situation.
---
mingw-w64-crt/configure.ac | 4 +-
mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt | 58
mingw-w64-headers/configure.ac | 12 ++--
3
On 6/8/23 06:18, LIU Hao wrote:
I agree that those are valid concerns. However, there is little we
can do about it and it's unlikely to change over time. Do we want
msvcrt-os to remain the default forever?
For your information, this is a non-exhaustive list of distributions
that do not specif
On 6/7/23 19:46, Biswapriyo Nath wrote:
Do we need to reimplement 'wia.idl', instead of importing 'wia_lh.idl' and
'wia_xp.idl' from Wine?
wia_lh.idl and wia_xp.idl in wine are missing many declarations.
It should be easy to add them to Wine.
Besides, wia_xp.h is just a stripped down vers
On 6/5/23 10:59, Martin Storsjö wrote:
On Sun, 4 Jun 2023, Jacek Caban via Mingw-w64-public wrote:
We're early in release cycle again, so it feels like a good time to
consider defaulting to ucrt. At this point, ucrt support seems
generally mature enough and I'm not aware of an
Hi all,
We're early in release cycle again, so it feels like a good time to
consider defaulting to ucrt. At this point, ucrt support seems generally
mature enough and I'm not aware of any blockers.
Thanks,
Jacek
---
mingw-w64-crt/configure.ac | 4 ++--
mingw-w64-headers/configure.ac |
On 4/22/23 14:46, LIU Hao wrote:
在 2023-03-30 16:38, LIU Hao 写道:
Ping on this patch. A blank line got deleted by accident. I can fix
that locally.
Removal of stuff could be bad, but given that `mbstoc16()` has never
been working, it might not be a big loss.
Ping again? It has been almost
On 4/26/23 22:30, Biswapriyo Nath wrote:
The compiler error can be solved if DirectXAlphaMode is replaced with
ABI::Windows::Graphics::DirectX::DirectXAlphaMode. I am not sure if
this is an issue with widl generated header or an issue with clang and
C++ standards. How can I troubleshoot this issu
Pushed, thanks.
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On 3/31/23 18:24, NightStrike wrote:
On Thu, Mar 30, 2023, 06:45 Jacek Caban via Mingw-w64-public
wrote:
On 3/20/23 16:44, مهدي شينون wrote:
> Hi everyone,
>
>
> Could you please consider migrating your project to another host
other
> than s
On 3/20/23 16:44, مهدي شينون wrote:
Hi everyone,
Could you please consider migrating your project to another host other
than sourcefoge where people could file bugs, propose changes and
discuss things (like GitHub ot GitLab).
Using mailing-list for that is a way that's not suitable for youn
On 3/23/23 07:03, Martin Storsjö wrote:
On Wed, 22 Mar 2023, Jacek Caban wrote:
On 3/22/23 15:21, LIU Hao wrote:
在 2023-03-22 21:07, Jacek Caban 写道:
That's the motivation for this? I can see a point in supporting
both syntaxes in headers (which may be included by users with
various com
On 3/22/23 15:21, LIU Hao wrote:
在 2023-03-22 21:07, Jacek Caban 写道:
That's the motivation for this? I can see a point in supporting both
syntaxes in headers (which may be included by users with various
compiler options), but for crt, why isn't supporting a single syntax
underst
On 3/22/23 04:08, LIU Hao wrote:
This is the first attempt to allow the CRT to be built with
`-masm=intel`. This patch itself may look messy because it contains a
lot of inline changes. It should be examined with `git show
--color-words='\S'`.
I have only verified that the CRT actually builds
On 3/17/23 15:39, Steve Lhomme wrote:
On 2023-03-17 15:28, Biswapriyo Nath wrote:
1. You missed the Reserved member in
DXVAHD_STREAM_STATE_INPUT_COLOR_SPACE_DATA.
2. There should be __C89_NAMELESS before the struct and union keywords.
Indeed, good catch.
Here is v2 of the patch.
This does
On 1/20/23 13:49, Martin Storsjö wrote:
The UCRT provided versions should be fully C99 compliant.
This matches what was done for strtod/strtof for the initial
configuration for UCRT in 265d0a5e3f087ed6bd68412cceed5e27e3ef62ae.
Also clarify the endif comment, and make the condition in wchar.h
co
On 12/21/22 15:12, LIU Hao wrote:
在 2022-12-20 02:49, Pali Rohár 写道:
And I think that this decision is independent of tool itself if should
be removed too or not.
My point is that if this should be removed then we shouldn't behave as
if it was being actively maintained.
Patch attached. Thou
Hi Martin,
On 12/21/22 10:37, Martin Storsjö wrote:
Widl uses a subset of Wine headers, on top of the host's platform
headers (either Unix or Windows ones). When building widl for a
Windows target, the included Wine headers end up being preferred
over the toolchain's own platform headers.
Wine
On 11/15/22 15:17, LIU Hao wrote:
I think that when there is a real bug, we should fix it. As for
standard themselves, I think that C/C++ standards are important.
Praising POSIX-alike standards for mingw-w64, who's CRT is a wrapper
around Windows system CRT, seems a bit misplaced for me. Using
On 11/14/22 09:57, LIU Hao wrote:
在 2022/10/25 04:50, Jacek Caban 写道:
This also may be supported in existing threading models. Overflow is
trivial to fix by waiting in a loop. (There are other reasons why OS
support for absolute timeout is slightly better, but the price of
this design
builds (from GCC 12
release branch) with these patches at https://gcc-mcf.lhmouse.com/.
Forwarded Message
在 2022/10/23 18:06, Jacek Caban 写道:
>
> Please, let's not do that. It's possible to fix existing
implementations, we don't need to make
> things mo
On 10/23/22 10:28, LIU Hao wrote:
在 2022-10-23 10:16, JonY via Mingw-w64-public 写道:
On 10/22/22 19:52, Martin Storsjö wrote:
On Sat, 22 Oct 2022, Jacek Caban wrote:
Perhaps to a little surprise, I don't like it. My main issue is
that it requires mingw crt to be aware of 3rd party li
On 10/23/22 04:16, JonY via Mingw-w64-public wrote:
On 10/22/22 19:52, Martin Storsjö wrote:
On Sat, 22 Oct 2022, Jacek Caban wrote:
On 10/22/22 18:34, LIU Hao wrote:
Hello,
Attached are final patches for mcfgthread support in the CRT.
Please review.
Perhaps to a little surprise, I
On 10/22/22 18:34, LIU Hao wrote:
Hello,
Attached are final patches for mcfgthread support in the CRT. Please
review.
Perhaps to a little surprise, I don't like it. My main issue is that it
requires mingw crt to be aware of 3rd party library details instead of
being agnostic to threading
Hi,
I heard that it was committed to GCC. I just want to mention for the
record that I still think it was a mistake. I also think that
obfuscating mingw-w64 with proposed changes would be a mistake.
On 10/13/22 04:09, LIU Hao wrote:
在 2022/10/13 01:15, Jacek Caban 写道:
I'd argue
On 10/12/22 06:06, LIU Hao wrote:
在 2022/10/12 03:55, Jacek Caban 写道:
Is there anything that mcfgthread achieves that can't be fixed in
GCC's win32 model? This sounds to me like that GCC is the right place
to fix things, possibly by merging parts of mcfgthread into GCC
itself. I re
On 10/7/22 17:47, LIU Hao wrote:
While mingw-w64 might have been deemed to enable projects, which
typically build with the Microsoft compiler and linker, to build with
the GNU compiler and linker with little modification, sometimes I do
think we have payed too much in mimicking some non-standar
On 9/19/22 13:38, Yannis Juglaret wrote:
This fixes the struct used to enable the Arbitrary Code Guard mitigation
or query its status on Windows. The size of the struct was wrong, which
could lead calls to Get/SetProcessMitigationPolicy to fail with the last
error set to ERROR_INVALID_PARAMETER.
On 8/14/22 10:20, Takashi Yano wrote:
On Sun, 14 Aug 2022 17:09:44 +0900
Takashi Yano wrote:
I have built the partially fixed version (v6) attached, where only
printf, *putw* and fwrite are fixed, as well as the fully fixed
version (v7) attached. v7 patch is the modification of v5 where
the work
On 8/12/22 11:15, Martin Storsjö wrote:
Don't return NAN constants with the sign bit set.
This matches what UCRT returns for the nan*() functions since
UCRT was introduced. It also matches the _Nan constant provided
in older versions of MSVC (at least since 2003) (which are returned
by various f
On 7/25/22 00:10, Zebediah Figura wrote:
(+ wine-devel)
On 6/11/22 13:26, LIU Hao wrote:
在 2022-06-12 01:59, Zebediah Figura 写道:
The combination of `extern` with `__gnu_inline__` is necessary to
suppress generation of a function
body if the attached function could not be inlined when compiling
On 7/13/22 11:45, Ozkan Sezer wrote:
On 7/13/22, LIU Hao wrote:
在 2022/7/12 15:50, Ozkan Sezer 写道:
With the patch applied to v5.x branch and crt rebuilt, the game engine
rebuilt with -fno-asynchronous-unwind-tables in the CFLAGS against the
newly built crt and setjmp.h seems to behave as it is
Hi Biswapriyo,
On 6/17/22 09:38, Biswapriyo Nath wrote:
mingw-w64-crt/libsrc/dxguid.c| 1 +
mingw-w64-headers/Makefile.am| 1 +
mingw-w64-headers/include/dxcore.idl | 195 +++
3 files changed, 197 insertions(+)
create mode 100644 mingw-w64-heade
On 6/15/22 07:47, LIU Hao wrote:
在 2022/6/14 00:33, Jacek Caban 写道:
Signed-off-by: Jacek Caban
---
mingw-w64-headers/include/unknwnbase.idl | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
LGTM. THanks.
Thanks, I pushed it.
Jacek
Signed-off-by: Jacek Caban
---
mingw-w64-headers/include/unknwnbase.idl | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/mingw-w64-headers/include/unknwnbase.idl b/mingw-w64-headers/include/unknwnbase.idl
index a479baac1..a69a50468 100644
--- a/mingw-w64-headers
Hi Raphael,
On 4/2/22 13:22, Raphael Isemann wrote:
The attached patch fixes an uninitialized read from memory in `union_memsize`.
The summary of how the bug happens is:
1. union_memsize gets called with a pointer to uninitialized `dummy`.
```
static unsigned int write_union_tfs(FILE *file, co
On 3/17/22 09:56, Martin Storsjö wrote:
However, autotools does some dubious choices here. If I'm configuring
a cross compiler, and I do have x86_64-w64-mingw32-gcc but I don't
have x86_64-w64-mingw32-g++ because I built only with
--enable-languages=c, the configure script does this detection
On 1/11/22 16:43, LIU Hao wrote:
在 2022-01-11 03:29, Tom Ritter 写道:
I've changed BOOL -> WINBOOL (although this is the only use of WINBOOL
in the file)
-tom
Thanks for the patch. I pushed it to master now.
Use of `WINBOOL` instead of `BOOL` (which is a typedef for `bool` in
objc) is m
On 1/14/22 02:29, LIU Hao wrote:
在 1/13/22 10:07 PM, Jonathan Marler 写道:
Been 3 months since my last email, what's going on with this?
On Tue, Oct 19, 2021 at 11:03 PM Jonathan Marler
wrote:
Jacek were you able to forward this discussion to Wine? If so do
you have
a link to that discussi
Signed-off-by: Jacek Caban
---
It's needed due to importlib handling changes in recent widl.
mingw-w64-headers/Makefile.am| 2 +-
mingw-w64-headers/tlb/{oleacc.idl => oleacc.dll.idl} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename mingw-w64-hea
On 1/16/22 23:51, Martin Storsjö wrote:
On Sat, 15 Jan 2022, Pali Rohár wrote:
In attachment are updated patches which adds these redirects and usage
of F_NON_I386() macro. With these redirects it is possible to compile
target mingw applications also with those gcc linker flags
-Wl,--disable-au
On 12/29/21 16:52, Martin Storsjö wrote:
On Wed, 29 Dec 2021, LIU Hao wrote:
在 2021-12-23 22:20, Pali Rohár 写道:
Original MSVC 6.0 msvcrt.dll library does not provide _vscprintf()
function. Therefore usage of snprintf() with this DLL library cause
application crash. Add simple fallback implemen
On 12/30/21 09:50, Martin Storsjö wrote:
Import the latest version of widl from wine
7f95c692998daa83cbeffcbe261ebbff80af54a8 (wine-7.0-rc3-17-g7f95c692998).
This fixes a regression in widl in the mingw-w64 setup after
826215b4e0b54fe459bce203024fe50ec883cad8, which imported a newer
version of w
On 11/1/21 4:20 PM, LIU Hao wrote:
在 2021-10-30 23:18, Tom Ritter 写道:
Hi, I wanted to follow up on this patch series and ask if they could
be landed? Thanks.
Perhaps Jacek has been busy with other stuff. I have pushed these
three patches to master for now.
I just came back from vacation
Signed-off-by: Jacek Caban
---
mingw-w64-crt/libsrc/ksuser.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mingw-w64-crt/libsrc/ksuser.c b/mingw-w64-crt/libsrc/ksuser.c
index 3cc7f1e33..b5e37fa7c 100644
--- a/mingw-w64-crt/libsrc/ksuser.c
+++ b/mingw-w64-crt/libsrc/ksuser.c
@@ -129,6
1 - 100 of 920 matches
Mail list logo
