1 / 24

Win32 Programming

Win32 Programming. Lesson 20: Advanced DLL Techniques. Where are we?. We’ve looked at DLLs from a build/link/execute perspective But there are many different tricks you can use to get more “bang for your buck”. Explicit DLL Loading. To use a DLL, a process must load it

teleri
Download Presentation

Win32 Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Win32 Programming Lesson 20: Advanced DLL Techniques

  2. Where are we? • We’ve looked at DLLs from a build/link/execute perspective • But there are many different tricks you can use to get more “bang for your buck”

  3. Explicit DLL Loading • To use a DLL, a process must load it • We’ve looked at doing this implicitly via load and runtime and building in the calls • Can be done when the application is running too • The beauty of this technique is that you don’t need to know too much about the DLL at compile time

  4. Explicit Loading • Simple to accomplish via LoadLibrary: • HINSTANCE LoadLibrary(PCTSTR pszDLLPathName); • HINSTANCE LoadLibraryEx(    PCTSTR pszDLLPathName,    HANDLE hFile,    DWORD dwFlags); • HINSTANCE is a pointer to the virtual memory where the DLL is mapped

  5. Parameters • hFile: Reserved for future use – must be NULL • dwFlags: combination of DONT_RESOLVE_DLL_REFERENCES, LOAD_LIBRARY_AS_DATAFILE, and LOAD_WITH_ALTERED_SEARCH_ PATH

  6. Implications • DONT_RESOLVE_DLL_REFERENCES • Don’t execute DllMain or automatically load other DLLs needed by this one • LOAD_LIBRARY_AS_DATAFILE • Useful if you want to load an .exe file without executing it • LOAD_WITH_ALTERED_SEARCH_ PATH • Changes the order in which directories are searched in order to load the DLL

  7. Explicitly unloading the DLL • BOOL FreeLibrary(HINSTANCE hInstanceDLL); • And also: • VOID FreeLibraryAndExitThread(    HINSTANCE hinstDll,    DWORD dwExitCode); • Why? • And of course, this is all predicated on usage counts…

  8. Other Explicit calls • Can check to see if a DLL is already loaded via: • HINSTANCE GetModuleHandle(PCTSTR pszModuleName); • Would use like this: • HINSTANCE hinstDll = GetModuleHandle("MyLib"); // DLL extension assumed if (hinstDll == NULL) {    hinstDll = LoadLibrary("MyLib");  // DLL extension assumed }

  9. You can also… • Get the full path of a loaded DLL • DWORD GetModuleFileName(    HINSTANCE hinstModule,    PTSTR pszPathName,    DWORD cchPath);

  10. Second • Once a DLL has been explicitly loaded you need to get the address of the functions you want • FARPROC GetProcAddress(    HINSTANCE hinstDll,    PCSTR pszSymbolName); • Where pszSymbolName is either: • The name e.g. “MyFunc” • The resource number MAKEINTRESOURCE(2)

  11. Warning! • If you use the name, it can be slow, as you must search through the names of all exported things • If you use the second function, GetProcAddress can return a non NULL value even though it has failed…

  12. DLLs (startup) • A DLL can have a DllMain function which is called upon startup • This routine isn’t required – you implement it if you need it • Note the name is case sensitive. If you use DLLMain you’re not going to get called

  13. Code Example BOOL WINAPI DllMain(HINSTANCE hinstDll,  DWORD fdwReason,  PVOID fImpLoad) {    switch (fdwReason) {       case DLL_PROCESS_ATTACH:          // The DLL is being mapped into the process's address space.          break;       case DLL_THREAD_ATTACH:          // A thread is being created.          break;       case DLL_THREAD_DETACH:          // A thread is exiting cleanly.          break;       case DLL_PROCESS_DETACH:          // The DLL is being unmapped from the process's address space.          break;    }    return(TRUE);  // Used only for DLL_PROCESS_ATTACH }

  14. hInst • hInstance passed in is where the DLL got loaded – usually stored for later use in a Global • Remember though that when your DllMain is running, other DLLs may not have initialized. Thus, don’t call other DLLs within your DllMain

  15. Delay-loading a DLL • You can opt to delay load an implicitly-linked DLL • Beneficial because: • Faster startup – you can save time initializing DLLs later when you need them • Backward compatibility – you can avoid calling missing functions and handle the error yourself

  16. Function Forwarding • You can forward an exported function from one DLL to another • // Function forwarders to functions in DllWork #pragma comment(linker, "/export:SomeFunc=DllWork.SomeOtherFunc")  • Pretty simple eh?

  17. Known DLLs • Life isn’t fair… some DLLs get special treatment • Look at: • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs • These DLLs always load from the same place

  18. Version Independence • We are all familiar with DLL Versioning problems • Can fix using .local files. If a file called calc.exe.local exists, for example, in the directory in which calc.exe resides, DLLs are loaded from that directory first • For new systems think about Side-by-Side assemblies (see here)

  19. Rebasing DLLs • When a module loads, it has a preferred base address it would like to load at • However, that address is not always going to be available • If a module is relocated, internal structures have to be “fixed up” to deal with this new location (why?) • This is slow

  20. Instead • You can use the rebasing tool to modify the DLLs so that this relocation is done on disk, and not on the fly • Don’t ever ever *ever* rebase system DLLs

  21. Binding a DLL • Similar in some senses to Rebasing • Improves performance • Saves the system having to fix up the module import section

  22. What can we do with it? • This 

  23. Assignment • Not due until April 26th– that’s over two weeks • NO MERCY on people who say on the 19th “I’m stuck!” • This is somewhat tricky • I suggest you start work on it immediately… • We will look at your code in a week in SVN and assign some points for what you’ve done

  24. Calls… • I want you to be able to intercept the following Winsock system calls: • connect • send • recv • closesocket • You should be able to launch an arbitrary monitored process (specified on the Command line) • You should be able to display the calls to connect, send, recv and closesocket along with their parameters • Have fun  • I strongly suggest you read Ch 22.

More Related