RenderKit/oidn

International Paths Not Supported for Module Loading on Windows

joelrandria opened this issue · 6 comments

joelrandria commented

Hello,

I wanted to bring to your attention an issue related to dynamic module loading (OpenImageDenoise_device_*.dll) on Windows. It appears that this functionality does not work as intended when the paths of OIDN's DLLs contain characters that are not supported by the current ANSI codepage.

As an example, when attempting to run the official oidnTest 2.0.1 binary from a directory with Japanese characters in its path on my French Windows 11 system, I encounter the following problem:

C:\Users\MyUser\Desktop\oidnTest-i18n\テスト\oidn-2.0.1.x64.windows\bin>oidnTest.exe

oidnTest.exe is a Catch v2.13.6 host application.
Run with -? for options

-------------------------------------------------------------------------------
buffer
-------------------------------------------------------------------------------
C:/GA/intel/001/_work/_temp/w/apps/oidnTest.cpp(98)
...............................................................................

C:/GA/intel/001/_work/_temp/w/apps/oidnTest.cpp(101): FAILED:
  REQUIRE( bool(device) )
with expansion:
  false

-------------------------------------------------------------------------------
single filter
-------------------------------------------------------------------------------
C:/GA/intel/001/_work/_temp/w/apps/oidnTest.cpp(204)
...............................................................................

C:/GA/intel/001/_work/_temp/w/apps/oidnTest.cpp(210): FAILED:
  REQUIRE( bool(device) )
with expansion:
  false

-------------------------------------------------------------------------------
multiple filters
-------------------------------------------------------------------------------
C:/GA/intel/001/_work/_temp/w/apps/oidnTest.cpp(286)
...............................................................................

C:/GA/intel/001/_work/_temp/w/apps/oidnTest.cpp(289): FAILED:
  REQUIRE( bool(device) )
with expansion:
  false

...

While I'm not certain about its potential effectiveness, it's worth considering a solution involving the utilization of the Windows Unicode API instead of the legacy ANSI API for module loading. Making this transition, such as changing instances of core/module.cpp: GetModuleHandleExA(...) to GetModuleHandleExW(...) and GetModuleFileNameA(...) to GetModuleFileNameW(...), could potentially resolve the issue.

Thank you for your ongoing support.

Best regards,

Joël

atafra commented

Hi. Thanks for bringing this to our attention. We'll look into it soon!

  • 👍1
joelrandria commented

Hi!

Is there any update on this subject ?

Best,

Joël

atafra commented

Hi. It will be fixed in the next release.

  • 👍1
joelrandria commented

Great news!

Thanks a lot for your support!

  • 👍1
atafra commented

Fixed in v2.1.0.

  • 👍1
joelrandria commented

Great news! Thanks for the fix :)

  • 👍1