Setting up my Homelab for PDAs

Introduction

This article describes how I have set up an environment consisting of several physical and virtual computers and other devices that allows me to interface effectively with old PDAs. When I write “interface with”, I mean an environment where the PDAs can be used in much the same way as when they were essentially new. This includes things like syncing with a computer using the sync software supplied with the PDA, transferring files back and forth between the PDA and the PC, converting word-processing documents from one format to another used by the PDA, transferring information from a PC PIM application such as MS Outlook to the corresponding apps on the PDA, and so forth.

Because this is a long article, I have chosen to make certain sections hidden by default. If you are interested in more information about a particular aspect of the solution, you can click on a link, typically saying “Learn more about …”.

Also, this is a work in progress, as the collection is in no way complete, and new entries may present new challenges to overcome. When I see fit, I will therefore update this article with my new findings.

Overview

As described in other articles in this museum, interfaces have undergone a lot of changes in the 40-odd years that we have lived with PDAs. Many of these interfaces no longer exist on modern computers. Examples include PCMCIA, IrDA and serial interfaces. So the first obstacle is to find a suitable computer that still has those interfaces (meaning it has to be old enough), and/or an adapter that converts an old interface to a newer one. One example is a serial-to-USB converter cable.

The next level of interaction between an old PDA and the computing world we live in today includes using e-mail and, in some cases, browsing the web. This turns out to be more difficult than you might first think, and the reasons and solutions will be described later.

Finding a suitable computer

The first PDA in my collection is from the 1980s and the last one is from 2018. If we disregard the one from 2018 – and you should, because it is an attempt to reinvent the PDA category rather than a device typical of its time – the last ones are from around 2005. So we are looking at a period of no less than 25 years. During this period, the PC marketplace went from DOS on a PC typically equipped with an 80286 16-bit CPU and perhaps a few MB of RAM, to Windows XP on a PC equipped with a Core 2 Duo 64-bit CPU and perhaps 2 GB of RAM. (Windows XP typically ran in 32-bit mode.) Ideally, the computer used to support interactions with the PDAs in my collection should be able to handle all the environments from this period. Impossible? Yes and no.

My initial experiments led to the following insight: I need to find the most modern computer that still supports the important old physical interfaces required by some of the PDAs and that are no longer available on a modern computer. So I looked for a computer with the following interfaces:

  • Infrared (IrDA compatible)
  • PC Card (PCMCIA compatible)
  • VGA for connection to a CRT
  • USB

Note the absence of serial and parallel interfaces from the requirements list. This is because adapters are available that convert between USB and those interfaces, so this is not a problem. It turns out that the last computers marketed with the required interfaces are from the 2008–2009 era. I first found a Toshiba Satellite Pro A60 with a Celeron CPU and 750 MB of RAM, and although it had the necessary interfaces, it turned out to be quite a slow machine to work with. It didn’t help that the sound circuitry was half broken either. So I started looking for a replacement and found an HP Compaq 6910p with a Core 2 Duo CPU and 2 GB of RAM. This makes it quick enough to work with (after replacing the spinning hard drive with an SSD), and it can still run Windows XP. Windows XP is an appropriate operating system for the later models in the collection. However, it is not appropriate for the earlier models, so how I dealt with those is next.

But what about older PDA synchronisation software that requires Windows 9x, Windows 3.11 or DOS?

Some of the older PDAs have software that does not run at all under Windows XP. Also, in one particular case – the Timex Datalink watch-PDA – a VGA CRT-type display is required. This means that the HP Compaq 6910p with Windows XP has to be complemented by something even older. Or does it? Well, as it turns out, there are two solutions to this problem:

1. Find a suitable computer that can run Windows 98 (and hence also DOS, if required), or

2. Install Windows 98 in a virtual machine on the computer that runs Windows XP, and run it in something like VMware Player.

I first tried the second alternative, and it works. However, there are some specific challenges involved with this setup that made me look for a second computer running Windows 98 natively. I found an HP OmniBook xe4100 in good shape. It comes with a decent enough CPU (a Mobile Celeron running at 1.2 GHz) and 512 MB of RAM, more than enough for Windows 98. It also has a PCMCIA slot, a serial port and a VGA connector for the Compaq CRT 7500 monitor I acquired earlier. So I decided that this would be the PC for the older PDAs. But if you are interested in finding out more about alternative #2 – running Windows 98 in a VM – just click below:

Learn more about Emulating older operating systems

As some of the sync software and PC software used in conjunction with the older PDAs requires something older than Windows XP, my first attempt was to find a way around this. So I took the path of emulating older operating systems on the Windows XP machine. Finding software that can create virtual machines while still running on Windows XP was not self-evident, but it turns out that it is still possible to download and run a copy of VMware Player (version 3.x) that runs on Windows XP and allows you to create VMs for Windows 98 Second Edition and Windows for Workgroups 3.11. Windows 98 turned out to be far easier to emulate than Windows for Workgroups. Below are the details for each of them.

