This walkthrough covers installing MS-DOS 6.22 from the original installation diskettes. Why write this in 2013? That's a very valid question, to which there are a few answers:
Honestly, if you have no appreciation for old hardware or software, then this is definitely not for you. If, however, you share my passion for technology, not only for the new hotness of today but also the old and busted (and tried and true) of yesterday that got us to where we are today, then I think you'll find this interesting. If you have some old hardware lying around then I hope you'll follow along, but even if not I think you may still find some of this interesting enough to read.
As an alternative, if you want an easy-to-install version of DOS that includes some nice modern conveniences, check out FreeDOS. It's a great project that I highly recommend. For this project, though, I want a (mostly) authentic, original MS-DOS installation.
Note: I provide download links for all discussed software in the relevant section where it's discussed. Links point to the original download location for each file wherever possible, but for the files that no longer have an official source (or a reliable one, in the case of the files hosted on Microsoft's amazingly unreliable FTP server), I've linked to a local copy you can download instead.
Tip: I also recommend grabbing a copy of either Universal Extractor or 7-Zip if you're running Windows on your main computer, or p7zip and LHa for UNIX if you're running Linux (both should be available in your package management system). You'll probably need/want to unpack some of the software and drivers listed below on your main computer before copying it over to your new DOS system, and some of these are packed in fairly obscure (for today) formats. These applications should cover all the software I tried to unpack, so having these tools available in advance will save some time and hassle.
If you need to create the installation media:
dd if=disk1.img of=/dev/fd0 bs=1024 conv=sync; sync
You can get by with only one floppy diskette by writing the next disk image after the previous one completes installation, but I highly recommend using at least two diskettes so that you can have a copy of Disk 1 on hand at all times. You'll likely need to boot from or otherwise use that disk a number of times
If you need/want to partition and/or format your hard drive:
F3at the MS-DOS Setup welcome screen to exit the installer
format /v:labelname /u /s c:
/vsets the disk volume label; this can be omitted
/uperforms an unconditional format, which omits preserving certain recovery information
/scopies DOS system files to the partition, allowing it to self-boot
setup.exeto resume installation
Aside from possibly needing to FDISK and FORMAT your hard drive, the base MS-DOS installation is actually quite simple:
c:\dos. Press Enter to continue.
After rebooting, you'll be in a fresh, and very basic, DOS environment.
If you installed either MS-DOS 6.0, 6.2, or 6.21, you may (optionally) upgrade to 6.22 using MS-DOS 6.22 Step-Up. Since it's free, though, there really isn't a good reason to not upgrade.
The most annoying part of this process is just getting the Step-Up files to your DOS system. It's larger than a single floppy, and meant to be downloaded and run directly on the target computer, which is difficult for a freshly installed version of MS-DOS. To workaround, I suggest the following:
copy a:\*.* c:\backup\stepup
copy c:\backup\stepup c:\stepup
Yto agree to the EULA
Yto verify that C: is your OS drive
Yto begin upgrade
deltree /y c:\stepup
My copy of MS-DOS includes a fourth disk titled "MS-DOS 6.2 Supplemental Utilities," which can also be obtained from the link above (grab the version for MS-DOS 6.22, named SUP622.EXE). This disk is not mandatory, and mostly just includes some extra features from previous versions of DOS that were dropped for version 6.0. If you don't want to bother with it you won't be missing out on much, but just to be thorough let's take a look at how to install the more interesting stuff on here.
Sto install selected components only
Nas each component is listed. The only options I find interesting are the Additional MS-DOS Utilities and MS-DOS Shell, you enter
Yfor these if you feel so inclined.
Now, why bother with the Additional MS-DOS utilities? One reason, and one reason alone: QBasic Nibbles! I spent many hours playing this relatively simple but addictive Snake-like game as a kid, and was delighted to discover it on the supplemental disk. To try it yourself, just run
qbasic.exe /run c:\dos\nibbles.bas.
DOSSHELL, however, is a bit more substantial. It's essentially a primitive Windows-like (or perhaps more accurately, 'Windows Light') environment that runs on top of DOS and provides a GUI file manager, file associations, a menu-driven task list, and even primitive pseudo-multitasking (called Task Swapper here). It's not something I'll care to use, but it's a pretty interesting idea that I was completely unfamiliar with before this project, and it seems like it could be a reasonably powerful interface if a little time is spent on configuring it just right (though, honestly, running Windows 3.x instead will provide far more power and flexibility). I'm not going to dive into this here as it's beyond the scope of "(mostly) pure MS-DOS", but here are a couple tips if you want to play around with this:
/t) or GUI mode (
/g). Both interfaces are quite similar, but GUI mode can be configured to run at a much higher resolution. Try
dosshell.exe /g:h2, for example.
dosshell.inito tweak it to your heart's content, using the default menu items as an example. Like I said, if you're willing to invest a little time in this, it could probably be tricked out pretty nicely.
Before installing anything else, we'll configure a basic sane working environment:
mkdir apps- contains personal installed applications
mkdir temp- temporary directory used by some applications
mkdir backup(if necessary) - contains copy of original setup files or drivers
path c:\apps;c:\dos- set our installed apps to take precedence over built-in apps
Next, I recommend installing a couple utilities that will make the rest of the setup process much easier. As with the step-up files above, getting the files to the system is still annoying at this point. Until we get networking setup later on, I recommend unpacking the programs on your main computer and copying them over with floppies as the easiest option. I also recommend saving a backup copy of all of your installation media/files and drivers under
c:\backup (or, preferably,
d:\backup for easy access to it at any later point.
c:\apps\doskey.com -ito activate it. Running
doskey -?will show some additional information about how to use it.
move c:\apps\peditlgt.exe c:\apps\edit.exe. This will let you launch Pedit by simply typing
edit, making it effectively replace the built-in DOS editor.
edit, hitting Esc if prompted to open a file, and entering
Alt-F1. I like the following non-default settings:
Alt-Xto exit and save the changes
unzip32.exeis more flexible, but requires a separate DPMI (DOS Protected Mode Interface) memory manager, which won't be covered here. Other included binaries simply provide extra functionality not required for Zip extraction.
Now that we have a good editor and input processor installed, it's time to configure DOS itself.
Tip: You will be repeatedly hand editing your system configuration files throughout this walkthrough, and it's very possible at some point that you may be stuck with a system that won't boot properly. To recover, hit
F5 when DOS starts booting (when it says "Starting MS-DOS...", usually immediately after your system beeps to indicate it has completed it's POST process). This will perform a clean boot of the system, ignoring your
config.sys files. You can then edit them as appropriate to fix the problem, and reboot to load everything again.
To get started, edit
c:\autoexec.bat and add/change the following (other settings should be left alone for now):
loadhigh c:\dos\smartdrv.exe loadhigh c:\apps\doskey.com -i path c:\apps;c:\dos;c:\dos\net set DIRCMD=/o:gne set TEMP=c:\temp
Note: Most DOS commands and options are not case-sensitive. While most of the text in the stock autoexec.bat file is capitalized, I tend to convert it to lowercase just because I find it easier on the eyes. My personal naming convention, used throughout this document, is pretty simple: variables are fully capitalized, and almost everything else is lowercase. Feel free to leave everything uppercase if that works for you, though.
SmartDrive is "a disk caching program ... that improves data transfer rates by storing frequently accessed data in RAM" (per Wikipedia), and is enabled by default in DOS. Some versions of DOS include the
/x argument by default, which disabled write-behind caching; if you see this, remove it. Unless you're running on a known bad hard disk or expect to have frequent power failures (in which case, you should really fix those problems instead),
/x won't be needed and only slows down disk writes.
LOADHIGH will load the specified program (when possible) into upper memory, freeing up the all important conventional memory for other applications. This requires that EMM386 also be enabled, as shown below. The PATH setting specifies
c:\apps first so that our installed applications always take precedence over the OS programs (allowing Pedit to be easily used instead of EDIT, for example). The
c:\dos\net directory doesn't exist yet, but will shortly.
Finally, the DIRCMD variable instructs the DIR command to display files sorted first by name, then by extension, with directories always listed first (by default, it lists files sorted by date). I also modified TEMP, pointing it to
c:\temp to make it more general purpose; ie., anything can write to this directory without worrying about possibly overwriting DOS files.
c:\config.sys and add/change the following (again, other settings should be left alone for now):
SWITCHES=/f DEVICE=c:\dos\himem.sys /testmem:off DEVICEHIGH=c:\dos\emm386.exe ram i=b000-b7ff DOS=high,umb BREAK=on rem DEVICEHIGH=c:\dos\setver.exe
/f option to SWITCHES instructs DOS to skip a two second waiting period when booting so that your system will boot a little faster. Note that this shortens the amount of time you have to press
F5 if you need to clean boot your system, but it's still possible if you're fast, or you hold down
F5 right before DOS starts loading (which is what I do).
HIMEM.SYS is MS-DOS' extended memory manager, allowing the OS and applications to use more than the first 640 KB of available memory (RAM). The
/testmem:off option instructs HIMEM to not test your RAM on every boot, saving some time in the boot process.
EMM386 is DOS' expanded memory manager and, which (also) allows access to memory over 1 MB. Although this does roughly the same thing as HIMEM.SYS, EMM386 is required in order to load programs and drivers into upper/high memory (the area between 640 KB and 1 MB), so it's generally a good idea to load both.
ram instructs EMM386 to allocate RAM as EMS (expanded memory - an older version of upper memory management that was superseded by XMS (extended memory)).
noems can alternatively be used instead to disable expanded memory emulation in order to free up a little extra memory, but many older applications and games (including some discussed here) will only use EMS, so unless you have a specific need I recommend using the
ram option to enable EMS. I discuss this a bit more in the Addendum below. The
i=b000-b7ff option frees up a small amount of additional memory that is ordinarily reserved for monochrome monitors.
umb portion of the DOS option instructions MS-DOS to manage the upper memory blocks created by EMM386 (so LOADHIGH and DEVICEHIGH will work), and
high causes it to attempt to load part of itself into high memory when possible. DEVICEHIGH, like LOADHIGH, instructs the specific program or driver to load itself into high memory. Finally, BREAK enables the use of Ctrl-C for breaking out of misbehaving programs.
I commented out SETVER as it generally shouldn't be needed. Unless you plan on running particularly old (even by MS-DOS 6.x standards) software or drives, you can leave this disabled to free up some space. If you get any errors about a program not supporting this DOS version, uncomment this line and see Microsoft's Knowledge Base article on Using the SETVER command. You can also refer to Microsoft's list of applications that require SETVER
I recommend rebooting at this point to let the new configuration take effect. Run
mem /c /p after rebooting to verify that high memory is being utilized; at least some programs should be listed in the Upper Memory column.
NIC Drivers (you'll need to grab drivers for your specific NIC; these drivers cover my system, and will be used for the walkthrough):
Now it's time to (finally) configure networking. Getting this up and running is extremely helpful because it largely eliminates the need for floppy disks. Unfortunately, networking under DOS is... primitive. It can be done, but it's somewhat limited, slow, and painful to install due to multiple driver and network protocols. So, get ready for some fun!
The first decision to make is to decide what kind of networking support you want installed. In brief, there are two types of drivers we're going to install:
NDIS - the newer device driver interface co-developed by Microsoft, with somewhat more features and capabilities at the expense of more bugs and significantly more memory usage. This is required for Microsoft networking utilities, including support for drive mapping.
Packet Driver (PD) - the older, open device driver interface used by pretty much everything before NDIS. Most non-Microsoft network utilities require a packet driver interface and will not work with only NDIS installed.
Fortunately, this isn't a one-or-the-other choice; it's possible to install support for both with some extra work. If you only need one or the other, though, save yourself the hassle and go with that one. I'm going to walk through installing both below, and point out what you should do differently if you only want to install one of the drivers.
Note: Installation order differs depending on whether you want only PD support, only NDIS support, or both. Also, while the PD option may sound more limited than NDIS, it's really not. You can get it setup much faster, it's more efficient, generally more reliable, and much more widely supported, and among the various utilities that use it are DOS versions of SSH, SCP, SFTP, and even an NFS client. The SSH utilities will let you easily and securely copy files from another system without messing with NDIS or enabling DOS support in Samba (which is not enabled by default), and NFS will let you mount an NFS share as a DOS drive letter, very similar to mapped drives. For the full experience it's worth setting up NDIS (it can be cleanly disabled if you decide it's not worth it), but if you just want to get up and running as quickly is possible, the PD-only option should suffice, and is all I use on my system after experimenting with all of this.
Both NDIS and (native) PD require hardware drivers for your NIC. In my case, I'm using a 3Com 3C905C, which is a Plug and Play PCI NIC with a relatively easy configuration. If you're using an ISA NIC, there may be more steps involved for specifying the number, I/O address, etc. Download the appropriate driver package for your NIC and consult the documentation for details.
Edit: Due to various circumstances I've also setup a Kingston KNE20T and a 3Com 3C509B in this system, so instructions for all three NICs are included below.
The following files are required for DOS networking for each of the listed NICs:
Note: For the Kingston KNE20T, the listed files are included in
pnpdata1.exe. This file can be manually unpacked, but it's probably easiest to use QStart to unpack them for you:
If you only want to install the PD interface, copy the packet driver to
c:\autoexec.bat and add the following (note: the
/I for the 3C905C is case sensitive):
loadhigh c:\dos\3c90xpd.com /I=0x60
loadhigh c:\dos\3c5x9pd.com 0x60
loadhigh c:\dos\3c509.com -p 0x60
loadhigh c:\dos\ktc20pkt.com 0x60
0x60 option for each specifies the software interrupt; 0x60 is the default, and there shouldn't be a reason to change it unless you're using multiple NICs. This is optional on some cards (such as the 3C905C), but it doesn't hurt to be explicit, and it's required if you want to unload the driver later (with
/u, where supported).
Run the above command now to manually load the driver; assuming you have an ethernet cable plugged in, it should automatically detect the connection. If all you need is a PD interface, skip to the Packet Driver Configuration section.
NDIS driver installation is quite a bit more involved. It can be installed manually like the PD, but instead we're going to let installation and configuration be handled by Microsoft Network Client 3.0 for MS-DOS (MS-Client). MS-Client, as the name implies, is a multi-protocol stack for MS-DOS, requiring the use of an NDIS driver to talk to network hardware.
To prepare for setup, copy both MS-Client disks to your hard drive (as noted above, I recommend keeping a copy in
c:\backup as well - last time I'll mention this). Running each EXE file will unpack them to the current directory if you didn't unpack them before hand. If prompted, it's safe to overwrite any files as a few exist on both disks (assuming you copied the MS-Client disks to their own directory).; Copy your NIC's NDIS driver and configuration file (noted above) to your hard drive as well; place both in the same directory (if necessary) and note the location.
Note: If you are using a 3c90x card, you must edit
oemsetup.inf before proceeding with MS-Client installation. Comment out (or delete) the following lines and save the file:
To begin MS-Client installation, run
setup.exe from Disk 1.
c:\dos\netfor the installation directory (since these are DOS-specific drivers)
A bug in the MS-Client installer prevents a file necessary for Windows 3.1x support from being installed. This isn't necessary if running solely under DOS, but it doesn't hurt in anyway, so let's install it just to be safe. To do so, from the msclient setup directory run:
expand disk2\wsahdapp.ex_ c:\dos\net\wsahdapp.exe
If you run into any other trouble, or have questions about some of the options, official MS-Client setup documentation is still available from Microsoft.
MS-Client updated your system configuration files during setup, so let's review those changes and make a couple changes. First, edit
config.sys and change the following:
IFSHLP is the installable file system helper, and provides access to file and network APIs used by the MS-Client utilities.
Next, edit autoexec.bat and change:
loadhigh c:\dos\net\tcptsr.exe loadhigh c:\dos\net\tinyrfc.exe loadhigh c:\dos\net\emsbfr.exe
These are some of the various network services installed by MS-Client. We're requesting that they load themselves into high memory. Note that the lines containing the net command, *.com, and nmtsr.exe are NOT set to load in high memory; this is necessary, as these services must be run from conventional memory.
Note: If you get the error "Insufficient memory to load Tiny RFC 1.0" on boot (or a similar error from one of the other services), remove
loadhigh from the front of that line as well. This indicates you've run out of upper memory, and MS-Client isn't smart enough to load itself into conventional memory instead.
Reboot load the network drivers.
After rebooting, MS-Client should initialize your network card, grab an IP address from DHCP (if enabled), then prompt you to enter a username. This is only required if you plan on mapping shared drives, and can be disabled if you do not wish to auto-mount drives at login. If you do plan to mount shared drives, go ahead and enter your username now (or just press Enter to accept what you specified during MS-Client setup), then enter the password for your account. If you do not plan to mount shared drives, press Enter, then press Enter again to setup a NULL password. In either case, choose Y to create a password list when prompted.
At this point, Microsoft's TCP/IP stack should be (mostly) up and running, using the NDIS driver. We can perform a few tests to confirm, but note that the utilities described below, though named the same as modern utilities, work differently than what you're probably used to (again, think "primitive").
First, verify that you have an IP address:
This should have been provided by DHCP, or should match the manual one you specified during MS-Client setup. Next, make sure you can ping your own IP, eg.:
The bottom line should say "echo received". Finally, make sure you can ping your gateway's IP address (this can be found in the ipconfig output):
Again, the bottom line should say "echo received". If all that worked, congrats, you're up and running!
However, there's one more major issue we need to take care of. Due to another bug in MS-Client, DNS does not work by default, nor is it possible to configure or enable it through the setup utility; this must be done manually.
To enable DNS, first edit
c:\dos\net\tcputils.ini and append the following:
[dnr] drivername=DNR$ bindings=TCPIP_XIF
If you are not using DHCP, also add the following below the bindings line:
nameserver0=aaa bbb ccc ddd nameserver1=aaa bbb ccc eee domain=domain.com
Substitute the appropriate values for your network, and be sure to separate the octets with spaces (as shown above) rather than periods as would be done on modern systems.
autoexec.bat and add the following line immediately above "net start":
Finally, run the above command now to start the Microsoft domain name resolver. The implements DNS functionality in MS-Client. You can verify DNS is working properly with ping again:
As before, you should get an "echo received", along with the IP address for www.google.com.
All of this work will now let us (finally) do something very important: map shared network drives. This is especially useful as we can use this to easily copy files and install new applications and drivers without floppy disks.
To map a drive, assuming you already have a shared drive properly configured in Samba or a Windows server (which is outside the scope of this HOWTO), run:
net use e: \\servername\sharename
Again, assuming everything has been properly setup on the server, and that you logged in with proper credentials, this should just work; you'll get a "command completed successfully" message if it did. To test, try running
dir e: and verify that you get output. If it doesn't as expected, and you followed all instructions above, the error is most likely on the server side. As noted, modern versions of both Samba and Windows no longer support DOS or Windows 3.x clients by default, and have to be run in a more insecure mode to make this work. I've had mixed results myself - on my initial testing with MS-Client (about three years ago), I was able to get this working perfectly with Samba; this time, however, I can't. If you have trouble with this, don't worry - SCP, SFTP, and NFS all work perfectly well for copying files using the PD interface, and are described in detail below.
The final bit of network setup we're going to do for the NDIS driver is installing a "shim" packet driver. The shim driver basically adds a PD interface to the NDIS driver. This is necessary if you want to use both Microsoft (including mapped drives) and non-Microsoft network utilities on the system (which is highly recommended).
Note that this shim driver is meant specifically for this purpose; it cannot drive your NIC directly without the NDIS driver, nor can your NIC's packet driver be used as a shim. Also, while the driver itself works great, the whole concept is a hack and as a result requires a manual and rather complicated setup process.
To begin, copy
c:\dos\net. Next, edit
c:\dos\net\protocol.ini and append the following:
[pktdrv] DriverName=PKTDRV$ BINDINGS=TCM$EL90X INTVEC=0x60 CHAINVEC=0x68
The BINDINGS line needs to be modified for your hardware; everything else (should) be able to stay the same. The BINDINGS line informs the packet driver of which NDIS driver it must bind to. To find this, search for the [TCPIP] section in
protocol.ini; it should also contain a BINDINGS line. Use the same driver name for the BINDINGS line under [pktdrv].
Save your changes to
protocol.ini and edit
config.sys next. Add the following after "ifshlp.sys":
DEVICEHIGH=c:\dos\net\protman.dos /i:c:\dos\net DEVICEHIGH=c:\dos\net\nemm.dos DEVICEHIGH=c:\dos\net\tcpdrv.dos DEVICEHIGH=c:\dos\net\el90x.dos DEVICEHIGH=c:\dos\net\dis_pkt.dos
Although it looks like you're adding a lot here, you're only going to be loading one new driver; the
dis_pkt.dos driver you just copied over. Everything else was already being loaded automatically by MS-Client, but due to some dependency issues you need to load them before dis_pkt, which in turn needs to be loaded before MS-Client.
Two additional notes:
We also need to edit autoexec.bat and change the following:
rem c:\dos\net\net initialize
net initialize loads all of the required drivers for MS-Client, which you're now doing manually through
config.sys. As a result, this command is no longer needed, and will in fact cause errors if you try to run it with the other drivers already loaded.
This is also a good time to decide whether or not you want to automatically map shared drives on boot. If you do not plan on using shared drives, or you prefer to map them manually each time they're needed (which can be done by simply running
net start), comment out the following line to save a fair amount of conventional memory:
rem c:\dos\net\net start
Finally, reboot to load the new driver. You should see the following message during the boot process to confirm the shim driver was loaded:
MAC/DIS to Packet Driver convert loaded.
Whether you installed the native PD or the NDIS PD shim, you won't be able to test network functionality using currently available utilities. The PD only provides an interface to your network card; each application using this interface must provide it's own network stack to talk TCP/IP, provide an IP address, etc. Most older applications do this by using the Waterloo TCP/IP stack (WATTCP), which can be embedded into the application and provides all necessary network functionality. A much newer TCP/IP stack called mTCP works similarly, and includes some additional utilities not (well) supported by WATTCP. Fortunately, both stacks can installed and enabled simultaneously, so we'll setup both.
To configure WATTCP, create
c:\apps\wattcp.cfg and add the following:
print = "Configuring WATTCP..." hostname = <hostname> my_ip = dhcp
If you use a static IP, remove the dhcp line above and add the following:
domain.suffix = localdomain my_ip = 0.0.0.0 netmask = 255.255.255.0 nameserver = 0.0.0.0 nameserver = 0.0.0.0 gateway = 0.0.0.0
Edit the values as appropriate, then save and close the file. Finally, add the following line to
Run the above command now to manually set the configuration variable. Next, let's install a couple diagnostic utilities. Copy
ping.exe from the WATTCP archive to
c:\apps (I suggest renaming ping to something like
pingw.exe to avoid conflicting with the Microsoft or mTCP version of ping).
To test our WATTCP configuration run
tcpinfo.exe. The top line should state, "Reading Waterloo TCP configuration file," which indicates that it was able to find your config file. The network parameters output by tcpinfo should either match your static configuration, or should be appropriate for your DHCP network. To test, try the following:
If you see "Replies lost: 0", everything's working.
mTCP works, and is configured, very similarly to WATTCP. You'll need to create another config file,
c:\apps\mtcp.cfg, and add:
packetint 0x60 hostname <hostname>
If you use a static IP, also add:
ipaddr 0.0.0.0 netmask 255.255.255.0 gateway 0.0.0.0 nameserver 0.0.0.0 mtu 1500
Edit the values as appropriate, then save and close the file. Finally, add the following to
set MTCPCFG=c:\apps\mtcp.cfg c:\apps\dhcp.exe
The only practical difference between mTCP and WATTCP (from and end-user's perspective) is that mTCP provides a separate DHCP client, whereas WATTCP applications do this themselves. If you are using a static address you can skip the dhcp line in
autoexec.bat. Run those
autoexec.bat line(s) now to initialize mTCP.
To test, copy
c:\apps (again I recommend renaming it to something like
pingm.exe to avoid conflicts) and run:
If you see a "Success: 100 %" message, everything's working.
It's time install a few essential network applications. Quite a few exist, but these are the ones I find most useful.
I primarily run Linux systems, so SSH is very important to me. As a bonus, SCP and SFTP provide great options for transferring files across the network, and is especially useful when NDIS/MS-Client is not setup or mapped drives do not work properly with modern Samba or Windows servers. Fortunately, there's an excellent SSHv2 implementation for DOS called, simply enough, SSH2DOS. It can be downloaded from the link above.
Installation is pretty simple; just copy and rename the following files as suggested:
copy scp2d386.exe c:\apps\scp.exe copy sftpd386.exe c:\apps\sftp.exe copy ssh2d386.exe c:\apps\ssh.exe
SSH2DOS is a WATTCP-based application, so it requires a PD interface and a working
wattcp.cfg file. If you setup both of these as instructed earlier, you're already good to go. Run
ssh username servername to verify SSH works as well.
SSH2DOS also includes a thoroughly commented example WATTCP configuration file. If you're having any trouble with your WATTCP apps, or you want to poke around to see what other options are available, take a look at the included
wattcp.cfg. If you decide to edit and use this version of the file, you can either replace the existing
c:\dos, or point the
WATTTCP.CFG variable in
autoexec.bat to the new location (but don't forget to update that variable as well, or reboot, or your apps will continue to use the old configuration file).
wget is another useful utility. This is a command line download manager that can download files from pretty much any web or FTP server and, happily, there's a DOS version available from the link above (though the DOS version is no longer maintained at this point).
Installation is the same as SSH2DOS;
copy bin\wget.exe c:\apps and you're done. This is another WATTCP-based application, so it should just work at this point.
Now let's install some mTCP applications. These are all bundled with the mTCP distribution, so just copy the following files to
Each of these will utilize your mTCP configuration file so you can go ahead and use them directly. FTP and TELNET should be fairly self-explanatory and work how you'd expect, with FTP being especially useful if you run Windows on your main machine and don't have SSH available. The utility I'm most interested in here, though, is SNTP, a simple Network Time Protocol client. You can use this to automatically set your computer's clock to the correct current time, which is very handy on ancient computer hardware with bad CMOS batteries. :-) To test this, run the following:
set TZ=CST6CDT sntp.exe pool.ntp.org
Note: TZ stands for time zone, and is required so that SNTP knows the correct 'local' time. CST6CDT is the code for the Central Standard Time zone; see
sntp.txt for additional information about how to set this.
After running the above, you should see your current system time as well as the current NTP server time (listed as "Time should be set to"). To actually set the time, use the
-set parameter. To always set your system clock to the appropriate time on boot (strongly recommended), add the above, with
Bonus tip: once you get the mTCP utilities installed, try running
telnet towel.blinkenlights.nl for an unexpected treat. :-)
Note: There are several additional applications/utilities included with both WATTCP and mTCP, but the above are the ones I personally find most useful. Feel free to play around with the others, though.
If you run an NFS server instead of (or in addition to) an SMB/CIFS server, you'll be happy to know that it is possible to mount an NFS share from DOS. The bad news is that you lose the ability to concurrently use many (but apparently not all) other PD-based applications. The reason is that XFS installs it's own driver literally on top of your packet driver, which conflicts with most other PD applications. wget (for whatever reason) still works with the XFS driver loaded, but none of the other WATTCP- nor mTCP-based utilities can use it.
If you only otherwise use NDIS-based applications, this is not an issue. If you only use PD-based applications, theoretically you should be able to get them to work with the XFS driver loaded by configuring them to use interrupt vector 0x62 instead of 0x60 (search for "redirected PKTDRVR" in
xfs.txt), but I could not get that to work. See the end of this section for an alternative approach that you can use instead. If you need to use both NDIS- and PD-based applications, you're pretty much out of luck; you need to choose one or the other at this point (or, of course, not use NFS).
So here's the deal with NFS under DOS: there's an old version of NFS for DOS called XFS Network File System Client. It was a commercial program, but as noted above it's long since been abandoned, so grab a copy if you're so inclined and let's get to work.
Note: Before installing, take a look at
kernels.txt, which describes the different kernel drivers available. I use the minimal kernel, XFSKRNLM, because that meets my needs and takes up the least amount of memory, but your needs may vary.
Installation is a bit tricky:
xfskrnlm.exe hosts ls.exe xfstool.exeThe rest of the executables can be useful for troubleshooting NFS connections, but shouldn't be required for routine use. I also recommend renaming
lsx.exeto avoid conflicting with the 4DOS alias for
aaa.bbb.ccc.ddd nfsserver.domain.com nfsserver
nfsclientis the name of your DOS system and the IP information applies to your network configuration:
aaa.bbb.ccc.eee gateway aaa.bbb.ccc.ggg netmask aaa.bbb.ccc.fff broadcast aaa.bbb.ccc.ggg nfsclient.domain.com nfsclient
config.sys. Add/change the following:
rem DEVICEHIGH=c:\dos\net\dis_pkt.dos DEVICEHIGH=c:\dos\net\dis_pkt9.tcpNote that this disables the old packet driver and loads the new one provided by XFS. Reboot here if using NDIS before continuing.
loadhigh c:\apps\xfskrnlm.exe 0x60
xfstool init bootp
nfsclientmust be defined as described above):
xfstool init nfsclient
xfstool mount f: nfsserver:/home/data/files
Note that XFS requires a local hostname to be set. If you're using a static IP address, this should be taken care of. If you're using BOOTP, your DHCP server has to be configured to supply a hostname in addition to an IP address to your system. If XFSTOOL complains about a hostname not being set, this is probably what's happening. The easiest workaround would is to configure a static IP address for XFS, as described above.
If everything worked, you should be able to do run
dir f: and see a list of files on your NFS server. Switch to F: and run
lsx) to see the long file names. If using NDIS, I also recommend testing an NDIS application to ensure the shim driver is working properly.
ping hostname should do the trick, but a more thorough test would be to map a shared drive, eg., with
If you want to automount any NFS shares on boot, add the three XFSKRNL, INIT, and MOUNT commands shown above to
autoexec.bat. Be sure it's added after any other PD applications included in
autoexec.bat, such as mTCP's DHCP client, or the other applications will fail for the reasons listed above.
As mentioned previously, it's not possible to (reliably) use XFS with other PD applications. However, XFS provides the ability to temporarily unload and then reload it's PD shim as needed, so you can leverage this to run other PD applications without completely tearing down NFS support or rebooting. As an example of how to do this, say you want to SSH to another system while you have an NFS share mounted; you can do this by calling the following additional commands before and after SSH:
xfstool pktdrv stop ssh username hostname xfstool pktdrv restart
While in the "stopped" state, your mounted shares will still exist but will not be accessible. Issuing the restart will make them available again. It's not ideal, but it's a fairly reasonable compromise, and can be made less annoying by using a 4DOS alias to simplify that much more (see the 4DOS section below).
Relevant Software and Drivers:
Whew, now that we're finally finished with networking, everything else should be a breeze in comparison. :-) Since we now have an easy way to transfer files to our DOS system, it's time to install our remaining drivers and applications. Let's start with the CD-ROM drive.
Microsoft does not include a CD-ROM driver by default with DOS, and it's difficult (if not impossible) to get a DOS CD-ROM driver from manufacturers today. Fortunately, though, a few generic CD-ROM drivers exist that should cover most standard IDE/ATAPI CD/DVD-ROM drives.
The most widely compatible and widely used MS-DOS CD-ROM drivers are probably from Oak Technologies and Gold Star, both available from the Computer Hope hardware downloads page. Unfortunately, both are memory hogs; the Gold Star driver consumes 25 KB, while the Oak driver consumes a whopping 35 KB. As an alternative I recommend the Toshiba driver linked above. This driver should offer roughly the same compatibility and capabilities, but only uses a svelte 7 KB of memory.
Acer's ATAPI CD-ROM driver (search for VIDE-CDD.SYS v2.15 on the linked page) is another option that uses only 5 KB, as is the modern UDVD2 driver for the FreeDOS project which uses, I think, less than 1 KB. Unfortunately, the UDVD2 driver doesn't behave well on a physical MS-DOS system, and I had some reliability issues with VIDE-CDD.SYS while installing and testing some classic games, so I'd recommend sticking with Toshiba's CDROMDRV.SYS driver.
To install the driver, copy
c:\dos. Then, edit
config.sys and add:
/d option sets a device name to be used by MSCDEX; you can set anything you want here, but mscd001 is the standard name and there's no real benefit to changing it. Next, edit
autoexec.bat and add:
loadhigh c:\dos\mscdex.exe /d:mscd001
MSCDEX acts as an interface for DOS to communicate with the CD-ROM driver and, in turn, the device itself. Reboot to load the new driver. If both the driver and MSCDEX were loaded properly, you'll see the following message in the output while the system is booting:
Drive D: = Driver MSCD001 unit 0
Try inserting a CD-ROM and entering
dir d: to verify MSCDEX was able to see it as well.
Next we'll install a mouse driver. This is optional, as DOS itself doesn't utilize mice, only the applications programmed to support them (such as Pedit). So, unless you plan on running an application or game that uses a mouse, you can skip this.
As with CD-ROM support, MS-DOS doesn't include a mouse driver by default. And again like CD-ROM support, we have a couple options to choose from. The first option is to use the original mouse driver provided by Microsoft with Windows 3.x. This is called MOUSE.COM, and can again be downloaded from the Computer Hope hardware downloads page. The second option is a much newer, open source mouse driver called CuteMouse. It's still actively developed for the FreeDOS project and available from the site linked above.
CuteMouse provides support for modern mice and mouse features such as wheels (though few applications support the wheel), and is significantly smaller than MOUSE.COM, using only about 3.5 KB of memory vs. almost 18 KB for MOUSE.COM. I strongly recommend CuteMouse here, and will use it for the example, but you're welcome to use MOUSE.COM if preferred.
To install CuteMouse, copy
c:\dos. Then, edit
autoexec.bat and add:
CuteMouse supports quite a few options, so run
ctmouse.exe /? to get a complete list and set the options appropriate for your hardware. Auto-detection should generally work fine, though. In my case, I use
/3 to force 3-button mode, which isn't enabled by default. Also, note that we're not specifying LOADHIGH here; CuteMouse is smart enough to load itself into upper memory when available, so LOADHIGH isn't needed.
Run the above command to manually load the driver. Pedit supports mice, so you can fire that up to verify that your mouse was properly detected and enabled, or use the included
Next up is sound. You'll need to install drivers appropriate for your sound card. I have a Creative Labs Sound Blaster AWE64, so that's what I'll setup in the example. Your setup should be at least somewhat similar, but certainly some of the details will be different.
To begin, unpack and copy over both the driver disk and configuration manager (linked above), then change to the driver disk directory.
c:\apps\ctcm. Verify the suggested settings are sensible and hit Enter to continue.
c:\apps\awe64. Again, verify the suggested settings are sensible and hit Enter to continue.
We'll need to reboot to activate the sound card, so do that now. After rebooting, change to
c:\apps\awe64 and run
diagnose.exe. This will let you verify that your sound card is installed and working properly. While here, you can also run
mixerset.exe to adjust the volume levels as necessary. I find the default config too loud (leading to noticeable distortion on my speakers), so I turn the Master volume down a couple clicks. You may also like to try enabling 3DSE (3D Stereo Enhancement) and see if that improves the sound; I generally don't care for this, but it can make a positive difference with cheap stereo or embedded monitor speakers.
At this point it's time to do some configuration cleanup and memory optimization. Remember, you can use
mem /c /p to view current memory usage and availability. My system, after installing everything listed above and despite tweaking the config files a bit, currently has only 497 KB of conventional memory available. This is actually pretty decent given everything I have loaded, but unfortunately it's not enough for some of the other programs I want to install, and definitely isn't large enough for many games. Generally, you should shoot for >530 KB free, which should cover most (though not all - 587 KB is the highest I've personally encountered) DOS applications and games.
For reference, here's my
config.sys file at this point:
REM configure boot options SWITCHES=/f REM enable memory management DEVICE=c:\dos\himem.sys /testmem:off DEVICEHIGH=c:\dos\emm386.exe ram 24576 highscan notr i=b000-b7ff DOS=high,umb REM load device drivers DEVICEHIGH=c:\dos\cdromdrv.sys /d:mscd001 DEVICEHIGH=c:\dos\net\ifshlp.sys DEVICEHIGH=c:\dos\net\protman.dos /i:c:\dos\net DEVICEHIGH=c:\dos\net\nemm.dos DEVICEHIGH=c:\dos\net\tcpdrv.dos DEVICEHIGH=c:\dos\net\elnk3.dos DEVICEHIGH=c:\dos\net\dis_pkt.dos DEVICEHIGH=c:\dos\ansi.sys DEVICEHIGH=c:\dos\power adv:min DEVICE=c:\apps\ctcm\ctcm.exe rem DEVICEHIGH=c:\dos\setver.exe REM configure environment SHELL=c:\dos\command.com c:\dos /p FILES=30 BUFFERS=5,0 FCBS=1 STACKS=0,0 LASTDRIVE=H BREAK=on
@echo off REM setup display and drivers c:\dos\mode.com con cols=80 lines=50 loadhigh c:\dos\mscdex.exe /d:mscd001 loadhigh c:\dos\smartdrv.exe loadhigh c:\apps\doskey.com -i c:\dos\ctmouse.exe /3 REM setup network rem loadhigh c:\dos\3c5x9pd.com 0x60 rem c:\dos\net\net.exe initialize c:\dos\net\netbind.com c:\dos\net\umb.com loadhigh c:\dos\net\tcptsr.exe loadhigh c:\dos\net\tinyrfc.exe c:\dos\net\nmtsr.exe loadhigh c:\dos\net\emsbfr.exe loadhigh c:\dos\net\dnr.exe c:\dos\net\net start REM setup sound card set SOUND=c:\apps\awe64 set BLASTER=A220 I5 D1 H5 P330 E620 T6 set MIDI=SYNTH:1 MAP:E MODE:0 set CTCM=c:\apps\awe64\ctcm c:\apps\awe64\diagnose.exe /s c:\apps\awe64\aweutil.com /s c:\apps\awe64\mixerset.exe /p /q c:\apps\ctcm\ctcm.exe /s REM setup environment path c:\apps;c:\dos;c:\dos\net prompt $e[1;34m$p$g $e[0;47;0m set DIRCMD=/o:gne set TEMP=c:\temp set WATTCP.CFG=c:\dos\net echo.
Most of this has been covered previously, but there are a few new items:
24576instructs EMM386 to only make 24 MB of extended memory (out of the 64 MB of RAM available on this system) available as EMS. By default, it'll use all available extended memory, up to 32 MB. I added this mostly for troubleshooting: if a game reports that it sees 24 MB of memory, then that means it's using EMS and not XMS.
highscanenables more aggressive attempts to find available upper memory (and this increase available capacity), though it can cause some systems to hang.
notrdisables searching for token ring adapters, a legacy networking topology no longer in use today.
adv:minenables power management support, but with a bias for performance. You can run
help power.exefor information about more advanced options if interested. Tip: You definitely want to enable this option if running DOS in VirtualBox or VMware; without it, DOS runs "wide open" and will suck up 100% of the CPU core assigned to that virtual machine.
help <option>) for each for more details. Each should generally be set as low as possible to reduce memory, without going too low as to adversely affect your system. I find the settings above provide a good balance for my system.
$p$g, which shows
c:\path>. My tweaked version shows the same information, but the prompt is now blue instead of white. See the ANSI.SYS help file for additional information.
Startup order is very important under DOS; loading drivers and programs in the "wrong" order can drastically increase memory usage. Unfortunately, there's no way to guarantee an optimal order. You can find a lot of advice about tweaking MS-DOS memory settings on the internet, but the basic advice I've found that works the best boils down to three parts:
MS-DOS also includes a utility called MEMMAKER that can help optimize settings for memory usage, but it produced slightly worse results than my hand-tweaked files above. I recommend giving it a shot, though; it may work better on your hardware, and even if it doesn't it provides an option to easily undo the changes.
With all that said, I'm still about 35 KB below my target of 530 KB, and this is already optimized. In order to hit 530 KB I'll need to disable some things. Good candidates:
c:\dos\netstuff from both config files (including the shim driver) to free up oodles of space. Note that you'll lose your PD interface as well if you installed the shim driver, so you'll need to (re)setup your NIC's native packet driver if you want to continue to use non-Microsoft network utilities. if you can get by with only using PD applications, this is a great option.
I elected to disable MS-Client and just load the native packet driver, which took me way beyond my target to 576 KB free. Aside from mapped drives, MS-Client provides almost no benefit to a home user over the PD applications, and even mapped drives is very flaky with recent versions of Samba. SCP/SFTP will meet my file transferring needs, even if it's slightly less efficient, and that extra memory will be put to much better use elsewhere.
At this point, I'd consider the base OS install to be complete. We have a tuned and optimized MS-DOS 6.22 system complete with network support and key network utilities. Everything we installed should be very stable and functional, and should, for the most part, be usable under Windows for Workgroups 3.11 as well (we'll probably swap out our network drivers, but that's a later discussion). Using this base, you can install additional applications, games, utilities, drivers, etc. to customize the system to your tastes. I'll cover a few of the more useful or interesting additions I've found here.
4DOS is a replacement shell / command interpreter for DOS. It provides a great many significant enhancements over the default DOS shell, command.com, and is amazingly customizable. To read up on it and download a copy, visit it's home page.
4DOS was originally a commercial program, but has since been discontinued and released as open source. The open source version (called "Free 4DOS"?) seems to still be actively maintained (though it hasn't been updated in a while) and is currently at version 8.00; this is the version you'll want to download from the above site.
Basic installation is quite easy. Copy the entire (unzipped) directory to
c:\apps\4dos, then run
c:\apps\4dos\4dos.com and follow the prompts. You can choose to have it automatically update
config.sys for you, but for some greater control you can enter
N and manually make the following changes. Edit
autoexec.bat and add/change:
rem loadhigh c:\apps\doskey.com -i c:\apps\4dos\kstack.com
config.sys and add/change:
rem SHELL=c:\dos\command.com c:\dos /p SHELL=c:\apps\4dos\4dos.com c:\apps\4dos /p
4DOS includes tab completion and command history by default, so Enhanced DOSKEY.com is no longer necessary (although 4DOS doesn't support command completion; that is, searching your path and completing commands as they're typed. That's a bummer.) Also, note that KSTACK.COM is only needed if you wish to use 4DOS' KEYSTACK command. Run
help keystack. If you don't need this, comment out the kstack.com line to free up that memory.
You can run
option.exe to configure the basic 4DOS settings. There are a lot to play with, but I personally like to set the following non-default options:
One handy feature 4DOS provides is the ability to use aliases. If you're familiar with the concept from Linux, it works similarly; if no, it's easiest to see it in action. Enter
alias ls=dir /wbh, then enter
ls. You should get a directory listing in the same style as the default
ls command on Linux. This is a pretty trivial example, but you can use it to provide a number of useful conveniences. For example, here's my
dir=*dir %dircmd ls=dir /wbh rm=del mv=move cp=copy cat=type date=echo %_DATE %_TIME eject=ejectmedia vi=edit p=xfstool.exe pktdrv stop ^ %1 %2 %3 %4 %5 %6 %7 %8 %9 ^ xfstool.exe pktdrv restart moved=mkdir %2\%@NAME[%1] ^ xcopy /e %1 %2\%@NAME[%1] ^ deltree %1 realias=unalias * ^ alias /r d:\etc\aliases.cfg
Many of the above are simple shortcuts, but a few deserve special mention:
pto any command, 4DOS will first unload the XFS packet driver, then run the given command, then reload the XFS packet driver; so, you can run
p ssh username serverto SSH to a server even while an NFS share is mounted, and 4DOS will automatically suspend/restart the driver before and after your SSH session
It isn't necessary to use an alias file, but I find it convenient to keep all alieses grouped together. To load, add
alias /r c:\apps\aliases.cfg, or whatever path you prefer, to
Another neat, but this time entirely superfluous, trick is to enable support for colored directory listing output. This is similar to what modern Linux distributions do by default (as shown in this simple example if you're not familiar with it), and makes it possible to quickly and easily recognize common file types at a glance. I modeled the following configuration based on Linux's default scheme for dircolors, with a couple differences and pruned down a bit:
ColorDir=dirs:bri blue;hidden:bri bla;exe com dos:bri gre;bat btm cmd:gre;zip tgz:bri red;jpg gif bmp png ico:bri mag;mov mpg:mag;mid mp3 wav:bri cya;txt doc me now 1st diz cfg inf ini:bri yellow;*~* bak:yel
The configuration is fairly straightforward, if a bit terse: in order, you specify:
There are a couple additional points to be aware of. The extension list can also be a special type of file, such as
hidden (hidden files),
rdonly (read-only files), etc. So, the first item in the line sets my directories blue. The color code is also fairly flexible; as shown above, you can specify both normal colors (
yel) and bright colors (
bri yel) (bright colors tend to be easier easier to read against dark backgrounds). You can also change the character background color:
bri blu on yel, for example, will display blue text on a yellow background.
You can run the above with the
set command to activate, then run
dir to test the results. Feel free to customize it a bit, then once you're happy with it you can make it permanent by either adding it to
autoexec.bat (again, prepended with
set) or copying it as-is to
c:\4dos\4dos.ini. I recommend the latter, as it won't clutter up your environmental variables.
For more advanced 4DOS features, refer to the online documentation by running
help. Also note: if you want to view the original MS-DOS help pages, you'll now need to run
Believe it or not, a GUI web browser is available for DOS. Support for modern web standards is quite limited, as should be expected, but basic web browsing should work pretty well. The name of the browser is Arachne, and it can be obtained from it's home page. After a four year hiatus, it very recently had a new release, so it's good to see that it's still under active development.
Installation is a bit involved, but not too complicated. The largest hurdle is that this requires at least 500 KB of free conventional RAM, and if you installed everything listed in this walkthrough so far, you will almost certainly be under that threshold. Please see the above System Optimization for tips on freeing up enough memory i fnecessary. You'll also want to use a mouse for this, so be sure to follow the mouse driver instructions above to get that setup.
mem /c /p shows >500 KB free of conventional memory, run
a197gpl.exe to begin the setup process and then follow the prompts. I recommend installing to
c:\apps\arachne to follow our installation convention, so press
N when asked and change the directory before continuing.
After everything is unpacked, the GUI setup process will start. If you have just barely more over 500 KB free, the installer will exit with a low memory error, as the memory from the unpacker was still in use at the time, pushing you under the threshold. If this happens, simply run
c:\apps\arachne\arachne.bat to restart the GUI setup wizard.
Set the video options to your preference. Try to go with at least 1024x768, higher if possible (and you have a reasonably large monitor), but you'll probably be limited by your video card memory. If you have any trouble and need to abort the setup process, you can restart by running
You'll be prompted to set your computer speed profile next; it's probably best to go with Arachne's recommended setting here, as it will do a quick benchmark of your computer first. Select your preferred option and click Next. You'll then be prompted for some system configuration changes. This is entirely personal preference (I prefer to update my files manually after installation, but I do have it create the shortcut batch file for me), so choose what you like and click Next. Set the max video resolution to the same resolution you selected previously and click Next.
Up next is the network configuration. Since we already have a working WATTCP configuration (...right?), choose Manual Setup. Select "Resident packet driver", then select "Use only WATTCP configuration", then set the WATTCP configuration file name to
c:\apps\wattcp.cfg and click Save.
The next page, Arachne Options, can be configured at any time later on to your preferences, so click "Use new settings" to complete setup. You'll be kicked back into DOS at this point, so now would be a good time to make any system config file changes. Consider changing the following in
config.sys, if you didn't have Arachne do it for you earlier:
If you had Arachne create a shortcut, you can move it to
c:\apps so that it's in your PATH. I also like to rename it back to arachne:
move c:\apps\arachne\a.bat c:\apps\arachne.bat. If you changed your FILES setting, you'll probably want to reboot now to have that take effect.
arachne.bat and try loading a website such as www.google.com to verify connectivity. It won't look very pretty, but you should see all of the content in its complete, barely styled glory. :-)
Arachne supports a ton of layout options, performance options, etc., and I strongly suggest you spend some time tuning it to make it a better experience for you. To get started, click on the Desktop link in the right navbar (or press
F10), then click Options.
This is a fairly random collection of utilities I found while researching this project that I consider useful or interesting. I won't cover them in great detail, but I do recommend checking them out.
Navrátil Software System Information is a comprehensive system information utility, reporting detailed information about the various components in your system. This is by far the best such utility I've found, is one of the only such utilities that is completely free and not crippled, and is even under reasonably active development. As a bonus, it even can even perform a basic CPU benchmark. If you have any questions about what's in your computer or how it's performing, this is a very worthwhile utility.
Snarf is a simple screenshot utility for DOS. It doesn't support much in the way of options, but it works well in my testing. Screen Thief is another screenshot utility. This one has far more options, but for some reason saves images as 720 pixels wide rather then 640, which makes everything look stretched horizontally. That seems to be expected behavior and I can't find a way to fix that, and that's a deal breaker for me.
RMENU, in the author's words, is a "'kind of' a telnet server for DOS... that can be used to remotely control a computer running DOS via telnet," providing a menu-driven interface as well as direct command line access. Since this is of somewhat limited practical use I won't spend much time covering the details, but it's a quite nice remote-access solution if that's something you need. A couple other options that might fit the bill are Remoter and Tiny. Unfortunately, Remoter which requires a separate Windows client, so it's not useful for me, and Tiny requires either the Novell or PCTCP TCP/IP stack (yes, there are even more network stacks and options that what I covered above...), so can't be used with the network configuration detailed above. So, RMENU is the best option for my situation. The RMENU author has also written a number of additional DOS applications that may be useful, also available from the same link.
ANSIPLUS is a much enhanced re-implementation of the ANSI.SYS driver discussed above, and includes several features that would ordinarily require separate additional utilities, such as a scroll back screen buffer, extended keyboard input buffer, mouse support for console copy/paste, etc. Installation and configuration is a bit wonky, so I recommend reading the included
ansiplus.doc manual before getting started.
SLOWDOWN is, as the name implies, a utility to slow your computer down. It's useful for very old software (generally games) that run relative to CPU speed. The problem with these games is that they will always run faster as CPU speed increases, so once you reach a certain CPU speed (which can be easily hit even with original Pentiums), games become unplayably fast. There are several utilities that can slow your computer down enough to play these games (Mo'Slo probably being the most well known), but my favorite is SLOWDOWN; it's free, has a wealth of features, and is very well documented. In particular, I recommend checking out the included CPUCACHE utility; this can be used to simply disable your CPU's cache, yielding a significant drop in speed. While testing Wing Commander, I found the using CPUCACHE resulted in the most consistent gameplay speed. The SLOWDOWN author also has several additional utilities on his site, including native DOS USB drivers, worth checking out.
After spending a while playing with the system and, most importantly, playing and installing many of my original DOS games, I have a couple few extra tips I wanted to share.
ramoption) as part of your standard config. Running EMM386 without EMS support (using
noemsshould be avoided as many games will assume that EMS available simply because EMM386 is running and then crash. If you want run a game that uses XMS memory is used, the most reliable option is to simply not load EMM386; this will ensure it uses XMS without any potential conflicts caused by EMM386, but has the unfortunate side-effect of preventing DOS from loading drivers/components into upper memory, which means you'll have less conventional memory available for the game.
I ran into a couple odd problems while testing all of my games that were traced back to the somewhat aggressive settings I had for FILES, STACKS, etc. I'm now using the following more conservative settings:
FILES=40 BUFFERS=10,0 FCBS=1 STACKS=9,128
This uses an extra few KB of conventional memory, but has resulted in less random application crashes. Now that I'm using boot menus as described below to re-configure my system as necessary for memory hungry games, I can afford to give up a few KB of RAM here, so the aggressive settings aren't really worth it.
Additionally, MSCDEX and SmartDrive can both be tweaked to provide faster performance and utilize less conventional memory as shown below:
loadhigh c:\dos\mscdex.exe /d:mscd001 /l:f /e /m:30 loadhigh c:\dos\smartdrv.exe 4096 4096 /b:65536 /e:8192 /u
For MSCDEX, the
/e parameter instructs it to utilize expanded memory, and
/m:30 causes it to cache up to 30 buffers, reducing the amount of direct CD-ROM reads your computer needs to make and this increasing CD-ROM performance. Note that EMM386 is required for this; without it,
/e cannot be used, and
/m:30 will result in a significant increase of conventional memory use; dropping
/m to 5 or 10 in these circumstances is recommended.
SmartDrive is a bit more complicated. I recommend reading the SmartDrive help page for more details, but the short version is that the above command instructs SmartDrive to always use 4 MB of extended memory for cache, use a read-ahead buffer size of 64 KB, use an element size of 8 KB, and disable support for caching CD-ROM drives. The
/u option is particularly important - while it seems like caching CD-ROM drives would be a good thing, it has a tendency to corrupt the CD in the process of copying a large number of files. I had issues installing quite a few games because of this, so using
/u to disable CD-ROM caching while allowing SmartDrive to continue to cache all hard drives is the easiest and most reliable solution. The other options, as mentioned for MSCDEX, all affect memory usage, and without upper memory available from EMM386 this will make SmartDrive consume a large amoutn of conventional memory. Dropping it down to something like
2048 2048 /b:8192 /e:4096 can help a lot in these situations, and you may need to go even lower for particularly memory hungry games.
MS-DOS 6.0 introduces support for boot menus, which can be used to select and load different system configurations at boot time. This is handy because it let's you easily change system settings by rebooting and choosing the new configuration rather than modifying
autoexec.bat each time you want to change something. This generally isn't really needed, but it can be useful on a system with multiple games loaded to easily switch between sometimes configurations needed by each different game, eliminating the need for bootdisks and hand-editing each time you want to play a different game.
The DOS 6.2 CONFIG.SYS Menu's for Dummies guide explains how boot menus work pretty well, and includes example
autoexec.bat files to show how it's done and to show how you can use the boot menu (handled by
config.sys to also affect what's loaded by
For a much more complicated example (probably unnecessarily so), I'm providing my latest
autoexec.bat files below. Few notes about this:
autoexec.batwill automatically run a custom game launcher I wrote (
games.bat) at the end of the process. The
%CONFIG%variable contains the name of the menu item chosen at boot, so it can be used by both
games.batto determine which drivers/utilities should be loaded and which game(s) should be run.
With that said, here's my fully tricked out
config.sys with boot menu:
REM Configure boot menu [menu] menuitem=default,Load standard MS-DOS 6.22 working environment submenu=games1,Load gaming-optimized environment menudefault=default,5 REM prompt for game-focused options [games1] submenu=games2,Basic optimizations - Disable EMS, disable CD-ROM menuitem=noemscd,Wing Commander III/IV, Crusader, SkyNET - Disable EMS, enable CD-ROM menuitem=noemscdextreme,Privateer 2 - Disable EMS, enable CD-ROM, extreme optimization menuitem=emsextreme,Wing Commander I/II - Enable EMS, perform extreme optimizations menuitem=emscdnomnosd,Tomb Raider - Enable EMS and CD-ROM, Disable Mouse and SmartDrive REM prompt for additional game options [games2] menuitem=basic,All other games - Basic optimizations only menuitem=noemsnosd,Dark Forces - Disable SmartDrive menuitem=noemsextreme,Privateer 1 - Perform extreme optimizations REM common boot/memory settings - always enable XMS [common] SWITCHES=/f DEVICE=c:\dos\himem.sys /testmem:off REM Enable EMS for default environment or games that require it [default] DEVICE=c:\dos\emm386.exe ram 24576 highscan notr i=b000-b7ff DOS=high,umb DEVICEHIGH=c:\dos\power.exe adv:min INSTALLHIGH=c:\apps\ansiplus\ansiplus.exe /e DEVICEHIGH=c:\dos\cdromdrv.sys /d:mscd001 SHELL=c:\apps\4dos\4dos.com c:\apps\4dos /p [emsextreme] DEVICE=c:\dos\emm386.exe ram 24576 highscan notr i=b000-b7ff DOS=high,umb SHELL=c:\dos\command.com c:\dos /p [emscdnomnosd] DEVICE=c:\dos\emm386.exe ram 24576 highscan notr i=b000-b7ff DOS=high,umb DEVICE=c:\dos\cdromdrv.sys /d:mscd001 DEVICEHIGH=c:\dos\ansi.sys SHELL=c:\apps\4dos\4dos.com c:\apps\4dos /p REM Disable EMS for all other games [basic] DOS=high DEVICE=c:\dos\ansi.sys SHELL=c:\apps\4dos\4dos.com c:\apps\4dos /p [noemscd] DOS=high DEVICE=c:\dos\ansi.sys DEVICE=c:\dos\cdromdrv.sys /d:mscd001 SHELL=c:\apps\4dos\4dos.com c:\apps\4dos /p [noemscdextreme] DOS=high DEVICE=c:\dos\cdromdrv.sys /d:mscd001 SHELL=c:\dos\command.com c:\dos /p [noemsnosd] DOS=high DEVICE=c:\dos\ansi.sys SHELL=c:\apps\4dos\4dos.com c:\apps\4dos /p [noemsextreme] DOS=high SHELL=c:\dos\command.com c:\dos /p REM Configure remaining drivers and default environmental settings [common] DEVICE=c:\apps\ctcm\ctcm.exe FILES=40 BUFFERS=10,0 FCBS=1 STACKS=9,128 LASTDRIVE=H BREAK=on
And, the corresponding
@echo off :: Configure environment based on config.sys menu selection goto %CONFIG% :: For default working environment, load all conveniences :default c:\apps\ansiplus\setaplus.exe mode 03h height 8 rate 30 delay 1 loadhigh c:\dos\mscdex.exe /d:mscd001 /l:f /e /m:30 loadhigh c:\dos\smartdrv.exe 4096 4096 /b:65536 /e:8192 /u c:\dos\ctmouse.exe /3 /o prompt $e[1;34m$p$g $e[0;47;0m alias /r d:\etc\aliases.cfg goto network :: For gaming environment, load memory-optimized configuration :basic c:\dos\mode.com con: cols=80 lines=50 rate=32 delay=1 c:\dos\smartdrv.exe 2048 2048 /b:32768 /e:8192 /u c:\dos\ctmouse.exe /3 /o prompt $e[1;34m$p$g $e[0;47;0m alias /r d:\etc\aliases.cfg goto finish :: Otherwise, apply more specialized settings :noemscd c:\dos\mscdex.exe /d:mscd001 /l:f /m:20 c:\dos\smartdrv.exe 4096 4096 /b:32768 /e:8192 /u c:\dos\ctmouse.exe /3 /o prompt $e[1;34m$p$g $e[0;47;0m alias /r d:\etc\aliases.cfg goto finish :noemscdextreme c:\dos\mscdex.exe /d:mscd001 /l:f /m:5 c:\dos\smartdrv.exe 2048 2048 /b:2048 /e:1024 /u c:\dos\ctmouse.exe /3 /o prompt $p$g goto finish :emsextreme loadhigh c:\dos\smartdrv.exe 4096 4096 /b:32768 /e:8192 /u c:\dos\ctmouse.exe /3 /o prompt $p$g goto finish :emscdnomnosd c:\dos\mscdex.exe /d:mscd001 /l:f /m:20 prompt $e[1;34m$p$g $e[0;47;0m alias /r d:\etc\aliases.cfg goto finish :noemsnosd c:\dos\ctmouse.exe /3 /o prompt $e[1;34m$p$g $e[0;47;0m alias /r d:\etc\aliases.cfg goto finish :noemsextreme c:\dos\smartdrv.exe 2048 2048 /b:4096 /e:2048 /u c:\dos\ctmouse.exe /3 /o prompt $p$g goto finish :: Load network drivers and configure protocol stacks :network echo. echo Initializing 3Com 3C509B-TPO... loadhigh c:\dos\3c509.com -p 0x60 >nul echo. echo Setting mTCP IP address via DHCP... set MTCPCFG=d:\etc\mtcp.cfg set TZ=CST6CDT c:\apps\dhcp.exe >nul echo Setting system time via NTP... c:\apps\sntp.exe -set boxdog.legroom.net >nul set WATTCP.CFG=d:\etc goto finish :: Configure remaining common drivers and environmental variables :finish echo. echo Initializing Creative Labs Sound Blaster AWE64... set SOUND=c:\apps\awe64 set BLASTER=A220 I5 D1 H5 P330 E620 T6 set MIDI=SYNTH:1 MAP:E MODE:0 set CTCM=c:\apps\ctcm c:\apps\awe64\diagnose.exe /s >nul c:\apps\awe64\aweutil.com /s >nul c:\apps\awe64\mixerset.exe /p /q c:\apps\ctcm\ctcm.exe /s >nul unset CTCM path c:\apps;c:\dos set DIRCMD=/a/o:gne set TEMP=c:\temp echo. :: Run games launcher automatically if appropriate if not %CONFIG%==default c:\apps\games.bat %CONFIG%
Finally, for the curious, you can also obtain my
games.bat file. It's fairly basic, but does show how you can prompt for basic user input and take action based on that input from a pure MS-DOS system, so it might be handy as a reference if you're not sure how to do that.
With that I think we're finally(!) done. I hope this inspires a few folks to tinker a bit with some of their old hardware, or at least fire up a DOS session under VirtualBox or something, and experience either anew or for the first time the joy of getting MS-DOS configured just right for whatever your needs might be. Computing was very different when MS-DOS 6.2 was released back in 1993, twenty years prior to the time this was written, and it's worth remembering that sometimes to better appreciate just how far we've come today.
Hope you enjoyed.