Created on March 7, 2022
Reminder: I just recently figured out how to fix a serious issue that was causing MS-DOS DHCP clients to receive corrupted files, hence I was able to affirm I could supply boot disks with DHCP enabled. Still, I have not gotten around to testing every disk provided, particularly because I tend to stick to one or two kinds of network cards. Should something go wrong, let me know so I can try to update this information and/or the disks as needed, but keep in mind that as always, no warranty is provided with the information I give here. Decryptifying the obscure arts of such things like MS-DOS is a continuous process!
Installing an operating system can be kind of tedious, especially when you have to do it on multiple computers, and even more so when a CD-ROM drive starts malfunctioning with age. These days, flash drives tend to be used for installing operating systems, but that's quite a tall order for systems that may not even have USB controllers. So what, do you just load the contents of the CD-ROM to the destination hard disk when it's plugged into another machine? That's not really convenient unless you have some mobile rack installed... but what if I told you there was a much better way of going about it?
That's where networking comes into play. All you need is a floppy disk and a network card, as well as a file server on some other machine. It could be running Windows 95 or Windows NT 4.0 of all things, or it could be a modern Samba server. The file server only needs to accept LAN Manager logons, as that's what MS-DOS uses. It's strongly advised that the file server run on a separate machine, physical or virtual, as accepting LAN Manager logons can be quite a security hazard these days.
Loading Up the File Share
I typically create a share named CLIENTS, as that's the share name the Windows NT Network Client Administrator uses by default; that's where the operating system installation directories would go. The share needs to be loaded up with a few things: operating system setup directories, and two other directories labeled DOSBIN and 95BBIN; those two directories can be used for running certain DOS utilities off the network share, and the boot floppies supplied below already have the PATH variable set to use either depending on the DOS version.
You can load these directories with the contents of a standard MS-DOS/Windows 95B boot floppy, or load only the programs you want in them. Make sure the MS-DOS 6.22 executables go in DOSBIN while the Windows 95B executables go in 95BBIN, otherwise you may get an error "Incorrect DOS version" when trying to run a program. You should also load SMARTDRV.EXE into both directories; this program really helps a lot in speeding up the installation of a Windows NT-based operating system. Since Windows 95B (OSR2) and 98 share the same DOS version, you could possibly load the boot disk files from the latter on there instead.
Typically, installation directories on a CD-ROM are located at \WIN95 or the like for a Windows 9x install CD, or \I386 for a Windows NT install CD. Once you copy such directories to the share (and rename them as needed, e.g. I386 might get renamed to WINNT), that's all that's needed. You can now run the installer, either SETUP.EXE or WINNT.EXE /B
If you have no install CDs handy, try Windows 95D Lite. This is a greatly enhanced version of Windows 95B that comes with a ton of drivers and updates that will be automatically loaded as you run the installation. Combine this with the power of an over-the-network installation, and you've really got something special.
There is one small caveat to take note of: on rare occasions, a network driver may refuse to let itself be used in the middle of Windows 95 Setup; normally, the NDIS2 driver would carry over to the first boot and continue to be used until you load a driver actually designed for Windows 95. However, at least one of my Intel PRO/100 cards causes Setup to throw an error - a non-fatal one, but one that causes Windows 95 Setup to get a monkey wrench thrown in it. Should this happen to you, the best workaround is to do things much like how you would have back when you were still using CD-ROMs: copy the setup files to the hard disk, and make the hard disk bootable with the SYS C: command.
What about MS-DOS 6.22?
The setup program for MS-DOS 6.22 is not very flexible, at least the OEM version that's designed for use with new computers. It insists on only being installed from floppy disks. However, installing MS-DOS by any other means is not complicated at all. Technically, running SYS C: is enough to create a complete installation of MS-DOS, even if it is too barebones to do any real work. Obviously you'd want more programs loaded alongside the kernel, and in order to do that, you'd have to install MS-DOS the way it was done in 1987. By creating a batch script to take care of the overhead, we can get a full-fledged MS-DOS installation ready to go in mere seconds.
First, install MS-DOS as you normally would to some virtual machine; this is necessary in order to uncompress all the files you need unless you want to run the EXPAND command over 100 times. After installing, power off the virtual machine. You should be able to extract the contents of the virtual hard disk with a program like 7-Zip, or you may be able to mount a raw disk image directly.
You can then copy all of the now uncompressed files to a directory at your file share. Since the MS-DOS installer creates a directory on the hard disk called DOS, it's best practice to replicate the directory structure on your file share. So, for a directory containing the MS-DOS 6.22 installation files, the contents of the DOS directory would be located at DOS622\DOS, and the more baseline files like AUTOEXEC.BAT would just be stored in DOS622.
Below is a barebones installation script that assumes your hard disk is already formatted, and you'll be using some network boot disks I've supplied down below. Before running the script on the target machine, you may want to update CONFIG.SYS and AUTOEXEC.BAT with settings you'd most expect to be using on the majority of the systems you'll be using. For instance, you'll probably want to have an IDE CD-ROM driver loaded by default, and you may want to apply certain performance and memory optimizations in order to make better use of 486 and Pentium systems. You may also want to have certain programs installed to the DOS directory by default; Blacklight's shutdown utility may be useful for laptops and ATX systems.
It's very important that you edit CONFIG.SYS and add this line underneath the standard-issue lines for loading your high memory drivers:
The default AUTOEXEC.BAT residing in our DOS622 must also be modified so that it may start the networking services. For a TCP/IP connection, these lines should be added around the bottom of the script:
If you are using NetBEUI exclusively, only the bottom line from there is required.
For good measure, I'd also load EMM386.EXE to that same file if it isn't already with the NOEMS option, which should free up valuable conventional memory. The kind of configuration (or menu of configurations) you want in the long run is entirely up to you.
While this script does install networking support, it doesn't necessarily have the complete installation you would get from installing the network client from the original floppy disks. You don't need such a complete installation in practice, I just wanted to let you know about it in case purism is a priority.
The Boot Disk
While you can generate a network boot disk yourself using Windows NT's Network Client Administrator program (this also works in Windows 2000), I've went ahead and made some disks for several popular PCI and ISA network cards already. These disks assume you're using TCP/IP, the most ubiquitous network protocol out there. Refer to another section below if you want to use something like NetBEUI instead (that is lighter on conventional memory).
Using these disks, you can run FDISK and FORMAT off the network share to get your hard disks prepared to install an operating system, assuming you have already loaded suck programs to the DOSBIN and 95BBIN directories, respectively.
You will need to perform some manual modification of these disks before you use them. In Windows, you can use a program called WinImage to modify the images directly, or in Linux you can just mount them to a directory with the -o loop option at the command line. There is also the option of writing the image to a physical floppy disk upfront and modifying it there, but really only works as a last resort.
The first file to modify is SYSTEM.INI. All you need to change in the [network] section are the values for workgroup and logondomain. These values should match the name of your workgroup or domain. If you're tight on conventional memory, you may also want to change preferredredir and autostart to basic, which would tell the network client to use the basic redirector instead of the full one. I have run Windows 95 Setup with the full redirector without memory-related issues on two network cards so far, so
Next, you should modify AUTOEXEC.BAT at the root of the disk. In a part of the file I've labeled as Section C, there is a NET USE command which maps a share to the Z: drive. Change the computer and share names to match what you've got set up. The bottom of Section D is where you could have your setup program run. For easier maintainability, I would prefer to have this call another batch script residing on the network share, to which you can then perform the tasks you need to after logon without having to go back and update the floppy disks over and over again. This might call for a visual pop-up menu selection program in the future... shouldn't be too hard to write at this point, right?
Got it? Alright, there are a lot of disks here, so take only what you need...
MS-DOS 6.22 Boot Disks
These are best suited for installations to FAT16 disks. They should be used when you're installing MS-DOS, Windows 95A (RTM), or Windows NT 4.0 and earlier.
Windows 95B Boot Disks
These should be used if you are installing to a FAT32 disk. It works best with Windows 95B, Windows 98, and Windows 2000.
If you need to use a different kind of boot disk, use the Windows NT Network Client Administrator program. Using a floppy disk with the program is not mandatory, but when it creates a set of files for the network boot disk, it expects the disk to already be formatted and loaded up with a bare minimum MS-DOS boot environment (this can be done with SYS A: or FORMAT A: /S)
Then, if desired, you can adapt the existing AUTOEXEC.BAT to use the routine I've set up in my own disks. My routine uses Infsect, which can be downloaded here.
IMPORTANT: If your netboot disks will use DHCP, the line sizworkbuf=1498 must be added to the [network] section to avoid file corruption on the receiving end! Also, the disks assume you are using a 386 computer or faster; if you will be using a 286, or perhaps even an XT-class machine, you ought to remove the [386enh] section and use the basic redirector.
The Power of PXE
Now for the really exciting part: it turns out that you don't really need a floppy disk after all, not if your network card has a PXE boot ROM! The 3Com 3C905C-TXM is my go-to network card for fast, highly compatible networking and PXE booting. ISA network cards will not have PXE capabilities, but if your network card has a ROM socket, you may be able to get some sort of EEPROM and program it with a gPXE ROM appropriate for your network card. More details on that are available on the website for the Etherboot Project.
Assuming you've already started up a TFTP server, you'll need to download Syslinux. If you do not have a TFTP server running, you can use TFTPD32/64 on Windows (and enable its DHCP server if needed, making sure to use an IP address range outside of the one your router uses) or dnsmasq or tftpd-hpa on Linux, the latter which is covered in this guide.
Once you have Syslinux downloaded, you need to take a few files from the archive:
These files should be copied into the TFTP root directory. Do not copy the directories which they reside in; it's expected that each file resides on a "flat" surface, to put it one way. After that's done, we should create two other directories inside the TFTP directory, being images and pxelinux.cfg. The images directory is where we will store most of our bootable images, which could be floppies or small ISOs. pxelinux.cfg is where PXELINUX expects configuration files to be stored at.
Load the images you want to be able to boot from over the network into the images directory. After that's done, you should create a new file called default located in the pxelinux directory. This file should NOT have an extension at the end of the name. Let's create a simple file.
Note that there's a line at the top which says TIMEOUT, followed by a number. It's preceded by a semicolon, so it has no effect, but if you were to remove that comment marker, PXELINUX would automatically execute the top listing within 10 seconds; the option takes a number in tenths of a second, so 100 is 10.0 seconds. The timeout is particularly useful if you want to deploy many installations of an operating system at once hands-free.
While you're at it, you may want to grab a couple of other handy bootable non-DOS programs.
Here's how they would be loaded into your PXE boot menu:
Adding ISO Files
You can also add entries for ISO images. Don't use this method for installing operating systems that expect to go through multiple reboots, as the contents of the ISO file are only stored in RAM once, and cannot be mounted again later. Plus, ISO files can end up being up to 700MB or even larger depending on how they're designed, and since the entire contents of such an ISO file will be stored in RAM by the Memdisk module, it may be far too much for certain Pentium III systems (as well as a stock Windows 9x installation without patches).
Some operating system developers provide "boot only" ISO files that take up a much smaller size and provide options to install the operating system over a LAN, the internet, or some other medium.
This is how you would add an entry for an ISO file:
If you find yourself accumulating a lot of menu entries, you can organize them into other menus in separate files. Let's restructure the default configuration file a bit:
There's a few things to notice here - rather than any of the entries in the default file calling memdisk, they call menu.c32 with an APPEND directive. So, when you select such an entry in the menu, it reloads the menu with a different set of entries stored in another configuration file. Also, I wrote >> at the end of the new entries to indicate each leads to another menu.
To make these entries useful, we should create some submenus in the specified files now. In the pxelinux.cfg, let's create two files, being dos622.cfg and win95b.cfg. Let's populate these files now...
Notice in these two files, I've organized the disk images more, by creating the directories dos622 and win95b within the images directory. You don't have to do this (in which case you would use a path like images/tcp622_el90x.img instead), but as you accumulate more operating systems, managing everything on a flat directory structure can get tedious.
I also added entries for "normal" MS-DOS boot disks which don't have networking capabilities, only some essential utilities. These utilities are always available to immediately access. They're helpful whenever you don't want to use networking, such as when you're partitioning a hard drive with FDISK, which needs to reboot after its work is done, or when you need to edit a text file somewhere without booting from a hard disk. Such disks are named dos622.img and win95b.img, respectively.
A very important entry at the top of both submenus has a label of upDir. This is used to take the user back to the main menu, which is needed in order to avoid a wasteful reboot just to get back there.
It is possible to use a "graphical" menu instead of one that uses pure 80x25 text mode. While this does not look like it will be compatible with all VGA cards since it uses a video mode a little bit above the original IBM VGA specifications, it has worked with pretty much every PCI VGA card I've thrown at it, including the popular S3 cards from the mid 90's. All you need is a PNG or JPEG image at 640x480 handy (higher resolutions can be used if you really want to; see the page I've linked to below for more details). Make sure it's dark enough so the text doesn't blend in with it.
For starters, you could download a background I used to use when PXE booting.
To set the background, add this line to the top of your default configuration file, just under the lines DEFAULT, PROMPT, and TIMEOUT:
This assumes your background is located at the root of the TFTP server. If it's stored in another directory, you'll need to specify the path leading there. If you're going to jump to another submenu, the background must be reloaded in the submenu's configuration. This can be done in one of two ways: one, add the line above into each and every submenu you create, and two, create a separate configuration file with some common options (I'd call it common.cfg) with that aforementioned line. In that case, all submenus should have a line up at the top as follows:
The second method is easier to maintain, as you only have to update one file should you wish to change the background at a later time.
Important Notes about Memdisk
Unlike a physical floppy disk, a floppy image booted from PXELINUX with Memdisk does not save its changes when you reboot the computer. That's because the actual floppy image is copied to RAM. It can be read from and written to, but once the system is rebooted or powered off, the contents of the RAM disk are destroyed, so when you boot from the floppy image again, it starts over with the original contents from before. Be mindful of this as you're setting hostnames and IP addresses when you boot from the floppy images I've supplied above.
You cannot switch from one floppy disk in RAM to another in the same boot, at least as far as I'm aware. So, if there is an operating system which requires multiple floppy disks to install, it cannot be done with PXELINUX and Memdisk.
If your system has two floppy disks installed, the B: drive will not be usable for the time being. The A: drive, however, will be usable. In the Memdisk environment, it will be seen as the B: drive, while the floppy image you're booting to will be the A: drive. It's possible that you may encounter subtle issues when trying to do very specific things with a RAM-resident floppy disk, but most of the time you should be able to go along all fine with the added benefits of much faster RAM disk operations. Most issues I've encountered probably happened in systems with two floppy drives installed. Read the official Syslinux wiki documentation for more possible options available in the menu module.
With PXE and some floppy disks all set up, you should be smooth sailing for networked operating system installations now, and your overall quality of life in managing your old computers will improve drastically.
No comments for this page.
Leave a Comment