Starting in the warmup to 3.3M7 there is a second launcher on Windows: eclipsec.exe.
The Eclipse launchers in 3.3 have had issues with various aspects of the console on Windows. See some bugs: 146807, 167310, 168726, and 173962.
All of our problems came from the fact that the eclipse.exe was linked as a UI application and not a console application. In 3.2, the console behaviour was tied to using java.exe instead of javaw.exe, but starting in 3.3 M5, the vm is loaded in the eclipse process using the JNI Invocation API.
So just like javaw/java, we now have eclipse/eclipsec. Eclipsec.exe is linked as a console application so that the OS handles allocating the console for us. Using eclipsec.exe does not imply any default arguments, so you still need to specify things like -console and -consoleLog.
3 comments:
I come from a Unix/Linux world. I've never understood the rationale in the Windows world for having an app that's a GUI app OR a console app.
This fix seams like a very good thing for Windows Eclipse users but it seams dumb to me that this fix had to be done in the first place.
Except it doesn't work if you change the launcher name and ini file. It still looks for the eclipse.ini file. Sigh. More proof that code rusts.
The name of the ini file is derived from the program name, see eclipseConfig.c/getIniFile.
The program name is take from argv[0].
On windows, the trailing ".exe" is stripped from the program name and ".ini" is appended. If the executable is the console launcher, and this file is not found, and the program name ends with 'c' (like "eclipsec" does),
then we also try removing the 'c'.
Nowhere in the code does it explicitly check for "eclipse.ini".
Post a Comment