Why was RunDLL and later RunDLL32 conceived? What is the purpose of their existence? So as to bypass the task manager?
https://support.microsoft.com/en-us/kb/164787
The article states that RunDLL still requires a particular method header for a candidate entry point:
16-bit DLL:
void FAR PASCAL __loadds
EntryPoint(HWND hwnd, HINSTANCE hinst, LPSTR lpszCmdLine, int nCmdShow);
32-bit DLL:
void CALLBACK
EntryPoint(HWND hwnd, HINSTANCE hinst, LPSTR lpszCmdLine, int nCmdShow);
What is the purpose of using a RunDLL entry point rather than a main entry point as in a regular executable file?
Related
I'm trying to display the command line arguments.
This is my current code.
#include "windows.h"
int _stdcall WinMain ( HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpszCmdline,
int nCmdShow )
{
MessageBox ( 0, lpszCmdLine,L"Title",0);
return ( 0 ) ;
}
I'm getting different characters in application.
What changes should I do in order to display the command line arguments in application window?
Since lpszCmdline is LPSTR, (ASCII, not UNICODE), the first option would be using the ASCII version of MessageBox(), but since UNICODE is the standard, I would suggest using the UNICODE version of win32 entry point. See the code below:
#include "windows.h"
int _stdcall wWinMain ( HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPWSTR lpszCmdline,
int nCmdShow )
{
MessageBox ( 0, lpszCmdLine,L"Title",0);
return ( 0 ) ;
}
Further more, to convert the command line to an argv style array of strings, call the CommandLineToArgvW function.
I try to write simple show_window function but that which uses wide chars, there are no examples anywhere in D of that, only I could find windows creation that uses narrow-string and try now to rewrite that (I know bad english). So I'm failing even at proper registering unicode winapi bindings.
import core.runtime;
import core.sys.windows.windows;
import std.c.windows.windows;
pragma(lib, "gdi32.lib");
pragma(lib, "user32.lib");
struct WNDCLASSW { UINT style; WNDPROC lpfnWndProc; int cbClsExtra; int cbWndExtra; HINSTANCE hInstance; HICON hIcon; HCURSOR hCursor; HBRUSH hbrBackground; LPCWSTR lpszMenuName; LPCWSTR lpszClassName; }
extern(Windows) HWND CreateWindowW(LPCWSTR lpClassName, LPCWSTR lpWindowName, DWORD dwStyle, int x, int y, int nWidth, int nHeight, HWND hWndParent, HMENU hMenu, HINSTANCE hInstance, LPVOID lpParam );
extern(Windows)
int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int iCmdShow) {
HWND hWnd = CreateWindowW("wndClassName",
"window caption", WS_SYSMENU | WS_VISIBLE, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, HWND_DESKTOP, null, hInstance, null);
return 0;
}
and that produces:
Error 42: Symbol Undefined _CreateWindowW#44
Modern versions of Windows do not implement CreateWindow(). It is an ancient winapi function that dates from the 1980s and has been replaced by CreateWindowEx(). In the WinUser.h SDK header, CreateWindowW is a macro that actually calls CreateWindowExW(), passing 0 for the extra dwExStyle argument.
You must use CreateWindowExW() instead.
int APIENTRY _tWinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int nCmdShow)
UNREFERENCED_PARAMETER(hPrevInstance);
UNREFERENCED_PARAMETER(lpCmdLine);
what's the purpose of UNREFERENCED_PARAMETER here?
It just suppresses a compiler warning about two parameters being unused in the function.
The macro itself is probably just defined as
#define UNREFERENCED_PARAMETER(x) (x)
so it references its argument but does nothing with it.
I'm trying to learn OpenGL ES with the "OpenGL ES Training Course" (An OpenGL ES tutorial). I use OPENGL-ES 1.1 WINDOWS PC EMULATION with visual studio 2010. I'm trying to compile the 'hello triangle' program and get an error:
'WinMain': function cannot be overloaded
EDIT: I have only one definition of WinMain in the project: The one in the 'hello triangle' source code (which I didn't write).
Could anyone tell me what's going on?
It sounds like you have two definitions of WinMain, or perhaps a prototype and a definition that disagree.
I had the problem too. It showed that I have overloaded the function:
My old text:
#include "windows.h"
int CALLBACK WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, long lpCmdLine, int nCmdShow)
{
}
and my new text:
int CALLBACK WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
With the new text it works
Try
int CALLBACK WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow){
// Your Code.
}
Instead Of
int WinMain(){
// Your Code.
}
I have created a DLL in VC++ as Win32 project
DLLMAIN function is
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
return TRUE;
}
Now I need HINSTANCE of the DLL , that need to be passed to Win32 functions.
Are HMODULE and HINSTANCE same?
How can I get HINSTANCE?
An excerpt from the book Windows Via C/C++ [1]
Note As it turns out, HMODULEs and HINSTANCEs are exactly the same thing. If the documentation for a function indicates that an HMODULE is required, you can pass an HINSTANCE and vice versa. There are two data types because in 16-bit Windows HMODULEs and HINSTANCEs identified different things
[1] Richter, Jeffery and Nasarre, Christophe, Windows Via C/C++, 5th ed, Redmond: Microsoft Press 2008, pp. 74
Microsoft linker specific
#include "windows.h"
EXTERN_C IMAGE_DOS_HEADER __ImageBase;
#pragma warning(disable: 4047)
HINSTANCE hInstance = (HINSTANCE)&__ImageBase;
#pragma warning(default: 4047)
I think that these are the same. If you want HINSTANCE of the running process (exe), you should use
GetModuleHandle(NULL);
Calling GetModuleHandle(NULL) from a dll will return the Hinstanc of the EXE that started the DLL; to get the Hinstance for the curently running dll try this tip:
http://www.dotnet247.com/247reference/msgs/13/65259.aspx
DllMain function as it's described in MSDN:
BOOL WINAPI DllMain(
__in HINSTANCE hinstDLL,
__in DWORD fdwReason,
__in LPVOID lpvReserved
);
http://msdn.microsoft.com/en-us/library/ms682583%28v=vs.85%29.aspx
Each DLL has at least a header file, say MyDll.h and a corresponding implementation file MyDll.cpp. Open the header file and add
extern HMODULE hDllModule;//or whatever name you like
Now open the MyDll.cpp file. There is a function DLLMAIN. Add before it HMODULE hDllModule; and insert hDllModuleDll = hModule; before return true;. Your code will look like this:
HMODULE hDllModuleDll;
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
hDllModuleDll = hModule;
return TRUE;
}
In functions like ::GetModuleFileNameW(hModule, PathFile, MAX_PATH); that require a HMODULE of the DLL you can pass the global variable hDllModule.
To complement the other answers, for the sake of completness.
The actual signature of DllMain has an HINSTANCE parameter, instead of a HMODULE parameter. The Visual Studio DLL template generates the signature with HMODULE since at least Visual Studio 2008 however, but I believe this to be a minor bug more than anything. VC6 generated the code with HANDLE (even though both HINSTANCE and HMODULE exist). The reason that doesn't cause problems is because HINSTANCE and HMODULE are now exactly the same thing. Unfortunately I was unable to find an ancient enough version of the MSDN documetnation that could have confirmed this.
So the answer is: You get your HINSTANCE as an argument to your DllMain.
Personally I sort of like the distinction between HMODULE and HINSTANCE because it appeals to me as being good code hygiene. It's a bit like using const. But then, a new question arises: Given your HINSTANCE, how do you get your HMODULE in the "hygienic" way?
The windowsx.h header defines GetInstanceModule, which is now a macro that just casts the HINSTANCE to HMODULE. It only exists for code compatibility, along with a bunch of very similar macros.