B арсенале администраторов появились файлы Windows Script на основе XML.

В статье 'Extensible Markup Language' (майский номер Windows 2000 Magazine/RE за этот год - прим. ред.) я рассказывал о файлах Windows Script (WS-файлах), которые Windows Script Host (WSH) 2.0 регистрирует с расширением .wsf. Там же была приведена схема XML для этих файлов, а также разобраны синтаксис, определение и использование каждого элемента. В данной статье рассматриваются новые возможности и преимущества WS-файлов, которые иллюстрируются конкретным рабочим примером.

Особенности WSH 2.0

Прежде чем перейти собственно к программному коду, хочу напомнить несколько свойств WS-файлов на основе XML в WSH 2.0.

Поддержка внешних файлов

Совместно используемый код можно разместить в одном или нескольких файлах, а потом обращаться к нему из других сценариев. Внешний код становится доступен после директивы подключения внешнего файла. Для этого в элементе <script> следует указать необязательный атрибут src='ИмяФайла'.

Поддержка внешних констант

Для поддержки внешних констант в WSH 2.0 используется элемент <reference>. Он позволяет задействовать мнемонические константы, которые определены во внешних по отношению к обработчику сценария объектах. Это избавляет от необходимости переопределять те константы, которые уже определены, например ActiveX Data Objects (ADO), File SystemObject или Windows Management Instrumentation (WMI).

Поддержка нескольких языков сценариев

WSH 2.0 поддерживает несколько языков внутри одного WS-файла. Между доступными языками можно переключаться с помощью обязательного атрибута language элемента <script>. В WS-файле одна часть любого задания может быть написана, скажем, на JScript, а другая - на VBScript. Кроме того, можно передавать за границы кода переменные, содержащие ссылки на объекты.

Элемент<object>

WSH 2.0 позволяет задействовать элемент <object> для создания объектов. Этот элемент выполняет те же функции, что и методы CreateObject, GetObject и new ActiveXObject в WScript, VBScript и JScript.

Задания

Задания предназначены для разделения WS-файла на несколько независимо выполняющихся частей. Атрибут id элемента <job> используется для присвоения каждому заданию уникального имени внутри одного файла. Для указания конкретного задания при выполнении в командной строке WSH следует установить новый параметр //job:ID задания. Таким образом, можно, например, поделить WS-файл на несколько отдельных задач, каждая из которых оптимизирована по быстродействию.

Дополнительные средства

Дополнительные средства для разработки делают работу с WS-файлами более удобной и позволяют задействовать такую возможность Microsoft Visual InterDev 6.0 Service Pack 3 (SP3) и Microsoft Office 2000 Script Editor, как расцвечивание ключевых слов. Об этом подробно рассказывается в статье 'Enable Windows Script Version Tools Support for Visual InterDev' по адресу: http://support.microsoft.com/support/kb/articles/q249/0/24.asp.

Пример WS-файла eventlog.wsf

