Bug 108

При открытии отображается окно "Ошибка помощи". Содержание помощи отображается не очень корректно, но информация присутствует вся.
Панель инсрументов не работает и выглядит некорректно

Причём окно "Ошибка помощи" открывается только после того, как winhelp запустится, прочитает справку и выведет её на экран.

В бета-версии 1.0.9 окна с сообщением об ошибке не возникает.

Сейчас помощь открывается корректно, но появились проблемы со шрифтами, см. скрин.

wine-etersoft-sql-1.0.9-alt0.M41.11
libwine-gl-1.0.9-alt0.M41.32
libwine-1.0.9-alt0.M41.32
wine-1.0.9-alt0.M41.32

Created attachment 861 [details]
скрин

На данный момент баги, похоже две.

Первая с запуском, собственно, помощи.
Если запустить через ww со свежей склонированной копией репозитория, то возникает сообщение с окошком "Ошибка помощи". А в консоль пишется о падении с бэктрейсом

=>0 0x7ef05128 WINHELP_GetCaption+0x27(wpage=0x33fda8) [/home/mibori/Projects/wine/programs/winhlp32/winhelp.c:547] in winhlp32 (0x0033fba8)
  1 0x7ef05a7a WINHELP_CreateHelpWindow+0x74c(wpage=0x33fda8, nCmdShow=0, remember=1) [/home/mibori/Projects/wine/programs/winhlp32/winhelp.c:688] in winhlp32 (0x0033fd88)
  2 0x7ef060b7 WINHELP_OpenHelpWindow+0x67(lookup=0x7eef61fe, hlpfile=(nil), val=0, wi=0x7ef1f860, nCmdShow=0) [/home/mibori/Projects/wine/programs/winhlp32/winhelp.c:772] in winhlp32 (0x0033fdb8)
  3 0x7ef08e45 WinMain+0x2f9(hInstance=0x7eef0000, prev=(nil), cmdline="", show=0) [/home/mibori/Projects/wine/programs/winhlp32/winhelp.c:1710] in winhlp32 (0x0033fe38)
  4 0x7ef0b7a6 main+0x10a() [/home/mibori/Projects/wine/dlls/winecrt0/exe_main.c:48] in winhlp32 (0x0033feb8)
  5 0x7ef0b682 __wine_spec_exe_entry+0x6e(peb=0x7ffdf000) [/home/mibori/Projects/wine/dlls/winecrt0/exe_entry.c:36] in winhlp32 (0x0033fef8)
  6 0x7b881a7c start_process+0xe4(arg=(nil)) [/home/mibori/Projects/wine/dlls/kernel32/process.c:915] in kernel32 (0x0033ffe8)
  7 0xb7e6bcc7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000)
в winhlp32

т. е. помощь посмотреть не удаётся

Если запускать, через wine то окошко помощи выводится.
И как раз там неверное отображение текста -- это вторая ошибка.

Интересует, чем отличается wine от свежего ww.

по строчкам канала process:

trace:process:CreateProcessW app (null) cmdline L"winhlp32.exe -x"
trace:process:find_exe_file looking for L"winhlp32.exe"
trace:process:find_exe_file Trying native exe L"C:\\windows\\system32\\winhlp32.exe"
trace:process:CreateProcessW starting L"C:\\windows\\system32\\winhlp32.exe" as Win32 binary (0x10000000-0x10011000)

понятно, что делается попытка запустить winhlp32.exe -x

если мы запускаем ww winhlp32.exe -x, то получаем падение.
если запускаем wine winhlp32.exe -x, то получаем:

<wine@cellar bottle 1c77/1c7727-night>$ wine winhlp32 -x
fixme:ntoskrnl:IoRegisterDeviceInterface 0x111770 {608225bc-766b-40a8-b8a4-d96bc999ae35} <null> 0x111970
fixme:ntoskrnl:IoRegisterDeviceInterface 0x1117e0 {10d60713-fb4c-4bb1-941b-44b79d25af8b} <null> 0x11113c
fixme:ntoskrnl:IoSetDeviceInterfaceState (null) 1

