As there are a lot of forbidden Win32 APIs in Windows Store apps (i.e. APIs that, if you call them, will cause your app to fail app certification), there are often other alternative APIs that you have to call instead. For example, the CreateFile API is banned, but for Windows Store apps they made CreateFile2.
But what about if I wanted to get the module handle of a DLL? Specifically of kernel32? Well, looking at the help for GetModuleHandle we see the unfortunate info:
| Minimum supported client |
Windows XP [desktop apps only] |
So we can only use this with desktop apps. For your own packaged libraries you can use LoadPackagedLibrary API. But this doesn’t work for system DLLs. So how can you the the handle to kernel32.dll, for example, by using only approved store APIs?
This is where VirtualQuery comes in. Interestingly, the API’s help page lists the following info:
| Minimum supported client |
Windows XP [desktop apps | Windows Store apps] |
This is great news, because VirtualQuery can get you the module handle of any DLL just by querying any particular known function in the DLL you want the handle to.
I discovered this trick a while ago – previously I used it to find the module handle of the DLL any code is being called from. See:
http://www.codeguru.com/cpp/w-p/dll/tips/article.php/c3635/Tip-Detecting-a-HMODULEHINSTANCE-Handle-Within-the-Module-Youre-Running-In.htm
You probably know where I’m going here, but VirtualQuery itself is a function exported from kernel32.dll!
So all we need to do to get the module handle of kernel32.dll is to do a VirtualQuery of VirtualQuery:
HMODULE GetKernelModule()
{
MEMORY_BASIC_INFORMATION mbi = {0};
VirtualQuery( VirtualQuery, &mbi, sizeof(mbi) );
return reinterpret_cast<HMODULE>(mbi.AllocationBase);
}
And then from your own code:
HMODULE kernelHandle = GetKernelModule();
You can now pass this into functions such as GetProcAddress (which is also approved). As you can see, we have a powerful way to get the module handles of any particular DLL that we have in our process address space, and then use that to get function pointers to any particular function.
Note you should only use this technique on approved APIs in Windows Store apps. But for debugging purposes (and just to have some fun), it might be cool to do something like the following:
Generate a blank XAML (C++ Windows Store) app, add a button to the blank form. Double click on the button. Add this code in place of the event handler:
typedef int (WINAPI *pMessageBox)( __in_opt HWND hWnd,
__in_opt LPCTSTR lpText, __in_opt LPCTSTR lpCaption, __in UINT uType);
typedef HWND (WINAPI *pGetActiveWindow)(void);
typedef HMODULE (WINAPI *pGetModuleHandle)(__in_opt LPCTSTR lpModuleName);
void App1::MainPage::Button_Click_1(Platform::Object^ sender,
Windows::UI::Xaml::RoutedEventArgs^ e)
{
static pMessageBox MessageBox_p = 0;
static pGetActiveWindow GetActiveWindow_p = 0;
static pGetModuleHandle GetModuleHandle_p = 0;
HMODULE kmod = GetKernelModule();
GetModuleHandle_p = (pGetModuleHandle)GetProcAddress(kmod, "GetModuleHandleW");
HMODULE mod = GetModuleHandle_p(L"user32.dll");
MessageBox_p = (pMessageBox)GetProcAddress(mod, "MessageBoxW");
GetActiveWindow_p = (pGetActiveWindow)GetProcAddress(mod, "GetActiveWindow");
MessageBox_p(GetActiveWindow_p(), L"Hello", L"Hello", MB_OK);
}
Build and deploy your app, run it, and the press the button and see what happens. Something you don’t ever want to do in a production app :)
Ted's Blog 