Fix DLL load failure on Windows for paths containing non-ANSI characters

[baijumeswani]

The JS SDK's native add-on fails to load onnxruntime.dll (and other dependency libraries) when the path contains characters outside the active Windows ANSI code page. Customers running the SDK from a profile directory with non-ascii characters see:

Failed to load dependency library: C:\Users\<non-ascii-name>\…\onnxruntime.dll

sdk/js/native/foundry_local_napi.c used LoadLibraryA, which interprets the path bytes as the active ANSI code page. N-API hands us a lossless UTF-8 string, but LoadLibraryA then mis-decodes those bytes and the loader returns ERROR_MOD_NOT_FOUND.

This pull-request routesWindows library loads through LoadLibraryW with a UTF-16 path fetched via napi_get_value_string_utf16. POSIX behaviour is unchanged (dlopen is already UTF-8).

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
foundry-local	Ready	Preview, Comment	May 29, 2026 7:39pm

[Copilot]

Pull request overview

This PR fixes a Windows-specific DLL loading failure in the JS SDK’s native N-API add-on when library paths contain characters outside the active ANSI code page, by routing Windows loads through LoadLibraryW using UTF-16 paths sourced from N-API.

Changes:

• Introduces open_lib_from_napi() to load libraries from N-API string values, using LoadLibraryW on Windows and dlopen on POSIX.
• Updates loadLibrary(corePath, depPaths?) to use the new helper for dependency and core library loading.
• Removes the LoadLibraryA-based LIB_OPEN macro usage and documents the rationale.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.