[FEATURE] Remove Windows application console

VERIFIED FIXED in M14

Status

SeaMonkey
UI Design
P1
normal
VERIFIED FIXED
18 years ago
13 years ago

People

(Reporter: don, Assigned: Bill Law)

Tracking

({polish})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

(Reporter)

Description

18 years ago
Bill, can you get rid of the console part of the executable on Windows for the
non-debug version of apprunner?  How hard is this?
(Reporter)

Updated

18 years ago
Priority: P3 → P1
Target Milestone: M14

Comment 1

18 years ago
Can I make a suggestion? [He says as he prepares to hit the submit button ;-)]

The console window forms part of a 'development system' for XUL and to a
lesser for js/DOM (barring the resurrection of any js debugger). Removing it
entirely will raise the entry barrier for people who want to develop XUL apps
and extensions (by making it a requirement to maintain their own build of
Mozilla in order to get to js output).

[To make an analogy, it would be equivalent to a requirement for you to build
your compiler in order to write some C++. Doable but not preferable nor
efficient.]

Certainly, the console window must die for the broadly distributed, branded
client, but is there any way to maintain 'back-door' access to this facility.
(Barring that, a switch that would log stdout to a file).
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 2

18 years ago
Windows doesn't seem to permit an application to choose whether it has a console
or not.  If it doesn't (/subsystem:windows) then stdout goes to the bit bucket
unless you launch with ">some-output-file".  So that could be the "switch."
But, you wouldn't see the results till you terminated the app.

I'll see about having a second executable that could run with the console.
(Assignee)

Comment 3

18 years ago
Code complete; here are my diffs.  Note that the console is controlled by the 
MOZ_WINCONSOLE environment variable.  If not set one way or the other, then it 
defaults to 1 if MOZ_DEBUG, to 0 otherwise.

I added a stub WinMain (that simply calls main) to nsAppRunner.cpp. That 
function is required when you link with /subsystem:windows and is ignored if you 
use /subsystem:console.

I plan to check this in when M14 gets underway.

Index: makefile.win
===================================================================
RCS file: /cvsroot/mozilla/xpfe/bootstrap/makefile.win,v
retrieving revision 1.29
diff -w -r1.29 makefile.win
43d42
< !ifdef NECKO
45,47d43
< !else
<       -I$(PUBLIC)\netlib                \
< !endif
79a76,92
>
> # This code removes the console from release builds
> # (unless you've set MOZ_WINCONSOLE=1).
> !ifndef MOZ_WINCONSOLE
> !if $(MOZ_DEBUG)
> MOZ_WINCONSOLE=1
> !else
> MOZ_WINCONSOLE=0
> !endif
> !endif
>
> # Set subsystem type according to whether we want a console.
> !if $(MOZ_WINCONSOLE)
> LFLAGS= $(LFLAGS) /subsystem:console
> !else
> LFLAGS= $(LFLAGS) /subsystem:windows
> !endif
Index: nsAppRunner.cpp
===================================================================
RCS file: /cvsroot/mozilla/xpfe/bootstrap/nsAppRunner.cpp,v
retrieving revision 1.151
diff -w -r1.151 nsAppRunner.cpp
724a725,733
>
> #if defined( XP_PC ) && defined( WIN32 )
> // We need WinMain in order to not be a console app.  This function is
> // unused if we are a console application.
> int WINAPI WinMain( HINSTANCE, HINSTANCE, LPSTR args, int ) {
>     // Do the real work.
>     return main( __argc, __argv );
> }
> #endif // XP_PC && WIN32

Comment 4

18 years ago
I am not sure, but can the concerns of 3jrgm@qlink.queensu.ca about the
use of the console output for debugging be addressed with this simple
workaround: start Mozilla from a command line. On Win32 this would be either
"command" (Win9x) or "cmd" (WinNT). I've been doing this for a while now to 
be able to look at the last few messages logged before a crash; the exact 
same messages that go to a dedicated console go to the console Mozilla is 
launched from.

law@netscape.com, this would be easy enough to test: just make a build with
/subsystem:windows, then run it from cmd.exe: if messages appear in that window,
there would be no need to distribute a /subsystem:console build as well for
developers not running a debug build, who ought to at least know how to use a 
command line ;-).

Comment 5

18 years ago
 I think law has done the right thing, given the confines of win32. That is,
the console must die, but let's not lose the console entirely. Since it is
not possible to become a console app at run-time (under win32), law has made
a provision to build mozilla.exe either with or without the console (and to
also have the console either with or without debug). THANKS!!! to Bill.

 So, this is really a question for the build team, and whatever choice that
mozilla.org makes for supporting a 'with-console' build on win32 [cc: leaf].

 To make an analogy (once again), the console serves a role analogous to the
role of *scratch*, *Messages*, and (defun message ...) in Emacs. I have
compiled emacs from source many a time, but that does not mean that I want
to 'stay on the tip' for emacs so that I can extend an editing mode, or
otherwise modify emacs. (And, I think that is consistent with brendan's
statement of Oct. 98 -- http://www.mozilla.org/roadmap.html [cc: brendan])
 
 So ... while I acknowledge the additional effort that this would place on
the build team, I propose that the mozilla-win32-installer.exe be built
without the console, but that the mozilla-win32.zip be built with the
console.

  ---------
Endnotes: 
  1) A longer term idea would be to subsume the console functions into
     a XUL-based utility, but for now, on windows, we have the
     console.] 
  2) This is only, really, an issue for windows: on unix, 'stdout to launching 
     terminal' is standard operating procedure; on mac, there is no   
     command-line at all (for now)).
  3) Perhaps, create a subdirectory './2000-mm-dd-hh-Mnn/win-console', and
     place the console-enabled build there -- this keeps the console away
     from windows users who are better off not knowing that a console exists
     at all. (A little knowledge is a dangerous thing sometimes, and I have
     seen bugs filed on, for example, travis for the mere reason that the
     last message in the console window before the crash was 'WEBSHELL +=1'
     :-])

Comment 6

18 years ago
Adding beta1 keyword
Keywords: beta1

Comment 7

18 years ago
adding polish keyword
Keywords: polish

Comment 8

18 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
> Since it is not possible to become a console app at run-time (under win32)

I don't think this is true. I think you can. See AllocConsole():
http://msdn.microsoft.com/library/psdk/winbase/conchar_6smd.htm
(Assignee)

Comment 10

18 years ago
Thanks for the tip!  That looks like it might work.  Requires some more code, 
though (and I'm wondering about how to get stdout directed to this newly 
allocated console).

So, I'm going to push that off as a new [FEATURE] bug (bug #26103) and address 
it down the road.
(Assignee)

Comment 11

18 years ago
Console is gone, sometimes (for better or worse).
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 12

18 years ago
marking verified
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.