Here is a neat summary of the DOS PPP drivers: http://www.oldskool.org/guides/tvdog/internet.html#I
...but, someone has already raised this question: Do you have a "counterpart"? I mean - a dial-in service answering with a modem and a PPP stack. Or at least a null-modem connection to a PPP "server", such as pppd running on Linux. Or possibly Windows running the "server side of RAS" would work too. You have mentioned that one of the PC emulators contains a "Hayes modem emulation". What is the use for that, exactly? What does it do? Suggestion: it answers to a few AT commands, including ATD, to which it responds with CONNECT, and puts you through onto a serial line - either a physical outside COM port, or e.g. an emulated virtual COM port in your host OS (where the emulator / VM is running). This might be useful to bamboozle some old DOS software, that insists on dialing out a modem (when accessing a serial line for whatever final purpose) - while in reality all you have is a null-modem cable, or a virtual equivalent thereof. The other option would be, that the "modem emulator" also provides the "server side PPP stack", effectively to set up a network connection, probably TCP/IP (although in principle, PPP can encapsulate other L3 protocols, such as Novell IPX/SPX or MS NetBEUI if I have all the ancient buzzwords right). Note that theoretically, at some sub-layers, PPP is really symmetrical, a conversation between equal parties. The client/server distinction stems from one party asking the other to authenticate, again using a modular mechanism supporting several protocols. For your practical purposes, these details are somewhat esoteric... Should you be interested, try reading RFC1661. If you don't insist on PPP / dial-up, and you really mean "I want to open Google in Arachne", just go down the "packet driver" route. You will save yourself quite a bit of hassle (configuring PPP). If OTOH it is the pain that you are after, go ahead with PPP client side and server side :-) and the follow-up networking stuff on the server part. Frank > > I'm not looking for anything out of Qmodem specifically. I'm > searching for a TSR that handles dial-up networking in the background > while I use TCP/IP utilities like PING, TRACERT and FTP; and/or a web > browser like Arachne. > > Brandon Taylor > > > From: Frantisek Rysanek <[email protected]> > Sent: Wednesday, April 24, 2024 4:52 PM > To: Brandon Taylor via Freedos-user > <[email protected]> > Cc: Brandon Taylor <[email protected]> > Subject: Re: [Freedos-user] Dial-up emulation? > > Hello there Brandon, > > to me the key question is - what do you expect of Qmodem? > What would you like to achieve in / by using that program? > I've never used it, but I figure it would be a "terminal emulator" > with some added candy. An analog (predecessor, really) of Putty or > Hyperterminal in Windows. > > A terminal was originally a hardware device, having a screen and a > keyboard. I believe the rows of text on the screen were an evolution > / innovation after line printers. The text no longer rolled on paper, > now it rolled on a screen. The terminal needed to connect to > something, typically a relatively large computer (like an early UNIX > or mainframe machine), and the computer presented a command-line > interface to the user using that terminal. A single server could > cater for several terminals simultaneously, already back then. > > Later, when PC's and other computers became common-place, the > so-called "terminal emulator" programs allowed you to use your PC > (which is a pretty versatile computer) as a dumb terminal = to > display what arrived by an RS232 serial line, and to send your > keystrokes to the opposite party. You can actually connect two > terminals (or emulators) together over a cross-over RS232 line (also > called a Null Modem) and chat with each other... > > A modem is a device that originally allowed two parties to connect > over a phonecall, via the POTS/PSTN (telephone network). You first > needed to talk to your modem a little, to have it dial out the call. > If the call got picked up by an opposite modem, the two modems would > establish a "virtual serial line" spanning potentially hundreds of > kilometers. You could then chat or transfer files with a friend > (terminal emulators supported file transfer protocols such as X-modem > and Z-modem), or there were machines called "bulettin board systems", > nowadays I'd call them early servers, that you could dial into to > download or upload files, maybe do a bit of messaging... I don't > really have much of a clue what these could do, because this was > before I got my hands on a PC with a modem :-) Obviously you could > dial in remotely into a UNIX machine and work in its command line > "shell" = work with files, read and send e-mail, use NNTP newsgroups > and whatnot. > All of the above was possible using a PC with a modem and a terminal > emulator - I assume your Qmodem belongs to this category. > I wouldn't call this usage style "the internet", except maybe in a > very broad sense :-) > > RS232-style async serial lines, and their modem-based long-distance > extensions, were also useful for other styles of traffic. > > As a side note, I'd mention UUCP, as a distributed worldwide e-mail > system, predating TCP/IP-based SMTP (in practical popularity, if not > by actual age). There were in fact several e-mail standards before > SMTP, and UUCP was one of them. UUCP was an "open standard" - unlike > other e-mail protocols/systems that were proprietary. > > RS232-style direct lines and modem connections can also be used to > transport TCP/IP - in case this is what you mean by "internet". > To "encapsulate" IP packets over an async serial line, you need an > intermediate layer, called a "layer 2 protocol" (IP is layer 3). > See also the layered ISO/OSI networking model (of which the Internet > is not a verbatim implementation). > So for serial links, there were two popular L2 protocols: SLIP and > PPP. During that era, PPP pretty much took over - being generally > more advanced / flexible / extensible... more suitable to the age of > mammoth modem pools and dial-up internet access. > > To start PPP, you generally need two things: > > 1) a piece of software that talks to the modem, to make it dial a > number, and wait for the modem to establish connection (the modem > reports CONNECT <baud_rate> and maybe some further info). > You can do this by hand in a terminal emulator, or by a script, or by > a dedicated unattended piece of software called a "dialer". > > 2) an implementation of PPP. After you dial the modem connection, you > need a way to hand over the established modem session to a PPP > "driver" (protocol talker). > > On top of PPP, you can then run a TCP/IP stack, which in turn gets > used by "internet" applications such as e-mail clients, web browsers, > FTP clients and whatnot (you can also run a server with a PPP > connection to the internet). > > For instance, Windows since 95 have an ex-works "connection software" > called "Microsoft Dial-Up Networking" (if memory serves) or RAS in > the NT-based Windows - which combines an unattended dialer + PPP > stack, and can transport TCP/IP (or other protocols) over that. > > You can also run PPP over a direct RS232 connection (null modem) or > over a pair of leased-line modems. Async serial modems in leased line > mode create a permanent connection, and do not respond to Hayes AT > commands. In these cases, you do not need a dialer (item 1 above). > > As for Internet in DOS: > > Both MS-DOS and FreeDOS can connect to the internet. > But, the first question is, what sort of "experience" you expect :-) > Yes you could probably find some SMTP e-mail client. > Yes there is an FTP client, a Telnet client... > Yes there are even HTTP browsers - but, these were very basic! Think > basic HTTP (hypertext). No JavaScript, hardly any graphics, text mode > preferred. Web standards at the level of mid/late nineties. > > To get "internet" (TCP/IP support) in DOS, yes you need drivers. > It is in fact a driver "stack", because the drivers are layered. > Lower layer drivers are hardware-specific, upper-layer drivers > implement HW-agnostic networking protocols. > In DOS, drivers have the form of "resident" programs - aka TSR = > Terminate and Stay Resident. > > DOS is a rudimentary mono-task OS. At face value, it cannot do > multiple things at once. TSR's are one way to achieve such operation. > A TSR looks like just any other program - except, upon its return to > the command prompt, it hasn't really unloaded itself from the memory. > A piece of its executable code has remained in RAM, with official > approval of the OS, and has probably hooked a hardware IRQ (e.g. from > a network card) or a so-called "software interrupt vector" = really a > service callgate. Thus, it can be invoked in the background, do a bit > of work, and return control to your interactive foreground > application. > > There were actually several TCP/IP stacks (libraries) for DOS, from > different vendors. A key concept, around which those TCP/IP stacks > revolve, is a "network driver interface" (API). > There is the Microsoft family of NDIS2 drivers. > Novell had its own family of ODI drivers. > Then there is the "Crynwr Packet Driver" interface - very popular in > MS-DOS TCP/IP software made by anyone except Microsoft :-) > > In general, if you have a particular application program that you'd > like to use for internet access in DOS, this program probably > contains a particular TCP/IP stack (either linked in, or as an > external protocol driver) and therefore dictates the interface that > you need to make available in your DOS setup = what set of drivers > you need to load. > > For the most popular brands and models of Network Interface Cards > (Ethernet), the vendors still make DOS drivers available. For some > cards, you can get a hardware-specific "crynwr packet driver". > Alternatively, you will also find HW-specific NDIS or ODI drivers. > Note that if you need a "packet driver", but all you can find is an > NDIS or ODI driver, do not despair - there are generic ndispkt and > odipkt "shims" to provide a Crynwr interface on top of an NDIS or ODI > hw-specific driver. > > I recall that there were also at least two implementations of a PPP > packet driver for DOS. One of them was a nice but proprietary package > called Klos-PPP. I don't recall the name of the other free PPP stack. > Those two stacks both could dial out via a Hayes modem, I seem to > recall a chat-script, and once the modem connected, start PPP and > serve the Crynwr interface on top. > > Do you need modem and PPP for internet access from DOS? > Definitely not! If you're speaking emulators, just check what legacy > NIC the emulator emulates. You will likely find one of Intel gigabit, > Intel 100Mb, Realtek RTL8139, NE2000 or some such. > So you enable the NIC in your emulator, and then you just need to > find the old DOS driver for that NIC. > You also need some know how, about how the driver stack fits > together. > I'd say that the PPP stack with a dialer would take more conventional > RAM (it's a TSR, see) compared to an Ethernet NIC driver. No need to > mess with PPP, unless of course you enjoy the nostalgic value. > > If you're interested to find out e.g. what web browsers could run on > top of a Crynwr packet driver, I recall that there were DOS builds of > Lynx and Links, and a graphical browser caller Arachne. > > I also recommend you to check Michael Brutman's mTCP utility pack, as > well as his homepage - it has many explanations and links to further > reading, on the broad topic of DOS networking and the (Crynwr) packet > driver interface. > http://www.brutman.com/ > The website and software keep receiving updates! > > If this is overwhelming, well there you have it :-) > On my part, questions to the point are always welcome. > You have my sympathy for being curious. > > Frank > > > > > Indeed, I'm using an old-school program called Qmodem. My question > > now is – would I be able to use the Internet using the emulated > > modem? > > > > Brandon Taylor > > > > > > From:Jim Hall via Freedos-user <[email protected]> > > Sent:Tuesday, April 23, 2024 10:12 PM > > To:Discussion and general questions about FreeDOS. > > <[email protected]> > > Cc:Jim Hall <[email protected]> > > Subject:Re: [Freedos-user] Dial-up emulation? > > > > > > > > On Tue, Apr 23, 2024, 9:38 PM Brandon Taylor via Freedos-user > > <[email protected]> wrote: > > Since FreeDOS doesn't support physical network hardware (even if > it's > > emulated in a program like PCem or 86Box), I figure there's no way > > FreeDOS is gonna be able to connect to the Internet, right? Well... > > > > The developers of the 86Box project have recently implemented > > emulation of a Hayes-compatible dial-up modem. So my question is... > > will FreeDOS support the emulated modem? > > > > > > Well, it's not that "FreeDOS" would support the Hayes modern, but > > that terminal/dialer software would then be able to. FreeDOS is not > > like Linux, which uses a Hardware Abstraction Layer (HAL) to support > > the hardware directly. FreeDOS, like any DOS, does normal DOS things > > and leaves certain hardware access (like playing sounds through a > > sound card, or accessing a network to browse the web or check email, > > or dialing out through a modem) to other software. > > > > So if you had a terminal/dialer program like Procomm or Telix, then > > yes, I expect you'd be able to dial out through this emulated Hayes > > modem from FreeDOS. > > _______________________________________________ Freedos-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
