VC++ "_app" library dependencies

1. Retail VC++ libraries (https://aka.ms/vs/17/release/vc_redist.x64.exe) are for non-UWP, legacy software
2. AppX VC++ UWP (Microsoft.VCLibs.140.00.UWPDesktop) libraries package is located in "Windows\Program Files\WindowsApps" and is for non-system UWP apps that are also found in "Windows\Program Files\WindowsApps"
3. AppX VC++ (Microsoft.VCLibs.140.00) libraries package is located in "Windows\Program Files\WindowsApps" and is for system UWP apps that are found in "Windows\SystemApps" , where each VC++ library file always ends in "_app" (such as concrt140_app.dll)

Questions:
- Do any packages other than the ones found in "Windows\SystemApps" use VC++ library files that end in "_app" ?
- VC++ "_app" library files for packages in "Windows\SystemApps" are very out-dated. Is it possible that the out-dated "_app" library files "Windows\SystemApps" act as links to newer "_app" library files found in "Windows\Program Files\WindowsApps" or that Windows simply ignores the out-dated "_app" library files and uses newer ones if they are present in "Windows\Program Files\WindowsApps" ?

I don't have a way to figure it out for now, but with Process Monitor or System Informer or any other advanced task manager it should be possibly to inspect handles and threads of executable images found in "Windows\SystemApps" directory to see if they ignore the old out-dated "_app" files packed with them and use newer "_app" library files found in "Windows\Program Files\WindowsApps"
 
Win32 apps use the normal Windows VC++ runtimes.
UWP apps use UWP VC++ runtimes.

Those are two distinct programming frameworks, and they don't borrow each other's DLL's. Unlike the VC++ model, UWP doesn't consider any two framework packages as superseded if the major & minor versions are the same. A package is replaced by a newer version if only the build number changes, outside of the major/minor.

For example:
Microsoft .NET Runtime Package 1.7 & Runtime Package 2.2 are installed as side-by-side libraries.​
But Runtime Package 2.2.27328.0 would be replaced by 2.2.30000.0​

Both Microsoft.VCLibs & Microsoft.VCLibs.UWPDesktop haven't moved from the 140.0 major & minor numbers, but do increment in their actual build numbers. Newer instances of these UWP packages would completely replace the older instances when installed.

There is no such concept as "cleaning up old UWP libraries". Frameworks are either installed side-by-side (different minor number), or completely replaced (same major/minor, different build).

If you don't integrate newer UWP packages into your image, then WU does the task of silently updating them 10-20 min. after installation.
 
Can you actually find any Apps that use "_app.dll" VC++ libraries? The only ones that use them that I can find are the ones from "Windows\SystemApps" , but System Apps come pre-packaged with those (out-dated) libraries in their respective directories and no handles are linked to "_app.dll" VC++ libraries located in "Windows\Program Files\WindowsApps\Microsoft.VCLibs.140.00" . That makes it a useless package not used for anything.

You can replace the out-dated ones in "Windows\SystemApps" with newer ones manually, but that of course breaks file and component store integrity.
 
Back
Top