Укажите отработанное время

Отработанное время:
Продуктивное время:
Bug 1126 - Ошибка при запуске MS Access 2003   Make a simular bug
Summary: Ошибка при запуске MS Access 2003
Status: CLOSED FIXED
Alias: None
Product: WINE@Etersoft
Classification: Продукты (Products)
Component: Запуск ; Отладка ; Исключения (show other bugs)
Version: 1.0.9
Hardware: PC Linux
: P4 normal
Target Milestone: ---
Assignee: Svetlana Zhukova
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 100 788 1415
  Show dependency treegraph
 
In work:
Reported: 2008-02-04 20:21 MSK by Константин Кондратюк
Modified: 2011-06-08 13:13 MSK (History)
4 users (show)

See Also:
Заявки RT:
Связано с:
Дата напоминания:


Attachments
log (8.55 KB, text/plain)
2010-11-18 03:58 MSK, Денис Баранов
Details
лог (7.11 KB, application/octet-stream)
2010-11-18 03:58 MSK, Денис Баранов
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Константин Кондратюк 2008-02-04 20:21:09 MSK
При первом же действии после запуска MS Access 2003 на экран выводится окно с ошибкой. Приложение не работоспособно.
Comment 1 Константин Кондратюк 2008-02-05 08:54:49 MSK
После первой ошибки - не запускается с сообщением:
err:winedevice:ServiceMain driver L"MountMgr" failed to load
Comment 2 Денис Баранов 2008-11-04 21:23:18 MSK
После установки, после запуска Access падает даже не открывая главного окна.
Сборка:
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

То что валится в консоль в приложении.
Comment 3 Денис Баранов 2008-11-04 21:23:36 MSK
Created attachment 862 [details]
log
Comment 4 Константин Кондратюк 2008-11-04 21:27:59 MSK
А почему mscoree встроенная? Кажется, работать может только с виндовой, и это ещё на этапе установки .NET заменяется.
Comment 5 Константин Кондратюк 2008-12-04 14:02:54 MSK
Нужно корректное тестирование, с работоспособным mscoree
Comment 6 Денис Баранов 2008-12-05 21:01:10 MSK
Если сначала установиь Net, то при первом запуске Acces в консоли: лог(в аттаче).

При последующих запусках в консоль ничего не валится и запуска не происходит.
Comment 7 Денис Баранов 2008-12-05 21:01:41 MSK
Created attachment 954 [details]
лог
Comment 8 Anton Rudnev 2009-01-15 20:04:30 MSK
даже из лога видно, что проблема в MSI (традиционно)

вызов CreateProcessW(NULL, cmd, NULL, NULL, FALSE, 0, NULL,
                  c_collen, &si, &info);

в HANDLE_CustomType50 происходит с cmd = L"\"C:\\windows\\Installer\\Files\\Program Files\\Microsoft Office\\Office11\\msohtmed.exe\" /regserverfp"

разумеется, такого файла быть не может, нужно найти почему такая строка получается.
Comment 9 Anton Rudnev 2009-01-16 20:32:06 MSK
в процессе поиска.

HANDLE_CustomType50 запускается на действии MsoHtmEdLFNSelfReg
но свойство MsoHtmEdLFNPath инициализируется раньше, чем действие MsoHtmEdLFNSelfReg начинает выполнятся (и не через MSI_SetPropertyW). Пока не удаётся найти где (ответить на вопрос "в каком действии?")
Comment 10 Anton Rudnev 2009-01-19 21:52:05 MSK
пока не нашел. К сожалению никак не получается падать с бэктрейсом, чтобы понять в каком месте идет установка свойства.

нашел что в базе это свойство должно раскрываться как
SetMsoHtmEdLFNSrcPath	51	MsoHtmEdLFNPath	"[SourceDir]Files\Program Files\Microsoft Office\Office11\msohtmed.exe"

т.е. не правильно раскрывается SourceDir.
это очень похоже на багу http://bugs.etersoft.ru/show_bug.cgi?id=256
Comment 11 Anton Rudnev 2009-01-20 21:06:41 MSK
точно понятно, что смена значения свойства проходит в custom действии SetMsoHtmEdLFNSrcPath (№51 - установить значение свойству)

в базе прописано строчка 
[SourceDir]Files\Program Files\Microsoft Office\Office11\msohtmed.exe

а SourceDir
раскрывается в действии SetMsoHtmEdLFNSrcPath после окончания установки на директорию C:\\windows\\Installer\\ (см. приаттаченый лог)
а в случае процесса установки -- на C:\\mso2003\\


