C++/DX Runtimes idea

[swight]

I know ahead of time this probably won't be done anytime soon just want to get the idea out there before I forget it.

When you install windows software on your computer it frequently loves to install some version or another of c++ runtime or directx regardless of if you have it or not. in the end you frequently end up with several versions eating up space on your hard drive or a waste of time going through an installer that effectively does nothing. I was wondering if it might be possible to have a version of these on reactos that combines all the current versions into one efficiently so you don't have a bunch of duplicated dlls wasting space. along with this making reactos ignore the installers for these faking a success maybe with a pop up with a message explaining what happened and an option to let the program go ahead. There may be some other runtimes that would benefit from similar treatment these just seem among the most common offenders.

[dizt3mp3r]

When ReactOS allows these MS runtimes/frameworks to operate on the o/s then it will be exactly the same situation as Windows - These are separate components being installed on yet another operating system. It is doubtful that the ReactOS team will feeel the need to rewrite these tools as well as completing the o/s. Someone, somewhere, in time might write a tool that helps to manage these a little better but I doubt it will be part of the o/s team that does it unless they recognise a powerful need for it. If Windows does not have it then I suggest it will not be a priority of the developers to write it as they'll have other tasks.

[PurpleGurl]

Yes, while this seems like a good idea, it would likely break things (though not by much in some cases since things are already broken) and require a lot of effort that our team really doesn't have time for. The team is just trying to get it to work at this point, and extra frills won't be added unless they really want to do them, they have a good idea on how to do them, and it somehow makes their coding, reverse engineering, or testing easier. For instance, BTRFS adds more ways to test the file system infrastructure and look for shortcomings. Some of the console stuff added, while more arcane parts of Windows 2k, apparently added more ways to test or troubleshoot.

So maybe you could find an outside team to work on this, like maybe some unified 3rd party (and Microsoft-like) library set that passes itself off as every version used and has all the necessary shims, etc. But I think really, more effort should be spent getting the authors to do better runtime analysis/testing to where if the current configuration can make it work, nothing has to be changed or added in terms of runtimes. Microsoft could be encouraged to fix this in their runtime installers and their apps that make use of them. It is not directly an OS problem, but industry-wide laziness that causes headaches for so many and causes so much bloat or incompatibilities for end users to clean.

However, even if you could pull this off, an issue I see would be compatibility. The apps don't care if something compatible is installed already or not. Microsoft could theoretically fix this by changing the exit codes of their installers, maybe also asking if you want to run them if something that can be used is already installed (except in unattended mode), and 3rd party vendors could try detection to see if what is needed is already there (or superceded). I mean, if a Microsoft "library installer" detects something better is installed, it bails with an error code, and the app that launched the library installer assumes any return code other than 0 is an unrecoverable, critical error, and thus it aborts too. So I'm not sure how this could be remedied at the OS level or by writing a better runtime library set, since the app brings its own copy of the runtimes, regardless of what is already installed.

The only OS-fix for this that comes to mind could be to intercept the runtime installers and launch its own smart installer (and/or 3rd party reimplementation), then return success to the underlying apps in most circumstances.

The problem here seems to be industry-wide. Microsoft might not have enough return codes on their runtime installers, but even if they do, the apps that use them might not even examine them to see if they can be worked around. And it seems that the app installers could be more intelligent and do .net analysis, etc., and maybe prompt the user as to what to do. Like if it asks, ".NET 4.5 is required and .NET 5.x is installed, would you like to allow your version to handle this, or still install the recommended version?" In this case, I think social activists could accomplish more than us, since they could help get the industry to reign in this insanity.

[swight]

The OS intercept idea is pretty much what I originally suggested. I was slightly hoping that the all in one type library might already exist somewhere though most of what I found in my searches basically just take all the existing installers together with no space optimization that they care to mention.

Found this kinda related article https://lezhang.net/2015/05/. basically details a bug that was in older versions of Visual Studio. the default installer that was included in programs created with it would reinstall the c++ library needlessly in a real buggy way. definitely a type of bug that would slip under a lot of developers notice.

Social activism is an interesting answer(though not something I am personally suited for) but the question then remains what about all the older software. For many products the original creator is no longer around or has zero interest in updating older programs. So it may be beneficial to have a system in place that says hey older program behave yourself.

[PurpleGurl]

Yeah, you are right. Even if we get the industry to clean this up and actually examine what is installed, there is still a lot of good discontinued or otherwise older software, and some sort of workaround could still be beneficial.

I love how thorough most of the codec sets are, for instance. When you install them, they analyze to see if there are problems, conflicting codecs, invalid or missing registry keys, accidental muting, etc. So you get prompts asking if you want to remove parts of other codec packs, remove leftover registry entries, and other recommended fixes. So why can't all the runtime library installers do this sort of thing?