Archive for November, 1994

Life As A ‘90s Game Developer Must Be Tough

Tuesday, November 8th, 1994

(This column first appeared in the November 8, 1994 issue of PC Graphics Report)

Yep, I actually used to write video games. Back in the early days of the PC, I developed a graphics animation library on the PC, and a game called Fleet Sweep, a Space Invaders take-off that ran on the original IBM PC on a CGA display. If you look for it hard enough at a software flea market, you might actually find a copy of it. Around the same time, I also helped port JumpMan to the IBM PC and PCjr.

The sort of animation routines I developed were state-of-the-art for that era. I designed and developed routines to handle software sprites, player-missles, flicker-free overlap of animated objects, and even double buffering via selective rectangular updating. I also developed a graphics editor to go along with all the animation code. Of course, back then, state of the art was all 2-D stuff. Rather flat, but with enough action to still make your heart rate surge. Alas, except for some die-hard end users, no one took games seriously at the time, least of all vendors of PC hardware technology.

When I look around me today, I notice that everything pertaining to game development has changed. First of all, the game technologies have totally eclipsed the sort of technology I developed in the early ’80s. Where 2D was once the master, games have evolved to an action packed 3D look. It reminds me of the change painting went through once artists realized they could paint in perspective back during the middle-ages. With the new technology, and dropping PC costs, there has been a resurgence in the popularity of 3D games.

Where once games were an occasional pastime, they are now a complete obsession. Whole markets have been built around games, most notably the multimedia market of sound boards and CD-ROMs. As a result, it appears that game developers are no longer deemed third class citizens. Game developers now actually hold celebrity status. In a world originally dominated by the Borlands, Microsofts, and Lotuses, we now see companies like 47-Tec, Software Toolworks/Mindscape, id Software, Access, MicroProse, and others dominating the PC skyline.

The Game Developer Interface
Back over a decade ago, when I was a game developer, PC companies couldn’t care less that the company I worked for developed exciting computer games. For that matter, our efforts were frequently scorned. No one took game developers seriously.

It astounds me to no end how that scenario has changed. Now, it seems that game developers need to hire dedicated liaisons to cope with the time and bandwidth demands various PC software and hardware companies are attempting to impose on them by lobbying them to use their products and technologies. I’ve tried to categorize the groups I see lobbying for the attention of game developers, and come up with quite a large number:

2D API Vendors
This category is primarily focused around Microsoft and its attempt to get game developers to move to Windows via WinG. There are a few others in this group as well, but none significant enough to list.

3D API Vendors
This group seems to grow on a weekly basis. Current “members” include Argonaut, Criterion, Intel, Microsoft, RenderMorphics, and Silicon Graphics. All of these companies are offering some way of generating and manipulating 3D images in software, with some level of hardware acceleration occasionally recommended (especially in the case of SGI’s OpenGL).

Tools Providers
There are several types of tools providers. There are those who have created products for other markets, but have accidentally discovered that their products are well suited to the games environment. This group includes Autodesk with 3D Studio and Animator Pro, as well as Macromedia and Asymmetrix with their respective products.

There are some games companies that have managed to build engines that are portable, such as what id Software has done with the Wolf-3D engine by licensing it to Capstone for use in Corridor 7.

Finally, there are companies who have designed products specifically for the game market. Usually, these are expensive, vertical market applications, some of which may require additional hardware. Wavefront is an example here. Tools providers are perhaps the least intrusive lobbying group, in the sense that they have proven their worth over time. They also seem to be the least pushy, which sits well with game developer attitudes (i.e. they tend to prefer passive selling vs. hard selling).

Digital Video
Say hello to MPEG, Indeo, Cinepak, and countless other methods for compressing and playing back video on a computer. Some require royalties, some only require use of the game developer’s name in press releases, and some change their focus and approach on a regular basis.

Sound Interfaces
This category covers both hardware and software. There are a handful of key sound driver suppliers, who offer universal sound APIs under DOS to a large number of different sound boards. There are, of course, the large number of sound hardware vendors, who have wised up to the point that in addition to their own proprietary interfaces, always make sure to provide some backward compatibility to de facto industry standards. Of course, the companies responsible for those standards also need to advance their technology. Creative Labs, for example, has a developer’s program, which, in exchange for attending one of their annual seminars, offers free hardware.