и висим.

Впрочем, падение проявляется и без параметра -x.
Нормальное поведение без параметра -x -- это запустить диалоговое окно открытия файла .hlp (что и происходит в случае, если мы запускаем с wine)

c wwo падает, но немного по-другому.

падение с ww поисходит в WINHELP_GetCaption:

static char* WINHELP_GetCaption(WINHELP_WNDPAGE* wpage){
    if (wpage->wininfo->caption[0])
        return wpage->wininfo->caption;
    return wpage->page->file->lpszTitle;
}

из-за того, что wpage -> page == 0

я пришел к тому, что причина падения кроется в этом коде из WinMain winhlp32:

    if (*cmdline)
    {
        ...
        hlpfile = WINHELP_LookupHelpFile(cmdline);
        if (!hlpfile) return 0;
    }
    else
        hlpfile = NULL;

в hlpfile хранится структура описывающая .hlp-файл

если вместо hlpfile = NULL подставить hlpfile = WINHELP_LookupHelpFile(cmdline);

то, winhlp32 не будет падать, а поругается на то, что .hlp-файл не найден, и откроет диалоговое окно Open file
при этом файл открывается и можно решать проблему с некорректным отображением букв.

Однако это изменение не работает в 1C.

параметр -x "приказывает" winhlp32 запуститься скрыто.
какая в этом логика я пока не понял.

Кроме того 1С никак не передает в командной строке какой именно файл помощи открывать. И как оно на самом деле передается пока не выяснил.

Попытки вручную по коду проанализировать почему все-таки на самом деле происходит падение, не увенчались успехом.

На данный момент, версия wine, запускаемая через "wine" -- это 1.0.9-eter42. Через git откатился до 1.0.9-eter34.1. Падение всё равно проявляется.

Из этого следует думать, что проблема никак не решается на уровне исходников: т. е. нет ни одного коммита приводящего к падению winhlp32. Проблема, возможно, на уровне сборки.

Далее буду решать проблему с неправильным отображением букв.

Следующий патч -- способ заставить winhlp32 отображать .hlp-файл на собственных исходниках без падения...

Created attachment 1083 [details]
патч

Изменение шрифтов через реестр ни как не помогает.

И, скорее всего, не должно помогать: если взглянуть на приаттаченый скриншот, то искажение можно видеть также и в заголовках.

Попробую проанализировать работу от DrawText.

(In reply to comment #12)
> Изменение шрифтов через реестр ни как не
> помогает.
> 
> И, скорее всего, не должно помогать: если
> взглянуть на приаттаченый скриншот, то
> искажение можно видеть также и в
> заголовках.
> 
> Попробую проанализировать работу от DrawText.
Это не тот уровень совершенно. Проблема либо в кодировке исходного текста, либо в особом названии шрифта, который используется.
Но всё это можно увидеть гораздо раньше. 

при помощи Help & Manual 5 (http://www.ec-software.com/) и Microsoft Winhelp compiler (там же скачать можно) удалось создать русский hlp файл, в котором не искажается текст.

Попробую сравнить канал font искажаемого и неискажаемого файла и попробывать создать файл с искажением.

В 1С-овском hlp-файле используется шрифт (ARIAL CYR, 9)
с нестандартным размером отступа между строк (он уже обычного).

Попытка перекомпилировать этот файл в просто (Arial, 9) или поправить отступ, дает hlp-файл, который отображается "вопросиками".

Попытки прописать в реестре, чтобы вместо Arial CYR отображался просто Arial, также ничего не дают.

Нужно анализировать, какой шрифт запрашивается у шрифтового движка, с какими параметрами.

По-моему, говорить о проблеме со шрифтами - это не совсем верно. 

Вот что сыпется в трейсы функции ExtTextOutW:

trace:font:ExtTextOutW 0x1e0, 21, 422, 00001004, 0x33ec40, L"Iaoaaaiiua", 10, 0x33e8e4)
...
trace:font:ExtTextOutW 0x1e0, 21, 443, 00001004, 0x33ec40, L"Iieuciaaoaeuneea eioadoaenu", 27, 0x33e8e4)
...
trace:font:ExtTextOutW 0x1e0, 21, 464, 00001004, 0x33ec40, L"Idaaa ainooia", 13, 0x33e8e4)


