The kernel is a shared environment. Accordingly, many different kernel-mode drivers utilize services provided by the kernel. Furthermore, when shimming of drivers is necessary, it is desirable to support shim reuse amongst drivers with similar problems or issues, rather than generating a customized shim for each driver. To facilitate kernel-mode shimming and shim reuse, context information needs to be retrieved and maintained so that shims can identify particular driver calls and preserve driver specific linkage information. The present invention accomplishes the forgoing by employing an intermediate structure, a content component, between a client or driver call and a common shared shim to provide the shim with contextual information.

TECHNICAL FIELD

The present invention relates generally to computers and more particularly toward a system and method of shimming kernel-mode drivers.

BACKGROUND

Shimming is a technique that allows additional functionality to be inserted between an application programming interface (API) client (e.g., an application, driver) and an API service (e.g., supplied by an operating system). An API client application may be written to use a collection of externally provided services (APIs), which provide some well-described functionality. These API services reside external to the client program, for example, contained in a dynamically linked library (DLL).

One of the major benefits provided by external API services is that a client application can be built without including the API service code directly in the client application. In particular, such a scheme provides a way for applications to declare their usage of a particular API service, but defer binding to that API until the application is actually loaded for execution. This allows application code to be separated from the API service code and allows for modularity in the construction of the application run-time environment. External API services are said to be “imported” into client applications and have “load-time binding” to applications. Accordingly, an application declares its intent to use imported API services and in response, the compiler can implicitly generate a “stub” entry in the applications import address table (IAT). The IAT containing import stubs can be generated by the compiler. These IAT stubs identify the name of the import API and the external service or DLL that corresponds with the API. When the application is loaded or otherwise made ready for execution, load-time binding will be performed and the IAT stubs will be updated to reference the correct API services.

FIG. 1illustrates a conventional system100for linking an application110and an API service provider120. Application110comprises a code section112and an IAT114. In the code section112, there is a call to import a procedure, here Foo. IAT114contains a pointer to the address of the Foo procedure in the API service provider120. Conventional user-mode application shimming techniques are based on manipulating the IAT table entries to effect the insertion of functionality. This can be accomplished by changing the imported API's entry in the application's IAT to point to shim code rather than the original API service code.

FIG. 2illustrates a conventional user-mode utilization of a shim130between the application110and the API service provider120. The shim130can be written to provide a “value added” benefit to the API service or it can completely replace the API service functionality and never call the original API service provider120. User-mode applications run in a process which is essentially owned by the application. Accordingly, there is only one client, the application, in the process. This is not true for a system process where kernel-mode drivers execute. In a system process, API service providers, such as an operating system kernel, are called by a multitude of different and substantially unique drivers.

Turning briefly toFIG. 3, an exemplary system driver interaction is illustrated. Driver X310has code312which utilizes IAT314to import or link to Foo Procedure332operating system kernel330. Driver Y320has code322that employs IAT324to import or link to VerifierFoo Procedure334in system kernel330, which then calls Foo Procedure332also in the kernel330. Both drivers were written to invoke Foo Procedure or API332, but Driver X's linkage is different from that of Driver Y's linkage. Driver Y has had its Foo import shimmed by a built in shim, namely VerifierFoo, while Driver X is directly linked to the original Foo API in the kernel.

One important goal of shim developers is reusability. Thus, a good shim framework should support reuse of shims when possible. If a shim, which provides some extended service or fix is created then it is desirable that that shim be applied to all applications expressing the problem, for instance, that the shim was designed to correct. For example, if Shim X fixes problem X and applications A, B, and C have problem X, then it would be desirable to have Shim X be able to fix applications A, B, and C without any changes to Shim X. However, providing such a common shim has not been possible up to this point, due in part by the fact that different drivers often have different linkage configurations, such as Driver X and Driver Y supra. Moreover, conventional user-mode shims and shimming systems can retain only one linkage configuration, namely the most recent, while other linkage configurations associated with previously shimmed drivers is lost. Further complicating the problem is the fact that existing infrastructures for imported APIs or services do not readily provide any contextual information with respect to which driver is utilizing the API or service.

