The goal here was to change the way the three paths (cwepg executable path, hdhr executable path, and application data path) are assigned when CwHelper starts. It's complicated by the fact that we're trying to run on XP through Windows 11. Security measures, presumably, prevent Windows 11 from using the earlier technique of Windows registry access. So a text file that was originally created to enable testing on non-production systems has been leveraged to work around the Windows registry issue.
See emails from 11/8/2024 +/-:
Here’s my rationale on the text file. First, it isn’t used/needed in non-Store installations, because the Registry values that CW_EPG always provides will be available to all apps. Second, it is created by the Store version of CW_EPG IFF running on Win11 post-21H2 when the workaround is triggered. But then it isn’t really required unless someone manually launches CWHelper.exe in the data folder because in that circumstance CWHelper won’t have any (easy) way of finding CW_EPG’s actual folder path, unlike when it’s launched by CW_EPG or the Store package’s CWHelper launcher with that path as the “start in” folder. IOW it’s a failsafe for manual user intervention of the workaround configuration only.
The goal here was to change the way the three paths (cwepg executable path, hdhr executable path, and application data path) are assigned when CwHelper starts. It's complicated by the fact that we're trying to run on XP through Windows 11. Security measures, presumably, prevent Windows 11 from using the earlier technique of Windows registry access. So a text file that was originally created to enable testing on non-production systems has been leveraged to work around the Windows registry issue.
See emails from 11/8/2024 +/-: