I am running producer consumer problem( using windows thread ).It compiling successfully but on running it showing following error
The procedure entry point InitializeConditionVariable could not located in the dynamic library Kernel32.dll.
can u tell what would be reason
That's an API function that is only available in Vista and up. I would guess that you are running this code on XP.
To avoid accidentally using API functions that are only available in later versions of Windows, you'll want to define the _WIN32_WINNT macro:
#define _WIN32_WINNT 0x502 // Designed to run on Windows XP SP2 and up
#include <windows.h>
If you don't set it then it typically defaults to 0x600 on later versions of the Windows SDK, selecting Vista as the target operating system. Btw, you'll probably have to give up on condition variables. There isn't enough detail in your question to offer a suitable replacement. Code that uses mutexes instead shouldn't be hard to find.
InitializeConditionVariable and the related condition-variable APIs are only available on Windows Vista onwards. You could use Boost.Thread to provide a condition variable implementation which works on Windows XP. I wrote an article on my blog about how to use that for a producer/consumer queue.
Related
Background
I'm writing a C++ app using VS2015 on WIN 7. This app will run on all windows OS greater than equal to XP.
Through out my code, I use lots of WINAPI calls.
I wish to prevent, at compile time, the usage of API that are not defined in win XP.
Motivation
At some point, I used function RegDeleteKeyEx function without noticing that this API is NOT available in win XP
Solution
So, I follow this post: Modifying WINVER and _WIN32_WINNT and declared this:
#include <winsdkver.h>
#define _WIN32_WINNT 0x0501
#define WINVER 0x0501
in file targetver.h
I was hoping that after this fix, when I compile my project that contains usage of RegDeleteKeyEx function, I will get compilation error.
But I didn't.
QA
I tried looking for other, new WINAPI in vista, and just added a call to GetTickCount64 function. when compiling, I got this:
error C3861: 'GetTickCount64': identifier not found
which confirmed my solution.
Question
I've noticed that for RegDeleteKeyEx function, the Minimum supported client is Windows Vista, Windows XP Professional x64 Edition
However, my app will run in XP 32 as well.
How may I enforce compilation error in such use case?
Unfortunately, as I can see in "winreg.h", there is no conditional compilation of RegDeleteKeyEx (other than RegDeleteKey). So there is no (easy) way to trigger compilation error in this case.
The only option (for the regular statical DLL loading) would be to create your own wrapper over winreg.h (or windows.h) which would handle the version check (and e.g. #undef RegDeleteKeyEx in the corresponding cases).
Sometimes this kind of stuff is also solved using dynamic DLL loading (LoadLibrary / GetProcAdress) where you can check the presence of the particular function on the current version of Windows, where the application runs (so you could for example create a RegDeleteKey wrapper which would call RegDeleteKeyEx on the windows versions which support it and RegDeleteKey if run under versions which don't). The check of the feature presence is then done at runtime, so the program can run on any version of system and still use the newest features on the versions which support them (and doesn't have DLL "unresolved import" loading issues on the lower versions which do not support the feature).
I'm writing a program that needs to run across Windows 7, 8.x and 10. The program has a one (relatively minor) feature that relies on Windows APIs that are only available on Windows 10. This feature will obviously not work on Win7, and before calling these APIs I make sure that the current OS is Windows 10.
In order to use these APIs I'm forced to configure my VS2015 project to "Consume Windows Runtime Extension" (/ZW) and to set "Target Platform Version" to 10.0.10586.0.
However, this causes a problem when I try to run the app on Windows 7. I get an error dialog saying "The program can't start because api-ms-win-core-winrt-string-l1-1-0.dll is missing from your computer". I tried to installed VS2015 redistributable package on the Win7 machine, but that did not solve the problem.
Any idea on how to get this to run on Win7? I really prefer not to change all my code to dynamically load all Windows 10 functions.
The program is written in C++, and the Windows API I use are from Windows.Devices.WifiDirect namespace.
I ended up solving this problem by moving all my Win10-only API calls into a proxy DLL, which is compiled with /ZW. I then removed the /ZW switch from the main program, which then allowed it to run under Windows 7. The proxy DLL is only loaded (using LoadLibrary() call) when my program is running on a Windows 10 machine.
This solved the problem. I did have to write a few proxy functions for the DLL, but it was far lass overhead than doing that for all the Win10-only API calls.
I would still like to hear better solutions, if there are any.
It is possible to access Windows 10 APIs without using /ZW switch by using the "ABI" API. More details here:
https://blogs.msdn.microsoft.com/oldnewthing/20160629-00/?p=93775
You'll have to use APIs like "RoGetActivationFactory" and "WindowsCreateString" through LoadLibrary/GetProcAddress, since you can't link to them as they're not available on Windows 7. Don't forget to define your WINVER and _WIN32_WINNT to Windows 7:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745(v=vs.85).aspx
That will allow you to not link to any APIs not available on Windows 7.
I am trying to create an application which uses a dll for pipe communication and run into this error, when I started using this function GetOverlappedResultEx. Whenever I run the executable that uses my dll, I get this error message ...Does anyone know what is the meaning of it? I am building 64 bit dlls! I am using C++ on visual studio 2012. Do I need to install any service pack?
Edit: I am using Windows 7 Computer
The message means that some part of the code depends on GetOverlappedResultEx, a function it expects exists in the system DLL kernel32.dll. (The 32 in kernel32.dll refers to the 32-bit version of the Windows API, which is the same even for 64-bit programs.)
To figure out what's going on, search MSDN for the function. On that page, you can see that GetOverlappedResultEx should indeed come from kernel32.dll, but it wasn't added to the API before Windows 8. You're likely trying to run the program on an older version of Windows.
Your options are to run the program on a newer version of Windows or to modify the code to not rely on this particular function.
If you are targeting Windows 7 as your minimum, then you should set _WIN32_WINNT to 0x0601 as a Preprocessor Define. The Windows 8 SDK or later defaults to the 'newest' rather than the 'oldest' setting for this primary header control which with VS 2012 is 0x0602 (Windows 8). A number of API headers rely on this define to control platform-specific behavior to support 'down-level' versions of the OS. See Using Windows Headers.
GetOverlappedResultEx is only supported on Windows 8 or later. If you want to be compatible with Windows 7, then you need to stick with GetOverlappedResult.
For Windows 8 Store, Windows phone 8, and universal Windows apps you need to use GetOverlappedResultEx. Therefore, if you are writing code that is being reused for both these platforms, you go back to our friend _WIN32_WINNT. For example, in WaveBankReader.cpp in DirectX Tool Kit I used the following to support Windows Vista or later for Windows desktop, Windows 8 Store, Windows phone 8, and universal Windows apps:
#if (_WIN32_WINNT >= _WIN32_WINNT_WIN8)
BOOL result = GetOverlappedResultEx( hFile.get(), &request, &bytes, INFINITE, FALSE );
#else
if ( wait )
(void)WaitForSingleObject( m_event.get(), INFINITE );
BOOL result = GetOverlappedResult( hFile.get(), &request, &bytes, FALSE );
#endif
I have the explicit call to WaitForSingleObject in the "down-level" case based on a variable that is set if the previous ReadFile failed with an ERROR_IO_PENDING. GetOverlappedResultEx handles this case.
See Dual-use Coding Techniques
I'm modifying a large C++ project whose first release was Windows 7-only to work on Vista and XP.
The main work will be to change the W7 API calls to use GetProcAddress at runtime (to avoid static linking with methods that are not available on the other platforms), and so I'm wondering if there are any tools that can help identify which calls need to be changed -- hopefully by examining the C++ code itself.
Failing that, would it be best to try building the project against an older Windows SDK? -- for example: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=6510
#define WINVER 0x501
Now everything that is newer than Windows XP will cause a compilation error.
Replace everything that causes an error until none remain.
If you have some sed-fu, you can probably write a filter that directly finds all #if WINVER > 0x501 blocks in the windows headers, but for me, this is a bit out of my scope :-)
I would open your binaries using the depends.exe tool (either from your VS install or from here) under WinXP and Vista to see which functions can't be statically linked under these OSes. These would be the functions which your binary is using, but which are missing in older releases of the OS. You'll have to deal with them somehow: either implement them by yourself, replace them with something else or disable some of the functionality of your app.
I'm using Qt Creator 2.0.1 based on Qt 4.7.0 (32 bit). The OS is Windows 7 Ultimate (32 bit).
I'd like to restart Windows using the following function call:
ExitWindowsEx(EWX_REBOOT, SHTDN_REASON_MAJOR_SYSTEM |
SHTDN_REASON_MINOR_NETWORK_CONNECTIVITY);
I've added windows.h and reason.h in the source code and added libuser32 in the LIBS section of *.pro file.
After compiling the code, Qt Creator issues an error saying SHTDN_REASON_MAJOR_SYSTEM and SHTDN_REASON_MINOR_NETWORK_CONNECTIVITY are not define in the scope.
I looked into reason.h file that comes with mingw. I found the #defines are inside an #if:
#if (_WIN32_WINNT >= 0x0501)
I looked into the value of _WIN32_WINNT which appears to be 1024 (0x400).
I understand this represents some kind of version number and those #defines should be compiled after a specific version. But why _WIN32_WINNT is so low on Windows 7? How can I use those #defines? I do not want to put direct values instead of SHTDN_REASON_MAJOR_SYSTEM and SHTDN_REASON_MINOR_NETWORK_CONNECTIVITY.
The value of _WIN32_WINNT indicates the version of the Win32 API you're targeting at runtime. It has nothing to do with the version of the OS you happen to be using while doing the build.
If you set this to a higher value before including the API header files more API functions and definitions will become available, but making use of those functions may cause your application to refuse to run on previous versions of Windows. Typically, you want to use the lowest value that you can get away with.
It's safe to use #define values from higher API versions as long as you check for errors from Win32 functions indicating that the value is not supported. Using Win32 functions, however, will cause your application to fail on startup with errors like "DLL import not found".
When you use the Windows SDK, you can specify which versions of Windows your code can run on. The preprocessor macros WINVER and _WIN32_WINNT specify the minimum operating system version your code supports.
When you upgrade an older project, you may need to update your WINVER or _WIN32_WINNT macros. If they're assigned values for an unsupported version of Windows, you may see compilation errors related to these macros.
from:https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=vs-2019