Автоматизация MS Windows, или AutoIt как мечта эникейщика. Часть 1.

АЛЕКСЕЙ БАРАБАНОВ

Автоматизация MS Windows, или AutoIt как мечта эникейщика

Часть 1

Если не работает ксерокс, вызывайте сисадмина.

Это ведь электронный прибор, разве нет?

Со дня появления компьютеров человечество разделилось на пользователей и «компьютерщиков». Они стояли по разные стороны от электронной вычислительной машины, иногда путаясь в точной принадлежности к своему классу или группе. Но постепенно всё и все стали на свои места. Число пользователей увеличивалось, а число «компьютерщиков» лишь уточнялось. Пока компьютеров было мало, и они представляли собой большие инженерные сооружения, обслуживаемые целыми бригадами «компьютерщиков», в составе которых находилось изрядно механиков и электриков, то и число пользователей, приходящееся на один компьютер, старались сделать максимально большим. Общее соотношение пользователей к «компьютерщикам» мало кого интересовало, поскольку главным ресурсом были именно компьютеры. Но с появлением персональных компьютеров, когда пропорция их числа к количеству пользователей бесповоротно перешла в разряд целых чисел, иметь бригаду для обслуживания каждого компьютера стало очень накладно. Именно с этого момента, с момента создания персональных компьютеров, разработчики как оборудования, так и программного обеспечения стали задумываться о снижении затрат на обслуживание своих изделий. Именно тогда абстрактные «компьютерщики» стали превращаться в системных администраторов, специализирующихся на обслуживании компьютерных систем. Одновременно с этим стали появляться и специальные программные продукты, предназначенные именно для системных администраторов или ориентированные в первую очередь на решение задач обслуживания.

Например, пользователи IBM 360, работающие в среде DOS, должны были так или иначе знать и уметь применять язык управления заданиями JCL, а если они работали в консольном режиме, то и язык управления работой всей системы. А вот те же пользователи IBM PS/2, работающие в среде OS/2, уже могли ничего не знать про настройки системы и довольствоваться лишь тем, что им предоставляет графический интерфейс.

Таким образом, вопрос отличия пользователей от системных администраторов свелся к отличию применяемых ими интерфейсов. Пользователь компьютера, встроенного в мобильный телефон, управляет устройством с помощью графического интерфейса и кнопок на корпусе аппарата, а техник, обслуживающий этот же телефон, пользуется консольными командами или графическим интерфейсом программы специального компьютера, к которому упомянутый телефон подключается через технологический разъем JTAG. Другими словами, интерфейс должен соответствовать решаемым задачам. Но для персональных компьютеров интерфейс имел поистине судьбоносное значение. Ведь самое главное отличие их от компьютеров, использующихся коллективно, заключался в монопольном предоставлении всех ресурсов одному пользователю. Это не могло не сказаться на способе решения проблемы интерфейса. Многие из первых персональных компьютеров продавались как приставка к телевизору, например Sinclair. То есть без телевизора это был еще не компьютер, а вот после его подключения компьютером уже можно было пользоваться. В этом проявлялась важность интерфейса.

Коммерческий успех ПК в очень большой степени зависел от того, как решался вопрос интерфейса, и насколько легко этим интерфейсом могли пользоваться неподготовленные потребители. Если бы первые ПК имели такой же текстовый интерфейс, как мейн-фреймы (для сведения, JCL многие за сверхзапутанность называли «птичьим языком»), то, скорее всего, лишь появившись, эти устройства канули бы в Лету. Но этого не произошло именно благодаря доступному и привлекательному графическому интерфейсу. Сначала главное было в самом экране, то есть в телевизионной трубке. Вероятно, людей привлекало то, что с помощью ее можно было просматривать не только новости и кинофильмы. Но затем в компании Xerox прошли удачные опыты по обучению разумных прямоходящих млекопитающих навыкам использования манипулятора «мышь» с одной кнопкой. Это было поистине революционным событием. И хотя «мышь» с того времени успела увеличить число кнопок, но предложенный способ взаимодействия с ПК путем нажатия на кнопки мыши, или «кликов», прочно вошел в обиход компьютерных пользователей. И точно так же однозначно заставил принять системных администраторов негативную позицию к этому процессу – «мышиному» кликанью.

Интерфейсы

Если сисадмин по телефону говорит вам,

какие кнопки надо нажимать, почитайте газету.

Hа самом деле я не хочу, чтобы вы что-то делали.

Мне просто нравится звук моего голоса.