Accordingly, there is a need in the art for a shim system and method that can determine and maintain a plurality of linkage configurations, context, unique to each application or driver to be shimmed.

SUMMARY

Disclosed herein is a system and method for establishing and maintaining driver unique contextual information so that common shims can be utilized to provide some service or fix a particular problem associated with a plurality of drivers or other similar applications. Unique context formation is injected into a shimming system via an intermediate context component residing between the driver and a shim component. The context component comprises a hook component and a thunk component. The hook component stores context information regarding a kernel procedure referenced by a driver and redirects the driver to the context component. The thunk component links the context component to the shim component and provides the shim component with driver unique context information. The shim can then perform its function and subsequently link or jump to the kernel procedure or service originally referenced by driver.

According to another aspect of the subject invention, a shimming system is disclosed herein that implements and supports driver unique context information. More particularly, the system comprises a shim engine component that receives a notification signal indicating when a driver is loaded. Upon receipt of the signal the shim engine can query a shim database to determine if any shim components or shim packages are associated with the loaded driver. Thereafter, the shim engine can load any associated shim components and generate or load a context component associated with the loaded driver. Additionally, the shimming system disclosed herein can include a diagnostic component that monitors a system and, upon a system crash or a detected instability or inefficiency, queries the shim database to determine if a shim component is available that if applied would fix or compensate for the problem causing the crash, instability or inefficiency. Further yet, the shimming system according to an aspect of the subject invention can employ an interface component to facilitate development, deployment, and management of shim components and packages by users or developers.

To the accomplishment of the foregoing and related ends, certain illustrative aspects of the invention are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways in which the invention may be practiced, all of which are intended to be covered by the present invention. Other advantages and novel features of the invention may become apparent from the following detailed description of the invention when considered in conjunction with the drawings.

DETAILED DESCRIPTION

The present invention is now described with reference to the annexed drawings, wherein like numerals refer to like elements throughout. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed. Rather, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present invention.

Furthermore, the present invention may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. The term “article of manufacture” (or alternatively, “computer program product”) as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope or spirit of the subject invention.

Turning toFIG. 4, a shimming system400is illustrated in accordance with an aspect of the present invention. System400comprises driver component410, kernel component420, procedures422(Procedure1, Procedure2through ProcedureN, where N is greater than one), context component440and shim component430. Driver component410(also referred to herein as simply driver) can be used to perform almost any function on a computer however driver components are typically employed to provide an interface to a particular hardware device or piece of software. Driver component410can encapsulate special instructions and information associated with a particular device or piece of software and provide users (e.g., hardware, software) access to a set of generic instructions. Devices or software then utilized the generic commands to communicate with a device or software component. The driver component410can translate received generic instructions to the specialized instructions utilized by the device or software component. A driver component(s) can be provided by an operating system, by software applications, or via software associated with a particular device (e.g., disk drive, printer, scanner, keyboard, mouse, speakers . . . ). A driver component410can be implemented in computer systems as dynamically linked library (DLL) files. DLL files are small files that are utilized by a larger program or device to perform a specific function. For instance, a driver component or DLL file can provide support for a particular device such as a printer. The driver component or DLL file can then be utilized by a larger program like a word processing program to facilitate printing a document utilizing a particular printer associated with the driver component.

Turning briefly toFIG. 5, a driver component410is illustrated in further detail in accordance with an aspect of the subject invention. Driver component410comprises driver code412and import address table414. Driver code412corresponds to software specified procedures and functions that driver component410utilizes to implement driver functionality. Driver component410can enhance its utility while minimizing its overall size by using external services or procedures422(FIG. 4) provided by the kernel component. Driver component410accesses external procedures422by “importing” them using an import address table414. When a driver component410is loaded or executed the procedures422listed in the import table can be bound to the drivers so that the driver can utilize the functions and procedures provided therein. This binding is referred to herein as driver linkage or import linkage.

