I remember sending in a bug report to the developers of GNU make. They refused to fix the bug because cygwin and msys bash were, in their opinion, the only viable shell options on Windows and the only environments they wanted to officially support. When I tried to build autoconf with a natively built version of make on Windows, it just hung. There's also the problem of using make on Windows without a shell. The command prompt has a limitation of how many characters can be passed to it. Typically, it's not enough to be able to run many of the commands used in standard makefiles. So, using make with a shell on Windows is a requirement to work with typical makefiles from many Free, Libre and/or Open Source software projects.

Several years later, the landscape for Windows has changed. It's still incredibly hard to find a standard port of POSIX shells outside of Cygwin, msys and now msys2 projects. However, there are options. Some of the older options that were around when I reported the bug are winbash (an older version of bash natively ported to Windows) and winZsh (which has not been maintained for a while). More recently, with the port of busybox to Windows in the busybox-w32 project, we have access to a modern shell. That project makes the ash shell available. It can run natively in Windows. The one drawback is that you need to build busybox-w32 on a Linux machine with a cross-compiler. I did recently manage to build ash natively on Windows with a lot of patching and my own custom makefile. Another option is to use midipix to build bash or other shells but it has similar licensing constraints to Cygwin and the msys projects. An alternative that I haven't seen a lot of information about is using bash from WSL via the Windows command prompt. You actually don't need msys or similar environments with this option. You can run a cross compiler and Linux tools via WSL and access them all from a standard Windows command prompt outside of WSL. That opens up a lot of possibilities. There were other projects that were supposed to port shells to Windows that still haven't shared much in the way of results. I remember offering to work with the developers of the mksh to port it to Windows. They said they already had someone working on the port. I've yet to see a publicly available, natively built mksh running on Windows. Plus, with all these Windows shell options, I still haven't seen a fix to the GNU make project. I do continue to patch my builds of make with my own patch for the issue.

WSL is great for development on Windows. Even with WSL, Busybox-w32 and environments like Cygwin, msys2, msys and midipix, I still like the idea of a minimal native build system and shell. I'd like something I can build from source for myself on Windows. I'd also prefer to use tools with more lenient Open Source licenses over GNU GPL and AGPL options. I'm going to be experimenting with replacing the msys environment on my system with more native options that don't obscure my actual file path names and don't require compatibility with GPL licenses to get POSIX style core utility programs to work. I will still need some standard POSIX style utilities and programs if I want to build FLOSS projects that use GNU autotools. However, I've been avoiding using cmake for FLOSS projects that use it by creating my own build files. I may start doing that in the case of some FLOSS projects that use GNU autotools. libressl comes to mind since a change to their build scripts made them no longer work on Windows and I've yet to hear if they'll fix the issue or not. I've been using cDetect, GNU make and pkgconf for my build scripts. I wish someone would come up with a simpler replacement for GNU make that still offered enough flexibility to build FLOSS projects that require make.

The build environment I'm working towards will probably look like the following... I'm building ash from Busybox-w32 natively with my own scripts. I'm using a combination of POSIX style core utilities from projects such as Minix, sbase and BSD. I'm hoping for compatibility with Open Group standards not necessarily with GNU standards for the various utilities. At the moment, I'm using the GNU gcc compiler built from source. However, llvm is a nice option. I just haven't seen an easy way to build it from source on Windows. My main goal is to be able to build all parts of my environment from source code. It may not have as many features or as much compatibility as other development environments available on Windows. However, I like the idea of being able to modify and change the source code of every tool I use whenever I want to. One other thing I'd like to look for is a console program that I can build natively with my C compiler. If I get everything working for Windows, a lot of it will probably port to other environments fairly easily.

I know most people prefer to just download a prebuilt environment or let their package manager do that for them and they don't care about the ability to build every part of their development environment from scratch. However, if this does sound interesting to anyone else, if you're working on something similar or if want to discuss parts of this project with me further, feel free to contact me. You can reach me via Mastodon or Bluesky.
If you've tried to run Windows console programs (such as pdcurses based applications) using a terminal emulator (rxvt, mintty) via msys (including msys2), you'll probably have I/O issues. Output may not appear properly on the screen.

There are two work-arounds for the issue.

1. Use software from a project that deals with console/terminal incompatibilities.

Winpty - provides and interface similar to a Unix pty-master for communicating with Windows console programs.
https://github.com/rprichard/winpty

Alternative to MinGW and Cygwin and build scripts for various Open Source tools:
http://midipix.org/

2. Run the program in a console instead of a terminal.

I have an article on setting up msys to work with the standard Windows console instead of a terminal at:
http://www.distasis.com/cpp/msys.htm

For alternatives to the standard Windows console, take a look at these projects.

ConEmu Console emulator - Unlike Console 2, this has a build file for gcc.
https://conemu.github.io/

Console 2 - Command prompt replacement. May be used with cmd.exe or rxvt or other shells.
https://sourceforge.net/projects/console/

ConsoleZ - Console 2 fork with improved support for Windows Vista/7/8/10.
https://github.com/cbucher/console
This post includes a list of resources for building applications and libraries for Windows using MinGW or similar projects.


Just wanted to note some of the native Windows porting projects I've worked on before I list some of the other projects out there. I've compiled the X server code and built a X server on Windows (similar to the Xming X server but with all my own patches). I'm looking into porting msh to Windows and other platforms (including patches for better handling of internationalization/UTF-8 character codes). I'm working on porting various core utilities based on Minix, BSD and custom implementations. I have patches and build scripts for several Open Source libraries and programs. See http://www.distasis.com/cpp/lmbld.htm for further details and a link to some of the scripts and patches. I work with regex and fnmatch libraries based on MIT licensed code from musl. musl uses regex code from the BSD licensed tre library. I also work with a BSD gettext implementation based on code put together for PostgreSQL. The libiconv and iconv implementations I use are written from scratch using custom UTF-8/internationalization code. I also have my own custom implementations of libmman, libdl and pthreads as well as other libraries I use to help with porting applications.