Чем же «мышки» так не устроили сисадминов? Дело было не столько в манипуляторах «мышь», а в особенностях применяемого тогда графического интерфейса. Поскольку главным показателем уровня системного администрирования стало число обслуживаемых одним сотрудником компьютеров, то средства обеспечения автоматизации системных операций, установки ОС, ее настройки и управления, приобретали решающее значение. И вплотную решение этого вопроса соприкасалось с обеспечением всех этих же работ по каналам удаленного доступа. Естественно, для платформ с текстовым интерфейсом и первое, и второе решалось легко. Существовали простые скриптовые языки, которые позволяли очень быстро запрограммировать любую операцию управления ОС, и средства обеспечения удаленного доступа в текстовом режиме обеспечивались на достаточно слабом технологическом уровне коммуникаций. Например, так решались вопросы администрирования в ОС семейства UNIX. Но в операционных системах, ориентированных на работу в графической среде, все было не так просто. Во-первых, графический интерфейс с семантической точки зрения полностью определяется прикладной программой. То есть, реакция на активацию кнопки «ОК» в графическом меню зависит от фазы диалога и от назначения программы, его обслуживающей. Во-вторых, обеспечение удаленной работы в графической среде требовало гораздо большей пропускной полосы от каналов связи, чем работа в текстовом интерфейсе. Все это привело к тому, что автоматизация графических настроек практически не развивалась. Ну разве что самим разработчиком ОС, в данном случае Microsoft, путем увеличения сложности вложенных меню. И для системных администраторов работа в среде Microsoft Windows превращалась в бесконечную тренировку кистевых мышц, поскольку ничем практически их возможности не отличались от тех, что были предоставлены рядовым пользователям, менялись лишь заголовки и содержание выпадающих окон. Это сыграло свою положительную роль – манипулятор типа «мышь» за последнее время из примитивной «каталки» с крыльчатками и обрезиненным шариком превратился в высокотехнологическое устройство на основе оптического (лазерного) сканера и оснащенное радиоканалом для связи с компьютером. Но ясно, что даже если манипулятор «мышь» будет преобразован в имплантант с компьютерным интерфейсом, это все равно не позволит одному системному администратору обслуживать одновременно большее число компьютеров, как этого требует современная IT-индустрия, подчиняющаяся жестким рамкам TCO: http://www.telecominfo.ru/?t=2012, таблица 2. И рост показателя числа одновременно обслуживаемых пользовательских компьютеров (Full Time Equivalent – FTE) сдерживался неразвитостью средств автоматизации системных работ в ОС, построенных на основе графических интерфейсов.

Нельзя сказать, что все было ограничено лишь технологическими проблемами. Дело в том, что на платформе MS Windows, которая долгое время была безальтернативной для персональных компьютеров, применяются в основном проприетарные программные продукты. А решение проблемы их массовой установки идет в разрез с требованиями соблюсти обязательную процедуру регистрации (легализации, активации) каждой копии программы. Обычно процедура регистрации копии обставлена специальными защитными протокольными и не всегда техническими действиями, например, требуется согласиться с лицензией, ввести серийный номер с бокса или CD-диска, вставить ключевой диск в лоток привода, провести активацию через Интернет и многое иное, что взбредет в голову озабоченного получением прибыли разработчика. Даже сама ОС MS Windows в ее коробочном воплощении не предназначена для создания автоматизированных систем установки на ее основе. В чем смысл автоматического размножения одной копии, если по маркетинговому замыслу все продаваемые копии этой системы требуют оригинальной для каждой из них процедуры регистрации. Были, конечно, оставлены лазейки и прочие оговорки. Ну не могли же «отцы-основатели» этой софтверной «пирамиды» просто низвести весь институт системных администраторов до положения «эникейщиков». Поэтому существовали так называемые «корпоративные» версии, которые допускали серийную установку, как копирование одной и той же установочной процедуры на множество компьютеров. Правда, в отместку там вводились иные ограничения, например, на установку обновлений. Но даже такую суррогатную свободу автоматизации рутинных операций установки собственной продукции могла позволить далеко не каждая фирма-производитель программного обеспечения. Поэтому еще одна проблема автоматизации работ в среде GUI заключена в том, что многие программные продукты не предназначены для автоматической установки и настройки в силу дизайна, так как требовали в процессе установки именно «человеческих» действий.

Анимация вместо автоматизации

Если вы увидели сообщение «Are you sure?»,

нажмите «Yes» как можно быстрее!

Черт побери, если бы вы не были уверены,

вы бы не делали этого, не так ли?

