Merge pull request #4 from eirikbakke/fixCharsetWarning

Windows: Allow NetBeans to run with non-ASCII path in some cases
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 ).
+    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;