I've built a C++ application using MSVC 2010, default compile settings (note: Using "Multithreaded" instead of "Multithreaded DLL" to avoid the Microsoft C++ runtime being needed).
I used only the STL and a few, old functions from the Win32 API (Windows.h).
Where will my app run? (98-7?)
Can the be any differences on how my app works on different PCs? As said: It's only a simple console app.
I'd be glad if you could add some additional information if you have it!
The Simplest answer is: Your app will run on Windows versions 5.0 and later - depending on what other APIs YOU use.
the hard limit of 5.0 is introduced in Visual C++ 2008 that stamps a 5 into the minimum OS version field in all the PE headers of all the executable files it produces.
As Windows NT is the only desktop OS with version's 5 and higher, this means that Windows 95, 98, ME cannot run programs made with VS 2008 and VS 2010. Windows 2000 is actually Windows NT 5.0, so it can be targetted. XP is 5.1, Vista 6.0, and in a twist of idiocy, Windows 7 is actually version 6.1 of Windows NT.
Take a look at "Using the Windows Headers" at MSDN. It describes how to configure the windows header files to support various mixtures of OS's.
I think you have to think about it the other way, what versions of Windows do you need to support, and then you can check if the APIs you need are supported or if you have to find workarounds.
After seeing Chris' comment about Win9x no longer being supported I took a look and discovered that the 2010 redist package only supports WinXP and upwards, so you might not be able to compile for Win 2000 either now?
Related
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?
We're moving to Visual Studio 2017 and VS2017 prompts us to retarget the projects for 2 things: Windows SDK Version and Platform Toolset.
Currently our application can run on older Windows versions (at least to Server 2003, possibly older), and we need to retain the same (I know they're not supported anymore, but that's the customer's requirement).
Assuming that our code (which is all C++ in case it makes a difference) does not use any APIs which are only available on newer versions of Windows, will re-targeting to a newer version of the Windows SDK restrict or limit the versions of Windows that our app will run on?
And while on the subject, will re-targeting to a newer version of the Windows SDK have any pros or cons (ex. performance) (again, assuming we don't use any of the new APIs that are only available on newer Windows)?
No, using a newer SDK allows use of newer funcntionality but it does not require doing so. So long as you are careful to only use functionality that is present on the version of windows you are interested in your program will continue to work. You will, however, likely need to install the vs2017 runtime on the client systems.
You will need the VC++ runtime for the development kit that you are building from. Statically linking this library will remove this requirement, as the runtime is embedded in your binary.
I'm stuck in a deployment issue with my Qt 5.4.0 application.
After two days of research, my app really doesn't want to execute on Windows XP !
I have created my deployment folder with windeployqt provided by my Qt installation. When I double-click on *.exe, I have always :
The procedure entry point vsprintf_s could not be located in the dynamic link library msvcrt.dll.
Dependency walker hasn't really helped me and I don't know what I can try now.
Note :
SDK : Qt 5.4.0 (MSVC 2010, 32 Bits)
IDE : QT Creator 3.3.0
Compiler : MinGW 4.9.1 32 Bits
Need to run on : Windows XP Pro SP2 32 Bits
App works like a charm on Windows 7 with same configuration (IDE, compiler, etc.)
While Guilhem G. is correct in the broader sense, it doesn't mean you actually called that function yourself (speaking now to a theoretically other person running into this issue like me, heh). I believe it's a bug with MinGW's XP support; I've seen bug reports of similar issues, including nearly the exact same issue in a much earlier version of Qt that was then fixed. I haven't seen this particular incarnation, which I actually ran into myself. I suppose I should probably submit a bug report!
Anyways, I've fixed it without changing any of the code I've written myself. What I had to do to fix it was twofold:
Switch over to using the msvc2010 compiler, since that set of C++ libraries rather unsurprisingly runs fine on Windows XP (AFAIK they still haven't dropped XP support with the latest version).
Switch over to Qt 5.5 (I'll explain why at the end).
For the compiler, you'll need then either Microsoft Visual Studio 2010 (hence the name), or the older Windows SDK that ships with it; the "Microsoft Windows Software Development Kit for Windows Server 2008 and .NET Framework 3.5" release should do the trick for you if you don't have a Visual Studio 2010 license.
Once one of those is installed, I'd encourage you to install Qt 5.5 as compiled by MSVC2010. You can either start a fresh installer or use the Qt Maintenance Tool which should already be installed.
Once that kit is installed, within your project (selecting "Projects" from the left-side menu) you should be able to go "Add Kit" and select Qt 5.5 msvc2010 32-bit, and if you now recompile and redeploy your application, it should run fine on XP.
Now, why did I insist on you upgrading to Qt 5.5? Well, there's some underlying issues with choosing a working OpenGL renderer on each version of Windows, and Qt 5.5 simplifies that a lot by having it fall back on OpenGL or ANGLE depending on what capabilities are actually detected, plus IIRC some other related fixes. So certainly if you're deploying a QML / Qt Quick 2.0 app across multiple Windows versions like I'm doing, it's worth upgrading to Qt 5.5.
The error was I called "sprintf_s" somewhere in my code (ok for recent windows on my dev machine but not for XP).
If you have the same problem when you search in your code don't use exactly the name of the function in the error message but an expression like *_s.
You probably call a secure API function somewhere !
I haven't been able to find any information on this issue:
I have a C++ Windows Phone 8.1 library project, I would like to convert it into a portable library without having to recreate the project and set all parameters.
I guess it should be possible to do it by editing the vcxproj file, but I don't know how to modify it to make it work.
I meet several issues:
What is the equivalent of Portable Library (C#) for C++?
How to change an existing Windows Phone 8.1 C++ project into this equivalent?
Thanks :)
In general, Windows Phone 8.x doesn't support sharing of binaries with Windows desktop because the import libraries are different between the two (eg, desktop apps link against kernel32.dll but that DLL doesn't exist on Windows Phone). You could share between Windows Phone 8.0 and 8.1 though (provided you only used features available in 8.0).
In theory you might be able to make a static lib that was shared if it didn't depend on any Windows APIs, but it's not really supported. You could try creating a new Static Library project and diffing it against your current project to see what settings have changed.
This changes in Windows 10, where shared binaries are fully supported (obviously you still need ARM vs x86 vs x64 builds depending on CPU architecture).
According to Maximize code reuse between Windows Phone 8 and Windows 8 C++ is not supported as PCL language as this is a .net framework technology.
Note that Portable Class Libraries are a .NET Framework concept and don’t support C++
I also looked into Visual Studio to confirm that and couldn't find a template.
I have a software which has to be deployed in Windows Xp and Windows 7 32 bit versions. Is it Ok to build the software in Win XP for for both platforms?
or
Should I build in Xp for deploying in Xp and build in Win7 for deploying in Win7?
The software is developed in C++
Both operating system will do the job. Just use the proper SDK version and deployment target constants (see targetver.h in C++ project template).
Yes you can build on any (modern) windows version for deployment on any other.
But you probably want to test on both!
If you really have to choose, use XP since Win7 is most likely XP-compatible.
I mean, there are more chances that your program will not run under XP if developped with Win7 than the opposite.
Of course, if you use the correct libs, it should be OK, but what if by mistake you use a Win7 only feature ?
More recent version are expected to be compatible with old versions, not the opposite.