Partager via

CLSID Key (Windows Embedded CE 6.0)

  • Article

1/6/2010

A CLSID is a globally unique identifier that identifies a COM class object. If your server or container allows linking to its embedded objects, then you need to register a CLSID for each supported class of objects. The CLSID is stored under the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID = <CLSID>

The CLSID value specifies a name that can be displayed in the user interface. The CLSID value contains information used by the default COM handler to return information about a class when it is in the running state. To obtain a CLSID for your application, you can use CoCreateGuid. The CLSID is a 128-bit number, spelled in hexadecimal format, within a pair of braces.

The following table shows the named values for the HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{CLSID} key.

Value : type Description

\<CLSID> = HumanReadableName

A globally unique identifier (GUID) used to map information about a component class. The value entry specifies a human readable name that can be displayed in the user interface.

COM uses the information mapped by the CLSID to locate and create an instance the object associated with the CLISID.

\AppID = <CLSID>

Associates an application identifier (AppID) with a CLSID.

\AutoConvertTo = <CLSID>

Specifies the automatic conversion of a given class of objects (ClsidOld) to a new class of objects (pClsidNew). The value entry contains the class identifier of the object to which a given object or class of objects should be converted.

This key is typically used to automatically convert files created by an older version of an application to a newer version of the application.

\AutoTreatAs = <CLSID>

Automatically sets the CLSID for the TreatAs key to the specified value. The value entry specifies the CLSID that will automatically be assigned to the TreatAs entry.

\Control

Identifies an object as an ActiveX Control. This optional entry is used by containers to fill dialog boxes. The container uses this named value to determine whether to include an object in a dialog box that displays ActiveX Controls. A control can omit this entry if it is only designed to work with a specific container and thus does not need to be inserted in other containers.

\DefaultIcon = <full path to exe, resource id>

Provides default icon information for iconic presentations of objects. This value specifies the full path to the executable name of the object application and the resource index of the icon within the executable.

DefaultIcon identifies the icon to use when, for example, a control is minimized to an icon. This entry contains the full path to the executable name of the server application and the resource index of the icon within the executable. Applications can use the information provided by DefaultIcon to obtain an icon handle with the ExtractIconEx function.

The following code example shows the settings for this value:

HKEY_CLASSES_ROOT\CLSID\{00000402-0000-0000-C000-000000000046} 
\DefaultIcon = c:\samp\isvrotl.exe,0

\InprocHandler32 = <handler.dll>

Registers a 32-bit handler DLL. This value specifies the custom handler used by the application.

If a custom handler is not used, the entry should be set to OLE32.DLL, as shown in the following example.

HKEY_-CLASSES_ROOT\CLSID\{00000402-0000-0000-C000-000000000046} 
\InprocHandler = ole32.dll

If a container is searching the registry for an InprocHandler, the 16-bit version has priority with a 16-bit container, and the 32-bit version has priority with a 32-bit container.

\InprocServer32 = <path to 32-bit inproc server>\ThreadingModel = <threading model>

Registers a 32-bit in-process server DLL and specifies the threading model of the apartment the server can run in.

The <path to 32-bit inproc server> value specifies the path to the 32-bit in-process server.

The <threading model> value specifies the threading model of the apartment the server can run in. In-process servers are loaded into an existing apartment and so do not call CoInitialize or CoInitializeEx; they must use the registry to specify an application's threading model. Allowable values are:

  • ThreadingModel=Apartment. Single-threaded apartment.
  • ThreadingModel=Both. Single-threaded or multithreaded apartment.
  • ThreadingModel=Free. Multithreaded apartment.
  • ThreadingModel=Neutral. Neutral apartment (available in Windows 2000).

If the ThreadingModel key is not in the registry or no value is entered for it, the server is loaded into the first apartment that was initialized in the process. This apartment is sometimes referred to as the main single-threaded apartment (STA). If the first STA in a process is initialized by COM, rather than by an explicit call to CoInitialize or CoInitializeEx, it is called the host STA. COM creates a host STA, for example, if an in-process server to be loaded requires an STA but there is currently no STA in the process.

The ThreadingModel value must be the same for all objects provided by an in-process server.

Whenever possible, the in-process server is loaded in the same apartment as the client that loads it. If the threading model of the client apartment is not compatible with the model specified by the ThreadingModel value of the InprocServer32 key, the server is loaded as follows:

  • Free threading model = apartment server runs in multithreaded apartment
  • Neutral threading model = apartment server runs in neutral apartment
  • Both = apartment server runs in same apartment as client
  • If this value is unspecified, the main STA applies.

