Required sdk

Question

Good morning,

 

In visual studio enterprise 2019, I have three "command line" projects in C++. Two of the projects are Windows services and only one a utility which could be launched from command line. For building them I'm using SDK 10.0.19041.0. 

I create the binary the way I think it's in "statically linked" mode. In Project properties -> C/C++ -> Code generation the parameter "Biblioteca en tiempo de ejecución" is set it to "Multiproceso /MT". It's set that way for avoid installing Visual studio redistributables.

It seems to work properly in versions from Windows 2008R2 to Windows 2025.

It's working but I was wondering if perhaps for running these two services I generate, and the command line tool (they are 3 different projects templated as console application c++) it should better to use a different SDK version or even use different executables done with different SDK for each or at least some Windows OS. Perhaps a dedicated build with a concrete SDK for 2025 or similar.

Which SDK should I use for which Windows version?. I have not been able to find a good documentation about this match of SDK <->Target windows os.

 

Best regards,

Answer 1

Hello @Egoitz Aurrekoetxea ,

Thank you for sharing the details of your project configuration.

Regarding your question about matching SDKs to specific Windows versions, Microsoft Windows SDKs are cumulative, meaning you typically do not need to hunt for an SDK that matches a specific OS. A common approach involves using a recent SDK and setting the _WIN32_WINNT and WINVER macros to your oldest intended platform. You can read more about this mechanism in the Update WINVER and _WIN32_WINNT documentation.

Furthermore, using the /MT flag is a way to statically link the C runtime and avoid installing Visual C++ Redistributables. As outlined in the /MD, /MT, /LD compiler options guide, this is a valid configuration for standalone utilities. However, it might be worth keeping in mind that you would need to manually recompile and redeploy your services if future security updates for the C runtime library are released.

Consequently, building separate executables for different operating systems is generally not required. The Win32 API natively preserves backward compatibility, so a single binary targeting Windows Server 2008 R2 APIs could normally run on Windows Server 2025, provided it does not call newly introduced APIs.

Additionally, if supporting an older system like Windows Server 2008 R2 remains a priority, keeping your current Visual Studio 2019 toolset (v142) might be advisable. Newer Visual Studio iterations slowly phase out structural support for older OS environments, making your current setup a reasonable baseline to stay with.

I hope this perspective, alongside the official reference materials, provides a helpful viewpoint for organizing your builds. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Answer 2

AFAIK, the Windows SDK version you build with does not need to exactly match the Windows version where the application will run. In most cases, you should use the newest SDK supported by your Visual Studio version unless you specifically need compatibility with very old APIs or very old operating systems.

Using SDK 10.0.19041.0 is a reasonable choice for applications that must run from Windows Server 2008 R2 up through current Windows Server releases. The SDK mainly provides headers, libraries, and API definitions at compile time. Runtime compatibility is determined more by which APIs your application actually calls than by the SDK version itself.

Your use of /MT statically links the Microsoft C runtime into the executable, which avoids requiring the Visual C++ Redistributable package on target systems. That is valid for command-line tools and Windows services. The tradeoff is larger executable size and needing to rebuild if runtime security fixes are released, but operationally it is common for standalone utilities and services.

The important compatibility setting is actually the platform toolset and the minimum Windows version you target. Visual Studio 2019 normally uses toolset v142. That toolset tends to work across Windows versions.

For Windows Server 2008 R2 specifically, you should be careful not to use APIs introduced in newer Windows versions unless you dynamically check for them. Windows 2008 R2 corresponds roughly to Windows 7-era APIs. If your code only uses common Win32 functionality, you are usually fine even with a newer SDK.

You generally do not need separate builds for Windows Server 2012, 2016, 2019, 2022, and 2025. One binary can normally run on all of them if you avoid unsupported APIs.

Windows Server 2008 R2 is the problematic target because it is extremely old and out of support. If you truly must support it, then:

• Use the v142 toolset.
• Keep SDK 10.0.19041.0 or even 10.0.17763.0.
• Set the minimum supported OS appropriately in your project or manifests.
• Avoid APIs added after Windows 7 / Server 2008 R2.
• Test directly on that OS.

You do not gain much by creating a “Windows Server 2025 build” unless you want to use APIs or features that only exist there. Newer Windows versions are intentionally backward-compatible with applications built using older SDKs.

Generally, the following should be sufficient for WS compatibility:

• Visual Studio 2019
• Toolset v142
• SDK 10.0.19041.0
• Single x64 build
• /MT for static runtime

Note that newer versions of the Visual C++ toolset no longer support Windows 7 / Server 2008 R2. Even if your application compiles, some newer runtime internals may not behave correctly forever on those old systems. If 2008 R2 support is business-critical, keep a dedicated test environment and avoid upgrading toolsets aggressively.

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin