DESQview/X was a product of a now-defunct software company called Quarterdeck. Quarterdeck was bought by Symantec, which no longer supports this product. For many people, DESQview/X is simply an X11R5 X-server. It turns any DOS-based 386-or-above PC into an X-terminal. It's more than just an X-terminal, however. As I see it, the most important additional features of DESQview/X are:
The same approach can be used to load a packet driver for Windows 3.1 when run from DESQview/X in "direct" mode.
Create a new file C:\DVX\NETWORK\NETPTM.BAT. It should load your network drivers, and then execute NETPTM.EXE. Mine looks like this.
Now you can remove the commands that load LSL.COM, 3C509.COM, and TCPIP.EXE from your AUTOEXEC.BAT file (and rerun OPTIMIZE). These drivers will no longer occupy any conventional or upper memory in DOS windows that you open inside of DV/X.
To use the port, you would type the following:
C:\> set DISPLAY=10.10.10.1:0
C:\> ssh -v email@example.com xterm
In the first line, 10.10.10.1 is the IP address of the local host (the machine running DESQview/X). The DISPLAY environment must be set if you want to enter your passphrase without having it appear in the DOS window, and also if you wish to have the program running on the remote host display any X-windows on the local host.
In the second line both the user name, "bmm", and the command that is to be run on the remote host, "xterm", are required. (-v indicates verbose diagnostic output.) Username is required because the notion of who the current user on a DESQview/X machine is a bit fuzzy to me. The command is required because this port of ssh does not provide TTY emulation. (The reason being that djgpp version 1.12 doesn't have a TTY library.) But running xterm will do what you want it to do: run an xterm on the remote machine, but have it display on the local host. From this xterm you can then launch other programs on the remote machine, and also have them display on the local host.
Not only does ssh make a connection to the remote host without sending your password in the clear, it also cryptographically encodes all of the data that is sent back and forth between the two machines during the session. Furthermore, it automatically "tunnels" X traffic through the connection in a secure fashion.
For all of this to work, you'll need to have sshd running on the remote host. This is pretty standard these days on Unix systems.
A few other remarks: the port assumes that the files containing the list of known hosts, the random seed, etc., are stored in /dot.ssh/ on whatever disk you run ssh from, and will create this directory if it doesn't exist. It also looks for some things in /etc/. It doesn't have to find any files to run successfully, though.
I've noticed that DESQview/X behaves badly when you attempt to open more sockets than the network manager allows. I bumped into the limit because ssh will open two sockets to the local X server for each X window that is displayed on the local host. So don't try to open too many. But I'm able to get three xterms, an xemacs, an ical, and an xbiff (running on two hosts) simultaneously.