Nick M Cummins

X410 – run WSL gui applications as native Windows applications

Software developers who work on Windows have likely heard of WSL, which stands for the Windows Subsystem for Windows. Essentially, it is a way to run Linux distributions within Windows somewhat like running a virtual machine (VM) but more seamless – or akin to running a Docker container. WSL provides support for GUI applications out-of-the-box with WSLg. The important thing to note about WSLg is that it is implemented using the RDP protocol, so GUI applications are essentially run via an RDP process running on the host Windows machine. Due to this implementation, the performance of GUI applications running on WSLg will not perform as well as would a native Windows application or compared to running the application on a regular Linux installation.

There are some really cool uses of WSL even outside of software development that may be useful for users who are somewhat technical. Some of these are from the interoperability provided with WSL:

  • Windows drive C:\ is mounted in WSL at /mnt/c
  • WSL filesystems can be accessed at \\wsl.localhost and can be mounted to network drives (for example I have \\wsl.localhost\Arch mounted as L:\)

Windows provides the ability to mount network drives using FTP or SMB – however, it doesn’t provide support natively for mounting network locations using SSH/SFTP. Linux has a FUSE filesystem called sshfs. With WSL, this means network locations can be mounted and accessed from Windows. Similarly, Windows does not natively support mounting external drives containing ext4 formatted partitions.

X410 is a really cool alternative to WSLg, which allows X-Window GUI apps to run like any other Windows application. Note that X410 does require the purchase of a license. The license I purchased is for perpetual for the version when I purchased, though updating to newer versions of X410 will require an additional purchase. Here is an example of Caja running in X410: Caja File Manager in X410

Notice how the Window appears like a normal Windows application would. For comparison, here is what Caja looks like in WSLg: Caja File Manager in WSLg

While it may not look like much of a difference, the advantage of X410 is not about the appearance but performance. The UI responsiveness running X410 is noticeably better than running in WSLg.

GCC / make – pcdPointXYZRGB2txt.cpp:12:24: error: ‘split’ is not a member of ‘boost’

If make fails due to

[ 13%] Building CXX object CMakeFiles/treeseg.dir/src/treeseg.cpp.o
./treeseg/src/pcdPointXYZRGB2txt.cpp: In function ‘int main(int, char**)’:
./treeseg/src/pcdPointXYZRGB2txt.cpp:12:24: error: ‘split’ is not a member of ‘boost’
   12 |                 boost::split(tmp1,args[i],boost::is_any_of("/"));
      |                        ^~~~~
./treeseg/src/pcdPointXYZRGB2txt.cpp:13:24: error: ‘split’ is not a member of ‘boost’
   13 |                 boost::split(tmp2,tmp1[tmp1.size()-1],boost::is_any_of("."));
      |                        ^~~~~
make[2]: *** [CMakeFiles/pcdPointXYZRGB2txt.dir/build.make:79: CMakeFiles/pcdPointXYZRGB2txt.dir/src/pcdPointXYZRGB2txt.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:578: CMakeFiles/pcdPointXYZRGB2txt.dir/all] Error 2

This can be resolved by including the required header (source: boost::split in C++ library | GreeksForGeeks):

#include <boost/algorithm/string.hpp>

archlinux-pkgbuilds – Arch Linux PKGBUILDs

I maintain a set of PKGBUILDs for the Arch Linux distro in a public GitHub repository: archlinux-pkgbuilds. Many of these are modified versions from the official Arch package repositories or from AUR packages, however some are not found in either. The modifications for existing packages are usually small fixes for issues building with the existing version or to build configured with different CMake variables.

Many of the packages are GIS applications, including

Some of the PKGBUILDs have not been built in several years. I will periodically update this list with recently built packages that are not available in the official repos or AUR.