(Visual Studio 2010 / Visual C++ / Windows 7)
example.cpp:
#include <Shlobj.h>
#pragma comment (lib, "Shell32.lib")
...
void example()
{
SHGetKnownFolderPath(...) // undefined
}
I'm doing everything according to documentation and what I see in other threads, but it still doesn't work.
I had exactly the same problem. Another project with the same code and ancillary files (but different includes) was working.
Putting #include <Shlobj.h> at the top of the file solved the problem.
It might not be replicable though, as it should have worked without doing that. Probably another Visual Studio bug.
Try putting following statement before all includes:
#define WINVER 0x0600
#define _WIN32_WINNT 0x0600
Since the documentation says it needs Vista/2008 minimum.
Related
I have a VS (C++) project that relies on OpenCV and TBB, so I created property sheets for each library and included them in the project. Everything worked fine and the code compiled.
Yesterday, I have started using vcpkg package manager. I installed OpenCV and TBB via vcpkg and everything seemed to work. I created an empty project, included the headers of both and tested if the new compiled libraries work. After verifying that, I went back to my main project and removed the property sheets, so I can use the libraries from vcpkg. I did not change the code in any way since the last successful compilation.
But when I try to compile the code now I get this error two times (in main.cpp and in a submodule)
tbb\critical_section.h(53): error C3861: 'InitializeCriticalSectionEx': identifier not found
Does anybody know what is going on here or why this error occurs?
Update
I found the error myself. I'm adding the poco-libraries tag, because it's actually a conflict between TBB and Poco.
I found the source of the problem and it has actually nothing to do with TBB but with the Poco library.
Consider the minimum example:
#include <Poco/Poco.h>
#include <tbb/tbb.h>
void main()
{
}
This will throw an compiler error.
Tracing down the path
When including tbb.h, critical_section.h is included in line 51 of tbb.h. However, ciritcal_section.hpp includes machine/winwdows_api.h which looks like this (unnecessary stuff is cut out):
tbb/machine/winwdows_api.h:
#if _WIN32 || _WIN64
#include <windows.h>
#if _WIN32_WINNT < 0x0600
#define InitializeCriticalSectionEx inlineInitializeCriticalSectionEx
inline BOOL WINAPI inlineInitializeCriticalSectionEx( LPCRITICAL_SECTION lpCriticalSection, DWORD dwSpinCount, DWORD )
{
return InitializeCriticalSectionAndSpinCount( lpCriticalSection, dwSpinCount );
}
#endif
As you can see, windows.h is included before the check of the _WIN32_WINNT macro. This macro is defined in sdkddkver.h (which is included in windows.h), iff it's not already defined (in my case it's set to Win10):
sdkddkver.h:
#if !defined(_WIN32_WINNT) && !defined(_CHICAGO_)
#define _WIN32_WINNT 0x0A00
#endif
In windows.h, the _WIN32_WINNT macro controls which version of the windows header files are actually included. If _WIN32_WINNT is set to an earlier version than Windows Vista, the function InitializeCriticalSectionEx is not defined.
This issue is catched by machine/winwdows_api.h (as you can see in the code block of that file) by simply defining a macro InitializeCriticalSectionEx that calls an appropriate alternative function.
So far so good.
The problem
The root of all evil lies in Poco/UnWindows.h of the Poco library. When including a poco header, at some point UnWindows.h will be included.
Poco/UnWindows.h (shortened):
#if defined(_WIN32_WINNT)
#if (_WIN32_WINNT < 0x0501)
#error Unsupported Windows version.
#endif
#elif defined(NTDDI_VERSION)
#if (NTDDI_VERSION < 0x05010100)
#error Unsupported Windows version.
#endif
#elif !defined(_WIN32_WINNT)
#define _WIN32_WINNT 0x0501
#define NTDDI_VERSION 0x05010100
#endif
#endif
#include <windows.h>
The preprocessor checks, if _WIN32_WINNT is already defined, and if not, sets it to 0x0501 which is Windows XP. After that, windows.h is included. In the previous chapter I mentioned that _WIN32_WINNT controls which version of the windows header files are actually included.
Now imagine, the very first include in our project is a header from Poco. This means, that _WIN32_WINNT will be set to Windows XP and windows.h will include the windows headers of Windows XP (which imo is already a bad sign).
But don't worry, it gets worse.
If we trace the include hierarchy one level up, we reach Poco/Platform_WIN32.h.
Poco/Platform_WIN32.h (shortened):
#include "Poco/UnWindows.h"
...
#if defined (_WIN32_WINNT_WINBLUE)
#ifdef _WIN32_WINNT
#undef _WIN32_WINNT
#endif
#define _WIN32_WINNT _WIN32_WINNT_WINBLUE
...
Funny, isn't it? First, it includes UnWindows.h, which sets _WIN32_WINNT and causes Windows XP headers to be included, and next it redefines _WIN32_WINNT to be Windows 8.1. I have no clue why it does that, maybe there is a good reason, idk.
If we now look at the minimum example at the very top we see that Poco is included before TBB. What now happens is:
Include Poco headers
Set _WIN32_WINNT to Windows XP
Include windows headers (Windows XP version, because of 2)
Reset _WIN32_WINNT to Windows 8.1
Include TBB headers (windows headers are already included, so TBB doesn't need to include them again in tbb/windows_api.h)
TBB checks the windows version via _WIN32_WINNT and recognizes Windows 8.1 (as set by Poco)
TBB thinks InitializeCriticalSectionEx is defined, because the Windows version is 8.1 (or is it? Poco says: get rekt) and InitializeCriticalSectionEx is defined since Windows Vista.
Unfortunately Poco ensured that the Windows XP headers are loaded, so compiler says: no.
The solution
Either include windows.h yourself beforehand, or set _WIN32_WINNT yourself beforehand:
#define _WIN32_WINNT 0x0A00 // either this
#include <Windows.h> // or this
#include <Poco/Poco.h>
#include <tbb/tbb.h>
void main()
{
}
Maybe someone of the Poco contributors can clarify some things here. The Poco version is 1.8.1-1 built with x64 (via vcpkg).
Update
Poco is on the issue. Updates can be found here.
Hello I actually learning DirectX 11 with this tutorial: http://www.rastertek.com/dx11tut03.html
First Part
My code (where the probleme come from):
d3dclass.h:
//Linking
#pragma comment(lib, "dxgi.lib")
#pragma comment(lib, "d3d11.lib")
#pragma comment(lib, "d3dx11.lib")
#pragma comment(lib, "d3dx10.lib")
//Include
#include <dxgi.h>
#include <d3dcommon.h>
#include <d3d11.h>
#include <d3dx10math.h>
I do all like the tutorial, the only diference is I compile it with g++, trough this the command :
g++ -mwindows WinMain.cpp systemclass.cpp inputclass.cpp graphicsclass.cpp d3dclass.cpp -o Prog.exe -I "D:\Programme File\DirectX SDK\Include" 2> log.txt
but in the output file, I have a large sum of errors. This is the log.txt:
https://drive.google.com/open?id=1XUlcAFUyRcLIvdKbe0FkLVjkvwxpOmEv
To sum up the log there is a lot of things like __in which has not been declared in the dxgi.h, but this header is from DirectX11 Library;
Second Part
I found the way to fix a lot of my problem (of the first part) with adding this :
#define __in
#define __out
#define __inout
#define __in_bcount(x)
#define __out_bcount(x)
#define __in_ecount(x)
#define __out_ecount(x)
#define __in_ecount_opt(x)
#define __out_ecount_opt(x)
#define __in_bcount_opt(x)
#define __out_bcount_opt(x)
#define __in_opt
#define __inout_opt
#define __out_opt
#define __out_ecount_part_opt(x,y)
#define __deref_out
#define __deref_out_opt
#define __RPC__deref_out
but there still is a major problem, this is the error output :
D:\Programme File\DirectX SDK\Include/d3dx10core.h:345:13: error: expected ';' at end of member declaration
HRESULT WINAPI_INLINE GetDesc(D3DX10_FONT_DESCA *pDesc) { return GetDescA(pDesc); }
it comes from WINAPI_INLINE (this is in the DirectX header)
How can I fix this? please.
I don't have any experience with using g++, but I can help with a few details here. To use g++ you need to install the Windows SDK and configure it to include the proper paths. The legacy DirectX SDK requires the Windows SDK and is not fully standalone.
Note that the legacy DirectX SDK and the Windows SDK don't claim to be compatible with the GCC toolchain.
The __in, __out, etc. macros are called "SAL annotations" and they are there to improve the quality of static code analysis both internally at Microsoft and when using Visual C++'s /analyze switch. They are defined as 'blank' in other cases so they just get removed from the code. The macros are defined in the Windows SDK. You can try explicitly doing a #include <sal.h> and/or #include <specstrings.h> before including a version of dxgi.h.
Another thing to keep in mind is that the legacy DirectX SDK itself is deprecated along with the D3DX9, D3DX10, and D3DX1 utility libraries. As such, if you are using the Windows 8.0, 8.1, or 10 SDK you can code Direct3D 11 without using it at all--see Living without D3DX. If you do want to continue to use those older helpers--which the somewhat dated rastertek tutorials assume--, you can do so but you need to make sure the DirectX SDK include and lib paths are searched after the Windows SDK include/lib paths.
If you were using Visual C++ (which BTW has a free Community edition available), then you'd probably be having an easier time. You might also want to see the DirectX Tool Kit tutorials.
I tried to compile TBB which I want to use on OpenCV. I am using Windows XP and Visual Studio 2010 C++. When I compiled TBB 4.4 I got the error
"The procedure entry point InitializeCriticalSectionEx could not be located in the dynamic link library KERNEL32.dll."
The error is similar but under little different conditions like here:
http://answers.opencv.org/question/6151/opencv_createsamplesexe-entry-point-problem-with-xp/
In my case I cannot run the program at all. I tried the solution described there, so I renamed InitializeCriticalSectionEx to InitializeCriticalSection and removed parameter 2 and 3.
OpenCV claimes the bug is not on their side. I know OpenCV uses this:
#if (_WIN32_WINNT >= 0x0600)
InitializeCriticalSectionEx(&cs, 1000, 0);
#else
InitializeCriticalSection(&cs);
#endif
I know this should not make any problems but I commented some lines to keep InitializeCriticalSection(&cs); only. I recompiled the OpenCV and still the same error. Finally I have found in TTB:
tbb44_20160627oss\include\tbb\machine\windows_api.h
__TBB_WINBASEAPI BOOL WINAPI TryEnterCriticalSection( LPCRITICAL_SECTION );
__TBB_WINBASEAPI BOOL WINAPI InitializeCriticalSectionAndSpinCount( LPCRITICAL_SECTION, DWORD );
// Overloading WINBASEAPI macro and using local functions missing in Windows XP/2003
#define InitializeCriticalSectionEx inlineInitializeCriticalSectionEx
I also find the word "InitializeCriticalSectionEx" in opencv_core310d.dll and opencv_core310.dll. Does the overload really work and why I got the error? How could I fix it?
Update:
the definition in OpenCV
#ifndef _WIN32_WINNT // This is needed for the declaration of TryEnterCriticalSection in winbase.h with Visual Studio 2005 (and older?)
#define _WIN32_WINNT 0x0400 // http://msdn.microsoft.com/en-us/library/ms686857(VS.85).aspx
#endif
"The procedure entry point InitializeCriticalSectionEx could not be located in the dynamic link library KERNEL32.dll."
This is a standard error that Windows displays when you try to run a program that contains a statically-bound call to a function in a DLL that does not exist.
The InitializeCriticalSectionEx function is not available on Windows XP, but the version of the library that you have contains code that calls this function.
OpenCV claimes the bug is not on their side. I know OpenCV uses this:
#if (_WIN32_WINNT >= 0x0600)
InitializeCriticalSectionEx(&cs, 1000, 0);
#else
InitializeCriticalSection(&cs);
#endif
OpenCV's workaround is a compile-time solution. It determines at the point when the library is compiled which version of Windows is being targeted, and uses that information to generate a call to the appropriate version of the function.
There are two possibilities for why this is going wrong in your case:
You are using the OpenCV library in binary form, and the binary that you have was compiled to target Windows Vista and later. You can solve this by obtaining the source code for OpenCV and compiling it yourself, either as a DLL or a static library.
You are compiling with _WIN32_WINNT set to 0x0600 or later. By default, the Windows headers define this symbol to the latest available version. You have to explicitly define an earlier target version if you want it. To arrange for targeting Windows XP, add the following code at the top of your code file (probably in your precompiled header):
#include <WinSDKVer.h>
#define _WIN32_WINNT _WIN32_WINNT_WINXP
#include <SDKDDKVer.h>
Here is my codes in stdafx.h :
// stdafx.h : include file for standard system include files,
// or project specific include files that are used frequently, but
// are changed infrequently
//
#pragma once
#define _WIN32_WINNT 0x0502
#include "winsock2.h"
#include "windows.h"
#include "stdio.h"
#include "Iphlpapi.h"
#include <psapi.h>
#include "Ntsecapi.h"
#include "txdtc.h"
#include "xolehlp.h"
#include <iostream>
#include <tchar.h>
// TODO: reference additional headers your program requires here
As you see i have included "windows.h"
And here is main codes :
#include "stdafx.h"
...
if (hThread && dwRpcssPid == GetProcessIdOfThread(hThread))
...
My errors are :
'GetProcessIdOfThread': identifier not found
IntelliSense: identifier "GetProcessIdOfThread" is undefined
How can i fix these errors?
The function is not available with _WIN32_WINNT values less than 0x0600 AKA _WIN32_WINNT_VISTA. If you change your code this way, you will get it working:
//#define _WIN32_WINNT 0x0502
#define _WIN32_WINNT 0x0600
The function is available since Vista, to target Vista+ you should have this value defined respectively.
To target latest versions of API with current SDK, you can simply include SDKDDKVer.h and those values will be defined for you/
//#define _WIN32_WINNT 0x0502
#include <SDKDDKVer.h>
See also:
What is _WIN32_WINNT and how does it work?
GetProcessIdOfThread's platform requirements states:
Windows Vista [desktop apps only]
Windows Server 2003 [desktop apps only]
And the header requirements states:
Processthreadsapi.h on Windows 8 and Windows Server 2012
So:
Make sure your windows SDK is up-to-date
Make sure you have specified your platform requirements properly.
Make sure you're including the right header file.
If you are using windows 8 you need to include : Processthreadsapi.h
See the MSDN references in the header section.
EDIT 2: Ok so I changed to Orwell DevC++ which contains the "winnt.h" that contains #define KEY_WOW64_64KEY 0x0100 but it still is not working. (Refer to EDIT 1:)
EDIT 1: I looked into the "winnt.h" which came along the CodeBlock and DevC++ and the DevC++'s is missing the following lines:
#if (_WIN32_WINNT >= 0x0502)
#define KEY_WOW64_64KEY 0x0100
#define KEY_WOW64_32KEY 0x0200
#endif
And putting the above code in the wint.h of DevC++ doesn't work.
Original Post:
I have a 32bit application (developing in DevC++ and Windows 7 64bit) which reads a 64bit app's registry as one of its task, so I am trying to use "KEY_WOW64_64KEY" flag in RegOpenKeyEx, and found few posts regarding how to use it with _WIN32_WINNT : this and this
It worked like charm when I used it in a CodeBlock Project(a test project) but the same code is not working with DevC++, I can't port it to codeblock now since codeblock presents other problems.
How do I make it work with DevC++ ?
Thanks
It defines the version of the windows header files to use. It must be declared before you #include <Windows.h>.
There are a few other similar variables you should probably set if you're going to modify it:
MSDN Using Windows Headers
_WIN32_WINNT is a preprocessor token, which is replaced by (0x0601) wherever _WIN32_WINNT is used. The preprocessor just scans the whole file and replaces _WIN32_WINNT with (0x0601) everywhere it is found.
Chances are, there could be ifdef preprocessor guards that will enable/disable a preprocessor constant. Like:
#ifdef _WIN32_WINNT
#define KEY32 32
#endif
There, KEY32 will only be defined IF _WIN32_WINNT is defined.
It already works with DevC++.