I'm kind of lost with all these SDK windows versions.
For instance, I installed vs2013 on windows8.1, and I (also) need to link my apps against vs2008 runtime (platform toolset).
Should I install the whole VS2008 too or just the API. In the last case, what SDK do I have to install ?
You are talking about two very distinct things. The Windows SDK only covers the declarations and libraries that you need to make winapi calls. SDK v8.1 is suitable to target any modern Windows version since Vista, you select the Windows version you want to target by setting the _WIN32_WINNT macro. Note that XP requires an older SDK version, v7.1 is the last one that's still suitable and selected by setting the Platform Toolset to v120_xp.
The runtime libraries are a pure implementation detail of Visual Studio C/C++ projects and completely unrelated to the SDK. When you build such a program on VS2013 with the /MD compile option then it will have a dependency on msvcr120.dll, possibly msvcp120.dll and others. These DLLs implement the C runtime library and the C++ standard classes. And possibly MFC, ATL, OpenMP and AMP if you use those libraries.
If you still have a dependency on the VS2008 version of those libraries then you are liable to have a Really Big problem. You can obtain the release versions of those DLLs from the redist installer you can download from Microsoft. Having a dependency on the debug version requires having VS2008 installed on your machine. But having trouble linking the program and misery at runtime is highly indicated, the runtime libraries changed a great deal between VS2008 and VS2013 thanks to the new C++11 language standard. Having more than one CRT in a program is in general liable to cause lots of trouble.
You need to strongly pursue getting the library that still has the VS2008 dependency rebuilt. Contact the owner of the library if necessary to get an update.
Related
We are currently using CUDA on windows which requires MS C++ Build tools installed. With every new version of the CUDA toolkit it happens that newer versions of Visual Studio are not supported. That's why we are using the MS build tools seperately so that the VS version doesn't matter.
Since its hard to guide our developers to install the right CUDA and MSVC version we have packaged it into NUGET packages so that the toolkit (especially NVCC) is in a defined version and location. Additionally we wanted to do this with MSVC but we couldn't find a good solution since the installer obviously does modifications on several places that we don't know.
Is there any good way to get the MSVC tools portable so that we can simply drop it into a folder and put the right pathes?
NVCC doesn't support GCC, otherwise I would have gone with this.
Some libraries are available to download as pre-compiled binaries, usually in specific architecture (x32 or x64) but I have also noticed that some pre-compiled binaries are splitted based on visual studio version, for example: vc17_x64. Let's assume that I use visual studio 2019. Does it mean that I have to use binaries precompiled for vc2019 or build a library from source when apropriate version is not available ? It's not clear for me because some pre-compilied binaries don't contain information about visual studio version.
If a pre-compiled library has Visual Studio version info you should use that version of Visual Studio to work with the library. This is not always the case though, as often enough happens that an older (with respect to VS version) library contains code that is a subset of the newer VS's header and runtime SDK files (.NET, C/C++, Windows SDK, etc). The other way around, when the library is newer can also work but it's far less frequent. You can try, if it doesn't work for your particular library and VS version then you should consider matching versions, rebuilding not always works for the same reasons of code changes.
If a library doesn't contain VS version info then it's reasonable to assume that it's portable/compatible up to operating system (Windows, Linux, etc) and programming language version (C++ 11, C++ 14, C# 7, C# 8, etc). However, VS version comes into play here as well, not every VS runs in every Windows, neither it supports the same runtimes, SDKs, and language(s) version. You should always check the library documentation for recommended working environment, if this info doesn't exist then it's trial and error and/or community consulting.
Considering to develop a desktop application with Qt for Windows. It will be a free download application, but for a commecial SERVICE. (need an account with our commercial service to work).
I think we could use the Qt for Windows from Nokia (LGLP version) because its free app. But the lastest one version of Qt needs a C++ complier from Microsoft.
Which one?
Do I need to pay for an C++ compiler from Microsoft, or do they have a free version to use with Qt?
Reading info docs, googling and we still cann't understand what tools do I need.
If you want to use the Visual Studio compilers, you can download the free Windows SDK. The following link takes you to the SDK for Visual Studio 2008:
Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1
This includes all the C++ compilers and tools you need. (There is a more recent version available, but Visual Studio 2010 is not yet a "level 1 supported" platform for Qt.) We are using this on standalone build machines and it works fine.
Just a personal opinion, but we have found that using anything other than MSVC on Windows (for example, MinGW) causes a lot of problems. It is not that the other toolchains are bad, it is just that they are all treated as second-class citizens. We had lots of problems with third-party libraries not being able to build in MinGW or having nonexistent build instructions and having to do a lot of manual Makefile editing, etc. You are much more likely to have things "just work" if using MSVC.
For the most part (static linking), you cannot mix and match. You need to pick one toolchain and stick with it. If I were starting from scratch, I'd definitely go with MSVC.
Just our experience (we started with MinGW); your mileage may vary.
No, you do not need to pay for anything.
The Microsoft toolchain is available for free as part of the Microsoft Windows Software Development Kit.
Additionally, the following article may also be of interest to you:
Developing Windows Applications in C++: The tools you need
The alternative supported by Qt is MinGW. The runtime libraries are free from copyright, so you can do whatever you want with them.
It is basically the Windows counterpart of the GNU Compiler Collection (GCC) under Unix.
What are the different platforms/languages in which an app can be compiled and run on Windows without any prerequisites? I know of .NET but it requires the specific version of .NET to be present in the Windows installation.
C and C++, but Visual Studio defaults to dynamically linked library. Change the default to static and you will be fine.
That being said, ther are no compilers that come with windows. You must install a compiler to build the a program that will run everywhere after that. There are free version of the compiler in the Platform SDK and in mingw (Cygwin requires a dll).
If you are using Visual C++ as language and development tool, you may switch to Statically bound DLLs, which would produce larger binaries, but would run without any runtime-prerequisites. Visual C++ Runtimes are easily installable, can be distributed, or users may be asked to install them directly. If users are using Windows Update, they would anyhow get the latest VC runtimes.
Can I use new SDK directories that comes with VS2010 for VS2005 ?
I expect you can, but unless you need that specific version the simplest thing to do would be to download the latest Windows SDK instead:
Microsoft Windows SDK for Windows 7 and .NET Framework 4
This is more recent and can (IIRC) automatically integrate into VS2005.
If there is going to be an issue with this or with the VS2010 SDK then it will be because the .lib files are incompatible, e.g. through an object file format change or through a whole-program-optimisation intermediate representation change. However most if not all of the .libs in the SDK will just be DLL headers and so this shouldn't be an issue. (In the SDK release notes there is actually a link to a supported hotfix that improves compatibility between VS2005 and VS2008 objects but it sounds like VS2005 SP1 will usually be enough.)
There's a slim chance that the header files might not work (or might assume a different set of default defines) but in general the Windows header files are very careful with defines and version testing that I doubt this would be an issue.
If you're asking if you can use ATL + MFC from the later version then I think this is less clear cut, and may require a recompile of their sources in the older compiler. In that case I think your best option might be to upgrade to VS2010 if that's possible.