Теперь рассмотрим сценарий, реализующий возможности файлов на основе языка XML. Eventlog.wsf является сценарием WSH версии 2.0, он использует WMI Scripting API для поиска информации в журналах безопасности Windows 2000. Для работы eventlog.wsf в Windows NT следует установить SP4 или более поздний пакет исправлений, а также ядро WMI версии 1.50 и выше (можно загрузить по адресу: http://msdn.microsoft.com/downloads/sdks/wmi/download.asp). Eventlog.wsf представляет собой консольную программу со своим языком запросов, использующую встроенную в WMI поддержку журнала. С ее помощью можно производить поиск интересующих событий во всех шести журналах Windows 2000. Более подробно о WMI рассказано в статье Марка Русиновича 'Внутри Windows Management Interface' [майский номер Windows 2000 Magazine/RE за этот год - прим. ред.].

Сценарий очень прост в применении, причем при вызове с вопросительным знаком в качестве аргумента он выдаст подробную справку о параметрах запуска (см. Экран 1). В сценарии используется несколько значений по умолчанию, поэтому eventlog.wsf может работать даже без аргументов.

Если запустить сценарий без аргументов, то eventlog.wsf выведет на экран все события из локального журнала безопасности приложений. С помощью параметров можно выбрать режим поиска и указать конкретный журнал на любом компьютере, источник события, его тип и код. Например, можно отыскать все ошибки DCOM с кодом 10006, зафиксированные в журнале безопасности системы на удаленном компьютере dell610 - командная строка с таким запросом видна на Экране 1 (внизу).

Здесь же приводятся дополнительные инструкции по использованию сценария. Так, указано, что для запуска eventlog.wsf следует задействовать консольную среду выполнения cscript.exe. Это обязательно, поскольку eventlog.wsf выдает результаты своей работы на STDOUT, а воспользоваться свойствами STDIO, которые включают и STDOUT, можно только с консоли. Имеющийся в WScript метод Echo плох тем, что при случайном запуске в оконной среде будет создано слишком много 'всплывающих' окон. Кстати, нужно иметь в виду, что все содержащие пробел переменные следует заключать в двойные кавычки. Например, для поиска всех ошибок в журнале службы Directory Service на локальном контроллере домена следует набрать:

C:\> eventlog.wsf l='directory service' t=error

В приведенной командной строке не указана программа cscript.exe - конкретную среду выполнения можно опустить, если ранее она была настроена с переключателем //h:host. Если cscript.exe не является средой по умолчанию, то eventlog.wsf завершится аварийно, поскольку данный сценарий требует запуска в режиме консоли. Кроме того, в нашем случае командная строка не содержит ключа //job:xxxx, поэтому WSH 2.0 запустит первое задание в пакете, т. е. задание Search из eventlog.wsf.

Сценарий и XML

Утилита для поиска в журналах Windows 2000 состоит из двух файлов. Это eventlog.wsf, и library.vbs, файл, который содержит процедуры и функции общего плана и вызывается сценарием из eventlog.wsf.

Основная логика программы заключена в файле eventlog.wsf, который на первый взгляд похож на причудливый HTML. XML придает обычному исходному коду ясность и определенность, что позволяет построить более мощную и расширяемую рабочую среду сценария.

Если вспомнить, что говорилось в статье 'Extensible Markup Language' об XML и схеме XML в Windows Script, то легко выделить несколько свойств eventlog.wsf. Например, помеченная буквой 'A' директива <?xml?> включает режим распознавания XML. Она переводит обработчик сценария в строгий режим интерпретации, при котором имена элементов и атрибутов пишутся строчными буквами, а значения атрибутов заключаются в двойные кавычки. Эта директива также предполагает, что исходный код размещается внутри секции оператора <![CDATA[ ... ]]>, иначе лексический анализатор XML (scrobj.dll) может ошибочно интерпретировать код или данные как XML. Использование самого первого тега <package> (помечен буквой 'A') и последнего </package> (помечен буквой 'D') означает, что eventlog.wsf содержит несколько заданий. Помеченная буквой 'C' заготовка показывает, как можно добавлять дополнительные задания.

Буквой 'B' в Листинге 1 отмечены элементы, играющие основную роль в задании search-сценария, поэтому на них я остановлюсь подробнее. Как и другие задания в WS-файле, задание search начинается с тега <job> и заканчивается тегом </job>. Элемент <job id='search'> имеет необязательный атрибут id, позволяющий идентифицировать каждое задание в пакете. Для eventlog.wsf этот атрибут необязателен, поскольку задание search является первым и единственным существенным заданием в пакете. Однако применение атрибута id всегда приветствуется.

За элементом <job> следуют три элемента <object>, позволяющие создавать ссылки на объект. На Рисунке 1 представлены эквивалентные вызовы функций CreateObject языка VBScript, которые помогают разобраться с элементом <object>.

Рисунок 1. Различия между VBScript и XML.

Элемент <object> содержит необязательный булевый атрибут reference, который имеет важную особенность - при установке его в true появляется возможность использовать мнемонические константы, определяющиеся внутри создаваемого объекта. При этом отпадает необходимость в элементе <reference>. В примере элемент <reference> закомментирован, поскольку использовался атрибут reference, который выполняет точно такую же функцию.

Последним в блоке является обязательный элемент <script>, отмеченный в Листинге 1 буквой 'B', это наиболее существенный элемент схемы WS XML. Его атрибут language определяет, какой язык использован внутри тела данного элемента. Поскольку в одном задании допускается наличие нескольких блоков кода, заключенных в элементы <script>, в рамках одного задания можно легко переключаться с одного языка на другой. Лексически анализатор XML использует обязательный атрибут language для того, чтобы определить соответствующий обработчик для конкретного блока сценария.

Кроме того, элемент <script> позволяет поддерживать внешние файлы. Атрибут src используется для указания имени внешнего файла. При этом соответствующий блок сценария и внешний файл должны быть написаны на одном языке. Если это не так, то следует добавить дополнительный элемент <script>, указывающий язык внешнего файла и имеющий атрибут src. На Рисунке 2 приведен пример структуры XML, которая обеспечивает блоку кода на VBScript обращение к определенным в библиотеке JScript процедурам.

Рисунок 2. Схема XML.

В данном примере у первого тега сценария нет парного конечного тега, поскольку тело элемента пусто. В случае пустого тела нужно использовать символ 'слеш' непосредственно перед закрывающей угловой скобкой элемента. Это правило распространяется также на элементы <object> и <reference>.

Eventlog.wsf активно использует внешнюю библиотеку library.vbs. Этот файл содержит несколько процедур и функций, которые я применял в нескольких своих WS-программах, например функция IsHost (strPreferredHost), процедура ParseArgs (objHash), функция CWmiDate(cim_DateTime), функция CWmiTime(cim_DateTime) и процедура UsageForSearchJob(). Все эти функции размещают в одном внешнем файле, чтобы не переписывать их из проекта в проект. Однако следует помнить, что если подключаемый внешний файл содержит тело, т. е. не включенный ни в одну процедуру или функцию код, то этот код выполнится непосредственно в том месте, где был определен атрибут src. Во внешнем файле library.vbs это свойство использовалось для инициализации ссылок STDIO. Ниже приводится описание применяемых в library.vbs процедур и функций.

Функция IsHost(strPreferredHost)

IsHost сравнивает значение strPreferredHost с той средой, в которой выполняется сценарий. Если они совпадают, то результатом выполнения функции будет значение TRUE, в противном случае - значение FALSE.

Процедура ParseArgs(objHash)

ParseArgs служит для обработки командной строки. Она просматривает набор аргументов WScript, отыскивая аргументы в виде 'параметр=значение'. Процедура добавляет найденные пары в виде 'параметр/значение' в объект dictionary, на который указывает objHash.

Функция CWmiDate(cim_DateTime)

CWmiDate преобразовывает тип даты CIM_DATETIME WMI в вариант представления подтипа Date языка VBScript. Из CIM_DATETIME функция выделяет только значение даты в формате мм/дд/гггг.

Функция CWmiTime(cim_DateTime)

CWmiTime преобразовывает тип даты CIM_DATETIME WMI в другой вариант представления подтипа Date языка VBScript. Функция возвращает значение времени в формате чч:мм:сс AM|PM.

Процедура UsageForSearchJob()

UsageForSearchJob выдает инструкции по использованию eventlog.wsf. По окончании вывода информации она завершает выполнение всего сценария.

Остальные действия сценария заключены в секцию <![CDATA[ ... ]]>. Содержимое CDATA представляет собой VBScript и напрямую к XML не относится, поэтому здесь комментировать его не стоит.

Применить или повременить?

Найдется ли в арсенале пользователя место для WS-файлов на основе XML? Думаю, многие ответят утвердительно - чего стоят одни только встроенные интеллектуальные средства поддержки WS-файлов! Хочется надеяться, что читатели освоят грамматику WS XML и смогут воспользоваться разнообразными возможностями, заложенными в XML разработчиками Microsoft.