OS Companies
Well, let’s see… there’s Microsoft with Windows 3.1, IBM with OS/2 3.0, and Microsoft with Windows 95. Microsoft is coming up with all sorts of reasons (and tools) for developers to switch to some flavor of Windows. Key benefits touted: Windows makes installation and configuration easier (in some ways, perhaps); Windows offers WinG and DCI support, which makes it almost like DOS frame buffer access (isn’t that what DOS is for?); Windows has integrated sound support (but developers complain about its lack of quality and real synchronization capability); and Windows 95 will probably support 3D via 3D DDI (when and if still to be seen). IBM is just starting to offer OS/2 as a games platform, but will probably have a pretty difficult time going up against the Microsoft momentum.

3D Hardware
This will be the major push in 1995, it appears, with Artist, Matrox, 3DLabs, Yamaha, Cirrus Logic, SPEA, and Kubota all having announced new 3D acceleration hardware, and at least 6 other companies having made overtures in that direction in the last few months. Each one of these devices is interfaced with differently, and each offers differing levels and types of graphics acceleration. In other words, this area is a total mess. If a leader emerges out of the 3D API battles, and that API is viable with the 3D hardware being unveiled, there might be some hope for this new and growing category, but right now there seems to be too much noise resulting from competing overtures to developers.

2D Hardware
2D hardware seems rather passe in comparison to sexy 3D hardware, doesn’t it? Ironically, games developers predominantly still use dumb frame buffer animation. This means that they don’t use even the simplest acceleration features commonly found in 2D SVGAs. And, even so, everyone wants the game developers to make the leap to 3D APIs and  hardware… Nevertheless, a few pragmatic folk are trying to get games developers to take the 2D hardware acceleration step first. The benefits in game performance are significant, as ATI’s Fox demo at a recent GamePC Consortium meeting demonstrated.

Input Device Companies
If there is game developer lobbying category struggling to emerge, this is it. All PCs have keyboards, and most have mice. All the games I’ve tried support these two input devices. Beyond that are a variety of joysticks and game controllers (both are offered numerous flavors, and all are reasonably well supported in compatibility modes). Beyond that are 6 dimension (6D – X, Y, Z, roll, pitch, yaw) of freedom input devices. The 6D devices are sparsely supported at best, but with 3D-style games getting a lot of attention, the 6D input devices are a natural complement. But there are a lack of these devices at affordable price points. The least expensive appears to be the Logitech CyberMan (around $80), but without much finesse. Spacetec IMC is going to be releasing a “Space Player” (based on their Spaceball technology) for games shortly in a slightly higher price range, and beyond that, a few other manufacturers are also looking to release 6D input devices. The problem these manufacturers face is that they all, due to the lack of a uniform API, still have to peddle their devices individually to the game developers in order to convince the developers to free up precious resources to support the new input device. For some reason none of the 3D API companies I spoke to at last week’s GamePC meeting seemed at all interested in providing a 6D input API as part of their interfaces. Seems like a major opportunity is being ignored, since proper manipulation of 3D space is perhaps the biggest limiting factor in 3D application acceptance.

Standards Groups/Consortiums
VESA’s promoting VBE/AI (VGA BIOS Extension/Audio Interface) and the forthcoming VBE/Core 2.0 specification (which includes protected mode VGA frame buffer access) to game developers, and The GamePC Consortium is trying to get all the groups listed above together with the game developers to figure out how to get better game  performance out of PCs. Both efforts end up demanding even more time from game developers to keep up with.

So, by my count, there are at least 40 different entities (and that’s not even counting Microsoft and Intel multiple times for their different efforts) vying for the attention of all game developers. That means if each game developer devotes just a single hour to each vendor every couple of weeks, it requires a full time employee, what with the reports and summaries that person would have to generate. The reality of it is that some vendors alone take 40 hours a week while others require virtually no time for interaction. Scary use of bandwidth either way.

What Many Game Developers Really Want
There appears to be quite a bit of disparity between what most game developers seem to want, versus what all the vendors appear to be trying to sell them.

