Compile Errors upgrading ATL project from vs2010 to vs2013 [duplicate]

Question

When including atlwin.h from the Microsoft ATL libraries in Visual Studio 2013 building may result in numerous complier errors about undefined elements.

HMONITOR is not defined

This does not occur when building using VS2010.

As this is a standard MS header file the missing class errors do not seems to make sense.

Gaylenegayler

Just a note: this seems like a reasonable question, and it's one that can be answered. But posting a duplicate is not the way to go about it. If you can clean up the original question via editing, that would be great. That would "bump" it back up so it can get the rest of the re-open votes it needs. – Propst

I tried that and got jumped on and lost rep, so how do I work with the system here? – Gaylenegayler

Err, what? How did you get jumped on and lose rep? That doesn't make any sense. Even if a suggested edit gets rejected, you won't lose any rep. Although looking at it more carefully, you did successfully edit that question. Then another user who reviewed your edit actually improved it, adding code formatting. See the revisions list here. So it looks like you've done what you are supposed to do, it may just take some time for it to get re-opened. It has 2 re-open votes now. – Propst

Thanks for taking the time to respond. I'll wait for it to reopen. – Gaylenegayler

Please either reopen the other question or this one. Don't really care. Just know I spent a day and a half killing myself to fix this issue on my own and would like to help someone else avoid the same pain. – Gaylenegayler

Waiting for the community to respond can take some time. There are only so many users with re-open vote privileges, and they have to see the question, open it, read it, evaluate it, and vote. If you want to speed up the process, you can try flagging for moderator attention. No guarantees they'll agree with you. – Propst

They don't want to reopen the other one because they are concerned that my edits do not reflect the original question. So in that case this is not a dupe, and should be open or it is a dupe and the other one should be open. – Gaylenegayler

I don't think anyone is afraid of that... – Propst

That was interjay's comment on the answer to the other question. – Gaylenegayler

Answer 1

As this is a very old legacy project the problem is with the targeted version of windows in the stdafx.h file

from MSDN

Visual C++ no longer supports targeting Windows 95, Windows 98, Windows ME, or Windows NT. If your WINVER or _WIN32_WINNT macros are assigned to one of these versions of Windows, you must modify the macros. When you upgrade a project that was created by using an earlier version of Visual C++, you may see compilation errors related to the WINVER or _WIN32_WINNT macros if they are assigned to a version of Windows that is no longer supported.

So, changing

#ifndef WINVER  
#define WINVER 0x0400   
#endif

to

#ifndef WINVER  
#define WINVER 0x0500
#define _WIN32_WINNT 0x0500
#endif

corrects the build problem

Gaylenegayler

I ran across this as I had the issue moving from 2010 to 2015. Note that _WIN32_WINNT 0x0500 won't work in 2015 but #define _WIN32_WINNT _WIN32_WINNT_WINXP will. Thanks for your post. – Poleaxe