Places to download builds of various Open Source software and libraries for Windows and MinGW:

http://gnuwin32.sourceforge.net/
Many of the GNU libraries and programs patched and recompiled for MinGW.

http://devpaks.org/
Devpaks repository Libraries for the Dev-C++ compiler which uses MinGW. Could also be used without Dev-C++. Files should be standard tar.bz2 files renamed with .devpak extension.

http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Factory/noarch/
OpenSuse Windows Packages has windows packages cross-compiled using MinGW on OpenSuse and the OpenSuse Build System (OBS).

https://sourceforge.net/projects/ezwinports/
ezwinports has ports of Unix and GNU software to MS-Windows.

https://sourceforge.net/projects/mingwrep/
MinGW packages repository

https://sourceforge.net/projects/takeoffgw/
TakeoffGW - Cygwin style package manager and native Windows packages built with the OpenSUSE Build Service.


Patches and build scripts to build Open Source software for Windows:

https://github.com/Alexpux/mingw-builds
https://github.com/mxe/mxe


MSYS and Cygwin alternatives:

http://midipix.org/
Alternative to MinGW and Cygwin and build scripts for various Open Source tools:

https://github.com/bmatzelle/gow/wiki
GNU on Windows - lightweight alternative to Cygwin. Native Win32 programs.

Busybox port for Windows:
https://github.com/pclouds/busybox-w32
Lightweight versions of core utilities.

Busybox-w32 fork:
https://frippery.org/busybox/

http://unxutils.sourceforge.net/
UnxUtils - Native Win32 ports of core utilities.

https://github.com/rubenvb/UnixToolsForWindows
Unix Tools for Windows - Native Windows implementations emulating core utilities written in C++.

http://sourceforge.net/projects/win-bash/
Native Win32 port of an older version of bash.

https://steve.fi/Software/bash/
GNU Bash for Windows

https://sourceforge.net/projects/zsh-nt/?source=directory
WinZsh - Z shell for Windows

http://www.straightrunning.com/XmingNotes/
Xming X Server - Windows native X server


Open Source libraries patched for Windows:

http://waterlan.home.xs4all.nl/libintl.html
Relocatable libintl for MinGW.

https://github.com/dlfcn-win32/dlfcn-win32
POSIX dynamic runtime library loading (libdl) compatibility routines.

https://code.google.com/archive/p/mman-win32/
POSIX mmap functionality.

http://synesis.com.au/software/unixem.html
Various POSIX functions implemented for Windows.

https://github.com/rprichard/winpty
Winpty - provides and interface similar to a Unix pty-master for communicating with Windows console programs.


Pthreads and C/C++ 11 threads compatibility patches and implementations:

https://sourceware.org/pthreads-win32/
pthreads-win32 - Red Hat's POSIX thread library for Win32.

http://jmhartsoftware.com/Pthreads_Emulation.html
Simplified Pthread Emulation with Macros - Minimal pthread emulation.

https://tinycthread.github.io/
TinyCThread - C11 threads implementation

https://github.com/jtsiomb/c11threads
c11threads - GNU compatibility headers for C11 thread support

MinGW

May. 5th, 2016 12:29 pm
There are now several forks of MinGW and each has its pros and cons. However, there are now enough negatives to using them, that I've found it necessary to build MinGW from scratch myself. The MinGW64 project uses a later version of gcc, has better compatibility for building Open Source projects and has its own thread library instead of using Red Hat's pthreads-w32. Some custom builds of MinGW64 even have POSIX threading set as the default instead of Win32 threading. That means better compatibility for C++ thread related code (since the GNU C++ library relies on POSIX threading for parts of its implementation). The MinGW project has always been more careful about licensing and making sure that the code it was using was properly licensed and legal for usage. The MinGW project did follow the example of the MinGW64 project in one key area. They switched from public domain to a MIT license for their runtime library and Win32 API. When they did so without clearly indicating that an exception could be made similar to the GNU gcc runtime license exception, I felt it was time to stop using that version of the MinGW compiler.

I'm currently working with gcc 4.9.2 compiled from source. I'm still using the older public domain APIs, but I've made several modifications for compatibility with the Win32 API (including some modifications that aren't available in the MinGW64 libraries). I have a minimal thread library that was custom written for portability. It's based on C11 thread support and includes POSIX functionality. The gnu compiler is built with POSIX threads as the default so C++ threading works as expected.

So far, I've had no reason to want to work with any other MinGW forks. The version I have does everything I need and supports all the programs I want to compile on Windows. My particular fork is continually evolving. I continue to add support for new Win32 API changes, Win32 API omissions, new C/C++ features as I need them. At some point, I hope to completely replace the runtime library with code that better supports internationalization (better UTF-8 support), C standard compatibility and other useful features.

If anyone else is finding limitations with the compilers maintained by the various MinGW and MinGW64 projects or other related forks based on these projects, I highly recommending building the GNU compiler from source on your own with the options you need most. If you're interested in discussing the GNU compiler further or want to know more about my modifications, you're welcome to use the CppDesign mailing list ( http://groups.yahoo.com/group/CppDesign ) as a forum for further discussion.

April 2025

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
27282930   

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated May. 29th, 2025 01:02 pm
Powered by Dreamwidth Studios