I've noticed something particularly annoying while using Directory Opus that does not occur in Windows 10 File Explorer. In DOpus when I open an *.exe file the GUI text and size oftentimes are "condensed" and/or unproperly scaled for my UHD screen. An example when opening an executable from DOpus:
When I open the same file in Windows Explorer, I get:
This occurs for a whole bunch of exe files--I'll post another example, one where the interface still remains readable but definitely effected:
Note that both the pictures above are the same "size" onscreen (I resized them to be equivalent). Also note that for the Explorer version, I get much larger UI elements and even have to stretch the interface further horizontally to view all the info.
Many exe files that I have run turn out much worse than the second one (more like the first, perhaps even worse). Is there a workaround/fix for this?
Try setting Preferences / Miscellaneous / Advanced: dlldir_security to FALSE and rebooting. It can affect launched apps by influencing where they look for implicitly loaded DLLs. (But if it does not change things, set it back, as it is more secure in the default TRUE state.)
Try setting Preferences / Miscellaneous / Advanced: def_func_cd_sourcedir to TRUE. It can affect launched apps similar to the above setting and also affect where they load their config files, if they assume the CD will always be their own folder. (But if it doesn't help, set it back to the default of FALSE, as it is more secure.)
Aside from that, I do not know any way that the launching program could affect the DPI scaling or similar of applications which it launches. You may be looking at an operating system bug (there are a lot of OS bugs still in Windows 10 if you are mixing multiple monitor DPIs at the same time, or without rebooting after changing, for example) or a bug caused by 3rd party software that is interacting with Opus and the apps being launched.
To clarify: I changed Preferences / Miscellaneous / Advanced: dlldir_security to FALSE and rebooted. Apps now appear properly sized.
Just wondering though--is changing def_func_cd_sourcedir to TRUE more or less secure than changing dlldir_security to FALSE (i.e. should I try using that option instead)?
Hmm, it is in some cases, and isn't in others. On balance, def_func_cd_sourcedir probably is the better of the two to change if you find either one works.
Since changing dlldir_security made things work, it means something on the system is requiring DLLs to be loaded out of the processes's current directory, not from a full path, from a system folder, or from the same directory as the processes's .exe files.
It may also mean that different DLL versions are being picked up depending on where the program is run from, which makes the program fail sometimes and work in other times, but also introduces the possibility of tricking it into loading a malicious DLL that was included in the same folder as some data files.
That is not good, in terms of security or general good practice. If it affects multiple programs, it might indicate the problem is with a 3rd party tool that has its DLLs loaded into all programs, rather than a problem with all the different programs. (It's definitely not normal.)
A tool like Microsoft's Process Explorer can be used to see which DLLs are loaded into different processes. If you see a common DLL in the programs which are having problems, it might be worth a try to uninstall the software it comes from to see if the problem goes away under normal Opus settings. If it does then it might be worth reporting to the vendor so they can fix things. It's often easy to fix, but also easy to not realise it's a problem at all, so they may just not be aware of it.
Their software would also fail to work correctly if Windows was set to be more secure system-wide via the CWDIllegalInDllSearch = 0xFFFFFFFF registry setting, which effectively does what dlldir_security does in Opus, but forces it on for all software.
If you do find someone to report it to, linking them to my SetDllDirectory inheritance issue page may help them understand what's happening.
I have def_func_cd_sourcedir set to TRUE now instead of dlldir_security to FALSE, and the change also appears to be working. I'll leave it on this setting for now as suggested until I find any other issues. Thanks.