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)
Related
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.
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.
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.
I'm using Microsoft Visual Studio 2008 (VC9) to compile a project that has a .dsw file. I already have the 2010 and would prefer to use it, but it seems this dsw was built for 2008.
I'd like to compile and produce a binary that's also compatible with Windows 7. My questions:
if I compile with 2008, will the resulting binary be compatible with Windows 7? I'm not sure at which version of VS did Windows 7 support start.
or does this have nothing to do with the VS version, and is instead related to the Windows SDK? If that's the case, can I use VS2008 with a newer Windows SDK?
Can someone please clarify.
Microsoft has a great backwards compatibility "story", so pretty much anything you compile with any version of Visual Studio/Visual C++ will be compatible with Windows 7. The same may not neccessarily apply in reverse, i.e. if you use an API that's introduced in Windows 7, your application will error when you try to run it on prior versions of Windows.
There are a couple of things to consider though:
If the project was originally written to target Windows XP or earlier, it may fall foul of UAC
There are changes to directory structures (such as %systemdrive%\Documents and Settings becoming %systemdrive%\Users) that are fairly well handled by the link that Windows 7 creates in the root of `%systemdrive%, but you may fall foul of these.
VS2010 includes version 7.0 of the Windows SDK and VS2008 does not. You need Windows SDK v7.0 if you want your app to take advantage of Windows 7 features like jump lists.
Since you already have VS2010 installed, you can just change your include file / lib file paths in VS2008 to point to the Windows SDK v7.0 instead of the default one provided with VS2008. This is assuming you need that version of the SDK.
You do not need the latest Windows SDK if you do not plan to use the latest Windows 7 features like ribbons and jump lists. If you are building your app for the lowest-common-denominator OS (i.e. Windows XP), then really you should be fine using VS 2008 with default settings.
The other concern is, if your code was originally written before Windows Vista came out, it is likely that it will not work properly on Windows 7 unless it is run in Administrator mode, which is something you want to avoid. The only way to fix that is to rewrite much of your code to avoid writing to certain protected directories and avoid using certain APIs that require Administrator privileges.
Windows SDK is well backward compatible. See binary compatibility report between Windows 6.0 and Windows 7.0 on x86_64 generated by the abi-compliance-checker tool for the detailed comparison.
Reports for other Windows versions are here: https://abi-laboratory.pro/index.php?view=windows
We're looking at upgrading from Visual Studio 2005 to Visual Studio 2008. I discovered the following disturbing comment.
From Update WINVER and _WIN32_WINNT:
Beginning with Visual C++ 2008, Visual C++ does not support targeting Windows 95, Windows 98, Windows ME, or Windows NT.
Does this mean that if we rebuild our products with Microsoft Visual C++ 2008, they will stop working on Windows 98 machines? It sounds like it, but I have trouble believing they'd make that big a change.
It's not just about .NET 3.5. It's about the Windows SDK header file macros and definitions pulled in by the mandatory version bump in WINVER. So yes, Colen, Visual C++ 2008 binaries will target the Windows NT APIs only and while occasionally they may work on Windows 98, you should assume that you cannot use Visual Studio 2008 to target Win9x. You will have to use Visual Studio 2005 or older.
Yes, it does mean that: The Windows CreateProcess and LoadLibrary APIs on Windows NT before Windows 2000 and all of Windows (95, 98, and ME) will not load a DLL or EXE file made by Visual Studio 2008 (VS 9), because the PE header in the file has the required OS version field set to 5.
The error message upon attempting to load a Visual Studio 2008-generated EXE file will (be a very unfriendly modal error dialog) actually say "You need to upgrade your operating system to run this program".
I experimented with editing the field to 4. The binary will be loaded, but any use of the Visual Studio 2008 C-runtime will hang or crash the process. There are ways to get Visual Studio 2008 projects to not use their native C-runtimes, but if massive use of C++ features is important to you, this approach is not going to scale past a small application.
Visual Studio 2005 (VS 8) has most of the features of Visual Studio 2008, but it still targets early OS versions which is why at my shop we are sticking with that for the moment.
It's natural that they do not support older versions of their operating system on their newer products. It would cost them more (not just monetary cost, but also making harder or impossible to provide some newer useful features) to make things work with the limitations (and often bugs) of older systems. This happens all the time, and with everyone; new versions of GCC drop support for older less popular architectures; new releases of glibc require a more recent minimum kernel version; and so on.
These operating systems have long been retired; from Microsoft's point of view, nobody should be using them anymore. If you still want to develop for them, you can use older tools of the same vintage.
The 3.5 Framework won't even install on Windows 2000 Server at this point. So I don't believe that they will on 95, 98, or NT either. Microsoft doesn't want the responsibility of supporting these retired operating systems anymore.
It is my understanding that with the most recent KernelEx all MSVC versions targeting XP could potentially work (results depending on how many "newest" functions/features you will then decide to use)
With respect to what the answer could have been in 2008 instead, there were quite a number of patched libraries even back then (check links on the Wayback Machine if they are broken).
While I agree with JesperE, Windows 98 is such a small percentage of users that it makes little sense to target them, unless of course you know a large percentage of your customers are in fact using Windows 98.
In any case, you can in fact target Windows 98 in Visual Studio 2008 (you can't develop on Windows 98). You must, however, target your projects at .NET 2.0 only, you cannot use any 3.0, or 3.5 features.
I'd recommend that you take this as an opportunity to stop supporting Windows 9x. This is a good reason as any to do so. And, at least if you're writing C/C++ code for the Win32 API, life is much easier if you can assume that the target OS is Windows 2000 or later.
According to .NET 3.5 information, Windows 98 is not supported by .NET 3.5, so I would imagine that is what they mean. You can still do .NET 2.0 and lower development, but if you use the 3.5 libraries, Windows 98 is not supported.