> LoWe creates the missing device files (as regular files) under /dev to let them to be opened by the program and have a file descriptor. Later on it intercepts Linux kernel system calls (syscalls) in user mode via ptrace (like strace). When LoWe thinks that she is responsible to handle given syscalls (ioctl, read, write, mmap, etc.) of particular devices identified by file descriptors then it provides her own responses to the syscalls instead of going down to the Windows kernel that has no support for those functions.
Question for the author: in terms of running X apps, what's the advantage of this over using a third-party x server, like VcXSrv?
Using VcXSrv and just two tweaks (setting DISPLAY to :0 and setting dbus to not use UNIX sockets), I've gotten gnome-terminal, gvim, and Plank dock working perfectly. Firefox, Nautilus file explorer, and various Gnome programs seem to work fine too.
Most probably to employ a third-party X server is more robust at the moment.
However in this case we can achieve the same effect with the Ubuntu bits of the X server. It's true that here we require other tweaks but this is a bigger step towards letting Ubuntu on Windows on its own to run X apps.
LoWe provides a generic approach and idea that can be applied in a specific way to other functionalities. Eg. it's possible to play music (PCM) by "emulating" some ALSA devices.
Originally there was no actual need, I was just curious about the technology, the limits and I wanted to push these limitations.
But:
Later I realized that there is a need for this. With apt, it's much easier to install and update (GUI) apps than with the Windows installer, so the need has grown from nothing to a real-world requirement.
Moreover it happened several times that I was looking for some software and there were many alternatives for Linux but nothing valuable for Windows. LoWe will help in these situations, as well.
Simple and neat idea.