И вот все эти проблемы получили свое решение. Появилось средство автоматизации операций в графической оконной среде, которое имитировало работу человека-оператора, названное AutoIt и предназначенное изначально для автоматизации операций установки программ. Сейчас можно воспользоваться версией 2.64, загрузив ее с http://www.hiddensoft.com/AutoIt, и версией 3.1.0, доступной по адресу: http://www.autoitscript.com/autoit3/index.php .Эти программы распространяются под открытыми лицензиями. Версия 2.64, написанная Джонатаном Беннетом (Jonathan Bennet), в некоммерческих проектах может быть использована без ограничений, а в коммерческих необходимо вместе с продуктом указывать ссылку на сайт разработчика. Версия 3.1.0, авторство которой принадлежит упомянутому Джонатану Беннету вместе с AutoIt Team, уже идет под GNU GPL, что свидетельствует о зрелости подхода и о невозможности в дальнейшем изъять эту программу из свободного оборота, переведя под какую-нибудь закрытую лицензию. На обе версии есть, кроме прилагаемого файла Help на английском языке, еще и русская версия документации в формате chm, подготовленная Валерием Ивановым.

Если рассмотреть эту программу отдельно от контекста предполагаемого применения, то это всего лишь средство перехвата анализа состояния оконного интерфейса и эмуляции нужных сообщений якобы от лица оператора. Практически смотрится как демонстрационная мультипликация. Но с точки зрения языковой машины, например, юниксового bash, интерпретирующей некоторый скрипт, все действия выглядят точно так же мультипликативно. Только это никому не заметно, если происходит не на экране, а в текстовой консоли. И тем более что в текстовых интерпретаторах есть возможность прятать и перенаправлять обрабатываемые потоки символов. Но можно назвать и полную текстовую аналогию из мира *nix обсуждаемой здесь программе. Это известное средство expect. Оно позволяет заменить для некоторой прикладной программы общение с текстовыми терминалами и тем самым автоматизировать работу оператора путем эмуляции процесса его работы. Применяется это обычно для автоматизации работ с интерактивными средами, например с ftp. Примечательно, что и expect, и AutoIt имеют в своем составе средство, облегчающее создание сценариев путем записи перехваченных реальных интерфейсных данных. Конечно, в AutoIt это пока очень незрелое ручное средство, которое в модальном окне показывает характеристики выбранного элемента графического интерфейса.

С точки зрения технологии AutoIt всего лишь использует возможности, заложенные в API графического интерфейса. Того же самого результата можно добиться с помощью Visual Basic или даже C++. Но в том-то и разница, что использование AutoIt позволяет избежать программирования на «тяжелых» языках. Ибо сисадмин не программист, и ему нужно не писать программы, а лишь решать стандартные проблемы автоматизации, возникающие в ходе его работы.

Итак, как же это работает. Такое средство должно иметь возможность ввести в управляемую им среду все необходимые данные, проанализировать ответ и в меру стандартных языковых возможностей организовать интерактивное выполнение описанного процесса. Все! Если интерфейс текстовый, что верно в отношении expect, то такая система должна вводить строковые последовательности, принимать и анализировать ответные строки и в зависимости от результата и в силу возможностей своего синтаксиса организовывать некоторый алгоритмический процесс. Если интерфейс графический, то к перечисленному добавляется GUI-специфика. К вводимым данным добавляются управление поведением окон (обнаружение, активация, минимизация, закрытие и проч.), закладок и других элементов оконного интерфейса, передвижение мыши и нажатия кнопок на ней. Точно так же, к получаемым данным добавляются события по созданию, активации и прочим операциям с окнами. Ну а оставшееся всецело определяется дизайном встроенного языка. В версии 2.* используется язык с синтаксисом подобным ассемблерному с разделителями в виде запятых и примитивными управляющими операторами, основанными на условных переходах. В 3-й версии это уже практически полноценный язык программирования с привычными управляющими структурами, включая функции, и как следствие goto из употребления в этом релизе изъят. И та и другая версии позволяют, как интерпретировать операторы, записанные в отдельный скриптовой файл, так и создавать исполняемую версию на основе runtime-компонентов. Но версия 3.* «тяжелее» в полтора раза. Поэтому исполняемые файлы на основе 2-й версии имеют размер от 40 Кб, а версии 3.* – от 116 Кб. Вероятно, из-за большего числа встроенных функций. Кроме уже перечисленного версия 3.* имеет встроенные тайм-ауты в операторах ожидания, что позволяет решать проблемы «зависаний» неустойчивых приложений, но в практике автоматизации стандартных действий можно с успехом обойтись и без этого. Другими словами, решения, построенные на версии 2.* не утратили актуальности для 90% задач, решаемых с помощью AutoIt, но релиз 3.* позволяет создавать полноценные приложения, если такое нужно. В интернет-ресурсах, посвященных AutoIt есть даже примеры игровых программ.

