I think I've heard all the reasons why people can't use DOS Internet software by now: Their modem won't work with DOSPPP06 nor LSPPP. (I use the term WinModem to refer to all such modems.) Their Ethernet or WiFi adapter lacks a DOS Packet Driver. Their modem or WiFi adapter is connected via a USB port. Their ISP uses a CHAP login procedure that only Windows knows. Their ISP requires that they use a software package installed into Windows for connecting. And, so on.
Before you conclude that one of those reasons describes your situation, make sure you've studied my DOS Internet Software How To document. If you then feel that one of those reasons describes your situation, there still is a way for you to use DOS Internet software.
In short, you use your Windows system as an elaborate device driver for your modem or other networking device(s). These may include Ethernet or WiFi adapter(s) lacking DOS Packet Driver(s). Or, even, a USB-connected modem or WiFi adapter. Then, use the NDIS3PKT or SWSVPKT drivers to provide Packet Driver interface(s), for those networking device(s), to your Windows DOS window(s). Once you've used Alt-Enter to make your DOS window(s) "full-screen", it will be easy to ignore the fact that Windows is running your system! However, if you want to, you'll still be able to run Windows software at the same time in other window(s).
The NDIS3PKT driver comes in three flavors, from Dan Lanciani. Dan's ndis3pk2.zip package provides the NDIS3PKT.386 VxD for Windows 9x and ME. Dan has been working on this software, on and off, for over ten years! Dan also has an ndis3nt.zip package, which provides the NDIS3PKT.SYS driver for Windows NT, 200x, and XP. And, an ndis3ce.zip package for Windows CE! The free versions of Dan's packages are severely crippled demos. But, the un-crippled registered versions are relatively inexpensive.
The SWSVPKT driver is an offering of Software Systems Consultants. Their SwsVpkt1005.zip package provides SWSVPKT.SYS for Pentium compatible PCs running Windows XP, 2000 and NT4. They say that the package, though shareware, "may be freely used by any individual for personal and private use or for their business without any restriction or charge."
Most of the rest of this document is a recounting of my experiences with several of these packages. First, I'll recount my experience with a couple of Dan's packages. This section, shortly below, also includes a discussion of two approaches for obtaining a Windows Dial-Up Networking connection's configuration information. This information is needed for (re)configuring one's DOS networking clients at the beginning of each new dial-up session.
I'll recount my experiences with Software Systems Consultants packages below, toward the end of this document.
Before I get into my own stories, let me introduce some related resources: First, Andrew Diamond wrote to tell me that he has succeeded in using SWSVPKT.SYS on 32-bit versions of Windows Vista and Windows 7. His note includes a detailed procedure for installing SWSVPKT on those systems. With his permission, I am reproducing Andrew's note on SWSVPKT, here. Neither Andrew nor I expect that SWSVPKT will ever be found usable on 64-bit versions of Windows.
Mike Brutman, developer of the mTCP package of DOS Internet software, provides a related resource. Mike has published a guide or review to/of three alternatives, to the Windows DOS window, for running DOS Internet software on Windows systems. These alternatives are known as DOSBox, VirtualBox, and VMWare. If there is any hope for being able to run DOS Internet software on 64-bit versions of Windows, surely it comes from one or more of these. Mike's guide/review document is entitled: Using mTCP in Virtual Environments.
I started playing around with several versions of Dan's ndis3pk2.zip package back in May 2004. The latest one, from Dan's Web site, is still version 2.9 dated 03/30/03. I also found a version 2.5 elsewhere on the Web. Both of these are severely crippled demos. ndis3pkt.zip, an un-crippled forerunner of the ndis3pk2.zip package, may also be found elsewhere on the Web. Google is great for finding these. The latest ndis3pkt.zip that I've been able to find contains a 27,478 octet NDIS3PKT.386, version 1.5, dated 01/26/97. This version came out before Dan had worked out support for Windows dial-up modem based networking devices. So, it won't help with your WinModem. But, if you have a Windows 95 system with an Ethernet card, it can give you an extended demo.
I've installed the ndis3pkt.zip package into the Windows 95 system on my PC named Sailboard. At the time, this was a 16 BogoMIPS '486 based system with 36 MB of RAM. Once the installation was complete, a Packet Driver interface for its Ethernet card showed up in Sailboard's Windows DOS window(s). When I ran DosLynx in a full-screen Windows DOS window on that system, the only difference from running in DOS that I noticed was that the system seemed to have slowed down to, perhaps, 8 BogoMIPS!
I've installed the ndis3pk2.zip demo packages into the Windows 98 SE system on my PC named Digerydo. This is a 60 BogoMIPS Pentium based system with 64 MB of RAM and a Zoom WinModem. In preparing to test with Digerydo's WinModem, I did consider an obvious difference between the Windows "dialer" and the DOSPPP06 and LSPPP packages. Unlike DOSPPP06 and LSPPP, the Windows dialer doesn't produce an IP-UP.BAT file. I thought this wouldn't be needed with applications that can be configured to use BOOTP or DHCP. But, once I started testing with NDIS3PKT.386 installed on Digerydo, I found the actual situation to be a little more complicated than I had expected.
DosLynx wouldn't work, via the NDIS3PKT Packet Driver for Digerydo's WinModem, with my_ip= configured for BOOTP or DHCP. But, please read on for this story's happy ending.
My post-dialing "glue" script normally starts by CALLing IP-UP.BAT. I had planned to provide a substitute by running WINIPCFG or IPCONFIG and manually editing the IP addresses reported into an IP-UP.BAT file template. WINIPCFG and IPCONFIG did report a valid IP Address for each of my sessions. But, they reported a Default Gateway address that was identical to the IP Address they were reporting! On the basis of successful DOS sessions recently provided by LSPPP on another PC, I knew that wasn't right.
Next I tried tvdog's undocumented ping.exe program, which I've renamed TRMPING.EXE. Actually, tvdog also provided some documentation he wrote for this ping. TRMPING was able to report both a valid IP Address and a valid gateway address for each of my sessions. However, TRMPING isn't much good in a batch file. Because keyboard input seems to be required to make it quit.
So, I then tried the CUTCP/CUTE PING program from the
cutcp-b.zip
package. A command like:
PING -e myip=bootp 192.168.0.50
yielded a response including five lines similar to:
BootP: Reply from server IP [0.0.0.0]
BootP: My IP [207.88.126.116] Gateway IP [0.0.0.0]
BootP: Subnet is 255.255.255.255
BootP: Adding Gateway number 1 IP 207.88.126.2
BootP: Adding Nameserver number 1 IP 205.158.183.100
I don't know why the server's IP address appears to be 0.0.0.0.
And, I don't know what to make of that all ones (binary) Subnet mask.
However, those BootP: My IP . . . and
BootP: Adding . . . lines do provide most of the
information needed for composing the following successful IP-UP.BAT file:
set myip=207.88.126.116
set remip=207.88.126.2
set netmask=255.255.255.0
set peermru=1500
set dns1=205.158.183.100
set dns2=205.158.183.102
My regular post-dialing glue script then provides that configuration to a PATH.CFG file that may be included in DOSLYNX.CFG, WATTCP.CFG, and other similar configuration files. When configured by means of that PATH.CFG file, DosLynx worked fine! It shouldn't be too hard to automate a process for composing an IP-UP.BAT file from that PING report.
In August 2006, I revisited the problem, of finding one's Windows Dial-Up Networking configuration, while setting up a Windows 98 SE system for a relative. I've found another method, for Windows 9x systems at least, that's so easy it almost seems like cheating! This method is based on the PPPLOG.TXT log file that the Windows "dialer" may write in the windows directory. I think that getting this log file written depends on having two checkboxes, in a Dial-Up Networking connection's configuration, checked.
After configuring a Dial-Up Networking connection, I can reach its Properties
by working through the following buttons, menu entries, tabs, and windows:
Start
Programs
Accessories
Communications
Dial-Up Networking
some connection's icon
Properties
From a connection's Properties, I can reach the two check boxes that need to
be checked as follows:
General
Configure
Connection
Advanced
Append to log
And:
Server Types
Record a log file for this connection.
Upon discovering PPPLOG.TXT, I worried that the contents I needed might not get written as soon as a Dial-Up Networking connection is established. However, in about half a dozen dial-up session setup trials, I found no problem like that. The present session was always correctly documented by the last set of the following four messages (interspersed with other messages) in PPPLOG.TXT:
IPCP : Received and accepted IP address of hhhhhhhh.
IPCP : Changing IP address from hhhhhhhh to hhhhhhhh.
IPCP : Accepting primary DNS hhhhhhhh.
IPCP : Accepting backup DNS hhhhhhhh.
In those messages, each hhhhhhhh field will be replaced with an IP address, in hex. So, converting the needed values from hex to decimal is about the hardest part of this method. The IPCP : Received and accepted IP address . . . message indicates the gateway's IP address. The IPCP : Changing IP address . . . message's to field indicates my (new) IP address. I can quickly check my hex to decimal conversion for that one with WINIPCFG or IPCONFIG. The two IPCP : Accepting . . . messages provide IP addresses for DNS servers.
I haven't found a netmask value in PPPLOG.TXT. So, I figure one by XORing my IP address with the gateway's IP address. An XOR's result is a 0 bit for each pair of matching bits. And, a 1 bit for each pair of opposite bits. Then, I complement or reverse the XOR result's bits and zero any 1(s) to the right of the Complement's most significant 0 bit. If the most significant bits of the two IP addresses don't match (so that the Complement's most significant bit is 0) I use a netmask value of 0.0.0.0. For example:
Hex values Decimal values
my IP address: 04 BF 74 13 = 4.159.116.19
gateway IP address: 3F D7 1D 25 = 63.215.29.37
=================== =========== ============
XOR 3B 68 69 36
=================== =========== ============
Complement C4 97 96 C9
=================== =========== ============
netmask: C0 00 00 00 = 192.0.0.0
^ ^
| Least significant hex digit
Most significant hex digit
Once I have all the values discussed above, I can edit or update a copy of
IP-UP.BAT and run the rest of my regular post-dialing glue script, as if it
had been produced automatically.I also noticed my Internet sign-on ID and password, in clear text in PPPLOG.TXT, a lot more often than I might have expected! So, that PPPLOG.TXT file is something that will have to be kept away from sophisticated visitor(s).
Well, what else is there to say? Once you've successfully installed NDIS3PKT.386 into your Windows system, it just works. Unless it's a crippled version that has decided that you've sent or received enough packets. Then, it just stops. Frustratingly, that comes all to quickly. If you access my Web site via its IP address, so you don't use up packets for name look up, you're still only able to retrieve a few of my pages before the crippled versions shut down. (Perhaps you can stretch that out a bit by upping your mss= configuration to 1500.)
I've noticed just one small limitation in the support provided: There doesn't seem to be any support for the Packet Driver function that returns statistics. So, a program like PKTSTAT.COM can't get anything to report. (I used to mention a second issue here. But, I've found I was mistaken about that one.)
If I have a serious problem with the ndis3pk2.zip package, it is with the "network license management facilities" that may have been added sometime since version 2.5. These are only mentioned in the license agreement on the order form. And, I suspect that the crippled version doesn't run long enough to demonstrate the operation of these facilities. So, I can only imagine what they might consist of. If these facilities might bother you, as they do bother me, I suggest that you read the license agreement very carefully before sending Dan your check.
In February 2006, I installed a Windows 2000 Pro (SP3) system to dual Boot, along with my existing Windows 98 SE system, on Digerydo. This finally gave me an installation meeting the requirements of the SwsVpkt1004.zip package, which I then installed. With the SwsVpkt package, Packet Driver interface(s) don't automatically start showing up in your DOS windows, after installation. Rather, the package's installation into your Windows system enables SWSVPKT.EXE to work like a "Real Mode" DOS Packet Driver, in your Windows DOS windows. SWSVPKT.EXE allows a "Hardware IRQ" and a Software Interrupt to be specified. By default, these are 7 and 0x60. I don't know what that Hardware IRQ specification is for.
I made sure that the Software Systems virtual packet driver was bound to Digerydo's Ethernet card, in the Windows 2000 Local Area Connection Properties. Then, I ran SWSVPKT.EXE with its defaults, in a DOS window, and started testing. I was immediately able to PING and TROUT other systems on my LAN, using DOS tools! However, I wasn't able to establish a TCP/IP session, with any of the FTP and HTTP servers on my LAN, using DOS clients. What could the matter be? I very slowly realized that connectionless UDP protocols were working. But not TCP/IP, which involves establishing a session.
Finally, it occurred to me that perhaps the SwsVpkt1004.zip package's SWSVPKT.SYS lacks the "tcp multiplexer" function that the ndis3pk2.zip package's NDIS3PKT.386 provides. I went back to the Windows 2000 Local Area Connection Properties window and un-checked the (Windows) Internet Protocol (TCP/IP) also binding to the Ethernet card. Sure enough, the DOS window's SWSVPKT Packet Driver then started working for all protocols!
Having reached this point, I expected that the (Windows) Internet Protocol (TCP/IP) binding to the Ethernet card could be safely restored. As long as I give my DOS Packet Driver applications IP address configuration that is different from my (Windows) Internet Protocol (TCP/IP) IP address configuration. This has proved to be the case. So, for Ethernet cards, at least, the SwsVpkt1004.zip package resembles the ndis3pkt.zip package more than the ndis3pk2.zip package.
I haven't secured my Windows 2000 installation, yet, to the point where I can trust it to the Internet without the protection of an external firewall. So, I haven't dared try my Windows 2000 system's Dial-up Networking, yet. Therefore, I am not able to say whether a Software Systems virtual packet driver binding to a Dial-up Modem is able to coexist with a (Windows) Internet Protocol (TCP/IP) binding. It might not. Because, in the Dial-up Modem case, there is rarely ever more than one IP address available for use. So, the dual IP address configuration bypass, described above, won't apply.
If the two can't coexist, the (Windows) Internet Protocol (TCP/IP) binding, to the Dial-up Modem, will have to be unchecked while the Software Systems virtual packet driver uses it. If Windows tools are needed for determining a connection's IP address and gateway's IP address, this may make dial-up connection setup very difficult. I need to finish securing my Windows 2000 installation and give this issue further study.
In the summer of 2010, I got my first Windows XP system. A 2004 vintage Dell Optiplex GX270 I call Barnaby. Barnaby has a very fast 3185 BogoMIPS processor, 128 MB of RAM, an Intel 82540 based "Gigabit Ethernet Controller", and Windows XP (SP2). Using the Administrator ID, I installed the Software Systems Consultants SwsVpkt1005.zip package in it. The results are quite similar to what I've related for the SwsVpkt1004.zip package and Windows 2000, above.
Something I've noticed since 2006 is that the SWSVPKT program has -l and -a
command line options for dealing with systems that have multiple networking
interfaces, or adapters. (Command:
SWSVPKT -h
to get a complete list of its command line options.) The command:
SWSVPKT -l
gives one a numbered list of the system's interfaces or adapters. Then:
SWSVPKT -an
may be used to specify that SWSVPKT should use interface or adapter n.
As with my Windows 2000 system, I haven't got to the point of putting my
Windows XP system on the Internet, except behind an external firewall.
So, I still don't have any experience in using the
Software Systems Consultants package with a dial-up networking
interface.
Did I leave you stuck in a full-screen Windows DOS window back near the beginning of this section? Use Alt-Enter again to change it back to a standard window. Or, use Ctrl-Esc to go to the Windows Start Button. Or, hold down Alt and use the Tab key to step through icons for all of your suspended windows. When you release Alt, the then selected icon's window will be activated.
See you on the 'net.
Fred C. Macall K8GIV
27 October 2021
