MantisBT - Doomseeker
View Issue Details
0003706Doomseeker[All Projects] Bugpublic2019-08-28 17:582020-01-27 22:11
Zalewa 
Zalewa 
lowmajoralways
needs testingopen 
MicrosoftWindowsXP/Vista/7
1.3 
1.3.1 
0003706: Non-ASCII characters in path prevent the plugins from being loaded on Windows
Plugins from the /engines/ directory are not being loaded correctly on Windows when Doomseeker is in a path with non-ASCII characters.

Doomseeker properly detects the presence of the DLL files but it appears that the LoadLibrary() WinAPI function has problem with actually opening the DLL.
1. Put Doomseeker in a path with non-ASCII characters in it, such as C:\ąść\doomseeker\
2. Run C:\ąść\doomseeker\doomseeker.exe
3. Discard the failure to load the plugins error (if any) and inspect logs.
No tags attached.
Issue History
2019-08-28 17:58ZalewaNew Issue
2019-08-29 19:23WubTheCaptainStatusnew => acknowledged
2019-08-30 16:20ZalewaAssigned To => Zalewa
2019-08-30 16:20ZalewaStatusacknowledged => assigned
2019-08-30 16:39ZalewaNote Added: 0021014
2019-08-30 16:39ZalewaStatusassigned => needs testing
2019-09-02 07:36Blzut3Note Added: 0021015
2019-09-02 16:18ZalewaNote Added: 0021016
2019-09-02 16:19ZalewaNote Edited: 0021016bug_revision_view_page.php?bugnote_id=21016#r12817
2019-10-06 08:56ZalewaNote Added: 0021056
2020-01-27 20:54WubTheCaptainTarget Version1.4 => 1.3.1
2020-01-27 22:11WubTheCaptainNote Added: 0021129

Notes
(0021014)
Zalewa   
2019-08-30 16:39   
This has turned out to be an easy fix, just needed to change LoadLibrary() to LoadLibraryW():https://bitbucket.org/Doomseeker/doomseeker/commits/66e3062320b4dc6d52525dcd4f964228f07657d1 [^]

Update with this fix is available on the beta auto-update channel.
(0021015)
Blzut3   
2019-09-02 07:36   
While that fix is probably just fine, is there a chance that we should be adding some flag to compile Doomseeker in Unicode mode?
(0021016)
Zalewa   
2019-09-02 16:18   
(edited on: 2019-09-02 16:19)
From what I see the `A` variant of LoadLibrary() can also work if the string is converted to a local 8-bit string rather than to UTF-8:

// Both work
d->library = LoadLibraryW(nativeFilePath.toStdWString().c_str());
d->library = LoadLibraryA(nativeFilePath.toLocal8Bit().constData());


In regards to your question, from what I can discern the "Character Set" compiler flag in the MSVC actually controls only whether a `#define _UNICODE` is implicitly added. This #define, in turn, controls whether the various WinAPI #defines resolve to the `A` or the `W` variant. In this case: `LoadLibrary` is a preprocessor macro that can either resolve to `LoadLibraryA` or `LoadLibraryW`. If you pass to it a TCHAR string (another macro that expands to char or wchat_t) you can control the ANSI or widestring variants with a compiler flag. In Doomseeker I simply explicitly chose to use the widestring variant.

Nevertheless, I missed an important remark in MSDN that states that backslashes should be used in the path instead of forward slashes. So, adjustment for that is here:https://bitbucket.org/Doomseeker/doomseeker/commits/a4dfeee1abefddfcec79aee55f0405c92866adff [^]

Moreover, this exists:https://doc.qt.io/qt-5/qlibrary.html [^]
Unless QLibrary will bring back 0003401, we should consider using that instead of the native API functions.

(0021056)
Zalewa   
2019-10-06 08:56   
QLibrary seems to do the job very well in regards to loading the plugin DLLs and also it hides the Windows pop-up messages by default. Therefore I've removed all of the OS #ifdefs and Windows specific code from pluginloader.cpp:

https://bitbucket.org/Doomseeker/doomseeker/commits/d81e50682a11705420753ad9691f81bb1d86300e [^]
(0021129)
WubTheCaptain   
2020-01-27 22:11   
This went out to 1.3.1 release. I don't have a Windows operating system, sorry; Can anyone confirm this to be resolved, please?