Ordinal Not Found ComCtl32.dll C++ on XP - c++

I got this error when c++ program made on win 7 run on xp. Here the error
support.microsoft.com/kb/260283
I got The ordinal 380 could not be located in the dynamic link library (COMCTL32.DLL)
. How can I fix that without
Copy the Comctl32.dll File from Another Computer . How can I add that dll direct in my program. Or another way?
Thanks

You can't add comctl32.dll directly to you program. It is part of operation system. Each version of Windows has own version of this library. The root of you problem is that you using some WinAPI that is not supported by Windows XP.
You can define minimum supported Windows version with WINVER and _WIN32_WINNT macros. After doing that you will see at compile time some errors that show you what api is not supported by minimum requred windows version.
You can read more about minimum version requirement here

Related

Is it not possible to run compiled C++ applications in Windows 95 and Windows NT 4.0?

Whenever I use MinGW to compile C++ applications, they work correctly in modern versions of Microsoft Windows including Windows 2000 and Windows XP.
However, when I attempt to run them on Windows 95 and Windows NT 4.0, I get these errors:
Does that mean that the idea of running compiled C++ applications is fundamentally unsupported in those versions?
Note: I haven't tested Windows 98 and Windows ME yet.
Edit: I've tested Windows 98. The testsortingvisualization runs properly, but the tetrisimplementation displays a blank command prompt and doesn't halt. Both of these programs gave the exact same error given above in Windows 95 and Windows NT 4.0. Keep in mind, Windows 2000 can run both correctly.
Edit:
Microsoft claims some of the functions I used (WriteConsoleOutput, GetAsyncKeyState) have a minimal requirement of Windows 2000. Indeed, it's tested not to work in Windows 98. I haven't figured out a more compatible way to do console output (system 8-bit codepage, 80 columns, 25 rows, 16 colors) or key detection.
The MSVCRT.DLL failure: the DLL is a critical dependency for compiled C++ applications, so it's fundamentally not possible to run any compiled C++ applications on Windows 95 at all.
I haven't found an explanation for the NT 4.0 issue.
When compiling, the compiler doesn't seem to find the correct definitions for a specific Windows version or a specific Internet Explorer version. Why is that?
You need to set defines _WIN32_WINDOWS, _WIN32_WINNT, WINVER and/or _WIN32_IE to the minimum platform you plan to support before including the windows.h header file. Possible values for these definitions can be found in the header w32api.h file.
Taken from here
The MS Visual C++ runtime DLL was not distributed with early versions of Windows, you either statically linked the code to the Microsoft libraries (not possible with MinGW), or you deploy the dependencies with your application.
The redistributable parts of VC++ (in which MSVCRT.DLL is included) are provided in a redistributable package specific to various versions of VC++, MSCVRT.DLL is from VC++ 6.0, and no longer available from from official sources; at your own risk you can get it from here for example.
Your Windows NT 4.0 error is a matter of your code using an API that was not part of the Win32 API when NT 4 was current. You can specify the target Windows version through various macros to restrict the API available to your code. That will then generate a compile time error rather then a runtime error. If that particular call is critical to your application, then it simply cannot be run on WinNT. The documentation for SetCriticalSectionSpinCount() states that the minimum supported system is XP.
With respect to your console I/O issue, MSVCRT.DLL includes Microsoft's conio library (not the same or as extensive as Borland's). MinGW includes conio.h header I think or here. That may provide what you need.
I could write novel here on the actual set of issues, but the bottom line is this:
Newer C/C++ runtime libraries, whether linked statically or dynamically into the target EXE, depend on OS APIs that were not available in Windows 9x. You'll need a set of tools that are still compatible with these a̶n̶c̶i̶e̶n̶t legacy versions of Windows.
You are going to need Visual Studio 2005 or earlier if you want to target Windows 95 and NT 4. As per the Wikipedia page:
Visual Studio 2005, codenamed Whidbey ... was released online in
October 2005 ... ... It is the last
version available for Windows 2000 and also the last version to be
able to target Windows 98, Windows Me and Windows NT 4.0 for C++
applications.
You might be able to do some hybrid thing with MinGW - let it still be the compiler, but link with the older MSVC*.lib files from Visual Studio 2005.
Perhaps you can statically link to the required libraries?

Build my application for a previous Windows platform

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

api-ms-win-core-winrt-string-l1-1-0.dll is missing from your computer

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.

Can mingw be used to compile code for Windows Vista or 7?

I noticed that the included headers for Windows development (such as Windows.h) are essentially for Windows XP and older. I am unable to call functions such as GetTickCount64 because they require Windows Vista or higher. I have Windows 7, but these functions are still absent. I understand that linking to such functions would increase the requirements on my program, and I am OK with that.
Does anyone have any experience with this? Can I use the newer Win32 API with mingw? How?
You can always download the very latest platform SDK and have all you need. Use the header and lib files from the SDK.
Having said that, it may be that all you need to do is to define _WIN32_WINNT and/or WINVER to 0x0600 or higher to gain access to more recent APIs. Off the top of my head, I'm not sure what Windows header file mingw ships with.

Why _WIN32_WINNT == 0x400 in Qt Creator on Windows 7 machine?

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