Use of visual C++ Redistributables and strange performance

[Davidk]

This is a bit of a backgrounder prior to a question about these files and the often remarked strange and sometime un-reproducible crashes reported by VS users.

Those who have used VS for a while - back when installs were done using self-extracting files - will know from seeing the progressive status messages (not done in the new stub technique) that VS uses quite a few Microsoft Visual C++ redistributable files. Generally, 4 or 5 per release version, but they may not be the same ones version to version. You can see the results in the Control panel/program and features list. Here's a screenshot from my win 7 PC which currently has 5 versions of VS installed, from x9 thru 2020, all ultimate:

Visual C++ redistributables are described here https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B and there are several items of note in it:
1. they are community assets: once installed by one program, others can use it. The corollary of that is that uninstall and re-install efforts (eg of VS) do not address these items, so if there's a bug in one, no amount of un/re-installing is going to fix it.
2. In the para on run-time libraries there is an explicit remark that the libraries should be run with the related runtime code to avoid problems.

Elsewhere it is clear that the Visual C++ runtime for windows 7 is different to the run time for windows 10. I can certify that from burnt finger experience. And I have read MS remarks that when OS updates are developed, the Visual C++ libraries are also tested and adapted. ie, changed. Thus a variation in the performance of VS from version to version, updated or not, and under different OS platforms as reported can seem inexplicable. Descriptions of 'flaky' have been made. Maybe, it's not Corel that's doing it, but possibly Microsoft is via variations in the status of the C++ re-distributables in use when the VS version was installed. And AFAIK, once installed on a PC, a redistributable isn't subject to update, even if the parent on the MS servers is.

So, from this
- are there any users who - having other editors - can comment on whether or not they also use Visual C++ redistributable program packages?
- can any user identify an area where redistributables are used that has given problems/ In my case, just selecting the Share panel will not work correctly if the re-distributables are damaged or wrong.

Which leads to a case for Corel to remove their reliance on the MS Visual C++ re-distributables in any effort to fix the flaky problems in VS (silents crashes, anyone??) so often discussed here.

[asik1]

David, this what I have on my W7.
I have only corel X9 and 2018, (or prodad's)
As I examine the list by dates I can add that looks as
- 9.0.30729.6161 relates to Xiaomi
- 12.0.21005.1 , 14.14.26429.4, relates to VMS16P
- 10.0.40219 , 11.0.60610.1, 12.0.40660.0 relates to CrazyTalk Animator
- 12.0.40660.0 relates to VSDC

I have new W10 installation that I'm working on, and till now it got only X9, VMS16P and WMM2.6 video editors. By checking the log I have, I see:
- 11.0.61030.0, 11.0.61030.0 ,11.0.50727.1 relates to X9 (or prodad's)
- 14.0.24215.1, 14.0.24215.1, 9.0.30729, 9.0.30729 relates to VMS16p and prodad's Respeeder

relates = same date.

I hope this will help you any how

[Davidk]

Hi Adi,
Unlike my earlier (Jan) rant about VS and win10 upgrades, This is a hopefully more reasoned approach to re-distributables. VS relies on them. But the conditions I outlined seem to me to underscore the regular complaints in the forum about flaky performance - things that should work, but don't on irregular basis ,- sometimes it works often it doesnt' (ghost problems)

But when issues with VS are discussed, no one mentions the 3rd party parts of the code that are absolutely essential to it doing the things it is supposed to do: the re-distributables. Used by Corel and others basically because they are too lazy to write the complete code themselves. Which would be fine, if that 3rd part did not also have a regular change program for the items concerned.

When I thought about the various statements I've read about re-distributables, it seemed that changes to them is a back-door, unplanned Microsoft-sourced mechanism for issues within VS itself, and it would and does look like corel screwing the pooch in programming. I have often thought that a situation where the complete coding was part of the app would minimise any issues about bugs and ghost problems. At least the developers should be better able to identify what is going wrong. And any PR problems would be theirs clearly, not theirs by proxy.

So many of the forum users mention other NLE's they have, usually to VS disadvantage when addressing an issue, that I wondered just how many of those other NLE's actually use re-distibutables. And if there are many, possibly a case could be made for a future version of VS that did NOT use re-distributables.