This is an old revision of the document!
Mingw-w64 and the ecosystem surrounding it are stable and with many features. There are however some topics for which developer-time has been scarce. This page lists tasks that are relatively simple and can be worked on without the need for a huge background while still being important and high on the wish-lists of users.
In order to avoid duplicate efforts, if you take on one of these tasks, please mention it on the mailing-list.
The tasks below have been split enough to be simple and fairly well-contained while still being useful on their own. Most could be internship topics.
There are references to other websites on this page; their presence does not constitute an endorsement in any way.
The patent for SEH for 32bits has now expired and while new computers are all 64 bits, Intel has continued selling Atom CPUs that only handled 32 bits very late and some applications are still 32 bits. Projects such as Wine and ReactOS will also benefit from 32bits SEH. Overall the need is still there and will continue for years to come and will outlast Microsoft's support for 32bits.
Note that you will need FSF paperwork since the work has to be done inside GCC. Check CC's page on contributing.
Sanitizers are runtime checks for a number of situations which have usually required instrumentation with tools that cause an important slowdown (like Valgrind).
They are relatively new and much lighter than other approaches.
ASAN, TSAN and USAN are great technologies which are available in GCC. Unfortunately they are not completely usable on Windows. A proper review and tests are needed before anything.
Once a report on the status is available, work on it can be started.
Optimizations in C cannot cross compilation units and many of them are therefore missed in large applications and when using libraries. LTO runs some optimizations during linking, when the toolchain can see all the objects at once and run cross-unit optimizations.
LTO has recently been improved a lot in GCC and binutils. There are still some issues on Windows though. The first step to making it work is to get a proper and up-to-date test and to identify the platform-specific bugs.
Fix the issues found by the status report from above. The actual bug list will be updated as it becomes available.
A compiler plugin would make GCC, binutils tools and GDB available from the Visual Studio IDE. Most people state they stick with VS because of the IDE; such a plugin would allow mixing the two.
VisualGDB (commercial) provides such a plugin, apparently meant for compiling to micro-controllers and Linux (Android or not).
PDB is the file-format used by Microsoft to store debug info. Unfortunately it is undocumented.
Since the format is undocumented, first step is to document it. Fortunately, during the past few years, reader and possibly writer code has appeared, mostly out of Microsoft.
Creating PDB files will allow the Microsoft tools to make meaningful backtraces when code built with free compilers is involved.
Reading PDB files will allow free tools to make meaningful backtraces when code built with MSVC is involved.
Most often debug informations will only be available in a single format. Being able to convert between them when needed will be useful.
The C11 standard has a section on threading which is still left unimplemented on several platforms. The API follows pthreads' quite closely and it is left to the implementor to decide whether to base it on winpthreads or directly on the (>= Vista) Win32 API.
The final C11 draft is identical to the standard but is available freely.
Note that you will need FSF paperwork since the work has to be done inside GCC. Check GCC's page on contributing.