Opened 9 years ago

Closed 5 years ago

Last modified 7 months ago

#7792 closed enhancement (fixed)

Suppress Console Window Option

Reported by: SF/collector9 Owned by: Kirben
Priority: normal Component: Port: Win32
Keywords: Cc:
Game:

Description

It would be good to have a way to suppress the console from a command line switch much like DOSBox can.

Ticket imported from: #3093800. Ticket imported from: feature-requests/608.

Attachments (1)

console.diff (6.1 KB) - added by Kirben 9 years ago.
Patch using FreeConsole()

Download all attachments as: .zip

Change History (16)

comment:1 Changed 9 years ago by Kirben

DOSBox uses the FreeConsole(), which isn't reliable on Windows 2000 and later. If you start DOSBox (with -noconsole option) via a Command Prompt, the console won't be freed.

The console window is specifically enabled in Windows builds, to make feedback (i.e. bugs, unknown games) from people much easier.

comment:2 Changed 9 years ago by Kirben

Owner: set to Kirben
Resolution: wontfix
Status: newclosed

comment:3 Changed 9 years ago by fingolfin

Resolution: wontfix
Status: closednew

comment:4 Changed 9 years ago by fingolfin

Travis,
actually, I'd like to re-evaluate this long time decision.

Do we enabled the console window in releases, too? Always?

That seems wrong and undesirable to me. Most people just want to play. For most users, feedback only starts to matter when they run into problems. It seems to me that we should therefore not show the console by default, but instead have an option to optionally enable it, e.g. when trying to debug problems. This way, users are not annoyed by the console by default, but if there is reason for feedback or diagnostics, they can simply enable it (e.g. via a config dialog setting).

Regarding your cryptic comment on FreeConsole: Can you explain the relevance of that? As I see it, as long as we do not start attached to a console in the first place, we don't have to free it / detach from it either, so no problem there.

comment:5 Changed 9 years ago by Kirben

Yes, the console Window is enabled in all Windows builds.

The problem with FreeConsle() is the prompt is not returned, when launched via a command prompt (in Windows 2000 onwards), unless the program in compiled as GUI program. While compiling as GUI program means no feedback (to current console window) when using arguments, from a command prompt. Unfortunately there doesn't seem to be any easy way to work around this problem, due to the way that console control is based on how Windows programs are compiled.

I have attached an alternative patch, which still enables the console window by default in Windows, for feedback reasons. But offers a '--no-console' option, for users who would rather not have the console window around.

The alternative patch uses FreeConsole(), which it is simpler, since the currently disabled method in ScummVM SVN offers no advantages. With the console output redirected to log files in the %APPDATA%\ScummVM path (where available) or the current working directory (older Windows versions), when the '-no-console' option is used.

Changed 9 years ago by Kirben

Attachment: console.diff added

Patch using FreeConsole()

comment:6 Changed 9 years ago by m-kiewitz

Like I said on the wiki. CMD.exe is waiting for charmode processes to end. The called process doesn't do anything, so also FreeConsole() wont be able to change it.

Also most users are definitely not interested in the console window at all, hiding the console should be default.

It's also automatically redirecting now, when the console is hidden. I would propose that we should additionally log all the time - not depending, if we hide/show the console.

And at least on my Windows 98 notebook, there is no USERPROFILE environment variable. AppData is inside %WINDIR% and is not even called "application data", the name was already translated as well.

comment:7 Changed 9 years ago by m-kiewitz

nevermind about the USERPROFILE, I see it's using the current working directory.

comment:8 Changed 9 years ago by fingolfin

Logging should always be on, and it should always log to the same place. Anything else would be inconsistent and confusing.

comment:9 Changed 9 years ago by fingolfin

(Same location on the same computer, I mean. It's of course OK to log to a different place depending on the Windows version)

comment:10 Changed 9 years ago by Kirben

FreeConsole() is able to free the console, but only on old Windows versions (Windows 95/98/ME).

Sending the stdout/stderr to both the console and a file looks more complicated, since a redirect usually has exclusive access. But you are welcome to make further changes to patch, to always use a log file.

The logs are stored in the exact same location as the ScummVM config file, in my patch.

comment:11 Changed 9 years ago by Kirben

Correction to my previous message, when using my patch:
The logs are stored in the exact same location as the ScummVM config file, in Windows NT4 onwards. Using USERPROFILE for Windows NT4, and APPDATA for Windows 2000/XP/Vista/7.

While logs are stored in the current working directory on old Windows versions (Windows 95/98/ME).

comment:12 Changed 9 years ago by fingolfin

Of course it's a bit more work to redirect stdout/stderr to two destinations (i.e. do a "tee"), but always creating a log file is important enough to warrant spending the extra effort.
Plus, if we do that, we don't have to use FreeConsole at all, we can just hide the console. And show it again later if we desire so.

I will investigate ways to do so.

Of course, a very simple way to implement a tee on stdout is to use a wrappper app which invokes ScummVM, but that's not very nice, so I'd prefer to avoid it.

And on the long run, we should avoid *any* use of printf in our code. Then, this whole teeing business reduces to inserting a few lines of code in our central console output functions (which would be used by warning, error, debug, etc.), making this rather trivial to implement. Actually, this might be the best solution right now. But I'll do some research on Windows pipes etc.

There's another remark about the patch (and current SVN): neither "no_console" nor "show_console" strike me as good choices for the config key. Better to use just "console", then the user can equally use "--console" and "--no-console" on the command line, as opposed to "--no-no-console" and "--no-console", respectively "--show-console" and "--no-show-console" :).

comment:13 Changed 5 years ago by digitall

Since --no-console is now implemented as a command line option, we can close this as fixed.

comment:14 Changed 5 years ago by digitall

Resolution: fixed
Status: newclosed

comment:15 Changed 7 months ago by digitall

Component: Port: Win32
Note: See TracTickets for help on using tickets.