Created: July 1994
Today's PCMCIA implementations are falling short of end-users' expectations. Although significant progress has been made to achieve a level of dynamic functionality, end-users are still forced to compromise on which cards, applications, and configurations they are able to use. These compromises are often the result of fundamental limitations in today's operating systems. What is needed is core operating system technology that recognizes and accounts for the dynamic nature of PCs and PC users today. A Plug and Play operating system provides just the needed services and functionality that will enable PCMCIA to achieve its full potential.
The purpose of this paper is to describe how the next version of the Microsoft® Windows® operating system (called Windows 95) will implement Plug and Play PCMCIA, and to provide guidance to PCMCIA card vendors in developing compatible cards and drivers.
This article is based on preliminary information that is subject to change before the final version of Windows 95.
There are several fundamental barriers to achieving the true potential of PCMCIA. In current implementations, for instance, it is assumed that resource requirements for the entire system are defined at boot time. This defines the pool of resources that remain for use with PC cards. Unfortunately, this static view of resources causes problems when docking systems or port replicators are used. Cards that worked in a stand-alone laptop suddenly fail when the laptop is docked. Another problem arising from this static view of the system is the requirement that drivers for all possible PC cards be resident in memory at all times to enable hot swapping. Beyond consuming valuable memory, this situation can result in cards that are unusable because of conflicts between drivers in memory. Finally, even when everything works well with the cards and drivers, there is no guarantee today that your application will survive a hot-swap. Fundamentally, these problems reflect the fact that there are currently no clear guidelines for how to achieve Plug and Play PCMCIA in a particular operating environment. While the PCMCIA standards provide an architecture and many components upon which to build, how these integrate with other operating system functions to achieve Plug and Play is necessarily operating environment-specific. What follows represents the implementation for the Windows operating environment.
The problems described above can be addressed through tight integration of PCMCIA software with a Plug and Play operating system, as in Windows 95. In a Plug and Play operating system, there are three critical features that support PCMCIA technology:
The Plug and Play framework that provides these features is shown in Figure 1. (See "Microsoft Windows and the Plug and Play Framework Architecture" in the Backgrounders, Operating Systems section of the Development Library.)
Figure 1. The Plug and Play framework
The approach to supporting PCMCIA under the Plug and Play framework calls for a PCMCIA adapter to be controlled by a PCMCIA Bus Enumerator that incorporates the PCMCIA Card Services functions as well as the enumeration, identification, and configuration functions defined by Plug and Play (Figure 2). Using this approach, the PCMCIA card can be treated like any other Plug and Play device. The configuration process is managed centrally for the entire system, so resources can be allocated and reclaimed dynamically by the Configuration Manager, allowing for easy addition of static devices and support for hot or warm docking. Additionally, standard Plug and Play device drivers can be used to support PCMCIA cards, offering bus-independence and dynamic load/unload. Finally, PCMCIA software can participate in dynamic messaging, thereby taking advantage of the smart, "hardware-aware" applications made possible by Plug and Play.
Figure 2. PCMCIA in the Plug and Play framework
In a Plug and Play system, the operating system is responsible for keeping track of every device in the system dynamically. This requires each device to be associated with a unique identifier (ID). Also, for each device there must be an information (.INF) file that associates the ID with other information required by the operating system to locate device drivers and perform the necessary class-specific installation and configuration functions for the device. It is the responsibility of the Bus Enumerator to create the ID for any device it enumerates, and the device installer component is responsible for accessing the .INF file for this ID. The .INF files can be supplied with the system or with the PCMCIA card. If the device installer is unable to locate the .INF file for a particular ID, it will interact with the end-user to access a vendor-supplied disk containing the .INF file and the device's driver software. Once located, the information in the .INF file is stored in the operating system registry so that future insertions will not require the device installer or any end-user interaction.
Each PC card must contain the information required for the PCMCIA Bus Enumerator to create a unique device ID. This is done through the use of tuples contained in the card's card information structure (CIS). Without these tuples, Plug and Play cannot be achieved. Furthermore, since reconfiguration can happen frequently in a Plug and Play environment, these tuples must always be available (that is, they cannot "disappear" after the card is configured).
The Windows 95 Plug and Play ID for PCMCIA I/O cards has the form:
PCMCIA\Manufacturer-Product-CRC16
The Manufacturer-Product portion of the ID is constructed from the first two strings provided in the Level 1 Version Tuple (Table 1). Non-printable characters are removed, and spaces are converted to underscores.
Table 1: PCMCIA Level 1 Version Tuple
| Tuple | Tuple Code | Tuple ID | Comments |
| Level 1 Version/ Product Information | CISTPL_VERS_1 | 15H | Product Information String. Product Name String. Only the first 2 strings of this tuple are included in the Manufacturer-Product portion of the ID (optional strings 3 and 4 are not included). |
The CRC16 portion of the ID is a unique number created by mathematically combining the binary bit patterns that make up the identification and configuration tuples shown in Table 2.
Table 2. PCMCIA I/O Card Identification and Configuration Tuples
| Tuple | Tuple Code | Tuple ID | Comments |
| Level 1 Version/ Product Information | CISTPL_VERS_1 | 15H | Only data in the tuple up through the first 2 strings is included in the CRC16 portion of the ID (optional strings 3 and 4 are not included). |
| Manufacturer ID | CISTPL_MANFID | 20H | Card manufacturer ID code: Defines manufacturer for this card. |
| Device | CISTPL_DEVICE | 01H | Device size and type are used to determine if the card should be treated as a storage device. Memory regions NOT intended as general storage should be described as "Function-Specific." |
| Configuration | CISTPL_CONFIG | 1AH | Indicates location of configuration registers. |
| Configuration Entry | CISTPL_CFTABLE_ENTRY | 1BH | Configuration requirements should be specified for I/O space, interrupts, memory, and so on. |
The configuration for the PCMCIA I/O card is determined by the Configuration Manager based on the entries in the configuration entry tuples. These tuples are critically important to supporting cards in a Plug and Play fashion (See the "CIS Verification" section later in this article for more information.)
PCMCIA memory cards are also assigned a Plug and Play device ID. For this, memory cards must include the tuples described in Table 3 below. This information is used by the PCMCIA Bus Enumerator to create the ID, as well as to correctly set up the file system(s) and driver(s).
Table 3. PCMCIA Memory Card Identification and Configuration Tuples
| Tuple | Tuple Code | Tuple ID | Comments |
| Device | CISTPL_DEVICE | 01H | The size of memory regions is used to determine the size of the storage device. Memory regions NOT intended as general storage should be described as "Function-Specific." |
| JEDEC-C Tuple | CISTPL_JEDEC_C | 18H | Used to determine the programming algorithm to be used with a region of programmable memory. |
| Device Geometry Information Tuple | CISTPL_DEVICE_GEO | 1EH | Used to configure the programming algorithm to be used with a region of programmable memory. |
| Format | CISTPL_FORMAT | 41H | Describes partition size and boundaries. |
| Organization | CISTPL_ORG | 46H | Describes partition type. |
The preferred driver for PCMCIA cards in Windows 95 is a standard Plug and Play device driver. These drivers are implemented as dynamically loadable virtual device drivers (DLVxDs). Plug and Play device drivers are necessarily class-specific, since each class of device—network, block, media (for example, sound), communication, and so on—has its own driver architecture. In Windows 95, these familiar architectures are extended to support Plug and Play. Therefore, all Plug and Play drivers, regardless of class, have certain things in common: They all obtain their assigned configuration from the operating system, they are dynamically loadable and unloadable, they participate in systemwide messaging, and they can be bus-independent (that is, they can support the same type of hardware on another bus).
With Plug and Play drivers, all resource allocation for the driver is done by the Configuration Manager, based on the required resource information supplied by the tuples. The actual configuration of the card is done by the PCMCIA Bus Enumerator, using the Card Services interface, after the resources have been allocated by the Configuration Manager. In PCMCIA terminology, the Bus Enumerator/Configuration Manager combination serves as a sort of "generic enabler" that is tightly integrated with the rest of the PC's subsystems. This tight integration provided by Plug and Play solves the issues with device driver interfacing that are prevalent in today's PCMCIA implementations. This allows the same Plug and Play device driver to support, for instance, ISA, PCI, and PCMCIA implementations of the same device. Note, however, that PCMCIA cards that do not contain the above required tuples cannot be supported by Plug and Play drivers, because the PCMCIA Bus Enumerator would be unable to identify and configure such cards.
As mentioned above, the PCMCIA Bus Enumerator makes use of the Card Services interface to access PCMCIA cards. In Windows 95, this interface is implemented to the PCMCIA standard bindings for 32-bit protect mode VxDs. Therefore, any 32-bit protect-mode device driver that uses Card Services 2.1 will still work under Windows 95 without modifications. Due to limitations in the interface, though, PCMCIA cards supported by these drivers will not be fully Plug and Play. In addition to being statically loaded, resource allocation for these drivers may not be optimized, and the driver does not participate in any systemwide messaging or dynamic resource balancing. However, because the device driver makes the requests for obtaining resources and configuring the card, this may be the only option to support cards that do not implement the required tuples. More importantly though, the availability of the Card Services interface means that Plug and Play drivers can use these functions if necessary. While Plug and Play satisfies the overwhelming majority of card interfacing needs, specific hardware implementations may require the driver to access some of the Card Services tuple-processing and memory-windowing functions. Windows 95 supports version 2.1 of the Card Services specification.
Because the Windows 95 Card Services interface implements the 32-bit protect mode bindings, real-mode client drivers are not directly supported. However, Windows 95 is compatible with Windows 3.1 and MS-DOS®, so third-party real-mode Card Services drivers can run under Windows 95 to provide this support. Real-mode support, though, is an all-or-nothing proposition: If it is loaded, the Windows 95 protected-mode PCMCIA software will not be available. Both implementations cannot be supported at the same time.
The Card Services layer described above utilizes the Socket Services interface to access the socket controller. Socket Services drivers in Windows 95 are, themselves, Plug and Play device drivers (DLVxDs). Windows 95 includes Socket Services drivers for Intel® 365-compatible and Databook-compatible socket controllers. These drivers support release 2.1 of the Socket Services specification. (See Appendix A for more information on compatibility with these drivers and recommendations for compatible socket implementations.) The Socket Services functions required by the Windows 95 Card Services layer are documented in the Windows 95 Driver Development Kit (DDK).
Memory cards will be supported under Windows 95 through the Memory Technology Driver (MTD) interface defined by PCMCIA (see Figure 2). Clients such as CARDDRV and the Microsoft Flash File System driver will use the Card Services interface to access memory cards. Memory card vendors can provide MTDs for their cards, implemented using PCMCIA's 32-bit protect-mode bindings.
The work required to develop Plug and Play support for PCMCIA cards on Windows 95 can be generally categorized as follows:
As indicated in the discussion above, correct CIS design is critical to achieving Plug and Play with PCMCIA cards. The first task in your work for Windows 95 is to verify that your card's CIS conforms to the requirements described earlier in this paper. To facilitate this, Microsoft has created and is distributing to vendors an MS-DOS-based program that will read a card's CIS, parse the information, and provide a printout of how Windows 95 will identify and configure the card. The tool, DTPL.EXE, accepts tuple information from cards or from a file, allowing what-if analysis during the design of the CIS. With this tool, vendors are able to modify the tuples to achieve the desired configuration. If the DTPL.EXE output for your card looks correct (that is, if the configurations DTPL proposes are the ones you intended), your CIS is ready for Windows 95. If not, you can modify your CIS design (for new cards), or use the .INF file to override the information in your CIS (for existing cards).
The most important thing that DTPL.EXE does is generate the Plug and Play device ID for your card. You will need to include this ID in your .INF file to associate the file with your specific device.
For the rest of your development work, you will need the Windows 95 DDK, which also includes a beta release version of Windows 95 for testing. Before you jump into your own development efforts, though, you should see if Windows 95 has built-in support for your card. Windows 95 ships with several standard Plug and Play drivers and includes .INF files for many popular PCMCIA cards. Once you have verified that your CIS is ready for Windows 95, you can test for built-in support with the beta release.
Upon insertion, if your card is supported, Windows 95 will indicate that it has the software required to make it work. If there is no built-in support, Windows 95 will indicate that a new device has been inserted (displaying the card's Manufacturer and Product Identification strings) and request a driver disk. (There is also the option of picking the device, or a compatible one, from a list, although this is not a Plug and Play experience for the user.) The creation of this floppy disk containing the driver and .INF is the ultimate goal of the remaining development efforts (although distribution of the software may be through means other than floppy disk; see "Testing, Certification, and Distribution" section later in this article).
There are a couple of important points to make at this juncture. First, even if your card has built-in support, it may not be optimized. You have the option of creating a new .INF file or driver to more optimally support your card. For many devices, particularly modems and ATA drives, there is no need to create a special driver; the .INF file is all that is required to optimize for your device. Secondly, if your card is compatible with a built-in driver but there is no .INF file for your card, Microsoft would like you to provide your .INF file for inclusion with Windows 95. You will be able to test for compatibility with built-in drivers after you've created your .INF file (see below). After confirming compatibility, you can deliver the .INF (with a sample of the card for testing) to Microsoft for inclusion with the next beta release of Windows 95.
This is a simple text file whose main purpose is to associate your card with an appropriate device driver during installation. However, the .INF file format is extremely flexible and powerful, so there are many installation- and configuration-related functions you can implement with these files. Some classes of devices, such as modems, use the .INF file for setting-up and configuring advanced functionality, such as special modem commands or remote network access support. All of the documentation for .INF files is provided in the DDK, including sample .INF files for many cards. You can use a sample as a starting point in the creation of your own .INF file. For compatible cards, this may only require you to replace the existing card's device ID with the ID for your card (which was provided by the DTPL.EXE program) and change some display strings. For many other cards, including most modems, the .INF file requires a bit more information, but it eliminates the need to develop a special driver.
This task represents the major portion of your work, assuming your card is not compatible with a built-in driver. However, none of this work need be specific to the PCMCIA interface. As mentioned earlier, Plug and Play drivers are class-specific and can be bus-independent. For most classes of devices, Windows 95 offers a familiar and standard device driver model that is Plug and Play ready. For example, Plug and Play drivers for network cards implement the standard NDIS 3.0 interface. For storage devices, the NT Miniport interface is the model for Plug and Play drivers. Similar models exist for communications drivers and media devices, among others. For unique devices, a generic Plug and Play driver model exists, and can be adapted to any type of device. All of these models are well documented in the DDK, and sample source code is also provided.
Also included in the DDK are the Compatibility Tests (CTs). These tests are provided to assist you in verifying that your driver software is compatible with Windows 95 and ready for certification. Use these tests to find and fix problems with your driver software. Once your development is complete, you will need to submit your product (hardware and driver software disk) to the Microsoft Compatibility Labs (MCL) for certification. The MCL tests will be based on the DDK's CTs, but will cover a very broad range of hardware and software configurations.
Once certified, your product will be able to display the Windows 95 logo, and your driver software will qualify for distribution through the Windows Driver Library (WDL). The WDL is offered as a download service by Microsoft.
This section provides a directory of services and tools targeted at enabling card vendors to create PCMCIA cards that are fully Plug and Play compatible.
Microsoft participates in a forum on CompuServe® for the purpose of supporting and promoting the creation of Plug and Play personal computer systems. As part of this forum, Microsoft provides tools and support for PCMCIA card vendors in the development of CIS. Just type GO PLUGPLAY to join this forum.
DTPL.EXE is available on the PLUGPLAY forum.
These kits are available under NDA as part of the Windows 95 Beta Program until Windows 95 ships. To enroll in the Beta program and to obtain a kit, contact Microsoft's Windows Hardware Programs (WHP) group at ihv@microsoft.com.
Participants in the Windows 95 Beta Program have access to the WINDDK forum on CompuServe, where Microsoft provides technical support to developers, including help with .INF files and Plug and Play drivers.
Microsoft maintains on its Redmond Campus a building entirely dedicated to helping device driver and application developers port to Windows operating systems. This facility is set up to assist vendors with particularly troublesome problems and offers the vendor technical support and direct interaction with Microsoft's development team. A major porting program for Windows 95 Plug and Play drivers for PCMCIA cards is currently under way in the lab. Contact Microsoft's Windows Hardware Programs (WHP) group at ihv@microsoft.com for more information.
Microsoft sponsors many events for developers, including interoperability workshops (sometimes referred to as "PlugFests"). These events enable vendors to test their hardware and Windows 95 driver support software against a variety of systems, in many combinations, configurations, and using different socket controllers. There will be a major Windows 95 PCMCIA PlugFest during the Beta program. Register your interest with WHP at ihv@microsoft.com.
You can contact MCL at (206) 635-4949, or e-mail mclinfo@microsoft.com.
Plug and Play operating system technology is essential for achieving the full vision of PCMCIA card interoperability and hot-swapping. Plug and Play overcomes the traditional static view of hardware that is assumed in today's operating systems. With a fully integrated Plug and Play framework supporting it, PCMCIA technology will be able to provide users with dynamic functionality on a wide variety of platforms, in diverse configurations, and with a large number of applications.
The built-in Plug and Play PCMCIA software in Windows 95 includes drivers for Intel PCIC-compatible and Databook TCIC-compatible socket controllers. To be compatible with these drivers, socket controller implementations must fully support the Intel PCIC (365) or Databook TCIC base-register set. Many controllers do not fully implement the base-register set and are not compatible. Furthermore, some controllers implement extended registers or enhancements. The built-in Windows 95 drivers do not exploit these features, although the controller may be compatible.
The following guidelines are also recommended for compatible implementations: