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.
Related
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.
I am developing some applications (MSVC++) and I always run into deprecation warnings. To be general, in this question I am asking lets say I use the standard C90:
fopen()
over
fopen_s() <- as msvc++ suggests for me to use
Does this mean that after compiling my application, lets say a windows 8 user wants to use it, would he get less of the feature from it, in lesser terms, does that mean when he runs the application then the fopen() function will not be recognized since it is "deprecated" (I assume it means it's outdated)?
Also, if say it doesn't matter whether I use it or not, MSVC++ says that I can use the _CRT_SECURE_NO_WARNINGS flag to ignore deprecation, if so, where can I include this flag so it ignores the warnings?
In the case of the MSVC runtime functions, no, there is no risk of compatibility problems if you use deprecated functions like fopen().
The code for fopen() exists in the MSVC runtime library and your application either (a) links with that library statically, or (b) uses a specific version of a DLL. The DLL version used by the app will be the same wherever your app runs, so you don't have to be concerned about Windows 8 not having an appropriate DLL.
The MSDN documentation Security Features in the CRT states:
In this context, "deprecated" just means that a function's use is not recommended; it does not indicate that the function is scheduled to be removed from the CRT.
I have a win32 DLL that includes Windows.h and makes use of the windows API. I want to load this DLL into an application that uses MFC.
Will this cause any memory leaks or strange behavior? or is it safe?
MFC is implemented on top of the Windows API. An MFC application can call into the Windows API without any restrictions. It is, however, not possible (nor required) to #include <windows.h> prior to including afxwin.h. If you do, afxv_w32.h will error out with the following message:
WINDOWS.H already included. MFC apps must not #include <windows.h>
The reason behind this is not a compatibility issue. It is due to the fact, that MFC has to set up several preprocessor symbols to control certain aspects of the compilation process. Those symbols must be defined prior to including windows.h (which afxv_w32.h eventually does include).
Likewise, there are no problems associated with linking against a .dll that is implemented using the Windows API. In fact, a default MFC application already links against a number of Windows API libraries, like kernel32.dll and user32.dll. If the header file declaring the .dll exports includes windows.h you need to make sure that it is included after afxwin.h. Otherwise the preprocessor will error out with the message quoted above.
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 ^_^