I need my application to be upgraded from visual studio 2005 IDE to visual studio 2012 .
The upgradation wizard converts the solution and project files successfully with 0 errors and few warnings.
But when i start building the application i get error message :
error C1189: #error : This file requires _WIN32_WINNT to be #defined at least to 0x0403. Value 0x0501 or higher is recommended. in atlcore.h !
I tried changing the version no to 0x0500 , 0x0501 , 0x0502 and also 0x0601 ( both through /D compiler option and manually changing in atlcore.h , WINVER is also changed. ) but no luck . the same error is being displayed.
Where do i go wrong ?
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.
To modify the macros, in a header file, add the following lines.
#define WINVER 0x0500
#define _WIN32_WINNT 0x0500
EDIT:
WINVER determines the minimum platform SDK required to build your application, which in turn will determine at compile time which routines are found by the headers.
#define _WIN32_WINNT_NT4 0x0400
#define _WIN32_WINNT_WIN2K 0x0500
#define _WIN32_WINNT_WINXP 0x0501
#define _WIN32_WINNT_WS03 0x0502
#define _WIN32_WINNT_WIN6 0x0600
#define _WIN32_WINNT_VISTA 0x0600
#define _WIN32_WINNT_WS08 0x0600
#define _WIN32_WINNT_LONGHORN 0x0600
#define _WIN32_WINNT_WIN7 0x0601
Other Solution:
If you have installed a WIndows SDK on your PC (in /Microsoft SDKs/Windows), you can #include in stdafx.h (or in a header you include in all your C++ files). Including SDKDDKVer.h will target the highest Windows version available.
Hopefully It work!!!!!
For more info SEE HERE
Problem temporarily solved by commenting a check in atlcore.h :
if _WIN32_WINNT > 0x0501
//#error This file requires _WIN32_WINNT to be #defined at least to 0x0403. Value 0x0501 or higher is recommended.
endif
I know it isnt the right way to do [ editing a file shipped by the IDE ] but did since it may be due to Improper installation.
If anyone come across a permanent fix let me know .
you can add a pre-processor directive for the project under project settings, C/C++, Pre-processor definitions, appending WINVER=0x0501;
(you can also undefine definitions)
I'm wondering if you are using pre-compiled headers which is overwriting changes to stdafx.h, this is the way to make sure this is set
This preprocessor setting holds until code in the project files changes it, at which point if this doesn't fix the problem, then you must find how or where this is being set/unset/checked; but the solutions shouldn't involve any changes to the windows SDK files
Related
I have a.cpp that is used in several projects. Some of them are using precompiled headers, others - not. Depending on this I must add or remove line :
#include <stdafx.h>
Is it possible somehow play with #define to make this in automatic way?
UPD.
I can't use empty stdafx.h file in case when precompiled headers are not used because I got strange behaviour in my situation when a.cpp is placed in project sub directory libA. In this case projects that use precompiled header must have line:
#include <stdafx.h>
and projects that are not using PCH must have line:
#include "..\stdafx.h"
Wice versa is not working. Actually I still can't understand this behavior. I would like to have a.cpp file identical for all projects.
You can include a preprocessor define in the project settings for those projects which use precompiled headers, and then base the inclusion of stdafx.h based on its existence. Using your example, libA's C++ settings should include /D USE_PCH, and then in a.cpp:
#ifdef USE_PCH
#include <stdafx.h>
#else
#include "../stdafx.h"
#endif
To ensure that the define and precompiled header settings remain in sync, you could create a property sheet with both settings, and link it to your project. However, if it were me, I would just disable precompiled headers for the files which are shared between libraries. Unless the PCH is very large, and the number of shared sources also very large, the compilation time savings likely won't outweigh the maintenance of this approach.
I've Win32 DLL application. Debug build is selected. I wrote such code:
#if DEBUG
fflush(logFile);
#endif
But fflush(logFile); is grayed out so I assume it will not be executed.
But i want it to be executed. Does it mean that in Debug DEBUG symbol is not defined? Where can I define it in VS2012?
Preprocessor definitions are defined under project settings as shown on screenshot (note _DEBUG there):
Note that in case of _DEBUG you want to check if it is defined at all, and not compare it (possibly missing definition) to zero. You want:
#if defined(_DEBUG)
or
#ifdef _DEBUG
By default, a Visual Studio C++ project will have the macro _DEBUG defined for a Debug project configuration. It will have the value 1, so you can test for it using #if or #ifdef.
But note that the macro starts with an underscore - if you want to use the name DEBUG (maybe you have existing code that uses that name), you'll need to add it to the project properties yourself (C/C++ | Preprocessor | Preprocessor definitions). Or you can put the following in a header that's included in every translation unit (maybe stdafx.h):
#if _DEBUG
#undef DEBUG
#define DEBUG 1
#endif
Every project has two builds: Debug and Release. Debug build have DEBUG defined, as if you defined using:
#define DEBUG
It enables, the code to get generated differently. The writers of code (functions, classes etc), may add additional diagonistics to aid in debugging. The Debug build is for debugging only, and you don't give this build (i.e. EXE generated with Debug build), to the customers.
Another build where DEBUG symbols is not defined, is for Release build. A release build is for optmized code, at code level, compiler setting level, and linker level. Most of diagonistic, asserts, debugging-aid feature will be disabled - so as to produce optimized executable.
Whomsoever who has written the above code, has written the same thing in mind. To let flush the file, only if debug build is running. You can comment the #if and #endif, and let fflush line compiled, or you can use Release build. It all depends on you.
You know,
there are codes like
#ifdef WPRFLAG
and
#ifdef _WINMAIN_
in ctrexe.c . I'm using vs2010)
These macros determine what function is called from entry point.
But I can't find these macros even in the macro settings of project setting.
Where teh hell are these macros defined?
VS
Project->Configuration properties->Linker->System->SubSystem:
Console (/SUBSYSTEM:CONSOLE)
Windows (/SUBSYSTEM:WINDOWS)
/SUBSYSTEM:WINDOWS this let it run into _WINMAIN_.
WPRFLAG is defined in many wide char version of source files, such as wcrt0.c under source code folder of CRT. _WINMAIN_ is defined in Windows version of CRT source files, such as Wincrt0.c and wWincrt0.c.
I am trying to maintain a program written 5 years ago in VC++ 6.0. It uses our 'common' libraries. The trouble I have is that it either links against the debug version of these libraries or the Release version, depending on whether I have the [Directories] for [library files] set to "common/debug" or "common/release" in [Tools]->[Options].
How do I get it to link to [common\debug\common.lib] when building the debug version and [common\release\common.lib] when building the release version? If I have both paths in the library directories, it seems to link to the first one it finds.
Instead of specifying the paths in the include folders and all the best way i use to include the libraries depending on the configuration is by using #pragma
try this once, it is very useful
#ifdef _DEBUG
#pragma comment(lib, "..\\DllTest\\Debug\\DllTest.lib")
#else
#pragma comment(lib, "..\\DllTest\\Release\\DllTest.lib")
#endif
In [Project Properties]->[Linker]->[Input]->[Additional Dependencies] you can use the $(ConfigurationName) placeholder, like this:
c:\common\$(ConfigurationName)\common.lib
In the Debug configuration this will change to:
c:\common\Debug\common.lib
and in Release it will change to:
c:\common\Release\common.lib
If I have both paths in the library directories, it seems to link to the first one it finds.
Just add the debug folder for the debug settings and the release folder for release settings.
Almost all compiler, linking etc. settings are per configuration (the project properties will show settings as blank in "all configurations" (if I recall the right text) if debug and release are different.
You could specify the full path of the library to link to in the Additional Dependancies field, this can have different values for debug and release builds.
The solution I have found is a little like Richard's & "1800 Information"'s...
I removed the Common library path from Tools->Options. The paths in here are global to all configurations of all projects running in MSVS VC++ 6.0.
I then added a full path to the appropriate library in Project->Settings for each configuration. Hense the debug configuration has D:\VSS\Common\Debug\Common.lib and the release configuration has D:\VSS\Common\Release\Common.lib. This seems to work and for the first time I have no build warnings!
Thanks to all the suggestions for pointing me in what seems to be the right direction.
--- Alistair.
I have used OpenMP with gcc for writing parallel code. I am now using Visual C++ 2005 and am trying to figure out how to use OpenMP. There is a compiler option in the Properties->C/C++/Language menu but then it complains the library is missing. Is there a 3rd party implementation for OpenMP or am i just configuring Visual C++ incorrectly?
After some research I found out that the OpenMP libs and dlls are not included with Visual C++ 2005 or Visual C++ Express Edition 2008. But with a few workarounds you can get it working.
First you need to download the lib files from microsoft which can be found at the Windows SDK for Windows Server 2008 and .NET framework 3.5. After you download it you need to make sure that either vcomp.lib or vcompd.lib is being linked to your program.
Next you need to have the dll which can be found in the Visual C++ Redistributable Packkage. Then make sure that vcomp90.dll is somewhere in your path.
You also need to have the OpenMP compiler option enabled which can be found in the Properties->C/C++/Language menu of Visual C++.
After that you should be able to use OpenMP just fine.
I think t works out of the box with VC 2005 but I am not sure if they are provided with all versions.
If you jsut attach the
/openmp
option you also have to include the open mp header
#include <omp.h>
This is important because this header will add the manifest to your application which
enables it to load the vcomp.dll from the correct system path. So it is normally no longer
allowed to copy vcomp.dll or other system dlls beneath your executable but you have to pimp the manifest of your application to load the dll from the correct location.
This is none automatically by the omp.h header.
So the minimum code if you do not want to modyfy your manifest on your own is:
#include <omp.h> // has to include this header to build the correct manifest to find vcom.dll or vcompd.dll
int main(int argc, char* argv[])
{
double sum;
#pragma omp parallel for
for(int i = 0; i < 10000; ++i) {
}
return 0;
}
You need to add:
/openmp
To your compiler options.
More information is available on MSDN