DllMain implementation

**George2** · 02-13-2008

Thanks Elysia,

I do not know what do you mean "mess around with the linker". My question is why main.obj is not shown as input command line of linker?

Originally Posted by Elysia

Whatever does it matter? You're using Visual Studio so you shouldn't have to mess around with the linker.

regards,
George

**Elysia** · 02-13-2008

My point is, why do you need to know? Visual Studio automatically passes everything correct to the linker, so you don't have to worry about it.

**matsp** · 02-13-2008

So, you are building an executable with a funciton called dllmain? I would still expect to see all object files being fed to the linker, but it may not be part of the command-line, as it may be part of an indirect input.

--
Mats

**George2** · 02-13-2008

Hi Elysia,

The reason why I am doing this, is because all our previous discussion is just theory discussion -- i.e. linker will search obj files before searching lib files. So, I want to make my hands dirty to make some test to show obj files are input before lib or something.

BTW: do you have any practice for us to illustrate (prove) your point -- linker will search obj files before searching lib files?

Originally Posted by Elysia

My point is, why do you need to know? Visual Studio automatically passes everything correct to the linker, so you don't have to worry about it.

Hi Mats,

"you are building an executable with a funciton called dllmain"

No, I am building the dll itself. I think if you tried in your own environment, I think you will find similar issues -- no object files as input to linker.

Originally Posted by matsp

So, you are building an executable with a funciton called dllmain? I would still expect to see all object files being fed to the linker, but it may not be part of the command-line, as it may be part of an indirect input.

--
Mats

regards,
George

**matsp** · 02-13-2008

Code:

/OUT:"D:\Visual Studio 2008\Projects\test_link1\Debug\test_link1.exe"

Really?

--
Mats

**George2** · 02-13-2008

My mistake, Mats!

Sorry, here is the correct information. You can see still no main.obj.

/OUT:"D:\Visual Studio 2008\Projects\test_link1\Debug\test_dll_link1.dll" /NOLOGO /DLL /MANIFEST /MANIFESTFILE:"Debug\test_dll_link1.dll.intermediat e.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"d:\Visual Studio 2008\Projects\test_link1\Debug\test_dll_link1.pdb" /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

regards,
George

**CornedBee** · 02-13-2008

The command line shown in the project properties is the result of your project settings. The actual input files are added when building.

You need to look at the log of the build process to find the real linker command line.

**matsp** · 02-13-2008

Right, I haven't got Visual Studio at work, so I can't say where the main.obj would be, but are you saying that your text is not being output when the DLL is "started"?

--
Mats

**George2** · 02-13-2008

You are correct, CornedBee!

Cool! Here is the build log and seems main.obj is appended as the end of linker input.

So, coming back to my original question, why do you think user provided DllMain (in main.obj) will be selected to be linked other than using CRT default one -- because obj has higher priority than lib?

--------------------
Creating temporary file "d:\Visual Studio 2008\Projects\test_link1\test_dll_link1\Debug\RSP0 0000168926972.rsp" with contents
[
/Od /D "_WINDLL" /D "_MBCS" /Gm /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc90.pdb" /W3 /c /ZI /TP ".\main.cpp"
]
Creating command line "cl.exe @"d:\Visual Studio 2008\Projects\test_link1\test_dll_link1\Debug\RSP0 0000168926972.rsp" /nologo /errorReport

rompt"
Creating temporary file "d:\Visual Studio 2008\Projects\test_link1\test_dll_link1\Debug\RSP0 0000268926972.rsp" with contents
[
/OUT:"D:\Visual Studio 2008\Projects\test_link1\Debug\test_dll_link1.dll" /DLL /MANIFEST /MANIFESTFILE:"Debug\test_dll_link1.dll.intermediat e.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"D:\Visual Studio 2008\Projects\test_link1\Debug\test_dll_link1.pdb" /DYNAMICBASE /NXCOMPAT /MACHINE:X86 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

".\Debug\main.obj"
]
Creating command line "link.exe @"d:\Visual Studio 2008\Projects\test_link1\test_dll_link1\Debug\RSP0 0000268926972.rsp" /NOLOGO /ERRORREPORT:PROMPT"
Creating temporary file "d:\Visual Studio 2008\Projects\test_link1\test_dll_link1\Debug\RSP0 0000368926972.rsp" with contents
[
/outputresource:"..\Debug\test_dll_link1.dll;#2" /manifest

".\Debug\test_dll_link1.dll.intermediate.manif est"
]
Creating command line "mt.exe @"d:\Visual Studio 2008\Projects\test_link1\test_dll_link1\Debug\RSP0 0000368926972.rsp" /nologo"
Creating temporary file "d:\Visual Studio 2008\Projects\test_link1\test_dll_link1\Debug\BAT0 0000468926972.bat" with contents
[
@echo Manifest resource last updated at %TIME% on %DATE% > ".\Debug\mt.dep"
]
Creating command line """d:\Visual Studio 2008\Projects\test_link1\test_dll_link1\Debug\BAT0 0000468926972.bat"""
--------------------

Originally Posted by CornedBee

The command line shown in the project properties is the result of your project settings. The actual input files are added when building.

You need to look at the log of the build process to find the real linker command line.

Hi Mats,

I have found in the build log, other than in the linker command line window, main.obj is added. And it is at the end of the command line. So the theory of sequence matters is not correct.

So, what is your point? Function in obj always has higher priority than in lib?

Originally Posted by matsp

Right, I haven't got Visual Studio at work, so I can't say where the main.obj would be, but are you saying that your text is not being output when the DLL is "started"?

--
Mats

regards,
George

**abachler** · 02-13-2008

Originally Posted by George2

Thanks Mats,

abachler and Elysia, any comments to my below points?
1. I do not think linker program writes special code for DllMain, and it should have a general rule to deal with how to use user defined one as higher priority if there is also a default one in lib;

regards,
George

Code:

#ifndef DllMain
 
BOOL APIENTRY DllMain( HANDLE hModule, 
                       DWORD  ul_reason_for_call, 
                       LPVOID lpReserved
      )
{
    switch (ul_reason_for_call)
 {
  case DLL_PROCESS_ATTACH:
             break;
  case DLL_THREAD_ATTACH:
            break;
  case DLL_THREAD_DETACH:
            break;
  case DLL_PROCESS_DETACH:
            break;
    }
    return TRUE;
}
 
#endif

or something similar. Im assuming though that rather than it being in some hidden headr file, that it actually just adds some generic code to the DLL. Now that I think about it Im almost positive it would have to be in the linker itself.

**matsp** · 02-13-2008

I guess MS linker works a bit differently than the gnu ld then - because there the order is definitely important. But it makes some sense to perform lib resolution AFTER the object files "enforced", as you do want all object files always, whilst lib content is optional.

--
Mats

**abachler** · 02-13-2008

hmm, Ive never tried overloading a function that was in a library Im linking to, perhaps that is how they do it?

**matsp** · 02-13-2008

Originally Posted by abachler

hmm, Ive never tried overloading a function that was in a library Im linking to, perhaps that is how they do it?

I have created my own malloc, using this method, for example.

--
Mats

**abachler** · 02-13-2008

Thats probably how its done then, some required lib for making a dll contains the generic DllMain, and the logic that subverts overloaded lib functions handles that one the same way. Oh now it almost makes me want to write my own compiler... almost.

**CornedBee** · 02-13-2008

Why would the generic DllMain have to be in some library? The linker might just have it hardcoded. We don't know, because MS doesn't document this stuff. But it also shouldn't matter.