DllMain implementation

Hello everyone,


CRT is implemented a way that if developer provides DllMain, it will use the provided one, or else the default DllMain is used.

I am wondering how to implement similar selective linking approach? i.e. if there are more than one implementations of a method of the same signature, I can control which one has the higher priority to link, and if the highest priority one does not exist, the second priority one will be used (and compiler will have no duplicated method warning/error).

I do not think CRT implements the approach by using MACRO (if developer provides DllMain, developer needs to define some MACRO, but actually we do not define any macro when writing DllMain) to control the selective linking to DllMain.

Any ideas?


thanks in advance,
George

Quote:

---

CRT is implemented a way that if developer provides DllMain, it will use the provided one, or else the default DllMain is used.

---

Actually, I'm pretty sure that the trick is not the CRT, but the linker itself: if it finds a user-provided DllMain, it uses it; otherwise it supplies a built-in no-op version.

Thanks CornedBee,


I think you mean the sequence of object/lib files input to linker matters?

(user defined DllMain is set to linker input before CRT default DllMain?)

Quote:

---

Originally Posted by CornedBee

Actually, I'm pretty sure that the trick is not the CRT, but the linker itself: if it finds a user-provided DllMain, it uses it; otherwise it supplies a built-in no-op version.

---

regards,
George

It doesn't matter. If it finds a user-specific DllMain, regardless of the other the files are passed, it will use it, otherwise the CRT default.
...I think is what CornedBee is suggesting.

Thanks Elysia,


So you think the sequence of input object/lib files to the linker matters?

If yes, can you post your linker whole command line option please? :-)

Quote:

---

Originally Posted by Elysia

It doesn't matter. If it finds a user-specific DllMain, regardless of the other the files are passed, it will use it, otherwise the CRT default.
...I think is what CornedBee is suggesting.

---

regards,
George

Ordering of object/lib does normally not matter, but there are some situations where it does. For example, if the linker expects to find DllMain before it encounters the .lib version (which is the case for example if you want to implement your own version of other library functions), then you have to make sure that YOUR object file is BEFORE the .lib - this is the normal ordering for Visual Studio anyways, so it won't make much difference.

If it works like I described above, that the DllMain() is introduced from a .lib if it's not part of the object files, you'd get a linker error for duplicate symbols if you have the libs first then the main object files - but there's no real reason for that to happen unless you go out of your way to create such a situation. Just like buying a car with the steering wheel on the right-hand side is quite easy here in England, but a car-dealer in the US would not hold many of those in stock, so the fact that it makes it awkward to drive such a car in the US is not really an issue for you and me.

--
Mats

As CornedBee stated. Either the compiler or the linker handles inserting the default DllMain function. This is not limited to CRT. If you supply a DllMain it uses yours, otherwise it uses a default version that does nothing. Rather like the use of default constructor code for a class.

Oh, and we do have some right side cars here, mostly mail trucks.

Quote:

---

Originally Posted by George2

So you think the sequence of input object/lib files to the linker matters?

---

My point was that it doesn't matter what order.

Quote:

---

If yes, can you post your linker whole command line option please? :-)

---

And even if yes, I don't mess around with linker options. That's why we use IDEs!
Set specific options and don't modify the compiler or linker commands.

Thanks Mats,


abachler and Elysia, any comments to my below points?

Your reply covers generally how it works, but it does not cover internally why linker will select user defined DllMain other than default one provided by CRT -- which is the main point of this question. Maybe I can ask this question in another way.

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;

2. The another way to ask this question should be, suppose we want to override a function foo defined in CRT, how to achive this goal (put foo.obj before CRT libs in linker options?)

Quote:

---

Originally Posted by matsp

Ordering of object/lib does normally not matter, but there are some situations where it does. For example, if the linker expects to find DllMain before it encounters the .lib version (which is the case for example if you want to implement your own version of other library functions), then you have to make sure that YOUR object file is BEFORE the .lib - this is the normal ordering for Visual Studio anyways, so it won't make much difference.

