Community
Participate
Working Groups
The attached patch adds a console for the equinox launcher on win32. However, it is not working with 1.4 VMs. The Java stdout, stdin, and stderr stream do not seem to be properly connected to the console. This seems to be the problem described here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4994125 Which implies the problem may come from mixing C runtime models. However, as far as I can tell, we are linking dynamically with MSVCRT.dll as we should be.
Created attachment 55346 [details] patch to add console
I'm not sure if this is related but we have issues when connecting to the input/output streams from the debug console when launching from eclipse also. See bug 40066. We implement a workaround in the console when osgi.dev=<anything> or when osgi.console.blockOnReady=true
Increase severity as I always use console to see debug trace. It's definitely necessary to have some information when a problem occurs while running an eclipse runtime session (in fact same severity than bug 168726...)
It appears that the patch to create a console in win32 is in 3.3M5 which I'm working with. The implementation opens a new console window even if eclipse was launched from a command prompt. In the limited test I've performed changing AllocConsole(); to if( !AttachConsole( ATTACH_PARENT_PROCESS)) AllocConsole(); } doesn't open a new console if eclipse is launched from a command prompt and "in-lines" the existing console output otherwise opens a new console if -console is specified. I'm very new to eclipse. Maybe this information can be useful.
Note: AttachConsole is only in XP and greater so if W2K is to be supported as I assume then the entry point will have to be gotten conditionally through GetProcAddress and W2K will not work the same as XP and above.
Is 'Incubator' really the right component for this bug? I see this regression in normal SDK drops, so I guess the bug should be moved to 'Framework' (and get a Target Milestone of M6 or at least 3.3).
Yes, it should be moved to the framework component since the launcher work has been graduated from the incubator. Thanks, Markus.
*** Bug 178353 has been marked as a duplicate of this bug. ***
Changing summary to be consistent with other [launcher] bugs.
The launcher was modified to use AttachConsole if possible (bug 173962 Comment #7). However, problems still exist here. Notably, with reusing the existing console, we should be able to redirect the output (eclipse -debug > out.txt), but this isn't working.
An additional annoyance with using AttachConsole I now see is that the console advances to the next command prompt and doesn't wait for eclipse.exe to terminate. The console output from eclipse.exe does go to the console but it's not synchronized with the invocation of eclipse.exe. As a part of that, other console commands can be executed generating output while eclipse is running that will be mixed with the eclipse output. Here's and old discussion of getting output from a Win32 GUI application to the console I just found. http://blogs.msdn.com/junfeng/archive/2004/02/06/68531.aspx It identifies approaches used in two Microsoft tools. The first approach, used by MS Visual Studio 2005 (and maybe 2003) in devenv.com/.exe, seems the more interesting of the two. It's a variation of the approach previously mentioned to have a full console and non-console version of eclipse.exe. The approach instead uses a small console application .exe renamed as a .com file. The small shim application invokes the full eclipse.exe, in the eclipse case, with the redirected handles etc. The application in the .com program is a true console application so the command prompt doesn't return until the .com and by implementation of the .com the launched .exe have exited. The little trick that comes into play to make magic appear to happen is that on the commandline typing just "Eclipse" will invoke "Eclipse.com" if it exists instead of "Eclipse.exe". Even if the .com trick isn't used and a EclipseC.exe, or such, is created to launch the regular Eclipse.exe the technique is the best I've seen so far. It seems like this would be W2K compatible as the AttachConsole would be gone from the full eclipse.exe. The AllocConsole in the .exe could still remain for cases that the .exe was invoked for console output but the .exe wasn't launched by the .com shim. I'll look more into the DevEnv.com concept and come up with sample code. The sample could be pretty general and work with any .exe in the same directory by renaming the .com to to the name of the .exe to be launch. It seems like it would be best if the eclipse version also added a commandline parameter to the .exe parameters to indicate to the .exe that the console is hooked up or maybe there is a way that the .exe can detect that the console is already attached. I'll see what I can come up with. The shim seems like it will meet all the "requirements" and be version independent of the .exe it's launching. The second, used by ildasm doesn't seem usable because it puts up a console window on every launch. The console is quickly removed if it's not going to be used. It's not a good solution in my option. PS: I can't actually build the Eclipse.exe in my development environment(s). With MSVS 6 makefile I have to hide later versions of the MSVS to get the PDK setenv to point to MSVS 6. I haven't been able to get the MinGW build environment to be setup right so it will do a complete build.
Starting in I20070430-0800, we now have an eclipsec.exe which is a console linked version of the launcher. Changes for comment 10 were reverted. We decided against naming the console version eclipse.com because it was a little too much magic.