At the first GamePC Consortium meeting in late August, a number of developers spoke up about this particular topic, and here’s a summary of what the game developers wanted:

  • No other software getting in the way
    Game developers are typically performance freaks. That means that they don’t want anything getting between them and sheer performance on the systems their games are running on, which means that chunky operating systems, like Windows and OS/2 don’t really fit the bill, and which is why DOS, for all its frailties is such a popular games platform.
  • A stable and consistent boot and install environment
    Currently, DOS games (the majority) each seem to require specific boot environments, including varying (although often unrealistic) amounts of free low memory, disk caches (or none), memory managers (or none), a VESA VBE interface for the graphics board in the system, certain types of sound boards, and possibly some amount of extended memory. Windows fits this bill, to some extent, except that game developers don’t want Windows running when their game is running. Their game should have complete control of the system it’s running on, when it’s running. Alas, this is inherently contrary to the Windows design philosophy.
  • Wanting to transparently support a variety of hardware
    This does not mean putting extra layers upon layers of software APIs between the game and the hardware. It means that hardware designs should be compatible and consistent wherever possible, and only minimalistic APIs should be present, if absolutely necessary. Game developers don’t want to have to add special support for each type of graphics board and sound board out there (unless they get paid a lot to do it or find it to be really neat – the former is more likely than the latter). Windows fulfills part of this, but really gets in the way from a minimalistic API perspective.
  • The ability to double buffer/page flipping
    This seemed to be the major hardware feature request from game developers wanting to do animation. All it involves is being to create a scene on the graphics board, off-screen, and being able to flip to the display of that area during a vertical blank. Then the other page on the board gets updated and display in the same fashion. Ironically, most modern graphics boards are capable of this at lower resolutions (like 640x480x256 colors), but no APIs I know of actually take advantage of this hardware capability, yet.
  • Being able to trigger an operation on a vertical blank
    This includes page flipping, palette cycling, and general animation. This was the second most requested feature.
  • Being able to use off-screen memory on the graphics board
    This feature is related to the page flipping request, but reinforces the requirement for consistent graphics hardware memory architectures, since such consistency would allow developers to intelligently use off-screen memory for storage of sprites, textures, and text. If such consistency existed, then game developers would be much  more likely to use BitBLTs and related graphics acceleration features. Tied to this request was linear frame buffer access, as most developers are using, or starting to use, DOS extenders.
  • Being able to switch resolutions on demand
    This allows game developers to select resolutions best suited for a given task, such as 320×200 for digital video playback, and 640×480 for other types of animation or display.

3D APIs just aren’t that important yet
Surprisingly, the game developers present at that GamePC meeting indicated that while they thought 3D was an important technology, it just wasn’t that important to them yet. They were more concerned about getting current games done for the ’95 Christmas season (which means finished software by next summer) then figuring out what to do with 3D.

Hardware Vendors vs. Game Developers
In all the varied discussions between these two groups I’ve been witness to of late, the hardware vendors universally seem to want to force game developers to use Windows, because that’s where all the vendors have focused their development efforts. Additionally, with the exception of a DOS MPEG API specification and VESA VBE (both worked on by a small subsets of the lobbying hardware vendors), none of the hardware vendors have bothered to get together to create DOS APIs and support for game developers. And DOS DDKs for the various 3D APIs appear to be difficult to come by, based on my experience, further hampering development in the DOS environment.

At the other end of the spectrum, the game developers are largely happy with DOS and comfortable with the DOS environment. In a few areas (as I pointed out earlier), Windows could be of benefit, but only if the game developers could just switch it off when desired – something that’s not exactly straightforward to do.

All in all, it appears that we’re getting nowhere quickly if vendors don’t listen to game developers and game developers aren’t vocal enough about what they want from vendors. But that’s life, isn’t it?

Evangelists on Every Corner

Tuesday, November 1st, 1994

(This column first appeared in Vol. 6-2 of the Panacea Perspective, circa November, 1994)

It started a few years ago. Certain large companies such as Apple and Microsoft started blessing key employees with the spiritual title of “Evangelist”. It was the Evangelist’s mission to go forth and spread the gospel of whatever product and/or philosophy the company wanted the masses to worship.

At first, it was a novelty. You’d get a business card, read the title (“Software Evangelist”, etc.) and a beatific smile would form on your face, expressing a sentiment similar to that of your grandmother about to pinch your cheeks and tell you how much you’ve grown since she’s last seen you. In other words, it was cute.

But, as time has shown with Barney the Purple Dinosaur, even cuteness has its limits when it goes ballistic and is perpetually “in your face”. Nowadays, it seems like everyone has an evangelical title of some sort. The irony of the whole thing is that in the 80s, evangelists (of the television kind) were perpetually paraded in front of us as examples of the depravity of human nature. Do we really want technology evangelists associated with the likes of Jim and Tammy Faye Bakker, Oral Roberts, or Jimmy Swaggert?

