_WIN32_WINNT not defined. Defaulting to _WIN32_WINNT_MAXVER (see WinSDKVer.h)
This error keeps popping up during my compilation. It doesn't seem to affect compilation, but how should I get rid of it? Am I risking anything by ignoring it?
Set it to the oldest Windows Operating System you want your program to run on.
The possible values are given in this MSDN article, Using the Windows Headers.
You can define these symbols by using the #define statement in each
source file, or by specifying the /D compiler option supported by
Visual C++.
For example, to set WINVER in your source file, use the
following statement:
#define WINVER 0x0502 // Windows Server 2003 with SP1, Windows XP with SP2
To set _WIN32_WINNT in your source file, use the following statement:
#define _WIN32_WINNT 0x0502 // Windows Server 2003 with SP1, Windows XP with SP2
To set _WIN32_WINNT using the /D compiler option, use the following command:
cl -c /D_WIN32_WINNT=0x0502 source.cpp
It is defined for you through WinSDKVer.h. So just define it explicitly on the top of your source code (e.g. in the beginning of stdafx.h) and you will get rid of the warning.
Having it defined to the same value (as compared to _WIN32_WINNT_MAXVER from WinSDKVer.h) is highly unlikely to break anything.
For example, WinSDKVer.h of Windows® Software Development Kit (SDK) for Windows 7 and .NET Framework 3.5 Service Pack 1 contains:
// This list contains the highest version constants supported by content
// in the Windows SDK.
// [...]
#define _WIN32_WINNT_MAXVER 0x0601
Solving in VS2019
Ways to solve this and a link to possible values to use can be found here in the super answer by user93353 which I used to solve the problem.
https://stackoverflow.com/a/12871547/3070485
However, after reading the solution, I set my compiler option in my IDE which is Visual Studio 2019.
For anyone wanting to set it there quickly and wanting to know the location (as these things change from IDE release to release, or maybe someone is more familiar with another IDE), here is where it went.
Configuration Properties
C/C++
Preprocessor
Preprocessor Definitions
_WIN32_WINNT=0x0502
Note: the #define _WIN32_WINNT must occur before any header file, including "stdafx.h".
If using MFC: My preferred answer is to include windows.h. But if you are using MFC, you cannot do this*. To avoid defining WINVER in your project, instead you can include sdkddkver.h before afx.h.
#include <sdkddkver.h>
#include <afx.h>
The sdkddkver system header sets WINVER and _WIN32_WINNT so you don't need to add it to your project. This does the same as windows.h for versioning windows SDK/DDK from the system headers.
*if you include windows.h before afx.h you get: #error: WINDOWS.H already included. MFC apps must not #include <Windows.h>
#define _WIN32_WINNT and #define WINVER can occur in a header, so long as they occur before including SDKDDKVer.h or any headers from the Windows SDK (in particular Windows.h). Visual Studio VC++ projects typically provide a targetver.h header, where you can include WinSDKVer.h, define _WIN32_WINNT, NTDDI_VERSION and WINVER, and then include SDKDDKVer.h. Comments within this file say:
// If you wish to build your application for a previous Windows platform, include `WinSDKVer.h`
// and set the _WIN32_WINNT macro to the platform you wish to support before including `SDKDDKVer.h`.
The Microsoft article Update WINVER and _WIN32_WINNT goes out of its way to instruct you to define _WIN32_WINNT and WINVER in targetver.h (though it mentions these can be defined using command-line parameters, too).
Note: targetver.h gets included in certain .rc resource files generated by Visual Studio, so this is another reason to fill out the contents of the targetver.h file as described, above.
Note: defining _WIN32_WINNT, NTDDI_VERSION and WINVER using command-line parameters or preprocessor directives within the project's build configurations can also work, but neither takes care of the need to include WinSDKVer.h and SDKDDKVer.h.
Note: when using the Windows 8.1 SDK (or newer), you may also need to define WINAPI_FAMILY in targetver.h depending on the specific Windows platform (server, desktop, phone, store, etc.) you need. See winapifamily.h for details.
Note: In newer Windows SDK versions, the values NTDDI_VERSION, WINVER and _WIN32_IE can be set automatically based on the value you define for _WIN32_WINNT. However, you may want to define a more specific version for NTDDI_VERSION explicitly prior to including SDKDDKVer.h.
Related
I am developing a piece of software in C++ using Visual Studio on Windows. From the beginning, I would like to have it run on both Windows and Linux. Obviously, I won't compile the Linux binary on a Windows machine, but I still want to use Visual Studio to write the code.
When it comes to headers, I am selecting while file to use based on pre-processor definitions.
A very rudimentary and simple example:
#pragma once
#ifndef PLATFORM_TIMER_H
#define PLATFORM_TIMER_H
#ifdef _WIN32
#include "win32\win32_timer.h"
#elif __linux__
#include "linux\linux_timer.h"
#endif
#endif // PLATFORM_TIMER_H
For the header it works just fine. But the .cpp-file for the Linux implementation breaks the build on Windows. That's because the Linux .cpp-file will get compiled no matter what, even on Windows. And because the Windows machine is missing Linux-headers, the function it uses will be undefined.
Question 1: What is the "industry standard" to deal with this?
Question 2: Is it reasonable to wrap both the .h and .cpp-files in "#ifdef PLATFORM" so that the code will only be enabled on the correct OS?
But the .cpp-file for the Linux implementation breaks the build on Windows. That's because the Linux .cpp-file will get compiled no matter what, even on Windows.
Why are you compiling the Linux-specific file for a Windows build?
Question 1: What is the "industry standard" to deal with this?
If you're going to create separate source files for Windows-specific and Linux-specific code, then the whole point would be that you use only the appropriate one for the current platform when you build.
An alternative approach would be to have both implementations in the same source file, using conditional compilation to choose which parts to use. That's pretty conventional, too, especially where the parts that vary are smaller than whole functions.
Question 2: Is it reasonable to wrap both the .h and .cpp-files in "#ifdef PLATFORM" so that the code will only be enabled on the correct OS?
It would be strange to go to the trouble of creating separate, platform-specific source files and then use conditional compilation to include them all in every build. It could work, but it would not fall within my personal definition of "reasonable".
Any code specific to one operating system needs to have the proper #ifdef's set up, whether in header files or source files.
Visual Studio 2012 (and earlier versions) provide predefined #defines so that source code can be #ifdef ed appropriately, see http://msdn.microsoft.com/en-us/library/b0084kay.aspx
I would like to #ifdef some C++ code if it is being compiled (or not) for the Windows 8 Runtime (Component Extenstions for Runtime C++/CX) , i.e. with compiler switch /ZW, see http://msdn.microsoft.com/en-us/library/hh561383.aspx and http://msdn.microsoft.com/en-us/library/xey702bw.aspx
Checking for C++ or CLR compilation is provided by __cplusplus and __cplusplus_cli (or __CLR_VER) respectively, but there doesn't seem to be a way of #ifdef ing for C++/CX /Zw Windows Runtime compilation!?
Does anyone know a way?
Thanks
The __cplusplus_winrt macro is defined when C++/CX support is enabled (i.e., when compiling with /ZW).
I have a C++/CLI project created with Visual Studio 2010 that targets .NET Framework 3.5 and PlatformToolset v90. Initially it requests the VC CRT of version 9.0.21022.8, but if I include atlbase.h header then it requests the VC CRT of version 9.0.30729.6161.
Why does this happen? And how can I make it to target 9.0.30729.6161 without including atlbase.h?
I tried to define macroses _BIND_TO_CURRENT_CRT_VERSION=1 and _BIND_TO_CURRENT_VCLIBS_VERSION=1 but this didn't help.
The version is set by vc/include/crtassem.h, near the bottom you can see:
#ifndef _CRT_ASSEMBLY_VERSION
#if _BIND_TO_CURRENT_CRT_VERSION
#define _CRT_ASSEMBLY_VERSION "9.0.30729.6161"
#else
#define _CRT_ASSEMBLY_VERSION "9.0.21022.8"
#endif
#endif
So the rule is that you can explicitly override the version by #defining _CRT_ASSEMBLY_VERSION. Don't do that. As you noted in your question, #defining _BIND_TO_CURRENT_CRT_VERSION to 1 gets you the version string you want.
Having a problem with this in a C++/CLI project is possible. You can compile C++/CLI code without ever #including any of the CRT include files. So you'll end up with a default version which, ironically, is defaulted by the linker to its own version of the CRT. So a workaround is to explicitly put #include <crtassem.h> in one of your source code files. #including atlbase.h would do that too since it does include CRT headers but of course is the big hammer approach.
Additional troubleshooting is available from Project + Properties, C/C++, Advanced, Show Includes = Yes. You'll see a trace of all the #include files getting included in the Output window.
Beware that you'll now have the additional burden to ensure that the up-to-date version of msvcr90.dll gets deployed on the user's machine. Your program will fail to start if it is missing or old.
I have a growing project in CMake. It is time to link to a library, which at this time exists only in Windows, Linux functionality will have to wait. I am attempting to do this with preprocessor directives as recommended in an answer to this question:
// MyLibHeader.hpp
#ifdef WIN32
#include <windows.h>
#define ProcHandle HINSTANCE
#define LoadLib LoadLibraryA
#define LoadSym GetProcAddress
#else
// ... I'll fill these in with dlopen etc. when necessary
This is the first platform specific inclusion I have had to put in my code, and It seems there is more to it than this. This is generating this error:
C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include\intrin.h(944) : error C2733: second C linkage of overloaded function '_interlockedbittestandset' not allowed
The error is repeated four times, twice in intrin.h, and twice in winnt.h. So here's my question. Are there other includes or preprocessor steps I need to take to get this to work inside windows (up to now it has been a basic console application) and is there something in CMake I can leverage to make this easier.
From what I've been able to scrape up with some help and some google, one solution is indeed to comment out the duplicate definitions of _interlockedbittestandset in initrin.h
This may have been fixed in later versions of Visual Studio.
You could look at the source code of CMake, there is a C++ class that does cross platform library loading. It is a BSD style license so you could just copy the code. Works on lots of platforms. The code is here:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/kwsys/DynamicLoader.cxx;h=c4ee095519fe27742a0a9a9e392be4ce095af423;hb=HEAD
I am usign DevC++ on Windows 7 Ultimate 32 bit and have included windows.h and psapi.h in my program. All the Windows APIs I've used so far ar working except for GetProcessId and DebugActiveProcessStop. The compiler returns in both cases that the specified function is undeclared. However, when I look in winbase.h, I can clearly see that GetProcessId is declared. Even when I hover the mouse over the function, information on the structure is displayed. So, why can't the compiler seem to recognize either function?
When using the Win32 API headers you need to specify what version of the operating system you are targeting. This is documented in the MSDN library.
Nowadays, you are supposed to do this by defining NTDDI_VERSION. If you check the documentation for GetProcessId you'll note that it requires Windows XP SP1, so you need to specify at least NTDDI_WINXPSP1 as the target operating system version. In fact since SP1 is no longer supported you're probably better off with SP2:
#define NTDDI_VERSION 0x05010200
In the past I've found that defining NTDDI_VERSION doesn't always work as expected, though hopefully most of the glitches have been ironed out by now. If it doesn't work, try using the older macro _WIN32_WINNT instead, which is also documented at the link given above. In this case you want:
#define _WIN32_WINNT 0x0502
If you later need to use functions that were introduced in Vista or Windows 7, change the value of NTDDI_VERSION or _WIN32_WINNT appropriately. The MSDN library documentation for each function says which version of the operating system it was introduced in.
This problem sometimes pops up when you're coding in the windows api. You can see that the function is in the header file, but for some reason, your compiler disagrees. When you come across this problem, find the function in the header file, and look for pre-processor directives around it. You may need to define something in order to use that function.
In this case, here's what i found for the functions you're having problems with:
#if (_WIN32_WINNT >= 0x0501)
WINBASEAPI DWORD WINAPI GetProcessId(HANDLE);
#endif
and
#if (_WIN32_WINNT >= 0x0501)
WINBASEAPI BOOL WINAPI DebugActiveProcessStop(DWORD);
#endif
So, in your main code file, where you include the windows header, put this definition BEFORE your include of the windows header:
#define _WIN32_WINNT 0x0501
This should solve your problem. Good luck ^_^