mingw-w64
GCC for Windows 64 & 32 bits
Table of Contents
Mingw-w64
Mingw-w64 is an advancement of the original mingw.org project, created to support the GCC compiler on Windows systems. It has forked it in 2007 in order to provide support for 64 bits and new APIs. It has since then gained widespread use and distribution.
The development and community are very active and welcoming with new contributors every month and simple installers.
Version 6 has been released
v6.0.0: 2018-09-17
Notable changes:
- C++ __cxa_atexit thanks to Martin Storsjö and Liu Hao
- Massive additions to support UCRT thanks to Martin Storsjö
- Sync COM interface headers with Wine development thanks to Jacek Caban
- WinRT additions thanks to Hugo Beauzée-Luyssen
- ARM32 and ARM64 additions thanks to Martin Storsjö
- CRT library api-ms-win-core additions thanks to Martin Storsjö
- CRT library def file reorganization thanks to Martin Storsjö
You can also look at the full list of versions.
Headers, Libraries and Runtime
- More than a million lines of headers are provided, not counting generated ones, and regularly expanded to track new Windows APIs.
- Everything needed for linking and running your code on Windows.
- Winpthreads, a pthreads library for C++11 threading support and simple integration with existing project.
- Winstorecompat, a work-in-progress convenience library that eases conformance with the Windows Store.
- Better-conforming and faster math support compared to Visual Studio's.
Tools
- gendef: generate Visual Studio .def files from .dll files.
- genidl: generate .idl files from .dll files.
- widl: compile .idl files.
Friend projects
Mingw-w64 interacts a lot with other projects in order to help everyone move forward. Contributions have been going to and coming from these projects:
Some Projects using Mingw-w64
Most Recent Activity
17.01.2019
I take it back, on Windows "regular_file/" is the same path as "regular_file" so stripping the slash is fine, and works consistently with the expected behaviour on the OS. I was foolishly expecting Windows to have sane pathname handling, but I was wrong.
17.01.2019
This just seems to be how Windows works, and so is a feature not a bug. I was trying to make the MinGW version of std::filesystem::status behave similar to POSIX, but after comparing it to boost::filesystem::status I think I should just accept this behaviour as correct for Windows. Feel free to close this ticket.
17.01.2019
This just seems to be how WIndows works, and so is a feature not a bug. I was trying to make the MinGW version of std::filesystem::status behave similar to POSIX, but after comparing it to boost::filesystem::status I think I should just accept this behaviour as correct for Windows. Feel free to close this ticket.
17.01.2019
I can confirm this in native Win10 in 32-bit mode. Maybe we should add stat function that checks if dirs are valid -- proposition in attachment.
17.01.2019
I forgot to say that I've only tested this under Wine, not on real Windows. I don't know if the same behaviour is seen on Windows.
16.01.2019
The fix looks wrong, it means that _stat("regular_file/", &buf) will resolve to "regular_file" but a trailing slash should only be valid on a directory. Stripping the slash unconditionally is wrong. A better fix would be to append "." to the path, so that something ending in a slash is treated as a directory, but that won't work because of https://sourceforge.net/p/mingw-w64/bugs/782/
16.01.2019
stat, _stat, _wstat etc. incorrectly resolve '..' components in path
16.01.2019
headers: Add DWRITE_VERTICAL_GLYPH_ORIENTATION definition.
15.01.2019
include: Add remaining interface definitions from dwrite_1.h.