What does the title of Evangelist really mean in our industry? A quote from a recent elevated Microsoft evangelist was “Whenever Microsoft designates a person to be an evangelist in a given technology, it means that Microsoft intends to dominate that technology area in the near future.” That’s an uncommonly honest and blunt definition, but it does say it all.

However, with the blatant overuse of the Evangelist title, it’s not clear that all companies who employ evangelists have the position as clearly defined as Microsoft. So, as a means to allow companies with differing philosophies to better categorize there employees, we’d like to suggest the following new generation of secular/semi-secular technology titles (imagine them preceded by “Software”, “Hardware”, etc.):

  • Agnostic – Believes in the concept of the technology but not necessarily the implementation. An example would be someone who believes in 32-bit operating systems, but doesn’t really believe in Windows NT, Windows 95, or OS/2 as the proper solution.
  • Anarchist – Believes in whatever seems appropriate at the moment, especially if other people don’t believe in it. May get violent if lots of others actively disagree with them. Amiga fans and people who promote hardware locks fall into this category.
  • Atheist – Doesn’t believe in the technology at all and can’t understand why anyone actually does believe. Workstation Evangelists tend to be PC Atheists.
  • Believer – Someone converted by an Evangelist or the like. Probably brainwashed to the point that they don’t question anything – they accept what they are told without needing supporting facts.
  • Buddhist – Believes in all technologies, and that with time and inner awareness all technologies will ultimately become one. One could argue that Bill Gates could be deemed part-Buddhist as he believes that all technologies will ultimately become Microsoft’s.
  • Communist – Feels that all technology belongs to a single entity, no matter who actually developed it, and that the entity should use such technology to benefit the entity, which should benefit all those associated with the entity. Software pirates occasionally are part of this category.
  • Deity – This is the most knowledgeable person, world- wide, in a given technology field. No one else comes close to that person. This should be an earned position, over  many years of effort, and not given lightly. Sometimes also referred to as God.
  • Democrat – Believes that no matter what the technology is (although it tends to be quite bulky and ill-defined), it should cost more than it brings in, while being freely available to any group of people who claim that they need it, as long as they aren’t rich. Such technology should also be administered by as many people as possible. Coincidentally, the National Information Infrastructure seems to fit the type of technology a Democrat would promote.
  • Gadfly – Is excited about every new technology that comes along, but just for a brief period of time (i.e. until the next cool technology is presented). However, during the brief period of excitement, they evangelize with the best of the dedicated Evangelists. Editors and writers for computer publications are frequently Gadflies.
  • Hippie – Truly feels that all technology should be freely available to all those who want it, and everyone should be happy as a result. Ever hear of the Free Software Foundation and GNU?
  • Libertarian – Doesn’t care what technology anyone else believes in or promotes as long it doesn’t interfere with anyone else’s way of life. Libertarians are proud of the fact that they still use DOS and don’t buy the latest upgrades.
  • Luddite – Fears all technology and wants to see it destroyed. These people are all either locked up or lurking just around the corner.
  • Mercenary – Will evangelize any technology for a reward, usually monetary. Could be one technology one day, and a competing technology the next. Mercenaries frequently take the guise of independent PR & marketing professionals, although some employees have been known to assume the role as well, usually with disastrous results for the employer.
  • Nihilist – Wants to destroy all technology for the sake of its destruction. May pair with the Luddite for convenience’s sake. Needless to say, you don’t want a Nihilist working for you.
  • Preacher – An Evangelist in training.
  • Prophet – An Evangelist whose technologies have time and time again becoming the leading technologies in the market on their own merit. There’s also the False Prophet, who has managed to evangelize leading technologies by coercion instead of merit, and done so many times (see Terrorist).
  • Republican – Believes that while technology can be a good thing, it’s best not to rush things too much. Technologies should be thoroughly analyzed to make sure that  they are safe to start using, and should be administered by lots of smaller disparate groups that should be able to communicate with one another. COBOL is still widely used because of Republicans. Opposite of the Democrat.
  • Scrooge – Favorite line is “bah-humbug” in response to a question about the latest technologies. Also known as an un-Believer. Opposite of the Gadfly.
  • Terrorist – An Evangelist that’s gone over the edge in trying to convert the faithful to his or her technology. Uses market pressure, coercion, threats, and unethical means to force people to adopt his or her view. This title may also be applied to marketing and sales people, as the Terrorist does not need to really have a technical background. Terrorists may also be Mercenaries.
  • Worshipper – A Believer that is too far gone to even consider questioning reality, even as it changes around them. Fans of Gadflies are sometimes Worshippers.

