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.
Related
I have an application which supports Windows version from XP.
Recently I have made changes to the application by including <regex>.
Does this application still work in Windows XP machine?
P.S.: I did configure my application to use MFC in a static library.
If this doesn't work what should I install on XP machine to make this work?
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 have a small console based, standards compliant, C++ program that I developed in Visual Studio on Windows. Since it is in standard C++, is all I need to do is compile it for OSX? or am I being overly optimistic?
I am looking for the easiest and most straightforward way to do this. Is it possible to do from Visual Studio 2012 Professional? If necessary I have access to a Mac. However, since my dev platform is Windows, it would be nice if I could do it from here.
I'm not experienced with mac development at all. When you compile an application for OSX, what do you get instead of a .exe?
If you don't mind installing MinGW or Cygwin to your Windows machine, you can build a Windows to OS X cross-toolchain as per the instructions here: https://github.com/Tatsh/xchain
I would get an OSX system (a VM is fine), install XCode and then compile your code using that. Should be trivial if your C++ code is written in a cross platform way.
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?
Is there any way I can cross-compile C/C++ code for Windows (XP, Vista, Win7), ideally in 64-bit as well as 32-bit (for Vista and Win7), from a Solaris or OpenSolaris setup? My codebase is already cross-platform, I would like to cross-compile it (generate windows DLLs and EXEs) from Solaris or Linux as part of an automated process.
I would like to use the GCC suite, and would rather not need to use the Cygwin DLLs, if possible.
If it is possible, which tools would I need in my Solaris environment? How would I go about compiling/linking an entire project?
If this is not possible in Solaris, how should I proceed from Linux, considering I would like 32- and 64-bit binaries for all of the versions of Windows I have mentioned?
Thanks in advance for any help!
I'm not sure if you want cross-compilation (creation of Windows EXE files on the the Solaris box) or cross-platform (code that compile on Solaris or Windows). The latter is easier, and to do it you should start by installing the MinGW version of the GCC compiler on your Windows box.
howto: Creating a cross Win32 and Win64 compiler
There is no 64-bit cross-compiler for Windows, you have to compile it using MSVC compiler :(
Er, why not just automate your build process by performing a remote build process? It's what we do - we have CruiseControl.NET on a Windows box which performs remote builds on Linux and Solaris via sshexec. I'm sure it would be possible the other way round.