Is Windows SDK always needed for including Windows.h? - c++

I tried to use FindFirstFile WIN API function in my c program and noticed that i can use it after including Windows.h in Visual Studio 2010. I am a bit confused because i never installed the Windows SDK on that system. I thought one can only use Windows.h after installing the Windows SDK. Can someone explain to me why this is possible? Also i am wondering about the starting capital Letter of Windows.h. In the past i used windows.h. I have to do a presentation of my code on a computer with only Visual Studio 2010 installed and need to be sure that it will compile on that computer. Big thanks for any helpful information!

The Windows SDK isn't the only way to get the headers - they are also included with Visual Studio.
Visual C++ and the Windows Header Files
Microsoft Visual C++ includes copies of the Windows header files that
were current at the time Visual C++ was released. Therefore, if you
install updated header files from an SDK, you may end up with multiple
versions of the Windows header files on your computer. If you do not
ensure that you are using the latest version of the SDK header files,
you will receive the following error code when compiling code that
uses features that were introduced after Visual C++ was released:
error C2065: undeclared identifier.
Source: http://msdn.microsoft.com/en-gb/library/windows/desktop/aa383745(v=vs.85).aspx)

Related

Can't find windows.winmd – if path specified, erros multiply

I must work on a Visual Studio C++ solution done many years ago by a corporation that doen't have C++ experts.
I have few experience with C++, a lot with Visual Studio, but zero experience on those two together (when I used to program in C++ it was always for Linux).
This solution has 9 projects and used to compile for Windows Embedded using Visual Studio 6.0 under Windows XP or Windows Vista.
I now must make it compile for x86 and ARM, using Visual Studio 2017 under Windows 7.
The only error I have on compiling is well-known:
Can't find assembly windows.winmd. Specify the path using/AIor set the environment variable LIBPATH.
If I follow the advice and add C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.17134.0 to the /AI parameter of the main project, I get 100+ compiler errors.
The previous error I had was: missing "platform.winmd", but after adding to /AI the path to that file the error disappeared. Solving the problem "windows.winmd" isn't trivial at all, because I have many of those files on my computer.
I just want to compile the project and I'm banging my head against this single error. Can someone help?
I would say with 99,999% probability, it is impossible to work with WinCE projects in VS2017. You really need to have old good VS 6.0 that is equipped with necessary toolchains and project types (indeed they're obsolete now).
Also, there is a non-zero chance you have to have lower OS version (something like WinXP or so) as some CE-time SDKs can be not compatible with Win10.

Version Helper functions for Windows XP

In my application I need to check windows version. I'm using Version Helper functions in Visual Studio 2013 (v120) platform toolset. But then the program does not work in Windows XP. error is:
'xxx.exe' is not a valid win32 application
So I changed platform toolset to Visual Studio 2013 - Windows XP (v120_xp). But in this case application will not compile.
The error is:
error C1083: Cannot open include file: 'VersionHelpers.h': No such file or directory
What can I do? Can I use old GetVersionEx function? MSDN says:
GetVersionEx may be altered or unavailable for releases after Windows 8.1. Instead, use the Version Helper APIs
But may be I should use it for now!
I've managed to solve it using Remmy Lebeau's comment.
I copied VersionHelpers.h from C:\Program Files (x86)\Windows Kits\8.1\Include\um and winapifamily.h and sdkddkver.h from C:\Program Files (x86)\Windows Kits\8.1\Include\shared into my project and changed some includes in them.
Now it compiles with Windows XP toolset.
I've tested it and it's working as expected in all versions of windows.
How about this: try to link the functions manually with GetProcAddress to see what is available, If the new API is not, then the old must be, so you can use the one you managed to link without errors.
I am assuming you are building 32bit or 64bit and the OS in both cases is compatible.
EDIT:
GetVersionEx(), here is exported from kerner32.dll in XP, so you can try to link it using
GetProcAddress() here also has a suggestion by Microsft using "GetNativeSystemInfo".
The new API function
IsWindowsXPOrGreater() // also exported from kernel32.dll and ntdll.dll
can also be linked the same way using GetProcAddress(). This function will return an error if the function you are trying to link is not found, so you will know which one you have available. Then you call the available one and get the version info you need.
You only need to define the function prototypes yourself instead of using the headers, then define two function pointers, one for each, then assign them a NULL value initially until you try to link the functions. Then one pointer (or both) will end up with a value, and you can use the latest one available to call the linked API.

C++ - Visual Studio's compiler set up in Code::Blocks?

Honestly I like Code::Blocks (v13.12) much more than Visual Studio because it doesn't eat up my RAM. I was wondering: I recently installed Visual Studio 2012 Professional, and attempted to set the compiler up to work with Code::Blocks, but upon viewing the files included, I was missing a few critical C++ headers and, in addition, Microsoft's resource compiler, therefore I could not successfully get it working with Code::Blocks. There were no errors when I installed Visual Studio, so why would I be missing headers and their resource compiler? Are those not included in the professional version? Do I seriously need to get a copy of ultimate?

How do I get crtdbg.h file?

I am using MinGW GCC + Eclipse on Windows, and I have run into this error:
C:\Program Files\ITG Derivatives LLC\api_clear-2.0.2.48\include/windows/csassert.h:12:20: fatal error crtdbg.h No such file or directory
What is the crtdbg.h file? How can I get it and solve this problem?
I ran into this exact same issue, but with Visual Studio Community Edition 2019.
The solution was to download the Windows 10 SDK using the Visual Studio installer. Once I did that the next compile worked fine.
The header file "crtdbg.h" is part of the Windows 10 SDK kit. I believe you will find crtdbg.h located here C:\Program Files... or C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt\crtdbg.h depending on your setup and version.
<crtdbg.h> is a Microsoft Visual C++ specific header. You may be able to work around this problem using a stub similar to the following:
#ifdef _MSC_VER
#include <crtdbg.h>
#else
#define _ASSERT(expr) ((void)0)
#define _ASSERTE(expr) ((void)0)
#endif
Note that this will disable any asserts in the code you are compiling against, and still won't help you if the code you're compiling uses more advanced features inside crtdbg.h, such as memory leak detection. If these features are in use, you will need to compile the code with MSVC++ rather than MinGW.
I ran into this exact same issue, but with Visual Studio Code.
First start/restart VS Installer and install the Win10 SDK.
Then restart your computer and the needed heasers are available.
I am from Go--g-- search here.
After installing Visual Studio 2019 preview(2022 preview), I have faced the same.
Opening Developer Command Prompt and after going to a particular folder,
cl test.cpp gave above error.
Resolve :
After installing Visual Studio 2022 preview or any other version, do reboot the system.
After rebooting, I could successfully, run the cl command, and compiled a test program without any of the above error.
I ran into this problem recently by trying to install LLVM/Visual Studio Code.
The Windows SDK installation is required for the clang compiler.
To install the Windwos SDK open/download the Visual Studio Installer and check the Windows 10 SDK in Desktop in development with C++
If you have the Windows SDK, and still have this error, go to project propreties -> VC++ -> Include Directories. then paste C:\Program Files (x86)\Windows Kits\10\Include(Version)\ucrt
Just note that I got the same error in Visual Studio 2022 installed on Win 10 Version 21H2. Solution was to install latest Windows 10 SDK from here and then restart the computer.
I ran into this problem, I tried updating the SDK through Visual Studio as mentioned above to no avail. One thing I did was used an old PC to download the SDK, transferred the contents via USB. Took the File directory that Visual Studio was looking in, and copied everything over from the downloaded SDK in the USB to that file path/directory as mentioned in Visual Studio.
Hope this helps.

'dxerr9.h': No such file or directory

I am trying to compile a program I took off a cd from a book that uses directx to render 3d objects. when i press compile I get the following error
C1083: Cannot open include file: 'dxerr9.h': No such file or directory
I am using VC++ 2008 Express Edition and i am running off of Vista. I went to the following folder
[edit]
C:\Program Files (x86)\Microsoft DirectX SDK (February 2010)\Include
I was able to find dxerr.h in the folder and the path is also being included in the VC++ Directories tab in the options window. dont know whats going on.
It seems your program was written using older version of DirectX SDK. The 'dxerr9.h' is present at least in "Microsoft DirectX 9.0 SDK (December 2004)", but is absent at least in "Microsoft DirectX SDK (August 2009)".
I think VitalyVal was right. about the following:
It seems your program was written using an older version of DirectX SDK. The 'dxerr9.h' is present at least in "Microsoft DirectX 9.0 SDK (December 2004)", but is absent at least in "Microsoft DirectX SDK (August 2009)".
I think the files now go by dxerr.h. I removed the 9 to the header and lib files and it worked.
That header was precisely duped in Aug2009 SDK, though that shouldn't surprise since it was already two years older DX versions had been deprecated, thus allowing for just a single library for everything.
By the way, people might be interested to check this post for a kind of more updated version.