Added Mingw support by TracerDS · Pull Request #1652 · brainboxdotcc/DPP

TracerDS · 2026-09-12T19:15:00Z

[ Please outline your change here. Be sure to check the checkboxes below. ]
The current version of DPP does not support mingw environments (ucrt64, clang64).
This PR adds this support.

Code change checklist

I have ensured that all methods and functions are fully documented using doxygen style comments.
My code follows the coding style guide.
I tested that my change works before raising the PR.
I have ensured that I did not break any existing API calls.
I have not built my pull request using AI, a static analysis tool or similar without any human oversight.

netlify · 2026-09-12T19:15:05Z

✅ Deploy Preview for dpp-dev ready!

Name	Link
🔨 Latest commit	`5c581de`
🔍 Latest deploy log	https://app.netlify.com/projects/dpp-dev/deploys/6ac78f5e19f6c800081dc7da
😎 Deploy Preview	https://deploy-preview-1652--dpp-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Copilot

🟡 Changes recommended

Five unresolved findings remain, including two critical issues affecting Windows/MSYS2 builds.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds MinGW/MSYS2 support, including UCRT64 and CLANG64, through centralized platform detection, Windows/networking updates, CMake integration, and documentation.

Changes:

Adds platform and compiler detection macros.
Updates socket, SSL, compatibility, and CMake handling.
Documents MSYS2 build configurations.

File summaries

File	Changes	Final review note
`src/unittest/test.h`	Uses centralized platform/compiler checks.	Critical (3 votes): `DPP_USE_MSVC` and `DPP_USE_WINDOWS` are tested before DPP headers are included, causing Windows unit tests to select `libdpp.so`.
`src/sockettest/socket.cpp`	Adjusts Windows socket setup.	No final comment.
`src/dpp/voice/enabled/enabled.h`	Updates Windows detection.	No final comment.
`src/dpp/utility.cpp`	Updates Windows C runtime handling.	No final comment.
`src/dpp/sslconnection.cpp`	Updates platform-specific socket logic.	No final comment.
`src/dpp/ssl_context.cpp`	Updates Windows certificate handling.	No final comment.
`src/dpp/socketengine.cpp`	Updates Winsock cleanup detection.	No final comment.
`src/dpp/socket.cpp`	Removes a redundant template instantiation.	No final comment.
`src/dpp/queues.cpp`	Updates Windows I/O includes.	No final comment.
`src/dpp/httpsclient.cpp`	Uses the invalid-socket sentinel.	No final comment.
`src/dpp/discordevents.cpp`	Updates time conversion detection.	No final comment.
`src/dpp/dave/persisted_key_pair_generic.cpp`	Updates platform-specific file handling.	Critical (3 votes): `DPP_USE_WINDOWS` is evaluated before DPP headers, causing Windows and MSYS2 builds to include `unistd.h` instead of the required Windows declarations.
`src/dpp/cluster.cpp`	Updates Windows configuration validation.	No final comment.
`library/CMakeLists.txt`	Adds MinGW detection and dependency handling.	Moderate (3 votes): The new `DPP_MINGW` fallback is not used consistently with existing `MINGW` checks, potentially selecting MSVC libraries and omitting MinGW libraries.
`include/dpp/win32_safe_warnings.h`	Limits warning pragmas to MSVC.	No final comment.
`include/dpp/system.h`	Adds platform/compiler detection.	Moderate (3 votes): Apple toolchains match the generic Unix branch first, so `DPP_USE_MACOS` is not defined and macOS is reported as Unix.
`include/dpp/sysdep.h`	Uses centralized platform guards.	No final comment.
`include/dpp/sslconnection.h`	Uses a platform-neutral error sentinel.	No final comment.
`include/dpp/socket.h`	Makes socket types platform-aware.	No final comment.
`include/dpp/socket_listener.h`	Fixes invalid socket checking.	No final comment.
`include/dpp/nlohmann/json.hpp`	Adds platform/compiler metadata.	Moderate (2 votes): DPP macros may be undefined when the public JSON header is included first, causing `json::meta()` to report unknown platform and compiler values.
`include/dpp/message.h`	Removes enum export decoration.	No final comment.
`include/dpp/export.h`	Integrates system detection.	No final comment.
`include/dpp/dns.h`	Updates socket includes.	No final comment.
`include/dpp/discordvoiceclient.h`	Updates Windows defaults.	No final comment.
`include/dpp/compat.h`	Adds MinGW-compatible Winsock handling.	No final comment.
`docpages/building/windows.md`	Documents MSYS2 builds.	No final comment.

