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 <frantisek.rysa...@post.cz> Sent: Wednesday, April 24, 2024 4:52 PM To: Brandon Taylor via Freedos-user <freedos-user@lists.sourceforge.net> Cc: Brandon Taylor <donnie126_2...@hotmail.com> 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 <freedos-user@lists.sourceforge.net> > Sent:Tuesday, April 23, 2024 10:12 PM > To:Discussion and general questions about FreeDOS. > <freedos-user@lists.sourceforge.net> > Cc:Jim Hall <jh...@freedos.org> > Subject:Re: [Freedos-user] Dial-up emulation? > > > > On Tue, Apr 23, 2024, 9:38 PM Brandon Taylor via Freedos-user > <freedos-user@lists.sourceforge.net> 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 Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
