For bug #20738 a possible fix could work like this:
- Find the place in code, where Freeciv determines the (last) directory in its default FREECIV_DATA_PATH and FREECIV_SCENARIO_PATH.
- Only for Windows replace it by the data- or data/scenarios-subdirectories of the binary. This is of course the same as ./data or ./data/scenarios if the current working directory is the directory of the binary, but the goal (on Windows) is to start Freeciv in another (=writable) directory, say, ~/.freeciv/2.x for version 2.x, where it can create RPT-, stderr-, stdout-, or map-color-test-files as it sees fit.
- Let the shortcuts to the xyz.cmd scripts (at the moment client+server+modpack, more to be added) in the Windows start menu use ~/.freeciv/2.x as working directory. At the moment this would fail, because Freeciv doesn't find its own data-subdirectory.
- Until point (2) is fixed replace all xyz.cmd by one this.cmd as suggested in bug #22781: The this.cmd has to define a FREECIV_DATA_PATH + FREECIV_SCENARIO_PATH + QT_PLUGIN_PATH (only if they don't already exist, of course) for this purpose, and the NSIS installer copies this.cmd to all required xyz.cmd. It's always the same pattern, xyz.cmd sets a LANG=%1 unless %1 is auto, and then it starts xyz.exe with the same name in the same directory and the rest of the arguments (limited to %2 .. %9 at the moment, but already extended to the rest of the command line in a this.cmd preview attached to bug #22781.)