При первом же действии после запуска MS Access 2003 на экран выводится окно с ошибкой. Приложение не работоспособно.
После первой ошибки - не запускается с сообщением: err:winedevice:ServiceMain driver L"MountMgr" failed to load
После установки, после запуска 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 То что валится в консоль в приложении.
Created attachment 862 [details] log
А почему mscoree встроенная? Кажется, работать может только с виндовой, и это ещё на этапе установки .NET заменяется.
Нужно корректное тестирование, с работоспособным mscoree
Если сначала установиь Net, то при первом запуске Acces в консоли: лог(в аттаче). При последующих запусках в консоль ничего не валится и запуска не происходит.
Created attachment 954 [details] лог
даже из лога видно, что проблема в 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" разумеется, такого файла быть не может, нужно найти почему такая строка получается.
в процессе поиска. HANDLE_CustomType50 запускается на действии MsoHtmEdLFNSelfReg но свойство MsoHtmEdLFNPath инициализируется раньше, чем действие MsoHtmEdLFNSelfReg начинает выполнятся (и не через MSI_SetPropertyW). Пока не удаётся найти где (ответить на вопрос "в каком действии?")
пока не нашел. К сожалению никак не получается падать с бэктрейсом, чтобы понять в каком месте идет установка свойства. нашел что в базе это свойство должно раскрываться как SetMsoHtmEdLFNSrcPath 51 MsoHtmEdLFNPath "[SourceDir]Files\Program Files\Microsoft Office\Office11\msohtmed.exe" т.е. не правильно раскрывается SourceDir. это очень похоже на багу http://bugs.etersoft.ru/show_bug.cgi?id=256
точно понятно, что смена значения свойства проходит в 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
немного поясню. в процессе установки выполняется два действия подряд: 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 пакете офиса.
соответствия между 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.
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 из реестра.
небольшой мануал для пробега по запросам на будущее: пусть есть запрос 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 непонимая проблемы. так и не нашел, где это документировано подробнее.
Сборка 40/17 Запуск не происходит.
wine@cellar bottle bugs/1126 WINE@Etersoft 1.0 SQL 1.0.12-eter11.3/19 Запускается, работает.
(В ответ на comment #17) > wine@cellar bottle bugs/1126 > WINE@Etersoft 1.0 SQL 1.0.12-eter11.3/19 Проверено на access 2003. > Запускается, работает. Запускается. Пока должным образом не работает.
