Думаю, название каждого из них довольно красноречиво говорит само за себя. Вдобавок ко всем перечисленным есть еще один псевдоканал под названием all, являющийся ссылкой на все каналы сразу. Выбрав его, мы получим абсолютно все отладочные сообщения, создаваемые wine. Количество отладочной информации выводимой в тот или иной канал, может быть довольно большим, если не сказать огромным, поэтому, пользуясь точным указанием интересующих нас каналов и классов сообщений, мы имеем возможность отфильтровать только те фрагменты данных, которые нам реально необходимы. Давайте разберемся, как это делается. Описание типа нужных нам отладочных сообщений чаще всего выглядит довольно просто. К примеру, если мы хотим увидеть сообщения класса WARN для канала, отвечающего за работу с реестром, то должны выполнить следующую команду:

$  /opt/cxoffice/bin/wine --debugmsg warn+reg имя программы

В случае если класс сообщений не указан, wine считает, что мы хотим читать все классы данного канала. Примером, иллюстрирующим такой подход, может стать следующая команда:

$  /opt/cxoffice/bin/wine --debugmsg +reg имя программы

Классами сообщения можно управлять не только с помощью знака «+», но и воспользовавшись его антиподом, знаком «-». Следующая приятная возможность, которая может весьма облегчить жизнь во время занятий поиском неисправностей, это то, что каналы сообщений можно перечислять через запятые. Нижеприведенная команда покажет все сообщения, относящиеся к загрузке dll, а из тех, что выводятся при работе с реестром, скроет все, что подпадает под класс ERR.

$  /opt/cxoffice/bin/wine --debugmsg +loaddll, err-reg имя программы

Итак, разобравшись с теорией, приступим к практическим действиям. Нам нужно узнать, что же именно мешает программе установить в систему эту загадочную библиотеку OPASmgr.dll. А так как речь идет об ошибке, связанной с файлом, то, видимо, стоит посмотреть, как приложение обращается со своими файлами. Для этого подаем следующую команду:

$ /opt/cxoffice/bin/wine --cx-log logfile.txt --debugmsg +file ./Ussp30to.exe

Сообщений получается довольно много, поэтому я специально перенаправил их в файл logfile.txt с помощью ключа командной строки --cx-log. В результате получился файл отладки размером в полтора мегабайта. Пройдясь по файлу поиском, обнаруживаем в нем следующие записи:

trace:file:CreateFileW L"C:\WINDOWS\TEMP\pft0dc8~tmp\Programs\English\OPASMgr.dll"

GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WRITE CREATE

trace:file:SetFileAttributesW (L"C:\WINDOWS\TEMP\pft0dc8~tmp\Programs\English\OPASMgr.dll",fffffffe)

trace:file:SetFileAttributesW (L"C:\WINDOWS\TEMP\pft0dc8~tmp\Programs\English\OPASMgr.dll",20)

Повторяющиеся записи я отфильтровал, но все равно, судя по суете в районе C:\WINDOWS\TEMP\, скрипт Install Shield производит туда распаковку дистрибутива и затем запускает оттуда инсталляцию. Идем далее и обнаруживаем еще более интересные факты.

trace:file:CreateFileW L"C:\Program Files\Ulead SmartSaver Pro 3.0\OPASMgr.dll" GENERIC_READ FILE_SHARE_READ

OPEN_EXISTING  attributes 0x80     

warn:file:CreateFileW Unable to get full filename from L"C:\Program Files\Ulead SmartSaver Pro 3.0\OPASMgr.dll"

(GLE 2)

trace:file:CreateFileW L"C:\Windows\Temp\pft0dc8~tmp\Programs\English\OPASMgr.dll"

GENERIC_READ FILE_SHARE_READ OPEN_EXISTING  attributes 0x80

trace:file:CreateFileW returning 0x78

trace:file:GetFileInformationByHandle 0x78