А вот это появляется на экране, очень похоже:
Ìåòàäàííûå
Ïîëüçîâàòåëüñêèå èíòåðôåéñû
Ïðàâà äîñòóïà

(In reply to comment #17)
> По-моему, говорить о проблеме со шрифтами -
> это не совсем верно. 
> 
Ну так выводится верно - текст в неправильной кодировке. Осталось только узнать, какой заказывается шрифт, отображаемый или подменяемый wine неправильно.

(In reply to comment #18)
> (In reply to comment #17)
> > По-моему, говорить о проблеме со шрифтами -
> > это не совсем верно. 
> > 
> Ну так выводится верно - текст в
> неправильной кодировке. Осталось только
> узнать, какой заказывается шрифт,
> отображаемый или подменяемый wine
> неправильно.
На мой взгляд, там при перекодировании из 8-битного в UCS2
неверно подразумевается кодировка для 8-битного текста,
поэтому результат в UCS2 получается латиницей.

Вот пример исправления: 

--- hlpfile.c.orig<---->2004-02-16 03:17:40 +0300
+++ programs/winhelp/hlpfile.c<>2004-02-16 03:16:37 +0300
@@ -1186,7 +1186,7 @@
         hlpfile->fonts[i].LogFont.lfItalic = (flag & 2) ? TRUE : FALSE;
         hlpfile->fonts[i].LogFont.lfUnderline = (flag & 4) ? TRUE : FALSE;
         hlpfile->fonts[i].LogFont.lfStrikeOut = (flag & 8) ? TRUE : FALSE;
-        hlpfile->fonts[i].LogFont.lfCharSet = ANSI_CHARSET;
+        hlpfile->fonts[i].LogFont.lfCharSet = DEFAULT_CHARSET;
         hlpfile->fonts[i].LogFont.lfOutPrecision = OUT_DEFAULT_PRECIS;
         hlpfile->fonts[i].LogFont.lfClipPrecision = CLIP_DEFAULT_PRECIS;
         hlpfile->fonts[i].LogFont.lfQuality = DEFAULT_QUALITY;


Собственно при поиске в этом файле по DEFAULT_CHARSET
одну багу я уже вижу.

> На мой взгляд, там при перекодировании из
> 8-битного в UCS2
> неверно подразумевается кодировка для
> 8-битного текста,
> поэтому результат в UCS2 получается
> латиницей.
> 
По-моему, если неверно идёт из 8 в 16 или больше, то отображается всё квадратами (управляющими символами).

(In reply to comment #20)
> По-моему, если неверно идёт из 8 в 16 или
> больше, то отображается всё квадратами
> (управляющими символами).
Ну почему же, в кодовой странице cp1252 например
http://en.wikipedia.org/wiki/Windows-1252 
на том месте, где у нас русские буквы, находятся
разные символы с диакритическими знаками. Соответственно, их мы потом в Юникоде и видим.

(In reply to comment #21)
> (In reply to comment #20)
> > По-моему, если неверно идёт из 8 в 16 или
> > больше, то отображается всё квадратами
> > (управляющими символами).
> Ну почему же, в кодовой странице cp1252
> например
> http://en.wikipedia.org/wiki/Windows-1252 
> на том месте, где у нас русские буквы,
> находятся
> разные символы с диакритическими знаками.
> Соответственно, их мы потом в Юникоде и
> видим.
> 
А, ну ясно. Тут сначала выбирается 1252, а потом это безобразие кодируется в юникод.

В winhlp32 используем charset, полученный из функции TranslateCharsetInfo().

commit 1eedd807fc267af2f2fafb0de06935a861230e6d
Author: Konstantin Kondratyuk <kondratyuk@etersoft.ru>
Date:   Thu Apr 16 17:32:50 2009 +0400

    winhlp32: Use charset from TranslateCharsetInfo results (eterbug #108)

Принято eter20/13