Please see the comment from mailto:roc+moz@cs.cmu.edu regarding use of AllocConsole() API (http://msdn.microsoft.com/library/psdk/winbase/conchar_6smd.htm) to dynamically create a Windows console. This may permit us to accept a -console option so that users can choose to see the console output in release builds.

You can sneak this into M14 but I'm gonna set the milestone to M15. OK?

Correct. The only reason I didn't target it there myself is because there's no Target Milestone field on the Create Bug form.

From the docs, it looks like stdout is set up by AllocConsole. Unless there's something special going on in NSPR, you shouldn't have to do much more than else if (PL_strcmp(argv[1], "-console") == 0) { #ifdef XP_PC AllocConsole(); #endif } just underneath the "-version" test in nsAppRunner.cpp. Forcing -console to be the first argument isn't too pretty, but it means you can see messages during XPCOM startup.

Sounds plausible. My concern was prompted by the mention of querying the console's handles via GetConsoleHandle() (or some such). I thought it must be trickier than first glance since you wouldn't need to query the handles if it was stdout (handle==1). But, as you say, it's a simple matter to code something up and see what happens. Thanks again, I'll test this out at some point today (hopefully).

Welcome to the wild world of Windows. Win32 file handles and POSIX-ish file descriptors are completely different creatures; to the extent that the latter are supported, it's by an emulation layer in the MSVC runtime library. Actually, your concerns are well founded. MSVCRT does not adjust its mappings of filedescriptors 0, 1, and 2 when a new console is created. The issue is quite well documented in this KB article: http://support.microsoft.com/support/kb/articles/q105/3/05.asp That article provides code that should basically solve our problems.

*** Bug 26643 has been marked as a duplicate of this bug. ***

adding paw, gbush to cc list

Without this fix our performance test scripts will not run.

Note: if you have a "cat" binary on your Windows box, then you can see the console by starting a shell, then running "mozilla | cat".

Unfortunately "mozilla | cat" doesn't work on Win9x because of COMMAND.COM braindamage. I will attach "mozcon.exe" which runs mozilla and does its own piping to standard output --- just copy to the mozilla/bin directory and run "mozcon.exe" instead of "mozilla.exe". This should be a reasonable workaround for anyone who stumbles over this bugzilla bug ... if it catches on someone could check it in. The code is originally due to Chris244@aol.com; he posted it to mozilla.xpfe, I made some small changes.

There is a workaround. Putting on the PDT- radar for beta1.

mozcon.exe is great for looking at the console output but I does not aid us in running our performance scripts. A number of processes are left around after running our perl scripts using mozcon.exe. Bindu wrote a program to kill the processes but it does not completely work. We still need a solution that will enable our performance scripts to work and that will be cross platform. Mozcon.exe only works for Windows.

Changing proposed priority level from beta1 to dogfood (which is higher). This is a QA performance testing blocker. Right now, improving product performance is one of our highest priority areas, and anything that blocks QA from being able to measure should be considered a dogfood QA blocker bug. To quote JimB, "You can't improve what you can't measure."

Can't QA's builds be built with the MOZ_CONSOLE option? If they're relying on Tinderbox, then one of the Win32 Tinderbox machines could build it that way. Another option would be to add a new build target "mozcon" with the same rules as "mozilla" but linked as a console app.

Putting on PDT+ radar for beta1.

I don't know anything about an XP solution. Doesn't this work OK on Linux already? Somebody else will have to help out with the Mac. I can look at this starting Wed probably.

PDT is scared by the 4/1 ETA for a dogfood bug. Can you workaround by writing to a file instead of to stdout?

I wasn't really serious about 4/1. That's April Fools Day, is all. We need a better performance measuring strategy. But this crappy one can be tweaked some more. I have all my other PDT+ bugs fixed so I'll look at this tomorrow. I dunno about the Mac, however.

Moving to M14.

I attached the patch that gets this new "-console" option working. I'd like somebody to review the code so I can get approval to check it in. The code is basically from the MSDN sites (use of AllocConsole and _open_osfhandle/_fdopen to map stdout/stderr to that console. Seems to work for me on WinNT. I will be testing on Win98 shortly. Provided that works and I get requisite review/approval, I'll be checking this in tomorrow. Thanks for all the assistance. I just hope it works for the performance testing.

Works on Win98 also.

Fix checked in this evening, you should be able to use "-console" (or "/console") in tomorrow's build.

verified 3/3 commercial windows builds