Implementing parallel component sharing in an application (ii)

When you modify an existing component to parallel, it is the way it is activated to use relative paths and isolate the global state. It is important to give it a new CLSID, ProgId, and rename the file, and then use this CLSID, ProgId, and new file names for later parallel components. Doing so avoids conflicts caused by registering a non-parallel version of the component on a parallel version. Parallel components are not backward compatible with their previous versions of non parallel.

State Store

For the status (settings) stored in the registry, the status needs to be privatized to the context in which the application is running. You can use the GetModuleFileName () function to set a virtual root. The operation should be performed on the HKLM and HKCU branches.

Registration settings must be completed on a per-version basis to obtain registry isolation. A registry key is a common way for a component to save its state. Because different versions of components may exist in the machine, it is important that you find the version of your table entries as easily as possible when you recompile. Getting a good set of header files and useful APIs will make this matter easier.

Store the registration status in a table key with the following naming convention:

Hkcu\mycompany\mycomponent\versionxxxx\

For example, suppose a configuration setting called Enablesupercoolfeature has a true or false value. The traditional way to store this information in the registry is:

Hkey_currentuser\software\mycompany\mycomponent\

Enablesupercoolfeature = TRUE

In parallel sharing, you should store it in the following ways:

hkey_currentuser\software\mycompany\mycomponent\version01.01

Enablesupercoolfeature = TRUE

In addition, if you decide that you want to isolate each application, you can use the

hkcu\mycompany\mycomponent\versionxxyy\someapplication\\

where "Someapplication" is the return value of the GetModuleFileName. Doing so enables the component to isolate its settings, which are only for applications that are currently running.

Ideally, a permanent model should be supported so that the application assumes responsibility for maintaining the user's state and does not change the registry. The application does not have to contact the component's registry key directly. Instead, the component should provide some APIs to save or restore the settings consistent with the parallel.

For interactions in the global state, settings stored in locations other than the registry should be stored in parallel. This type of storage contains:

Protected Storage (Pstore)

WinInet Cache

Microsoft SQL server& #8482; or Microsoft Jet database

Installing Parallel components

Before installation

Before you install the parallel components, you must determine whether they are supported in your operating system. The following code detects whether a parallel share is available. If not available, the component must be installed in the system directory.

BOOL bplatformsupportssidebyside (void)

{

Osversioninfoex Osviex;

osviex.dwosversioninfosize = sizeof (OSVERSIONINFOEX);

Parallel is not supported if the platform does not support OSVERSIONINFOEX architecture

In the kernel, we've made these modifications linked together

//

if (! GetVersionEx ((OSVERSIONINFO *) &OSVIEX))

{

return FALSE; No DLL redirection

}

For NT, however, NT4 SP4 supports OSVERSIONINFOEX support, but it does not support DLL redirection.

If DLL redirection appears in the future NT4 SP, this code must be updated.

//

if ((Osviex.dwplatformid = = ver_platform_win32_nt) &&

(Osviex.dwmajorversion < 5))

{

return FALSE;

}

For other platform identities, it is assumed to have parallel support

return TRUE;

}