Resurrecting RealPlayer

Technically RealNetworks and their premier product #RealPlayer still exist in this year of our dragon lord 2026, but in a very different form from their heyday in the late 1990s. Something I was playing with a week or so ago reminded me of it, and I decided bringing it back from the dead would be an interesting project.

I first discovered RealPlayer sometime in 1997 when I found an early version of it included with Windows 95, hidden in the SYSTEM directory. Microsoft shipped it along with Internet Explorer to provide media playback until they replaced it with their own Windows Media Player (which Real later sued them for). Even though this was the dial-up era, streaming audio channels even for just a few minutes at a time seemed fun. The player began to succumb to bloat once it hit version 6 but before that it was a pretty decent experience. I decided that RealPlayer 5, and its associated infrastructure, would be the best target.

Well, actually I wanted to target RealAudio Player 3 but I couldn't find a compatible server so I settled for Basic Server Plus 5. That gave me the option of experimenting with video if I wanted to, so it was a decent second prize. I set up a Windows 2000 VM to run the server on. I'd have preferred WinNT 4.0 but that will not run under the current version of QEMU. I was also able to find the UNIX versions (including Linux and FreeBSD) but I decided to go with Windows for this.

The server was easy enough to get going (although I wasn't able to get it to work as an NT service) so the encoder came next. I wanted to do live streaming rather than static files, and that led to another challenge. The Real encoder is hardcoded to take input from your sound card's mic or line input; it won't stream your desktop audio even if you set that as your recording source in Volume Control. An old version of Virtual Audio Cable let me work around that. The next wrinkle was that the encoder doesn't let you choose an audio input device; it always uses whichever one you have set as your default in Windows. Because of that, it's only possible to run one stream per machine. If you want to offer more channels (or enable bandwidth auto-negotiation) you have to use separate machines.

Audio is fairly easy, the aforementioned caveats aside, but video is a greater challenge. Like audio, the encoder absolutely insists on taking input from a camera or video capture card. I wasn't able to find anything that would run on pre-Win7 versions of Windows that would allow capturing the desktop display through a virtual device so I was stuck putting together a bit of a Rube Goldberg contraption: a laptop running Windows XP feeding VGA output to a TV scan converter, itself feeding into a USB analog capture card connected to the laptop. This, together with Virtual Audio Cable, allowed me to capture the output from VLC and encode it to a live RealVideo stream. Strangely I had problems with RealEncoder 5, but RealEncoder 1.0 (part of the RealServer 4 suite) worked fine.

So, with server and encoders going, attention now shifts to playback. The streaming protocol works a bit like FTP: the client opens a control connection to the server on TCP port 7070, then the server opens a connection to the client on a random UDP port in the 6970-7170 range (or whatever's set in the client preferences). That was fine in the dial-up era, when no one used NAT and hardly anyone used firewalls, but that would not work on the modern Internet. Starting with RealServer 4, Real added a feature they called "Smart Networking" to the server, allowing it to stream content via HTTP on port 80 rather than opening a direct connection to the client. This made it difficult to run a web server on the same machine though; that's why I opted not to run the Real server on my OpenBSD VM.

It was because of this unusual-by-modern-standards protocol that I decided to connect my server to Compu-Global-Hyper-Mega-Net (which I talked about in my previous blog post ) rather than running it directly over the modern 'Net. NAT is generally not used on #CGHMN and very few people run firewalls so the 'callback' connection method works fine, just as it did over dial-up. If you're on CGHMN and you want to give it a try, visit my site at www.n8fq.retro/real.

#RetroComputing #RealAudio

My Compu-Global-Hyper-Mega-Net Adventure

I've been hearing about the Compu-Global-Hyper-Mega-Net project for quite awhile and it sounded like something that'd be right up my alley: a large-scale VPN for #RetroComputing fans designed to replicate the Internet of the dot-com era. About a week ago I finally got to work on getting connected.

You connect to #CGHMN by running WireGuard on a modern PC, or a router that supports it. I decided I wanted to use a Debian Linux VM, so the first step was to apt install wireguard. Easy enough. Following the instructions on their wiki, I created a public/private key pair. Next, I had to fill in the sign-up form. After a few hours I received an email with my config information for WireGuard. I filled in my private key from earlier then saved it to /etc/wireguard/wgcghmn0.conf.

The welcome email also gave me my assigned subnet. In my case it was 100.68.39/24, meaning that I needed to give all the machines on my retro LAN IP addresses in the 10.68.39.0-10.68.39.254 range, replacing the addresses I had been using before. I did have some trouble finding the DNS server I needed to use, but the folks in the IRC chat let me know it was at 100.64.11.1.

Setting up Debian for routing was fairly simple. First I set it to run WireGuard on boot with systemctl enable wg-quick@wgcghmn0.service. To enable IP forwarding I created a file called /etc/sysctl.d/ipforward.conf with the line:

net.ipv4.conf.default.forwarding=1

After that I just had to reboot and everything was ready. At least as far as client access, that was it. I could connect to people's websites, streams, and whatnot from any machine on my retro net. Of course, that wasn't all I wanted to do; I wanted to host stuff too!

First thing I had to do was set up an authoritative DNS server. I chose NSD by @nlnetlabs@social.nlnetlabs.nl since it seemed like it'd be easy to set up. It was indeed, though there were a few details I didn't get right the first time. At first no one on CGHMN could ping the server, which ended up being because it wasn't binding to the right address. I had to specify ip-address: 100.68.39.1 under the server section in /etc/nsd/nsd.conf. Then it was time to fine-tune my zone file. For an experimental environment like this TTLs need to be short; an hour or less. On the "real" internet it's more common practice to set them to a day or so. In the IRC chat, I asked the admins to point the root record for n8fq.retro to my server at 100.68.39.1, under the name ns.n8fq.retro. To support it on my end I needed to set up my zone like so:

$ORIGIN n8fq.retro.
$TTL 1800

n8fq.retro.   IN  SOA     ns.n8fq.retro. jill.n8fq.org. (
        10068390    ;Serial
        1800        ;Refresh
        1800        ;Retry
        1209600     ;Expire
        1800        ;Negative response caching TTL
)
                        NS      ns.n8fq.retro.

ns.n8fq.retro.          A       100.68.39.1
n8fq.retro.             A       100.68.39.30
www.n8fq.retro.         CNAME   n8fq.retro.
n8fq.retro.             MX      1       n8fq.retro.

This meant that I had NSD running on my router VM at 100.68.39.1, while my web and mail servers would be on another machine at 100.36.39.30. CGHMN does offer email service, but I'm a masochist so I decided to run my own. Some tests with the IRC folks confirmed that everything was resolving, so now I could start working on my services.

I chose OpenBSD 3.0 for my retro server OS, mainly since I owned a physical copy that I'd bought from BSD Mall back in the day. Web was easy since Apache HTTPD comes pre-installed as part of the base system. Email was trickier. I balked at trying to get sendmail configured (I'm not that masochistic!) so I went with Exim instead. At first it was failing to deliver local mail, which I fixed by fiddling with /var/mail write permissions. I wasn't able to get any IMAP server to work but I did eventually have luck with POP3 using solid-pop3d. More tests with the IRC gang confirmed everything was working. Then I decided I wanted webmail, which posed another challenge. SquirrelMail was out since that requires IMAP, so I tried Postaci. To get that to work I had to recompile PHP from ports with IMAP support enabled (even though I was using POP3), which required me to track down some old source tarballs. Napalm FTP Search helped with that. After that was settled I just followed the setup instructions in the Postaci package and we were off.

After all that, I've earned the pleasure of sitting back with an old laptop and surfing the 'net like it's 1999! Or maybe somewhere around 2003. Whatever. If you decide to give it a try, visit my site at http://www.n8fq.retro or maybe drop me an email at jill@n8fq.retro.

Hello not-at-all cursed #CGHMN client device!