Error LNK2019: unresolved external symbol _wWinMain#16 referenced in function ___tmainCRTStartup - c++

I have started with DirectX 11 and get these compilation errors:
Error 1 error LNK2019: unresolved external symbol wWinMain#16 referenced in function __tmainCRTStartup
Error 2 error LNK1120: 1 unresolved externals(I figure that this error is because of the error just above this one)
I have searched around for fixes to this problem for quite a while, yet I cannot find any fixes to this problem on this site or any other sites via google.
I am using Visual Studio 2012 and c++ for this project. To make my testing project I created an empty project via New Project->Visual C++->Empty Project.
I am using the standard compiler for this project.
This is my wWinMain header in my main.cpp file:
int wWinMain(HINSTANCE hInstance, HINSTANCE prevInstance,
 LPWSTR cmdLine, int cmdShow)
IntelliSense also keeps throwing up "4 IntelliSense: '#' not expected here" errors on some include lines at the start of the file, these lines: (EDIT: the errors keep disappearing and reappearing, repeatedly)
#include <Windows.h>
#include <memory>
#include "BlankDemo.h"
#include <tchar.h>
I put that in my post as I thought that this may be effected by, or have something to do with the error, it could just be the include files. BlankDemo.h is the header file for a test demo that just produces a blank DirectX 11 window.
All the code I have used is from a book on DirectX; as I am not used to DirectX yet, I have tried a number of fixes and none seem to get rid of this error, the fixes being:
Going to Properties->Configuration Properties->General->Character Set and changing that to "Use Unicode Character Set".
After changing the character set the error still remains.
Going to Properties->Linker->System and changing SubSystem to Windows (/SUBSYSTEM:WINDOWS).
I have also tried changing this to Console (/SUBSYSTEM:CONSOLE), neither of these changes seem to fix the problem.
I have also gone to Properties->Linker->Command Line and added /ENTRY:"wWinMainCRTStartup" to "Additional Options", this does not fix the problem either.
I have still left changes to the project as detailed above in the project. I have only put in the few lines of code as the errors seem to be about the code I have put in this post, also when I copy and paste the code, it does not seem to format correctly, but please tell me if you need to see more code.
EDIT: I have changed the function to int WINAPI __stdcall wWinMain(HINSTANCE hInstance, HINSTANCE prevInstance,
 LPWSTR cmdLine, int cmdShow)
Even using __stdcall or WINAPI in the function name does not work it seems. At least, in the way I have used them, please tell me if this is incorrect.

Sorry guys, it seems that I made mistakes here, as in; I did not use Unicode to start off with, under Properties->Configuration Properties->General->Character Set. It seems that by using the Multi-Byte Character set to start off with, this confused Visual Studio 2012 into thinking that I was using the Multi-Byte Character set instead. This caused it to throw up the error, even though the entry point under Properties->Linker->Advanced was set to wWinMainCRTStartup. Makes sense, as the characters were not recognised properly.

Related

What does creating a Solution using a template in Visual Studio actually do versus an empty project?

