Merge pull request #5 from ebarboni/cleanupbuild
cleanup launchers
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;
}
}
