In the trade this sort of problem is called "Dependency Hell" and it can be much, much more difficult and expensive to fix than this example.
Part of the problem is the assumption that Windows 10 or Linux are simple entities. They're not. I have two machines that came pre-loaded with Windows 10 and they aren't identical. Then , every time I've added software I've further changed my individual configurations. Usually the differences are benign, but there are no guarantees that what I've got is completely compatible with anyone else.
Dynamic Link Libraries aren't programs as such: rather they are collections of common functions in a library that can be called by on the fly by an executing process . (A process is a program that is running). This is a very convenient and efficient arrangement for sharing common code, but it's quite easy to get into difficulties like:
- Program fails because a DLL it needs has never been installed.
- Program fails because the DLL is on the machine, but can't be found because it is located in the wrong part of the file system
- Program fails because it doesn't have permission to use the DLL
- Program fails because it requires an earlier version of the DLL than you already have
- Program fails because it requires a later version of the DLL than the one you have
- You have two or programs that turn out to need different versions of the same DLL
- An older Program fails because the DLL has been replaced by a newer, different DLL installed by something else.
- Program fails because you installed another program that came with an incompatible version of the DLL you already had.
- Program fails because it uses a DLL that uses another DLL that has one of the problems above
- Program requires a DLL provided for compatibility reasons (like 32 to 64 bit), that is no longer supported. A DLL provided to let something work during transition from XP to Windows 7, might work on Windows 8, but break on Windows 10.
- etc etc
This potential for DLL chaos is one of the reasons that IT managers usually forbid staff from loading their favourite home applications on a work computer, and why regular upgrading of a computer system is a "good thing". On the down side of regular upgrading, perfectly functional and paid for software can suddenly be rendered useless just because a upgraded DLL no longer supports your elderly configuration. Being forced to pay again for something you know works perfectly well is very annoying!
Although "Dependency Hell" can seem complicated and difficult and often is, it is also possible that the problem is easy to fix simply by installing the missing DLL after downloading it from a reputable source. Sometimes the individual DLL isn't available but can be got by installing a package (like the VB or VC runtimes) that includes it.
As Neil pointed out, be very careful where you get the DLL from. Fake DLLs are a classic way of getting evil into a computer.
Strictly speaking software ought to come with an install package that understands what all the necessary dependencies are and does it's best to automatically sort them out. Trouble is, putting a decent install package together can be more work than writing the blasted program in the first place.
Dave