I am following the Intro to C tutorial by Molly Rocket but am running into an issue running the following code in the Debugger in VisualStudio 2019 while using the Empty Project option.
I am using the Empty Project option instead of loading a template because that is what Molly used, while I could just load a template and run the code there instead I would like to know why I am getting this error so I can better understand Visual Studio and C++.
#include <Windows.h>
void learnC(void) {
OutputDebugStringA("Test\n");
}
int CALLBACK WinMain(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
learnC();
}
Recieving the error LNK2019 which doesn't help at all because it just a generic catch all error code.
error LNK2019: unresolved external symbol main referenced in function "int __cdecl invoke_main(void)" (?invoke_main##YAHXZ)
I have tried updating the compatiliblity settings of VS2019 as well as other settins that people suggested to use but the error still remains.
Again, when I created the Solution I used the blank document instead of a template becuase that is what Molly Rocket used when writing this code.
When I do use a template (I used the Windows Desktop Application template) and delete all the code and paste in what I had in my original document I do not recieve the Error, and I would like to know why.
Thank you for your time!
When you create an Empty Project, the value of SubSystem defaults to Console.
According to the Doc
An application that uses /SUBSYSTEM:CONSOLE; calls main (or wmain)
An application that uses /SUBSYSTEM:WINDOWS; calls WinMain (or
wWinMain), which must be defined to use __stdcall
As far as I'm concerned you should Set up SubSystem to windows(Properties -> Linker -> System -> SubSystem)
For more details about /SUBSYSTEM (Specify Subsystem), I suggest you could refer to the link: https://learn.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=vs-2019

Including files from a seperate project in the same solution in Visual studio - LNK2001?

I had a solution named fun.sln with a project called fun.vcxproj.
I created a whole bunch of name spaces ready to be used.
I made another project called no_more_fun.vcxproj.
I added the includes directory for fun.vcxproj to the configuration of no_more_fun.vcxproj.
I added this to no_more_fun.cpp
#include "candy.h"
void main(void)
{
candy::get();
return;
}
candy.h is in the default directory for fun.vcxproj(which was added to the config)
But I get...
LNK2001 unresolved external symbol "int __cdecl candy::get(unsigned long)" (?get#candy##YAHK#Z) .....
Visual Studio shows no error before compiling.
The "candy" namespace works fine in the "fun" project so idn...
Is there a guide or something so that i can understand how i can go about sharing code efficiently among different projects within ONE solution?
This is a linker error. You didn't get any error at compile time, because the compiler found the candy::get() method in candy.h header, but the implementation (which I suppose is in a candy.cpp file) is not found by the linker.
Just add candy.cpp too to no_more_fun.vcxproj.
ps. I didn't observe but in the error message you can see that the function waits a parameter.
call it like this:
unsigned long foo = 0;
candy::get(foo);
This is going to sounds stupid but...i just dragged the files in to visual studio so that the no_more_fun project had the "files" in its "directory" too.
wow... I shouldn't need to do that...Am I wrong?(sarcasm).

How to incorporate Win32 in an SDL project?

I made some software using SDL and OpenGL, and now I would like to add a graphical interface for input, like some textboxes and buttons. I realize that this probably would have to be in a separate window, which I don't mind, but I have no clue how to incorporate Win32 functionality in my project. I tried changing the definition of my main function from
int main(int argc, char **argv)
{
...
}
to
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE prevInstance, LPSTR lpCmdLine, int cmdShow)
{
...
}
But I get an errors that say:
LNK2005: _WinMain#16 already defined in SDL2main.lib (SDL_windows_main.obj)
LNK2005: _WinMain#16 already defined in Source.obj
LNK2019: unresolved external symbol _SDL_main referenced in function _main
I'm using Visual Studio 2012.
Is there a way to solve this, or is there an alternative way to create forms in c++?
Thanks
SDL defines main as a macro. It's like the ultimate horror show. Mixing Microsoft's WinMain monstrosity into that might seem appropriate, of course, but it isn't needed for anything.
Instead just keep your main.
If I had committed to using SDL (which, considering the above, I would never do), then I would first of all check out what SDL offers in the way of textboxes and buttons and such. If none, then just include <windows.h> properly (defining STRICT and NOMINMAX and UNICODE first), and use the API. But for that I suggest learning that API first by creating some pure API programs, with no interfering SDL.

How do I set WinMain as entry point?

I've deleted the _tmain() method which the IDE generated because I find no sense having two entry points after adding my WinMainentry. And yes, this is my first ever C++ application and I am a newbie, but please be nice.
So that's all I got:
// Included headers:
#include "stdafx.h"
#include <iostream>
#include <Windows.h>
// Shortened namespaces:
using namespace std;
// The main entry of the application:
int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd )
{
MessageBox( NULL, L"Hello World!", L"Just another Hello World program!", MB_ICONEXCLAMATION | MB_OK );
return 0;
}
// End of file.
When I try to build and run I get this error:
error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup
error LNK1120: 1 unresolved externals
I realise the entry point is missing, But where can I set WinMain as the entry point? I just took a look in the properties of the project itself and found nothing.
Note that I've started the project as a console application, But now I am trying to turn it into a regualr windows application.
Thanks.
You need to change the subsystem to Windows.
Project->Properties->Linker->System change Subsystem to /SUBSYSTEM:WINDOWS
If you have further trouble with it then start all over again, selecting Win32 Project instead of Win32 Console.
It sounds you are trying to build a console application with code that you imported from a windows application.
Console applications use a main (or _tmain) entry point, whereas windows applications use a WinMain (or _tWinMain) entry point.
Edit: Indeed changing the linker option as Benjamin told you will solve your immediate problem but you are likely to meet other issues later with such hybrid projects. For example you may include some code relying on the _CONSOLE preprocessor symbol.
You can of course adjust this latter setting yourself too but better restart from a clean win32 template as Scott and Hans suggested.

SFML linker error: unresolved external symbol _WinMain#16, Visual Studio 2012

I was able to get tutorial #1 to compile fine. But I can't get the 2nd one to compile.
When you do new -> Project, maybe one of those settings are interfering? Pretty sure I did empty project, else console.
What's wrong?
compile error:
Error 1 error LNK2019: unresolved external symbol _WinMain#16 referenced in function
___tmainCRTStartup C:\...\02-videomode-iterate\MSVCRTD.lib(crtexew.obj) 02-videomode-iterate
Error 2 error LNK1120: 1 unresolved externals C:\...\Debug\02-videomode-iterate.exe 02-videomode-iterate
entire source:
#include <SFML/Window.hpp>
int main()
{
sf::Window App(sf::VideoMode(800, 600, 32), "SFML-tut: 02");
bool Running = true;
while (Running)
{
App.Display();
}
return EXIT_SUCCESS;
}
Project settings:
include dir, lib: dir set correctly.
c++ -> preprocessor -> preprocessor definitions:
SFML_DYNAMIC
linker -> input
tried: sfml-window.lib and sfml-window-d.lib ( visual studio seems to always use debug mode at start? but tutorial #1 only worked when I didn't use -d version.
subsystem:
/SUBSYSTEM:WINDOWS
When you set the /SUBSYSTEM:WINDOWS flag, the linker will look for a WinMain function rather than the conventional main. You have two options:
Change to /SUBSYSTEM:CONSOLE. You will get an annoying (or perhaps helpful) console window, which you can get rid of with FreeConsole.
Change main to WinMain with the following signature:
int CALLBACK WinMain(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow
);
Unless you need to access argc and argv, this change shouldn't cause too much trouble.
Edit: Perhaps this is worth a look too (copied from the second tutorial):
Under Windows operating systems, you may have created a "Windows
Application" project, especially if don't want the console to show up.
In such case, to avoid replacing main by WinMain, you can link with
SFML_Main static library and keep a standard and portable main entry
point.
So, I suppose that boils down to adding sfml-main.lib (or similar) to the list of libraries to link with.