The client is a DLOG MPC5 industry PC which is past its prime. The hardware is from 2004, the software running on it was written in 1997 and the operating system MS-DOS 6.22 was released in 1994. There are no spare parts for the old hardware and no drivers to run the OS on newer hardware.
| Current hardware | |
|---|---|
| Display | 10.4-inch color TFT, SVGA 800 x 600 pixels |
| Mouse | Resistive analog touch screen |
| Memory | Compact Flash |
| Ports | RS232, USB |
| Network | Cisco WLAN card |
How can the client application, part of a client server software architecture, be operated on modern hardware without being changed?
| Current software | |
|---|---|
| Operating system | MS-DOS 6.22 |
| User interface | Graphical user interface that is designed for a resolution of 640 x 480 (extrapolated by the current hardware to 800 x 600) |
| Network | TCP/IP network connection with PC/TCP protocol stack (most of the network communication consists of file transfers via FTP) |
The project
The old hardware is replaced by an IND FTF2475A industry PC. As the operating system for this platform IND offers Windows Embedded Standard 7 (WES7) and Debian Linux (Version 7 “Wheezy”) in a special “hardened” version from IND Systems.
There are several conceivable solutions for emulating DOS: DOSBOX, VirtualBox, VMware, DOSEMU. The option of running the application in Windows compatibility mode is eliminated due to the lack of network support for DOS applications.
We choose the combination of DOSEMU and Linux because both the emulator as well as the operating system are completely open source. This makes it at least theoretically possible for us to solve any upcoming problems on our own. Also DOSEMU looks promising for the allegedly most difficult part, the network connection.
DOSEMU is a really old open source project. It was founded all the way back in 1992. It has been worked on for over 16 years with the last version 1.4.0.1 being released by the Debian project in 2008. So there is obviously no active developing community left to potentially help out.
The project starts with a proof of concept. The application running in a DOSEMU box should be able to address the display, the keyboard, the mouse, the touch screen and the network. We want to determine whether there seem to be any insurmountable difficulties as soon as possible, because there is neither documentation for the application or nor is it known if it conforms to official and therefore emulated APIs. So we have to test through the following list:
- Do the VGA graphics display correctly?
- Can the touch screen be properly operated? (connected with RS232 on the FTF2475A, used PS/2 on MPC5)
- How do we need to configure the network stack, so that the application server can not (and need not) distinguish between an old and a new client?
- Which mode of DOSEMU is best suited? Console Graphics Mode with direct VGA hardware access, SDL mode using frame buffer console devices or X11 mode so that the X11 server controls the hardware?
Testing DOSEMU “from stock” shows that there are no problems with keyboard and mouse.
The VGA graphics of the application are displayed correctly. Though while running in Console Graphics Mode the whole system crashes when the DOSEMU session is terminated with exitemu command.
The touch screen is problematic as well. Luckily the issue doesn’t require us to emulate the MPC5 touch that is connected via PS/2 port. But the Elo touch screen of the FTF2475A needs to be connected to DOSEMU. The native mouse support in DOSEMU is sufficient if the connected device generates relative movement. However a touch screen produces absolute cursor movement. This type of pointer device cannot be configured in DOSEMU even though there is existing code for it in the sources.
This issue eliminates the Console Graphics Mode as well as the SDL mode. Only the X11 graphics system offers native support for the Elo touch screen.
After configuring DOSEMU as an X11 client everything finally runs but only in windowed mode. We need full screen for compatibility with the old MPC5 though. In full screen the input from the touch screen is defective. Tapping the display moves the cursor to a random point instead of the point we tapped at.
Fortunately there is an easy solution for this problem. We need to combine the full screen mode in X with the mouse grab mode. Interestingly there is no configuration option for this but only a hotkey, see http://www.dosemu.org/docs/README/1.4/t1.html#AEN14. So we will integrate a hotkey action in the X_init() function:
--- old/dosemu/src/plugin/X/X.c
+++ new/dosemu/src/plugin/X/X.c
@@ -740,6 +740,8 @@ int X_init()
if(getenv("DOSEMU_HIDE_WINDOW") == NULL) {
if (config.X_fullscreen) {
toggle_fullscreen_mode(1);
+ force_grab = 0;
+ toggle_mouse_grab();
have_focus = TRUE;
} else {
XMapWindow(display, main window);
At last the network connection:
The DOS application uses the TCP sockets in the form of the PC/TCP protocol stack, a product of the company “FTP Software”. On the lowest layer of the protocol stack is the packet driver. This driver provides the interface to the network adapter (WLAN). In the old system this is the driver cscpkt.com from Cisco. It can be replaced by a generic packet driver which is part of the DOSEMU software and just needs to be activated in a configuration file. We also need to state which network adapter should be used by the driver in this config file. The available network adapter are “wlan0”, the physical adapter, and “tap0”, a virtual adapter. We select “tap0” so that the DOS application communicates with an emulated Ethernet device. Linux forwards data from the virtual network device to the physical network device (the WLAN adapter) via IP routing. This way the DOS box and its Linux host creates its own IP subnet and is hidden from the outside with IP masquerading (NAT). The DOSEMU manual contains an elaborate explanation in the chapter Networking using DOSEMU
There is just one little catch: This doesn’t work. The DOS box doesn’t establish any IP connections.
Some research shows: This problem was discussed back in 2008 by the mailing list Linux-MSDOS in the topic Running PC/TCP inside DosEmu. Luckily for us Mauro Flores from Uruguay found a solution. He submitted this patch:
--- old/dosemu/src/dosext/net/net/pktnew.c
+++ new/dosemu/src/dosext/net/net/pktnew.c
@@ -709,6 +709,11 @@ static int pkt_receive(void)
*--p = (char)(ETH_P_IPX >> 8);
}
#endif
+ if( size < ETH_ZLEN ) {
+ pd_printf("Fixing packet padding. Actual length: %d\n", size);
+ memset( pkt_buf+size, '0', ETH_ZLEN-size );
+ size = ETH_ZLEN;
+ }
p_stats->packets_in++;
p_stats->bytes_in += size;
Unfortunately this patch wasn’t adopted by either the main trunk or the Debian or Ubuntu distributions. Without this patch ARP doesn’t work and without ARP IPv4 networks are of little use.
The technical basics are now established: Linux, X11, XDOSEMU, TAP.
Putting the virtualized DOS box behind a NAT gateway creates a problem though: The DOS application uses active FTP. This means that the FTP client establishes communication with the FTP host by sending its own IP address and port number so that the FTP host opens up a data channel with these parameters. With the DOS box in its own IP subnet this won’t work.
The solution to this issue is to change the active FTP in the DOS box to passive FTP. The freely available Linux software package ftp-proxy does exactly this.
Now the prototype can start with this configuration:
Declaration of the TAP device
tunctl ifconfig tap0 $VMIP netmask 255.255.255.0 up
Declaration of the FTP proxy device
echo "ftpproxy $FTPPROXYPORT/tcp" >> /etc/services
Configuration of the FTP proxy (transforming from active to passive FTP)
cat > /etc/proxy-suite/ftp-proxy.conf <<! [-Global-] ServerType inetd LogDestination daemon AllowTransProxy yes AllowMagicUser yes UseMagicChar % PortResetsPasv yes DestinationTransferMode passive !
Declaration of the FTP proxy to the inetd super server
update_inetd --group STANDARD --add 'ftpproxy stream tcp no wait root /usr/sbin/ftp-proxy'
Creating the NAT rules and rerouting the data traffic to the FTP proxy
sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward" iptables -t nat -A PREROUTING -i tap0 -p tcp ! -d $VMIP --dport 21 -j REDIRECT --to-ports $FTPPROXYPORT iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
Starting the application
dosemu.bin -X
In production we discover some additional positive side effects of the conversion:
- The DOS box can be part of a WPA2 protected wireless network even though it doesn’t understand this encryption technique.
- The Linux version from IND Systems runs the application in a RAM disc and adds a write protection to the flash disc. This protects the file system from damage. The DOS application profits from this as it makes the application more robust.
- Thanks to virtualization and integration into a modern operating system, remote maintenance, SNMP and mobile device management are now possible.
Running freedos under DOSEMU under Linux inside Virtual Box. Linux has full internet access. I want to run DOS BBS, Doors, and terminal dial-up programs under DOSEMU. Dosbox already does something like this. Dosbox gives us a “virtual modem” and BBS, Doors, and terminal dial-up programs see a modem and can “dial” IP addresses. if you are not familiar with this, give it a try!
The problem with DOSBOX is that it loads the mounted disks into memory and does not write back to it until it is shut down. This creates several issues where multi node BBS, Doors,es are concerned. For starters, share.exe won’t work and so, if two nodes are accessing the drive at the same time, data will get corrupted. If you run only a single node BBS and power goes off, all your data is lost. if you are running Telix or Telemate and you download a QWK packet or a file, it doesn’t get saved to the hard drive. The creator of DOSBOX states that because he made this to only play DOS games and nothing else, he is not going to start changing it to be safe to run other applications. caching the drive makes sense when playing a single player DOS game, but not when running a multi node BBS or, God forbid, a multi-user legacy database system.
What we need in DOSEMU is the ability to have a “virtual modem” that lets BBS, Doors, and terminal dial-up software see a modem and then dial out and receive calls in using IP addresses. I am reading the documentation for the DOSEMU.conf Serial Port settings. It says:
“virtual” keyword may be used to redirect the COM port to the terminal. A wrong but quick way for the sysop to play his BBS door games locally.
This is not what we need. We need to be able to have BBS, Doors, and terminal dial-up programs use the virtual comports to send and receive modem data while the virtual modem does its magic and sends and receives that data over TCP. DOSBOX can do it, DOSEMU should too.