Review details

Files reviewed: 27/27 changed files
Comments generated: 5
Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

braindigitalis · 2026-09-13T10:09:59Z

this pr is way too big. it touches so much stuff. how can we know it doesn't break something, it's diving in changing functionality outside the build system, renaming variables, moving includes.

is it tested? does it have working ci?

secondly, who is going to support it after it's merged? I for one don't really like mingw and it is another target to support, test in ci, run unit tests on.

thirdly who added all these ai reviews, copilot is NOT an authorised reviewer of dpp!

braindigitalis

this pr is far too big in its current form and changes too many things outside the build system.

we already support proper native windows builds so mingw as a crutch is not needed.

braindigitalis · 2026-09-13T10:31:26Z


 template bool raii_socket::set_option<int>(int, int, int);
 template bool raii_socket::set_option<bool>(int, int, bool);
-template bool raii_socket::set_option<socklen_t>(int, int, socklen_t);


why remove it?

It causes issues as socklen_t = int on mingw toolchain.
So it causes redefinition

template bool raii_socket::set_option<int>(int, int, int); template bool raii_socket::set_option<bool>(int, int, bool); template bool raii_socket::set_option<int>(int, int, int);

So you need to remove the int specialization then, not the socklen_t specialization.

~~sure, either one will work.~~

The codebase uses explicit int template, e.g.
include/dpp/socket_listener.h

fd.set_option<int>(SOL_SOCKET, SO_REUSEADDR, 1);

include/dpp/socket.h

extern template DPP_EXPORT bool raii_socket::set_option<int>(int level, int name, int value);

TracerDS · 2026-09-13T13:10:31Z

this pr is way too big. it touches so much stuff. how can we know it doesn't break something, it's diving in changing functionality outside the build system, renaming variables, moving includes.

It doesnt change any funcitonality, only CMakeLists is modified and made definitions rely on compiler macros. Basically the same thing as it was before but with more detections.

is it tested? does it have working ci?

Its working fine.

secondly, who is going to support it after it's merged? I for one don't really like mingw and it is another target to support, test in ci, run unit tests on.

You dont run unit tests to check compilers. You write unit tests to check the code. It will naturally be supported as no changes touched the actual codebase.

thirdly who added all these ai reviews, copilot is NOT an authorised reviewer of dpp!

Its been added by default. Your repo, your settings 🙄

we already support proper native windows builds so mingw as a crutch is not needed.

MSVC only is not a good support choice. Clang on windows works dubiously if at all.
Non MSVC clang (clang++) doesn't work at all,
clang-cl not only doesnt recognize windows syntax flags (/Zc:preprocessor) but it also as above doesnt compile even with MSVC compatible mode.

- Removed changes in the thirdparty lib - Removed useless change in `current_date_time` - Improved Mingw detection in `library/CMakeLists` - Fixed possible macro issues

Jaskowicz1 · 2026-09-13T15:31:07Z

@braindigitalis See discord for discussion on Copilot, seems they've broken it again, not the fault of this review (from what I understand).

Mishura4 · 2026-09-14T06:40:17Z

MSVC only is not a good support choice. Clang on windows works dubiously if at all.
Non MSVC clang (clang++) doesn't work at all,
clang-cl not only doesnt recognize windows syntax flags (/Zc:preprocessor) but it also as above doesnt compile even with MSVC compatible mode.

