WinMain exported from a DLL - winapi

I am trying to hide the WinMain function inside a DLL in order to avoid typing again much of the code over and over again.
I exported wWinMain from the DLL by declaring it as
extern "C" int WINAPI wWinMain( ... )
{
// repetitive code here
}
and used the linker option /EXPORT:wWinMain, but when I try to use the import library in another project I get the error
LIBCMTD.lib(wincrt0.obj) : error LNK2019: unresolved external symbol _WinMain#16 referenced in function __tmainCRTStartup
Remark I do want to use the GUI interface and I know this is common error when you define a main instead of a WinMain function. Also, I enabled the UNICODE support in both projects. What should I do?

This is not possible as-is, the linker can only set the entrypoint for an EXE to a function that's inside the EXE. Rename the wWinMain() in the DLL to something else. Write a wWinMain() in a source code file that gets linked into your EXE, simply call the DLL's exported function.

// ...somewhere in a .cpp file within my .dll's sources...
#define WinMain WinMainOld // ...to suppress Win32 declaration of WinMain
#include <windows.h>
#undef WinMain // ...so that WinMain below is not replaced
. . .
#pragma comment(linker, "/export:_WinMain#16") // ...to export it from .dll
extern "C" // ...to suppress C++ name decoration
int CALLBACK WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR pCmdLine, int nCmdShow)
{
. . .
}

Should you be using WinMain in a DLL? Should it not be DllMain?

If you want to call the WinMain of the dll, you need to replace the CRTWinMainStartup function(_tmainCRTStartup in your liked CRT lib), and make it call your exported WinMain, this stops the linker looking for a local WinMain and still keeps correct flow of the program(the source for the CRT startups should be in the crt source of any compiler)

