This was causing startup problems on Windows. This was noticed while testing changes for work on #1099.
It seems that on Windows, the startup exe path is absolute, and was detected as an existing file, and so the Configuration code tried to load it, resulting in an error. On Linux, the startup exe path is relative, and was not detected as an existing file, and so the Configuration code skipping trying to load it, since it assumed it was a config file that hadn't been generated yet (such as on first startup). Hence the error was missed on Linux.
The reason for the difference in determining if the file exists, was that relative paths are appended to each entry of the search list, whereas an absolute path replaces it completely. The relative path of the executable file was from the project folder, but the search list only included the "data" subfolder of the project folder, hence the relative path was off by one level to the executable file.
This was causing startup problems on Windows. This was noticed while testing changes for work on #1099.
It seems that on Windows, the startup exe path is absolute, and was detected as an existing file, and so the
Configurationcode tried toloadit, resulting in an error. On Linux, the startup exe path is relative, and was not detected as an existing file, and so theConfigurationcode skipping trying toloadit, since it assumed it was a config file that hadn't been generated yet (such as on first startup). Hence the error was missed on Linux.The reason for the difference in determining if the file exists, was that relative paths are appended to each entry of the search list, whereas an absolute path replaces it completely. The relative path of the executable file was from the project folder, but the search list only included the "data" subfolder of the project folder, hence the relative path was off by one level to the executable file.