search

abbodi1406 / vcredist

AIO Repack for latest Microsoft Visual C++ Redistributable Runtimes
The Unlicense
5.77k stars 330 forks source link

separate legacy VC(2002/2003)/VB runtimes #61

Closed yumeyao closed 1 year ago

yumeyao commented 1 year ago

Years back I was one of the main contributors on RyanVM.net and co-worked with @ricktendo64 on both ryanvm.net and wincert.net.

I would suggest that we need to separate VC2002/2003/VB in a flavor that the user can selectively install parts of them. specifically, I want to filter VB out.

The reason is, while VC runtimes are keeping good backward compatibility through VC6 to latest 2015-2002(ucrt) within each generation, VB runtimes didn't maintain such good backward compatibility. It's not because VB runtimes are rarely used, it's because when they're needed and used, the latest versions (with security fix or other fixes) of a random VB runtime (*.ocx) sometime just don't work on an ancient executable (*.exe) built upon old VB runtime versions. So typically, those old ancient executables relying on VB runtimes tend to include the VB runtime files they need upon distribution.

Therefore, separating legacy VC and legacy VB runtimes into 2 groups, and adding 2 new switches to install them respectively, while keeping the old /aiE switch to install both, is a more preferable way, at lease to me.

Thanks for consideration.

abbodi1406 commented 1 year ago

Hi @yumeyao, i'm aware of your great contributions, good to see you :)

i will see if can dig up and split vbcrun.wxs (msi template)

yumeyao commented 1 year ago

yes, I just realized there is an extra challenge that is separating them while holding them in one single msi file, otherwise there may be some problems or ugly workarounds when upgrading existing installation. I can still remember the Feature table and FeatureComponents table blah blah, but I can barely remember how to process command line options to set an property and enable/disable features.

Thank all you guys for keeping such repacking going, I really don't like M$ official installers, they're just bloated.

abbodi1406 commented 1 year ago

Well, to keep things too simple, maybe i can create two new separate msi files for each (keeping the combined one too) and based on installation switches, i can choose the appropiate one