I find one way to put WinMain inside DLL.
You need to use WinMain instead of wWinMain (I don't know why)
Append a def file into your project and,
append EXPORTS WinMain in def file.
Like this
EXPORTS
WinMain
From the observation, all need exported functions generated, not only WinMain.
After test, the way of __declspec(dllexport) is invalid for WinMain.
Link your program to the DLL library
use #pragma comment(lib, "testDll.lib")
or modify setting in the project.

EXPORT int WINAPI _WinMain_(int (*_main_)(int argc, char **argv), HINSTANCE hInst, HINSTANCE hPrevInstance, LPSTR commandLine, int nCmdShow);
int _XMain( int argc, char **argv );
#define XMain WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrevInstance, LPSTR commandLine, int nCmdShow)\
{return _WinMain_( _XMain, hInst, hPrevInstance, commandLine, nCmdShow );} \
int _XMain
Then _WinMain_() calls or schedules _XMain().
Over in your application source:
int XMain( int argc, char **argv )
{
}

Related

MingW Header Files Have No Labels

I've installed vscode extension (ms-vscode.cpptools) from Microsoft to enable intellisense. But, when i typed MessageBox, the parameters have no labels.
It should be
MessageBoxW(HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uType)
My Question: Why MingW distribute the header files without labels?
It should be
MessageBoxW(HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uType)
That is not so.
The tooltip is showing you the declaration of the function, as declared
in MingGW's header winuser.h. That declaration specifies the function's
prototype, consisting of:
The return type of the function, then
The name of the function, then
The types of the parameters in the parameter-list, within brackets, in the right order.
as the tooltip does:
int MessageBoxW (HWND, LPCSTR, LPCSTR, UINT)
What you call "labels" are parameter-names. They are optional, and redundant,
in a function declaration, since the compiler does not need them to understand
how the declared function will be called, and what it returns. MessageBoxW
is to be called with arguments that are a HWND, a LPCSTR, another LPCSTR,
and a UINT, in that order; and it returns and int.
The compiler requires parameters to be named in a function definition:
add.c
// definition
int add(int x, int y)
{
return x + y;
}
main.c
#include <stdio.h>
extern int add(int,int); // Declaration
int main()
{
printf("%d\n",add(3,4));
return 0;
}
Compile with maximum strictness, link and run:
$ gcc -Wall -Wextra -pedantic -o prog main.c add.c
$ ./prog
7
See also Function Declaration in C
Parameter-names are useful to human readers in a function-declaration when the declaration
is accompanied by documentation of the function, since the documentation
can then refer to the parameter-names to explain the function's behaviour:
/*
Return the sum of `x` and `y`
*/
int add(int x, int y);
But they are unnecessary to the compiler.
Like the MinGW windows headers, Micorosoft's own headers do not contain comments
to document the APIs, but they do contain parameter-names, and also SAL Annotations
of the parameter names. E.g. in Microsoft's WinUser.h (SDK 2017) the declaration of MessageBoxW is:
int
WINAPI
MessageBoxW(
_In_opt_ HWND hWnd,
_In_opt_ LPCWSTR lpText,
_In_opt_ LPCWSTR lpCaption,
_In_ UINT uType);
The SAL annotations, (_In_opt_, _In_ and similar) are a non-standard Microsoft
language extension that supports static analysis of the correctness of code
implementing or invoking the APIs and they are used for that purpose by Microsoft's
compilers.
Such SAL-based static analysis needs names for the annotated parameters in order to provide
meaningful diagnostics; hence the parameters have names in the annotated declarations
in Microsoft's headers.
GCC, including MinGW ports, does not support SAL; so parameter names remain
redundant in function declarations.

Why winmain parameters doesn't match to each other?

Why QApp constructor fails with WinMain parameters?
int CALLBACK WinMain(HINSTANCE, HINSTANCE, LPTSTR _lpCmdLine, int _nShowCmd) {
QApplication app(_nShowCmd, & _lpCmdLine);
And here it fail with exception:
Exception at adress 0x0F3621DC (Qt5Guid.dll) in updater_app.exe: 0xC0000005
Whats wrong? how to fix it?
UPD:
And it works in such way:
int CALLBACK WinMain(HINSTANCE, HINSTANCE, LPTSTR _lpCmdLine, int _nShowCmd) {
int nShowCmd(0);
QApplication app(nShowCmd, & _lpCmdLine);
_lpCmdLine is 10 and _nShowCmd is empty string - so it doesn't match. Why?
The Qt application QApplication main object supposed to be created in the standard main function:
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
// more app objects initialization
return app.exec();
}
and you do:
int CALLBACK WinMain(HINSTANCE, HINSTANCE, LPTSTR _lpCmdLine, int _nShowCmd)
{
QApplication app(nShowCmd, & _lpCmdLine);
return app.exec();
}
Which implies that &_lpCdLine being equivalent to argv but:
LPTSTR _lpCmdLine which is an equivalent to char* and you take an address of it so &_lpCmdLine matches char** when _lpCmdLine is pointing to a contiguous buffer of characters and not an array of character strings as argv.
It makes sense to consider how main() function is implemented on Windows. There is a good discussion: WINMAIN and main() in C++ (Extended) Mind that the C runtime must be initialized before main() function runs and that may depend on compiler/linker. And also find an example of Qt application main function.
I guess that the case when you make your code not to crash by introducingn nShowCmd == 0 makes QApplication object not to read the command line which prevents an incorrect access via random content interpreted as addresses in _lpCmdLine. But that is still wrong and an incomplete intitialization of QApplication object.
The authors fails to see the window and sees the console instead and that relates to incomplete code of main function not launching any window. Also, QML application main.cpp might help.
Since this problem becomes relevant again with Qt6, here is a very simple solution for VisualStudio with using WinMain as entry point:
QApplication app(__argc, __argv);
__argc and __argv are populated by the microsoft compiler
(found this suggestion here: https://codingmisadventures.wordpress.com/2009/03/10/retrieving-command-line-parameters-from-winmain-in-win32/)
Short explanation of the problem: using main() with VC requires to use Subsystem:Console, but this always opens a console window, which you wanna avoid usually. You cannot get rid of this console, except with some very dirty hacks. So you need to switch to Subsystem:Windows to have a "silent" application launch, but this requires to use WinMain() as application entry point. Up to Qt5 there was an own implementation of WinMain() in qtmain.lib, which you simply linked in, and which forwards to the main()-function, but this has been kicked out in Qt6. The problem exists afaik only for MSVC users, because with mingw you can disable the console window and continue using main(), as shown in the Qt-examples.

How to hide the console window in a Win32 project using Visual Studio 2010

I need to create an exe application with no console window or (any other window) during the start up of the application.
I tried the below for this:
Using Visual Studio 2010, created a Win32 Console Application as an Empty Project.
Added a header file "stdafx.h" to the project
Added a cpp file to the project and added the below code.
The project settings are visual stduio default.
#include "stdafx.h"
#include <windows.h>
#include "TlHelp32.h"
#include <iostream>
#include <string>
int APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
{
return 0;
}
The above code compiles good.
But if I change the Character Set to "Use Unicode Character Set", I am getting the following compilation error.
error C2731: 'WinMain' : function cannot be overloaded
I am building the application on a Windows 7 64 bit computer and Visual Studio Build platform as x64.
Thanks in advance for your help.
Yes, when you build with UNICODE in effect then the entrypoint takes a Unicode string for the command line argument. So that requires a different declaration:
int APIENTRY wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPWSTR lpCmdLine, int nShowCmd)
Or you can use #include <tchar.h> so it works either way, not much point to it these days:
int APIENTRY _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPTSTR lpCmdLine, int nCmdShow)
Create Windows service instead console app.
In Visual Studio, create a new "EMPTY Project". Add a new source file named "main.cpp". Use the following template (assumes you want to build with Unicode):
/************
main.cpp
************/
#define UNICODE 1
#include <windows.h>
int APIENTRY wWinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPWSTR lpCmdLine, int nShowCmd)
{
// Process Return Codes
const int SUCCESS=0, FAILURE=1;
return SUCCESS;
}

