I use Visual Studio 2008 and work pretty exclusively with plain old C++. At present I'm using the Windows SDK 7.0, but I see that the VS2010 compilers are available with 7.1. I don't use C# or .NET, or even MFC or ATL, but I do use STL extensively.
If I switch my VS2008 to use 7.1, will I need to distribute VS2010 runtimes instead? Are there any other practical benefits or detriments to upgrading?
will I need to distribute VS2010 runtimes instead
No, Windows SDK does not upgrade your VC runtime. Only SDK headers, libs and tools are updated.
Are there any other practical benefits or detriments to upgrading?
You need to compare what features in the SDK you are using in your project and check what is new and see where they overlaps. Most of the change are probably of no use to you so it does not make sense to list them all.
Related
Is there any compatibility matrix as to what Visual Studio Versions (Say, ranging 2005 - 2017) are compatible with which Windows SDK Versions?
Should any Windows SDK be fully compatible with "any" C++ compiler, or are the different Windows SDK versions bound to certain compiler versions?
For example(!), we have a legacy C++ application that is still compiled with VS2005. We found that we'd like to use GetDpiForMonitor from this application. But to use this function, would require to use the headers+libs from at least an SDK supporting Windows 8.1 (e.g. the 8.1 SDK headers at C:\Program Files (x86)\Windows Kits\8.1\Include\um)
Generally, should a developer expect to be able to switch to a newer Windows SDK version without upgrading his compiler / Visual Studio?
Please refrain from suggesting to upgrade VS: This question tries to establish what you should do when upgrading VS is not an option for now, but you want to use stuff from (and depend on) functionality only available in newer Windows (SDK) versions.
concerning the "compatibility matrix": I don't think anybody made the effort to up to create one, also I'm not sure if this is really needed.
Rule of thumb: those API headers don't change quite often, and when they do, they are usually pretty much backward compatible.
The tricky part may be to teach your older VS to get along with a new SDK, you may need to change the VC+ include/source/lib directories for your solution/project manually.
(if it complies & links in your old VS, you should be fine)
I'm looking at using the TeeChart library for Compact Framework AND Full Framework (3.5) I'd like to know if there are any differences in API to support both platforms from the same source? (my current charting lib, different vendor, is not supported on Win32)
Question for Steema Software: I can't find the teechart.pocket.dll in the evaluation download? are you dropping CFNet support? where to get a cf eval dll?
No API differences between both versions, except for those specific to each platform.
Compact Framework and ReportingServices assemblies are currently not being included in the production version of TeeChart unless future customer demand signals its need. That's because CF doesn't work with .NET Framework 4.0 and 4.5 which means it doesn't compile with Visual Studio 2010 and Visual Studio 2012. In the meantime we are prepared to work with any customer that demands the assemblies on a case by case basis to certify its compatibility and featureset. In the meantime, you can use the assemblies included with previous versions.
To what extent is it possible and legal to developer WinRT applications with VS2010 Pro?
On the one side, I think it should be perfectly possible and legal to create an HTML5/CSS/JavaScript WinRT App with VS2010 Pro since you can probably do so using Win 8 Notepad. On the other side, I think it might be difficult and possibly illegal to create an C# WinRT App via VS2010 Pro since doing so might require the user to circumvent intentional limitations of the VS2010 Pro software.
In the old days, the user just bought a stand alone compiler and she/he was free to link it against whatever libraries she/he choose. In this way, she/he didn't have to upgrade her/his compiler anytime she wanted a newer version of MFC or *.NET. These days, the IDE seems to be married to the compiler so I'm not sure if the user is allowed to use older IDEs (such as VS2010) to link against newer libraries like those offered in WinRT
See here.
You can use the Windows SDK, along with your chosen development
environment, to write Windows Store apps (only on Windows 8)...
So it's clearly legal. I haven't tested it, but I'm going to guess that you can probably do the code side of things in VS 2010, but VS 2010 isn't setup to do Windows Store UI so xaml, html5 etc probably won't work.
It's probably much easier to simply use Visual Studio 2012 express.
To what extent is it possible and legal to developer WinRT applications with VS2010 Pro?
It is not (directly). The APIs and the packaging tools will not be available in VS 2010.
While you could potentially do this yourself, it seems far simpler to just install Visual Studio 2012 Express for Windows 8 and use it.
These days, the IDE seems to be married to the compiler so I'm not sure if the user is allowed to use older IDEs (such as VS2010) to link against newer libraries like those offered in WinRT
It's more than just newer libraries - there's an entire new runtime, and the language needed changing in order to work with it.
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.
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.