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.
While WSL is great, I've always wanted a native POSIX environment for developing on Windows. I wanted one that didn't require specialized DLLs with GNU GPL licenses such as as Cygwin and MSYS do. There are other options available. Midipix provides a POSIX environment for easily porting and developing POSIX compliant applications on Windows. The licensing isn't any more lenient than Cygwin though. It does use the MUSL C library which is a nice feature. There's AT&T's Uwin project which is now available as Open Source: https://github.com/att/uwin The license for the project isn't exactly compatible with GPL software. I've looked into native POSIX shell alternatives to those found in projects like Cygwin and msys. Bash is not easy to port to Windows without Cygwin or msys DLLs to support various functionality. It isn't exactly easy to port to DOS either. Most bash ports to DOS and Windows are older ones. One Windows port that builds successfully on Windows with MinGW32 is: http://win-bash.sourceforge.net/ I investigated the mksh project at one point and even offered to work on a Windows port. They were not in the least bit interested and already had some commercial company looking to create a port to Windows using there own proprietary code to provide a POSIX compatibility layer. So even if their plan was successful, it wouldn't exactly provide a native Windows port anyone could use in their projects. Tcsh has support for Windows. Zsh was also very popular on Windows. Checking the versions of zsh, the latest Windows version I could find that compiled with no issues using MinGW32 was 3.0.8.1: https://github.com/oldfaber/wzsh The zsh project seems to have progressed to a much later version since then. I've also experimented with Swiss which provides a Busybox-like set of tools with a shell. Speaking of Busybox, there is a port of it to Windows which provides an implementation of the ash shell: https://github.com/rmyorston/busybox-w32 Unfortunately, the build system works in such a way that you need to cross-compile it to get anything to build properly. Even after attempting to cross-compile using the source code, I still ended up with a program that crashes on exit. The busybox-w32 executables at the official sites don't seem to have that problem though. So much for being able to reproduce an executable others are distributing just from the source code.

I have several programs that could replace a lot of the core and basic utilities found on POSIX systems. I even have an older version of make patched to work with a shell of my choice rather than requiring Cygwin or msys DLLs or producing a crippled native version of make that can't handle long command lines. I had discussed the option of getting make to work with other shells besides Cygwin or msys with the developers of make at one point. I had sent them a patch for an issue with using make natively on Windows without a shell. The developers weren't interested in Windows support beyond using Cygwin or msys bash shells. I have older versions of GNU autotools patched to run natively and work around the slash versus backslash file delimiter issues. So, I think I could put together a native POSIX environment for Windows that could be used for development with a command line compiler. However, I'm still left with the decision of how to replace the msys bash shell. It would be very nice to avoid Cygwin and msys and not have the limitations on directories that these programs impose. For instance, they assume / and /usr are in the same locations so /bin is the same directory and in the same physical locaton as /usr/bin. A Windows native POSIX shell option would be ideal. The only question is which shell to go with.

Likely Windows shell candidates at this point are older versions of bash, zsh and ash. It would be nice to find some other options or hear from others interested in native Windows development as to what their POSIX shells of choice might be. If anyone else is interested in developing natively on Windows using a POSIX-like environment, feel free to contact me to discuss the situation further, add your suggestions or brainstorm some new ideas: http://www.distasis.com/connect.htm I'd love to be able to put something together similar to the gnuwin32 or unxutils projects but with more up-to-date utilities. It would be great to have input from others looking to create or piece together their own POSIX development environments on Windows.

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. 23rd, 2025 07:58 pm
Powered by Dreamwidth Studios