This should certainly provide business card printers with a new wealth of business.

Plug N’Pray

Tuesday, November 1st, 1994

(This column first appeared in Vol. 6-2 of the Panacea Perspective,
circa November, 1994)

It’s the dream of PC support specialists. It’s a technology backed/pushed by the might of Microsoft and Intel. It’s a core part of the PCI local-bus specification. It also doesn’t  work just yet, and it may never work properly.

Plug and Play (or PnP for short) is something that was announced at the 1993 Windows Hardware Engineering Conference (WinHEC), about 18 months ago. The purpose of PnP is to allow peripheral hardware to be inserted into a PC via the normal bus connectors and be automatically detected and configured. In order to support this capability, the hardware has to be PnP aware and software configurable. Microsoft, Intel, and Compaq, the originators of PnP, determined something like it was needed to help diminish the amount of time and effort it takes to properly configure a system when new hardware is added.

Currently, a user putting a new board into his or her system needs to make sure that the board doesn’t use any of the same IRQs, DMA channels, I/O port addresses, or memory ranges as any other piece of hardware in the system. This can be a difficult feat to accomplish because this sort of information is not always supplied by the peripherals  vendors. Frequently, conflicting settings may not be apparent until some obscure software package accidentally enables multiple devices at the same time, and the system hangs.

With a PnP BIOS or operating system, and completely PnP compliant hardware, the system software can determine the exact nature of all the add-in boards in the system, figure out what various resources are needed by the hardware, and then individually configure each component so that the devices don’t interfere with one another.

However, this all works only if the BIOS, the OS, the hardware-specific applications, and all the add-in boards are PnP compliant and work correctly in a PnP environment. The reality is that this will not happen for many years to come. Let’s take a look at why.

Add-In Boards
To date, very few add-in boards support the two basic requirements of PnP – a standard method of unique identification and software-only configuration. The only boards that do are a handful of ISA-bus based boards that have been specifically designed to support PnP. Also, virtually all EISA, MicroChannel, and PCI local bus based boards support PnP in a sense, but the percentage of the overall add-in board market that these boards represent is still quite small, and will probably continue to be so.

The reason for the latter assertion is that EISA has been relegated to being pretty much just for servers, MicroChannel has been quietly shelved by IBM in favor of ISA, VL-Bus, and PCI, and finally, PCI slots in on PCI- capable motherboard account for only 25-40% of the slots – the rest of the slots on the motherboard are usually ISA. And, while PCI is on a majority of Pentium motherboards, it accounts for only a tiny percentage of 486-class motherboards, virtually all of which ship with VL-Bus (basically used as an extension to ISA, and VL-Bus boards tend not to be PnP compliant as a result).

Also, while increasing numbers of PCI-based graphics boards are being shipped, very few of any other kind of add- in board are being turned out and sold in anything other than ISA flavors. Looking at today’s PCs, the drive controllers, CD-ROM controllers, I/O boards, network controllers, and modems are all generally still being cranked out as non-PnP compliant ISA boards. While PCI is the best bus hope for PnP, most add-in boards have no need for the performance PCI offers, and PnP also adds additional cost. Not enough cost to double the price of a PnP compliant add-in board, but enough to make competition difficult when margins are small, as they tend to be with high volume add- in boards.

In an attempt to force hardware manufacturers to make their ISA boards PnP compliant, Microsoft has implied that only PnP compliant boards will be able to receive a  “Windows 95-compliant” seal. Whether this coercion will be effective is yet to be determined, but it is obvious that as a result, virtually no user will be using Windows 95 compatible hardware to run Windows 95. This, of course, makes Microsoft Customer Service’s job a lot easier:

<ring> “Hi. I can’t get Windows 95 to run on my Pentium PC”

“Well, are all of your components certified as Windows 95 compatible?”

“Uh, no. I don’t think so.”

“Well then, we’re sorry, but we can’t help you. We can only support Windows 95 on PCs that are completely and thoroughly Windows 95 certified. Good bye.” <click>

The net result is that since the vast majority of add-in boards in use today, and sold for the next few years, will not be PnP compliant, PnP will not always work reliably.

