Identifying Self-Registering Servers
Applications need to check to see if a given server module is self-registering without actually loading the .DLL or .EXE for performance reasons and to avoid possible negative side-affects of code within the module being executed without the module first being registered. To accomplish this, the .DLL or .EXE must be tagged with a version resource that can be read without actually causing any code in the module to be executed. On Windows platforms, this involves using the version resource to hold a self-registration keyword. Since the VERSIONINFO section is fixed and cannot be easily extended, the following string is added to the StringFileInfo, with an empty key value:
VALUE "OLESelfRegister", ""
For example:
VS_VERSION_INFO VERSIONINFO
FILEVERSION 1,0,0,1
PRODUCTVERSION 1,0,0,1
FILEFLAGSMASK VS_FFI_FILEFLAGSMASK
#ifdef _DEBUG
FILEFLAGS VS_FF_DEBUG|VS_FF_PRIVATEBUILD|VS_FF_PRERELEASE
#else
FILEFLAGS 0 // final version
#endif
FILEOS VOS_DOS_WINDOWS16
FILETYPE VFT_APP
FILESUBTYPE 0 // not used
BEGIN
BLOCK "StringFileInfo"
BEGIN
BLOCK "040904E4" // Lang=US English, CharSet=Windows Multilingual
BEGIN
VALUE "CompanyName", "\0"
VALUE "FileDescription", "BUTTON OLE Control DLL\0"
VALUE "FileVersion", "1.0.001\0"
VALUE "InternalName", "BUTTON\0"
VALUE "LegalCopyright", "\0"
VALUE "LegalTrademarks", "\0"
VALUE "OriginalFilename","BUTTON.DLL\0"
VALUE "ProductName", "BUTTON\0"
VALUE "ProductVersion", "1.0.001\0"
VALUE "OLESelfRegister", "" // New keyword
END
END
BLOCK "VarFileInfo"
BEGIN
VALUE "Translation", 0x409, 1252
END
END
To support self-registering servers, an application can add a browse button to its object selection user interface, which pops up a standard File.Open dialog. After the user chooses a .DLL or .EXE the application can check to see if it is marked for self-registration and, if so, call its DllRegisterServer entry point (or execute the .EXE with the /REGSERVER command line switch). The .DLL or .EXE should register itself at this point.