Re: [PATCH v2 1/3] conhost: Save console settings as global defaults on first run

[Hugh McMaster]

Hi Jacek,

On Wed, 20 Apr 2022 at 23:10, Hugh McMaster wrote:
> SetCurrentConsoleFontEx() only alters the active session settings; it
> does not modify console registry settings. However, the call to
> SetCurrentConsoleFontEx() could end up modifying the registry settings
> if CreateFontIndirectW() fails, which is extremely unlikely since it
> selects a font as close as possible to the LOGFONT parameters.
>
> On Windows, passing an invalid font face name via CONSOLE_FONT_INFOEX
> generally results in the existing font remaining unchanged. On Windows
> 10 1809 or more recent, the font seems to change to a default font,
> Courier New. See [1] for some tests.
>
> Wine behaves similarly here. On my system, a simple test program set
> the font from Liberation Mono to DejaVu Sans Mono.
>
> If you're concerned, it might be better to create a new code path for
> set_output_info(). The call could check the returned value of
> set_console_font() and, if it failed (however unlikely that is), make
> a second call using the current active font (or get the first valid
> font).
>
> That proposal probably didn't make a lot of sense, so I might prepare
> a patch to make it clear. Let me know if you have a preference for
> using the active font as a fallback or getting the first valid font.
>
> I was planning on making updates to the default font code later, but
> it seems better to fix this now.

Scratch all of that. A better and more practical solution for the
SetCurrentConsoleFontex() and first-run code paths would be to call
EnumFontFamiliesEx() to get a valid matching font. In the case of
SetCurrentConsoleFontEx(), the font will either match or be very
similar. This would mirror the behaviour seen on Windows.

Font changes via the console dialog would not need that code path, as
EnumFontFamiliesEx() is already used to get valid console font names
and sizes.

Hugh