Установка программного обеспечения

Если вы занимаетесь на вечерних компьютерных курсах,

обязательно проверьте свои знания на своем

и всех соседских компьютерах.

Мы любим работать до 2:30 ночи, исправляя это.

Думаю, теории достаточно. Далее рассмотрим разнообразные примеры реального использования предложенной технологии. Здесь не ставится целью писать большие и изощренные программы. Главное, чтобы это были работоспособные и применимые в практике скрипты и программы. Часть из них будет разобрана в тексте, другая просто указана в ссылках и предназначена для самостоятельного изучения. Многие из них будут использованы в заключительном комплексном примере создания диска для автоматической установки MS Windows. Начиная с самой простой предложенные программы будут усложняться постепенно, что не мешает после прочтения всей статьи вернуться к началу и переработать рассмотренные программы с использованием всего арсенала AutoIt.

В качестве первого практического примера рассмотрим автоматизацию установки самого AutoIt. Поскольку мы располагаем сразу двумя работоспособными релизами, 2-м и 3-м, то решим задачу автоматической установки AutoIt версии 3 с помощью скрипта для 2-й. Для этого установим AutoIt версии 2 в систему и создадим с помощью текстового редактора Notepad файл setup_autoit3.aut. Расширение «aut» является стандартным для скриптов AutoIt2. Запишем следующую последовательность операторов:

// установим режим детектирования скрытого текста в окнах

SetTitleMatchMode, 2

DetectHiddenText, on

// уберем все окна с экрана

WinMinimizeAll

// подождем секунду

Sleep, 1000

// запустим установку из той же директории

Run, autoit-v3-setup.exe

// выведем окошко с сообщением

MsgBox, 0, AutoIt, Setup done

// завершение

Exit

Это очень короткая программка станет основой разрабатываемого скрипта. Все операторы снабжены комментариями и совершенно очевидны по содержанию. Но прежде чем запускать ее на выполнение загрузим «AutoIt Reveal Mode» – специальное средство для просмотра информации, скрытой в структурах связанных, с окнами в MS Windows. Затем запустим скрипт и дождемся завершения. После появления сообщения о завершении закроем его нажатием на кнопку «ОК» и снова развернем все окна. Должно получиться так, как показано на рисунке.

Рисунок 1

Здесь обратите внимание, что в окне AutiIt v2.64 приводится весь перечень текстовых строк с активного окна, начиная с его заголовка. Именно на эти строки и будет далее «ловиться» установщик в нашем скрипте, и поскольку кнопка Next уже выделена как активная, то сразу, как только скрипт дождется активности окна с названием «AutoIt v3.1.0. Setup», можно отправлять этому окну Enter, что приведет к нажатию активной кнопки, то есть к переходу на следующий экран установщика. Вот текст следующей, более сложной фазы разработки:

// установим режим детектирования скрытого текста в окнах

SetTitleMatchMode, 2

DetectHiddenText, on

// уберем все окна с экрана

WinMinimizeAll

// подождем секунду

Sleep, 1000

// запустим установку из той же директории

Run, autoit-v3-setup.exe

// дождемся нужного окна и нажмем Next

WinWaitActive, AutoIt v3.1.0 Setup

Send, {ENTER}

// выведем окошко с сообщением

MsgBox, 0, AutoIt, Setup done

// завершение

Exit

Для проверки отменим установку и запустим скрипт по новой.

После остановки снова завершим наш скрипт, развернем все окна и проанализируем результат, изображенный на рисунке.

Рисунок 2

Здесь аналогично первому запуску проследим за участками, отмеченными красным. Задача заключается в том, что надо «отловить» новое окно и активировать нужное действие. Но окно имеет такое же название, что и предыдущее! Тогда смотрим в окошке перехватчика, какие еще строковые значения нам доступны. Находим строку «License Agreement». Эта строка как нельзя лучше отражает специфическое значение полученного окна. И поскольку здесь снова нужное действие сразу стоит по умолчанию, то после обнаружения этого окна нужно снова отправить в него Enter. Меняем текст следующим образом:

// установим режим детектирования скрытого текста в окнах

SetTitleMatchMode, 2

DetectHiddenText, on

// уберем все окна с экрана

WinMinimizeAll

// подождем секунду

Sleep, 1000

// запустим установку из той же директории

Run, autoit-v3-setup.exe

// дождемся нужного окна и нажмем Next

WinWaitActive, AutoIt v3.1.0 Setup

Send, {ENTER}

// аналогично дождемся license agreement

WinWaitActive, , License Agreement

Send, {ENTER}

