COMponents mscomctl.ocx, mscomct2.ocx, mswinsck.ocx: set off Kill-Bit programmatically

On Windows 7, the COMponents listed in the title seem by default to have the "killbit" set to COMPAT_EVIL_DONT_LOAD (compare MSDN), that is, their Compatibility Flags in HKLM\SW\IE\ActiveX Compatibility\{<CLSID>}\ seem to be set to that value by default:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{B09DE715-87C1-11D1-8BE3-0000F8754DA1}]
"Compatibility Flags"=dword:00000400

When I set the value to 0 (that's what Nirsoft's ActiveX Compatibility Manager does when "activating" a COMponent), everything works fine.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{B09DE715-87C1-11D1-8BE3-0000F8754DA1}]
"Compatibility Flags"=dword:00000000

But this is just a GUI solution for one workstation. To deploy our software, I need a safe and stable procedure (script or tool) to ship with our software, that not only sets the "killbit" to 0 or deletes the registry entry (which procedure should be preferred?), but checks the situation before and does nothing if nothing is necessary. Preferably, the solution would just be passed over a file name or a list of files and proceeds everything else necessary on its own.

This is the point where the bigger questions begin:

• Regarding COM objects, the registry is queried by CLSID, not by ocx file name (that is the InProcServer32 entry in the Windows registry) nor by (VersionIndependent)ProgID (HKLM\Software\Classes\CLSID\{<CLSID>}\). Do you know a method, i.e., a batch / (PowerShell) script / tool / whatever to query the CLSIDs related to an ocx file or at least the ProgID radical?
• I understand the CLSID is constant in Windows 2000 up to 7?
• SlayOCX.vbs seems to be a low level approach that, called as a group policy as described in SlayOCX.vbs and here, could work as a network-wide solution. But: It's a vbs, switched off in some environments. Furthermore, I will end up with quite a list of CLSIDs to be checked by this script. Wrapped e.g. in a batch I will probably not be able to have it deployed by the customers' admins in the described way, but rather by logon script or runonce key in the registry or something -- not very elegant. So what would you suggest? I'd prefer a solution (a tool, a new group policy in 7 I don't know开发者_运维百科 yet, a more sophisticated script with less dependency on system and security configuration issues, ...) that makes the first informational questions superfluous.

You want to expose your clients knowingly to security vulnerabilities? I am not a lawyer, but...

According to this post, the files mentioned are "Supported Runtime Files to Distribute with Your Application", you just need to update to the latest version.

Another post details the necessary steps (probably for an older update, but still it should get you started): Clickety

CLSID Registry Scanner (COM/ActiveX)

is my answer to my own question. It's working for now, that's important for me now. It would be a moot discussion if it was not better to rewrite or at least refurbish the program, or both independently, and get rid of old hats. Would be moot because I do not make our budget decisions.

With the exception of the Treeview replacement code or API calls can be found for most usages of these OCXs. Apparently there was some German commented API code available for purchase years ago for the treeview. All these OCXs are is a wrapper for the API calls anyhow.

See the Calendar Tips page at my website

The mswinsck is a bit trickier and I don't have a URL for that one. However I'm sure there is VB6 code that can be found that will work quite nicely in VBA.

Blog posting - An older version of MSCOMM32.OCX has had the "kill bit" flag set. Although you don't mention this one.