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.
}
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.
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?
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;
}
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 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.