[PATCH] gdi32: Collapse relative paths inside true type fonts file names in registry.

[Paul Gofman]

On 10/7/19 15:21, Nikolay Sivov wrote:
>
>
> Is it the same for tahoma.ttf?Were you able to figure out where in CEF
> it fails and why exactly?
>
>
It is the same for tahoma.ttf in a way that it also gets "\\..\\" in the
path of course, but only times.ttf affects the crash I debugged.

I didn't figure exact reason inside libcef.dll. I just can say that
crash happens inside its code using some (probably class) pointers
initialized earlier. The minimal fix which makes me think that the core
reason is in treating the font file name outside of Wine is the fact
that I can workaround the crash by using GetFullPathName for returned
file name in localfontfileloader_GetFilePathFromKey() only
(ddraw/font.c). As far as I can tell, this function is not used anywhere
in Wine directly. This still leaves some chance of course that the
output of this function was passed to some Wine function which
mishandles the path with "..", but I could not find this path passed to
anything with +font, +file or +relay log. The sequence of fonts queries
to dwrite changes after getting "Times New Roman" from enumeration
through dwrite between successful sequence (with the path without "..")
and the failing one. I also don't think that breaking on a font path
with ".." is likely as we would likely have this problem exhibit itself
somewhere else. This leaves some small chance of course that the true
core reason lies somewhere deeper. My reasoning was that avoiding
relative path parts in font file name is the right thing to do
regardless. I was also thinking of suggesting the fix right to
dwrite/font.c create_local_file_reference(), as the documentation to
IDWriteFactory_CreateFontFileReference suggests that file path must be
absolute path. But it looks reasonable to me to avoid unusual path in
registry filled by gdi32 also, as it also exposed to the applications.
Besides, according to my testing on Windows, while
_CreateFontFileReference rejects truly relative paths, it is ok with the
paths containing "\\..\\".