Documentation for writting your own dll for Rundll32.exe? [duplicate]

This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
How to use Rundll32 to execute DLL Function?
Where can I find documentation (tutorials, books, etc.) to write my own dll's that can be run with rundll32.exe?
Here is the most basic Hello World sample I could come up with that will work with rundll.exe. Please follow along these steps:
Start a fresh WIN32 DLL project in Visual Studio (I used VS2010)
In dlllmain.cpp add:
// this shoud ideally go into the .h file I believe
__declspec( dllexport ) void CALLBACK EntryPoint(
HWND hwnd,
HINSTANCE hinst,
LPSTR lpszCmdLine,
int nCmdShow);
// our hello world function
void CALLBACK EntryPoint(HWND hwnd, HINSTANCE hinst, LPSTR lpszCmdLine, int nCmdShow)
{
int msgboxID = MessageBox(
NULL,
L"Hello World from Run32dll",
L"Hello World",
MB_ICONWARNING | MB_CANCELTRYCONTINUE | MB_DEFBUTTON2
);
switch (msgboxID)
{
case IDCANCEL:
// TODO: add code
break;
case IDTRYAGAIN:
// TODO: add code
break;
case IDCONTINUE:
// TODO: add code
break;
}
}
Add a module.def file to your project and edit the following snippet in it:
LIBRARY YourDll
EXPORTS
EntryPoint
Compile and then test from the commandline with
rundll32 YourDll.dll,EntryPoint
You should be greeted with a MessageBox with three buttons
I used the following url's to overcome C++ issues and EntryPoint not found in the early stages of my effort:
Rundll from user mricicle
How messagebox works
DependencyWalker
Exporting functions
Exporting with .def file
String literals

How can I get HINSTANCE from a DLL?

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.

Resources