For those of us who love vintage computing, many of us remember some of the more iconic
programs of the 80s and 90s.
For example, I have plenty of fond memories of playing DOOM and Duke Nukem 3D.
I still remember seeing WordPerfect and Lotus 1-2-3 being the forefront of business software,
and of course, I can remember that magic moment the first time I beat Solitare.
That being said, one thing I wish I could forget was the constant fight for hard disk space.
After all, every application I just listed needed its own bit of the C drive.
One of my first computers was a hand-me-down Compaq DeskPro with a very small hard disk,
and it was a constant battle of either deleting programs, tempting fate with DoubleSpace,
or trying your luck with external storage.
That being said, ever since my last video on Novell NetWare, I’ve had a lingering
question in my mind.
For a modern vintage ethunist, is it realistic that we just ditch the hard disk entirely?
Well, after finding a bit of code on the Internet, I was inspired to find out.
So as usual, this is your host NCommander, and today, some experimentation is required.
I won’t be surprised if a large majority of folks don’t recognize the program running on screen.
It’s Novell’s NetWare Ready Firmware for AMD network cards.
That probably means nothing to the vast majority so let me break it down.
If we look at this photo of an actual AMD PCNet card, you might notice this large chip socket here.
This is a spot for a special firmware chip called an Option ROM.
Option ROMs are special programs designed to modify how a PC starts up.
In this case, I was able to find a binary copy of the Option ROM for AMD PCNet Cards, which is what you now see on screen.
Of course, I still need to explain what “NetWare Ready” actually means!
In short, it’s a way to boot a computer without a floppy disk or hard disk!
For those familiar with modern networking, this might sound a lot like PXE.
PXE, short for Pre-boot eXecution Environment, is the modern way of starting a computer from a network.
However, PXE is a relatively recent development, having only been standardized in 1999.
Before that, we had RPL, or “Remote Program Load”.
Ready Start is merely Novell’s branding for the RPL protocol.
While there are significant technical differences between PXE and RPL, the largest is that RPL
is capable of starting most variants of DOS directly, as well as OS/2.
To actually get started though, we need an RPL server of some sort.
Quite a few networking solutions offer RPL, and the splash screen seen in Ready Start
shows a large list of early 90s network software we could potentially use.
However, given that NetWare inspired this project,
it seems more than fitting we should use it.
While we watch NetWare install, its a good opportunity to talk about how we’re going to test this.
In truth, I actually had the RPL firmware working some time ago, but I felt that just
doing a test between two VMs wouldn’t really be an indication of how well this would work in reality.
That changed when I found this Kingston PCMCIA 10 Megabit Ethernet card for my ThinkPad.
This gives us the opportunity to both demonstrate our apps running in a VM, and how they’d
perform on a period correct network.
That led to a rather crazy project of mine: Let’s assemble a small office NetWare network,
put all the essential apps on the NetWare server, and really put it to the test.
As seen in this diagram, we’re building a four machine network: At the center, we
have ODYSESSY_II as our NetWare server.
As we’ve seen before, we need a dedicated machine to do system administration, in this
case, that’s DISCOVERY.
Meanwhile, our client systems are EUROPA which is a QEMU instance booting via RPL, and finally,
TMA-1 which is our real life ThinkPad 380D.
I’ll put the machine name in the corner of the video to help keep everything clear.
This gives us the advantage of both being able to experience both ideal circumstances,
and get a real life idea of what it would be like.
Let’s get down and dirty with getting things installed.
As with any NetWare installation, proper configuration begins with writing the rather extensive autoexec.ncf
which is now on screen you see on screen.
I’ve uploaded an annotated version of this file for those who are interested; the link
is in the description.
The biggest takeaway from this though is the BIND RPL lines, which tell NetWare which interface
we want to enable remote booting from.
If we now boot our RPL machine, we get a new message: NET$DOS.SYS not found.
In the NetWare system folder, we have this utility, DOSGEN.
DOSGEN reads a literal floppy disk, and creates the NET$DOS.SYS file in the current working
directory.
If we format a normal floppy disk as a DOS boot disk, switch to the LOGIN folder, and
run DOSGEN, it succeeds!
If we now reboot EUROPA, we can now see DOS loading over the network via RPL
This works because RPL is essentially faking a read-only floppy drive;
whatever is in NET$DOS.SYS is loaded up on the client machine!
For example, if I create a test AUTOEXEC.BAT, and rerun DOSGEN,
we can see that change after a reboot.
Up to this point, I had been following the instructions in NetWare’s DOS Workstation
manual but, I hit something of a stumbling block.
The DOS Workstation guide specifically states you’re supposed to DOSGEN a “workstation boot disk”.
What it doesn’t tell you is how to make that.
From the diagrams, I can see some of the files that should be on the disk.
What I inferred after some trial and error is I needed to copy the core parts of the
NetWare client, write net.cfg, and then set autoexec.bat and config.sys correctly.
After more than a few failed attempts, I ended up with a floppy disk image that could successfully
start DOS, and attach itself to ODYSESSY_II.
I could even login!
I’d say I was home-free, but I wasn’t.
After running DOSGEN on my “known working” network boot disk, I had the rather unfortunate
problem of the system hanging.
A lot of experimentation showed that the moment that the PCNET driver was loaded, the RPL
firmware glitched out and reset the network card.
The end result was that DOS would hang because the Ready Start or its IPX driver was no longer available.
I tried various fixes, and went searching through the annals of USENET to try and figure
out what was going on.
What I learned was that this type of crash appears to have been fairly common.
The root cause appears to be due the fact that the NetWare client is modular, and that
the network driver must be loaded before the IPX stack.
This problem occurs in both NetWare’s official drivers like their NE2000 driver, and add-ons
like the PCNET driver I was using.
Various solutions such as installing an updated RBOOT, and various server side patches were
tried with no avail.
The most common solution was to simply use the older monolithic drivers from NetWare
2.0 which appear immune to this problem.
That would have been great if I had a driver from that era!
Finally, I managed to find one post that had figured out a workaround: to create a RAM drive,
and load the client from that!
Most DOS versions ship with RAMDRIVE.SYS,
a simple device driver that creates a blank RAM disk on startup.
Furthermore, DOS supports relocating COMMAND.COM after startup by using the COMSPEC environment variable.
After a lot of fiddling, I was able to copy up with a set of batch files which create
a RAM disk, copy the boot files from it, and initialize the network successfully!
As seen by the boot messages, EUROPA has made first contact with ODYSSEY_II!
For those who want to try this at home, the necessary batch scripts and instructions are linked in the description.
The next step was to bring the Tycho Magnetic Anomaly up to speed with this plan.
Unfortunately, despite my best efforts, I have yet to find a way to port or otherwise
run an RPL boot ROM on this machine.
EasySetup does list network boot as an option, but only supports a Token Ring adapter of some sort.
That being said, a boot disk is entirely practical.
As it turns out, all I needed to do was take the existing DOSGEN disk, replace the PC NET and we’re good to go.
Unfortunately, removing the hard disk from this ThinkPad is exceptionally difficult,
and not something I can easily do at this time.
To simulate a diskless environment though, I decided to simply delete the DOS partition on the hard disk.
Perhaps in the future I'll do a follow-up with a proper diskless setup on real hard,
but for the moment, this is the best I can do.
Switching back to our administration machine, let’s do a bit of basic setup.
The first thing we need to do is create a proper user, and figure out how to lay everything out.
Novell doesn’t provide any hard and fast rules for how to set up users or networked applications.
As I’ve shown before, the most Novell gives as far as guidance are these worksheets in
the Installation Manual.
The only truly necessary component is that the SYS:PUBLIC folder, which contains most
of the NetWare utilities, needs to be assigned a drive letter.
Beyond that, pretty much anything is fair game.
That being said, there are some obvious considerations.
As DOS normally assigns drive letters starting from A and going downward, it makes sense
for us to start at Z and make our way up.
That reduces the possibility of any sort of collision
First, let's get the obvious out of the way and map SYS:PUBLIC to Z.
The next bit is also fairly simple. We still need the rest of DOS.
We'll copy the DOS 6.2 folder from DISCOVERY and then map that folder read-only to drive letter Y.
We'll then dedicate drive letter X to holding our applications with each application being in a subdirectory.
Furthermore, I decided the user's home folder should be in L as it is roughly in the middle of the alphabet and is unlikely to cause a drive letter collision.
While DOS itself has no concept of users or home directories, by using a consistency mapped
drive letters, we can set sane defaults for applications and login scripts.
With the planning out of the way, let's get DOS and our login script sorted.
During installation, I created dedicated volumes for DATA and USERS.
Using XCOPY, I can simply copy the installed DOS folder from DISCOVERY in one single go.
Likewise, our home folder is stored on USER:NCMDR.
The login script then becomes extremely straightforward to write, and we now have a basic DOS system
ready to go on EUROPA.
Of course, we still need some actual applications to go along with this.
With all the setup work done, let’s start with the work stuff first.
And by work, I mean WordPerfect 5.1.
WordPerfect is one of a few DOS applications that has a specific Network install option.
Since DOS is normally a single user operating system, it’s not uncommon for applications
to have issues due to faulty assumptions, something we’ll see later.
Rather notably though, after a network installation WordPerfect’s behavior also changes.
After installation, running “WP” causes this new prompt to type in a three letter username.
This is WordPerfect’s way of keeping separate user’s settings separate, although it's
irrelevant with the way the L: drive is set up. That being said, as expected,
WordPerfect performs flawlessly over the network, so let’s give that the
big olde stamp of approval.
Next up is Lotus 1-2-3, version 2.4.
1-2-3 was one of the biggest killer apps, and remained one of the mainstays of businesses
until Excel would eventually push it out of the marketplace entirely.
Unlike WordPerfect, 1-2-3 doesn’t have a network option.
Infact, I had considerable issues getting 1-2-3 to work at all, with it constantly getting
stuck with broken display settings.
Even after I got resolved, it would constantly complain about read-only drives.
A lot of trial and error showed that Lotus’s configuration is split into what it calls
sets, and I eventually stumbled upon the right settings to move it’s working directory
to the L: drive.
While 1-2-3 didn’t make it easy, I have to give it a “It Works” stamp.
Now, I could sit here and do business software all day, but let’s try something a bit more interesting.
Games usually have to read resources across the network to load levels, art and music.
As such, I’m expecting some more interesting catastrophic failures.
Let's start with the smash hit of 1993, DOOM!
Here we start running into problems.
DOOM itself installed as SUPERVISOR, but I couldn’t configure it properly.
This is due to it's folder being read-only.
Changing the permissions to grant write access allowed SETUP to run just fine.
And I was really impressed to see it running without issue on the ThinkPad over the network.
That being said, there were some problems.
On our emulated machine, DOOM immediately hung.
This doesn’t appear to be because of the network, or the fact that this is a diskless machine.
In fact, it appears entirely due to broken sound emulation in QEMU 4.2
I guess it shows that bit rot in emulators is real.
There isn’t much demand to run DOS, so things like SoundBlaster support suffer.
That being said, it’s to NetWare’s credit that this not only works, it’s fully playable
on an 10 megabit Ethernet network.
In that vein, I decided to try something a little more demanding: Duke Nukem 3D.
LIke DOOM, I had to set its folder to read-write, but it works too!
I really have to give credit to NetWare here for making it’s client both performant and seamless enough that this works without issue!
Now I could sit here all day and continue trying various DOS applications, and if you guys have any suggestions,
I’d be happy to do a follow-up, but there was something specific I wanted to try: Microsoft Windows.
Windows 3.1 was the last 16-bit version of Windows that could be easily exit back to DOS and could simply be launched as an application
While Windows 95 could be loaded via RPL, it required a rather involved process to do so.
If you do want to see me do diskless Windows 95, leave a comment below.
Getting back to Windows 3.1, getting diskless operation to work was a little bit of trial and error
The first step is to do what is known as an “administrative install” as SUPERVISOR.
This launches the Windows Setup as normal, but it just prompts for all six disks, and
never starts the graphical part of the installation.
Instead, all the files are decompressed and installed to the X:\WIN31 folder.
The next step is then to login as the NCOMMANDER user, and run “SETUP /N” which does the
Network installation part.
Once again, installation prompts for a folder, but unlike the administrative install, this
is for an individual user's settings.
This looks similar to the normal to the normal graphical Windows installation, but it doesn’t
prompt for any disks.
In theory, I should be able to simply type “WIN”, but that errored out when I tried
it with the given error message that my NetWare shell was too old!
Some searching turned up an archived TechNet article which outlined how to fix it this.
Afterwords, we can simply start Windows just fine.
A closer examination with File Manager shows the small number of files in L:\WIN31, and
the rest of the files on the X: drive.
At this point, I think we can conclude, yes, Windows 3.1 can in fact be run without a hard disk.
And yes, it does work on real hardware!
As we reach the end of this video, it's time to draw some conclusions
In general, NetWare has been both rock solid and fast.
However, we've also seen a lot on why it's important to test things on real hardware..
Besides the DOOM sound issue, QEMU has had relatively poor network performance and notable lag.
I don't know if an artifact of emulation, or a problem with the RPL firmware itself.
I hope to acquire hardware capable of doing native RPL booting in the near future so I may come back to this topic in a future video
That’s all the time we have for today, so as usual, if you like this video, please like and subscribe,
it really does make a huge difference for the channel.
If you’re interested in my adventures in real time, feel free to follow me on Twitter
or come join my Discord.
Until the next time, this is NCommander, signing off!