Operating System Issues
Part of the PnP specification calls for non-PnP compliant hardware to be identified through a complex identification mechanism in the operating system. For Microsoft’s OSes  (such as Windows 95), for example, Microsoft has spent the last couple of years working with vendors to find out how they identify their particular hardware add-ins so that they can put such ID mechanisms into their OSes. Unfortunately, there are so many thousands of different devices out there, some very alike, that the likelihood of such add-in hardware being accurately and thoroughly identifiable (both for type and resource usage) is practically nil. A recent review of a Windows 95 Beta mentioned that it took the software 5 minutes to try and figure out what was in the system, and after all that effort, the detection still reported incorrect information.

Let’s just assume, for the time being, that such identification is an achievable task. The identification and configuration data so gathered then gets put in a registry of installed hardware that the user can manually override, just in case. Of course, this only works for operating systems that have such a capability built in. That automatically rules out DOS, Windows 3.1, versions of OS/2 prior to v3.0 (Warp), and all shipping versions of PC- based UNIX OSes. In other words, no OS currently shipping in any real numbers can properly support a mixed installation of PnP and non-PnP compliant hardware without significant user intervention. That implies that a complete PnP installation in software really only applies to future operating systems. What percentage of current users will be using such future operating systems anytime soon, assuming they actually do work? A few hardy souls, certainly, but not the masses in any near term. And, to top it off, the ability of these new OSes to be able to identify not-PnP hardware still remains in serious doubt.

BIOS Issues
Several manufacturers are currently shipping PnP compliant BIOSes. The BIOS implementations of PnP limit themselves to only identifying and configuring PnP compliant devices in the system. This is a necessary function, since PnP devices need to be configured in order to work with today’s common operating systems, like DOS and Windows. In some systems, the BIOS does the configuration automatically, while in others the BIOS is supplemented with an external utility to let the user aid in the configuration process, if necessary.

The problem we’ve encountered in working with various graphics hardware companies who have been building PCI graphics boards is that BIOS configuration behavior differs greatly among the various brands of BIOSes systems manufacturers use in their systems. For example, some of these BIOSes have refused to map a 1MB ROM into extended memory addresses locations, while others map only a portion of it, and some actually do it correctly. The net result is that manufacturers of new generation PnP compliant hardware can’t rely on the BIOSes to configure things properly, and as a result, may need to supply a custom configuration utility anyway. This makes PnP kind of useless at times. What needs to happen here to make this part of PnP functional is that all BIOSes need to be consistent in how they configure devices. Random configuration serves no one, the end user least of all.

Application Implications
One might not realize it, but there are lots of applications out there that have a definite dependence on how hardware is configured, specifically in order to access the hardware directly. The most obvious are programs that use externally loadable drivers, including environments such as Windows 3.1, or programs such as AutoCAD. In both of these cases, the drivers used for I/O, display, etc., need to be PnP aware. None (or virtually none) are, or will be any time soon.

Many such drivers are PCI aware, which comes with its own set of headaches, as there are at least 4 different ways to try and determine the configuration of PCI-based  hardware, none of which can be counted on to work in all situations. In some cases, only one or two of the methods are available because some control programs, like EMM386, have accidentally prevented the other methods from working. Needless to say, this can be a royal pain for drivers that have to handle device initialization and figure out device configuration as part of that process.

Another form of external driver is the kind that you might normally load/install as part of your CONFIG.SYS or AUTOEXEC.BAT files, such as network drivers, SCSI drivers, CD-ROM drivers, mouse drivers, etc. Again, virtually none of these drivers currently support PnP in any way, and that’s not likely to change as long as there’s legacy hardware (i.e. non-PnP) in circulation.

Finally, there’s a whole set of DOS applications out there that don’t necessarily use external drivers, but still need to access hardware that might have been reconfigured by a “helpful” PnP BIOS or OS. Perhaps the two largest categories of such software are communications packages (which need direct access to modem hardware) and entertainment software (which access sound and game controller hardware). The number of packages in the latter category is overwhelming, and as a result, it means that we will probably never see DOS software become truly PnP compatible. And, DOS software, especially entertainment software, will continue to be around for many years to come, Microsoft’s wishes notwithstanding. The effect on add-in board manufacturers is that they can either release PnP compliant hardware, or they can support the large (although most analysts try to ignore it) DOS market with a given product, but not both.

Conclusion
The only way PnP can become a true standard is getting away from today’s standard bus architectures and switching to a completely new add-in device mechanism, using a new OS that doesn’t support DOS and other existing hardware- dependent applications and drivers. On the hardware side, PCMCIA looks like it might offer this opportunity, while something beyond Windows 95 or OS/2 v3.0 is required on the software side of things. It’s far from certain, however, whether such a scenario will ultimately be a better one for the user.