The Answer Guy 28: LOADLIN.EXE, Plug & "Pray" and "Win(Lose)Modems"

#### "Linux Gazette...making Linux just a little more fun!"

# The Answer Guy

#### By James T. Dennis, answerguy@ssc.com
Starshine Technical Services, http://www.starshine.org/

### LOADLIN.EXE, Plug & "Pray" and "Win(Lose)Modems"

From Allen R Gunnerson on Sat, 11 Apr 1998

I was told be several people that I can configure my loadlin so that my plug n play stuff in Win95 would be detected by Linux. Right now, if I use dos mode, I lose all my hardware. I have tried to configure my LTWin modem for Linux with no luck.......

> I think you have two different issues embedded in here. Plug -n- Play (hardware) is a fairly lame attempt in recent years to create PC hardware that autoconfigures itself. When talking about ISA cards this is mostly just marketing fluff that fails in many configurations -- and is widely called "Plug -n- Pray" by many of the support reps that I know.
> "WinModems" are another issue.
> Let's start with the first issue:
> A typical PC has two (or three(*)) buses. System "bus" is a hardware interface, with slots or connectors to multiple devices. The original IBM PC (and XT) had 65 pin (8-bit) slots. With the introduction of the AT IBM placed another connector "end-to-end" with the original 65 pin slots -- which allowed many old "8-bit" cards to be used in AT and even in modern systems. These are called "16-bit ISA slots." (The term ISA or "industry standard architecture" was coined after the fact -- near the introduction of MCA (micro-channel architecture) and EISA (Extended ISA). These hardware specifications have almost completely disappeared).
> - (Technically a SCSI host adapter is a hardware bridge between your system bus and its own SCSI bus. This is actually a subsystem -- so that doesn't really count as a "system bus").
> As the industry fought over MCA vs. EISA (largely resulting in the markets rejection of both of them -- due to the crass attempts at exploiting proprietary designs by major vendors of each) the clone manufacturers -- particularly the motherboard and video engineers -- created a high speed 32 bit bus called "VESA local bus" or 'VLB' for short. VESA is the "video electronics standards association" although there were eventually a variety of disk and network controllers that plugged into VLB slots.
> These were the rule for late 386 and throughout most of the 486 era (if a period of only 5 years can be called an "era").
> With the introduction of the Pentium, Intel also created a number of chipsets and introduced a new bus/interface called "PCI" (sorry I don't remember what the abbreviation stands for -- something like "peripheral to CPU interconnect").
> I don't know alot of the low level details about PCI vs. VLB. I've heard that there were very good technical reasons why VLB couldn't be used in Pentium systems. I've also heard that Intel rammed their spec down everyone's throats in a way that has resulted in their clear domination of the chipset market as well as the CPU market.
> Prior to this there were a number of companies selling chipsets (all the support circuitry that connects the CPU, the memory, the bus(es), and other interfaces to the motherboard (like the keyboard connector). Now there are practically no other companies selling chipsets. It seems that all of the motherboard manufacturers have been forced to use various Intel chipsets (Neptune, Triton, etc). I've heard that some of these have had bugs as notorious as some of their CPU's.
> One problem that has persisted through all of this is that a typical PC owner has had to manually keep track of how each device on the system was integrated with the others. Any individual card might require an IRQ (interupt request), some I/O port addresses, a DMA channel, and/or some "reserved address space" (for memory mapped I/O between the 0xA0000 and the 0xFFFFF regions).
> There are only a pitifully limited number of each of these resources. The original PC only had 8 IRQ lines on a single PIC (programmable interrupt controller). A modern PC still only has 15 -- accomplished by "cascading" one PIC off of the IRQ 2 of the other.
> Of these the system timer, keyboard, the real-time clock and the FPU (floating point unit) are already taken up -- as well as two serial ports, a hard disk controller (IDE, SCSI, or any other). Usually there is also one associated with each LPT port and one for any bus mouse interface that we have. That leaves nine to be distributed between each of our SCSI, ethernet, sound and other cards. Sound cards often take up two of these incredibly scarce resources.
> As if the scarcity weren't enough of a problem, complexity -- the fact that every user has to keep track of these for every system -- was a major kicker. This has been a major failing of the PC architecture. The priority of "backward compatibility" as left us with a "backwards architecture."
> Plug and Pray was an attempt to relieve some of that complexity (though it does nothing to resolve the underlying problems of scarcity -- which are deeply ingrained design limitations). It has helped somewhat -- but it requires that all of the components of the systems (hardware and OS) conform to the same spec. A PnP system can work with some old ISA cards, some of the time. The real problem comes when you use multi-boot configuration (as you're doing between DOS and Linux) -- since each of these may try to "tune" the configuration to itself.
> The "universal serial bus" (USB) and the "Firewire" specifications offer some hope of relieving the issue of scarcity. Like SCSI these provide an adapter to a semi-intelligent "bus" of external peripherals. In effect the adapter uses one PC IRQ and I/O port range -- and negotiates/arbitrates among many devices on its own bus using its own discrimination logic.
> However, it looks like it will take some time for practical devices to become widely available in USB form. So far there are a few digital cameras and scanners that support it --- and no modems, ISDN TA's, terminals (or null modem adapters), X-10 powerhouse, or other toys. Ideally someone would make a couple of models of parallel-USB and RS232-USB bridges so I could use existing devices (like parallel port Zip drives and flatbed scanners) with my new USB equipment. It looks like the hardware companies would much rather force us to all buy all new peripherals --- and to get peripherals that aren't usable on any platform other than a PC.
> Naturally we can see that Microsoft will benefit from these and any form of "WinModem" or proprietary software drivers for peripherals. I can't think of anything that will perpetuate the status quo of this market more effectively than that short-sighted attitude among hardware vendors.

##### Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 28 May 1998