WSL and X Windows programs

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.

Native POSIX enviroment for Windows

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.