Dynamic-Link Library Entry-Point Function
Every DLL must have an entry point, just as an application does. The system calls the entry-point function whenever processes and threads load or unload the DLL. If you are linking your DLL with a library, such as the C run-time library, it may provide an entry-point function for you, and allow you to provide a separate initialization function. Check the documentation for your run-time library for more information.If you are providing your own entry-point, see the DllMain function. The name DllMain is a placeholder for a user-defined function. Earlier versions of the SDK documentation used DllEntryPoint as the entry-point function name. You must specify the actual name you use when you build your DLL. For more information, see the documentation included with your development tools. Calling the Entry-Point Function
The system calls the entry-point function whenever any one of the following events occurs: A process loads the DLL. For processes using load-time dynamic linking, the DLL is loaded during process initialization. For processes using run-time linking, the DLL is loaded before LoadLibrary or LoadLibraryEx returns. 
A process unloads the DLL. The DLL is unloaded when the process terminates or calls the FreeLibrary function and the reference count becomes zero. If the process terminates as a result of the TerminateProcess or TerminateThread function, the system does not call the DLL entry-point function. 
A new thread is created in a process that has loaded the DLL. You can use the DisableThreadLibraryCalls function to disable notification when threads are created. 
A thread of a process that has loaded the DLL terminates normally, not using TerminateThread or TerminateProcess. When a process unloads the DLL, the entry-point function is called only once for the entire process, rather than once for each existing thread of the process. You can use DisableThreadLibraryCalls to disable notification when threads are terminated. 
Only one thread at a time can call the entry-point function.The system calls the entry-point function in the context of the process or thread that caused the function to be called. This allows a DLL to use its entry-point function for allocating memory in the virtual address space of the calling process or to open handles accessible to the process. The entry-point function can also allocate memory that is private to a new thread by using thread local storage (TLS). For more information about thread local storage, see Thread Local Storage.Entry-Point Function Definition
The DLL entry-point function must be declared with the standard-call calling convention. Windows NT/ 2000: If the DLL entry point is not declared correctly, the DLL is not loaded, and the system displays a message indicating that the DLL entry point must be declared with WINAPI.Windows 95: If the DLL entry point is not declared correctly, the DLL is not loaded and the system displays a message titled "Error starting program," which instructs the user to check the file to determine the problem.In the body of the function, you may handle any combination of the following scenarios in which the DLL entry point has been called: A process loads the DLL (DLL_PROCESS_ATTACH). 
The current process creates a new thread (DLL_THREAD_ATTACH). 
A thread exits normally (DLL_THREAD_DETACH). 
A process unloads the DLL (DLL_PROCESS_DETACH). 
Your function should perform only simple initialization tasks, such as setting up thread local storage (TLS), creating synchronization objects, and opening files. It must not call the LoadLibrary function, because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. Similarly, you must not call the FreeLibrary function in the entry-point function, because this can result in a DLL being used after the system has executed its termination code. Calling Win32 functions other than TLS, synchronization, and file functions may also result in problems that are difficult to diagnose. For example, calling User, Shell, and COM functions can cause access violation errors, because some functions in their DLLs call LoadLibrary to load other system components. The following example demonstrates how to structure the DLL entry-point function.BOOL WINAPI DllMain(
    HINSTANCE hinstDLL,  // handle to DLL module
    DWORD fdwReason,     // reason for calling function
    LPVOID lpReserved )  // reserved
{
    // Perform actions based on the reason for calling.
    switch( fdwReason ) 
    { 
        case DLL_PROCESS_ATTACH:
         // Initialize once for each new process.
         // Return FALSE to fail DLL load.
            break;        case DLL_THREAD_ATTACH:
         // Do thread-specific initialization.
            break;        case DLL_THREAD_DETACH:
         // Do thread-specific cleanup.
            break;        case DLL_PROCESS_DETACH:
         // Perform any necessary cleanup.
            break;
    }
    return TRUE;  // Successful DLL_PROCESS_ATTACH.
}Entry-Point Function Return Value
When a DLL entry-point function is called because a process is loading, the function returns TRUE to indicate success. For processes using load-time linking, a return value of FALSE causes the process initialization to fail and the process terminates. For processes using run-time linking, a return value of FALSE causes the LoadLibrary or LoadLibraryEx function to return NULL, indicating failure. (The system immediately calls your entry-point function with DLL_PROCESS_DETACH and unloads the DLL.) The return value of the entry-point function is disregarded when the function is called for any other reason. 我在看MSDN时对以下关于 DLL的入口点函数的迷惑,请告诉我倒底这个函数新建了进程或线程吗?

