[Bug 54066] New: SysLink control shouldn't delete the HFONT it didn't create

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54066

Bug ID: 54066
           Summary: SysLink control shouldn't delete the HFONT it didn't
                    create
           Product: Wine
           Version: 7.22
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: comctl32
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

I believe there is a bug in `dlls/comctl32/syslink.c` where `WM_DESTROY`
handler calls `DeleteObject(infoPtr->Font)`, although this font is not owned by
the control -- it is (or can be) given to it via `WM_SETFONT` and doing this
means that a system font can be destroyed prematurely, resulting in plenty of
other problems later on in the program.

Amazingly, it looks like this code was there since a1f3756daab (Free allocated
font handles when control is destroyed., 2004-12-08) and I don't really
understand how could it not be noticed until now, but apparently somehow it
wasn't.

The following trivial patch:
```
diff --git a/dlls/comctl32/syslink.c b/dlls/comctl32/syslink.c
index 8130bf19641..efc3467838b 100644
--- a/dlls/comctl32/syslink.c
+++ b/dlls/comctl32/syslink.c
@@ -1709,7 +1709,6 @@ static LRESULT WINAPI SysLinkWindowProc(HWND hwnd, UINT
message,
     case WM_DESTROY:
         TRACE("SysLink Ctrl destruction, hwnd=%p\n", hwnd);
         SYSLINK_ClearDoc(infoPtr);
-        if(infoPtr->Font != 0) DeleteObject(infoPtr->Font);
         if(infoPtr->LinkFont != 0) DeleteObject(infoPtr->LinkFont);
         SetWindowLongPtrW(hwnd, 0, 0);
         Free (infoPtr);
```
is enough to fix the problem for me.