26761 - -help and -version not working on optimized win32 builds

Status: RESOLVED DUPLICATE of bug 355889

(Core Graveyard :: Cmd-line Features, defect, P3)

Description

[Alan S. Jones]

In the 2/5/00 build -help does not output anything.  Could this have come up 
after the console text was removed?

Comment 1

[Steven de Hoog]

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

Comment 2

[Bill Law]

"-help" is still working (as well as it ever did).  But the output goes to the 
console, which isn't there any more.  So, to see the output, you'd have to use 
output redirection to see the output, e.g., "mozilla -help>logfile" then "type 
logfile".

If we add support for "-console" (to force a console window) then I'll make 
"-help" imply "-console."  See bug 26103.

Comment 3

[Alan S. Jones]

I was wondering shouldn't this just be left open and depends on bug 26103?  A 
feature of something like -help or /? (as in bug 23501) for command line support 
is helpful and in many products.

Comment 4

[(not reading, please use [e-mail] instead)]

well, actually, -help is a little busted

I'm rewriting how the command lines get handled (using XPCOM categories and the
nsICmdLineHandler interface)

I'm working on fixing the -help to be as good as it was before.

(right now, you'll notice the help info is not complete.)

law is right, on windows, we will have the -console problem, on windows (and
mac, I guess.) to fix.

Comment 5

[(not reading, please use [e-mail] instead)]

I'll take this, since I need to fix -help for other reasons.

Comment 6

[(not reading, please use [e-mail] instead)]

the console problem still remains.  moving to m15.

Comment 7

[(not reading, please use [e-mail] instead)]

now that -console is fixed, I can use it to get -help working again.

accepting, will fix for m15.

Comment 8

[(not reading, please use [e-mail] instead)]

moving to m16.

Comment 9

[Alan S. Jones]

This is just a reminder that besides -help, -h, -?.....

The console output should also work for -v, -version  also

not sure there if there are other paramaters need that output to console also.

Comment 10

[Paul MacQuiddy]

spam, changing selected qa contact on selected bugs from [e-mail] to 
[e-mail]

Comment 11

[selmer (gone)]

Seth, why do you own this?  Could someone else be fixing it right now?

Comment 12

[(not reading, please use [e-mail] instead)]

not going to happen for m16. making -h act like "-h -console" will not work for
commercial builds.

here's why:

doing -console opens a dos console that goes away when the app quits.

so doing -h -console on a commercial build will dump out help to the console,
and then the console will immediately go away.

law / mcafee, you interested in taking this one from me?

moving to m18, this is not a m16 bug.

Comment 13

[(not reading, please use [e-mail] instead)]

update from timeless in #mozilla, even "-h -console" doesn't do anything.

I was hoping it would at least flash the console.

Comment 14

[timeless]

mozilla -h > outfile does nothing too.
We need to support output to current stdin/stdout/stderr, redirection is nice 
and all, but if i'm debugging and open cmd.exe [nt4/w2k] I should be able to 
use it. [adding self to cc]

Comment 15

[sairuh (rarely reading bugmail)]

over to me...if claudius doesn't mind ;).

Comment 16

[selmer (gone)]

Anyone on the CC list care to own this?  Seth won't be fixing this in beta3.  If 
no volunteers, then I'll be moving this to FUTURE.

Comment 17

[Bill Law]

"mozilla -h > output" *does* work, assuming Mozilla is not already running (if 
it is, then too bad, you can't need too much help in that case :-).

The problem with -console remains.  There is not much we can do, since Windows 
is Windows and it gives us no access to the console of the 
command.com/cmd.exe that launched us.

The only option is something like: Insert a "press any key" sort of thing after 
dumping the help info (windows only, only if MOZ_WINCONSOLE==0).  That way, the 
app doesn't exit and the console doesn't go away.  I'll also make "-help" imply 
"-console" (currently, "-help" blocks the "-console" code from getting called so 
I'll have to rearrange this a little).

If that's acceptable, I'll take this for beta3.  If we insist on some 
more utopian solution, then definitely FUTURE it.

Comment 18

[Alan S. Jones]

I like the option of "Press any key".

law, if you do this, it might be good to add code at the same time to count the 
number of lines to be displayed in the console with -help.  So if it is greater 
then 24 or 25 then you would get a "press any key" after every 25 lines on the 
screen then another at the very end so we can see the last few.

Thiw ould let us see all command line paramaters if we get more then a screen 
full.

Comment 19

[timeless]

I don't have time (now) to take this, but many of the comments are not entirely 
correct.

Case one: regedit.exe where command.com (win9x not NT) is configured (via pif) 
to lie ~windows is not running~
result: help in console.

The solution is probably to change the loader code (possibly the REAL main) to 
do some parsing before it starts using winmain.

Another application that might be similar is "start" (actually i'm not quite 
sure it's an application)

F:\backup\Win98\WINDOWS\COMMAND\START.EXE <-- win9x
No such critter in w2k.  
F:\backup\Win98\WINDOWS\COMMAND>ver

Microsoft Windows 2000 [Version 5.00.2195]

F:\backup\Win98\WINDOWS\COMMAND>.\START.EXE /?
Runs a Windows program or an MS-DOS program.

START [options] program [arg...]
START [options] document.ext

/m[inimized] Run the new program minimized (in the background).
/max[imized] Run the new program maximized (in the foreground).
/r[estored]  Run the new program restored (in the foreground). [default]
/w[ait]      Does not return until the other program exits.

I think that help is intuitive enough.

wrt mozilla -h > file.  Again I nearly always use non debug builds and in my 
experience it does not work.  Debug builds are special but...our release 
product isn't exactly supposed to be a debug build.

Press any key to continue is a reasonable short term fix.

So is the win3.1/win9x pif setting "don't close window on exit" Mozilla could 
change the window titled to Finished and just wait for someone to close it.

Comment 20

[timeless]

Bleh. I missed a comment. windows nt allows for the console to have varying 
sizes so does 9x. iirc on 9x it can be 24,25 or 50 lines. When we use -console 
we seem to create a scrolling window (well I'm in 2000 so maybe this is the 
os's action).  If we actually create the window and the scrollbars then there's 
no need for the multiple press any keys.  If we don't then use some functions 
to find out how many lines the window shows (see cmd.exe's [conflicting] 
implementations:

D:\Program Files\Netscape\Mozilla\new\bin>help


For more information on a specific command, type HELP command-name.
ASSOC    Displays or modifies file extension associations
AT       Schedules commands and programs to run on a computer.
ATTRIB   Displays or changes file attributes.
BREAK    Sets or clears extended CTRL+C checking.
CACLS    Displays or modifies access control lists (ACLs) of files.
CALL     Calls one batch program from another.
CD       Displays the name of or changes the current directory.
CHCP     Displays or sets the active code page number.
CHDIR    Displays the name of or changes the current directory.
CHKDSK   Checks a disk and displays a status report.
CHKNTFS  Displays or modifies the checking of disk at boot time.
CLS      Clears the screen.
CMD      Starts a new instance of the Windows 2000 command interpreter.
COLOR    Sets the default console foreground and background colors.
COMP     Compares the contents of two files or sets of files.
COMPACT  Displays or alters the compression of files on NTFS partitions.
CONVERT  Converts FAT volumes to NTFS.  You cannot convert the
         current drive.
COPY     Copies one or more files to another location.
DATE     Displays or sets the date.
DEL      Deletes one or more files.
DIR      Displays a list of files and subdirectories in a directory.
DISKCOMP Compares the contents of two floppy disks.
DISKCOPY Copies the contents of one floppy disk to another.
DOSKEY   Edits command lines, recalls Windows 2000 commands, and creates 
macros.

ECHO     Displays messages, or turns command echoing on or off.
ENDLOCAL Ends localization of environment changes in a batch file.
ERASE    Deletes one or more files.
EXIT     Quits the CMD.EXE program (command interpreter).
FC       Compares two files or sets of files, and displays the differences
         between them.
FIND     Searches for a text string in a file or files.
FINDSTR  Searches for strings in files.
FOR      Runs a specified command for each file in a set of files.
FORMAT   Formats a disk for use with Windows 2000.
FTYPE    Displays or modifies file types used in file extension associations.
GOTO     Directs the Windows 2000 command interpreter to a labeled line in a
         batch program.
GRAFTABL Enables Windows 2000 to display an extended character set in graphics
         mode.
HELP     Provides Help information for Windows 2000 commands.
IF       Performs conditional processing in batch programs.
LABEL    Creates, changes, or deletes the volume label of a disk.
MD       Creates a directory.
MKDIR    Creates a directory.
MODE     Configures a system device.
MORE     Displays output one screen at a time.
MOVE     Moves one or more files from one directory to another directory.
PATH     Displays or sets a search path for executable files.
PAUSE    Suspends processing of a batch file and displays a message.
POPD     Restores the previous value of the current directory saved by PUSHD.
PRINT    Prints a text file.
PROMPT   Changes the Windows 2000 command prompt.
PUSHD    Saves the current directory then changes it.
RD       Removes a directory.
RECOVER  Recovers readable information from a bad or defective disk.
REM      Records comments (remarks) in batch files or CONFIG.SYS.
REN      Renames a file or files.
RENAME   Renames a file or files.
REPLACE  Replaces files.
RMDIR    Removes a directory.
SET      Displays, sets, or removes Windows 2000 environment variables.
SETLOCAL Begins localization of environment changes in a batch file.
SHIFT    Shifts the position of replaceable parameters in batch files.
SORT     Sorts input.
START    Starts a separate window to run a specified program or command.
SUBST    Associates a path with a drive letter.
TIME     Displays or sets the system time.
TITLE    Sets the window title for a CMD.EXE session.
TREE     Graphically displays the directory structure of a drive or path.
TYPE     Displays the contents of a text file.
VER      Displays the Windows 2000 version.
VERIFY   Tells Windows 2000 whether to verify that your files are written
         correctly to a disk.
VOL      Displays a disk volume label and serial number.
XCOPY    Copies files and directory trees.

D:\Program Files\Netscape\Mozilla\new\bin>help start
Starts a separate window to run a specified program or command.

START ["title"] [/Dpath] [/I] [/MIN] [/MAX] [/SEPARATE | /SHARED]
      [/LOW | /NORMAL | /HIGH | /REALTIME | /ABOVENORMAL | /BELOWNORMAL]
      [/WAIT] [/B] [command/program]
      [parameters]

    "title"     Title to display in  window title bar.
    path        Starting directory
    B           Start application without creating a new window. The
                application has ^C handling ignored. Unless the application
                enables ^C processing, ^Break is the only way to interrupt
                the application
    I           The new environment will be the original environment passed
                to the cmd.exe and not the current environment.
    MIN         Start window minimized
    MAX         Start window maximized
    SEPARATE    Start 16-bit Windows program in separate memory space
    SHARED      Start 16-bit Windows program in shared memory space
    LOW         Start application in the IDLE priority class
    NORMAL      Start application in the NORMAL priority class
    HIGH        Start application in the HIGH priority class
    REALTIME    Start application in the REALTIME priority class
Press any key to continue . . .
...

I prefer help's approach (this window's buffer is 300 lines tall and that's 
what I care about, not the visible 54 lines; I want apps to check *the buffer 
size*)
[note: help start is help on w2k's cmd.exe's native start not the one used in 
the previous example]

Comment 21

[timeless]

Law wrote:
The problem with -console remains. There is not much we can do, since Windows 
is Windows and it gives us no access to the console of the 
command.com/cmd.exe that launched us.

I just remembered: viewer.exe uses the cmd.exe that launched it for debug 
output.

Maybe I should go in and compare viewer's source to apprunner (mozilla)'s.

http://lxr.mozilla.org/seamonkey/source/webshell/tests/viewer/nsWinMain.cpp
/*148*/ int main(int argc, char **argv)
{
//...
app->Initialize(argc, argv);
//...
}
http://lxr.mozilla.org/seamonkey/source/webshell/tests/viewer/nsViewerApp.cpp
/*306*/ nsViewerApp::Initialize(int argc, char** argv)
{
//...
rv = ProcessArguments(argc, argv);
//...
}
/*519*/ nsViewerApp::ProcessArguments(int argc, char** argv)
{
//...
PrintHelpInfo(argv);
//...
}
/*441*/PrintHelpInfo(char **argv)
{
fprintf(stderr, "Usage: %s [options] [starting url]\n", argv[0]);
//...
}

Comment 22

[sairuh (rarely reading bugmail)]

i run into this every time i run an optimized build on win32, so am adding 
mostfreq so that it'll at least get on my radar quickly when i run a query.

Comment 23

[Gervase Markham [:gerv]]

Removing mostfreq - this bug does not qualify for this keyword under the 
established criteria.

Gerv

Comment 24

[sairuh (rarely reading bugmail)]

adding se-radar to status so that i can find this bug more easily.

Comment 25

[Marcia Knous [:marcia]]

Netscape Nav triage team: this is not a Netscape beta stopper.

Comment 26

[sairuh (rarely reading bugmail)]

from bug 14003: this bug is preventing -version from working on win32 optimized
bits.

note to self: once this is fixed, doublecheck -version.

Comment 27

[(not reading, please use [e-mail] instead)]

this should probably go to alecf, law or mcafee.

Comment 28

[Bill Law]

Reassigning to self.  All I'll probably do is get -help to spawn a console and
maybe add a Sleep() call so the user has a chance to read it.

Comment 29

[(not reading, please use [e-mail] instead)]

it would be better if -help or -version didn't bring up a console.

Comment 30

[Simon Lucy]

If the executable file wasn't started from a command line (i.e. a shortcut) then
it probably won't have a console to display in, unless -help implies -console.
Other than that any stdio should go to the console that the app started in its
too confusing otherwise.

Is this still helpwanted?

Comment 31

[timeless]

http://msdn.microsoft.com/library/periodic/period96/S569.htm looks interesting, 
as do some other links

mainCRTStartup and WinMainCRTStartup might be enough to solve our problems.  
I'll work on a test application soon.

My current test concept is a main() which logs an event in the application 
event log.

Comment 32

[Brian 'netdragon' Bober]

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

Comment 33

[Brian 'netdragon' Bober]

After much thinking, I believe the options would be one of the following:
1) To create a simple console application to hold the console window, and link 
it into the application as binary data. Then you can load the executable 
straight from mozilla, write it to a file, run it, close mozilla.
2) Include another file in the dir named console.bin and run that.
3) If its possible, load a DLL that is independent of mozilla that opens a 
console, and registers a control handler with SetConsoleCtlHandler, and then 
close mozilla.
4) Make mozilla always a console application, and have it close the console if 
its not needed. Console will flicker? Console applications can open regular 
windows, I tested that. Don't know if you can close the console in a console 
application without closing the application. If you FreeConsole before the 
application closes, the console stays open even if the application is no longer 
open. I'm gonna play around with this a little more. It was timeless's idea - 
and will be the way to do it if you can somehow close the console if mozilla 
goes into gui mode.
5) Open the console and have Mozilla stay open until the console is closed. If 
Mozilla was opened again, it would have to know that the currently open console 
isn't really the gui mode of mozilla.