解决方案 »

  1.   

    没有。是系统调用该函数通知 DLL 到底是调用了它        case DLL_PROCESS_ATTACH: 
            // 一个新的进程加载了DLL        case DLL_THREAD_ATTACH: 
            // 一个新的线程加载了DLL        case DLL_THREAD_DETACH:
            // 其中一个调用DLL的线程结束或卸载了DLL        case DLL_PROCESS_DETACH: 
            // 其中一个调用DLL的进程结束或卸载了DLL
      

  2.   

    进程/线程新建时,或进程/线程结束时调用DLL的入口点函数.
    DLL的入口点函数中一般不新建进程或线程.如果在DLL的入口点函数中新创建线程,则会出现:线程新建时调用DLL的入口点函数->在DLL的入口点函数中新创建线程->线程新建时调用DLL的入口点函数... 这样就真的很迷惑了...  :0
      

  3.   

    我又看了看后面的:
    If the system cannot locate a specified DLL, it terminates the process and displays a dialog box that reports the error. Otherwise, the system maps the DLL modules into the virtual address space of the process and increments the DLL reference count。
    如果系统没有找到指定的DLL,那么它将终止这个进程(?????,这个进程到底怎么回事),并弹出一个对话框来报告错误,否则,系统将映射这个DLL模块到这个进程(这个进程应该是调用这个Dll的那个进程吧)的虚地址空间,并且把DLL的引用计数器累加一。
        上面提到了2个进程,我觉得好象这2个进程不是同意个进程,以为我使用LoadLibrary去加载了一个并不存在的DLL,它只是返回NULL, 但没有中指我的调用进程哦。 所以我想问上面说的终止了进程,到底是什么进程?????
      

  4.   

    比如你运行了一个application,它调用了某个dll。那么当这个application启动的时候系统就会去查找dll,如果dll无法找到,那么这个application就会结束,并且弹出一个对话框来表示出错。如果找到了,那么该dll的模块就会被映射到application的进程地址空间中,并将dll的引用计数加一。
      

  5.   

    上面提到了2个进程,指的是一个进程.以上提到的情况,只发生在进程找不到所隐式依赖的DLL时.
    DLL的隐式链接是最常用的链接类型。Windows也支持显式链接(通过LoadLibrary)以下一些关于DLL的信息摘自<<Windows核心编程>>
    --------------------------------------------
    当一个可执行文件被启动时,操作系统加载程序将为该进程创建虚拟地址空间。然后,加
    载程序将可执行模块映射到进程的地址空间中。加载程序查看可执行模块的输入节,并设法找
    出任何需要的D L L,并将它们映射到进程的地址空间中。由于该输入节只包含一个D L L名而没有它的路径名。因此加载程序必须搜索用户的磁盘驱
    动器,找出D L L。下面是加载程序的搜索顺序:
    1) 包含可执行映像文件的目录。
    2) 进程的当前目录。
    3) Wi n d o w s系统目录。
    4) Wi n d o w s目录。
    5) PAT H环境变量中列出的各个目录。
    应该知道其他的东西也会影响加载程序对一个D L L的搜索(详细说明参见第2 0章)。当
    D L L模块映射到进程的地址空间中时,加载程序要检查每个D L L的输入节。如果存在输入节
    (通常它确实是存在的),那么加载程序便继续将其他必要的D L L模块映射到进程的地址空间
    中。加载程序将保持对D L L模块的跟踪,使模块的加载和映射只进行一次(尽管多个模块需
    要该模块)。
    如果加载程序无法找到需要的D L L模块,用户会看到图1 9 - 2、图1 9 - 3所示的消息框中的一
    个:如果是Windows 2000,那么将出现图1 9 - 2所示的消息框,如果是Windows 98,则出现图
    1 9 - 3所示的消息框。
    ... ...
      

  6.   

    to punpuny:你说的正确。MSDN上说了有2种加载:Load - time dynamic linking :   将终止调用DLL的进程或线程
    Run - time dynamic linking :    不会终止................:)
      

  7.   

    Run-time dynamic linking enables the process to continue running even if a DLL is not available. The process can then use an alternate method to accomplish its objective. For example, if a process is unable to locate one DLL, it can try to use another, or it can notify the user of an error. If the user can provide the full path of the missing DLL, the process can use this information to load the DLL even though it is not in the normal search path. This situation contrasts with load-time linking, in which the system simply terminates the process if it cannot find the DLL.