wxStandardPaths::Get() in 8.3 format

[Rob']

I want to read an INI file, which has the same name as the executable file but with the extension INI, and is in the same directory. For this I do the following:

Code: Select all

wxFileName filename(wxStandardPaths::Get().GetExecutablePath());
filename.SetExt("ini");

The filename of my executable file is longer than 8 characters. In realease mode this works, but in debug mode the filenames are reported in 8.3 format. So MYFILENAME.EXE is reported as MYFILE~2.EXE and MYFILENAME.INI as MYFILE~1.INI. After changing the extension to INI, I have a filename MYFILE~2.INI, which does not exist.
Why is there a difference between debug and release mode? How can I force the long format?

Thanks in advance.
Rob'

[PB]

The build configuration (Debug vs Release) cannot have such an effect. I bet you cannot reproduce this in a minimal code sample or the bundled widgets sample (with DirCtrl - check the folder names in the log window after clicking on different standard paths).

If so, please provide the details, including the exact platform used and the way you built wxWidgets.

[Rob']

We are using wxWigets 3.1.5 under Windows 10 and 11. For debug version we are using the binaries from the wxWidgets website, built with TDM-GCC 9.2. The release libraries (monolithic) are created by ourselves.

[PB]

I do not use TDM-GCC but if you can reproduce the issue in the minimum code or in the bundled sample, it must be issue with the library build (or using it with your compiler). But I cannot think why this would happen.

I would avoid TDM-GCC, it is known to have bugs manifesting when used with wxWidgets (see e.g. here). The bug has a work-around in 3.2.2 and newer wxWidgets.

Truth to be told, both wxWidgets 3.1.5 and TDM-GCC are obsolete and should not be used if at all possible.

[Rob']

For testing I used the wxWidgets Application Template, which is created by Code::Blocks. These 2 lines I have added to the GUIFrame constructor:

Code: Select all

  wxString str = wxStandardPaths::Get().GetExecutablePath();
  wxMessageBox(str);

The problem only occurs, if I debug the code. If I run the app in debug mode w/o debugging, the path is shown in the long format.

[PB]

FWIW, I cannot reproduce it using Code::Blocks 20.03 with self-built wxWidgets 3.1.7 (as 64-bit DLL, using MSYS2 mingw-64 package with GCC 12.2).

The path is correct both in the message box and when viewed in the C::B debugger (as well as GDB).

I do not have wxWidgets 3.1 older than 3.1.7 (nor do I have TDM-GCC build), but I doubt the issue is there as this were a wxWidgets bug, it would likely manifest in the Release build as well.

My advice would be to use wxWidgets built in the similar manner both in Debug and Release configurations.

[ONEEYEMAN]

Hi,
Please build both configuration yourself with exact same options (difference should be only Debug vs. Release), then build your application in both variants.

You can't possibly try to build application with the different sets of libraries and expect the same behavior.

Thank you.

[Rob']

The differences are already in the debug build: If I start it w/o debugging, then it is okay. If I debug the same app, then I get the path in 8.3 format.

[PB]

How would you explain that running your executable under the debugger can result in a different path format returned by Win32 API?

[Rob']

I can't explain it, hence my question here.

[PB]

I have installed TDM-GCC 9.2

Code: Select all

c:\TDM-GCC-32\bin>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/TDM-GCC-32/bin/../libexec/gcc/mingw32/9.2.0/lto-wrapper.exe
Target: mingw32
Configured with: ../../../src/gcc-git-9.2.0/configure --build=mingw32 --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-libgomp --enable-lto --enable-graphite --enable-libstdcxx-debug --enable-threads=posix --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libstdcxx-threads --disable-build-format-warnings --enable-libstdcxx-time --with-gnu-ld --disable-werror --enable-nls --disable-win32-registry --disable-symvers --enable-large-address-aware --enable-cxx-flags='-fno-function-sections -fno-data-sections -DWINPTHREAD_STATIC' --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --enable-checking=release --prefix=/mingw32tdm --with-local-prefix=/mingw32tdm --with-pkgversion=tdm-1 --enable-sjlj-exceptions --with-bugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: posix
gcc version 9.2.0 (tdm-1)

Downloaded, unpacked wxWidgets-3.1.5.7z and wxMSW-3.1.5_gcc920TDM_Dev.7z, and made it used in the C::B template project:

Code: Select all

windres.exe -IC:\dev\libs\wxWidgets-3.1.5-TDM-GCC\include -IC:\dev\libs\wxWidgets-3.1.5-TDM-GCC\lib\gcc_dll\mswud  -J rc -O coff -i C:\dev\cb-tests\TESTPA~1\resource.rc -o obj\Debug\resource.res
g++.exe -pipe -mthreads -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE -Wall -g -D__WXDEBUG__ -IC:\dev\libs\wxWidgets-3.1.5-TDM-GCC\include -IC:\dev\libs\wxWidgets-3.1.5-TDM-GCC\lib\gcc_dll\mswud -c "C:\dev\cb-tests\test paths-tdm-gcc\test_pathsApp.cpp" -o obj\Debug\test_pathsApp.o
g++.exe -pipe -mthreads -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE -Wall -g -D__WXDEBUG__ -IC:\dev\libs\wxWidgets-3.1.5-TDM-GCC\include -IC:\dev\libs\wxWidgets-3.1.5-TDM-GCC\lib\gcc_dll\mswud -c "C:\dev\cb-tests\test paths-tdm-gcc\test_pathsMain.cpp" -o obj\Debug\test_pathsMain.o
g++.exe -LC:\dev\libs\wxWidgets-3.1.5-TDM-GCC\lib\gcc_dll -o bin\Debug\test-paths.exe  obj\Debug\test_pathsApp.o obj\Debug\test_pathsMain.o obj\Debug\resource.res -mthreads  -lwxmsw31ud_core -lwxbase31ud -mwindows
Output file is bin\Debug\test-paths.exe with size 2.47 MB

Still getting a long name.

BUT, there is a difference depending on the debugee full path. If there is not a space in the path (even if I have a long name there), I get the long name, C::B launched GDB like this:

Starting debugger: C:\TDM-GCC-32\bin\gdb32.exe -nx -fullname -quiet -args C:/dev/cb-tests/test-paths-tdm-gcc/bin/Debug/test-paths.exe

But if I have a space there (a space instead of a dash in the executable name here, i.e., "test paths.exe" vs "test-paths.exe"), then I get the short name since C::B launches GDB like this:

Starting debugger: C:\TDM-GCC-32\bin\gdb32.exe -nx -fullname -quiet -args C:/dev/cb-tests/TEST-P~2/bin/Debug/TESTPA~1.EXE

This looks as a C::B problem to me and it happens with GCC 12.2 as well. I would check if your executable full path in the debug build also does not have a space in it, unlike the one in the release build.

[Rob']

That is exactly the case. Some of the subdirectories have spaces in their name. I will check the behavior in release mode tomorrow morning.

[PB]

FWIW, I have asked about this on C::B forums: https://forums.codeblocks.org/index.php ... #msg171650

[Rob']

That means no solution from C::B. As a workaround I have choosen a different filename and shorter or equal than 8 characters for my INI file. I pass this filename as an argument to the executable. So it works also for debugging.

Thanks again.

[PB]

Regardless of C::B issues, you could also follow the standard practice and do what wxConfig does:
1. Set the application name and vendor via wxApp methods.
2. Store the config file in wxStandardPaths::GetConfigDir(), using a preset file name.

Even if your application is working only as a portable, the config file name probably does not need to be based off that of the executable. As a workaround, you could use wxFileName::Normalize(wxPATH_NORM_LONG) with the short name but I would try hard to avoid doing that.

Moreover, as suggested on the C::B forums, you could report this as a C::B issue and it may get fixed.