Other OSes do the bit about tracking which packages caused library packages to be installed, and will later give you the option to delete the libraries if no other programs use it. But Windows installers do a lot of their own things, rather than in standardized way that can be better tracked
I amazed of how much tolerance people have for clicking next and next in windows.. while I myself just give the computer a list of what I want and takes a coffee break 🤣
Seems eminently sensible, keeping track of who's using what. I'd have thought that that's what the registry is for, and that Windows would prohibit the installation of a library that's already loaded. And to make that workable - in the same way that there's a list of CVTs in the security field (Common Vulnerabilities & Threats) each with a unique number - I'd imagine there would be unique, addressable, immutable, APIs that, obviously, never change, but that accumulate. A new function, approved by David Cutler (🙂), gets a new higher 'CVT'. But apparently not. So sad.
Back when disk space was really limited and really expensive, sharing components (DLLs and other libraries) was about the only way you could get Windows to fit on a machine from the early to mid '90s. These days, a program is almost as likely to install its own personal copy of some library or redistributable, rather than try to share it.
Before Visual Studio 2015 there was no compatibility between msvc runtime. Each new major version of Visual Studio had a new runtime so if you have old software you may need older runtimes.
So true. Underlying implementation details of very basic things (like 'String' objects) changing from one release to the next means runtimes are also changed. Even in low-level things like windows DDK (driver development kits) had structs that changed size from one release to the next. Couldn't just rebuild drivers with newer DDK's things 'evolved' and changed too much.
I'm a software engineer and our company has an old piece of software probably 10 years old or so. (I've only been there about 5 years). It will not run on a computer that doesn't have C++ Dist 2013 and a specific version number of 2013 dist. Luckily that apps "sundown" is next summer (It's a WPF app). We built a better web based app using C# backend and react frontend. We are having some of our bigger customers trying the BETA along side with old version of the new app and fix any bugs they find. Developing software is fun 😁
As a programer, you can choose a static link to this Libraries, but it will blow up your code. I always choose a dynamic link to this libaries, because the DLLs often pre-load in the memory. The DLLs reduce space in physical and virtual memory. A static link to this libraries means, that the code of the library-functions will be included in the code of the program, and that blows the code up (there are many MBs more binary code). The Visual-C++-Runtimes are a part of the windows-system, because many programs need them. This libraries include the MFC, which are classes for programming windows-programs in C++. Even though the MFC is now obsolete, many programs still use it.
Well, it doesn't really blow up your code, it just combines the code sections that would otherwise be in the DLLs with your own code. You end up with a large monolith binary that isn't any bigger than your normal binary plus the DLLs separately. That monolith binary is impervious to other programs or (un)installers messing with the DLLs, it has everything it needs in it, and immutably so. Windows will use its paging system to just load the pages that are actually executed, so it isn't bad on memory either. DLLs were a great idea when harddisk space was at a premium. Not anymore.
@@rashidisw Many C and C++ libraries in Linux based operating systems are LGPL license and that is potentially dangerous to use static linking if source is not provided to customer. Developer can end up in court because license violation.
@@gruntaxeman3740 That mostly non-issue tho. I always stated whether in readme/doc/manual/legal license files , makefile, or in source code itself which libraries I uses, which version of it and where I obtained it from. Its also important to state which Linux distro, and which version updates of it that were used to compile the program. So if customers want to compile my program themselves to verify my works, they need to do the similar hoops I have done to do it, if they haven't done so already. So far there are no issues with customers, If anything most of them happy that I provides that information.
Sory, but i do not agree. My software is, always, complete with anything they need to run. If i could i would deliver even the machine to the users. Before a do the things this way my work were several times affected by others which i did not have any control.
This is where containers can come in handy, but you need to convince loads of software companies and windows app developers to only ever deploy with a packaging scheme based around container images rather than the standard installer files. It's a kind of tough sell for those trying to ensure top performance and memory efficiency, though.
Thanks for explaining this. I didn't understand why so many versions of Visual C++ Runtime are installed. Different programs use different versions of Runtime. As the saying goes "If it ain't broke, don't fix it"
For various technical reasons, versions of the runtimes are not always backwards compatible. Also, if you test your program against one runtime it might not work correctly with a different version of the runtime.
The multiple visual studio c++ versions make me feel safe, secure and stable while using my bad OS, and I like to feel safe, so they stay, no questions asked further.
Even if it makes the size larger, at this point there's way too many versions of the runtime. We REALLY need this feature or for them to stop changing the runtime constantly.
@@KertaDrake They do now. Since 2015, newer versions are backwards compatible all the way to the 2015 version. Too bad that there's also 2005, 2008, 2010, 2012, and 2013, none of which are compatible with each other or any later version.
However there might be things that by necessity has become more strict in newer versions causing an old program to stop function or become unreliable. You never know really where you'll end up.
The problem is that older programs are already dynamically linked to these libraries. Therefore, they are built to use the ABI (application binary interface) of these libraries. Changing the library changes the ABI, even if you use the same functions with the same signatures; because the positions of these functions inside the compiled library change. This means that even if you include all the functions and other symbols from previous libraries to a new and unique library. You will need to recompile ALL and EVERY one program that uses the previous libraries to use the new one. Unfortunately, if you don't want to break all programs that use any version of VC++ runtime you will need to distribute every version of the library. 😓 Another solution is to deprecate everything and encourage people to use the new library (UCRT already does this) but you still can't remove the old libraries without risking backwards compatibility.
@@teknixstuffdoes that mean I can uninstall anything pre-2015? I have 16 different redistributable files and I believe it’s causing me performance issues. I would really appreciate a reply to help me out man thank you ❤
The original definition of DLL hell was different programs overwriting the same DLL in the Windows system folder with different incompatible versions on Windows 3.1 and Windows 95 because there were no protections. The VB4 and VB6 DLLs being overwritten with older versions were frequent culprits of programs stopping working. It sometimes happened with OCX ActiveX controls too. The multiple copies of the VC Runtime are an attempt at fixing DLL Hell. SxS dotnet assemblies too.
And, as @davinp said, "If it ain't broke, don't fix it". And, if it IS broke, don't fix it. Some programs might DEPEND on a certain behavior that most would consider a bug. Therefore, fix the bug going forward, like, in a new release of the DLL, but KEEP the buggy DLL around for backwards compatibility. Finally, Leo may have been generous by showing "only" 6 versions of the library. Double that. Because developers often need the same DLLs, but also need the corresponding debug versions of each. It becomes multiplicative / exponential. You may need the x86 and 64-bit versions. And you might also need the debug versions. Times 2. Now you could potentially need 4 versions of each DLL release. Fortunately, though, consumers rarely need any debug versions.
"Therefore, fix the bug going forward, like, in a new release of the DLL, but KEEP the buggy DLL around for backwards compatibility." I read somewhere that in the early days when Windows was getting established, and they were trying to get as many applications as possible on Windows, they would often leave known incorrect code around so as not to break existing applications.
Every program should be portable, with anything they need. I know, somethimes its waste of space, but its a compromise i would take without questioning if i had the option to.
One purpose of shared libraries was to share the code, to reduce memory and disk usage. It has all the code because a program could use any of it. But when each program has its own copy, a lot of functionality isn't used so it's wasted disk space. They would have been better off just statically linking to the library, which allows only including the code actually used by the program. The worst aspect is programs breaking from different versions. I'll take the wasted disk space by having each program have its own version it was developed to work with.
Still not understanding why subsequent versions can't be backward compatible to older versions. If you want to change a library then it's an ADDITIONAL library with a NEW name- not the old library with the same name but different functionality. Why was that so hard to do, exactly?
That is very fine in theory, but not in practice. One standard problem is a know bug (usually at a corner case) getting fixed finally after years. Everybody is happy, but there is at least one program DEPENDING on the bug, using for something which was never envisioned. Windows is a particularly bad example. Under Linux, you have major and minor versions of so files. New functionality is supposed to be introduced only with major versions. It works better than Windows, but far from ideal.
@@thiloreichelt4199 Ok lets say we have library abc. great library, everybody loves it, very popular, but it has a bug they want to fix. Instead of altering abc you make the fixed version called abc1, leaving the original abc library in your next C++ iteration. Now the old programs can still use abc in the newer C++ versions but newer programs can call abc1, instead. Then for the next C++ iteration they want to beef up abc1 library. so ADD abc2, leaving both abc and abc1 as is. etc. etc. What problem would that cause?
I see one thing coming: there will be fewer native windows apps. instead using the linux subsystem libs to get things done, at least it would not surprise me to see some software doing this.
@@franciscohorna5542I have 16 and wonder if it is causing my gaming pc to suffer issues. I might be having motherboard or cpu problems though. Most likely my motherboard is dying 😭
It's more than just having different library versions cluttering your desk though. In general, there are two more problems here: 1. Each of these versions take up some memory in RAM which leads to cache misses. While you might think "What's another 3 MB, I've got half a Terrabyte of 'em!" however, each core on your computer only has 80 kB to work with before you start seeing penalty hits - and that is on the latest and greatest from AMD / Intel. All other memory need to be fetched from RAM (it's a bit more complicated than that, but essentially). 2. Outdated libraries that contain security holes. On Linux, if one library is used for all programs, you change that library and (in theory) the hole is patched. On Windows, the hole is only patched once every program installed is patched for the vulnerability. Windows way of multiple copies is the most convenient way and especially for applications you do not have source code for, but it's also one of the reasons Windows has been struggling with security even to this day.
1) they only take up RAM if you're running a program that actually uses them. It's very unlikely that your running programs simultaneously that load them all. 2) Microsoft does update the various libraries, even if they're labelled as older, for security fixes.
@@askleonotenboom 1) is more common than you might think; for instance these libraries contain the runtime that draw the win32 GUI code. I do concede, however, that it isn't the end of the world, we are talking increased latency of maybe 1 microsecond or two. It is unlikely a user is going to notice this, though this can matter in heavy algorithm loads like say, transcoding in three different applications. I agree this is a niche use case and very unlikely to be noticeable unless benchmarking, but the performance hit is measurable. It is mostly a problem in my domain of embedded realtime programming. 2) Microsoft might patch older versions where possible; but a lot of programs come bundled with their own versions of, say, ffmpeg, libssl, SDL... Who is going to update those, especially as much software is abandoned today? You do bring up good points though. :)
The problem is not unheard of in Linux but is less pronounced since version numbers are usually included in the file name of the library (or a sym-link). Linux dependency hell was almost as bad as DLL hell at times though. I think OS X apps have multiple copies of libraries as well, but they install separate copies for every app bundle. It is a lousy use of space, but you need to work to "accidentally" remove a library that way. I think frameworks can be installed on OS X if you will need the same functionality in a number of programs; however, that's getting a bit too deep for me. Most windows programs will install a DLL in the same folder as the executable now. If you had a DLL that was used by multiple programs it often got installed in the windows or windows\system32 folders. (I forget which, it's been ~20 years since i worried about that.) Some of the problems were also caused by licensing. Here's our DLL, it has a lot functionality and you can use it on your machine, and even sell software you create that uses it. However, you aren't allowed to distribute the DLL. It wasn't just MS, I think most of the large vendors did it.
Screw their BS licence, if i need it on multiple systems im going to distribute it. Aren't allowed to distribute? Fk that, i don't care. Im going to distribute it anyway.
Package managers exist precisely to solve the uninstall problem. On linux there is plenty of them apt, pacman, nix etc. Even on windows some of them exists like chocolatey and the Microsoft store is doing similar work if I'm not mistaking. So this problem is only existing with manual software installation which sadly is the most known way to install software on Windows.
I see that the need for multiple runtimes is a security risk because an older runtime might have a bug that allows an intruder to utilize it in order to access data or gain privileges and it will never be fixed because it's "too old".
Linux solved these issues. Linux tracks the dependencies between SW packages via a package manager tool. Exception is only the manual installation from source code. So Linux knows if a package is not needed any more and can be deleted. The duplications are also quite well managed by using so-names. Programs are linked against symbolic links (so-names) and they do not have to be specific with the full version numbers - say you can just state the major version you depend on, but not the minor or patch version. On windows you normally link against a specific DLL. This makes your program much less picky.
You also have portable programs that can require certain versions of a runtime but don't come packaged with them. That can make a DLL registry even more useless.
Could Visual C++ be configured for full static linking? If one is not using many functions in the DLL, it might be better to have a standalone executable .
I remember around 1978 when Object Oriented Programming (OOP) was hot. This is one of the unforeseen consequences. I have 11 copies on my machine. I leave them alone. Until this video, I did not know the WHY of so many copies. Thanks, Leo.
The problem isn't unique to OOP. Even c libraries can have compatibility problems between versions. C++s design just introduces more potential for incompatibility between versions, even if functionality is just being expanded. Java generally handles this binary compatibility better, while allowing OOP
@@SuprousOxide You are right about Java. Beginning in 1996 or 1997 we started coding in Java and kept the OOP mantra but then in a couple of years Java had security issues so we switched to C++. Thanks for reminding me.
I've been uninstalling older version of the C++ redistributable for a couple months now. I have 2012 and 2015-2022 left. I haven't run into any issue yet.
Microsoft fixed this in their Singularity OS, where programs have a standard way of describing their code, so you don't have the "my uninstaller doesn't uninstall everything I installed" problem. Installed code isn't just a big blob of executables.
OT : Leo, a possible subject for a future video... with Microsoft removing the 32 Gb limit on FAT32, what are the broader implications for FAT32, ExFAT, and NTFS for USB devices ? ( This is only for formatting from the command line, not the GUI.)
Always FAT32 for removable devices. You don't need the security/permission features of NTFS on removable devices. NTFS permissions are already annoying on a home PC. *_I_* am the administrator of my PC, i should have access to all files.
Could an alias (or script) be made with the name of the library, and that alias will write a timestamp to a log, and then call the intended library? If the above is doable, then we would have a way to identify how often, if ever, a library is run -- and then we could make an informed decision on whether or not the library is needed. Of course, we could wait and watch the log(s) for 6 months, before removing unused libraries, only to run into a problem a year later. But a log of when a library is run will provide insight into whether it is known to be used or whether it shows no sign of being used. I am not a programmer, so I do not know if the above effort to log instances will break anything.
I've been using embarcadero C++ builder foe over 20 years. And I always build exes that dont need to dynamically link to the embarcadero DLLs. So no dlls required.
It's untrue that other platforms have this problem, or that they don't share code. In Linux, code sharing is ubiquitous, and I need to run some unstable version of the distro to experience even the slightest problem with the dependency hell so common and unsolvable in Windoze.
Thanks for the video. Nice subject. Haven't heard mention of DLL Hell in a few years. I will make a minor objection to your example - lower casing text is non-trivial and you definitely want it as a library function as I'm sure you know. I used to be associated with text processing a bit so I've endured the pain. :)
Perhaps software should go back to being statically linked, rather than try to rely on external DLLs. You then get large binaries that are completely self-contained, that cannot be broken by other software. The Windows paging system can selectively load pages from the large monolithic binary, so it doesn't consume excess memory and still performs well.
i'm confused, have 1 pc with 2 and 1 with 5. Both work fine for apps, games, etc. i never went out looking for these except win update maybe. but even then i dont see any. g uessing it comes from other apps which installs it or something. should we have 6+ even though machine works fine and all?
You can, sort of. Go to the Control Panel \ Programs and Features. This will list the apps that have been installed AND the date that they were installed. Then check the dates on the folders of your C++ Runtimes. Not perfect but I bet you can really narrow down the candidates for deletion.
Having no experience of the programming software, I leave well alone. Are things any clearer in the Linux operating system, and if so is that the way to go?
If only there was a way to track what apps depend on what libraries. Let’s call them dependencies. And an app that will automatically check what app installed what dependency. And maybe even update them. Let’s call those ready to install dependencies packages. So the app will be package manager. What a great world it would be.
Another approach would be to statically link only the needed routine(s) into a program's executable file, eliminating the need for a DLL. I believe this requires a different kind of library available during development, which isn't always available. This would also result in some duplication of routines inside executable files but assures that an executable will always run even when a DLL is not present.
Yes, but this hasn't always been the case. Before apt, we could also experience a "dependency hell". Although it was never as bad as having 12 different copies of the same library, it had its own quirks. The introduction of apt in 1999 largely solved this problem in Linux.
And this is one of the big reasons windows is dumb and linux is good. It actually has the expected behavior of backwards compatibility in glibc, and a package manager tracks shared dependencies in a standardized way, and it decides what to uninstall, insteaf of the program being uninstalled, which is the obvious choice since it's impossoble for a dev to know which dependencies are shared.
Reality is that a lot from problem is actually caused by C++ language complexity. It is just garbage and hard to make binary compatible. Secondly, Windows just sucks here because it lacks proper dependency management. Also the problem is not unsolvable. Standardization solves a lot. Writing applications to run in browser means that no libraries need to be installed. However there may be libraries run top of browser but browser is very high level and standardizes stuff. One solution is of course proper maintenance of the software. Software developers should move forward and compile the software against latest runtimes so old versions can be removed. Or build the C++ run top of wasm runtime that is found from browser, or NodeJS/Electron. That means less dependencies. And one solution is that when requirements are fully known, it is possible write software practically without bugs, or need for upgrade. C++ in Windows is just not made that kind of development process.
✅ Watch next ▶ Managing Files on Your PC and in the Cloud ▶ ruclips.net/video/AQh0DDA77Pw/видео.html
Other OSes do the bit about tracking which packages caused library packages to be installed, and will later give you the option to delete the libraries if no other programs use it.
But Windows installers do a lot of their own things, rather than in standardized way that can be better tracked
I amazed of how much tolerance people have for clicking next and next in windows.. while I myself just give the computer a list of what I want and takes a coffee break 🤣
Seems eminently sensible, keeping track of who's using what. I'd have thought that that's what the registry is for, and that Windows would prohibit the installation of a library that's already loaded.
And to make that workable - in the same way that there's a list of CVTs in the security field (Common Vulnerabilities & Threats) each with a unique number - I'd imagine there would be unique, addressable, immutable, APIs that, obviously, never change, but that accumulate. A new function, approved by David Cutler (🙂), gets a new higher 'CVT'.
But apparently not. So sad.
Yup. E.g.: sudo apt autoremove 😊
As a software developer myself, I say that this is excellent advice delivered in a very clear way - great job Leo 👌
Back when disk space was really limited and really expensive, sharing components (DLLs and other libraries) was about the only way you could get Windows to fit on a machine from the early to mid '90s. These days, a program is almost as likely to install its own personal copy of some library or redistributable, rather than try to share it.
Before Visual Studio 2015 there was no compatibility between msvc runtime. Each new major version of Visual Studio had a new runtime so if you have old software you may need older runtimes.
So sad.
So true. Underlying implementation details of very basic things (like 'String' objects) changing from one release to the next means runtimes are also changed. Even in low-level things like windows DDK (driver development kits) had structs that changed size from one release to the next. Couldn't just rebuild drivers with newer DDK's things 'evolved' and changed too much.
I'm a software engineer and our company has an old piece of software probably 10 years old or so. (I've only been there about 5 years). It will not run on a computer that doesn't have C++ Dist 2013 and a specific version number of 2013 dist. Luckily that apps "sundown" is next summer (It's a WPF app). We built a better web based app using C# backend and react frontend. We are having some of our bigger customers trying the BETA along side with old version of the new app and fix any bugs they find. Developing software is fun 😁
I’m sorry but the problem does exist on other platforms. That’s why there’s a massive push for flatpak, snaps and containerisation of apps.
Exactly. GLIBC comes to mind for example with Linux development... Or even platform-agnostic, Python's PIP modules, etc.
As a programer, you can choose a static link to this Libraries, but it will blow up your code. I always choose a dynamic link to this libaries, because the DLLs often pre-load in the memory. The DLLs reduce space in physical and virtual memory.
A static link to this libraries means, that the code of the library-functions will be included in the code of the program, and that blows the code up (there are many MBs more binary code).
The Visual-C++-Runtimes are a part of the windows-system, because many programs need them. This libraries include the MFC, which are classes for programming windows-programs in C++. Even though the MFC is now obsolete, many programs still use it.
Well, it doesn't really blow up your code, it just combines the code sections that would otherwise be in the DLLs with your own code. You end up with a large monolith binary that isn't any bigger than your normal binary plus the DLLs separately. That monolith binary is impervious to other programs or (un)installers messing with the DLLs, it has everything it needs in it, and immutably so. Windows will use its paging system to just load the pages that are actually executed, so it isn't bad on memory either.
DLLs were a great idea when harddisk space was at a premium. Not anymore.
When I create program for Linux I would always choose to static compile/link, learned the hard way.
@@rashidisw
Many C and C++ libraries in Linux based operating systems are LGPL license and that is potentially dangerous to use static linking if source is not provided to customer. Developer can end up in court because license violation.
@@gruntaxeman3740 That mostly non-issue tho.
I always stated whether in readme/doc/manual/legal license files , makefile, or in source code itself which libraries I uses, which version of it and where I obtained it from.
Its also important to state which Linux distro, and which version updates of it that were used to compile the program.
So if customers want to compile my program themselves to verify my works, they need to do the similar hoops I have done to do it, if they haven't done so already.
So far there are no issues with customers, If anything most of them happy that I provides that information.
Sory, but i do not agree.
My software is, always, complete with anything they need to run. If i could i would deliver even the machine to the users.
Before a do the things this way my work were several times affected by others which i did not have any control.
Dependency tracking is a solved problem...
This is where containers can come in handy, but you need to convince loads of software companies and windows app developers to only ever deploy with a packaging scheme based around container images rather than the standard installer files. It's a kind of tough sell for those trying to ensure top performance and memory efficiency, though.
Excellent explanation. Many thanks Leo.
Thanks for explaining this. I didn't understand why so many versions of Visual C++ Runtime are installed. Different programs use different versions of Runtime. As the saying goes "If it ain't broke, don't fix it"
For various technical reasons, versions of the runtimes are not always backwards compatible. Also, if you test your program against one runtime it might not work correctly with a different version of the runtime.
The multiple visual studio c++ versions make me feel safe, secure and stable while using my bad OS, and I like to feel safe, so they stay, no questions asked further.
The newer versions of C++ libraries should include the functions of previous versions. Then you only need one version that works for all programs.
Even if it makes the size larger, at this point there's way too many versions of the runtime. We REALLY need this feature or for them to stop changing the runtime constantly.
@@KertaDrake They do now. Since 2015, newer versions are backwards compatible all the way to the 2015 version. Too bad that there's also 2005, 2008, 2010, 2012, and 2013, none of which are compatible with each other or any later version.
However there might be things that by necessity has become more strict in newer versions causing an old program to stop function or become unreliable. You never know really where you'll end up.
The problem is that older programs are already dynamically linked to these libraries. Therefore, they are built to use the ABI (application binary interface) of these libraries. Changing the library changes the ABI, even if you use the same functions with the same signatures; because the positions of these functions inside the compiled library change.
This means that even if you include all the functions and other symbols from previous libraries to a new and unique library. You will need to recompile ALL and EVERY one program that uses the previous libraries to use the new one.
Unfortunately, if you don't want to break all programs that use any version of VC++ runtime you will need to distribute every version of the library. 😓
Another solution is to deprecate everything and encourage people to use the new library (UCRT already does this) but you still can't remove the old libraries without risking backwards compatibility.
@@teknixstuffdoes that mean I can uninstall anything pre-2015? I have 16 different redistributable files and I believe it’s causing me performance issues. I would really appreciate a reply to help me out man thank you ❤
The original definition of DLL hell was different programs overwriting the same DLL in the Windows system folder with different incompatible versions on Windows 3.1 and Windows 95 because there were no protections. The VB4 and VB6 DLLs being overwritten with older versions were frequent culprits of programs stopping working. It sometimes happened with OCX ActiveX controls too. The multiple copies of the VC Runtime are an attempt at fixing DLL Hell. SxS dotnet assemblies too.
And, as @davinp said, "If it ain't broke, don't fix it". And, if it IS broke, don't fix it. Some programs might DEPEND on a certain behavior that most would consider a bug. Therefore, fix the bug going forward, like, in a new release of the DLL, but KEEP the buggy DLL around for backwards compatibility. Finally, Leo may have been generous by showing "only" 6 versions of the library. Double that. Because developers often need the same DLLs, but also need the corresponding debug versions of each. It becomes multiplicative / exponential. You may need the x86 and 64-bit versions. And you might also need the debug versions. Times 2. Now you could potentially need 4 versions of each DLL release. Fortunately, though, consumers rarely need any debug versions.
"Therefore, fix the bug going forward, like, in a new release of the DLL, but KEEP the buggy DLL around for backwards compatibility."
I read somewhere that in the early days when Windows was getting established, and they were trying to get as many applications as possible on Windows, they would often leave known incorrect code around so as not to break existing applications.
Every program should be portable, with anything they need.
I know, somethimes its waste of space, but its a compromise i would take without questioning if i had the option to.
the Uninstall Problem @3:55 sounds like our favorite problem in computer science, "The Halting Problem".
Still a problem after nearly 30 years of MSVC++
Thank you for covering more advanced topics.
I see you used the settings version of the list of installed programs. 🤔
One purpose of shared libraries was to share the code, to reduce memory and disk usage. It has all the code because a program could use any of it. But when each program has its own copy, a lot of functionality isn't used so it's wasted disk space. They would have been better off just statically linking to the library, which allows only including the code actually used by the program. The worst aspect is programs breaking from different versions. I'll take the wasted disk space by having each program have its own version it was developed to work with.
Still not understanding why subsequent versions can't be backward compatible to older versions. If you want to change a library then it's an ADDITIONAL library with a NEW name- not the old library with the same name but different functionality. Why was that so hard to do, exactly?
That is very fine in theory, but not in practice. One standard problem is a know bug (usually at a corner case) getting fixed finally after years. Everybody is happy, but there is at least one program DEPENDING on the bug, using for something which was never envisioned.
Windows is a particularly bad example. Under Linux, you have major and minor versions of so files. New functionality is supposed to be introduced only with major versions. It works better than Windows, but far from ideal.
@@thiloreichelt4199 Ok lets say we have library abc. great library, everybody loves it, very popular, but it has a bug they want to fix. Instead of altering abc you make the fixed version called abc1, leaving the original abc library in your next C++ iteration. Now the old programs can still use abc in the newer C++ versions but newer programs can call abc1, instead. Then for the next C++ iteration they want to beef up abc1 library. so ADD abc2, leaving both abc and abc1 as is. etc. etc. What problem would that cause?
Maintaining C++ ABI requires effort, language itself is changing and there can be bugs that some software depends.
I see one thing coming: there will be fewer native windows apps. instead using the linux subsystem libs to get things done, at least it would not surprise me to see some software doing this.
Hey Leo! I have 23 copies of that library. Whoopee!
i got 14 of them installed myselfe here i dont mess with them at all
yes best to just leave them alone
@@davinp yep how many do you have installed i got 14
@@franciscohorna5542 I have 10
@@franciscohorna5542I have 16 and wonder if it is causing my gaming pc to suffer issues. I might be having motherboard or cpu problems though. Most likely my motherboard is dying 😭
Thanks Leo it's like baking , miss one ingredient and the whole meal goes wrong😊😊😊😊
It's more than just having different library versions cluttering your desk though. In general, there are two more problems here:
1. Each of these versions take up some memory in RAM which leads to cache misses. While you might think "What's another 3 MB, I've got half a Terrabyte of 'em!" however, each core on your computer only has 80 kB to work with before you start seeing penalty hits - and that is on the latest and greatest from AMD / Intel. All other memory need to be fetched from RAM (it's a bit more complicated than that, but essentially).
2. Outdated libraries that contain security holes. On Linux, if one library is used for all programs, you change that library and (in theory) the hole is patched. On Windows, the hole is only patched once every program installed is patched for the vulnerability.
Windows way of multiple copies is the most convenient way and especially for applications you do not have source code for, but it's also one of the reasons Windows has been struggling with security even to this day.
1) they only take up RAM if you're running a program that actually uses them. It's very unlikely that your running programs simultaneously that load them all.
2) Microsoft does update the various libraries, even if they're labelled as older, for security fixes.
@@askleonotenboom 1) is more common than you might think; for instance these libraries contain the runtime that draw the win32 GUI code.
I do concede, however, that it isn't the end of the world, we are talking increased latency of maybe 1 microsecond or two. It is unlikely a user is going to notice this, though this can matter in heavy algorithm loads like say, transcoding in three different applications.
I agree this is a niche use case and very unlikely to be noticeable unless benchmarking, but the performance hit is measurable. It is mostly a problem in my domain of embedded realtime programming.
2) Microsoft might patch older versions where possible; but a lot of programs come bundled with their own versions of, say, ffmpeg, libssl, SDL... Who is going to update those, especially as much software is abandoned today?
You do bring up good points though. :)
The problem is not unheard of in Linux but is less pronounced since version numbers are usually included in the file name of the library (or a sym-link).
Linux dependency hell was almost as bad as DLL hell at times though.
I think OS X apps have multiple copies of libraries as well, but they install separate copies for every app bundle. It is a lousy use of space, but you need to work to "accidentally" remove a library that way. I think frameworks can be installed on OS X if you will need the same functionality in a number of programs; however, that's getting a bit too deep for me.
Most windows programs will install a DLL in the same folder as the executable now. If you had a DLL that was used by multiple programs it often got installed in the windows or windows\system32 folders. (I forget which, it's been ~20 years since i worried about that.)
Some of the problems were also caused by licensing. Here's our DLL, it has a lot functionality and you can use it on your machine, and even sell software you create that uses it. However, you aren't allowed to distribute the DLL. It wasn't just MS, I think most of the large vendors did it.
Screw their BS licence, if i need it on multiple systems im going to distribute it. Aren't allowed to distribute? Fk that, i don't care. Im going to distribute it anyway.
@@simontay4851
That means that DLL is not free, just pay the money what developer requires or write own.
Proper way is to install runtime separately.
Package managers exist precisely to solve the uninstall problem. On linux there is plenty of them apt, pacman, nix etc. Even on windows some of them exists like chocolatey and the Microsoft store is doing similar work if I'm not mistaking. So this problem is only existing with manual software installation which sadly is the most known way to install software on Windows.
I see that the need for multiple runtimes is a security risk because an older runtime might have a bug that allows an intruder to utilize it in order to access data or gain privileges and it will never be fixed because it's "too old".
Linux solved these issues. Linux tracks the dependencies between SW packages via a package manager tool. Exception is only the manual installation from source code. So Linux knows if a package is not needed any more and can be deleted. The duplications are also quite well managed by using so-names. Programs are linked against symbolic links (so-names) and they do not have to be specific with the full version numbers - say you can just state the major version you depend on, but not the minor or patch version. On windows you normally link against a specific DLL. This makes your program much less picky.
What about the other dozens of installers that some apps include in their /redis/ folders? Why are not deleted once the program is installed?
Usually because those are also the UNinstallers.
I saw what you did there. That was a nice nod to Hotel California. 😉
You also have portable programs that can require certain versions of a runtime but don't come packaged with them. That can make a DLL registry even more useless.
I've got 12 different versions (9.x - 14.x). However, they are small in size so no big deal.
Could Visual C++ be configured for full static linking? If one is not using many functions in the DLL, it might be better to have a standalone executable .
I have 20 versions of the runtime. But thanks for the very informative video.
Thank You, very useful!
I once renamed a DLL copy to the version a software I'm using required and it worked. Turns out you can sometimes fool software.
Great video; I was wondering about these files myself.
I remember around 1978 when Object Oriented Programming (OOP) was hot. This is one of the unforeseen consequences. I have 11 copies on my machine. I leave them alone.
Until this video, I did not know the WHY of so many copies. Thanks, Leo.
The problem isn't unique to OOP. Even c libraries can have compatibility problems between versions.
C++s design just introduces more potential for incompatibility between versions, even if functionality is just being expanded.
Java generally handles this binary compatibility better, while allowing OOP
@@SuprousOxide You are right about Java. Beginning in 1996 or 1997 we started coding in Java and kept the OOP mantra but then in a couple of years Java had security issues so we switched to C++. Thanks for reminding me.
I've been uninstalling older version of the C++ redistributable for a couple months now. I have 2012 and 2015-2022 left. I haven't run into any issue yet.
How much space have you released?
@@dudmanjohn30 mbs maybe😂😂😂
Too much time on his hands to care about such small things. Just leave them installed why waste brain power
Microsoft fixed this in their Singularity OS, where programs have a standard way of describing their code, so you don't have the "my uninstaller doesn't uninstall everything I installed" problem. Installed code isn't just a big blob of executables.
OT : Leo, a possible subject for a future video... with Microsoft removing the 32 Gb limit on FAT32, what are the broader implications for FAT32, ExFAT, and NTFS for USB devices ? ( This is only for formatting from the command line, not the GUI.)
Always FAT32 for removable devices. You don't need the security/permission features of NTFS on removable devices. NTFS permissions are already annoying on a home PC. *_I_* am the administrator of my PC, i should have access to all files.
Could an alias (or script) be made with the name of the library, and that alias will write a timestamp to a log, and then call the intended library?
If the above is doable, then we would have a way to identify how often, if ever, a library is run -- and then we could make an informed decision on whether or not the library is needed.
Of course, we could wait and watch the log(s) for 6 months, before removing unused libraries, only to run into a problem a year later. But a log of when a library is run will provide insight into whether it is known to be used or whether it shows no sign of being used.
I am not a programmer, so I do not know if the above effort to log instances will break anything.
I've been using embarcadero C++ builder foe over 20 years. And I always build exes that dont need to dynamically link to the embarcadero DLLs. So no dlls required.
It's untrue that other platforms have this problem, or that they don't share code. In Linux, code sharing is ubiquitous, and I need to run some unstable version of the distro to experience even the slightest problem with the dependency hell so common and unsolvable in Windoze.
Thanks for the video. Nice subject. Haven't heard mention of DLL Hell in a few years. I will make a minor objection to your example - lower casing text is non-trivial and you definitely want it as a library function as I'm sure you know. I used to be associated with text processing a bit so I've endured the pain. :)
Perhaps software should go back to being statically linked, rather than try to rely on external DLLs. You then get large binaries that are completely self-contained, that cannot be broken by other software. The Windows paging system can selectively load pages from the large monolithic binary, so it doesn't consume excess memory and still performs well.
With de-duplication mechanism even static compiling can share code.
Thank goodness storage space has increase much faster than the Runtime bin.
i'm confused, have 1 pc with 2 and 1 with 5. Both work fine for apps, games, etc. i never went out looking for these except win update maybe. but even then i dont see any. g uessing it comes from other apps which installs it or something. should we have 6+ even though machine works fine and all?
Simply microsoft can use composability around dll files and they can solve the problem...
It would be nice if one could check which software uses a certain C++ Runtime, so you can remove the unused ones without breaking stuff.
You can, sort of. Go to the Control Panel \ Programs and Features. This will list the apps that have been installed AND the date that they were installed. Then check the dates on the folders of your C++ Runtimes. Not perfect but I bet you can really narrow down the candidates for deletion.
These libraries are like 20 mbs in size don't delete them just leave them alone don't you have better uses for your time?
Having no experience of the programming software, I leave well alone. Are things any clearer in the Linux operating system, and if so is that the way to go?
Those packages always make me feel like I’m being hacked!
So to sum up, Support your local libraries.🤔
really interesting, thank you!
wow, never thought I would hear 'failure' in the same sentence as 'windows' -
If only there was a way to track what apps depend on what libraries. Let’s call them dependencies. And an app that will automatically check what app installed what dependency. And maybe even update them. Let’s call those ready to install dependencies packages. So the app will be package manager. What a great world it would be.
Winget, chocolatey and scoop exist but I don't want packages made by random people. Only the original devs
What about a cleanup program that scans all executable code to determine which runtime libraries are required?
just statically link the functions that the software actually uses.
Java has the same issue. Many Java Apps are Java version dependent.
Another approach would be to statically link only the needed routine(s) into a program's executable file, eliminating the need for a DLL. I believe this requires a different kind of library available during development, which isn't always available. This would also result in some duplication of routines inside executable files but assures that an executable will always run even when a DLL is not present.
i have 27 copies of visual C++ runtime .......
Linux system and *nix is the proper way to do this.
which is?
Yes, but this hasn't always been the case. Before apt, we could also experience a "dependency hell". Although it was never as bad as having 12 different copies of the same library, it had its own quirks. The introduction of apt in 1999 largely solved this problem in Linux.
@@victorsago yes that is what I meant. I didn't know it was worse before apt etc
Ooh lucky me I only install C++ redist when using WINE
I'm guessing that whatever Leo doesn't know about computers isn't worth knowing!
In short, is this what they calll in Linux as dependencies? So I close the loop.
and sadly I have 16 versions of it on my computer :(
Oh thank Hell....
Just use a Linux distribution that has a decent package manager..
Long live 'code bloat.'
At least they are small
And this is one of the big reasons windows is dumb and linux is good. It actually has the expected behavior of backwards compatibility in glibc, and a package manager tracks shared dependencies in a standardized way, and it decides what to uninstall, insteaf of the program being uninstalled, which is the obvious choice since it's impossoble for a dev to know which dependencies are shared.
Find out what programs are using them and stop supporting this lazy programming.
Microsoft blows.
The only way a Microsoft product will never suck is if it was a vacuum cleaner.
Reality is that a lot from problem is actually caused by C++ language complexity. It is just garbage and hard to make binary compatible. Secondly, Windows just sucks here because it lacks proper dependency management.
Also the problem is not unsolvable. Standardization solves a lot. Writing applications to run in browser means that no libraries need to be installed. However there may be libraries run top of browser but browser is very high level and standardizes stuff.
One solution is of course proper maintenance of the software. Software developers should move forward and compile the software against latest runtimes so old versions can be removed. Or build the C++ run top of wasm runtime that is found from browser, or NodeJS/Electron. That means less dependencies.
And one solution is that when requirements are fully known, it is possible write software practically without bugs, or need for upgrade. C++ in Windows is just not made that kind of development process.
Meanwhile in Linux environment, those problems rarely happen thanks to our rigid package manager
TLDR: microsoft is still incompetent
Because windows is trash