Engine design Tracking (nine. 14.2e) delayloaded DLLs (/delayload)

About delay load:http://msdn.microsoft.com/en-us/library/151kt790.aspx for DLLs

Shader compiler, who recently made Gles, turned the existing HLSL into GLSL.

Because Shaderresource is defined in the graphics Subsystem, and the graphics is a plugin, placed under tools\plugins\

While the transfer shader process, shader compiler need to directly rely on shader Resource, so to link bladegraphics.xxx

This time the problem arises, if the program itself to manually load the DLL, then you can specify the search path,

However, for a program that directly links the DLL's import Lib (. lib), the Windows system will only search for dependencies in the following places (http://msdn.microsoft.com/en-us/library/aa297182 (v=vs.60) . aspx):

1. folder where the exe of the current process is located

2. Current path (cwd/getcurrentdirectory)

3.windows system path: GetSystemDirectory ()

4.windows path: GetWindowsDirectory ()

5. Environment variables in path

Obviously the path I need is. \plugins (the corresponding absolute path)

However, the direct execution of the EXE can not set the path, resulting in running the EXE system prompt cannot find the DLL.

One solution is to copy the plugin from under the. \plugins\ below, but it is inconvenient for existing maintenance.

In fact bladegraphics this plug-in, the program at run time is the specified path, manually loaded it, but now compiled shader with its export class, in order to facilitate the need to directly connect its import lib, so execute/load EXE, The system automatically loads the DLL and connects to the IAT immediately

It is because this plug-in will be loaded immediately after startup, so the thought of a lazy load on the DLL, so that the system does not immediately start the program to find the DLL, but the first call to the DLL inside the function when trying to load,

And in the first call to the DLL function, the plug-in has actually been manually loaded by the program, the system detects that nothing will be done in the future.

About import Lib, is automatically done at startup LoadLibrary, and GetProcAddress (), the target DLL all the exported functions are connected to the Lib custom function. Because Lib is not a module, He will eventually be statically linked to the client Exe/dll, and when client Exe/dll calls the function defined in Lib, the function jumps to the address in the target DLL obtained by GetProcAddress ().

Engine design Tracking (nine. 14.2e) delayloaded DLLs (/delayload)