MSDN Sample Program not Working

[firecannons]

I am going through the MSDN's learn to program Windows tutorial. I have made it to the first sample program, but I can't compile it. I don't want to move on until I can compile it.

The sample program is at https://msdn.microsoft.com/en-us/library/windows/desktop/ff381409(v=vs.85).aspx

In compiler errors, I get
C:\Program Files (x86)\Dev-Cpp\MinGW64\x86_64-w64-mingw32\lib\libmingw32.a(lib64_libmingw32_a-crt0_c.o) In function `main':
18 C:\crossdev\src\mingw-w64-v3-git\mingw-w64-crt\crt\crt0_c.c undefined reference to `WinMain'
C:\Users\mocho man\Desktop\C++\New\collect2.exe [Error] ld returned 1 exit status
25 C:\Users\mocho man\Desktop\C++\New\Makefile.win recipe for target '"Windows' failed


I am using Orwell Dev-C++ and I started out the project using the "Windows Application" template, although I don't think that should matter.

thanks

[codewalker]

I dont have experience using Dev-C++, but I think your best option for learning/building Windows application is Visual Studio Express (which is free).

From the errors: 1) WinMain is missing, which is absolutely essential for any Windows program, 2) it is using MinGW for building the code. MinGW is not best for building Windows applications

[knn9]

Change wWinMain to WinMain:

int WINAPI WinMain(HINSTANCE, HINSTANCE, PSTR, int)

I think wWinMain is a Visual Studio thing.

[modoran]

Yes, wWinMain and wmain is not supported by MinGW toolchain. However there are workarounds for that.

[firecannons]

Thank you for the replies.

@codewalker

I dont have experience using Dev-C++, but I think your best option for learning/building Windows application is Visual Studio Express (which is free).

Sounds like I should switch to Visual Studio Express.

@knn9 and modoran
I changed
int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE, PWSTR pCmdLine, int nCmdShow)
from the sample program to
int WINAPI WinMain(HINSTANCE, HINSTANCE, PSTR, int)
and got these errors

C:\Users\mocho man\Desktop\C++\New\Untitled4.cpp	In function 'int WinMain(HINSTANCE, HINSTANCE, PSTR, int)':
17	24	C:\Users\mocho man\Desktop\C++\New\Untitled4.cpp	[Error] 'hInstance' was not declared in this scope
44	22	C:\Users\mocho man\Desktop\C++\New\Untitled4.cpp	[Error] 'nCmdShow' was not declared in this scope

but then I added parameters
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE, PSTR, int nCmdShow)
and it worked!

Edit: I also tried getting rid of the w at the beginning of WinMain. I received some compilation errors, but I was able to get rid of them by changingPWSTR pCmdLine to PSTR pCmdLine and making it ANSI. Is there any way to compile Unicode Windows programs with Dev-C++ and MinGW?

One more question:
Is there any way to keep the terminal window from opening behind the created window? Would switching to Visual Studio get rid of it?

thanks

[S G H]

Check your project settings, make sure it's a gui project.
Make sure you have #include <windows.h> on the top.
Make sure your entry point looks like this:
int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)

About unicode: Your entry point cannot be changed. You can use something like GetCommandLineW (can't remember right now, there is a function for this tho).
Also you can use e.g. MessageBoxW instead of MessageBox and WCHAR instead of TCHAR.

[firecannons]

I finally got it to run without the console windows showing.

SGH said:

Check your project settings, make sure it's a gui project.
Make sure you have #include <windows.h> on the top.
Make sure your entry point looks like this:
[quote]int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)

[/quote]
For a while I did all of these and the console window kept showing. Eventually I compiled and ran the program and it didn't show.

I think I might have had my C++ program not contained to any project, though a project looked like was the project with my program in it on the panel on the left. And I probably forgot to save my project a few times before I realized that I had to save a project so it would keep track of the files inside, contributing to the problem. In any case, this problem is now solved. : )


SGH said:

