Community
Participate
Working Groups
Build 20020409 Platform: Windows XP with GB18030 patch VM: IBM JRE 1.4.0 When eclipse is installed in a directory containing GB18030 characters, it fails to start. If you just invoke eclipse.exe, the launcher complains that it could not figure out the -ws value, then it exits. If you launch with "eclipse -ws win32, the java console quickly flashes then exits. Putting debug statements in the Eclipse Java entry point (UIMain.main()) indicates that this method is never entered. There is possibly a problem with the eclipse.exe launcher code when running in this configuration. There is a machine set up in the war room with this configuration, see me for more info.
We claim we support GB18030 on win2K so this is a serious issue. KC to investigate. Talk to SSQ about what is required w.r.t. constructing file paths etc. (and to test).
See bug http://bugs.eclipse.org/bugs/show_bug.cgi?id=7711 for a similar problem once the VM is launched.
I'm not sure what the GB18030 patch does to the XP file system but if the launcher indicates it cannot determine the WS GUI (-ws) then basically the file <installDir>\plugins\org.eclipse.swt\ws\win32\swt.jar does not exist. If the launcher cannot find the jar file then forcing Eclipse to run with "-ws win32" is probably not a good idea. So the question is why can't the launcher find the JAR file. Possible reasons (some of these are WAGs): 1) The installation of Eclipse is not correct such that one or more of the directories in the path either don't exist (renamed) or the JAR file does not exist. 2) The launcher uses 8-bit characters to define its file paths that are passed as arguments to stat() (which is used to find swt.jar) and to _spawnv() (which is used to start the JVM). If this patch somehow changes the underlying implementation of these functions to use wide characters or multi-byte characters (kernel32.dll) then these functions might fail. When the launcher is run, it uses argv[0] to determine the installation directory and then appends the subdirectory info. If the strings passed to main(argc,argv**) are now wide character strings, the launcher append 8-bit characters and the resulting string would not be recognized. According to MSDN, _stat() automatically supports MBCS but I'm not sure of _spawnv(). 3) The installation of the patch may changethe default character encoding (e.g., current code page). A string of bytes defined in ISO 8859-1 may not be recognized as valid characters with a different encoding. Personally I have not worked with multi-byte character or wide character strings so the above suggestions might be completely wrong. Take it with a grain of salt.
More information is available here: http://www.microsoft.com/GLOBALDEV/DrIntl/015/default.asp#Q5 Note that I reproduced this problem after applying a fix for bug 7711 that was working on Japanese Windows. They seem to be different problems.
There are two problems here. First, the java VM can not be started from the directory containing GB18030. It exists reporting that java.lang.Object can not be found. Second, the launcher fails to determine the WS because the C function stat() fails. The following C program fails the same way. ++++++++++++++++++++++++main.c+++++++++++++++++++++++++++++++ /* compile line: cl -o test main.c */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/types.h> #include <sys/stat.h> #define MAX_PATH_LENGTH 2000 int main( int argc, char* argv[] ){ struct stat stats; char *cmdPath; int result, length; length = MAX_PATH_LENGTH + 1; cmdPath = malloc( length + 1 ); getcwd( cmdPath, length ); printf("cmdPath=%s\n", cmdPath); result = stat( cmdPath, &stats ); printf("result=%d %s\n", result, result == 0 ? "success" : "failed"); free(cmdPath); } ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ KH to forward this to the GB18030 expert.
What do you mean when you say, "the java VM can not be started from the directory containing GB18030"? I tried a simple Hello World program in the same directory and it worked with a 1.4 VM. 1.3 VMs, on the other hand, fail on even Hello World, so it's probably not worth trying to get eclipse working there.
Please show the functioning VM to SSQ. We ran what we believe to be the VM you described and got the missing java.lang.Object message. Q: Did you cd to the directory using the "short" (8.3) version of the directory name, or the long version?
Please note that the response from me is actually from Silenio Quarti - he was responding logged in as me.
My comment wasn't precise enough. Hello World runs fine when the program being executed is located in a directory containing GB18030 characters. It fails to start with the missing java/lang/Object message when the VM is located in a directory containing GB18030 characters. Here is the directory structure (fa63~1 is the 8.3 equivalent of the GB18030 directory name): d:\0404\eclipse -> normal install plus jre d:\0404\fa63~1\eclipse -> normall install of eclipse + jre d:\0404\fa63~1\B.class -> A hello world program Here is what I did from the command prompt: > cd\0404\fa63~1 > eclipse\jre\bin\java.exe A -> fails > ..\eclipse\jre\bin\java.exe A -> works fine
So... We believe that it's possible to run java code as long as the path to the java VM doesn't include a GB-18030 character. This is a pain, but potentially something which can be worked around (i.e. the user would need to install his VM in a safe directory). We are still unable to make progress on the launcher issue without the answer to SSQ's question (i.e. the C code above). Waiting on reply from KH's contact.
On Windows (2000 and XP), GB18030 filename support requires a unicode version of the launcher executable. The 'A' ansi functions on Windows don't support GB18030. The 'W' ones (unicode) do. A unicode version of the launcher executable has been added to the 'platform- launcher' project. The executable is called 'eclipse18030.exe'. It should be used on Win2000/XP machines when the installation path of eclipse contains GB18030 characters. Current JVMs fail to support GB18030 filenames. The eclipse18030.exe should be retested when we have a VM able to support them. The VM needs to be able to pass 2 tests: - run from within a directory containing GB18030 characters - Runtime.exec must handle arguments containing GB18030 characters correctly (see Tod Creasey's tests) Platform note: 1) Win 95/98/NT4 do NOT support GB18030. (from Microsoft: http://www.microsoft.com/GLOBALDEV/DrIntl/015/default.asp#Q5) 2) eclipse18030 must not be used on Win95/98. It will not work because those 2 platforms do not support the unicode api it depends on.
Update: The default eclipse.exe has been re-coded to distinguish unicode- supporting platforms from non-unicode-supporting platforms. It calls the "W" calls on Unicode platforms and the "A" calls otherwise. Thus no separate launcher is needed.
The win32 launcher now handles both unicode and non-unicode systems. Thus Eclipse should start with the GB18030 patch on Windows XP.
