First I installed PSDK Windows Server 2003 R2 on my x86 machine, there were MFC header files out there. I tried to compile an example MFC application with cl.exe and I got this error message "winmsg_.h header file could not be opened.". I got "winmsg_.h" file from the International Network and put it into the MFC include files library then I again tried to compile the program and got that target platform option conflicts with IA64 platform specific object file. I think that PSDK Windows Server 2003 R2 does not include lib files for x86 machines!
Please help me to solve this problem or suggest me the PSDK that contains the header and lib files for x86 machines! Thanks!
Download SDK from Microsoft Website. It supports both 32 and 64 bit architectures. I'd suggest you to use a make file instead of barely using CL.exe for compilation. You will have to give proper include files to resolve the issues. Which version of the compiler you're using? How you installed it?
Don't go for a third party provided headers. Use the original ones.
I know this is old and people sometimes become upset when you revive a dead post. That said, Google brought me here, and I'm sure many others will be directed this way. This is what I, and I believe you, was/ were looking for:
http://www.codeproject.com/Articles/30439/How-to-compile-MFC-code-in-Visual-C-Express
ATL/MFC headers are not on Platofrm/Windows SDK. Instead, they are shipped with Visual Studio (except Express versions).
Related
I'm not familiar with this cross-compilation thing, but I do have successfully built wxMSW from Linux before, with the cross-compiler provided by my distro. So, I guess it's okay to say that I have some basic knowledge about cross-compilation. The question is that when cross-compiling, it failed and told me that EventToken.h is missing. According to Eventtoken.h header - Win32 apps | Microsoft Docs, it obviously is one of the header files of Windows' C++ Runtime. I don't have Windows, how and where can I install this header (and very likely some more other headers)? Installing VC++ is obviously not an option, because I don't have Windows at this moment. Thanks in advance. :)
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?
I need to compile a Portable UpnP library (http://pupnp.sourceforge.net/) for Windows Phone 8.1 or 10.
The library can be compiled in x86 Windows 10 and one person (https://github.com/atraczyk/libupnp) has already created the missing the VS 2015 project files for the library. I used this version and changed the project target to ARM and did several other changes like the following.
I have compiled pthread-win32 (https://github.com/GerHobbelt/pthread-win32) against ARM Processor and it was successful.
I have done some changes and tweaks in the library to make it work.
And, I successfully accomplished to compile pthread-win32, ixml and threadutil projects.
However; The actual project, libupnp, didn't compile because of missing iphlpapi library in Windows Phone environment. I searched online and stackoverflow. And I couldn't find any solution to compile the library without iphlpapi or with a replacement of it. I hope you can guide me on how to compile the library.
TL;DR
Is there any way that I can include iphlpapi library to a Windows Phone 8.1 ARM project to compile the Portable UPnP library for Windows Phone 8.1 ARM based device.
Clarification, I am sticking with this version of the UPnP even though I know there are alternatives. Because, other platforms (Android and iOS) are using this library and there is a common C code that we need to use in all platforms. So, changing the library is not an obvious solution.
I can see an ARM lib of the IPHlpApi.Lib on my system at C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\arm\IPHlpApi.Lib. Add this to the linker option of the solution.
I have been working on a VS 2005 project and have successfully generated an exe file which works fine on my system. However when I tried to run it on some other pc it didnt run. It throws up the error message "the system cannot run the specified program". Can someone tell me how to make my code immune to such message i.e. system independent?
platform used: Windows XP, VS 2005
the extension of all my code files is cpp but I know only c and thats what I wrote inside them.
I have seen before exe created on Windows Sp1 not working on SP2 and problems such as that.
This should help you perhaps.
I've seen this when you run on a different version of Windows that doesn't have some DLL you depend on. The easiest thing to do is statically link the C runtime (that's the usual culprit) and use depends.exe to see if there are any others.
You will almost certainly need to create an installer that installs your executable and any non-OS-included DLL's it relies upon. It is not always possible or desirable to statically link all dependencies. You can in many cases simply copy the DLL's to the same folder as the executable.
By default, even the C/C++ standard library is provided by a DLL. While the MSVCRT.DLL used by VC++ 6 is included with the OS since later editions Win95, the MSVCRT required by VS2005 is not included with XP installations (other versions I do not know). The run-time support is included VC redistributes package. You may need to arrange for your installer to include that installation, or you could be more selective is you know your dependencies.
Some Win32 API calls if you are using them are dependent on the OS version (check the documentation), but if you built and rin it on XP, it should normally work of any subsequent version of Windows. You need to define various API version macros if you want to extend support to earlier versions of Windows (which seems unlikley).
You might need to install the VS 2005 redistributables on the other machines, depending on how you have compiled your program.
I have written something that uses the following includes:
#include <math.h>
#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include <commctrl.h>
This code works fine on 2 machines with the Platform SDK installed, but doesn't run (neither debug nor release versions) on clean installs of windows (VMs of course). It dies with the quite familiar:
---------------------------
C:\Documents and Settings\Someone\Desktop\DesktopRearranger.exe
---------------------------
C:\Documents and Settings\Someone\Desktop\DesktopRearranger.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
---------------------------
OK
---------------------------
How can I make it run on clean installs? Which dll is it using which it can't find? My bet is on commctrl, but can someone enlighten me on why it's isn't with every windows?
Further more, if anyone has tips on how to debug such a thing, as my CPP is already rusty, as it seems :)
Edit - What worked for me is downloading the Redistributable for Visual Studio 2008. I don't think it's a good solution - downloading a 2MB file and an install to run a simple 11K tool. I think I'll change the code to use LoadLibrary to get the 2 or 3 functions I need from comctl32.dll. Thanks everyone :)
Use Dependency Walker. Download and install from http://www.dependencywalker.com/ (just unzip to install). Then load up your executable. The tool will highlight which DLL is missing. Then you can find the redistributable pack which you need to ship with your executable.
If you use VS2005, most cases will be covered by http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en which includes everything needed to run EXEs created with VS2005. Using depends.exe you may find a more lightweight solution, though.
Common controls is a red herring. Your problem is that the Visual C++ 8.0 runtime - I assume you're using Visual Studio 2005 - isn't installed. Either statically link to the C/C++ runtime library, or distribute the runtime DLL.
You will have this problem with any C or C++ program that uses the DLL. You could get away with it in VS 6.0 as msvcrt.dll came with the OS from Windows 2000 up, and in VS.NET 2003 as msvcr71.dll came with .NET Framework 1.1. No more. Visual Studio 2005 and later use side-by-side assemblies to prevent DLL Hell, but that means you can't rely even on .NET 2.0 installing the exact version of C runtime that your program's built-in manifest uses. .NET 2.0's mscorwks.dll binds to version 8.0.50608.0 in its manifest; a VS-generated application binds to 8.0.50727.762 as of VS2005 SP1. My recollection is it used some pre-release version in the original (RTM) release of VS2005, which meant you had to deploy a Publisher Policy merge module if you were using the merge modules, to redirect the binding to the version actually in the released C run-time merge module.
See also Redistributing Visual C++ Files on MSDN.
I suspect it is trying to find a version of common controls that isn't installed. You may need a manifest file to map the version of common controls to your target operating system. Also, you may need to make sure you have installed the same VC runtimes that you were linked to.
Chris Jackson blog
EDIT: A little searching and I've confirmed (mostly) that it is the version of your VC++ runtimes that is to blame. You need to distribute the versions that you built with. The platform SDK usually includes a merge module of these for that purpose, but there is often a VCRedist.exe for them as well. Try looking Microsoft's downloads.
KB94885