Implementing parallel component sharing in your application (i)

Summary: Explore implementation of parallel shared components in Microsoft (r) Windows (r) 2000 and version II of Windows 98, as discussed in the Windows Authentication specification. Includes the creation of new parallel components and the incompatibility between different versions of the same component using dll/com redirection. Includes guidelines for writing and installing parallel components and repackaging and testing applications.

Directory

Introduced

A little background knowledge

New Component Sharing policy

Comparison of two strategies

Create a new parallel component

Guidelines for writing parallel components

Installing Parallel components

Dll/com redirect

Using dll/com redirection

Introduced

Modern operating systems and applications are composed of many components. A component is a self-contained software entity that provides a set of functions that can be used extensively by various applications. Because individual components are used by multiple applications, it is necessary to share components.

A successful global component share requires that any shared component functionality be exactly the same as the previous version of the component. But if it doesn't, it's really hard to achieve full backwards compatibility because it's very difficult to test all the configurations that use shared components. Both old and new applications end up using the same components, so it becomes more difficult to fix and improve these components over time.

At the same time, the actual functionality of the component is not easily defined. An application can become an unintended side effect attached to a component and is not considered part of the core functionality of the component. For example, an error in a component may affect the application and the application fails when the component developer chooses to fix the error, which is what people often call "DLL Hell (damned dll)." This allows applications that use components to be more serious about the problem.

This lack of backward compatibility makes it necessary to break deployed applications or to sacrifice the functionality of some new applications when deploying new applications. All new applications require that the version of the shared component be different from the configured version. To provide successful sharing while enhancing application stability, Microsoft has introduced parallel sharing in Windows 2000 and Windows 98 Second editions, creating new ways to share components through selective isolation.

A little background knowledge

Before you understand the details of parallel sharing, let's look at some background information and the "DLL Hell" issue.

Component sharing

Windows initially embraced the concept of sharing. All operating systems seek a balance between the need to provide stability, a complete set of services, and the resource constraints of the hardware required by the operating system. So far, CPU usage and disk space are still very tight resources on the PC platform. Obviously, to put the operating system and application code into a very small space, you must share the code as much as possible. Compared with many other benefits, code sharing enhances the balanced use of hardware resources and minimizes the exposure to early-stage quality assurance testing. Code sharing is one of the elements that makes Windows successful.

Windows sharing is not limited to code. The state of applications and components can be found throughout the operating system in the form of registry state, in the form of application-specific data stores in the file system, and in the form of a Windows API that exposes global namespaces. This type of sharing provides high levels of interoperability between applications produced by multiple software vendors, lowers costs, and improves software efficiency.

However, sharing also has to pay some price. Sharing means that applications are dependent on each other, introducing vulnerability factors. Changing a component can have unpredictable effects on other components. Typically, an application may depend on a specific version of the shared component. Another application may be installed with the upgraded (or degraded) version of the shared component, so the first application may be affected by this change. In extreme cases, applications that once worked are suddenly dysfunctional or even fail. This situation is often referred to as "DLL Hell."

Isolation

In the system, the opposite of sharing is isolation. You can isolate an application by statically binding all resources and code to the application. But today, complete isolation is not feasible for applications that rely on system resources for COM or other global storage.

One solution to reducing application vulnerabilities is to selectively isolate applications and components. In this scenario, all applications may have access to the same components, but the component currently has multiple versions available. Component developers have the right to compile new versions of old components, make some improvements, or fix bugs. Customers can choose a version that is appropriate for a particular application. Just like walking into an auto parts store to pick a fuel pump for your 1984 Chevy. You will find this pump on the shelves and some other pumps that are suitable for other models than the one that comes later. In the case of using components, the key is to provide a version that is appropriate for each application and to isolate different versions. Also, in the case of redirection, an application can be configured to use a component version that is appropriate for that particular application, regardless of the recently developed or future versions.