If the threading model of the server is Apartment, the apartment the server is loaded in depends on the apartment the client is running in. The following list shows the possible dependencies between client and server apartments:

  • Multithreaded = apartment server runs in Host STA
  • Neutral (on STA thread) = apartment server runs on same apartment as client
  • Neutral (on MTA thread) = apartment server runs on Host STA

COM can also create a host multithreaded apartment (MTA). If a client in a single-threaded apartment requests an in-process server whose threading model is Free when there is no MTA in the process, COM creates a host MTA and loads the server into it.

For a 32-bit in-process server, the InprocHandler32, InprocServer, InprocServer32, and Insertable keys must be registered. The InprocServer entry is needed only for backward compatibility. If it is missing, the class will still work, but it cannot be loaded in 16-bit applications.

If a container is searching the registry for an in-process server, the 16-bit version has priority with a 16-bit container, and the 32-bit version has priority with a 32-bit container.

\Interface\<IID> = <name of interface1>\<IID> = <name of interface2>\...

An optional entry that specifies all interface IDs (IIDs) supported by the associated class. The values for this key specify the interfaces supported by this class. If an interface name is not present in this list, then the interface can never be supported by an instance of this class.

\LocalServer32 = <full path>

Specifies the full path to a 32-bit local server application. This value can also include command-line arguments.

COM appends the "-Embedding" flag to the string, so the application that uses flags will need to parse the whole string and check for the -Embedding flag. The following code example shows the setting for this value.

HKEY_CLASSES_ROOT\CLSID\{00000402-0000-0000-C000-000000000046} 
\LocalServer32 = c:\samp\isvrotl.exe

When COM starts a 32-bit local server, the server must register a class object within an elapsed time set by the user. By default, the elapsed time value must be at least five minutes, entered in milliseconds, but cannot exceed the number of milliseconds in 30 days. Applications typically should not set this value. This value is in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM2\ServerStartElapsedTime entry.

The required entries for 32-bit local servers are InprocHandler32, LocalServer, LocalServer32, and Insertable.

If a container is searching the registry for a local server, a 32-bit local server has priority over a 16-bit local server.

\ProgID = <programmatic identifier>

Programmatic identifier for a class. This value specifies the ProgID: <vendor>.<component>.<version>.

Every insertable object class has a <ProgID>.

\TreatAs = <CLSID>

Specifies the CLSID of a class that can emulate the current class.

Emulation is the ability of one application to open and edit an object of a different class, while retaining the original format of the object.

\Verb \1 = <verb1>\2 = <verb2>\3 =

Specifies the verbs to be registered for an application.

Each value specifies a verb, and its associated menu and verb flags. Each verb is specified by its own NamedValue / Value pair, as in verb number = <name, menu flag, verb flag> For example: \Verb  0 = &Edit, 0, 2 // primary verb; on menu, possibly dirties object, 1 = &Play, 0, 3 // other verb; on menu; leaves object clean -3 = Hide, 0, 1 // pseudo verb, hides window; not on menu, opt. -2 = Open, 0, 1 // pseudo verb, opens in sep. window; not on menu, opt. -1 = Show, 0, 1 // pseudo verb, show in preferred state; not on menu, opt.

For general information about verbs, descriptions of COM predefined verbs, and positive and negative verbs, as well as other material, see IOleObject::DoVerb.

Verbs must be numbered consecutively. The first value after the verb string describes how the verb is appended by an AppendMenu function call.

The second value indicates whether the verb will dirty the object. It also indicates whether the verb should appear in the menu, as defined by COMVERBATTRIB enumeration, used by the COMVERB structure.

For more information, see IOleObject::EnumVerbs and OleRegEnumVerbs.

The following code examples show two example entries:

Verb 0: "Edit", MF_UNCHECKED | MF_ENABLED, no COMVERATTRIB flags: 
HKEY_CLASSES_ROOT\CLSID\{00000402-0000-0000-C000-000000000046} 
\Verb\0 = &Edit,0,0 
Verb 1: "Open", MF_UNCHECKED | MF_ENABLED, no COMVERATTRIB flags: 
HKEY_CLASSES_ROOT\CLSID\{00000402-0000-0000-C000-000000000046} 
\Verb\1 = &Open,0,0

\Version = <VersionNumber>

Specifies the version number of the control.

The version number should match the version of the type library associated with the control.

See Also

Concepts

COM and DCOM Registry Settings
COM and DCOM Security

Other Resources

Component Services (COM and DCOM)
Enhancing the Security of a Device