#7792 closed feature request (fixed)
Suppress Console Window Option
| Reported by: | SF/collector9 | Owned by: | Kirben |
|---|---|---|---|
| Priority: | normal | Component: | Port: Win32 |
| Version: | 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)
Change History (16)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
| Owner: | set to |
|---|---|
| Resolution: | → wontfix |
| Status: | new → closed |
comment:3 by , 14 years ago
| Resolution: | wontfix |
|---|---|
| Status: | closed → new |
comment:4 by , 14 years ago
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 by , 14 years ago
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.
comment:6 by , 14 years ago
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 by , 14 years ago
nevermind about the USERPROFILE, I see it's using the current working directory.
comment:8 by , 14 years ago
Logging should always be on, and it should always log to the same place. Anything else would be inconsistent and confusing.
comment:9 by , 14 years ago
(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 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
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 by , 11 years ago
Since --no-console is now implemented as a command line option, we can close this as fixed.
comment:14 by , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:15 by , 6 years ago
| Component: | → Port: Win32 |
|---|
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.