If it works like I described above, that the DllMain() is introduced from a .lib if it's not part of the object files, you'd get a linker error for duplicate symbols if you have the libs first then the main object files - but there's no real reason for that to happen unless you go out of your way to create such a situation. Just like buying a car with the steering wheel on the right-hand side is quite easy here in England, but a car-dealer in the US would not hold many of those in stock, so the fact that it makes it awkward to drive such a car in the US is not really an issue for you and me.

--
Mats

---

regards,
George

Quote:

---

Originally Posted by George2

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;

---

We're telling you it's simple. It searches all libraries for DllMain. If not found, it selects the CRT default DllMain (which consequently might not be named DllMain either, because function names are irrelevant to the linker).

Quote:

---

2. The another way to ask this question should be, suppose we want to override a function foo defined in CRT, how to achive this goal (put foo.obj before CRT libs in linker options?)

---

You don't. You will most likely get multiple symbols error.

Quote:

---

Originally Posted by George2

2. The another way to ask this question should be, suppose we want to override a function foo defined in CRT, how to achive this goal (put foo.obj before CRT libs in linker options?)

---

Quote:

---

Originally Posted by Elysia

You don't. You will most likely get multiple symbols error.

---

If we put "foo.obj" ahead of any libraries should work just fine, and no you shouldn't get duplicate symbols, unless foo.obj isn't a COMPLETE replacement of the object file that it's attempting to replace [e.g. if you replace printf, but sprintf is also in the same xprintf.obj, then you get the a problem with printf being declared both on foo.obj and xprintf.obj - not that I think that this is the case in this particular case, but some object files do contain more than one function].

--
Mats

Though I wouldn't venture as far as relying on it since there's no saying the linker has to do it that way. If it searches all libraries, then you might just as well get a big fat problem.
Such as defining two main will get symbols error. But maybe that's just because it's within the same application.

Quote:

---

Originally Posted by Elysia

Though I wouldn't venture as far as relying on it since there's no saying the linker has to do it that way. If it searches all libraries, then you might just as well get a big fat problem.
Such as defining two main will get symbols error. But maybe that's just because it's within the same application.

---

Let's put it this way: I have so far not found a linker that doesn't take things in the order specified, and only drags out .lib content AS NEEDED. In fact, it's documented that you sometimes have to specify the same lib twice for gcc's ld, because it doesn't rescan a previous lib for stuff needed in the current one, so you need the lib specified again.

--
Mats

Thanks Mats and Elysia,


I did some self-study work, please comment.

I have written the following simple code to generate a DLL and name it main.cpp,

Code:

---

#include <iostream>
#include <objbase.h>

using namespace std;

BOOL APIENTRY DllMain(HANDLE hModule,
                      DWORD dwReason,
                      void* lpReserved)
{
        if (dwReason == DLL_PROCESS_ATTACH)
        {
                cout << "Hello World" << endl;
        }
        return TRUE ;
}

---

Linker command line is (from command line item of Linker item of Visual Studio project properties),

/OUT:"D:\Visual Studio 2008\Projects\test_link1\Debug\test_link1.exe" /NOLOGO /MANIFEST /MANIFESTFILE:"Debug\test_link1.exe.intermediate.ma nifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"D:\Visual Studio 2008\Projects\test_link1\Debug\test_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

My confusion is, why main.obj is not an input file to linker? Main.obj is generated.

Quote:

---

Originally Posted by matsp

Let's put it this way: I have so far not found a linker that doesn't take things in the order specified, and only drags out .lib content AS NEEDED. In fact, it's documented that you sometimes have to specify the same lib twice for gcc's ld, because it doesn't rescan a previous lib for stuff needed in the current one, so you need the lib specified again.

--
Mats

---

regards,
George

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

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?

Quote:

---

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

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.

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

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?

Quote:

---

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.

Quote:

---

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

Code:

---

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

---

Really?

