Автоматизация вендовых GUI-приложений в Wine

Я не уверен, насколько это оффтопик. Перенесите в Desktop, если так будет правильнее.

https://www.autohotkey.com/

Не смотря на красивый сайт, это опсосный GPL, еслишто.

Ты как всегда слишком узко смотришь. Зачем запускать виндовое приложение? Оно ходит куда-то сохраняет данные? Возможно имеет смысл просто открывать базу данных или кидать нужные запросы куда-нибудь?

AutoIt, он живой еще. Я на нем десктоп приложения тестировал. А тесты запускал через WinEXE, который использует IPC и принимает вызовы с удаленной линукс машины. Правда этот хак прикрыли после WinXP и заменами я не интересовался.

Делал подобное на autohotkey, правда в винде.

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

Зачем запускать виндовое приложение?

Потому что мне нужно автоматизировать работу с файлами в проприетарном формате этой программы.

Чтобы не быть голословным: речь о Macrium Reflect (виндовая бэкапилка) и конкретно об утилите consolidate.exe из комплекта поставки этой программы, которая занимается тем, что «склеивает» инкрементальные бэкапы.

Ты как всегда слишком узко смотришь.

Ну да, конечно, узко смотрю. Жду встречных предложений.

Нет, никакой поддержки командной строки там нет, иначе бы вопроса не стояло. Добавил в ОП.

https://www.autoitscript.com/site/autoit/ гайд, оно со времен winxp существует, может и под wine пойдет

xdotool

ждать появления заданного текста в TextBox

Как в xdotool ^ сделать?

TestComplete

но это проприетарщина

sleep ?

sleep что? слип какое-то непредсказумое время и в случайный момент кликать дальше, авось повезет? :)

Будь мужиком — пропатчи саму программу.

Если TextBox проверять, можно xclip как-то прикрутить.

LamerOk Lordwind Harald (и остальные) спасибо за ваши предложения, потыкаю.

Надеюсь, хоть что-то из этого заработает под вайном.

Как идеальный, но сложный вариант - реализовать минимальную симуляцию user32/gdi32 которая будет иммитировать нажатие нужных кнопок

Да, я думал об этом. Но тогда уж проще отреверсить и запатчить саму прогу (она небольшая). Как «совсем запасной» вариант сойдёт.

Касательно оожидания появления текста - есть виндовая консольная утилита cmdow, возможно через неё удастся найти поле с текстом
либо же патчить библиотеки wine чтобы выврдил оный текст в лог.
так же могут быть полезны декомпиляторы вроде ghidra/ida, чтобы понять что именно там искать

Можно запатчить прогу чтобы искала другие функции в библиотеках простым sed'ом
так перехватить выставление/вывод текста

Что там за textbox? Можно ли выделить текст и скопировать? Если да, то вариант с xdotool+xclip вполне рабочий.

может не с того конца решаешь? Не, если надо конкретно эту вундервафлю то флаг в руки, а так бэкапилок на винду пруд пруди, да хоть виндовый robocopy

Надо конкретно эту вундервафлю, вменяемых аналогов с нужными фичами у неё не очень-то и есть. Уже искал.

Сначала нужно определиться, оно x32 или x64.
Если x64, то хз.
Если x32, то всё просто:
https://pbpython.com/windows-com.html
- естественно, с виндовым питоном. И я не уверен, но с 2.7 вроде это лучше работает - сам делал только под оффтопиком с 2.7
Как я понимаю, нужно всё запускать из одного wine - SO пишут, работает:
https://stackoverflow.com/questions/6847684/automating-excel-with-win32com-on...

Не смотря на красивый сайт

GPL

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

есть вещи в линуксе, такие как gimp и wine, с которыми связываться себе дороже.:( я бы использовал полноценную виртуалку, а внутри бы отлично работала утилита по автоматизации. там они совершенно полноценные. и даже одна или две. какую конкретно я использовал, уже не помню.

Была такая штука Sikuli. Кажись загнулось.

Хотя если вспомнить про местного Рината с «софт не разлагается, а рукописи не горят», то может что-то и можно получить. Но такое себе…

Я не могу использовать виртуалку, потому что оверхед по I/O любым доступным способом будет большой. Эта прога много и долго пишет на диск.

я бы изучил вопрос с оптимизацией IO. ты и без меня знаешь, что RH на KVM добилась очень неплохих результатов при использовании спец.драйверов. у wine тоже накладные по IO. короче, [я] провел бы тест сначала.

плюс, если прога будет работать долго, я бы вообще от вайн отказался. обвалится по неизвестным причинам через 8 часов работы. нафиг надо.

Разве что если ты говоришь про virtiofs, но я слышал, что оно ещё очень сырое.

Нормальный (сравнительно) высокопроизводительный I/O в виртуалке сейчас только через virtio-scsi, но мне нужно работать с файловой системой, а не с блочными устройствами.

Или есть другие варианты, которых я не вижу?

xclip может читать поля в приложении в wine?

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

this, никаких новых сведений о драйверах у меня нет. конкретную задачу, нагрузку и железо я не представляю, так что тем более вариантов не вижу. можно выделить физический девайс под создание блочного девайса, а уже изнутри vm (т.е. экспортировать средствами guest и import on host) его отдать как ФС основной системе.

От поля зависит. Если его можно выделить мышью и скопировать, то почему нет?
Проверить сейчас не могу.

О. А про это я даже и не подумал.

тебя в гугле забанили

Да. Хотел поинтересоваться опытом реальных людей, особенно применительно к Wine.

можно выделить физический девайс под создание блочного девайса, а уже изнутри vm (т.е. экспортировать средствами guest и import on host) его отдать как ФС основной системе.

Ну блин. Мне же не в вакууме нужно прогу запускать, а работать с какими-то реальными данными. Реальные данные уже есть, они лежат на массиве btrfs-ном, туда по SMB пишут другие машины.

объем какой?

~5TB всего, при одном запуске сабжевой вундервафли обрабатывается где-то ~100GB random I/O

про wine не могу сказать, такого опыта не было

это в любом случае секс в гамаке. без смены самой ситуации ты нормально не вставишь.

туда по SMB пишут другие машины.

по логике вещей очевидно, что писать нужно сразу по SMB на виндовый сервер, где прога будет нативно работать с максимальной отдачей. btrfs и линукс тут нафиг, имхо, не нужны. а если нужны, то проще им как-то потом обеспечить доступ.

Я не энтерпрайз. У меня нет отдельного виндового сервера, в который я могу воткнуть отдельную полку дисков. У меня есть линуксовый NAS, на который бэкапятся виндовые машины. И на этом сервере надо по расписанию гонять определённую прогу (сабж), чтобы она эти бэкапы сжимала.

Сейчас виндовые машины сами лезут на сервер по SMB сжимать свои бэкапы, но это работает как говно.

а там какое-то особое сжатие?

p.s.

это работает как говно.

еще бы

Там вообще не сжатие. Я упрощаю несущественные детали. Там слияние инкрементальных образов.

Есть фреймворк а-ля селениум для тестирования гуи приложений Squish. Он умеет управлять виндовыми приложениями. Но он платный.

Программа может регистрировать COM объекты при установке. Тогда ставишь PowerShell и вперед!

мож, тебе как раз подумать, как вынести часть этого инкрементального функционала на линукс? это было бы тоже вполне логично. забирать файлы с винды в каком-то более простом виде, а логику навернуть самому. я чессказать не уверен, что тулзы для автоматизации будут корректно работать под wine, т.к. им там всякие данные об окнах нужны и т.д.

не, эт не то, это для вебдевелоперов. там autoit выше правильно советовали.