The former has been "unsupported" since Windows XP, while the latter is
still supported in Vista and later as a wrapper around a newer API.
Most importantly, used this as an excuse to rewrite the code to take
advantage of the fact that we already link to SHELL32.DLL at runtime
(it implements ShellExecute() and Shell_NotifyIcon(), used elsewhere in
our code), only run on versions of Windows guarantee to provide the
SHGetFolderPath symbol, and thus don't need all the LoadLibrary mumbo
jumbo that made the code considerably uglier and denser.
This allows asking Wesnoth to store user files in a directory relative
to the install dir if wanted on Windows (e.g. for portable installs to
removable media where the absolute path to the install dir is not
constant or under the user's control).
Use Documents\My Games\WesnothX.Y for user config data on Windows like
we currently do when using --config-dir there with a relative path. The
behavior of --config-dir when passed a relative path remains unchanged
with this commit, making the new out-of-the-box default equivalent to
passing --config-dir WesnothX.Y, except this is now enforced by Wesnoth
rather than a finicky installer option.
See bug #23753 for the rationale behind this change.
People who really can't live without the old CWD\userdata layout should
either use --config-dir with an absolute path to their existing userdata
dir, or wait for the next commit (which will help with "portable"
installs to removable devices, for example).
This has two advantages: first, it enforces a help style which is consistent across the various tools; second, it makes easier adding new command line options.
Another interesting fact is that those options requiring additional parameters do not need the equal sign any more; that is, writing --foo=bar is now the same as writing --foo bar.
Otherwise we build a bogus "terrain/.png" file path and produce spurious
`error display: could not open image 'terrain/.png'` messages in stderr.
Although this is primarily an issue found with certain special overlay
terrains such as ^Xo (Impassable Overlay), this fix covers base terrains
as well.
Those are sometimes relevant (for example, empty WML variables or
containers/arrays). We don't want to conceal the truth here because this
is supposed to be a debugging aid.