--
Mats

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

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.

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

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:prompt"
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"""
--------------------

Quote:

---

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?

Quote:

---

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

Quote:

---

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.

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

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

Quote:

---

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

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. :D

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.

DllMain exists in (my environment with Visual Studio 2008)

D:\Program Files\Microsoft Visual Studio 9.0\VC\crt\src\dllmain.c

Code:

---

BOOL WINAPI DllMain(
        HANDLE  hDllHandle,
        DWORD  dwReason,
        LPVOID  lpreserved
        )
{
#if defined (CRTDLL)
        if ( dwReason == DLL_PROCESS_ATTACH && ! _pRawDllMain )
                DisableThreadLibraryCalls(hDllHandle);
#endif  /* defined (CRTDLL) */
        return TRUE ;
}

---

The pending issues is,

We need to prove in which lib file DllMain (default) exists;

Quote:

---

Originally Posted by CornedBee

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.

---

regards,
George

Quote:

---

We need to prove in which lib file DllMain (default) exists;

---

Why?

Thanks CornedBee,


Maybe I can ask the question in another way, I have shown the source code of CRT default DllMain. But where is the binary format one?

Quote:

---

Originally Posted by CornedBee

Why?

---

regards,
George

Again, why?

I suppose if you look in the crt\src directory, you can find where a makefile or some such, which uses this file for input and produces an output file - such as libc.lib, perhaps.

I agree with CornedBee - why does it matter?

--
Mats

Thanks CornedBee and Mats,


My point is, we need to prove obj has higher priority than lib when linking met with the same symbol, like a function, right?

So, we need to make sure the default CRT provided DllMain is in lib, and this is my logics.

Any comments?

Quote:

---

Originally Posted by matsp

I suppose if you look in the crt\src directory, you can find where a makefile or some such, which uses this file for input and produces an output file - such as libc.lib, perhaps.

I agree with CornedBee - why does it matter?

--
Mats

---

regards,
George

Well, you can try that theory by implementing a replacement function for anything else provided in a library, such as printf, malloc, etc, etc.

--
Mats

Thanks Mats,


I have tried,

1. Implement a function in a cpp file and comple it to obj file;
2. Implement another function with the same name in a cpp file, and compile/build into static lib file;
3. Implement a client cpp file to invoke the function;
4. No matter we provide the obj file before or after the lib file to build the application, the function in obj file will be invoked.

I am just interested in where the default DllMain is and if it is in a lib, our theory is good, if not (for example, in another obj file, then our theory will have trouble) :-)

Quote:

---

Originally Posted by matsp

Well, you can try that theory by implementing a replacement function for anything else provided in a library, such as printf, malloc, etc, etc.

--
Mats

---

regards,
George

What obj file would it be in? It's in a library, or I'll eat the hat that is on top of my cupboard at home [it's a straw one, so I'm not exactly feeling that it's good eating material].

I was trying to find it yesterday, but I didn't have the right tools to do it on my home machine. Here at work I don't think I have the libraries [or the time].

--
Mats

Thanks Mats,


What tools could be used to find the contained exported functions of a static library? Dumpbin? I have the tools at hand and if you can direct me How-to, I can do the practices and post the results here. :-)

Quote:

---

Originally Posted by matsp

What obj file would it be in? It's in a library, or I'll eat the hat that is on top of my cupboard at home [it's a straw one, so I'm not exactly feeling that it's good eating material].

I was trying to find it yesterday, but I didn't have the right tools to do it on my home machine. Here at work I don't think I have the libraries [or the time].

--
Mats

---

regards,
George

Well, "lib /list somelibrary" will show which object files there are. Then use "lib /extract somelibrary someobj" to extract a suspect library, and dumpobj to actually see the contents [assuming it's not obvious what it is and does already, e.g called DllMain.obj - but you probably want to confirm that it REALLY is what you say].

--
Mats

Im going to assume that the default DllMain just clears the stack and returns, so it probably isnt part of an external library.

Thanks Mats,


Do you think the locations to find the libs to be scanned is? Any other locations do you think needed?

cd D:\Program Files\Microsoft Visual Studio 9.0\VC\lib

If you agree this is the only location to be scanned, there are many libs, which one(s) do you think we need to scan?

2007/11/06 21:06 419,840 comsupp.lib
2007/11/06 21:06 435,758 comsuppd.lib
2007/11/06 21:06 419,624 comsuppw.lib
2007/11/06 21:06 435,562 comsuppwd.lib
2007/11/06 20:19 63,258 delayimp.lib
2007/11/06 20:19 9,218,246 libcmt.lib
2007/11/06 20:19 11,364,288 libcmtd.lib
2007/11/06 20:19 5,019,506 libcpmt.lib
2007/11/06 20:19 6,409,034 libcpmtd.lib
2007/11/06 20:19 1,524,102 msvcmrt.lib
2007/11/06 20:19 1,620,522 msvcmrtd.lib
2007/11/06 20:19 1,650,568 msvcprt.lib
2007/11/06 20:19 1,823,396 msvcprtd.lib
2007/11/06 20:19 1,353,800 msvcrt.lib
2007/11/06 20:19 1,386,760 msvcrtd.lib
2007/11/06 20:19 12,819,158 msvcurt.lib
2007/11/06 20:19 14,193,848 msvcurtd.lib
2007/11/06 20:19 101,414 oldnames.lib
2004/03/07 13:58 17,576 opends60.lib
2007/11/06 20:20 4,904 pgobootrun.lib
2007/11/06 20:20 27,710 pgort.lib
2007/11/06 20:19 427,220 ptrustm.lib
2007/11/06 20:19 434,432 ptrustmd.lib
2007/11/06 20:19 427,220 ptrustu.lib
2007/11/06 20:19 434,432 ptrustud.lib
2007/11/06 20:19 485,218 RunTmChk.lib
2007/11/06 21:22 28,446 vcomp.lib
2007/11/06 21:22 28,574 vcompd.lib

Quote:

---

Originally Posted by matsp

Well, "lib /list somelibrary" will show which object files there are. Then use "lib /extract somelibrary someobj" to extract a suspect library, and dumpobj to actually see the contents [assuming it's not obvious what it is and does already, e.g called DllMain.obj - but you probably want to confirm that it REALLY is what you say].

--
Mats

---

Hi abachler,


I have posted default implementation of DllMain in post #31, I am not sure whether you description below conforms to the default implementation of DllMain. Any comments?

Quote:

---

Originally Posted by abachler

Im going to assume that the default DllMain just clears the stack and returns, so it probably isnt part of an external library.

---

regards,
George

I would start with the libc*.lib - then the msvc*.lib - note that there are several libs that have the same content, e.g. libcmt.lib, libcmtd.lib, libcpmtd.lib and libcpmt.lib all have the same functions [nearly all the same at least - the debug version (name ending with "d") may have some debug code in it that isn't in the other libs, but that's not what you are looking for].

--
Mats

Thanks Mats,


I did two search, one hit. Any comments?

1.

D:\Program Files\Microsoft Visual Studio 9.0\VC\lib>lib /list libc*.lib | "d:\Pr
ogram Files\GnuWin32\bin\grep.exe" "dllmain"
f:\dd\vctools\crt_bld\SELF_X86\crt\src\build\INTEL \mt_obj\dllmain.obj

2.

D:\Program Files\Microsoft Visual Studio 9.0\VC\lib>lib /list msvc*.lib | "d:\Pr
ogram Files\GnuWin32\bin\grep.exe" "dllmain"

(nothing found)

Quote:

---

Originally Posted by matsp

I would start with the libc*.lib - then the msvc*.lib - note that there are several libs that have the same content, e.g. libcmt.lib, libcmtd.lib, libcpmtd.lib and libcpmt.lib all have the same functions [nearly all the same at least - the debug version (name ending with "d") may have some debug code in it that isn't in the other libs, but that's not what you are looking for].

--
Mats

---

regards,
George

Yes, libc was my first guess, so it sounds like you've found it.

--
Mats

Thanks Mats,


Seems our conclusion is correct -- obj has higher priority during linking than lib? :-)

Quote:

---

Originally Posted by matsp

Yes, libc was my first guess, so it sounds like you've found it.

--
Mats

---

regards,
George

Yes, it's how it NORMALLY works, but in GNU ld, the order is important too.

--
Mats

Thanks Mats,


My question is answered.

Quote:

---

Originally Posted by matsp

Yes, it's how it NORMALLY works, but in GNU ld, the order is important too.

--
Mats

---

regards,
George