Manifest plays foul

[MichaelW]

http://blogs.msdn.com/b/oldnewthing/archive/2005/07/18/439939.aspx

[jj2007]

So it's the DllMain of COMCTL32.DLL that does the initialisation job.

However, Chen's argument chain is not convincing - we observe the contrary:

Recall that merely listing a lib file in your dependencies doesn't actually cause your program to be bound to the corresponding DLL. You have to call a function in that DLL in order for there to be an import entry for that DLL. And InitCommonControls is that function.

Without the InitCommonControls function, a program that wants to use the shell common controls library would otherwise have no reference to COMCTL32.DLL in its import table. This means that when the program loads, COMCTL32.DLL is not loaded and therefore is not initialized. Which means that it doesn't register its window classes. Which means that your call to the CreateWindow function fails because the window class has not been registered.

[sinsi]

Slightly off-topic, but the later linkers let you specify manifest details on the command line, no need for a resource file.

[MichaelW]

However, Chen's argument chain is not convincing - we observe the contrary

His arguments are a bit imprecise, but he gets the essential point across. It's not surprising that a call to InitCommonControls that never executes has the same effect on load-time linking as a call that does execute, or that an EXTERN/EXTERNDEF statement works, or that an InitCommonControls PROTO (which automatically generates an EXTERNDEF) works. But it is surprising, at least to me, that a:

Code Select Expand


dd InitCommonControls

, even in the data section, also works, like the other methods, causing the linker to create a COMCTL32.DLL reference in the imports:

Code Select Expand


Imp Addr Hint Import Name from comctl32.dll - Not Bound
-------- ---- ---------------------------------------------------------------
00002000   54 InitCommonControls


[TWell]

you can save 4 bytes by using MASM's EXTERN directive and the linker option /OPT:NOREF

Code Select Expand

EXTERN InitCommonControls@0:NEAR

using named variable it is usable for temporary memory place too and not wasted ;)

Code Select Expand

.data
foo dd InitCommonControls

[dedndave]

i wonder.....
we sometimes use LoadLibrary/FreeLibrary, and GetProcAddress to get a function address
i wonder if referencing a function in a library would allow you to use GetModuleHandle

[dedndave]

Code Select Expand

;###############################################################################################

        .XCREF
        .NoList
        INCLUDE     \Masm32\Include\Masm32rt.inc
        INCLUDE     \Masm32\Include\AdvApi32.inc
        INCLUDELIB  \Masm32\Lib\AdvApi32.lib
        .List

;###############################################################################################

        .DATA

          dd RegCloseKey
szAdvApi  db 'AdvApi32.dll',0
szEnumKey db 'RegEnumKeyA',0

;***********************************************************************************************

        .DATA?

;###############################################################################################

        .CODE

;***********************************************************************************************

_main   PROC

    INVOKE  GetModuleHandle,offset szAdvApi
    .if eax
        INVOKE  GetProcAddress,eax,offset szEnumKey
    .endif
    print uhex$(eax),13,10

    print   chr$(13,10)
    inkey
    INVOKE  ExitProcess,0

_main   ENDP

;###############################################################################################

        END     _main

result

Code Select Expand

77DE53B8

it seems to work   
if i comment out

Code Select Expand

     ;    dd RegCloseKey
it returns 0