It should be noted that while this detailed description focuses almost exclusively on drivers and driver components, the scope of the invention is not so limited. The scope of the present invention covers any applications or components, drivers or otherwise that are capable of being shimmed. While this description focuses on drivers and driver components, it is not meant to exclude all other software applications capable of being shimmed, but rather to facilitate a clear and understandable description of the invention devoid of confusing terms (e.g., client/application/component/driver).

Returning toFIG. 4, kernel component420is the nucleus or core of a computer operating system. An operating system is generally responsible for processing data and managing input and output. Kernel component420, as part of the operating system, is loaded first and remains in main memory. In addition to being responsible for process management, file management, and memory management, inter alia, the kernel component420provides the essential services or procedures422required by applications and drivers. Procedures422can correspond to but are not limited to I/O scheduling, buffering, spooling, and error handling. Furthermore, it should be noted that the term kernel-mode service or kernel-mode procedure as used herein is intended to cover any service, procedure, driver, application or other component located in the kernel address space.

Shim component430provides additional functionality between driver component410and kernel services or procedures422. According to one aspect of the subject invention such functionality can correspond to a fix for a faulty driver; however shim component430can also be utilized as a diagnostic shim to assist in root cause analysis. Faulty drivers can be the cause of many system crashes and other problems that contribute to a negative computer experience (e.g., delays, lockups . . . ) which are usually incorrectly attributed to an operating system. A shim component420provides a mechanism for fixing a driver's behavior by compensating for the drivers fault. Accordingly, the shim component430resides between one or more driver components410and a kernel component with desirable procedures422. However, unlike conventional shimming systems the present invention also employs a context component440.

Context component440is an intermediate component between a driver system call and a common shim component430. Context component440provides a mechanism to establish and maintain unique per-driver linkage information. Conventional shimming systems do not establish a context for each driver calling a shim component, rather they retain only one linkage configuration embedded in the shim itself, specifically the linking configuration of the last driver shimmed. Therefore, all shim linkage configuration data related to a previously shimmed driver is lost. Turning toFIG. 6, a context component440, in accordance with an aspect of the subject invention, is illustrated in further detail including hook component442and thunk component444. Hook component442can be constructed during the loading of the subject driver. Hook component442retrieves contextual information from a driver to be shimmed (e.g., using a shim engine component described infra) and makes such information available to thunk component444. In particular, hook component442can retrieve the address of the kernel procedure or service sought to be utilized by a driver from the driver's import address table (IAT). Furthermore, hook component442can determine the address of the shim to be utilized. This context data can then be stored in a data structure for later access by the thunk component442and the shim component430. Thunk component444utilizes information retrieved by hook component442to change a driver's import address table to point to or reference the location of the shim rather than the originally specified service or procedure. Furthermore, thunk component444provides the shim component430with access to the context information related to the driver calling the shim component430. The context information can be provided to the shim component430by passing such information or the location of the information as a procedure parameter or storing the data in a particular location known by the shim component430. The shim component430can then utilize this information to retrieve the calling driver's originally referenced kernel procedure. Subsequently, the shim component430can chain forward to the originally reference procedure or service after providing additional functionality (e.g., driver fix).

