Setup a Linux Development Environment on Windows
We can hack on Doom's source on Windows using Visual Studio, if we run a Linux instance in Windows Subsystem for Linux (WSL 2) on Windows 10 and use Visual Studio's Linux development feature to remotely build the source on that instance. WSL is a compatibility layer for running Linux ELF executables natively on Windows 10. Its second iteration, WSL 2, runs a Linux kernel in a lightweight virtual machine environment.
Prerequisites
We need WSL 2, a Linux distro, and a X Server set up on Windows 10. Then we do the usual things inside the Linux instance to get Doom compiled and running.
- Set up Linux in WSL 2 on Windows 10
- I use a minimal Debian distro as a Linux instance on Windows. To compile Doom in it, you will need to install the following software in that Linux-instance:
- libx11-dev
- libxext-dev
- Install a X Server on Windows: Cygwin/X
Configure the Linux Instance
With the prerequisites out of our way, we set the DISPLAY variable and install the X Server on the Linux instance.
Add the following string to the beginning of your .bashrc file that resides in your home directory, to update the DISPLAY environment variable every time you invoke a shell;
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0
Log out and log back in for this to take effect. On my system
echo $DISPLAY
prints
192.168.128.1:0.0
Then install netcat and use it to check an X Server is available on that IP address;
apt install netcat
nc -v 192.168.128.1 6000
which, on my system, prints
DNS fwd/rev mismatch: robu != robu.localdomain
robu [192.168.128.1] 6000 (x11) open X11
I don't know what the mismatch statement means and it probably doesn't matter at this point; I ignore it. The output confirms an X Server is alive. If one wasn't there the last line would have read
robu [192.168.128.1] 6000 (x11) : Connection timed out
To get a X Server running, we install a full-fledged graphical desktop environment, Xfce
apt install xfce4
Run a X Server on Windows 10
The usual way to start the Cygwin/X X Server is using the tool called XLaunch the comes with Cygwin, but the default options XLaunch launches the X Server with don't work.
So create a new shortcut on Windows desktop
Right-click on Desktop > New > Shortcut
and plug in the following invocation string
C:\cygwin64\bin\run.exe --quote /usr/bin/bash.exe -l -c "cd; exec /usr/bin/startxwin -- -ac -listen tcp -wgl"
and hit the Apply button to save it. Run the shortcut, and wait for a brief moment for the X icon to show up in the system tray. This confirms Cygwin/X is running.
X on Linux Renders to X on Windows 10
The steps to set up Cygwin/X was mentioned in the prerequisites.
To demonstrate that a graphical X application, running in the Linux instance, correctly renders its output to a X window managed by the X Server on Windows, you could run these programs in the Linux shell;
- xlogo
- xeyes
- startxfce4 -- a full-fledged Xfce graphical desktop environment
This immediately renders the output in a new window that shows up on the Windows desktop.
Render Doom's Output
Rendering Doom falls back to the same procedure described in the previous chapter. Do everything described here in the Linux instance running in WSL 2: Compile Doom on Linux.
At the end of it all we run an 8-bit instance of Xephyr in one shell of the Linux instance. Xephyr's window pops up on your Windows desktop. The window is blank to start with. Then, in another Linux shell, we run the Doom executable. Doom's output gets rendered in Xephyr's window.
To summarize, we now have a Linux instance running in a VM (WSL 2) on Windows. An X application running in that instance is rendered inside a window that is visible on the Windows desktop. This window is presented and managed by that X Server running on Windows.
Use Visual Studio to Build Doom on Linux
Now that the entire pipeline is set up, we introduce Visual Studio in the picture, where, we create a project with the Doom source files and compile it on a remote Linux machine. The remote machine can be another physical machine, or a Linux instance running on a virtual machine, like WSL 2. We need the user name, password, the IP address, the port where the SSH server is listening on the remote machine, and the proper build commands to make this happen.
On Visual Studio
Create a new Linux, C++, Makefile project. Initially the project is empty, it has no files. I name the project DOOM and the solution Doomadoom, to keep them distinct. On the file system the path is Doomadoom/DOOM/.
Copy over the contents of the original DOOM directory to Doomadoom/DOOM/, and from inside the Solution Explorer in the IDE, select the DOOM project, right-click on it, go to Add > Existing Item.... Then navigate to the linuxdoom-1.10 directory and select all the files (except the CVS directory.) This will populate the project with Doom's source files.
From the menu items in the top horizontal bar, select Tools > Options > Cross Platform > Connection Manager. This is where you add the information needed to establish a SSH connection to a remote Linux machine. Enter the usual user name, password, IP, port and save it.
Finally go to the project's property page (right-click on the project) and add the following to the Remote Build options
- Build Command Line: make -C linuxdoom-1.10
- Rebuild All Command Line: make clean -C linuxdoom-1.10; make -C linuxdoom-1.10
- Clean Command Line: make clean -C linuxdoom-1.10
This completes the setup. Now if you build the project, Visual Studio will copy the files to the remote machine, in the ~/projects/DOOM directory, compile it there and show you the result of the compilation process. The Doom executable will be on the remote machine.