If you have trouble navigating this page via WWW, use ftp:
http://ftp.oldskool.org/pub/tvdog/internet/The programs are in that directory. File README is this page in plain text format.
If you're not comfortable writing batch files, dialing scrips, and so forth, the best thing to do is get a shell account on your provider's machine, which is a much easier way to get on the Internet with an old machine. The only software you need for that is a communications program (Qmodem, Procomm, and Telix are a some good ones). The comm program should support VT100 emulation. The provider will have text-based programs you can use for WWW (Lynx), telnet, ftp, gopher, and other services. You don't need any special information for a shell account (maybe a book on Unix would help); it works like any BBS.
Before you try to dial your ISP and connect to them, you need to verify that you've got your modem set up right by calling into a regular BBS with some standard communications software. Your modem probably came with a communications program, and your modem's manufacturer probably has a BBS whose number is in the manual, so try calling them. (If you don't know the number of a BBS to call, Cardinal's BBS is 1-717-293-3074. If you don't have communications software, check a large DOS software site like http://ftp.simtel.net/pub/simtelnet/msdos/ .)
You will need to give an init string for your modem when you set up the dialing script for your packet driver or its dialer. For newer modems, "AT&F0" will work fine; that just resets the modem to the factory defaults, which should be fine for Internetting. My modem is older, and its factory defaults are kind of screwy. I've got its CMOS set up for the correct settings, however, so I give "ATZ" for my init string, which reads the settings from CMOS. You can set up your modem's CMOS to your liking using terminal mode in your communications program (if your modem has CMOS); check your modem's manual.
Generally, you need to set up your modem to enable hardware (RTS/CTS) flow control (&K3), to hang up when DTR is dropped (&D2), and to allow DCD to follow the true state (&C1). You want to get result codes (Q0) and specify that they should be text, not numbers (V1). If your modem provides hardware error correction and data compression, you want to enable them as well. See your modem manual; modem AT commands are not entirely standard. (If you have an old modem without data compression, error correction, or flow control, that is fine - just they are good to use if you have them.)
There are a few special cases to note. First, if you have a "plug and play" (sometimes called "plug and pray" :-) modem, you will need to configure its driver in AUTOEXEC.BAT or CONFIG.SYS. In addition, the BIOS in an XT will not be able to detect a plug and play modem, so you need to specify the modem's I/O port and IRQ when you configure your packet driver and its dialer (or any other communications software), rather than just saying "COM1:" or "COM2:". For example, if you have your mouse on COM1: and your modem on COM2: is plug and play, you will need to specify I/O port 2F8 and IRQ 3 instead of just giving a COM: port when you configure your dialer and packet driver.
Second, if you already have two serial port devices and you install the modem as the third one, the BIOS on many older machines will not detect the modem on the third COM: port. Again, you will have to explicitly specify the I/O port address and IRQ setting when you configure your dialer and packet driver (or any other communications software).
Third, if you have a Rockwell RPI or Rockwell DPI modem, you will need to disable data compression, error correction, and flow control on it (using the init string). Note that for most modems you want those things enabled for greater throughput; Rockwell RPI modems are an exception. They are designed to implement data compression in software, making them cheaper than other modems of the same speed. If you bought one of these "cheapies," you're going to pay for it now :-). To do data compression, Rockwell RPI modems require special software. Under DOS, that software is Quick Link II or Comit. Under Windows, there is a "Rockwell RPI applet" that you have to run (or use Quick Link II for Windows). None of that is going to help you with DOS software like packet drivers that don't support Rockwell RPI. Your modem will still work, but you won't be able to use its data compression, error correction, or flow control features. To determine if your modem is Rockwell RPI, type "ATI3" in terminal mode of your communications program. If the modem returns a string containing the word "RPI", it's an RPI modem. See this page for more gripes about RPI modems:
http://www.columbia.edu/kermit/faq-c-rpi.htmlFinally, it is possible that your modem will work with regular communications software at some given speed, but it won't work for Internet at the same speed. For example, if you have a 14.4k modem with V.42bis compression, you would normally set up your software to run it at 57.6k. That might work fine for BBSing, but it might not work for Internet because Internet is more work for the processor. This depends on the speed of your system, the type of UART chip the modem has, and the packet driver you select. Under no circumstances, though, should the modem's connect speed (the DCE rate, set via the init string) be greater than the packet driver speed (the DTE rate, configured in the dialer and packet driver).
It costs your ISP about $10 a month to reserve an IP address (well, probably a bit less, since they buy in bulk), so it is more economical for them to get a limited set of addresses and share them out. That way, they don't need an address for every user, only an address for every phone line, since not all users are connected all the time, and users who are not connected do not need IP addresses. If your ISP is allocating addresses that way, you will get a different one each time you call, which is called "dynamic IP address assignment."
Now, remember that every machine on the Internet has an IP address, not just your machine - and that includes the machine you dial into when you call. That machine, which belongs to your ISP, is called your "gateway" machine. On some providers, not only is your IP address dynamic, but your gateway's address is too. That could happen if your provider uses more than one networked machine to answer calls from users. Dynamic IP with a dynamic gateway is the most complicated situation to handle.
Some ISP's are now assigning nameservers dynamically. That is not going to work for DOS. Make them tell you the IP address of one of their servers.
Static IP is the simplest situation, and if you have that you can use either SLIP or PPP and your choice of packet driver. All the applications can be set up by simply filling in the values your ISP provides. Static IP, where everything is fixed, is the least problem-prone situation for setting up DOS Internet applications.
Dynamic IP with a static gateway is next. Here you will have to find ways to pass your IP address to the various applications you use; of course, it is possible to manually modify the configuration of each and every application each and every time you connect, but you really don't want to do that, do you ;-)? You can use a combination of DOS environment variables, batch files, and RARP or BOOTP (see below) to pass the IP address to the applications. You can use either SLIP or PPP, but setup is more complicated than in the static IP case.
Dynamic IP with a dynamic gateway is the worst case. Here you not only have to pass your IP address to your applications, but your gateway's IP address as well. The only convenient way to handle this situation is to get a PPP account and use Dospppd as your packet driver, or use Nettamer. If you have a dynamic gateway, it sometimes works to pretend that you have a static one and give the gateway you usually get when configuring applications. Don't just give a random number for the gateway, though; it needs to be a machine that actually exists.
If your provider tells you to get lost when you call their tech support line with these questions, you need to find another ISP. Few ISP's support DOS directly, but they should be able to furnish you with the above information if they know what they're doing and care about their customers. Not everybody has Windows or Mac, and people who are running Linux or FreeBSD need this information as much as you do.
You can usually figure out the login sequence for your ISP by just calling them with a regular communications program and seeing what you get; you will use that information to write a dialing script for your packet driver or its dialer.
If your provider does not have a file available listing the newsgroups they carry, it is possible to get such a list via telnet. See file cutcp-b.txt in this directory.
SLIP and CSLIP (SLIP with Van Jacobson compression) are different methods of connecting to your ISP and use different packet drivers. You need to know which kind your ISP uses so you can select the right packet driver. If your provider has adaptive SLIP, though, that means that you can use either SLIP or CSLIP and they will adjust on their end.
You might not need all this, depending on which applications you pick. Nevertheless, you should find out as much as you can since you can mess up the 'net if you get your settings wrong (which would make people very mad at you - particularly getting the IP address or machine name wrong with static IP). It helps if your provider has a fair amount of patience as well :-), but don't expect a lot of help from them since most providers only support Windows and Mac nowadays.
If you want to know what some of the stuff above is, get tcpdocs.zip. TCPINTRO.DOC is a basic introduction to TCP/IP, the Internet protocol suite. TCPADMIN.DOC contains more information for the terminally curious. TCPIP1.FAQ, TCPIP2.FAQ, TCPIP3.FAQ, TCPIP4.FAQ, and TCPIP5.FAQ are parts 1, 2, 3, 4 and 5 of the comp.protocols.tcp-ip.ibmpc FAQ. This is an old version from 1995; I can't find a newer one. A lot of the stuff in the FAQ is about Windows, but there is some on DOS as well.
Finally, don't imagine that you can get by without reading documentation. No DOS Internet application works right out of the box. You will need to study the docs that come with each program to get things to work right. I've written some .txt files that will hopefully be helpful as well. They include some special instructions for Agate Internet users; disregard those instructions if you're not on Agate (the .txt files should still be useful). I do not work for Agate Internet.
http://www.nettamer.net/In addition to Nettamer, the Bobcat and Arachne distributions (see below) come with dialers and packet drivers. I do not recommend that you use them, though you can try them if you want. There are three reasons for that. First, it is difficult enough to get dialed up and connected without worrying about how to configure a complicated application at the same time. Second, if you use Bobcat or Arachne to dial your ISP and load your packet driver, you are pretty much locked in to using Bobcat or Arachne for all your Internet work. Third, the batch files that Bobcat and Arachne use for dialing and packet driver loading require DOS 5.0 or later (Bobcat comes with some alternate batch files for DOS 3), though the programs themselves will work with DOS 3.3. So I say, take the long way around; the view is better :-).
Bobcat and Arachne use Dospppd for PPP and Slipper or Cslipper for SLIP, if you use their internal dialing capability. Those are pretty good packet driver choices.
Some packet drivers, however, do not come with a dialer and assume that you are already dialed in and connected before you load them. For those programs, you will need to get a dialer. Any communications program can be used as a dialer if it is capable of dialing the phone, logging you in, and exiting while leaving DTR up (i.e., leaving the connection open). I personally prefer to use CHAT0.EXE, which comes with Dospppd. Another alternative would be PHONE.EXE, which comes with Umslip.
I also have two general-purpose dialers in this directory. If you use Bobcat to dial the phone (see above), it will use Netdial, which is much simpler to write a script for than CHAT0.EXE (though of course Netdial is less powerful). Netdial uses the same script syntax as Etherppp's internal dialer. Get nd130.zip and nd130.txt for Netdial.
Comtool is a minimal command-line dialer that doesn't use a script; you specify everything on the command line. It might work for you if your login sequence is simple. Get comtool.zip for Comtool.
If you use PHONE.EXE as the dialer for your SLIP account (you can't use it with PPP, AFAIK), you need to get tcpdocs.zip. There is a section in TCPIP1.FAQ on using packet drivers other than UMSLIP.COM with PHONE.EXE.
If you find it difficult to select an init string or write a Chat script for Dospppd, you might try Alfredo Cole's Dospppd setup package. Get setup.zip and cole.txt for that.
Before Toni Lopez wrote Dospppd, I used to use Etherppp; get ethernew.zip and ethernew.txt. Etherppp emulates Ethernet (class 1). Etherppp works well enough for most applications, but it doesn't support modems faster than 14.4k. Etherppp supports both BOOTP and RARP.
Marc Williams has switched to Dospppd also, but he started out using Quakeppp. It is no longer available, but a newer version of the Klos packet driver in Quakeppp can be downloaded from:
http://ftp.klos.com/The packet driver is named PPPSHARE. Klos's PPP can also emulate Ethernet. You should also get klosppp.txt from my site for instructions on setting up Klos PPP. Klos works best if you have a newer modem with a 16550 UART, or if you have a 386 or above. Klos PPP requires DOS 3.3 or later. Recent versions of Klos PPP won't work on my machine any more, but last I heard it supported BOOTP, though that was problem-prone. There is a program included for configuring WATTCP applications that may or may not work. I don't know about RARP.
Note: if you are connecting via PPP and your provider requires CHAP authentication, you can't use Etherppp. You will need to get either Dospppd (preferable) or the demo version of Klos PPP, named PPPDEMO and available at the Klos sites above. It is time-limited to 15 minutes of connect time, so if decide to use it you will ultimately want to buy the full version of Klos. (Nettamer supports CHAP also, if you use that.)
Slipper and Cslipper can emulate class 1 and are compatible with more applications. SLIPPER.EXE is the packet driver for regular SLIP, and CSLIPPER.EXE is the driver for compressed SLIP (CSLIP). They are both in the same archive; get slippr15.zip and slippr15.txt for them. They do not come with a dialer, so you need to get one (see above). Slipper and Cslipper support BOOTP, but there is no configuration file to set the nameserver or netmask. It appears that for BOOTP to work with these drivers, your ISP must have server-side BOOTP support on their end. (Cisco servers can provide BOOTP over a SLIP link.) Marc has used Cslipper successfully.
Frank Molzahn has written a pair of very small packet drivers for SLIP and CSLIP. They emulate class 1 and support RARP but not BOOTP (the RARP here is an emulation; you need to use Ipread to get the IP address to configure it). They don't come with a dialer. Frank is requesting feedback on the drivers if you try them; his email address is in the documentation. Get csl_b04.zip and csl_b04.txt for Frank Molzahn's SLIP drivers. These programs are still officially under development, so check Frank's site for the latest:
For dynamic IP, you will generally have to set DOS environment variables in batch files. When you do that, you may get the message, "Out of environment space" from DOS. If that happens, you need to edit your CONFIG.SYS file and use the SHELL= command to increase the environment space, like this:
SHELL=C:\DOS\COMMAND.COM C:\DOS\ /E:1024 /PCheck your DOS manual and make sure that you know what that means; it should work as is for most people, but it depends on where you have COMMAND.COM installed. Whenever you modify CONFIG.SYS, for this or any other reason, always check the changes using a bootable floppy before you change CONFIG.SYS on your hard drive.
Whether you have static or dynamic IP, you may also need to modify CONFIG.SYS to increase the maximum number of open files. You use a line like this to do that:
FILES=20Perhaps a little about how DOS Internet works is in order. The Internet uses a layered model, where each layer of software runs on top of and uses services provided by the layer below. The lowest layer is the hardware itself, in your case, your modem, the phone line, and your ISP's modem. On top of that, you have a driver for the hardware, in your case, your packet driver. So far it is the same as on any other operating system.
Next comes the TCP/IP stack. This is where it gets different. Technically, IP runs on top of the hardware driver, and TCP runs on top of IP. Generally, though, IP and TCP are integrated into the same piece of software, called a TCP/IP stack. Under Windows, the TCP/IP stack is usually Trumpet Winsock. Under Linux, the TCP/IP stack is integrated into the operating system kernel. Under DOS, however, the TCP/IP stack may either be integrated into the application or be a separate TSR that you must load.
To run an Internet application, you must first configure its TCP/IP stack, telling the application or its TSR what your IP address is, your nameserver, your gateway, your netmask, and other things. Hence, how you configure an application mainly depends on the TCP/IP stack it uses, and applications that use the same stack are configured similarly. The four major TCP/IP stacks used by DOS applications are WATTCP, Trumpet TCP, the University of Minnesota stack, and the NCSA/CUTCP stack.
Over half of all DOS Internet programs use the WATTCP stack. In their case, the stack is integrated into the application. To configure them, you edit a file usually called WATTCP.CFG (for Doslynx it is called DOSLYNX.CFG, and for Arachne, LANTCP.CFG). WATTCP does not support RARP, and BOOTP does not work with it over a SLIP or PPP link (because of problems with the netmask). To configure these applications for dynamic IP you will have to set environment variables for your IP address and if necessary your gateway address as well, then create a batch file that uses those variables to generate files that can be included into WATTCP.CFG. To illustrate: I load Dospppd as my packet driver, and it generates the file IP-UP.BAT. I then run IP-UP.BAT, which sets the following DOS environment variables:
MYIP (my local IP address)To configure WATTCP applications, I need MYIP and (if my gateway is dynamic also) REMIP; the others don't matter. I make a batch file like this and run it next:
REMIP (the IP address of my gateway)
NETMASK (my netmask)
PEERMRU (the largest PPP packet the gateway will accept)
echo my_ip=%MYIP% > ipaddr.cfg echo gateway=%REMIP% > gateway.cfgThat creates two files, IPADDR.CFG and GATEWAY.CFG, which look like this (for me):
my_ip=18.104.22.168(for IPADDR.CFG) and
gateway=22.214.171.124(for GATEWAY.CFG). Now when I edit my WATTCP.CFG file and it asks me to set the my_ip parameter, I comment out that line and put this instead:
include=ipaddr.cfgSimilarly, where it asks me to set the gateway, I comment that out and put this:
include=gateway.cfgNow, assuming I've configured the rest of WATTCP.CFG and whatever else that particular application may require, I can run WATTCP applications in my dynamic IP setup. Of course, if I had static IP (as I really do) there would be no need for me to go through all that rigamarole. All I would have to do is just type my static IP and gateway addresses into WATTCP.CFG along with the other stuff in there, and I'd be ready to go. I've constructed what I call "the ultimate WATTCP.CFG file" containing all the variables required or used by the various applications; get mywattcp.zip to look at it.
The Trumpet TCP/IP stack, unlike WATTCP, is generally loaded as a separate TSR (NTCPDRV.EXE). The applications then use the TSR to connect to the Internet. Trumpet IRC (IRC 1.01) and Ping, however, do not use the TSR; the Trumpet TCP stack is integrated into them. In either case, DOS environment variables are used for configuration:
IP (your IP address)If you have static IP, you can just set these variables in AUTOEXEC.BAT and forget about it. In any case, your netmask, nameserver, mss, rwin, domain and timezone should be constants, so you can set them in AUTOEXEC.BAT. MSS and RWIN should be set to 512. This prevents packet fragmentation and is necessary with Frank Molzahn's SLIP drivers.
NETMASK (your netmask)
GATEWAY (your gateway's IP address)
DNS (your nameserver's IP address)
MSS (largest packet you will agree to receive)
RWIN (size of buffer for incoming packets)
DOMAIN (your domain - optional, see below)
TZ (your time zone - optional, see below)
As noted above, if you use Dospppd and you run the IP-UP.BAT it generates, it will set MYIP, NETMASK, and REMIP for you. To convert MYIP and REMIP to IP and GATEWAY as Trumpet TCP requires, you can make a batch file like this:
set ip=%MYIP% set gateway=%REMIP%DOMAIN is your domain. Normally, that is the part of your machine name after the first dot. For example, my PC is jhayes.buckeyeweb.com. I would set DOMAIN to "buckeyeweb.com". You don't really need to set DOMAIN, however, and it is probably better if you don't (speeds up DNS queries).
TZ is your time zone. This is a three-letter code, followed by a number indicating the offset from Greenwich Mean Time, optionally followed by a three-letter code for daylight savings time (if it's summer). It is not terribly important, and you can leave it out. If you want to set it, however, this is for the east coast of the U.S.:
SET TZ=EST5EDTThe Trumpet newsreader naturally uses the Trumpet TCP stack, but it does not use the TSR or the environment variables; instead, you configure it from inside the application. A configuration file, NEWS.PRM, is generated. To use the newsreader with dynamic IP, you need to make a batch file for it specifying command-line options to override the settings in the file, like this:
news -myip=%MYIP% -gateway=%REMIP%Finally, it could be said that Trumpet applications support BOOTP, but only if the IP and MYIP environment variables are not set (the -myip=bootp command-line option is ignored). I find that sort of behavior too screwy to deal with and just use the variables.
The University of Minnesota applications are Minuet, POPmail, and PC Gopher III. You configure them from inside the application, which contains the TCP/IP stack. How you configure them for dynamic IP depends on the application.
First, you can leave the IP address, Net mask, Gateway, and Name Server settings blank in the dialog box - in the case of PC Gopher III, there is a Use BOOTP box that must be checked (by default it is). That will cause a University of Minnesota application to use BOOTP, which will work with Dospppd and sometimes Slipper, Cslipper, or Umslip, but not with other BOOTP emulations (like Etherppp's). There is a bug in the BOOTP support of UMinn applications which requires a workaround in the BOOTP server.
Otherwise, for Minuet only, if you have dynamic IP and BOOTP doesn't work, leave the IP address, Net mask, and Gateway blank, but fill in the Name Server. Minuet will get the local IP address from the MYIP environment variable and assume a point-to-point connection so that the netmask and gateway are not needed (everything goes out the PPP or SLIP link). Of course, if you have IP set instead of MYIP, you can set MYIP in a batch file like this:
set myip=%IP%For PC Gopher III only, if you have dynamic IP and BOOTP doesn't work, then leave the IP address, Net mask, Gateways, and Nameservers blank in the dialog box, and uncheck the Use BOOTP box. Exit Gopher, and edit GOPHER.INI by hand to include these settings:
pc_ip = %MYIP nameserver_1 = 126.96.36.199(Use your nameserver's IP address.) This will get your IP address from the MYIP environment variable, as for Minuet. The gateway and netmask do not need to be set; PC Gopher III will default to a point-to-point link.
Using BOOTP with Dospppd appears to be the only way to configure POPmail for dynamic IP. Minuet will work for both gopher and email, however.
Finally, we have the NCSA and CUTCP applications. They use an integral TCP/IP stack and are configured by editing a file usually named CONFIG.TEL. (CUTCP's is slightly different from NCSA's.) To configure them for dynamic IP, you can use either BOOTP or RARP, depending on which your packet driver supports. BOOTP is probably preferable, since if you use that you don't need to configure the netmask, gateway, or nameserver in the file. Set myip=BOOTP or myip=RARP in CONFIG.TEL.
CUTCP (but not NCSA) also supports include files and environment variables to set the local IP address. The environment variable can be set like this:
set $cutcp1=myip~%MYIP%You also need to set DOS environment variables to point to the CONFIG.TEL files (whether or not you have dynamic IP), for example:
SET CONFIG.TEL=E:\INTERNET\TEL2308B\CONFIG.TEL SET CONFIGTEL=E:\INTERNET\CUTCP-B\CONFIG.TEL(The first line is for NCSA, the second for CUTCP.) You can just put those two lines in AUTOEXEC.BAT. CUTCP, but not NCSA, will also find CONFIG.TEL in the current directory if CONFIGTEL is not set.
Some applications (Bobcat and Arachne, for example) require that you be in the directory where you installed them to run them. Others (Dospppd, CUTCP) will run from any directory if you put them in the PATH and configure them correctly. I always change to the directory where I've installed a program before I run it. You can automate such directory changes with batch files, of course.
BOOTP and RARP can be useful if you have dynamic IP. With BOOTP, the packet driver provides the application with the IP addresses of the PC, the gateway, the nameserver, and the netmask. With RARP, the packet driver provides the PC's IP address.
Dospppd creates IP-UP.BAT to set the MYIP environment variable for dynamic IP configuration. But how do you set the variable if you're not using Dospppd? If you have RARP, Iprarp and Rarpset can get the PC's IP address from the packet driver by RARP. Iprarp creates a batch file that sets a DOS environment variable to the IP address; Rarpset directly sets an environment variable. Get ipcfg010.zip and ipcfg.txt for Iprarp, and get rarpset.zip and ipcfg.txt for Rarpset.
If you are using Klos PPP, it comes with a program PPPWAT.EXE that can create or modify WATTCP.CFG for your dynamic IP configuration. If you have such an automatically generated WATTCP.CFG file (and WATTCP apps work with it), Watbat can extract values from the file and create a batch file to set corresponding DOS environment variables for your other apps. Get watbat.zip for Watbat.
Ipread is another program that can be useful with dynamic addressing, particularly if your packet driver doesn't support RARP. It reads the IP address from the screen at connect time and creates a batch file that sets a DOS environment variable to that address. Get ipcfg010.zip and ipcfg.txt for Ipread.
If you use BOOTP to configure your applications, remember that the BOOTP support provided by the PPP packet drivers is an emulation. In particular, the packet drivers will not know where your nameserver is if you do not tell them, so be sure to configure that, for example by including the "nameserver" line in CONFIG.PPP with Etherppp, or the "namsrv" line in PPPD.CFG with Dospppd. With Etherppp, but not Dospppd, you also need to configure the gateway, using the "gateway" line in CONFIG.PPP. It is a good idea to explicitly specify the netmask as well.
Similarly, the RARP support in Frank Molzahn's drivers is an emulation, and you need to set the IP address on the command line for it. You can use Ipread to automate the process.
Note that BOOTP doesn't seem to work that way with Slipper, Cslipper, or Umslip. Those programs must be getting the local address, gateway, netmask, and nameserver from the ISP somehow, since there is no configuration required for them.
NCSA Telnet provides telnet, ftp, finger, whois, rsh, rexec, rcp, lpr, lpq, and lprm. rcp and ftp can operate in server mode when telnet is running. The telnet offers a complete, configurable VT100 emulation including Tektronics 4014 graphics mode on Hercules, CGA, EGA, or VGA. You can have multiple telnet sessions going simultaneously. Note: these applications can't resolve domain names, and you have to specify IP addresses, either on the command line or in the configuration file. NCSA Telnet supports class 1 packet drivers only, so it won't work with Umslip. Get tel2308b.zip, tel2308b.txt, tel23asc.zip, and tel23asc.txt for NCSA Telnet.
CUTCP Telnet is an offshoot of the NCSA Telnet package and is set up similarly. It provides telnet, tn3270, ftp, ping, lpr, lpq, and lprm, and it seems to deal with domain names better than NCSA Telnet. Like that package, CUTCP Telnet offers a complete VT100 emulation and supports incoming ftp during a telnet session. It supports both class 1 and 6 packet drivers. Get cutcp-b.zip and cutcp-b.txt for CUTCP Telnet. The documentation for NCSA Telnet will also be helpful with this one - get tel23asc.zip and tel23asc.txt as well.
Trumpet TCP (not to be confused with the Trumpet newsreader, from the same people) is a set of Internet applications using an included TSR to interface with the packet driver. Both class 1 and class 6 are supported. The applications are: telnet, ftp, finger, ping, archie, whois, hopchk (traceroute), and ichat (similar to Unix talk, apparently, but incompatible). The archie in this package is the only working DOS archie client I've found, but the other stuff doesn't work all that well. Dospppd and Klos PPP work better with these than Etherppp. Get tcp201.zip, ntcpdrv.zip, and tcp201.txt for Trumpet TCP. The Trumpet TCP apps work best with Slipper or Cslipper.
The WATTCP applications are the "example" apps that come with the Waterloo TCP development package, plus ftp. They include a fortune cookie client, two time clients, finger, lpr, lpq, ping, rexec, talk, a phonebook client, a POP mail retriever, a program that sets up a TCP connection to mimic a serial port (so that you could use a regular communcations program as a telnet client, for example), and of course ftp. Get wattcp.txt and wattcp.zip for the Waterloo TCP applications.
Pegasus Mail has got to be the ultimate DOS email client. (It includes basic MIME support and can control an automated mailing list, among other things.) Pegasus Mail has menus (but does not support a mouse) and comes with a great deal of documentation. It requires a class 1 packet driver and DOS 3.0 or later. Get pmail331.zip, pmpop110.zip, and pmail331.txt for Pegasus Mail. There is an official Web site for Pegasus Mail:
http://www.pmail.com/I don't have the latest Pegasus Mail, but there is no advantage to the newest one if you're not on a Novell network, and it takes more memory than the version I have. If you have problems retrieving mail from your POP server, you can try using Smtpop with Pegasus. Smtpop is somewhat more sophisticated but less convenient than the default setup. Get smtpop12.zip and smtpop.txt for Smtpop. Popgate is another transport agent you can try. It runs from inside Pegasus like Pmpop does, but Popgate is more complicated to set up. Get popgt10d.zip and popgt10d.txt for Popgate.
Bobcat is a good text-based WWW browser, successor to Doslynx, and very similar to Unix Lynx. It requires DOS 3.3 or later. Klos PPP or Dospppd work better with it than Etherppp. Bobcat is highly configurable, but setup can be somewhat involved. Get bcat-e06.exe and bcat-e06.txt for Bobcat. The main program (LYNX.EXE) requires more memory than the one in version 5 did, though version 6 is better behaved in low-memory situations generally. Get lynx05.zip also for version 5 LYNX.EXE. Bobcat is under active development; if I'm out of date, you can get the latest version from:
http://www.fdisk.com/doslynx/bobcat.htmArachne is a graphical WWW browser, and yes, it will run on an XT, albeit slowly. It requires DOS 3.3 or later. You must have EGA or better video and a mouse. At least some EMS is strongly recommended, and for best results, 640x480x256 SVGA or better is required. Get arcn14b2.exe and arcn14b2.txt for Arachne. Arachne almost requires a hard drive cache; if you don't have one, but you have some EMS to use for one, get adcsh122.zip. Arachne is under active development; if I'm out of date, you can get the latest version from:
http://arachne.browser.org/There are also some Arachne plugins (telnet, etc.) to be found there. One such plugin is extedit.exe. This one you have to install yourself, though - I'm not allowed to have APM files on my site.
http://www.trumpet.com.au/Despite what they say, the newsreader does work with PPP. Trumpet doesn't contain any capability of dealing with uuencoded or MIME-encoded messages, so if you're interested in binary newsgroups, you'll need decoders. For a uudecoder, get uuexe656.zip. To decode MIME under DOS, get mpack15d.zip.
Voice is another Internet Relay Chat client. You might like this one better if you're used to ircII on Unix; it can also connect to more sites than IRC101. Get voice11b.zip and voice11b.txt for Voice.
jpIRC is the best DOS IRC client around. It includes ident and CTCP PING support, which enables it to connect to many sites that IRC101 and Voice will not. It can also receive (but not send) files by /dcc and check periodically for incoming mail, and you can shell out of it. jpIRC is a Trumpet TCP application, so you need to get Trumpet TCP set up first (see above). As a Trumpet TCP application, it supports both class 1 and 6. Get jpirc.zip and jpirc.txt for jpIRC.
Nslookup is a simple application that looks up the IP address for a domain name or vice versa. It didn't come with any documentation. Get nslookup.zip and nslookup.txt for Nslookup.
BSD Nslookup/Nsquery is a direct port of those applications from Berkeley Unix. They require a class 1 packet driver. While they can be used in the same way as the Nslookup above, they do much more, though you need to be pretty well-informed to use the advanced features. Get nslb01a.zip and nslb01a.txt for BSD Nslookup/Nsquery.
PC Gopher III is a gopher client with menus, scrollable windows, and mouse support. It supports both class 1 and class 6 packet drivers, but it requires DOS 3.3 or later. Get pcg3bin.zip, pcg3doc.zip, and pcg3note.txt for PC Gopher III.
Talk is a DOS version of the Unix talk program for 2-way interactive communication over the Internet. Get talk-13.zip for Talk. It is a WATTCP application and is set up similarly.
Pcfsp is an FSP client. FSP is sometimes used in place of FTP to transfer files over the Internet. Get pcfsp105.txt and pcfsp105.zip for Pcfsp.
MudCaller is a MUD client (i.e., telnet with macros for connecting to a MUD). It doesn't seem to work very well. Get slip_mud.zip and slip_mud.txt if you want to try it anyway.
Jeff Patterson (author of jpIRC) has also written some clients for telnet, nslookup, and finger. Like jpIRC, they are Trumpet TCP applications, so you need to set up Trumpet TCP first. The telnet doesn't work for me, but nslookup and finger do (these programs don't come with any documentation). Get tn102.zip and tn102.txt for Jeff Patterson's clients.
Trout is a traceroute (hopcheck) client for DOS, essentially a clone of Unix traceroute. It requires a class 1 packet driver. Get trtb01b.zip and trtb01b.txt for Trout.
If you are interested in Web authoring, two tools you can use are Htget and Knots. Htget is a command-line HTTP retriever; get htget102.zip and htget102.txt for it. Knots is a graphical HTML viewer. It only supports a small subset of HTML codes, but it will work with any graphics card, even CGA or Hercules. It uses an "FAT" file to convert URL links to local filenames. Get knots2_0.zip for Knots. Note that Knots is not a browser - if you need a browser, use Doslynx, Bobcat or Arachne instead.
http://ftp.oldskool.org/pub/tvdog/internet/advanced/Also check out Nigel's (unfinished) List of PPP & Internet Applications for DOS at:
http://www.tropinet.com/ppp.htmlAnd see the FDISK.COM DOS Internet page at:
http://www.fdisk.com/doslynx/Another site worth checking out is Dan Komaromi's page on setting up Internet email for DOS:
http://www.komaromi.com/dos_email/See UKA PPP at:
http://mvmpc200.ciw.uni-karlsruhe.de/~mvmpc9/public/uka_ppp/welcome.htmIf you're looking for KA9Q, these people have a version that they claim will run on an 8086:
Here is a site with an FTP/WWW server for DOS that runs on 8088 up:
While not precisely Internet-related, Eko Priono's 386 software emulator can be useful. It requires a 286. It may permit you to run some applications that normally require a 386:
http://ftp.oldskool.org/pub/tvdog/tandy1000/misc/em3134b1.zipJeffrey L. Hayes <firstname.lastname@example.org>
Go back to Tvdog's Home Page.