Managing VC++ legacy within your Enterprise
Firstly, let the title of this blog post not fool you. VC++ is very much alive. Take a quick look at the VC++ blog and you will see that there is continuous investment still happening with VC++. However, while we say that, there are a lot of organizations that have a ton of legacy VC++ applications either their teams themselves have written or they have got those as a part of third party solutions running in their environment.
For an IT team that is focused on ensuring a supported and secure solution, detecting such legacy applications is sometimes a fairly big task. This post gets into some of the details around the detection of such legacy VC++ projects and runtime.
Now before we delve into the detection mechanisms, let's first look at what are the things that we should be really concerned with. First of all is the supportability. One basic reason for looking at supportability is that you get technical support for the product. But more importantly, it also helps address security concerns. Security threats for various software components are very common and having a supported version of the product ensures not just the technical support but also an assurance that Microsoft will fix the security vulnerabilities on the supported versions as they arise. This, I have seen is a biggie for most enterprises. Having a vulnerable version of software in your environment can potentially lead to larger attack across your network. Which is why it is absolutely critical to ensure that you are on a supported version. The table below provides details on the supportability of each version of the VC++ runtime. If the applications in your environment are targeting any of the runtimes that are out of support, it is a solid indicator that you need to start either upgrading the application or looking at alternatives.
Before the Visual Studio 2005, VC++ did not provide any redistributable runtime. The runtime dlls were usually shipped along with the application and were usually copied to the application local folders. These dlls were usually available as msvcr70.dll or msvcr71.dll. Do note that up till the VC++ 6.0 time (late 90s), Microsoft also shipped the runtime as msvcrt.dll. However, that dll has since been forked and adopted within the OS. It is supposed to be used by Windows components only. If any applications are using this dll, they are still considered out of support.
| VC++ Runtime Redist Version | Associated Visual Studio version | Mainstream support end date | Extended Support End Date | Comments |
| Microsoft Visual C++ Redistributable for Visual Studio 2017 | Visual Studio 2017 | 4/12/2022 | 4/13/2027 | VC++ 15.0 (vcruntime140) VS2015 & VS2017 use the same VC++ Runtime |
| Microsoft Visual C++ Redistributable Packages for Visual Studio 2015 Update 3 | Visual Studio 2015 | 10/13/2020 | 10/14/2025 | VC++ 14.0 (vcruntime140) VS2015 & VS2017 use the same VC++ Runtime |
| Microsoft Visual C++ Redistributable Packages for Visual Studio 2013 | Visual Studio 2013 | 4/9/2019 | 4/9/2024 | VC++ 12.0 (msvcr120) |
| Multibyte MFC Library for Visual Studio 2013 | Visual Studio 2013 | 4/9/2019 | 4/9/2024 | This add-on for Visual Studio 2013 contains the multibyte character set (MBCS) version of the Microsoft Foundation Class (MFC) Library |
| Visual C++ 2013 Runtime for Sideloaded Windows 8.1 apps. | Visual Studio 2013 | 4/9/2019 | 4/9/2024 | |
| Microsoft Visual C++ Redistributable Packages for Visual Studio 2012 Update 4 | Visual Studio 2012 | 1/9/2018 | 1/10/2023 | VC++ 11.0 (msvcr110) |
| Microsoft Visual C++ 2010 Service Pack 1 Redistributable Package MFC Security Update | Visual Studio 2010 | 7/14/2015 | 7/14/2020 | VC++ 10.0 (msvcr100) |
| Microsoft Visual C++ 2008 Service Pack 1 Redistributable Package MFC Security Update | Visual Studio 2008 | 4/9/2013 | 4/10/2018 | VC++ 9.0 (msvcr90) |
Detecting Legacy Applications with Source Code
The easiest detection techniques are often when you already have access to the source code. Within the source code, you would usually start by looking at the project files. This scan will usually be done on the centralized code repository such as TFS or VSTS.
The VC++ source code can have the following project files –
- .dsp project files: This is a project file for VC++ 6 and earlier. Note that these projects are already out of support and MUST be upgraded ASAP.
- .vcproj project files: These files are used for VC++ 7 to VC++ 9 runtimes. Again, these are out of support starting April 2018 and MUST be upgraded ASAP. The vcproj is an XML file. It can be parsed further to understand the specific runtime version that it is targeting.
| <VisualStudioProjectProjectType="Visual C++"Version="9.00" |
- .vcxproj project files: These files are used for VC++ 10 and above. This one again is an xml file and can be parsed further to understand the specific runtime version being targeted.
| <PlatformToolset>v141</PlatformToolset> |
Detecting Third Party Legacy Applications
Detecting the third party legacy applications is slightly more challenging process. The runtimes usually do not register any link backs to the applications that are using them. Hence, it is a fairly tedious process to understand which applications are using a particular version of the runtime. One of the ways to detect this is to use the DUMPBIN utility.
The DUMPBIN utility ships with Visual Studio and allows you to display information regarding a particular binary file. The DUMPBIN /HEADERS option displays the linker version information. This version can be correlated with the table above to understand the VC++ runtime being used and its supportability status.
Detecting all the legacy VC++ applications is a multi-step process. Following the below steps might help simplify the process for your organization.
- Gather software inventory for VC++ Runtime installations: This would be the first step and probably the easiest as most organizations already maintain an inventory of installed software or can easily prepare an inventory of the installed software with the configuration management tools. If the machines do note have the older runtimes installed, then there are high chances that those machines are still supported. Unless some rogue application is using an older version of runtime before VS 2005.
- Inspect Source codes for available applications: This step ensures that all of the applications written by your development teams are covered and supported.
- Detect third party application dependencies using DUMPBIN: This step is perhaps the most challenging and very difficult to automate with some challenges of its own. But possibly once the first two steps are done, it will help address most of the legacy applications within your environment and you would hopefully have a very small subset to perform a scan using DUMPBIN.
Here are some of the links regarding this topic that will be helpful once you start exploring this more -
DUMPBIN Utility Reference - /en-us/cpp/build/reference/dumpbin-reference
Latest Supported VC++ Runtimes - https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads
CRT Distribution with older version of Visual Studio - https://support.microsoft.com/en-us/help/326922/redistribution-of-the-shared-c-runtime-component-in-visual-c