Re: [hatari-devel] Hatari debug mode -> console vs gui for windows

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 03/08/2025 à 15:51, Vincent Rivière a écrit :
> On 31/07/2025 at 21:08, Nicolas Pomarède wrote:
> > regarding this console issues, do you know if there's a way to detect 
> > in which "context" Hatari was launched ? ie from an already opened 
> > console or by clicking on its icon (or using windows menu to launch 
> > it) ?
>
> Unfortunately, Windows isn't designed to do that at runtime. 
> Availability of a console is normally specified at link-time: either 
> "console application" or "GUI application". This sets a specific bit 
> in the .exe header.
>
> - If the program is a "console application" (compiled with gcc 
> -mconsole), Windows ensures there is always a console to perform text 
> I/O. If the program is run from a shell (i.e. cmd.exe), the shell's 
> console is reused. If the program is double-clicked from the Explorer, 
> a new console is opened. printf() output is of course directed to that 
> console. This is the classic UNIX behaviour, except that the console 
> is automatically opened by the operating system if there is none. This 
> is a good thing for text-mode programs, but undesirable for GUI programs.
>
> - If the program is a "GUI application" (compiled with gcc -mwindows), 
> no console is reused or opened on startup. printf() does nothing, as 
> console I/O isn't initialized. Furthermore, if run from a cmd, the 
> program is started asynchronously (like "&" suffix on bash shell), so 
> the user can type new commands without having to wait for the 
> program's end. Such programs can be run synchronously by using the 
> "start /w" prefix, such as "start /w notepad". On the contrary, when 
> programs are run from a .bat file, they are always run synchronously.
>
> When run from cmd, a GUI program can attach itself to the cmd's 
> console using AttachConsole(ATTACH_PARENT_PROCESS). Then it can 
> reinitialize stdout using GetStdHandle / freopen_s / setvbuf (*), so 
> it can use printf. But this isn't ideal, because the starting cmd 
> isn't aware of that special behaviour going to happen, so it starts 
> the program asynchronously anyway. And as Thorsten mentioned, such 
> hacks don't work well with MinTTY (the terminal used by Cygwin and 
> MSYS2).
>
> (*) https://forum.qt.io/topic/144399/command-line-and-gui-at-same-time/4
>
> The most common solution is to avoid those hacks, and simply provide 2 
> executables. One compiled with -mconsole (to run with console), and 
> the other one with -mwindows (to run without console). This is the 
> solution chosen by the Java Runtime Environment. On UNIX systems, 
> there is a single "java" command, which may or may not produce output 
> to the console. On Windows systems, "java.exe" is a console 
> application, so output can be displayed. And a second executable 
> "javaw.exe" is provided, that one being a GUI application, silently 
> ignoring all console output. So the user is free to use "java" or 
> "javaw" depending on the context. Hatari could to the same, with 
> hatari.exe and hatariw.exe executables.
>
> --
> Vincent Rivière
Hi

thanks a lot for the detailed explanations (and to Christian for his 
summary too).

So, it seems the "best" solution would be to provide 2 versions of the 
hatari binaries ; we already provide 32 bit and 64 bit binaries, but as 
32 bit seems to be rarely useful nowadays,we could remove it and provide 
instead 2 binaries console/gui in 64 bit (as such, it's not for the 
space saved by removing 32 bit, but to avoid having to handle too many 
binaries per release).

We can see after 2.6.1 is released.

Nicolas