Creating a VM for Windows 98 Second Edition

In order to create a virtual machine that runs Windows 98 Second Edition on a host computer running Windows XP, you first need to locate a download site for VMware Player. Although other virtualisation platforms may work, I have had the best results with VMware Player. Select a version old enough to run under Windows XP, which is a 32-bit operating system. Then locate a Windows 98SE OEM installation CD image, or create one from a physical installation disc. As Microsoft still holds all rights to all versions of Windows, neither I nor an AI will tell you exactly where to find a copy, but it is not difficult, and I sincerely doubt that Microsoft would have any issues with Windows 98 being used in this way. Once you have installed VMware Player, create a new VM, select Windows as the operating system and Windows 98 as the sub-choice, if available.

I have used the following settings, which work well for me:

Guest OS: Windows 98 Second Edition

  • RAM: 256 MB
  • Hard disk: 4 GB (IDE)
  • CD Drive: Enabled. Initially point it at an ISO file containing the Win98SE installation CD
  • Network Adapter: Bridged
  • Sound Card: Enabled (auto-detect)
  • Display: Standard VGA
  • USB Controller: Enabled
  • Shared Folder: “Shared” (points to Desktop\Shared on the XP host)

Point the CD-ROM drive to the ISO file containing the installation disc image. Also give the VM whatever amount of disk space you think is appropriate. 4 GB should be enough for most purposes. Click Play this virtual machine to start the installation process. You then go through exactly the same installation process as if you were installing Windows 98 on a physical computer. When the installation finishes, you should have a Windows 98 virtual machine that works, in most respects, like a real computer. Whenever you need to install a program in the Windows 98 VM, you have two options:

  1. If the software was distributed on floppy disks, find the .img files (or use an application to create those image files from the real floppies and point the floppy-drive setting in VMware Player to the first image file. After running the VM again, you will find the installation disk mounted as drive A:. Proceed as if you had the real floppy inserted in the floppy drive of a real computer. When the installation program tells you to switch to the next floppy, use the VMware menu to mount image number two, and so on.
  2. If the software was distributed on a CD-ROM, find the .iso file that contains the whole CD-ROM, or create an ISO file yourself from the original installation disc. Point the CD drive in VMware Player to the .iso file and you will find your CD-ROM mounted as drive D: (typically). Proceed as if you had a real computer with a real CD-ROM drive.
Sound

VMware Player emulates an Ensoniq AudioPCI (ES1371). In order for Windows 98 to use it, it has to be installed using the “Add New Hardware” option in Control Panel. It works with the standard settings of 220/IRQ 5/DMA 1/5.

Creating a VM for DOS 6.22 and Windows for Workgroups 3.11

Creating a VM for DOS 6.22 and Windows for Workgroups 3.11 is in some ways similar to creating the VM for Windows 98, but it involves a lot more steps. In the days when DOS and Windows 3.1 ruled the world, there was no such thing as plug-and-play. Instead, you, the user, had to know which I/O addresses, DMA channels and interrupt levels a particular card was using (and often set jumpers on the actual hardware cards yourself), and make sure that no two cards were using the same resources. If they did, the computer would not start.

Network stack

In the days of DOS, TCP/IP was not necessarily the default way of networking. In fact, IPX and NetBEUI were more common. In principle, you first need to tell the computer what kind of network card you have, then install the appropriate drivers, then install the TCP/IP protocols, and finally configure them. I will not go into the details here; there are plenty of guides on the Internet.

Browser

Once you have installed DOS and got networking going, you can install Windows for Workgroups on top of DOS. Finding a working browser for this old operating system is not easy, but old versions of Opera or Netscape may work if you configure them to use a proxy as described elsewhere in this article.

Exchanging files with the host

Windows for Workgroups and Windows XP can use the SMB protocol to exchange files (aka ”Windows filesharing”. However, they understand the old SMB version 1 only, and all modern operating systems use SMB version 3 and have disabled version 1 by default because it is inherently insecure. This leaves you with two options:

  1. Option 1: You connect your old machines in an isolated environment and tightly control access to the Internet using router and firewall rules between the “retro-LAN” and your normal office LAN. You then can install a Samba server that accepts SMB version 1 clients. Read more on network separation below.
  2. Option 2: Avoid SMB altogether and install a piece of software called “Copyparty” instead. Despite its odd name, it is a file server with a web interface that can be used with almost any web browser, even very old ones, so it works as a bridge between newer and older equipment.

Network infrastructure

Because both your old computers and your old PDAs are vulnerable to threats on the Internet, you should not connect any of them directly to the Internet. Moreover, you should not connect them directly to your normal LAN, as they may pose a security threat to the modern computers and other equipment on your LAN.

So does this mean that you should not connect them to a network at all? Not necessarily. As long as it is a separate network, with very specific rules governing what traffic is allowed to pass from the old environment to the new environment and in the opposite direction, you can allow your old computers and PDAs to be networked.

This is how I have solved it:

  1. I bought an old Netgear WiFi router that allows old WiFi clients to connect using either no security at all or WEP security. Many old PDAs do not understand newer WiFi security protocols such as WPA and WPA2.
  2. I connected that router to a second Ethernet port on my main server computer.
  3. I spun up a new VM called “retro-proxy” and gave it exclusive access to that Ethernet interface through PCI passthrough. I also gave it access to the first Ethernet interface, which is connected to the normal LAN.
  4. I assigned the new Ethernet interface an address on a different network from my normal LAN.
  5. I defined routing and firewall rules in that VM controlling what traffic could and should pass between the two network segments.
  6. I also installed proxy software there (more on that later).

The end result is that old clients can connect using native protocols but pose no threats to other LAN devices, and themselves are not subjected to threats on the Internet.

Getting online

Some of the PDAs in my collection support some form of communication with a service provided by something other than the PC they connect to. Typically this would involve sending e-mail messages and, in the very latest PDAs, using early versions of web browsers. So just connect them to the Internet and all is fine, yes? No, not at all! As it turns out, there are a number of problems that have to be solved first:

  1. Connectivity: What kind of connectivity does the PDA provide? Only the very latest models provided Wi-Fi out of the box, and if they did, it would not be compatible with the modern WPA security protocols typically enabled by default on modern Wi-Fi routers. Some of the later models provided Bluetooth. OK, but what will act as the go-between between the PDA and the Internet connection? What about infrared (IrDA)? If you have a phone with IrDA connectivity that can provide a dial-up connection, you are fine. Most people don’t nowadays, so the PC has to be the go-between in this case, and this requires a bit of tinkering. Serial connection only? Sure, you can set up a SLIP/PPP server that routes IP packets over a serial line. More on that later. Or perhaps you need to dial up a service provider using a built-in modem? Good luck finding one! You will have to be your own service provider, and details are provided below.
  2. E-mail protocols: Back in the day, SMTP was used to send e-mail and POP3 was typically used to receive it. Usernames and passwords were sent in clear text. Not so nowadays. Protocols have evolved to become more secure, which means that the e-mail software on those old PDAs will typically not be able to connect to and exchange e-mail with current servers. So you will have to install your own, less secure servers.
  3. Web browsing: Some of the old PDAs had first-generation web browsers supporting the HTTP protocol. Not HTTPS, which all modern websites use. So in order to “get online” with these PDAs, you will have to use some sort of proxy that translates modern web pages into something the old PDA can digest.

But there is an even more fundamental problem to take into consideration here. If you expose old devices – be they PDAs or old computers with operating systems that are no longer supported or updated, such as Windows XP – directly to the Internet, it may not be long before they are infected by viruses, ransomware or other malware. So the only sensible solution is not to expose them directly to the Internet. Instead, I have created a separate subnet on my LAN where all the old, insecure devices are connected. They can communicate with each other, but not with the outside world, with a few exceptions. These are:

  • They have access to a few proxies that act as go-betweens between the insecure devices and the Internet, shielding the devices from potential malware infections. These proxies talk to the insecure clients on the insecure subnet and connect to the router on the secure side of the LAN.
  • They have access to a file server (Copyparty), which is also exposed to the normal LAN so that files can be exchanged between the safe and insecure sides of the LAN. I recently added a Samba server using version 1 of the protocol, which is understood by DOS, Windows 98 and Windows XP but refused by newer operating systems because it has been proven insecure. To put files there, the newer computers use SSH to connect to the server that also acts as the Samba server.

PDAs that can use Wi-Fi are set up to connect to an old Netgear router that speaks the protocols that were relevant when these PDAs were new. This includes 802.11b and 802.11g for connectivity and WEP for authentication. The Netgear router then connects to a port on the server that belongs to the insecure subnet. The PCs, and the few PDAs that can actually use Ethernet, also get a port on the Netgear router for this purpose. The server then decides which traffic goes where using routing and firewall rules.

Pretending you are an ISP

In the 1990s, the most common way to connect to the Internet was through a dial-up Internet Service Provider (ISP). The computer or PDA would have a modem, and that modem would be connected to the residential phone line and dial the ISP to get online. This is also how most old PDAs are supposed to connect to the Internet. There are some problems associated with this, of course:

  1. Dial-up ISPs are no longer available, at least not in Sweden where I live.
  2. The copper-wire residential telephone system (sometimes referred to as POTS – Plain Old Telephony System) is also being dismantled, at least in Sweden, and it has been ten years since we last had a residential phone line in our house.

So how do you deal with this? The simple answer is – or perhaps it is not so simple – that you must become your own ISP. But how? You are not a telecoms company and you don’t own any copper infrastructure. Well, it turns out that quite a few people still use ordinary telephones but connect them to a device that converts their analogue signals into digital data, which can then be sent over the Internet to call other phones. This is accomplished using a protocol called SIP (Session Initiation Protocol), and requires a service provider that connects the caller to the recipient, regardless of whether the recipient uses POTS or SIP. There are still SIP service providers available, even in Sweden, but fortunately we do not need one, as we are only going to “call ourselves”.

So, to make this happen, we first need a device that takes the analogue signals from the modem in the PDA and converts them into digital signalling that we can send over our LAN. This type of device is called a PAP2T or VoIP gateway, and a common brand used in this context is Linksys. Linksys no longer exists as a company in its own right, but its devices are still available from other suppliers.

At the other end of the line, another PAP2T device converts the signal back to analogue and feeds it into a modem connected to the server containing the software needed to handle the calls and provide a serial-to-IP (SLIP) connection.

Learn more about the homemade ISP solution

So, to make the system work in your home, you should ideally have two PAP2T devices. You connect the modem of your PDA to one of the RJ11 phone jacks on the first one. On the second one, you connect the modem that is attached to the server running the SLIP/PPP software. You also need to install switchboard software such as Asterisk so that the PDA modem can dial a number to reach the server modem. For the fun of it, you can connect telephones to the free RJ11 jacks on the PAP2T boxes and use them to make local phone calls!

I used Docker and Docker Compose to install Asterisk, with the help of ChatGPT to configure it. It needs three configuration files: sip.conf, extensions.conf and modules.conf. You also need to configure the PAP2T boxes so that they know how to reach the Asterisk service. Send me a message if you want to do this yourself, and I can send you the configuration settings.

Setting up your own e-mail services

As the old e-mail clients included with the PDAs are not capable of communicating with modern e-mail servers, we have to provide our own e-mail service. Because e-mail could potentially be used to spam real users on real computers connected to the Internet (like me and you), I have chosen not to expose the e-mail service to the Internet. E-mails can therefore only be sent and received by PDAs and computers on the local network.

Two types of server are needed here. One is for sending e-mail between servers and clients. This type of server uses the Simple Mail Transfer Protocol (SMTP). The other is the server that collects your e-mail and makes it available for download. In the old days, this service typically used Post Office Protocol version 3 (POP3). In order to provide a complete e-mail service for the PDAs, both types of server have to be installed. To make things as simple as possible, I chose a Docker container called “docker-mailserver” that provides both types of service in a single container. To make it work, I had to turn off all security features.

Surfing the web: The use of web proxies

Some of the old PDAs came with a web-browser that allowed its user to surf the web once connected to the Internet. Well that was then, and now is now. The modern world-wide-web has evolved in many ways since then: First, most sites uses the secure https-protocol to transport pages from the server to the client, and most PDAs don’t understand this protocol. Second, most modern web-pages use a combination of html, css and javascript and most old web-browsers only understand (a subset of) html. So, to overcome this problem we need a piece of software that acts as a translator between the new world and the old world. We need a proxy.

There are basically two types of web proxy used in this scenario. One type is set up as a proper proxy and is then configured in the web browser that needs Internet access. This is the normal way to do things, and it works well if the web browser inherently understands the modern protocols used on today’s web.

The other type is, in fact, a browser in itself. It presents a search/URL field that can be used by the browser on the PDA (or old PC). The user enters a search term or web address, and the proxy retrieves the content from the website and then translates it into a form the old browser can understand. So it is a specially packaged version of an ordinary web browser such as Chrome or Firefox, with the added ability to translate the content into a less sophisticated format. There is a variation on this theme: FrogFind, which essentially removes more or less all formatting from pages before presenting them to the old browser. This works best on sites that do not rely too heavily on formatting, but for really old browsers it may be the only practical way to get online.

In my homelab, I have installed both types of proxies and use one of them depending on what the browser in the PDA can handle. The ”normal proxy” is called WebOne and and describes itself as ”WebOne is a web proxy designed to allow older “Web 1.0” clients work in a “Web 2.0” world”. You tell the old browser to use if for at least the http and https protocols and that they should use port 8080 for this proxy.

The other type of proxy that basically is a modern web-browser acting on behalf of the old browser is called Browservice. I have also installed a local copy of the Frogfind web-service, as the one available online can easily get overloaded. To use these, you simply browse to their web-page and fill in the site that you actually want to look at.