Разработка службы Windows "Контроль приложений"

Разработка на языке C++ службы, осуществляющей контроль набора выполняющихся приложений. Проектирование, кодирование, отладка, тестирование и сопровождение службы Windows. Взаимодействие службы и приложения. Интерактивность разрабатываемой службы.
Краткое сожержание материала:

Размещено на

Размещено на

Содержание

Задание на выполнение

Введение

1. Анализ

2. Проектирование

3. Кодирование и отладка

3.1 Служба

3.2 Приложение

3.3 Взаимодействие службы и приложения

4. Тестирование

5. Сопровождение

Заключение

Список литературы

Задание на выполнение

Разработка службы Windows: «Контроль приложений», осуществляющей контроль набора выполняющихся приложений и, возможно, управление ими. Кроме разработки службы, необходимо разработать приложение, которое будет осуществлять управление этой службой.

Введение

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

Объект проектирования в данной работе - служба Windows: «Контроль приложений».

Для более полного понимания объекта рассмотрим определения службы.

Служба Windows (англ. Windows Service, сервисы) - приложения, автоматически запускаемые системой при запуске Windows и выполняющиеся вне зависимости от статуса пользователя [1].

Служба - это Windows-приложение, содержащая дополнительную инфраструктуру, которая позволяет ServiceControlManager (SCM) - компоненту, работающему на всех windows-машинах, - управлять этим приложением [2].

Данный программный продукт разрабатывался на языке C++ с использованием среды разработки Builder C++ XE2, позволяющей оптимизировать процесс его создания.

1. Анализ

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

Для реализации данного проекта был выбран язык С++, так как в наличии имеется среда разработки, и соответствующие знания данного языка.

Реализация службы возможна в двух вариантах:

1) с использованием WIN API;

2) с использованием встроенного класса vcl TService в Builder C++ XE2.

Использование 2-го варианта наиболее оптимально, так как работа с сервисом значительно упрощается.

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

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

Существуют два варианта реализации приложения:

1) графическое приложение с использованием визуальных компонент;

2) консольное приложение, работающее с командной строкой.

В среде разработке Builder C++ XE2 возможна реализация обоих вариантов, но исходя из соображений, что обычный пользователь редко занимается установкой служб и их запуском самостоятельно, то выберем консольный вариант реализации.

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

2. Проектирование

Основной целью данного этапа является получение проектных решений.

На первом этапе проектирования рассмотрим саму службу.

Определим функционал разрабатываемого сервиса:

1) создание лог файла, в который будут заноситься сведенья о запушенных процессах. При запуске и завершении процесса добавляется соответствующая запись;

2) при бездействии операционной системы запускать дефрагментацию основного раздела жесткого диска.

Существуют два варианта подхода в проектировании службы.

Вариант первый: стартует служба, начинает что-то делать, время от времени уведомляя систему о своём состоянии, потом служба останавливается.

Вариант второй: стартует служба, создаёт рабочие потоки. По уведомлению от системы потоки останавливаются и служба выключается.

Обычно в службах используется второй вариант, поэтому остановимся именно на этом варианте.

Для формирования лога необходимо создать структуру, в полях которой будут храниться данные о процессе (время создания/завершения, идентификатор (pid), имя процесса, указатель процесса), передаваемую в качестве параметра в функцию записи в лог файл.

Сам процесс формирования лог файла происходит в несколько этапов:

1) служба получает список запушенных процессов в данный момент;

2) сверяет со списком запущенных процессов, полученным ранее, если существуют процессы, отсутствующие в данном списке, затем происходит заполнение структуры данных о процессе и добавление в этот список и вызов функции формирования записи в лог файле о запуске процесса;

3) поиск в списке, полученном во втором пункте, процессов, которые отсутствуют в списке из первого пункта и формирование записи о завершении данного процесса, удалении его из списка.

Сам процесс записи в лог файл будет осуществляться с использованием потоков.

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

На втором этапе рассмотрим управляющие приложение.

Данное приложение необходимо для установки, удаления службы и ее настройки во время установки.

Для управления сервисами в Windows существует Service Сontrol Manager (SCM). Для корректного управления службой при ее модификации или смене состояний необходимо каждый раз сначала получать указатель SCM и лишь затем указатель самой службы. Закрытие указателей происходит в обратном порядке.

Меню данного приложения можно реализовать в виде бесконечного цикла while c использованием условной конструкции switch предусматривающая возможность выхода из данного цикла. В данном меню необходимо будет реализовать 5 пунктов:

1) установка сервиса;

2) удаление сервиса;

3) запуск и завершение работы сервиса;

4) помощь по использованию приложения;

5) выход.

В первом пункте необходимо предусмотреть возможность ввода ключей для выбора функционала и проверку на правильность их ввода.

3. Кодирование и отладка

Основной целью данного этапа является реализация программного продукта.

3.1 Служба

При создании проекта службы были автоматически созданы два метода:

TServiceController __fastcall TControlProcess::GetServiceController(void)

{

return (TServiceController) ServiceController;

}

void __stdcall ServiceController(unsigned CtrlCode)

{

ControlProcess->Controller(CtrlCode);

}

Эти два метода никогда изменяться не будут, так как за ними скрывается процесс взаимодействия с SCM менеджером.

Согласно проектному решению в основном потоке службы осуществляется только взаимодействие с SCM, а функционирование службы происходит в созданном ею потоке.

Для создания потока воспользуемся встроенным в Builder C++ XE2 классом TThread. Создадим потомка данного класса TSparkyThread.

class TSparkyThread: public TThread {

private:

protected:

void __fastcall Execute();/*главным методом объекта TThread. В теле метода должен содержаться код, который представляет собой программу потока*/

public:

fastcall TSparkyThread(bool CreateSuspended); /*конструктор созданого класса */ };

Win32 предоставляет несколько способов перечисления запущенных процессов:

с помощью библиотеки Process Status Helper (PSAPI);

с помощью ToolHelp32 API;

с помощью недокументированной функции ZwQuerySystemInformation;

с использованием интерфейсов Windows Management Instrumentation.

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

BOOL WINAPI EnumProcesses(

__out DWORD *pProcessIds,//указатель на массив идентификаторов

__in DWORD cb,//размер pProcessIds

__out DWORD *pBytesReturned//число возвращенных байтов

);