Closed Bug 26103 Opened 25 years ago Closed 25 years ago

[FEATURE] Add command line option to cause Windows console output to appear.

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: law, Assigned: law)

References

Details

(Whiteboard: [PDT+] Feb29 (fix available; waiting for review))

Attachments

(3 files)

The mozcon.exe binary executable; put in your mozilla/bin directory
24.00 KB, application/octet-stream
Details
source code for mozcon.exe (mozcon.c)
1.98 KB, text/plain
Details
Patch to add support for -console option.
2.59 KB, patch
Details | Diff | Splinter Review 
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?
Target Milestone: M15
Correct.  The only reason I didn't target it there myself is because there's no 
Target Milestone field on the Create Bug form.
Status: NEW → ASSIGNED
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.
Keywords: beta1
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.
Whiteboard: [PDT-]
Blocks: 11349
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.
Whiteboard: [PDT-]
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."
Keywords: beta1 → dogfood
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.
Whiteboard: [PDT+]
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.
Whiteboard: [PDT+] → [PDT+] Apr01
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.
Whiteboard: [PDT+] Apr01 → [PDT+] Feb28
Moving to M14.
Target Milestone: M15 → 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.
Whiteboard: [PDT+] Feb28 → [PDT+] Feb29 (fix available; waiting for review)
Fix checked in this evening, you should be able to use "-console" (or 
"/console") in tomorrow's build.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
verified 3/3 commercial windows builds
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: