When should you install windows dlls for wine with winetricks?
I noticed in winetricks that it can install windows dlls to the wine folder. It even gives an option to install almost all of them at once. When should someone install these instead of staying with wine's own versions of the components? Will it increase compatibility? Are there any downsides except for the obvious ones of potential legal issues for businesses and introducing more proprietary software to your system?
I tried searching online, but the only answers I found were very out of date.
2 answers
Each situation is different. Some programs in Wine/Windows will work better with the Windows dlls, and some will work better with the Wine (builtin) dlls.
The best way to learn how which dlls work better for your specific application is experimentation, I'm afraid. Regarding increasing compatibility, maybe. Sometimes a wine built-in implementation works, and sometimes it does not.
The second-best way to learn, is to check https://appdb.winehq.org/ for your app and follow guidelines by somebody who reported success.
Downsides of using Windows (native) dlls: takes up more space, makes you dependent on sourcing those files (winetricks tries to download the components from proper sources like Microsoft VB6 runtime, which depends on Microsoft still offering those), and doesn't always make things better.
0 comment threads
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.
0 comment threads
0 comment threads