What are you talking about? We literally test clang-cl as part of our CI/CD pipeline.

Mishura4

We will not officially support MinGW. None of the maintainers use it as there is almost no reason to with MSVC and clang-cl. We would have to be careful that none of our changes break it, and that's not something we can or are willing to do.

With that said I don't mind a PR that fixes it for now, but then we cannot have a tutorial that explains how to build it in MinGW, as we cannot officially support it. If it breaks in the future, then it breaks, and we can't care.

TracerDS · 2026-09-14T09:14:34Z

We will not officially support MinGW. None of the maintainers use it as there is almost no reason to with MSVC and clang-cl. We would have to be careful that none of our changes break it, and that's not something we can or are willing to do.

As stated above there is nothing to actually support. As long as the include checks compare the system macros (DPP_USE_...) then nothing will break. MSVC is actually not a good compiler for the actual use. Which leaves the other option of clang-cl but it has issues above. And you're obviously only limited to the VS toolchain.
Supporting mingw will also bring new contributors who dont rely on VS tools. The build process would also be simplified as its still just gcc/clang under the hood but with a different shell.

Mishura4 · 2026-09-14T21:40:48Z

You have been given reasons as to why we will not officially support MinGW, and you have chosen to ignore them. You have been given a proposition for a compromise, and you have chosen to ignore it as well.

Well, good luck.

TracerDS · 2026-09-15T08:50:33Z

You have been given reasons as to why we will not officially support MinGW, and you have chosen to ignore them. You have been given a proposition for a compromise, and you have chosen to ignore it as well.

Well, good luck.

??? What are you taking about? I've given reasons to support it and the only valid reason you said you won't is because current collaborators sit on msvc only.

It is not my role to start supporting it or not, there is no compromise as I'm not the one that's making the decision.

Ashthetik · 2026-09-15T09:18:31Z

We will not officially support MinGW. None of the maintainers use it as there is almost no reason to with MSVC and clang-cl. We would have to be careful that none of our changes break it, and that's not something we can or are willing to do.

As stated above there is nothing to actually support. As long as the include checks compare the system macros (DPP_USE_...) then nothing will break. MSVC is actually not a good compiler for the actual use. Which leaves the other option of clang-cl but it has issues above. And you're obviously only limited to the VS toolchain.
Supporting mingw will also bring new contributors who dont rely on VS tools. The build process would also be simplified as its still just gcc/clang under the hood but with a different shell.

In what way is MSVC/clang-cl not a good compiler for windows? It's compliant to the WinAPI ABI, and has no issues with optimisations, linking, or building in general

I've personally found MinGW to hold extensive compatibility issues with Windows especially around networking since the Windows TCP stack is different to Unix/Linux. MinGW tends to also get flagged as suspicious/PUP because they don't follow the standard PE architecture without having to add rs and rec files to the project

TracerDS · 2026-09-15T09:57:47Z

In what way is MSVC/clang-cl not a good compiler for windows? It's compliant to the WinAPI ABI, and has no issues with optimisations, linking, or building in general

I've personally found MinGW to hold extensive compatibility issues with Windows especially around networking since the Windows TCP stack is different to Unix/Linux. MinGW tends to also get flagged as suspicious/PUP because they don't follow the standard PE architecture without having to add rs and rec files to the project

mingw is nowadays fully compatible with windows. It also has no issues with optimisations, linking or building in general. In fact, mingw is a better candidate for building stuff because it is basically a posix shell on windows so backporting anything non-windows to windows is trivial. It also compiles a fully native windows PE exec. So if they get flagged, we got one reason out of the picture. Resource files are also part of the windows resource mechanism, not a required thing to be conformant with PE execs.

MSVC is notoriously known for not following the standard, it requires you to have the exact same toolchain to work, you cant crosscompile.
clang-cl is just msvc in disguise.
You also have the deprecation by windows of using C functions and going over to their "safe variants" (..._s). The "has no issues with optimisations" is also a stretch. One example of such inconsistency can be found here.