для процесса установки менять значение SourceDir не нужно -- оно верное
для запуска приложений значение SourceDir скорее всего нужно брать из реестра ( http://bugs.etersoft.ru/show_bug.cgi?id=2501 ).

+ должен быть менханизм перевода длинных путей в короткие (или наоборот), т. е.
файл msohtmed.exe реально существует по скращенному пути 
c:/mso2003/FILES/PFILES/MSOFFICE/OFFICE11V
это должно работать для действия 51 в функции ACTION_CustomAction





Comment 12 Anton Rudnev 2009-01-21 19:42:13 MSK
немного поясню.

в процессе установки выполняется два действия подряд:

1. номер 51 (назначить значение свойству) SetMsoHtmEdLFNSrcPath

затем:
2. номер 50 (запустить процесс прочитав имя файла из свойства) MsoHtmEdLFNSelfReg

в певом по порядку действии значение свойству MsoHtmEdLFNPath выполняется неправильно.

вопрос в том как это исправить: понятно, что это можно исправить либо в обработчике 51 (если имя файла, которое присваивается свойству не существует, то скорректировать его путь на правильный), или же 50 (по необходимости скорректировать его путь на правильный перед вызовом CreateProcess).

что будет, если мы будем это делать в обработчике 51?

дело в том, что небольшое исследование показывает, что в качестве значения свойства обработчик действия 51 ставит не только пути имени файлов или директорий но иногда совершенно произвольные значения. Даже при установке одно только офиса там попадают данные вроде:

L"74017-640-0000106-57381\\GWH28DGCMPP6RC46J4MT3HFDY\\#xA40000000300000037343031372D3634302D303030303130362D353733383100720000003132332D31323334350000000000000000354E1105B8180A8A53AE4C0C2E0100000000005D247C4124F71D00000000000000000000000000000000000000000000000000323337323100000000000000000000003365A70"...

L"FALSE"

L"1"

L"VisualStudioTeamCoreUI.dll"

т.е. уже условие "такого файла не существует" ставить будет не корректно.
поэтому этот вариант мы отметаем.

что у нас с обработчиком 50?

обработчик 50 просто читает данные из заданного свойства, конкатенирует их с параметрами командной строки и затем запускает их через CreateProcess.

Тут всегда значение свойства будет имя исполняемого файла.
Но что делать, если такого файла не существует: обработчик действия 50 реализован в функции HANDLE_CustomType50 и ему не доступна никакая информация о том, из каких компонентов (в нашем случае SourceDir) складывалось значение свойства (это значение просто туда записано). Разбирать путь, а затем вычислять, где файл находится было бы слишком нагруженно.

разбираюсь с тем, как MSI под Windows реагирует на ошибку без дальнейших последствий в виде падения. Т. е. для действия 50 признаю, что ошибка в оригинальном msi пакете офиса.
Comment 13 Anton Rudnev 2009-01-22 20:51:29 MSK
соответствия между ShortName и LongName указаны в таблице Directory ( http://msdn.microsoft.com/en-us/library/aa368295.aspx ) в поле DefaultDir

модификации подвергнется обработчик действия 50.
Когда CreateProcess будет отрабатываться не верно, то будет происходить коррекция пути, по этой таблице.

В этом поле данные записаны таким образом, что лучше использовать like в запросе. Однако like в MSI SQL не поддерживается и никакого аналога нет ( http://msdn.microsoft.com/en-us/library/aa372021.aspx ).

Заканчиваю реализовывать нечто подобное через MSI_ViewExecute ... MSI_ViewFetch ... MSI_ViewClose.
Comment 14 Anton Rudnev 2009-01-27 18:06:55 MSK
http://lists.etersoft.ru/pipermail/wine-patches/2009-January/000241.html

патч решает проблему неправильных путей в msi таблице в процессе установки на уровне 50-ого действия (запуск процесса).

в процессе запуска используется путь C:\\windows\\Installer\\Files\\Program Files\\Microsoft Office\\Office11\\msohtmed.exe с неверным SourceDir, это я решу позже, для обработчика действия 51 (установить значение свойства), забирая значение SourceDir из реестра.
Comment 15 Anton Rudnev 2009-01-27 18:19:56 MSK
небольшой мануал для пробега по запросам на будущее:

пусть есть запрос WCHAR querystr[] = {'S','E','L',...

далее нужно делать MSI_OpenQuery(package->db, &view, querystr, ...как в printf);
где 
package -- это текущий пакет
view -- это MSIQUERY *view = NULL;

далее нужно делать MSI_ViewExecute(view, NULL)

далее открываем цикл с итерациями по записям

делаем r = MSI_ViewFetch(view, &rec);
в rec получаем запись
r - это результат выполнения:
если r == ERROR_NO_MORE_ITEMS, то цикл завершаем.

далее MSI_ViewClose(view); 
(не путать с MSI_CloseView)

далее ОБЯЗАТЕЛЬНО! msiobj_release(&view->hdr);
я так и не понял почему это надо делать, но если этого не делать, то можно очень долго ловить сегфолты при последующих MSI_OpenQuery на любых view непонимая проблемы.

так и не нашел, где это документировано подробнее.
Comment 16 Andrey Vusik 2009-01-30 13:37:12 MSK
Сборка 40/17
Запуск не происходит.
Comment 17 Svetlana Zhukova 2011-06-07 14:41:16 MSK
wine@cellar bottle bugs/1126
WINE@Etersoft 1.0 SQL 1.0.12-eter11.3/19

Запускается, работает.
Comment 18 Svetlana Zhukova 2011-06-08 13:13:14 MSK
(В ответ на comment #17)
> wine@cellar bottle bugs/1126
> WINE@Etersoft 1.0 SQL 1.0.12-eter11.3/19

Проверено на access 2003.  

> Запускается, работает.

Запускается. Пока должным образом не работает.