Describe the bug
While nearly all modern operating systems run executables using UTF-8 encoding,
operating system Windows by default still runs executables using ANSI encoding.
Using ANSI encoding, may lead to problems especially when dealing with filenames containing UTF-8 characters (German umlauts, Cyrillic letters, etc.), which cannot be mapped to currently ANSI code page used by Windows.
Windows POSIX shell by default uses system's code page. If current code page is ANSI, e.g. fopen does not handle filenames containing not contained in current ANSI code page. QMS dependency Routino still uses POSIX shell!
What have you done to circle down the problem?
To Reproduce
Currently, if QMapShack's installation folder is QMapShack_äαöω, either letters ä and ö are non-ANSI or letters α and ω are non-ANSI, depending on default code page of Windows installation.
Running command "QMapShack_äαöω/qmapshack.exe -d" gets stuck in showing splash screen and shows nothing more than
2026-07-12 14:46:33.518 [debug] Log configuration: logfile= "C:/Program Files/cygwin/tmp/org.qlandkarte.QMapShack.log" write to file= false debug output= true
[debug] Qt versions: build=6.11.1, runtime=6.11.1
[debug] Executable path: "C:/Program Files/QMapShack_ a ?/qmapshack.exe"
[debug] Argument list: "-d"
[debug] Configuration path: "\\HKEY_CURRENT_USER\\Software\\QLandkarte\\QMapShack"
[debug] "GDAL_DATA directory set to C:\\Program Files\\QMapShack_äαöω\\data"
...
[debug] "ROUTINO" path "C:/Program Files/QMapShack_äαöω/routino-xml/translations.xml"
as debug output. Program has to be killed afterwards.
Running command "QMapShack/qmapshack.exe -d --qwindowtitle QMapShack_äαöω" does not show "QMapShack_äαöω" but a string containing more or less question marks depending on ANSI code page.
Expected behavior
After forcing QMS to run using UTF-8 code page and running command "QMapShack_äαöω/qmapshack.exe -d", program starts withou problems showing debug output:
[debug] Log configuration: logfile= "C:/Program Files/cygwin/tmp/org.qlandkarte.QMapShack.log" write to file= false debug output= true
[debug] Qt versions: build=6.11.1, runtime=6.11.1
[debug] Executable path: "C:/Program Files/QMapShack_äαöω/qmapshack.exe"
[debug] Argument list: "-d"
[debug] Configuration path: "\\HKEY_CURRENT_USER\\Software\\QLandkarte\\QMapShack"
[debug] "GDAL_DATA directory set to C:\\Program Files\\QMapShack_äαöω\\data"
...
[debug] "ROUTINO" path "C:/Program Files/QMapShack_äαöω/routino-xml/profiles.xml"
[debug] Profile ... Using
"C:/Program Files/QMapShack_äαöω/routino-xml/profiles.xml"
[debug] Loaded Routino DB D:/Landkarten/QMapShack/Routino/Berlin Berlin
[debug] "ROUTINO" path "C:/Program Files/QMapShack_äαöω/routino-xml/profiles.xml"
[debug] Profile ... Using
"C:/Program Files/QMapShack_äαöω/routino-xml/profiles.xml"
[debug] CMapDraw::loadMapPath(cfg)
[debug] CDemDraw::loadDemPath(cfg)
[debug] CMapDraw::loadConfig(cfg)
[debug] CMapDraw::loadMapList(cfg)
[debug] CDemDraw::loadConfig(cfg)
[debug] CDemDraw::loadDemList(cfg)
[debug] CMapDraw::loadConfig(cfg)
...
After forcing QMS to run using UTF-8 code page and running command "QMapShack/qmapshack.exe -d --qwindowtitle QMapShack_äαöω" exactly shows "QMapShack_äαöω" as QMS toplevel window title.
Caveat:
Reading an ANSI encoded text file, e.g. a VRT file, text does not get automatically converted from ANSI to UTF-8.
ANSI encoded filenames contained in text files stay ANSI encoded and may still be treated as invalid UTF-8 filenames.
Therefore it is good practice no longer feed QMS with ANSI encoded text files.
Conversion is highly recommended and easy by Windows Powershell command:
Get-Content <Source> -Encoding Default | Out-File <Destination> -Encoding UTF8
Screenshots
Running with ANSI encoding:
Running with UTF-8 encoding:
Attachments
Tracebacks
Desktop
- OS: Windows
- QMapShack Version: any
- Window Manager: -
Additional context
An option extists since Windows 10 to switch system-wide from ANSI encoding to UTF-8 encoding.
But with possible side-effect, that existing installations not yet UTF-8 aware may then get problems.
In May 2019, Microsoft added the ability for a program to set the code page to UTF-8 itself.
Using this ability, is is possible to run QMS UTF-8 encoded without impact on other existing software.
To circumvent problems mentioned above, it is desirable that QMS runs with UTF-8 enabled on each operating system, on Windows too, and thus behaves same on each platform.
This will remove restriction not to be installed in a folder containing non-ANSI letters.
Tiny but significant addition to CMakeLists.txt forces to build executables running with UTF-8 encoding without need to enable system-wide UTF-8 encoding. This is achieved by an additional linker instruction to embed an appropriate manifest into executable.
Describe the bug
While nearly all modern operating systems run executables using UTF-8 encoding,
operating system Windows by default still runs executables using ANSI encoding.
Using ANSI encoding, may lead to problems especially when dealing with filenames containing UTF-8 characters (German umlauts, Cyrillic letters, etc.), which cannot be mapped to currently ANSI code page used by Windows.
Windows POSIX shell by default uses system's code page. If current code page is ANSI, e.g. fopen does not handle filenames containing not contained in current ANSI code page. QMS dependency Routino still uses POSIX shell!
What have you done to circle down the problem?
To Reproduce
Currently, if QMapShack's installation folder is QMapShack_äαöω, either letters ä and ö are non-ANSI or letters α and ω are non-ANSI, depending on default code page of Windows installation.
Running command "QMapShack_äαöω/qmapshack.exe -d" gets stuck in showing splash screen and shows nothing more than
as debug output. Program has to be killed afterwards.
Running command "QMapShack/qmapshack.exe -d --qwindowtitle QMapShack_äαöω" does not show "QMapShack_äαöω" but a string containing more or less question marks depending on ANSI code page.
Expected behavior
After forcing QMS to run using UTF-8 code page and running command "QMapShack_äαöω/qmapshack.exe -d", program starts withou problems showing debug output:
After forcing QMS to run using UTF-8 code page and running command "QMapShack/qmapshack.exe -d --qwindowtitle QMapShack_äαöω" exactly shows "QMapShack_äαöω" as QMS toplevel window title.
Caveat:
Reading an ANSI encoded text file, e.g. a VRT file, text does not get automatically converted from ANSI to UTF-8.
ANSI encoded filenames contained in text files stay ANSI encoded and may still be treated as invalid UTF-8 filenames.
Therefore it is good practice no longer feed QMS with ANSI encoded text files.
Conversion is highly recommended and easy by Windows Powershell command:
Get-Content <Source> -Encoding Default | Out-File <Destination> -Encoding UTF8Screenshots
Running with ANSI encoding:
Running with UTF-8 encoding:
Attachments
Tracebacks
Desktop
Additional context
An option extists since Windows 10 to switch system-wide from ANSI encoding to UTF-8 encoding.
But with possible side-effect, that existing installations not yet UTF-8 aware may then get problems.
In May 2019, Microsoft added the ability for a program to set the code page to UTF-8 itself.
Using this ability, is is possible to run QMS UTF-8 encoded without impact on other existing software.
To circumvent problems mentioned above, it is desirable that QMS runs with UTF-8 enabled on each operating system, on Windows too, and thus behaves same on each platform.
This will remove restriction not to be installed in a folder containing non-ANSI letters.
Tiny but significant addition to CMakeLists.txt forces to build executables running with UTF-8 encoding without need to enable system-wide UTF-8 encoding. This is achieved by an additional linker instruction to embed an appropriate manifest into executable.