If we want to use the DLL in both Kernel- and User-Mode we replace the K with a Q:
MyDll.dll $(_FLATRELEASEDIR)\MyDll.dll NK SQ
MakeImg creates a copy of our DLL named K.MyDll.dll. Each version of the DLL will relocated to the corresponding XIP section in User-Space and in Kernel-Space.
Up to this point the facts are easy and every BSP developer should know about it.
Now it starts to be tricky:
What about LoadLibrary()? What happens if I try to call LoadLibrary(L”MyDll.dll”); from a driver in the Kernel context?
The answer is: LoadLibrary() loads K.MyDll.dll, you don’t have to add a “K.”!
But what if the DLL needs another DLL, e.g. My2ndDll.dll?
It is obvious that My2ndDll.dll must be also a Kernel-Mode DLL, but the name mustn’t be K.My2ndDll.dll.
Alternatively you may move My2ndDll.dll from the MODULES section to the FILES section. Remember to remove any K or Q!
MakeImg cannot resolve all dependencies in this situation:
Warning: Unable to do imports from K.MyDll.dll to My2ndDll.dll - will late bind
But if My2ndDll.dll is on your target, K.MyDll.dll will be loaded successfully.
It’s a good idea to review all DLL dependencies and think about the special functionalities of your DLLs. Some DLLs do kernel-specific things and cannot run in User-Mode, e.g. read from KSeg1 addresses. Some DLLs use application interfaces you won’t move to the Kernel, e.g. MFC or OleAut32.