Turning toFIG. 7, a block diagram of an exemplary system700in accordance with an aspect of the invention is illustrated. System700depicts the use of context components amongst two different driver components. Driver X710and driver Y720contain respective driver code712and722as well as import address tables714and724. Furthermore, each driver is associated with a context component730and740. A common shim component750is utilized to provide additional functionality between the drivers and kernel component procedures Foo762and VerifierFoo764. Driver X710utilizes Foo procedure762in its code section710. Accordingly, there is a pointer in driver X's import address table714pointing to the memory location containing kernel procedure762. Here, however, a shim component750has been employed to provide additional functionality, for example compensating for a problem with driver X710. In accordance with an aspect of the subject invention a context component730is also employed to provide driver specific context information to the shim component750. Context component730includes a hook component732and a thunk component734. Hook component732changes the pointer in import address table714originally referencing Foo to point or link driver X's import of the Foo procedure to context component730. Additionally, context component730receives the memory address of the shim component750and stores, inter alia, a pointer to the shim component750and a pointer to the originally referenced kernel procedure Foo762in a data structure, here Hook struct. Thus, hook struct contains the driver context information. Thunk component734utilizes this information to jump to the shim component750and provide shim component750with context data. After the jump is complete, shim component750executes its function and then utilizes the context data to link and ultimately execute the original procedure call Foo762.

Driver Y720goes through a similar process with the common shim component750. In this case, however, driver Y720utilizes its own context component740and a different procedure call. Driver Y720ultimately seeks to call Foo procedure762, but as shown here after calling VerifierFoo procedure764. The hook component742of the driver context component740determines and saves information related to the procedure called by the shim component750. Thunk component744links the driver to the shim component750by changing the reference address in driver Y's import address table724. Thereafter, when driver Y720calls the Foo procedure in its code section722control is transferred to the context component740. Context component then stores the stores a pointer to the context information in a register or by alternative means transfers the location of the context information or the context information itself to shim component750. Shim component750then executes its functionality and then using the context information jumps to the verifier procedure764, which executes and jumps to the Foo procedure762that is associated with an oskrnl.exe code at760. It should be noted that by retrieving and maintaining context data for each driver, the subject invention ensures that context data for previously shimmed drivers is not lost upon the utilization or calling of the shim by another driver. Conventional shimming practices would have lost information regarding the context of the driver X710upon execution of driver Y720. In this case, if driver X710was called again after driver Y720, a conventional shim would not know which procedure driver X710originally referenced as context data would not have been retained and the reference in the drivers import address table would have been changed to reference the shim component750. The present invention eliminates this problem by storing unique context information for each driver component.

FIG. 8depicts a system800for utilizing shims in accordance with an aspect of the subject invention. System800comprises driver loader component810, shim engine component820, shim database830, diagnostic component840, and interface component850. Driver loader component810receives a signal from an entity (e.g., person, application, device, plug-and-play component . . . ) to load a driver. Driver loader component810establishes driver initial linkage and loads a target driver into memory for execution. The loader component810can resolve any unresolved dynamic references the driver may have for external APIs or processes and when all references are resolved generate a notification signal. The notification signal provides, among other things, the identity of the driver being loaded to the shim engine component820. Such notification signaling allows other services to receive control during the driver load procedure just prior to the driver being called. The shim engine component receives the notification signal and utilizes the information contained therein to query the shim database830to determine if the target driver is to be shimmed. The shim database830acts as a central repository for the data concerning which drivers need to be shimmed and which shim components are to be applied to particular drivers. If the shim engine component820determines, utilizing at least the shim database830, that a driver should be shimmed, the shim engine component identifies the set of shims or shim package to be applied, loads them (if not already loaded), and allows the shims to initialize a unique context. Subsequently, the shim engine component820can redirect the target driver API imports to one or more shim components.

System800can also include a diagnostic component840that analyzes a computer system and initiates corrective action. According to one aspect of the subject invention the diagnostic component840assists in root cause analysis of a system crash. The diagnostic component can therefore employ a variety of methods of analyzing system dump information and/or a program trace (e.g., utilizing expert systems, neural networks . . . ) to determine the cause of the crash. However, diagnostic component840need not wait for a system crash. The diagnostic component840can also be proactive and engage in system analysis to detect system instabilities and/or inefficiencies. Upon determining the cause of a crash or detecting system instabilities and/or inefficiencies, corrective action can be initiated by the diagnostic component840. Such corrective action can include providing notification to a user or operator via interface850. Corrective action can also comprise searching the shim database830to determine whether a shim component already exists that if applied can fix the detected problem, instability or inefficiency. Such a determination can be made intelligently using Bayesian networks, neural networks, decision trees, support vector machines, linear and non-linear regression and/or other learning models. According to an aspect of the invention, the diagnostic component can engage in a probabilistic analysis based on the cost of making an incorrect diagnosis and/or selecting the wrong shim weighed against the benefit of correction. Confidence levels may be employed and specified by a developer or user to control actions of the diagnostic component.