Comment 34

[Brian 'netdragon' Bober]

Sorry, unfortunately, I was wrong on #4 - it was only when I ran it within MSVC.

Comment 35

[Brian 'netdragon' Bober]

Notice: #4 does let you write to the command prompt though when run from 
cmd.exe.

Comment 36

[timeless]

1-5 don't make any sense.

in English, we can easily make mozilla a console application. w32 allows us to 
release the console if we like.  The only big issue is that when we want to 
hide the console it flickers.  I think we can find out when our console is 
fresh. if it's fresh we can hide it temporarily [first step, reduces flash] -- 
probably minimizing it.  result: we decide whether we need to display output to 
the console, if we do, we show the console. either way we put output to the 
console.  if we don't need to use the console, we release it.

Comment 37

[Brian 'netdragon' Bober]

One of the solutions, was make a console application that does nothing but 
shows the parameters or help for each parameter. Then you can pack it into 
the .exe and load it as a resource, turn it into memory, save it to a temp file 
and run it. This was successful and fast for me on my test. Screenshots to be 
attached, along with a directory containing two .dsw files for msvc++. One .dsw 
creates the commandline.exe file. The other makes commandlinegui.exe. 
commandlinegui.exe contains commandline.exe as a resource and loads it from 
its .exe file using windows API. It then saves it to a file and runs that file. 
The file is placed in the temp dir. Try it, it works!

