This is about as weird as it sounds. While many disregard WSLv1 as being borderline useless, it can still quickly bridge the gap when you need something in user-space, and quickly. And for those of us on Windows 10 (I could upgrade this machine, but I haven’t bothered as I don’t have a real GPU for it), there is no real UI. But how to solve this?

Well, the first thing is xrdp. Xrdp is an RDP server that will allow any halfway good Unix machine become a terminal server, very ‘Citrix like’. Combine that with the Xorg virtual frame buffer, and now you have a display surface that is basically exported over RDP. I did modify it to listen on a different port so I could retain RDP to Windows 10 by modifying xrdp.ini:

port=4389
port=ask4389

Now the real fun comes from CDE.

I built 2.5.1 from source, following the guide, with 2 important notes: Make sure you install and activate the UTF!!!. The other thing that was trashing my build was that WSLv1 picks up the Windows path, and it has spaces in it, which confuse the build process. Be sure to export something like:

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

before beginning the process.

With all the bits in place, the next issue is the RPC. I couldn’t figure out how to start the ‘safe mode’ version, so it will absolutely need RPC. But it turns out that you just have to start the rpcbind manually, since WSLv1 doesn’t have a real ‘startup’. I also saw a lot of errors trying to talk to dbus, so may as well start that up as well.

mkdir -p /run/sendsigs.omit.d/
/usr/sbin/xrdp
/usr/sbin/xrdp-sesman
/usr/sbin/rpcbind
/usr/bin/dbus-daemon --system

And finally link the Xsession to the default user .xsession so CDE will be the default environment.

ln -s /usr/dt/bin/Xsession $HOME/.xsession

Now you should have everything in place, to login and get the Xrdp login

And with any luck, you’ll be greeted with CDE!

And there we go! Neat!

Finally someone made a distribution with CDE as default eyecandy. I’m happy.

Enter CDEbian!

For the 2 or 3 people in the world still running MS-DOS.

Desqview/X

I never used Desqview back in the day, as I didn’t have a good enough computer. A 286 with 1mb of ram just wasn’t enough to push the thing. And by the time I did get a 386, OS/2 2.1 was all the rage. But in that time between OS/2 2.x and the release of the 80386 CPU there was all kinds of programs to take advantage of the 386’s v86 mode.

Desqview X really is different in that it not only incorporates the desqview multitasking, but it also supports the X11 protocol found in the UNIX world. Sounds cool right? A friend wanted to run it, so he actually dug out a web page, chsoft.com with all the bits.

The first stumbling block is that Desqview requires that you use the memory manager QUEMM, which the majority of emulators we tried couldn’t work with it. Qemu 0.14.0 however proved itself up to the task, as long as you didn’t let it do the aggressive optimization, just let it install, and reboot.

Installing DesqviewX was pretty straightforward, the only catch was the video. VGA doesn’t work but the SVGA modes work fine. I just used the 800x600x256 mode.

With that out of the road, the next thing needed was a good mouse driver. For some reason the majority of the mouse drivers I tried just wouldn’t work with desqview, until I tried ctmouse.

Naturally for the whole X11 experence you need networking. The tcpip package on the desqview webpage uses some old netware thing with a ne2000 driver that is hard coded to 0x300 irq 4. Which won’t work in any machine I know since everyone has at least one com port. So I had to take the lsl & ne2000 parts from my Netware 3.12 client. But doing so revealed that the lsl wouldn’t run because of a lsl buffer pool error. And of course to work with slirp you need to be running ethernet_II instead of 802.3 …

So you’ll need a net.cfg like this:

link support
buffers 4 1504
mempool 8096
max stacks 4
link driver ne2000
port 300
irq 3
frame ethernet_ii

Naturally you’ll need to change the source to Qemu if you have your own build to use IRQ 3 instead of 9 (it’s in hw/pc.c), or use one of my binaries. It’ll configure via bootp and at the end you should be able to ping 10.0.2.2

Putting it all together, running it like this:

./qemu -L pc-bios -hda packet2.qcow -net nic,model=ne2k_isa -net user -redir tcp:6001::6000

On OS X has qemu listen on 6001 for X11 sessions, then redirect them into the VM on it’s X11 port. So I could then easily run xeyes like this:

xeyes -display 127.0.0.1:1

And the output appears inside of Desqview X. Likewise, removing the session security, and allowing remote connections in OS X’s X11 widget, then allowed me to send xeyes from Desqview to my mac like this:

xeyes.exe -display 10.0.2.2:0

And exeyes pops up on OS X as running from the Desqview VM.

I don’t know if it’s terribly useful, but I thought someone may get a kick that Desqview X can run on Qemu 0.14.0 In this day & age though you can get easier versions of X11….

So my hope would now lay in making up a configuration file that’ll satisfy the Xfree86 1.2 server, and build enough of X11R5 to where it’s able to do something….

I have no idea if it’s even that easy to do, but if anyone has any leads on a source copy of xfree86-1.2 or 1.3 that’d probably be easier to build for 386BSD as it was used in the time frame… 2.0 was for the forks of NetBSD & FreeBSD so no doubt it’d hinge on things like DLL’s…

In the meantime, you can check out Neils Horn’s blog, with an example of what Xfree86 1.x was capable of on 0.96 linux.. Back in the day.