Interface component850enables a user to interact with the shim database830. According to one aspect of the invention, the interface component850is a graphical user interface (GUI) that facilitates creation of a shim component or shim package for a driver and storage of the shim component or shim package to shim database830. For example, the interface component850can be a wizard that presents a user with a series of steps in graphical windows that aids in the generation of a shim component to remedy a detected problem, instability, or inefficiency. The interface component850can also provide a developer or user a means for developing and deploying a diagnostic shim component that can assist in understanding an operation sequence to determine or converge upon a problem.

In view of the exemplary systems described supra, a methodology that may be implemented in accordance with the present invention will be better appreciated with reference to the flow charts ofFIGS. 9-11. While for purposes of simplicity of explanation, the methodology is shown and described as a series of blocks, it is to be understood and appreciated that the present invention is not limited by the order of the blocks, as some blocks may, in accordance with the present invention, occur in different orders and/or concurrently with other blocks from what is depicted and described herein. Moreover, not all illustrated blocks may be required to implement the methodology in accordance with the present invention.

Additionally, it should be further appreciated that the methodologies disclosed hereinafter and throughout this specification are capable of being stored on an article of manufacture to facilitate transporting and transferring such methodologies to computers. The term article of manufacture, as used, is intended to encompass a computer program accessible from any computer-readable device, carrier, or media.

Turning toFIG. 9, a methodology900for shimming kernel mode drivers is depicted in accordance with an aspect of the present invention. At910, a shim component common to several drivers is generated. A common shim component provides an efficient mechanism to add functionality to one or more drivers so as to compensate for a fault associated with the one or more drivers, for example. A shim component can be generated using a program editor and/or a graphical user interface. Alternatively, a shim component can be generated using a wizard that guides a user or developer through a series of steps associated with generating a shim component utilizing a myriad of windows and graphical interface components such as buttons, scroll bars, text boxes and the like. At920, driver unique context data is generated for each driver to be shimmed. Subsequently, the driver unique context is provided to the common shim at930. The unique context data allows the common shim component to identify the driver that is utilizing the shim component. This enables the shim component to add additional functionality and then chain forward to the kernel-mode service or procedure utilized by the driver and therefore leaves a driver's chain of execution intact.

FIG. 10is a flow chart diagram illustrating a methodology1000for shimming kernel mode drivers in accordance with an aspect of the subject invention. At1010, a shim component common to a plurality of drivers is generated. As mentioned supra, the shim component provides an efficient mechanism to add functionality to a driver for instance to compensate for some fault (e.g., referencing restricted memory . . . ). However, it should also be noted that a shim component can be utilized as a tool to determine and pinpoint system problems. The shim component can be generated using one of several methods, components, and devices, for example using a GUI or a wizard. At1020, a driver's imported API or kernel-mode service is retrieved from the drivers import address table. Subsequently, the drivers API service reference in its import address table is replaced with a pointer to the shim component at1030. The replaced API or kernel kernel-mode service is then provided to the shim at1040. This context information can be provided to the shim component by employing it as a parameter in a function or procedure calling the shim, by loading it to a particular memory location, and the like. Accordingly, a driver associated with a common shim component becomes linked to the shim component, which is then able to chain forward to the API or kernel-mode service after the shim component executes its additional added functionality.

