I've changed BOOL -> WINBOOL (although this is the only use of WINBOOL
in the file)
-tom
On Fri, 7 Jan 2022 at 23:25, Biswapriyo Nath wrote:
>
> Replace BOOL with WINBOOL.
From 1e194838686c2db26d120ff6c024ee349df0fbf7 Mon Sep 17 00:00:00 2001
From: Tom Ritter
Date: Fri, 7 Jan
___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
From 4dac0becbe4da4042ed7b3d01d51558cf6eeb898 Mon Sep 17 00:00:00 2001
From: Tom Ritter
Date: Fri, 7 Jan 2022 10:52:40 -0500
Subject: [PA
From a0788a96d75cb46ab813d4e7984f3d3a133f128f Mon Sep 17 00:00:00 2001
From: Tom Ritter
Date: Wed, 5 Jan 2022 22:32:47 -0500
Subject: [PATCH] Add IVirtualDesktopManager
---
mingw-w64-headers/include/shobjidl.h | 138 +
mingw-w64-headers/include/shobjidl.idl | 11
From 10ca079810ea8d50340e98fc7b6579f73595d668 Mon Sep 17 00:00:00 2001
From: Tom Ritter
Date: Fri, 17 Dec 2021 09:39:03 -0500
Subject: [PATCH 2/2] Add missing KScategories
---
mingw-w64-headers/include/ks.h | 125 +
1 file changed, 125 insertions(+)
diff --git
From 52170da06a19b955bddd54839c9b4c5d853137c1 Mon Sep 17 00:00:00 2001
From: Tom Ritter
Date: Fri, 17 Dec 2021 09:37:07 -0500
Subject: [PATCH 1/2] Reorder existing KSCategories to be aphabetical
---
mingw-w64-headers/include/ks.h | 52 +-
1 file changed, 26
Sorry about that!
On Thu, 11 Nov 2021 at 20:00, Biswapriyo Nath wrote:
>
> The patch is not attached. Wondering if it is possible to include ks.h
> in kuser.c file like other *-uuid.c files.
From b7458fa3d1371aee74fecc90df8b191d20877d84 Mon Sep 17 00:00:00 2001
From: Tom Ritter
Date
ks.h is missing many of the defines that are specified in ksuser.c
file - this copies all the ones from ksuser.c to ks.h
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-publ
As mentioned earlier, I get a compilation error because the underlying
type for this enum is not specified when it is forward declared. This
type matches the one used by Microsoft.
From aa846d35bfcffc0b182a1b0437f9ad5fc84ce216 Mon Sep 17 00:00:00 2001
From: Tom Ritter
Date: Wed, 10 Nov 2021 12
I was getting this error when compiling including windows.foundation.h:
error: ISO C++ forbids forward references to 'enum' types
Digging into this, I learned that forward declaring an enum is allowed
in C++11 but only if the underlying type (e.g. int) is declared. more:
https://stackoverflow.com/
Hi, I wanted to follow up on this patch series and ask if they could
be landed? Thanks.
On Fri, 15 Oct 2021 at 15:50, LIU Hao wrote:
>
> 在 2021-10-15 04:55, Jacek Caban 写道:
> > Signed-off-by: Jacek Caban
> > ---
> > mingw-w64-headers/include/winuser.h | 5 -
> > 1 file changed, 4 inserti
Okay, the attached fixes that issue, I think this is ready now.
-tom
On Tue, 3 Dec 2019 at 12:46, Tom Ritter wrote:
>
> Hm. I haven't debugged this yet; but apparently something is still missing:
>
> > lld-link: err
Hm. I haven't debugged this yet; but apparently something is still missing:
> lld-link: error: undefined symbol:
> __Z14__mingw_uuidofI26IDCompositionDesktopDeviceERK5_GUIDv
(and more)
-tom
On Tue, 3 Dec 2019 at 04:59, Tom Ritter wrote:
>
> Attached is a correct patch (hopefu
first, enums at last.
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
From 1fd460dfe00ca9cb15b6dd84ee4ea9f806d1de82 Mon Sep 17 00:00:00 2001
From: Tom Ritter
Date: Thu, 28 Nov 2019 22:20:28 -0600
Subj
The attached additions are needed for Firefox; some new interfaces,
constants, etc.
-tom
From aeb22c3a17cc5d6eb043385f87e3f3c2081d7fc9 Mon Sep 17 00:00:00 2001
From: Tom Ritter
Date: Thu, 28 Nov 2019 22:20:28 -0600
Subject: [PATCH] Add interfaces to dcomp.h, two constants to dcomptypes.h
Oops, forgot to git add. Sorry.
-tom
On Wed, 21 Aug 2019 at 09:34, Martin Storsjö wrote:
>
> On Tue, 20 Aug 2019, Tom Ritter wrote:
>
> > Updated!
>
> Now the patch removes it from lib64 and libarm32, but doesn't add it to
>
Updated!
On Tue, 20 Aug 2019 at 18:35, Martin Storsjö wrote:
>
> On Tue, 20 Aug 2019, Tom Ritter wrote:
>
> > The x64 urlmon.def was out of date in comparison to the x86 version. I
> > was advised that the arm version looked correct, so I copied that one
> > into
2001
From: Tom Ritter
Date: Sat, 17 Aug 2019 11:24:29 -0500
Subject: [PATCH] Update urlmon.def
The x64 urlmon.def was out of date in comparison to the x86 version.
The arm version looked correct, so that was copied into lib-common and
the others removed (except x86 which gets special treatment
The attached patch fixes an error from the recent commit for netlistmgr.h
-tom
From 660c608cdde7a2398fc4f599a7b0c004f2746d87 Mon Sep 17 00:00:00 2001
From: Tom Ritter
Date: Tue, 2 Jul 2019 08:23:18 -0500
Subject: [PATCH] Add include to uuid.c to resolve undefined symbols
This patch moves MEMORY_PRIORITY_ defines outside a _WIN32_WINNT #if
check to match Microsoft's definitions, which are in winnt.h and not
behind any version #ifs.
-tom
From 84d449158871f8bdd2bb1969b71261d5183d3b38 Mon Sep 17 00:00:00 2001
From: Tom Ritter
Date: Thu, 20 Jun 2019 11:41:52
On Wed, 22 May 2019 at 16:53, Jacek Caban wrote:
> [Fixes]
Thanks! Here are updated versions.
-tom
From 3c9828b560e978b42037d1ab18412d8c8062834f Mon Sep 17 00:00:00 2001
From: Tom Ritter
Date: Wed, 22 May 2019 10:51:24 -0500
Subject: [PATCH 1/3] Add concurrencysal.h to the headers
---
mi
While updating the chromium sandbox in Firefox we identified the
following SDK components missing from MinGW.
(Hopefully I remembered how to attach patches so the mailing list accepts them)
-tom
From aeebd607b7d6a8b42d98b97205f70188b4945af9 Mon Sep 17 00:00:00 2001
From: Tom Ritter
Date: Wed
With the bump to d3dcompiler_47 in
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/2d4e517ad0c7a9f0bd7001c42e6c131b977c15d9/
I think the following needed to be updated as well:
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/Makefile.am#l73
-tom
__
This is not really a MinGW problem, but MinGW does diverge from other
compilers and it caused Firefox to crash.
MinGW defines a lot of I64[foo] format specifiers in inttypes.h.
clang and clang-cl don't use I64[foo] they use ll[foo]. (I64[foo] is
valid according to Microsoft. MinGW mentions "MS run
On Thu, 18 Oct 2018 at 12:20, Jacek Caban wrote:
>
> Hi Martin,
>
> On 10/17/2018 10:08 PM, Martin Storsjö wrote:
> > These are normally only referenced by objects in libmingwex. However,
> > ntdll also contains the function _snwprintf. Depending on the order that
> > object files and libraries ar
In mingw-w64-headers/crt/time.h:
#if __MSVCRT_VERSION__ >= 0x1400
#define __MINGW_ATTRIB_DEPRECATED_UCRT \
__MINGW_ATTRIB_DEPRECATED_MSG( \
"Only provided for source compatibility; this variable might " \
"not always be accurate when linking to ucrtbase.dll.")
#define daylight
Hit an error compiling Firefox because 1471 wasn't defined.
-tom
From 71ee4edf14d76ddacb8154620024c7a8b60be18b Mon Sep 17 00:00:00 2001
From: Tom Ritter
Date: Thu, 2 Aug 2018 09:50:56 -0500
Subject: [PATCH] Add Error Codes between 1460 and 1471
---
mingw-w64-headers/include/winerror.h
I feel pretty confident that this line has a bug, and the for
initialization should be 'target = RenderTarget'
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/direct-x/include/d3d11.h#l1644
I was getting errors in CreateBlendState passing in this structure
with Inva
in
https://stackoverflow.com/a/866731) causes objcopy to segfault. It
seems all x64 MinGW builds I have tried doing this to cause objcopy to
segfault.
I filed a bug on this here:
https://sourceware.org/bugzilla/show_bug.cgi?id=23061
-tom
On 13 April 2018 at 02:39, Tom Ritter wrote:
> Okay
Okay, I've been digging into this and have more information. I have a
few things I'm going to try, but any insight into what might be
happening or why or other things to try would be greatly appreciated.
The DWARF data is definitely bad. Specifically the offset into the
.debug_abbrev section is
I'm building Firefox with debug information - I've tried both x86 and
x64 versions -
and it produced a gigantic 2+GB xul.dll. I believe that in the
process it is also outputting bad DWARF information though, and
preventing it from running (or being debugged).
I have two scenarios of the same (?)
00:00:00 2001
From: Tom Ritter
Date: Mon, 26 Feb 2018 20:15:20 -0600
Subject: [PATCH] Work around "stdcall function returning an aggregate is
incompatible with MS ABI" bug
Background:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384
https://sourceforge.net/p/mingw-w64/mailman/mingw
The whitespace was inconsistent in this area, so I replaced the tabs
with spaces.
-tom
From eeaca371370ce9e4996a1a4c6a598205866a2c44 Mon Sep 17 00:00:00 2001
From: Tom Ritter
Date: Mon, 22 Jan 2018 20:19:19 -0600
Subject: [PATCH 1/2] Fix whitespace near the PROCESS_MITIGATION structs
---
mingw
Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1431809
This syncs the PRODUCT_ENTERPRISE_XXX defines between widl and
headers, and declares ERROR_INVALID_TOKEN in headers
-tom
From d258bc0274c8b1b63ed8ea4d31e6ab8a8b621833 Mon Sep 17 00:00:00 2001
From: Tom Ritter
Date: Mon, 22 Jan
Afraid I was too eager, the newly attached one correctly defines
ERROR_INVALID_TOKEN in all the places.
-tom
On 22 January 2018 at 11:58, Tom Ritter wrote:
> Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1431809
>
> This syncs the PRODUCT_ENTERPRISE_XXX defines between
We missed one, here is the additional patch.
-tom
On 18 October 2017 at 11:55, Jacek Caban wrote:
> On 18.10.2017 18:50, Tom Ritter wrote:
>> On 18 October 2017 at 02:58, Jacek Caban wrote:
>>> The attachment didn't make it to the mailing list.
>> Whoops, sorr
On 18 October 2017 at 02:58, Jacek Caban wrote:
> The attachment didn't make it to the mailing list.
Whoops, sorry, let me try with a .txt. If that fails:
https://pastebin.mozilla.org/9070416
-tom
From 297ce100d033e69c41abf19cfd0839477050e6ae Mon Sep 17 00:00:00 2001
From: Tom Ritter
D
Attached is a patch that I think, maybe, resolves the issue in
https://bugzilla.mozilla.org/show_bug.cgi?id=1372958#c10
-tom
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.
Hi all,
I work at Mozilla, and have been the person working there actively
getting Mozilla building with mingw (again); and I recently got it
into our build servers. Mostly I relied on Jacek to write patches I
needed in mingw (as well as help me with the hardest parts of the
build, since he mainta
38 matches
Mail list logo
