Win32 API Functions not Found - c++

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 ^_^

Related

C++ Linux code breaks the Windows build because missing headers means the functions are undefined

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.

How to check if Xlib is used using #ifdef?

For example you can check if Windows is used by checking if "WIN32" macro is defined. And i would like to get the same behaviour but to check if Xlib is used. But i don't know what Xlib defines to know it's defined.
If you don't know what i mean here is an example:
#ifdef WIN32 //Check if WIN32 is defined
//Do something
#endif
And i would like to change this in a way that it does something when Xlib used.
I'm sorry if there are some grammatical errors but i'm not a native english speaker.
The macro WIN32 is only defined, if you included #include <windows.h> before or set the macro in your compiler flags (-DWIN32). For Xlib you could use the macro X_PROTOCOL very similar if you included #include <X11/X.h> before.
#ifdef X_PROTOCOL //Check if X_PROTOCOL is defined
//Do something
#endif
Another way would be to use _XLIB_H_ if you included #include <X11/Xlib.h> before, but I wouldn't because identifiers beginning with an underscore are reserved to the implementation and there is no guarantee that this identifiers won't change.
you can check if Windows is used by checking if "WIN32" macro is defined
The WIN32 macro is defined by default by compilers that target Windows OS. Its purpose is to let the program detect Windows OS API, not necessarily any graphic subsystem.
X11 is not and OS. It's optional userland software that installs and runs under many operating systems, including Windows. When compiling an X11 programs for Windows, WIN32 will be defined, just like for any other Windows program.
No compiler defines anything by default on a system where X11 is installed.
If you want to detect X11 at build time, your best bet is probably a meta-build tool like GNU autotools or CMake.

Condition variable functions were not declared in this scope

Its the first time I'm using WINAPI and with functions like SleepConditionVariableCS , WakeConditionVariable , WaitForMultipleObjects and InitializeConditionVariable Eclipse IDE told me that they were not declared in this scope.
All of them are supposedly included in the same lib windows.h so i dont know what's failings because other functions like ExitThread , ReleaseSemaphore and WaitForSingleObject are running without any problem.
It can be some problem with my c++ version? Or it exist any other library to include?
Thanks
The documentation for SleepConditionVariableCS (or any other WIndows API call) tells you the minimum supported client and server OS. The API calls are conditionally declared, based on your target platform setting.
You can control your target platform by setting certain preprocessor macros (see Using the Windows Headers for information). In your case you need to add
#define WINVER 0x0600
before including Windows.h, to target Windows Vista and later. It is common practice to define the preprocessor macro on the command line, to use a consistent environment across all compilation units.

How to get rid of _WIN32_WINNT not defined warning?

_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.

Windows library inclusion in CMake Project

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