Comment 38

[Brian 'netdragon' Bober]

Attachment: "commandlinegui.exe /?"

Comment 39

[Brian 'netdragon' Bober]

Attachment: "commandlinegui.exe"

Comment 40

[Brian 'netdragon' Bober]

Attachment: .zip file of commandlinegui - Make sure to build commandline.exe before commandlinegui.exe (Requires MSVC++)

Comment 41

[Brian 'netdragon' Bober]

Note that these are .dsw files to be loaded by MSVC++ 6.

First load commadline.dsw and build.
Then load commandlinegui.dsw and build.

they go to the debug dir and try:
commandlinegui
commandlinegui /?
Notice the difference in what happens and also notice that the window stays 
after the original program ends.

Comment 42

[Brian 'netdragon' Bober]

In conclusion, this would allow it to display the parameters without it 
flickering when starting up in normal mode. The only drawback is the parameters 
will be loaded in another window from the command prompt. There is no way 
around that since the gui app (Mozilla) isn't attached to the console (command 
prompt) on startup because of the way Windows works. This is ok, anyway since 
it can be kept as a reference while entering commands. Also calling Mozilla 
with paramaters from run in the start menu will load a console window, which is 
nice.

Comment 43

[Jesse Ruderman]

Would it be sufficient to make mozilla.exe -help open about:commandline 
(bug 60085) in a new Navigator window?

