[Bug 60217] New: Prefix update (wineboot -u) resets a customised "MS Shell Dlg 2" font substitute to Tahoma, while "MS Shell Dlg" is kept

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=60217

            Bug ID: 60217
           Summary: Prefix update (wineboot -u) resets a customised "MS
                    Shell Dlg 2" font substitute to Tahoma, while "MS
                    Shell Dlg" is kept
           Product: Wine
           Version: 11.16
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: minor
          Priority: P2
         Component: loader
          Assignee: [e-mail]
          Reporter: [e-mail]
  Target Milestone: ---
      Distribution: ---

Created attachment 81919
  --> http://bugs.winehq.org/attachment.cgi?id=81919
Terminal output of the reproduction steps on wine-11.16 (clean prefix)

A font substitute set by the user for "MS Shell Dlg 2" under
HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes is
reset to Tahoma every time the prefix is updated, that is at the first
start of Wine after any Wine upgrade, or with "wineboot -u". The sibling
"MS Shell Dlg" substitute survives the same update.

Steps to reproduce, in a clean 64-bit prefix:

  export WINEPREFIX=~/wine-bugtest-fontsubst
  wineboot -i
  K='HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes'
  wine reg add "$K" /v "MS Shell Dlg"   /t REG_SZ /d "DejaVu Sans" /f
  wine reg add "$K" /v "MS Shell Dlg 2" /t REG_SZ /d "DejaVu Sans" /f
  wineboot -u
  wine reg query "$K" | grep "MS Shell Dlg"

Observed (wine-11.16, full terminal output attached):

    MS Shell Dlg      REG_SZ    DejaVu Sans
    MS Shell Dlg 2    REG_SZ    Tahoma

Expected: both values keep what the user set. A prefix update should not
undo a font configuration, as it already doesn't for "MS Shell Dlg"; on
Windows, FontSubstitutes is a system setting that upgrades leave alone.

I hit this on a prefix where both substitutes had been changed to another
face: after the upgrade to wine-11.16, dialogs asking for "MS Shell Dlg 2"
were back to Tahoma, with nothing in the logs to explain it. The only way
to notice is to re-read the registry after every upgrade.

Analysis: the two values are written by two different mechanisms.
"MS Shell Dlg" is written by win32u, in update_codepage()
(dlls/win32u/font.c, lines 3105-3110 in wine-11.16), and only when the
stored "Codepages" value changes — the code carries the comment "Only
update these if the Codepage changed". "MS Shell Dlg 2" comes from
loader/wine.inf.in, line 515:

  HKLM,%FontSubStr%,"MS Shell Dlg 2",,"Tahoma"

with an empty flags field, so setupapi rewrites it on every
DefaultInstall: a value is left alone only when the entry carries
FLG_ADDREG_NOCLOBBER (dlls/setupapi/install.c, line 384). wine.inf.in
already uses that flag (",2,") for more than a hundred entries users are
expected to customise, such as file associations, but for none of the
FontSubstitutes entries.

Marking the entry NOCLOBBER ("MS Shell Dlg 2",2,"Tahoma") keeps the
default for new prefixes and makes the two substitutes behave the same
way. Alternatively the value could be written next to "MS Shell Dlg" in
update_codepage(), under the same guard.

Tested on wine-11.16 (Arch Linux package, x86_64, unmodified); the
wine.inf.in line and the update_codepage() code are identical on current
git master.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 60217] Prefix update (wineboot -u) resets a customised "MS Shell Dlg 2" font substitute to Tahoma, while "MS Shell Dlg" is kept

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=60217

Ken Sharp <[e-mail]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |http://bugs.winehq.org/show
                   |                            |_bug.cgi?id=31655

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.