About unicode: Your entry point cannot be changed. You can use something like GetCommandLineW (can't remember right now, there is a function for this tho).
Also you can use e.g. MessageBoxW instead of MessageBox and WCHAR instead of TCHAR.

That's good news! It looks like I can deal with unicode strings easily.

Thank you all for your help. I can now mark this topic as solved.

[S G H]

Tip for quotes:
[ quote=SGH]ABC[/quote]
becomes

SGH wrote:

ABC

Also, yes, you should have projects instead of .cpp files only, since the project file will store your project settings (eg gui/console/library is a project setting).
Plus, if you change your settings and you only do a simple compilation, it is possible your program is not getting recompiled by scratch. To fix this, you can perform a full project Cleanup (search for Clean Project or similar). This is not always necessary, since it is prone to increase the build time.

[freddie1]

Glad things are working for you firecannon. I read this thread to late to help, but was somewhat amused by the fact that you encountered all or most of the issues beginning WinApi coders encounter when starting out. I'm sure it wasn't amusing to you, and I'm glad you solved them.

To clear up some inaccuracies and misconceptions though, I might point out that Visual Studio Express or whatever is far from being a requirement for WinApi coding. I have Visiual Studio Pro but seldom use it. When I do use it I'm more apt to just use the compiler itself rather than the IDE. Mingw works fine for Windows programming. If you preface code something like this at the top of your *.cpp files you'll find that the code/project can be compiled by both MS VC or mingw without warnings or errors...

#ifndef UNICODE
#define UNICODE
#endif
#ifndef _UNICODE
#define _UNICODE
#endif 

The reason for that is the VS IDE predefines or defaults to wide character builds and the various IDEs that use mingw don't.

As SGH said, once you move away from beginning console style coding, projects become a necessity, unless one does command line compiling or uses nmake, which take the place of projects. The reason for this is that in C or C++ one must take cognizance of the libraries which contain the functions one is calling. Console coding can get away with kernel32.lib and msvcrt, but GUI projects must inevitably link with such libs as gdi32.lib, user32.lib, etc. When you set up a GUI project in any environment the environment will see to it that it generates these entries in the command line it feeds into the compiler/linker.

[firecannons]

SGH wrote:

Also, yes, you should have projects instead of .cpp files only, since the project file will store your project settings (eg gui/console/library is a project setting).
Plus, if you change your settings and you only do a simple compilation, it is possible your program is not getting recompiled by scratch. To fix this, you can perform a full project Cleanup (search for Clean Project or similar). This is not always necessary, since it is prone to increase the build time.

Good to know. Thank you for your advise.

@freddie1
Thank you for your advise. Those lines of code will come in very handy.


However, I am still having compiling issues with sample programs. A Dev-C++ Direct3D sample program has errors (undefined reference to Direct3-D functions). When I added freddie1's code, it got rid of the errors, and it made some new ones (a couple string conversion errors), but the new ones can probably be solved. I'm not sure how defining unicode got rid of undefined function errors, but it did.
I've also found that a sample GDI+ programs on MSDN didn't compile (undefined reference to GDI+ functions), and adding the lines of code made no difference.
Also, surprisingly, GDI programs do compile.

I'm not sure why these programs didn't compile, since they have been checked and compiled before, and how there can be undefined functions while include all the right header files. I'm also sure that the *.cpp files were attached to projects.
Maybe someone might know why these issues are coming up?

thank you

[freddie1]

Realize that there are two completely different steps to the process of creating an executable binary. These two steps are compilation and linkage. Including header files won't solve linkage problems. You know you have a linkage problem whenever you get an error message saying something to the effect 'unresolved externals' or 'unresolved references'.

When a program successfully compiles, but doesn't link, what that means is that the compiler was able to understand all the lines of code. In other words, it was able to understand every function call. When it encountered a function call, it found a definition of that function call involving all the parameters and return values.

Let me just give an example. Let's say you set up a 'console project' (by now you understand the value and need for 'projects'), which will allow you to use the various Standard Libraries in C++. Let's further say that you #include <windows.h>. That include has declarations of most of the functions available in Windows, including BeginPaint(), which is a GDI function heavily implicated in rendering graphics in Windows GUI programs. Now if you call BeginPaint() in your console project you may be able to get the code to compile, but it won't link. It will compile because the compiler found a declaration of BeginPaint() in Windows.h or something included by Windows.h, and so it recognizes the function call. The compiler by itself knows everything it needs to know about BeginPaint() to successfully create an *.obj file. But it won't link.

At the linkage stage the build system will search through the various libraries included in the compilation string to actually search for the object code of any missing function calls not found in your source code, i.e., ones that you yourself wrote. If it can't locate the function body you'll get an unresolved external error. It sounds to me like this is a large part of your problem.

It might help to do some command line compiling of simple programs to help set this stuff straight in your head. By actually feeding the compiler all the data it needs to know on the command line it helps to bring home the necessity for all the stuff.

Also, every function call listed on MSDN (BeginPaint() included) - towards the end of the documentation after descriptions of what the function does and how to use the parameters, will also have a section telling what lib the function is in. When I looked up BeginPaint() its lists user32.lib. That surprised me a bit - I thought it was in gdi32.lib. Learn something new everyday!

[firecannons]

Sorry for the slow reply. Despite only being about half-way through the tutorial on this website and starting module 2 in the windows tutorial, I had to leave the tutorials and make a little gdi video game. :P

It actually taught me a lot. One thing that I found was that 1 of 4 times I tried to compile the program, with no syntax errors, it gave me a "access denied" error and wouldn't compile. This even happened when the target excutable was not already running. I tried using clean (thanks SGH) or recompiling, and it would probably work.

I just tried compiling some program by command line (dragging and dropping in windows explorer, if it matters). g++ wouldn't make a executable for my video game, but that's probably because I didn't use the right settings, because then I got a console program to compile with command line.

I examined compiler and linker settings in Dev-C++ more closely, but didn't see anything that stood out as causing "undefined reference" problems.

Maybe the MSDN GDI+ sample left out a header file that I need to compile with MinGW. When I ctrl+click on the GdipStartup function in the sample, it doesn't take me to that function in the header file like it usually does.

Thank you