FIG. 11depicts a method1100of modifying kernel mode drivers in accordance with an aspect of the subject invention. At1110, a signal is received indicating that a driver has been loaded. In accordance with one aspect of the invention, the signal can be generated by a driver loader component after resolving any unresolved dynamic references the driver may have for external APIs. Such notification allows other services to receive control just prior to the driver's driver entry being called. At1120, a query is performed on the shim database to determine if a driver is one that is to be shimmed. A determination is then made at1130as to whether the driver is to be shimmed based on the existence or nonexistence of shim components associated with the driver. If there are no shims associated with the driver then the procedure is terminated. If, however, there is one or more shims associated with the driver then the process proceeds to1140where a unique driver context is initialized and loaded. Subsequently, the driver is redirected to the shim component rather than a driver import entry such as a kernel-mode service or procedure at1150. Such redirection can be accomplished by replacing an entry in the driver's import address table with a pointer to the shim component. Thereafter, the shim component can but is not required to utilize the unique driver context to chain forward to the replaced driver import entry.

In order to provide a context for the various aspects of the invention,FIG. 12as well as the following discussion are intended to provide a brief, general description of a suitable computing environment in which the various aspects of the present invention may be implemented. While the invention has been described above in the general context of computer-executable instructions of a computer program that runs on a computer and/or computers, those skilled in the art will recognize that the invention also may be implemented in combination with other program modules. Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks and/or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the inventive methods may be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, mini-computing devices, mainframe computers, as well as personal computers, hand-held computing devices, microprocessor-based or programmable consumer electronics, and the like. The illustrated aspects of the invention may also be practiced in distributed computing environments where task are performed by remote processing devices that are linked through a communications network. However, some, if not all aspects of the invention can be practiced on stand-alone computers. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

With reference toFIG. 12, an exemplary environment1210for implementing various aspects of the invention includes a computer1212. The computer1212includes a processing unit1214, a system memory1216, and a system bus1218. The system bus1218couples system components including, but not limited to, the system memory1216to the processing unit1214. The processing unit1214can be any of various available processors. Dual microprocessors and other multiprocessor architectures also can be employed as the processing unit1214.

The system memory1216includes volatile memory1220and nonvolatile memory1222. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer1212, such as during start-up, is stored in nonvolatile memory1222. By way of illustration, and not limitation, nonvolatile memory1222can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory1220includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM).

It is to be appreciated thatFIG. 12describes software that acts as an intermediary between users and the basic computer resources described in suitable operating environment1210. Such software includes an operating system1228. Operating system1228, which can be stored on disk storage1224, acts to control and allocate resources of the computer system1212. System applications1230take advantage of the management of resources by operating system1228through program modules1232and program data1234stored either in system memory1216or on disk storage1224. It is to be appreciated that the present invention can be implemented with various operating systems or combinations of operating systems.

A user enters commands or information into the computer1212through input device(s)1236. Input devices1236include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit1214through the system bus1218via interface port(s)1238. Interface port(s)1238include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s)1240use some of the same type of ports as input device(s)1236. Thus, for example, a USB port may be used to provide input to computer1212, and to output information from computer1212to an output device1240. Output adapter1242is provided to illustrate that there are some output devices1240like monitors, speakers, and printers, among other output devices1240, that require special adapters. The output adapters1242include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device1240and the system bus1218. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s)1244.

Computer1212can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s)1244. The remote computer(s)1244can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer1212. For purposes of brevity, only a memory storage device1246is illustrated with remote computer(s)1244. Remote computer(s)1244is logically connected to computer1212through a network interface1248and then physically connected via communication connection1250. Network interface1248encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE 1102.3, Token Ring/IEEE 1102.5 and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).

Communication connection(s)1250refers to the hardware/software employed to connect the network interface1248to the bus1218. While communication connection1250is shown for illustrative clarity inside computer1212, it can also be external to computer1212. The hardware/software necessary for connection to the network interface1248includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.