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.
I've been reading a lot about WSL. It's a great way to run Linux in Windows without needing a virtual machine like VirtualBox or Qemu installed. However, the earlier versions of WSL only ran command line or console based programs. If you wanted to run X Windows programs, you needed an X server. Well it just so happens, I've built the X server on Windows from source and all the packages for it. I've recently been testing remote access to X Windows programs on an AIX machine at work. From those tests, I found X forwarding using tools like putty and a Windows based X Windows server can be rather slow. My experiments with sixel weren't very satisfactory. The other protocols I investigated were vnc and xrdp. Both offer faster alternatives to X forwarding or other techniques I'd tried.

I did not make a lot of progress with the vnc protocol. I was able to build sdl_vnc from source. I had issues with building libvncserver because they're using cmake which never works properly for me. Was able to find an older version that uses GNU autotools and get that working though. Another interesting project is spiritvnc which uses libvncserver and provides a front end using FLTK.
https://sourceforge.net/projects/sdlvnc/
https://sourceforge.net/projects/libvncserver/
Eventually I was able to build two SDL based vnc clients from source code. Unfortunately, there isn't much in the way of documentation and I really couldn't get theTto do much. If anyone finds any decent documentation regarding vnc and either of those clients, please let me know.

Xrdp looked like a very promising option especially when I read that performance was even better than vnc. There isn't an xrdp package for AIX, but there is one for Debian via WSL. So, I decided to investigate. I found several articles on how to set up xrdp for WSL. That was surprising since so many articles I've been reading discussed how hard it was to access WSL based X Windows applications and the need for Microsoft to add GUI support in WSL 2.

It was also surprisingly easy to get working. I used sudo apt-get install xrdp to install it. I added my window manager of choice, jwm, and a few X Windows based test programs, SciTE and tuxmath. The documentation said to add the xrdp user to the ssl-cert group:
sudo adduser xrdp ssl-cert
Then it said to edit /etc/xrdp/xrdp.ini. I did so with nano. I changed any instances of 3389 to 3390. I commented out max_bpp=32 and added nmax_bpp=128. I added nxserverbpp=128 after #xserverbpp=24 which was already commented out. I started the system using:
sudo /etc/init.d/xrdp start
Then, all I had to do was use the remote desktop connection program on Windows and connect using my WSL username and password. When you connect, use computer name: localhost:3390 Everything came up with no issues. I tried out Xfireworks, SciTE and tuxmath. They ran very efficiently considering they weren't running as native Win32 applications. (I also have Windows versions of all these programs.) I was really pleased with the results. I think this method probably works even better for me than upgrading to the latest WSL and using the Microsoft GUI support (which I have tried on one of my computers). Now if I could just get a solution like this working on our AIX system at work, we'd be all set. It would also be interesting to see how this works with Wayland and rdp support in place of xrdp.

October 2025

S M T W T F S
   1234
567891011
121314151617 18
19202122232425
262728293031 

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Nov. 2nd, 2025 03:14 am
Powered by Dreamwidth Studios