Sorry for the delayed response. I've been busy. (Probably I should not have volunteered for this review.)
Heiko, thanks for the patch. JDK engineers (Xueming, Alan?) will need to help with testing, architectural issues, and shepherding. I no longer use windows. I approve of the general approach being taken here. We need a general purpose version of JVM_NativePath, as you have coded it up, but it needs to go into some shared location for use by other JDK native code - not sure quite where that would be. I guess until we have another client for it, living in ProcessImpl_md.c is not so bad. Make sure you run the java.lang regression tests, especially ProcessBuilder/Basic.java There's a fair bit of cleanup that will be required. Use of white space and commenting style are non-standard and will need to be fixed (even if you've copied them from other parts of the JDK) I think the spec for free() guarantees that free(null) is a no-op, and the JDK already relies on this, so no need for releaseStringCopy. Typos/suggestions: path.md.c => path_md.c *(res + len) = 0; => res[len] = L'\0'; Martin On Mon, Mar 9, 2009 at 02:57, Heiko Wagner <heiko.wag...@apis.de> wrote: > This is related to my previous post at > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001145.ht > ml and my first contribution to the JDK7 project. As Martin suggested, I > have worked on a wide char version of ProcessImpl_md.c. For discussion of my > proposed chages a copy of my source can be found at: > > http://www.apis.de/pub/jdk7/ProcessImpl_md.c > > and a diff at: > > http://www.apis.de/pub/jdk7/ProcessImpl_md.c > > This patch enables launching executables residing on a path containing > non-ansi characters. My next goal is to get the java launcher working on a > unicode path. I think this needs additional coordination with the hotspot > team, since some of the code in os.cpp also has issues in a unicode path > when loading verify.dll and java.dll. > > Regards > Heiko > >
