1

I am running inside a process where COMCTL32.DLL is loaded twice, once with the version 5.82.7601.17514 and once with the version 6.10.7601.17514. The legacy version is loaded by some legacy DLL the program is linked with, and the other version is loaded by a newer DLL.

If I use GetModuleHandle (L"COMCTL32.DLL") I have no control over the DLL which gets resolved.

When I call GetProcAddress to reach, for instance, TaskDialogIndirect, I get a null pointer back, which is certainly because I got back the handle of the legacy DLL.

So, is there some means of getting to the address of, say TaskDialogIndirect when both DLLs are loaded.

If not, can I somehow make sure that the process loads the 6.10 version and not the 5.82, in the hope that our legacy DLL will work fine with the newer version of COMCTL32?

Dialecticus
  • 16,400
  • 7
  • 43
  • 103
Pierre Arnaud
  • 10,212
  • 11
  • 77
  • 108
  • A possible quick fix is to open a copy of the DLL in Visual Studio with File + Open + File and delete the manifest resource. – Hans Passant Aug 31 '11 at 21:18
  • Finally, we fixed the issue by making sure the application was using the 2new" look by adding a manifest, not by removing it. However, the new look (COMCTL32 v6) has several compatibility issues. – Pierre Arnaud Sep 08 '11 at 03:26

1 Answers1

5

I guess you are having to use GetProcAddress() rather than implicit linking because you want your app to run on XP where task dialog is not available.

I can see three options for you:

  1. Use implicit linking, but use delay loading as supported by the MS tool chain. I'm not 100% certain that will give you the correct comctl32 but it's worth a try.
  2. Use the activation context API to make sure that the comctl32 v6 manifest is in play when you call LoadLibrary(). Call LoadLibrary() rather than GetModuleHandle() to make sure that you get the manifest magic.
  3. Enumerate all the modules in the process and select the correct version of comctl32. There is a comprehensive example of how to do this on MSDN.

The activation context approach is the cleanest solution, but the activation context API can be tricky to get into. I personally have used it to ensure that an Excel COM add-in links to comctl32 v6.

The module enumeration approach is quick to implement, somewhat dirty, but will work well.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • We will give (3) a try, as it seems to be a good replacement for what our code needs to do. I was not aware of the *activation context API* , thank you for pointing me at it too. – Pierre Arnaud Sep 01 '11 at 03:31
  • The activation API was finally not needed. We were able to fix the legacy code so that it would link to `COMCTL32` v6. – Pierre Arnaud Sep 08 '11 at 03:26
  • 1
    Thank you so much David, this did help fix a major problem that we where having. Going to write up a report on it. – Chad Mar 09 '12 at 12:16