The networking stack isnt what you say it is really. Windows exposes a bsd api for sockets (and thus, networking) to be more or less compatible with earlier iterations of berkeley's sockets (the api all networking on linux relies on). It has its own winapi for networking but the general backbone was still dependent on the old sockets behaviour. Sure, the differences in how each system does networking is different. But its trivial to separate these issues and fix them especially with the knowledge and libraries we have in 2026.

Don't take it as an attack for MSVC and saying how MSVC is a terrible compiler and to never ever ever use it.
I use it all the time, it does its job. But mingw is also a solid choice to compile nowadays especially with how easy it is to crosscompile with it.

Added Mingw support

40295d8

github-actions Bot added documentation Improvements or additions to documentation build Issue or Pull Request related to the build process code Improvements or additions to code. labels Sep 12, 2026

TracerDS added 2 commits September 12, 2026 21:28

Fixed typo, improved documentation

1571b6b

Merge branch 'dev' into feature-Add_mingw_support

afe29a8

TracerDS marked this pull request as ready for review September 13, 2026 08:54

Copilot AI lite review requested due to automatic review settings September 13, 2026 08:54

Copilot started reviewing on behalf of TracerDS September 13, 2026 08:59

View session

Copilot AI reviewed Sep 13, 2026

View reviewed changes

Comment thread src/dpp/dave/persisted_key_pair_generic.cpp

Comment thread src/unittest/test.h

Comment thread include/dpp/nlohmann/json.hpp Outdated

Comment thread include/dpp/system.h Outdated

Comment thread library/CMakeLists.txt

braindigitalis requested changes Sep 13, 2026

View reviewed changes

Comment thread include/dpp/nlohmann/json.hpp Outdated

braindigitalis requested changes Sep 13, 2026

View reviewed changes

Comment thread include/dpp/nlohmann/json.hpp Outdated

braindigitalis reviewed Sep 13, 2026

View reviewed changes

Comment thread src/dpp/utility.cpp Outdated

braindigitalis reviewed Sep 13, 2026

View reviewed changes

Comment thread src/dpp/httpsclient.cpp

braindigitalis reviewed Sep 13, 2026

View reviewed changes

Comment thread include/dpp/export.h

Applied changes from the reviews

01f1df6

- Removed changes in the thirdparty lib - Removed useless change in `current_date_time` - Improved Mingw detection in `library/CMakeLists` - Fixed possible macro issues

Mishura4 requested changes Sep 14, 2026

View reviewed changes

Merge branch 'dev' into feature-Add_mingw_support

5c581de

Conversation

TracerDS commented Sep 12, 2026

Code change checklist

Uh oh!

netlify Bot commented Sep 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for dpp-dev ready!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

braindigitalis commented Sep 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

braindigitalis left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

braindigitalis Sep 13, 2026

Choose a reason for hiding this comment

Uh oh!

TracerDS Sep 13, 2026

Choose a reason for hiding this comment

Uh oh!

Mishura4 Sep 14, 2026

Choose a reason for hiding this comment

Uh oh!

TracerDS Sep 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TracerDS commented Sep 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Jaskowicz1 commented Sep 13, 2026

Uh oh!

Mishura4 commented Sep 14, 2026

Uh oh!

Mishura4 left a comment

Choose a reason for hiding this comment

Uh oh!

TracerDS commented Sep 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Mishura4 commented Sep 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TracerDS commented Sep 15, 2026

Uh oh!

Ashthetik commented Sep 15, 2026

Uh oh!

TracerDS commented Sep 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

netlify Bot commented Sep 12, 2026 •

edited

Loading

braindigitalis commented Sep 13, 2026 •

edited

Loading

TracerDS Sep 14, 2026 •

edited

Loading

TracerDS commented Sep 13, 2026 •

edited

Loading

TracerDS commented Sep 14, 2026 •

edited

Loading

Mishura4 commented Sep 14, 2026 •

edited

Loading