Продолжение задания https://bugs.etersoft.ru/show_bug.cgi?id=8849 Название и номер бутылки будет в следующем сообщении. Установлено: - 1С 77 - Специально подготовленная конфигурация от клиента, с одним товаром "xxxxx" - Уже зарегистрированная компонента barcode.ocx (командой wine regsvr32 barcode.ocx) Воспроизведение: 1) Открываем 1С. 2) Справочники -> Номенклатура -> Товар "xxxxx" 3) Внизу есть кнопочка "Этикетка(вн.)" жмём. 4) "Выводить этикету на" : экран - это предпросмотр принтер - это печать ( тестировалось в cups-pdf ) При печати и предпросмотре всегда выводиться значение "1234567890128", которое является тестовым. Должно соответствовать значению из поля "Штрихкод" со страницы из пункта 3). Поведение в Windows : что в поле "Штрихкод", то и в предпросмотре, и при печати.
(Ответ Konstantin Artyushkin на комментарий0) > Воспроизведение: > > 1) Открываем 1С. > 2) Справочники -> Номенклатура -> Товар "xxxxx" > 3) Внизу есть кнопочка "Этикетка(вн.)" жмём. > 4) "Выводить этикету на" : > экран - это предпросмотр > принтер - это печать ( тестировалось в cups-pdf ) > > При печати и предпросмотре всегда выводиться значение "1234567890128", > которое является тестовым. Должно соответствовать значению из поля > "Штрихкод" со страницы из пункта 3). Во-первых, при выполнении в eter-2.1 проблема полностью воспроизводится. (Было бы странно, если бы это было не так, так как никаких существенных изменений в etre-2.1 не было). Во-вторых, при попытке выполнить 1С из префикса .wine-10620 под winehq, 1С не может открыть базу с сообщением "Общая файловая ошибка при доступе к C:\DB\1Cv7.MD". Это регрессия, так как никаких подобных проблем раньше я не видел. Дальнейшее исследование проблемы с открытием базы показало, что виной всему новая реализация блокировок при работе с IStorage. Патч, исправляющий эту регрессию, я отправил в wine-patches [1]. С этим патчом после изменения кодовой страницы базы в конфигураторе (из-за хаков в eter-2.1 изменяющих перекодировку между cp1251 и unicode) база успешно открылась и под winehq. Более того, под winehq barcode.ocx показывает правильный код на этикетке, а не "1234567890128". В задаче https://bugs.etersoft.ru/show_bug.cgi?id=8849 было выяснено, что использование ole32=n позволяло избавиться от проблемы с неверным кодом, поэтому я скопировал ole32.dll.so из winehq в eter-2.1 и попробовал выполнить 1С. Это не получилось, так как ole32 в winehq использует нереализованный в eter-2.1 kernel32 API InitOnceExecuteOnce. После простого хака, который избегает использования InitOnceExecuteOnce, ole32 из winehq заработал в eter-2.1 и с ним код на этикетке тоже показывается правильно. Значит проблема действительно была в ole32, и ole32 из winehq содержит исправление для этой проблемы. Пока я не нашел, какое именно изменение/патч в winehq исправил проблему с barcode.ocx. [1] https://www.winehq.org/pipermail/wine-patches/2015-July/140536.html
Created attachment 3226 [details] InitOnceExecuteOnce хак для ole32 из winehq для использования в ветке eter-2.1 InitOnceExecuteOnce хак для ole32 из winehq для использования в ветке eter-2.1
(Ответ Dmitry Timoshkov на комментарий2) > Во-вторых, при попытке выполнить 1С из префикса .wine-10620 под winehq, > 1С не может открыть базу с сообщением "Общая файловая ошибка при доступе > к C:\DB\1Cv7.MD". Это регрессия, так как никаких подобных проблем раньше > я не видел. Дальнейшее исследование проблемы с открытием базы показало, > что виной всему новая реализация блокировок при работе с IStorage. Патч, > исправляющий эту регрессию, я отправил в wine-patches [1]. Этот патч пока в очереди. > В задаче https://bugs.etersoft.ru/show_bug.cgi?id=8849 было выяснено, что > использование ole32=n позволяло избавиться от проблемы с неверным кодом, > поэтому я скопировал ole32.dll.so из winehq в eter-2.1 и попробовал выполнить > 1С. Это не получилось, так как ole32 в winehq использует нереализованный > в eter-2.1 kernel32 API InitOnceExecuteOnce. После простого хака, который > избегает использования InitOnceExecuteOnce, ole32 из winehq заработал в > eter-2.1 и с ним код на этикетке тоже показывается правильно. > > Значит проблема действительно была в ole32, и ole32 из winehq содержит > исправление для этой проблемы. > > Пока я не нашел, какое именно изменение/патч в winehq исправил проблему > с barcode.ocx. Так разница в файлах dlls/ole32 между eter-2.1 и winehq огромна из-за времени релиза ветки eter-2.1, то простой поиск исправления подстановкой файла из winehq, последующей перекомпиляцией и поиска в результирующем diff практически невозможен. Попробовав этот путь и наткнувшись на первый серьезный барьер из-за изменившихся зависимостей между файлами было решено искать другой способ. Пришлось делать полноценный Reverse Regression Testing по инструкциям из wiki.winehq.org/RegressionTesting и wiki.winehq.org/ReverseRegressionTesting. В результате был найден патч, исправляющий проблему, но который совершенно не прикладывался к ветке eter-2.1. После недолгого поиска выяснилось, что этот патч - часть последовательности из 10 патчей и номер его 4. Вместо прикладывания всех 10 патчей я решил ограничиться только первыми 4, т.е. только патчами, необходимыми для корректного приложения нужного. Патчи для решения данной проблемы отправлены для включения в ветку eter-1.2. Константин, пожалуйста протестируйте и подтвердите решение проблемы.
(Ответ Dmitry Timoshkov на комментарий4) > > Во-вторых, при попытке выполнить 1С из префикса .wine-10620 под winehq, > > 1С не может открыть базу с сообщением "Общая файловая ошибка при доступе > > к C:\DB\1Cv7.MD". Это регрессия, так как никаких подобных проблем раньше > > я не видел. Дальнейшее исследование проблемы с открытием базы показало, > > что виной всему новая реализация блокировок при работе с IStorage. Патч, > > исправляющий эту регрессию, я отправил в wine-patches [1]. > > Этот патч пока в очереди. Патч принят.
Поскольку у нас имееются некотрые проблемы при сборке пакетов в Sisyphus , от куда пакеты попадают в контейнеры swine. Проверял в vbox altlinux p7. C Пакетом wine-etersoft-2.1.3-alt22.M70P.23 Проблема решена.
