diff --git a/src/main/cpp/ide/nblauncher.cpp b/src/main/cpp/ide/nblauncher.cpp
index 338e7a7..2bd940e 100644
--- a/src/main/cpp/ide/nblauncher.cpp
+++ b/src/main/cpp/ide/nblauncher.cpp
@@ -183,10 +183,43 @@
 
     baseDir = path;
     
-    //check baseDir for non-ASCII chars
+    /* The JavaVMOption.optionString interface forces us to stick to ANSI
+    strings only, using whichever codepage is the default on the current Windows
+    installation (e.g. windows-1252 for US Windows). For any Unicode characters
+    that cannot be encoded using the current ANSI codepage, Win32 functions
+    such as GetModuleFileName (used by getCurrentModulePath) and
+    GetCurrentDirectory will substitute a question mark, which we detect here.
+    Note that the ANSI codepage is a superset of ASCII; it can accomodate a
+    limited selection of international characters that Microsoft once considered
+    appropriate for the current Windows locale.
+
+    It would be easy enough to switch the launcher process to UTF-8 everywhere;
+    this can be configured from the manifest file
+    (see https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page ).
+    String types in these sources could remain as "char *" rather than
+    wchar_t. The problem is that JNI will still seems to expect parameters to be
+    passed using the default Windows codepage.
+
+    I tried setting UTF8 in the manifests and using the --fork-java parameter
+    to use the old CreateProcess launcher rather than JNI, but this still
+    causes a "Could not find or load main class org.netbeans.Main" error. I
+    also tried doing MultiByteToWideChar from UTF8 to wchar_t and calling
+    CreateProcessW; it does not fix the problem even though changing the command
+    line to prefix "cmd /c echo" causes my Cyrillic test character to show up
+    correctly on the Windows command line.
+
+    Other approaches which were attempted, but demeed too fragile:
+    1) Set the current directory to baseDir and pass relative paths only.
+       (Still led to ClassNotFoundException from ProxyClassLoader, which would
+       have needed to be fixed. And doesn't work e.g. for the home directory,
+       e.g. if the username itself has problematic characters in it.)
+    2) Using the GetShortPathNameW function to get an equivalent
+       Windows 95 style "8.3" compatibility path (e.g. "C:\Users\CHARTE~1").
+       This worked, but is too likely to create problems down the line.
+    */
     for (size_t i = 0; i < baseDir.size(); ++i) {
-        if (!(baseDir[i]>=' ' && baseDir[i]<='~')) {
-            logErr(false, true, "Cannot be run from folder that contains non-ASCII characters in path.");
+        if (baseDir[i] == '?') {
+            logErr(false, true, "Cannot run in this folder; the path \"%s\" contains problematic characters.", path);
             return false;
         }
     }