Post History
Windows packages all of its API functions into DLLs, so when you have a program that relies on calls to X, Y and Z you must ensure that you have the correct set of DLLs that provide all of those. T...
Answer
#2: Post edited
- Windows packages all of its API functions into DLLs, so when you have a program that relies on calls to X, Y and Z you must ensure that you have the correct set of DLLs that provide all of those. The exact organization of which X, Y and Z goes into which DLL is complicated and depends on:
- * Three decades of Windows development
- * Possibly multiple years of third party software development
- * The decisions and competence of the programmer of the actual program using the DLLs
Wine does not replicate the mess of Windows DLLs exactly because it has the benefit of hindsight. Windows apps often ship with "redistributables" that need to install a bunch of their own DLLs to cope with Windows version/dependency hell, because Windows environments (ie. what DLLs that user has installed) are unpredictable and unreliable. However, Wine does not have this problem and usually all the features needed by your Windows will already be provided by Wine out of the box, even *without* letting the app install its redistributables.- The "Install DLL" feature is an escape hatch for rare instances in which you find a case where Wine developers forgot to or couldn't support a given DLL properly. It's not a routine thing, because in modern Wine these situations are rare. So in practice, the rule is to install DLLs only if:
- * You find other sources online saying it doesn't work without that DLL, and works after
- * You get a specific error message saying `xyz.dll is missing`
- The most common Windows software I use with Wine is games. For these, I don't even bother with DLLs. If I did try, there would be a huge number of DLLs I might potentially need to try combinations of. Normally, if Wine doesn't work, I try one of the other runtimes like Proton or GloriousEggroll which have even more DLLs baked in. If it doesn't work with Proton and/or GE, and the tricks from protondb don't help, I give up and boycott the app for being an utter embarrassment to the programmer profession.
- >Are there any downsides
- The biggest downside is that it's probably a waste of your time because odds are very low a simple DLL install is going to fix whatever issue you have, and nobody else online has posted that and you get no error about it (assuming my rule from above).
- You can potentially install a bunch of junk DLLs and break your wine prefix. However, luckily Wine (unlike Windows) has been developed by competent people who understand the concept of isolation. So you can simply create separate Wine prefixes for each DLL experiment and nothing will be harmed.
- Windows packages all of its API functions into DLLs, so when you have a program that relies on calls to X, Y and Z you must ensure that you have the correct set of DLLs that provide all of those. The exact organization of which X, Y and Z goes into which DLL is complicated and depends on:
- * Three decades of Windows development
- * Possibly multiple years of third party software development
- * The decisions and competence of the programmer of the actual program using the DLLs
- Wine does not replicate the mess of Windows DLLs exactly because it has the benefit of hindsight. Windows apps often ship with "redistributables" that need to install a bunch of their own DLLs to cope with Windows version/dependency hell, because Windows environments (ie. what DLLs that user has installed) are unpredictable and unreliable. However, Wine does not have this problem and usually all the features needed by your Windows program will already be provided by Wine out of the box, even *without* letting the app install its redistributables. Not always though - for example the C++ redists are often necessary.
- The "Install DLL" feature is an escape hatch for rare instances in which you find a case where Wine developers forgot to or couldn't support a given DLL properly. It's not a routine thing, because in modern Wine these situations are rare. So in practice, the rule is to install DLLs only if:
- * You find other sources online saying it doesn't work without that DLL, and works after
- * You get a specific error message saying `xyz.dll is missing`
- The most common Windows software I use with Wine is games. For these, I don't even bother with DLLs. If I did try, there would be a huge number of DLLs I might potentially need to try combinations of. Normally, if Wine doesn't work, I try one of the other runtimes like Proton or GloriousEggroll which have even more DLLs baked in. If it doesn't work with Proton and/or GE, and the tricks from protondb don't help, I give up and boycott the app for being an utter embarrassment to the programmer profession.
- >Are there any downsides
- The biggest downside is that it's probably a waste of your time because odds are very low a simple DLL install is going to fix whatever issue you have, and nobody else online has posted that and you get no error about it (assuming my rule from above).
- You can potentially install a bunch of junk DLLs and break your wine prefix. However, luckily Wine (unlike Windows) has been developed by competent people who understand the concept of isolation. So you can simply create separate Wine prefixes for each DLL experiment and nothing will be harmed.
#1: Initial revision
Windows packages all of its API functions into DLLs, so when you have a program that relies on calls to X, Y and Z you must ensure that you have the correct set of DLLs that provide all of those. The exact organization of which X, Y and Z goes into which DLL is complicated and depends on: * Three decades of Windows development * Possibly multiple years of third party software development * The decisions and competence of the programmer of the actual program using the DLLs Wine does not replicate the mess of Windows DLLs exactly because it has the benefit of hindsight. Windows apps often ship with "redistributables" that need to install a bunch of their own DLLs to cope with Windows version/dependency hell, because Windows environments (ie. what DLLs that user has installed) are unpredictable and unreliable. However, Wine does not have this problem and usually all the features needed by your Windows will already be provided by Wine out of the box, even *without* letting the app install its redistributables. The "Install DLL" feature is an escape hatch for rare instances in which you find a case where Wine developers forgot to or couldn't support a given DLL properly. It's not a routine thing, because in modern Wine these situations are rare. So in practice, the rule is to install DLLs only if: * You find other sources online saying it doesn't work without that DLL, and works after * You get a specific error message saying `xyz.dll is missing` The most common Windows software I use with Wine is games. For these, I don't even bother with DLLs. If I did try, there would be a huge number of DLLs I might potentially need to try combinations of. Normally, if Wine doesn't work, I try one of the other runtimes like Proton or GloriousEggroll which have even more DLLs baked in. If it doesn't work with Proton and/or GE, and the tricks from protondb don't help, I give up and boycott the app for being an utter embarrassment to the programmer profession. >Are there any downsides The biggest downside is that it's probably a waste of your time because odds are very low a simple DLL install is going to fix whatever issue you have, and nobody else online has posted that and you get no error about it (assuming my rule from above). You can potentially install a bunch of junk DLLs and break your wine prefix. However, luckily Wine (unlike Windows) has been developed by competent people who understand the concept of isolation. So you can simply create separate Wine prefixes for each DLL experiment and nothing will be harmed.