Comment 44

[Brian 'netdragon' Bober]

Jesse: I think that would be annoyingly slow.

What I just showed will work and I believe is the best way. That way you get no 
flickering. A console application is very small and won't change the size of 
mozilla very much.

Timeless: I'll explain it better:

Definitions:
gui mode - regular browser mode
console / console mode / console app - just display command line params in a 
window

1) Link the console app into Mozilla.exe as a resource and write to a temp file 
after loading Mozilla and run the temp file - this is what I just showed how to 
do.
2) Simply, just include a file in the mozilla dir called console.bin or 
something which is an executable file that has been renamed to a non-executable 
extension. Mozilla can then do WinExec("console.bin",...).
3) Use rundll to load a dll that loads the console so the dll doesn't close 
when mozilla closes (I think).
4) Make mozilla always a console application, and have it close the console if 
its not needed. Console will flicker. Console applications can open gui 
windows, I tested that. You still need to close the app before you run it 
again. Hopefully the console window stays open.
5) Open the console and have Mozilla (in console mode) stay open until the 
console is closed. If mozilla.exe is opened again without closing the previous 
instance, it would have to know that the currently open console isn't the gui 
mode of mozilla and therefore won't interfere with the gui mode.


Also, the command line params don't necessarily have to be shown in a console 
window. They could be showed in a regular window that allows copying to the 
clipboard, although I think that would look sloppy.

Comment 45

[Brian 'netdragon' Bober]

BTW: 1-5 are all different options and not steps.

Comment 46

[Brian 'netdragon' Bober]

Attachment: c++ file for commandline.exe

Comment 47

[Brian 'netdragon' Bober]

Attachment: c++ file for cmdlinegui.exe - has cmdline.exe linked in to project as resource "cmdline"

Comment 48

[Bill Law]

There's localization problems with this Rube Goldberg scheme (no offense).

Comment 49

[timeless]

afaik this whole process is still totally unnecessary.

Comment 50

[Brian 'netdragon' Bober]

If you could somehow make a console DLL that is loaded by Mozilla but stays 
active (with a timer) after Mozilla exits, that would work too.

Comment 51

[Brian 'netdragon' Bober]

That way the .dll could be just stuck into the .dll dir and wouldn't have to be 
explicitly linked into the code.

Comment 52

[Paul Chen]

Marking nsbeta1- bugs as future to get off the radar.

Comment 53

[timeless]

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

Comment 54

[Mike Young]

We need to have some way for Windows users to see what commandline options are
available. 

Comment 55

[Jesse Ruderman]

Mike Young: see also bug 60085, [RFE] about:commandline.

Comment 56

[Brian 'netdragon' Bober]

Shouldn't this be fixed by 1.0?

Comment 57

[Brian 'netdragon' Bober]

Take a look at msdev. It does both console and gui. 
Check out:
http://www.codeguru.com/console/dualmode.html
http://www.codeguru.com/console/ConsoleFromWindows.html

Comment 58

[Brian 'netdragon' Bober]

Still, neither of these are any better than timeless's wrapping WinMain in main
in a console app idea since there still is a flicker if trying to simply do gui.

Comment 59

[Brian 'netdragon' Bober]

Bug 60085 is about adding about:commandline.

Due to the limitations of Windows, I feel we should have -help bring up
about:commandline and -version bring up about: and set this bug dependant on
both those bugs.

AFAIK, there is no good way around this dilemma other than that. The only four
choices are:

1) Bring up another console or window.
2) Make it a console application. It will flicker before you hide the console if
not using the help info.
3) Do the mozilla.exe, mozilla.com thing msdev does (info in earlier comment
today). If someone types "mozilla.exe -help" then it won't work, they would have
to type "mozilla -help"
4) Somehow create a hybrid subsystem that is neither console nor gui. We would
have to somehow feed this to linker. I have no clue how we would do this.

I had limited success with replacing WinMainCRTStartup by linker option
ENTRY:MyStartup. The problem was, if I created it as a console app, Windows
still made the console. If I made it as a gui app, I still didn't have access to
the console even if I called mainCRTStartup directly.

IMHO, let's stop beating ourselves up over Windows shortcomings and just fix the
about:commandline and about: for -help and -version

Comment 60

[Brian 'netdragon' Bober]

Microsoft must have fixed this in Windows XP
Surprisingly, mozilla -help works in Windows XP!

Comment 61

[Brian 'netdragon' Bober]

I submitted a patch for about:commandline.

For Windows systems except Windows XP, we can open up a browser window to
about:commandline.

Patch in Bug 60085 for about:commandline.

Comment 62

[ajbu]

Running build 2002042608 on Windows XP Professional, but running 'mozilla -
help' or 'mozilla - version' from the command prompt still doesn't work for me.

Comment 63

[Brian 'netdragon' Bober]

That's strange. I wonder why. My friend noticed the same thing as you. I'm
thinking it has something to do with the fact that I have msvc++ service pack 5.
If not that, it might be some windows update I have that others don't.

Can anyone with msvc++ and sp5 check this?

Comment 64

[Brian 'netdragon' Bober]

I just realized the reason is cause I was doing it in my tree, on my debug
build. Hmmmm. I think someone has mentioned that before. I forget why it works
though.

