Magazine article Online

Conflicting Device Drivers and CapAccess

Magazine article Online

Conflicting Device Drivers and CapAccess

Article excerpt

This month in PC Monitor we'll look at a technique for coping with conflicting PC devices by switching between sets of device drivers, and briefly discuss the latest "Freenet" style public-access computer network, Washington DC's CapAccess (see sidebar).

SWITCHING GEARS

Software steadily becomes more complex, and programs require more and more of a PC's resources, such as RAM, CPU cycles, and hard disk space. At the same time, users are putting an increasing variety of sophisticated hardware devices into their PCs. As a result, it can sometimes be difficult to make all the required software and device drivers get along well with one another. Often different devices will want access to the same RAM address or hardware interrupt, causing a conflict whereby neither one will work. With the introduction of improved memory management tools in DOS 5.0, users have more flexibility in how and where device drivers are loaded in memory. By rearranging these drivers in different combinations, usually conflicting applications can be coaxed to work together.

IRRECONCILABLE DIFFERENCES

However, getting to that end result is often a time-consuming process of trial and error. It may turn out that certain devices or programs will never be able to live together in peace. In such cases, users can resort to an old but workable compromise: setting up different versions of CONFIG.SYS, AUTOEXEC.BAT, and any other required "control" files, and switching between them. This is clearly not the best solution, especially if the two offending applications or devices need to share data. But sometimes it is the only solution. These days, it is not unusual for one PC to have special device drivers for a high-resolution video board and monitor, scanner, CD-ROM player, network interface card, network software, mouse, and memory management software. Some combinations of these devices just may not work, and the only way to use some of them is to switch to special versions of the control files. The PC usually must be rebooted after each "session," and a different set of device drivers loaded. With some careful use of batch files, this process can be made relatively painless.

THE BAD OLD DAYS OF CD-ROM

Many readers may remember when this type of "juggling act" was practically standard operating procedure in the early days of CD-ROM drives, before the introduction of the Microsoft CD Extensions to DOS. Every CD software product had its own proprietary device driver to work with different CD drives. Problems arose because each of these device drivers had to be loaded when the PC booted, and each expected to be the only one for that drive. Therefore, a different copy of the CONFIG.SYS and AUTOEXEC.BAT files was needed for every product. The PC had to be rebooted between using each one so that the next set of device drivers could be loaded. Thankfully, the Microsoft Extensions brought an end to that brand of anarchy, at least in the CD-ROM realm. However, there are still times when that approach is necessary to resolve resource conflicts. The greater the variety of devices attached to a PC, the greater the chance that this type of solution will be needed.

A NETWORK EXAMPLE

For instance, we work with a token ring local area network in my office. Our network operating system has device drivers that work directly with our token ring network interface cards. For normal use of our LAN, this works very well. In addition to our local LAN, we have TCP/IP software that allows our PCs to use connections between our token ring and other networks to access the Internet.

The TCP/IP software we use requires an additional "LAN support program" to be loaded, and we must also use a network driver for our interface cards that is

slightly different from our normal one. When we try to use our LAN software with these extra items loaded in memory, we experience a number of undesirable side effects, such as spurious read/write errors from our network drives, difficulties copying files between file servers, and a general reduction in response time between the PCs and the servers. …

Search by... Author
Show... All Results Primary Sources Peer-reviewed

Oops!

An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.