// выведем окошко с сообщением

MsgBox, 0, AutoIt, Setup done

// завершение

Exit

Обратите внимание, как изменился синтаксис оператора WinWaitActive, поскольку теперь нужно определить окно не по названию, а по тексту внутри, то детектируемая строка записывается в третьем поле. Снова прекратим установку и проделаем те же операции, что и в предыдущем запуске. После остановки должен получиться результат, сходный с изображенным на рисунке.

Рисунок 3

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

// установим режим детектирования скрытого текста в окнах

SetTitleMatchMode, 2

DetectHiddenText, on

// уберем все окна с экрана

WinMinimizeAll

// подождем секунду

Sleep, 1000

// запустим установку из той же директории

Run, autoit-v3-setup.exe

// дождемся нужного окна и нажмем Next

WinWaitActive, AutoIt v3.1.0 Setup

Send, {ENTER}

// аналогично дождемся license agreement

WinWaitActive, , License Agreement

Send, {ENTER}

// окно с выбором места установки

WinWaitActive, , Choose Install Location

Send, {ENTER}

// завершение установки

WinWaitActive, , Click Finish to close

Send, {ENTER}

// выведем окошко с сообщением

MsgBox, 0, AutoIt, Setup done

// завершение

Exit

Эта программа устанавливает AutoIt v3 в автоматическом режиме. Её можно преобразовать в исполняемый, а не интерпретируемый код. Но предлагаю прогнать ее полностью и далее перейти к работе в AutoIt v3, который как раз и будет установлен к этому моменту. Прежде всего, воспользуемся утилитой перевода тестов из 2-й версии в 3-ю «v2 to v3 Converter». Такой подход позволяет сразу получить синтаксически верную программу. Вот результат:

//  V2.64 to V3.0.100 (Version 1.0.6)

//  Converted with AutoItV2toV3 [Version 1.0.6]

//  (C) Copyright 2004 J-Paul Mesnage.

// установим режим детектирования скрытого текста в окнах

AutoItSetOption ( "WinTitleMatchMode", 2 )

AutoItSetOption ( "WinDetectHiddenText", 1 )

// уберем все окна с экрана

WinMinimizeAll ( )

// подождем секунду

Sleep ( 1000 )

// запустим установку из той же директории

Run ( "autoit-v3-setup.exe" )

// дождемся нужного окна и нажмем Next

WinWaitActive ( "AutoIt v3.1.0 Setup" )

Send ( "{ENTER}" )

// аналогично дождемся license agreement

WinWaitActive ( "", "License Agreement" )

Send ( "{ENTER}" )

// окно с выбором места установки

WinWaitActive ( "", "Choose Install Location" )

Send ( "{ENTER}" )

// завершение установки

WinWaitActive ( "", "Click Finish to close" )

Send ( "{ENTER}" )

// выведем окошко с сообщением

$__msgbox = MsgBox ( 0, "AutoIt", "Setup done" )

// завершение

Exit

Как видно по тексту, никаких существенных изменений новый синтаксис не несет. Скрипт после конвертации был помещен в файл setup_autoit3.au3, расширение у которого имеет стандартное для версии 3 значение. Но программа делает все то же самое. Если преобразовать ее в исполняемый код с помощью имеющегося в версии 3 компилятора, то после удаления AutiIt v3 из системы его можно снова установить с помощью новой программы. Это и будет проверкой работоспособности.

Совершенно таким же способом можно создать средства автоматической установки практически любого программного обеспечения вне зависимости от особенностей использованного разработчиками установщика. Конечно же, в реальной работе можно сразу начать создание скрипта в среде AutoIt версии 3, и тогда для определения строк, по которым происходит детектирование нужных окон, надо будет воспользоваться «перехватчиком» окон из версии 3, который называется «AutoIt v3 Active Window Info». Но в остальном последовательность действий будет точно такой же: запускаются приложения, определяются названия окон или тексты внутри них, записываются клавиатурные нажатия (например, клавиша ALT как активатор меню) и все это переводится в скрипты AutoIt. Полученные скрипты, преобразованные в исполняемые файлы, можно разместить в соответствующих дистрибутивных директориях под красноречивыми названиями auto_setup.exe. И в практической деятельности установку очередного 1С клиента можно свести к запуску только одной программы. Более того, можно даже поделиться почетной обязанностью установить 1С с тем бухгалтером, которому это нужно. Чего же проще – кликнуть один раз!

Но точно так же, как не вся работа системного администратора сводится лишь к установке прикладного программного обеспечения, так и возможности AutoIt не ограничиваются лишь обслуживанием программ типа setup.exe. Но об этом в следующей части.