Sorry for the unintentional spam.

Comment 65

[Mike Kaply [:mkaply]]

Actually, I have an idea that I am working on.

I'll post a patch tomorrow.

Basically I've changed the DumpHelp function to call some APIs like
DisplayHelpText and DisplayHelpOption rather than use printfs.

Then I've created two new functions called BeginHelp and EndHelp.

The idea is that if you are going to use the DisplayHelp APIs, you do something
like this:

BeginHelp
DisplayHelp...
DisplayHelp...
.
.
.
EndHelp

This allows a platform to do setup in BeginHelp and then process the help
statements all at once in EndHelp.

For instance on Windows right now, I'm doing an allocation in BeginHelp and then
in EndHelp I use a MessageBox to display the help and then free the buffer.

This solution gives a great deal of platform flexibility, while leaving unix
platforms working exactly the way they used to.

We could even create a Windows console in BeginHelp, and then display the help
in that console.

Comment 66

[Christian :Biesinger (don't email me, ping me on IRC)]

Creating a console would look ugly if you start Mozilla from a console, because
there is (to my knowledge) no way to use an existing console. Also, you'd have
to ensure that the console doesn't go away directly after displaying the
message, so that the user can read the help :)

Comment 67

[Mike Kaply [:mkaply]]

Attachment: First attempt at a patch

OK, this implements my idea.

Now when you do mozilla -version or mozilla -help, you get a message box on
Windows.

Unix and others work the same way the used to.

The only problem I am running into is alignment within the message box.
-jsconsole and -installer both have 10 letters, but completely different sizes
with the default windows font.

You'll see it when you run with the patch.

I think this is a pretty good idea to do this.

Looking for opinions.

Comment 68

[Mike Kaply [:mkaply]]

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

Comment 69

[Brian 'netdragon' Bober]

mkaply: 

I tried your patch, and it is a good solution until we are able to modify the 
Mozilla stub. The only thing I thought about when I tested it is that you 
can't select or copy the text. Is there any way we could make the text 
selectable? If dialogs don't allow it, we could make this a window instead. We 
could also possibly put a button in that says "Copy to clipboard".

People might want to copy it all to put on a web page, text file or something 
else.

I'm going to modify this patch so that this is possible.

Comment 70

[Brian 'netdragon' Bober]

mkaply: nsApprunner.cpp is a cross-platform file. You need to put #if statements
around code you don't want compiling in Linux (such as the MessageBox).

I tried compiling on Linux and had the following errors:

../../../xpfe/bootstrap/nsAppRunner.cpp:518: warning: ISO C++ forbids
declaration of `BeginHelp' with 
no type
../../../xpfe/bootstrap/nsAppRunner.cpp: In function `int BeginHelp ()':
../../../xpfe/bootstrap/nsAppRunner.cpp:521: warning: no return statement in
function returning 
non-void
../../../xpfe/bootstrap/nsAppRunner.cpp: At top level:
../../../xpfe/bootstrap/nsAppRunner.cpp:524: warning: ISO C++ forbids
declaration of `EndHelp' with no 
type
../../../xpfe/bootstrap/nsAppRunner.cpp: In function `int EndHelp (char *)':
../../../xpfe/bootstrap/nsAppRunner.cpp:525: `HWND_DESKTOP' undeclared (first
use this function)
../../../xpfe/bootstrap/nsAppRunner.cpp:525: (Each undeclared identifier is
reported only once for each 
function it appears in.)
../../../xpfe/bootstrap/nsAppRunner.cpp:525: `MB_OK' undeclared (first use this
function)
../../../xpfe/bootstrap/nsAppRunner.cpp:525: `MessageBox' undeclared (first use
this function)
../../../xpfe/bootstrap/nsAppRunner.cpp:527: warning: no return statement in
function returning 
non-void
../../../xpfe/bootstrap/nsAppRunner.cpp: At top level:
../../../xpfe/bootstrap/nsAppRunner.cpp:530: warning: ISO C++ forbids
declaration of 
`DisplayHelpTextWithString' with no type
../../../xpfe/bootstrap/nsAppRunner.cpp: In function `int
DisplayHelpTextWithString (const char *, 
const char *)':
../../../xpfe/bootstrap/nsAppRunner.cpp:542: warning: no return statement in
function returning 
non-void
../../../xpfe/bootstrap/nsAppRunner.cpp: At top level:
../../../xpfe/bootstrap/nsAppRunner.cpp:545: warning: ISO C++ forbids
declaration of `DisplayHelpText' 
with no type
../../../xpfe/bootstrap/nsAppRunner.cpp: In function `int DisplayHelpText (const
char *)':
../../../xpfe/bootstrap/nsAppRunner.cpp:552: warning: no return statement in
function returning 
non-void
../../../xpfe/bootstrap/nsAppRunner.cpp: At top level:
../../../xpfe/bootstrap/nsAppRunner.cpp:555: warning: ISO C++ forbids
declaration of 
`DisplayHelpOption' with no type
../../../xpfe/bootstrap/nsAppRunner.cpp: In function `int DisplayHelpOption
(const char *, const char 
*)':
../../../xpfe/bootstrap/nsAppRunner.cpp:579: warning: no return statement in
function returning 
non-void
make: *** [nsAppRunner.o] Error 1

Comment 71

[Mike Kaply [:mkaply]]

We could certainly do that and I was going to have to do it for OS/2.

Create a dialog with a text area in it that displays the help information.

Comment 72

[Brian 'netdragon' Bober]

Attachment: latest diff, everything but OS/2, works for Linux

- This patch doesn't break Linux. Not only that, it speeds up the help text
display thanks to mkaply's idea of printing it all out at the end which I also
put for the Linux code.
- This patch also shows the text aligned correctly
- It allows for copyable text on Win32 -help in a nice-looking Window

mkaply: So OS/2 doesn't show the info either? Can you make this work in OS/2,
also? (I don't have OS/2)

Comment 73

[Brian 'netdragon' Bober]

See also bug 184594 about timeless's idea about making a new application stub 
to replace the loading code (before main or Winmain even get called) which is 
something we can try do in the future but is not a priority since michael 
kaply came up with a sufficient work-around for now. Let's get his idea into 
the tree! :-)

Comment 74

[Brian 'netdragon' Bober]

I also have updated the patches on Bug 60085 (about:commandline).

Comment 75

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 108851 [details] [diff] [review]
latest diff, everything but OS/2, works for Linux

(fwiw, writing an entirely new stub seems _so_ wrong to me. but ok, whatever, I
do not know what that would involve... I am guessing a lot, and I think we
don't want this)

+   helpbuffer = (char*)malloc(65536);
any reason for exactly 64 KB?

+#endif //XP_Win
wrong case. (should be XP_WIN).

Why bother allocating helpbuffer on all platforms if you're only using it on
XP_WIN?

(const char *)commandLineArg
do me a favor and use .get() instead of the typecast.
oh yeah and above in the function, maybe test emptyness with .IsEmpty() rather
than typecast to const char* and checking non-null-ness.

-  // this works, but only after the components have registered.  so if you
drop in a new command line handler, -help
-  // won't not until the second run.
-  // out of the bug, because we ship a component.reg file, it works correctly.

So. Any reason for removing that comment?



That said, get module-owner review for this as well (also law I believe)

Comment 76

[Brian 'netdragon' Bober]

Attachment: Final fix?

This patch also fixes bug 60265 

biesi:

The reason I allocated helpbuffer was because I rerouted even Linux info to it.
It has since been renamed though.

- Changed to use nsCString
- Replaced the DisplayHelpTextWithString and DisplayHelpText with
  var arg AddCmdHelpText that uses PR_vsnprintf
- Moved the -help info over a bit so its not more than 80 chars wide (but
version is at least with a developer build)
- Moved the functions to be closer together
- Removed malloc reference
- Fixed XP_Win

What does this mean? -
// this works, but only after the components have registered.  so if you drop
in a new command line handler, -help
// won't not until the second run. out of the bug, because we ship a
component.reg file, 
// it works correctly. 

Why don't we put this into the tree, and then have the OS/2 stuff in a separate
bug?

Comment 77

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 108991 [details] [diff] [review]
Final fix?

er. So there is exactly _one_ case which requires printf?

+   // NOTE: The above comment is poorly written. 
how so, looks perfectly fine to me.

+ #ifdef MOZ_WIDGET_GTK
I think some compilers (preprocessors) have problems with ifdefs that don't
start at the beginning of the line, please remove the space.

Comment 78

[Mike Kaply [:mkaply]]

I realize I wrote the original patch, but my indent was way off. We should use
two space indentation.

Also I have the OS/2 piece of this code done as well.

Comment 79

[Mike Kaply [:mkaply]]

Attachment: OS/2 stuff and indentation fixed

That comment IS poorly written. Unless you know what this means:

won't not until the second run.

Comment 80

[:deanis74]

// this works, but only after the components have registered.  so if you drop in
a new command line handler, -help
// won't not until the second run.
// out of the bug, because we ship a component.reg file, it works correctly.

This is my take on the comment....
("won't not" == won't know, "out of the bug" == out of the box)

Command-line help displays the proper help information, but only after
components have been registered.  If a component with a command-line handler is
added its help information will not display application has been run once
without the "-help" parameter, because the help text is displayed before
component registration occurs.  Out of the box all help information is displayed
correctly due to the included component.reg file.

Comment 81

[timeless]

the right thing to do is to register components <g>, this is actually rather
easy to do.

Comment 82

[Brian 'netdragon' Bober]

mkaply: Is the text also selectable in OS/2?

Comment 83

[Mike Kaply [:mkaply]]

yes. We use a text area the same as Windows.

Comment 84

[Brian 'netdragon' Bober]

Great! Ok, lemme modify the comment that doesn't make sense, and then let's 
get this baby in!

Comment 85

[:deanis74]

Correction to my interpretation...

'If a component with a command-line handler is added its help information will
not display application has been run once without the "-help" parameter'

I forgot "until the" between "display" and "application".

Comment 86

[Brian 'netdragon' Bober]

Attachment: diff -u from mozilla/..

timeless: You said you would registration issue in #mozilla (and thanks to Dean
Tessman I finally understand it. I filed a separate bug 184979 just for you.

I modified the comment. Tested it on Win32 and Linux, no problems.

Can I go to sleep now? ;-)

Comment 87

[Brian 'netdragon' Bober]

Comment on attachment 109053 [details] [diff] [review]
OS/2 stuff and indentation fixed

Forgot to mark previous obsolete

Comment 88

[Brian 'netdragon' Bober]

Comment on attachment 109096 [details] [diff] [review]
diff -u from mozilla/..

Asking law for review

Comment 89

[Bill Law]

Comment on attachment 109096 [details] [diff] [review]
diff -u from mozilla/..

My opinion is that this is way too much code for little benefit.  I don't think
it is worth it.

That said, I don't really "own" this code anymore so I will not object if
somebody goes ahead and checks it in.

Also, I'd like to find somebody else to take over ownership of this code once
and for all since I can't give it the attention it deserves.

Comment 90

[Brian 'netdragon' Bober]

Note that we have only added about 700 lines of code. and about 10k to the 
source file.

Comment 91

[Brian 'netdragon' Bober]

Comment on attachment 109096 [details] [diff] [review]
diff -u from mozilla/..

Requesting review from jag.

Notice that even though this is a large diff, at least half of it is actually
removing code.

Comment 92

[Brian 'netdragon' Bober]

Attachment: New patch - Mkaply, please update

Mkaply: 

This patch has shortened the nsAppRunner.cpp code to only an added 200 lines or
so by making it a dialog stored in splash.rc (resource script) and using the
DialogBox API function instead of being created through the CreateWindow API
function. The actual patch file isn't any different in size (because it spans
more files), but there is less code added.

Please do the same (in splashos2.rc and nsAppRunner.cpp) so that this adds even
less code.

Comment 93

[timeless]

Comment on attachment 110291 [details] [diff] [review]
New patch - Mkaply, please update

>+static nsCString gCmdHelpBuffer;
must it really be static? :(

>+#if defined(XP_WIN) || defined(XP_OS2)
>+    #define NS_CMDHELP_NEWLINE "\r\n"
>+#else  //XP_WIN
>+    #define NS_CMDHELP_NEWLINE "\n"
>+#endif //XP_WIN
what about macos classic? (yes, i know no one in their right mind would do
care, so?)
also, either remove the //XP_WIN or fix it to be accurate (i'd remove it)

>+  switch (uMsg)
>+  {
...
>+    case WM_INITDIALOG:
scope variable definitions:
{ // <-- like this 
>+      // Set up the window's icons
>+      HICON hMozillaIconLg =  (HICON) LoadIcon( GetModuleHandle( NULL ), IDI_APPLICATION);
...
>+      return TRUE;
how exactly do you expect code to reach this break?
>+      break;
(remove it)
>+  }

>+static void AddCmdHelpText(const char * format, ...)
>+{
>+  // It would be nice if nsPrintfCString has a constructor that 
>+  // accepted a va_list as its second param. 
valists suck. don't use them. they're bad bad bad.

two alternatives which are better and safer:
1. an xpcom array which indicates length,  especially when your callers will
only pass in strings.
2. an overloaded function since at compile time you have to know the number of
possible parameters -- you can't dynamically construct a valist :o.

>+    nsCOMPtr<nsISimpleEnumerator> e;
>+    rv = catman->EnumerateCategory(COMMAND_LINE_ARGUMENT_HANDLERS, getter_AddRefs(e));
>+    if(NS_SUCCEEDED(rv) && e) {
don't deep nest. use |if (!e) return;| instead.
also please use whitespace consistently |if(..| v. |if (..|
>+      while (PR_TRUE) {
i'm not a fan have while (1), usually there's a better condition, in this case
it's |NS_SUCCEEDED(e->hasMoreElements(&more)) && more|

in fact, what you're doing violates the nsISimpleEnumerator contract:
Although hasMoreElements() can be called independently of getNext(), getNext()
must be pre-ceeded by a call to hasMoreElements().

copied from:
http://unstable.elemental.com/mozilla/build/latest/mozilla/xpcom/dox/interfacen
sISimpleEnumerator.html#a1
but also available in the real idl file.
>+        nsCOMPtr<nsISupportsCString> catEntry;
>+        rv = e->GetNext(getter_AddRefs(catEntry));
>+        if (NS_FAILED(rv) || !catEntry) break;
don't bother with the rv. catEntry will only be true if GetNext succeeds.
>+        nsCAutoString entryString;
>+        rv = catEntry->GetData(entryString);
>+        if (NS_FAILED(rv) || entryString.IsEmpty()) break;
same idea
>+        nsXPIDLCString contractidString;
>+        rv = catman->GetCategoryEntry(COMMAND_LINE_ARGUMENT_HANDLERS,
>+                                      entryString.get(),
>+getter_Copies(contractidString));
>+        if (NS_FAILED(rv) || !((const char *)contractidString)) break;
again, don't bother with the rv. don't use (const char *) either, use IsEmpty()
>+        nsCOMPtr <nsICmdLineHandler> handler(do_GetService((const char *)contractidString, &rv));
don't use (const char*), use .get()
you don't actually use rv, so don't ask for it.
>+        if (handler) {
why not |if (!handler) continue;| ?
>+          nsXPIDLCString commandLineArg;
>+          rv = handler->GetCommandLineArgument(getter_Copies(commandLineArg));
>+          if (NS_FAILED(rv)) continue;
>+
>+          nsXPIDLCString helpText;
>+          rv = handler->GetHelpText(getter_Copies(helpText));
don't bother with rv.
>+          if (NS_FAILED(rv)) continue;
do |if (commandLineArg.IsEmpty()) continue;|
>+          if (!commandLineArg.IsEmpty()) {
>+            PRBool handlesArgs = PR_FALSE;
>+            rv = handler->GetHandlesArgs(&handlesArgs);
don't bother with rv.
>+            if (NS_SUCCEEDED(rv) && handlesArgs) {
>+              commandLineArg += NS_LITERAL_CSTRING(" <url>");
>+            }
>+
>+            AddCmdHelpOption(commandLineArg.get(), (const char *)helpText);
use .get()

>+  AddCmdHelpOption("-nosplash", "Disable splash screen.");
>+#if defined(XP_WIN) || defined(XP_OS2)
>+  AddCmdHelpOption("-quiet", "Disable splash screen.");
>+#endif /* XP_WIN || XP_OS2 */
>+#endif /* MOZ_ENABLE_REMOTE */
this nesting sucks, please unnest it (i don't care whose fault it is)

Comment 94

[Brian 'netdragon' Bober]

mkaply: Can you fix the issues that timeless spoke of that need fixing when you
do the OS/2 portion please?

> (From update of attachment 110291 [details] [diff] [review])
> >+static nsCString gCmdHelpBuffer;
> must it really be static? :(

Its used by global functions. The only other option is to pass it around in params.

> >+#if defined(XP_WIN) || defined(XP_OS2)
> >+    #define NS_CMDHELP_NEWLINE "\r\n"
> >+#else  //XP_WIN
> >+    #define NS_CMDHELP_NEWLINE "\n"
> >+#endif //XP_WIN
> what about macos classic? (yes, i know no one in their right mind would do
> care, so?)

We can file another bug on that. Maybe mkaply can mention that in a comment
within that part of the code.

> also, either remove the //XP_WIN or fix it to be accurate (i'd remove it)

Agreed.

> >+      return TRUE;
> how exactly do you expect code to reach this break?
> >+      break;
> (remove it)
> +  }

If the break isn't there, then removal of the return TRUE might have unexpected
results and cause a regression if its not caught if someone adds more
statements. In this case, I think the questionable redundancy is with merit.

>+static void AddCmdHelpText(const char * format, ...)
>+{
>+  // It would be nice if nsPrintfCString has a constructor that 
>+  // accepted a va_list as its second param. 
> valists suck. don't use them. they're bad bad bad.

Do you have a reason other than that they are bad? They are also used in some of
the PR string classes.

> >+    nsCOMPtr<nsISimpleEnumerator> e;
> >+    rv = catman->EnumerateCategory(COMMAND_LINE_ARGUMENT_HANDLERS, 
> getter_AddRefs(e));
> >+    if(NS_SUCCEEDED(rv) && e) {
> don't deep nest. use |if (!e) return;| instead.
> also please use whitespace consistently |if(..| v. |if (..|
> +      while (PR_TRUE) {
> i'm not a fan have while (1), usually there's a better condition, in this case
> it's |NS_SUCCEEDED(e->hasMoreElements(&more)) && more|
> 
> in fact, what you're doing violates the nsISimpleEnumerator contract:
> Although hasMoreElements() can be called independently of getNext(), getNext()
> must be pre-ceeded by a call to hasMoreElements().

That function was already there. Oh well.. I guess we can fix it. Sigh.

> >+  AddCmdHelpOption("-nosplash", "Disable splash screen.");
> >+#if defined(XP_WIN) || defined(XP_OS2)
> >+  AddCmdHelpOption("-quiet", "Disable splash screen.");
> >+#endif /* XP_WIN || XP_OS2 */
> >+#endif /* MOZ_ENABLE_REMOTE */
> >this nesting sucks, please unnest it (i don't care whose fault it is)

Agreed. And if you look at the code before and after it, it sucks even more.

Comment 95

[Mike Kaply [:mkaply]]

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

Comment 96

[Matthias Versen [:Matti]]

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

Comment 97

[Veronica Loell]

Nothing has been done even though this bug was filed in the year 2000? This is a
really problematic thing. Not being able to query the commandline options _at
the commandline_ for a program that takes commandline options? The installer -h
works just fine btw...

Comment 98

[Brian 'netdragon' Bober]

Incorrect. If your read this bug, things have been done. I have thought about
making a new loader for Mozilla to replace the gui loader that microsoft
provides, but for the meantime, we have the patch that I made.

http://bugzilla.mozilla.org/attachment.cgi?id=110291&action=view

That has been rotting. So don't say nothing hasn't been done. That's insulting.

Comment 99

[Veronica Loell]

My apologies that is not what I meant to imply, English is not my first
language. What I meant was that even though there had been extensive discussion
and a patch had been supplied, long time ago, nothing of this had made it into
Mozilla 1.4 which is what I am using at the moment.

Comment 100

[Gili Tzabari]

I agree with Veronica. Brian and other Mozilla developers, stop getting all
touchy about people's comments. Veronica stated quite clearly that this issue is
over 3 years old and regardless of the fact you submitted a patch the fact
remains the issue is *still* open and unresolved.

Mozilla developers: someone has to take charge of this issue and carry it
through to the end. Bill Law has ownership of this issue. Is he still active?
Why isn't this issue getting resolved?

All too often you guys shoot the messenger, and I think it's about time you stop it.

Comment 101

[Christian :Biesinger (don't email me, ping me on IRC)]

law is gone, for a year now I think.

Comment 102

[Brian 'netdragon' Bober]

Law is gone, so I'll take this...

I'll have to make sure the patch still works and such. I won't do any OS/2
stuff. We can handle that seperately. Piggybacking the OS/2 stuff on the same
patch doesn't seem like the most efficient way to do it.

Eventually, I'm going to write a new bootloader to replace the generic Win32
bootloader, and this issue should magically go away (at least for Win32), but
this is something that can be done more immediately.

Comment 103

[Brad Town]

In comment 57, Brian referenced two pages at CodeGuru that discussed how
Developer Studio handles this sort of thing.  If you have any Visual C++ from
6.0 through 7.1, you can try the following to see if you like this particular
style of solution.

Copy msdev.com from <VSDir>\Common\MSDev98\Bin (or devenv.com from
<VSDir>\Common7\IDE) to your Mozilla directory.
Rename the new copy Mozilla.com (or MozillaFirebird.com if using Mozilla
Firebird).  This works because the .com file uses its own name to determine the
.exe to run.

As long as start menu links and such point to the .exe rather than the .com,
they'll work just like they always have.

From the command line, if you don't specify the extension, Windows uses the .com
version before the .exe version.  Typing

  Mozilla /?

dumps out the command line options.  Typing

  Mozilla http://www.mozilla.org/

launches the browser at that page.

Note:  It's not perfect.  On my machine, both .com versions occassionally stops
printing out the options in the middle of -ProfileManager.

Comment 104

[Brian 'netdragon' Bober]

I'm considering whether to forget this bug altogether, and write a new
bootloader to replace the current standard GUI bootloader Microsoft provides.

Comment 105

[timeless]

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

Comment 106

[Tony Mechelynck [:tonymec]]

As a workaround, use "firefox -h |more". It works perfectly, even if there's already a running instance. Ditto for Thunderbird. I don't have the Mozilla Suite.

Comment 107

[Simon Paquet [:sipaq]]

*** This bug has been marked as a duplicate of 355889 ***

Comment 108

[Eyal Rozenberg]

Isn't bug 355889 the duplicate?