1. Завдання на курсову роботу

Служби - це життєво важлива і разом з тим таємнича частина Windows. Якщо раніше ви вже працювали з Windows або адміністрували системи працюючі під цією ОС, то мабуть ви вже зустрічалися зі службами. Що ж це таке? Сама проста відповідь: служба - це програма, яка працює не в контексті користувача. Іншими словами, служби продовжують працювати тоді, коли один користувач відключається від системи і до неї підключається інший користувач. Служби - це єдина категорія програм, які можуть робити в такому режимі.

В Windows служби використовуються для розв'язку багатьох важних задач, наприклад, існує служба, яка дозволяє вам підключатися до комп'ютера, очевидно, що така програма повинна продовжувати працювати навіть в випадку коли до системи не підключено ні одного користувача. Інші служби забезпечують сумісний доступ до диску і принтеру, а також являються допоміжними по відношенню до драйверів дискових пристроїв.

З точки зору програміста, служби - це звичайні програми, які мають засіб зв'язку з диспетчером служб SCM (Service Control Manager). Диспетчер SCM - це внутрішній механізм Windows, який здійснює керування службами. В Windows NT 4 користувач взаємодіє з SCM за допомогою аплету Services Control Panel. В Windows 2000 ту ж функцію виконує один із модулів консолі ММС. Список функцій які зв'язані зі службами, приведений в таблиці 1.

Як і будь-яка інша консольна програма, служба має функцію main. Одна програма може забезпечити роботу одної служби, а може включати в себе зразу декілька служб. Функція main заповнює масив, який описує всі служби, які підтримує програма. Масив передається службою StartServiceCtrlDispatcher. Для кожної служби, яка входить в склад файла, який використовується, цей масив містить текстовий ідентифікатор і точку входу.

Точка входу служби нагадує собою функцію main. Це функція, яка приймає звичайні аргументи argc і argv.

Таблиця 1. Функції служб.

В процесі звернення SCM до функції, яка є точкою входу служби, важливу роль грає структура SERVICE_STATUS. Більшість служб зберігають статичну копію цієї структури і відновлюють її в випадку необхідності. Функція, яка є точкою входу, використовує виклик RegisterServiceCtrlHandler для того, щоб зареєструвати обробник, який призначений для взаємодії SCM зі службою. Крім цього підпрограма ініціалізації служби звертається до виклику SetServiceStatus для того, щоб проінформувати SCM про поточний стан служби (служба може знаходитися в одному із станів: ініціалізація, функціонування або зупинка). Якщо ініціалізація потребує більше ніж декілька секунд, то потрібно виконати її в окремому програмному потоці.

Створення окремого програмного потоку потрібне також в випадку, якщо ви хочете створити службу, яка буде працювати виключно в фоновому режимі. Наприклад, якщо ви хочете розробити службу, яка кожну годину видає звуковий сигнал, який імітує роботу години каз боєм, то вам потрібно створити програмний потік, який буде слідкувати за часом і видавати звуковий потік.

Диспетчер SCM звертається до обробника також в випадку, якщо потрібно визначити поточний стан служби. Крім цього служба визначає інші спеціальні види запитів, які можна адресувати службі за допомогою виклику ControlService (цей виклик є частиною диспетчера SCM). Звичайно ж, для того щоб направити службі запит, необхідно мати необхідні полномочиями.

Встановлення служб

Щоб встановити службу, необхідно добавити в реєстр декілька записів. Частіше за все ця процедура виконується за допомогою SCM. Для цього необхідно відкрити SCM (за допомогою виклику OpenSCManager), а потім звернутися до виклику CreateService. В якості аргументів цей виклик приймає ім'я файлу, в якому міститься служба, а також іншу необхідну інформацію. При цьому в реєстр вносяться всі необхідні записи.

Виклик CreateService використовує 13 аргументів, що може визвати легкий переляк в тих програмістів, які не мали з ним діла (список цих аргументів приведений в табл.2). Насправді звернутися до цієї функції зовсім не важко. Діло в тому, що при зверненні до CreateService більшості аргументів можна присвоїти значення за замовчуванням. Параметр dwServiceType може мати одне із значень: SERVICE_WIN32_OWN_PROCESS (у випадку, якщо в файлі, який виповнює, міститься тільки одна служба) або SERVICE_WIN32_SHARE_PROCESS (у випадку, якщо в події файлу, який виконує, входять декілька служб). Інші прапори дозволяють вказувати є служба драйвером ядра чи драйвером файлової системи.

Таблиця2. Аргументи виклику CreateService

Служби NT.

В принципі сервери можуть працювати безкінечно довго, обслуговувати при цьому велику кількість клієнтів, які підключаються, відправляють запити, отримують відповіді і відключаються. Таким чином, ці „сервери” можуть давати неперервні послуги, тобто бути службами, але для повної ефективності служби повинні бути керуючими.

Служби NT в Windows NT і 2000 дають можливість перетворити сервери в служби, які можна буде запускати по команді або при запуску системи, призупиняти, відновлювати і завершати. Служби NT дозволяють навіть наглядати за „станом здоров'я” служби. В кінці кінців, будь-які серверні системи потрібно перетворювати в служби NT, особливо якщо вони будуть інтенсивно використовуватися в організації або замовниками. А Windows 2000/NT є багато служб, наприклад керування telnet і обліковими записами безпеки, а також драйвери пристроїв. На панелі керування можна визвати програму адміністрування, яка відображає повний набір служб.

Програма JobShell дає елементарні засоби керування серверами, які дозволяють запускати сервер під керуванням завданням і відправляти сигнал завершення. Служби NT набагато складніше і надійніше. Для того, щоб продемонструвати це функція JobShell буде модифікована так, щоб вона могла керувати службами NT.

Також тут буде показано, як перетворити даний консольний додаток в службу NT і як встановити цю службу, керувати нею і контролювати її. Описується також реєстрація подій, завдяки якої служба може фіксувати свої дії в журналі.

Служби Windows NT. Огляд.

Служби NTпрацюють під керуванням диспетчера керування службами (Service Control Manager - SCM). Для перетворення консольного додатку, такого як serverNT чи serverSK, в службу NT, потрібно виконати три основні дії, в результаті яких програма переходить під керування SCM.

1. Створити нову точку входу main(), яка буде реєструвати службу в SCM , інформуючи про точки входу і імена логічних служб.

2. Перетворювати попередню функцію точки входу main() в ServiceMain(), яка буде реєструвати обробник керування служби і інформувати SCM про його стан. Другий код зберігається практично без змін.

3. створити обробник керування служби, який буде відповідати на команди SCM.

Описавши ці три етапи, ми будемо по мірі необхідності давати додаткову інформацію по створенню, запуску служб і керуванню ними. Далі ці дії описанні краще.

Функція main().

Задача нової функції main(), яку викликає SCM, полягає в реєструванні служби і в запуску диспетчера керування службою. Для цього потрібно визвати функцію StartServiceCtrlDispatcher з ім'ям (іменами) і точкою (точками) входу однієї або декількох логічних служб.

BOOL StartServiceCtrlDispatcher (

LPSERVICE_TABLE_ENTRY lpServiceStartTable)

Єдиний параметр lpServiceStartTable є адресою масиву SERVICE_TABLE_ENTRY, кожен елемент якого містить ім'я і точку входу логічної служби. Кінець масиву позначається парою елементів з значеннями NULL.

Виклик StartServiceCtrlDispatcher в головному потоці процесу служби приводить до приєднання потоку до SCM в формі потоку диспетчера керування службою SCM не повертає керування, поки всі служби не будуть закінчені. Але потрібно замітити, що в цей момент логічні служби фактично ще не запускаються.

В прикладі 1 показана проста головна програма служби, яка містить одну логічну службу.

Приклад 1. Програма main: головна точка входу служби.

#include “EvryThng.h”

void WINAPI ServiceMain (DWORD argc, LPTSTR argv []);

static LPTSTR ServiceName = _T (“SocketCommandLineService”);

/* головна процедура, яка запускає диспетчер керуваня службою. */

VOID _tmain (int argc, LPTSTR argv [])

{

SERVICE_TABLE_ENTRY DispatchTable [] =

{

{ ServiceName, SeviceMain },

{ NULL, NULL }

};

if (!StartServiceCtrlDispatcher (DispatchTable))

ReportErrjr (_T

(“Не вдалося запустити диспетчер керування службою.”),

1, TRUE);

/*Servoce<aom () не буде працювати, поки її не запустить SCM.*/

/*Повернення назад відбувається тільки після завершення всіх служб.*/

return;

Функції ServiceMain()

Ці функції визначені в таблиці служб, як показано в прикладі 1, і представляють логічні служби. Це, по суті, вдосконалені версії основної програми, яка перетворюється в службу, причому кожну логічну службу SCM викликає в окремому потоці. В свою чергу, логічна служба може запускати додаткові потоки, наприклад потоки-робочі сервера, які застосовувалися в програмах serverSK і serverNP. Часто в службі NT знаходиться тільки одна логічна служба. Можливо реалізувати в складі одної служби NT логічні служби як на базі сокетів, так і на базі іменованих каналів, якщо задати дві головні функції служби.

Також тут є додатковий код для реєстрації обробника керування служби - функції, яка SCM викликає для керування службами.

Реєстрація обробника керування служби

Обробник керування служби, який викликається диспетчером SCM, повинен бути здатним керувати відповідною логічною службою. Обробник керування консолі в програмі serverSK, який встановлює глобальний прапор закінчення, в обмеженій формі демонструє, що повинен представляти собою обробник. Але кожна логічна служба повина зареєструвати обробник з використанням функції Register-ServiceCtrlHandler.

SERVICE_STATUS_HANDLE

RegisterServiceCtrlHandler (

LPCTSCR lpServiceName,

LPHANDLER_FUNCTION lp&HandlerProc)

Параметри

lpServiceName - вказане користувачем ім'я служби, яке представлене в елементі таблиці, який відповідає цій логічній службі.

lpHandlerProc - адрес функції обробника, яка буде описана нижче.

Функція повертає дескриптор об'єкта SERVICE_STATUS_HANDLE, рівний нулю, якщо вийшла помилка; для аналізу помилок можна застосовувати звичайні методи.

Встановлення стану служби

Коли обробник зареєстрований, то наступна задача полягає в тому, щоб встановити стан служби; в даний момент це SERVICE_STAER_PENDING. Функція, яка для цього застосовується, SetServiceStatus також використовується в деяких інших місцях і повина викликати періодично, щоб інформувати SCM про стан служби (інтервал вказується в полі параметра-структури стану).

Структура service_status

Структура SERVICE_STATUS визначена слідуючим чином:

typedef struct _SERVICE_STATUS {

DWORD dwServiceType;

DWORD dwCurrentState;

WORD dwControlsAccepted;

DWORD dwWin32ExitCode;

DWORD dwServiceSpecificExitCode;

DWORD dwCheckPoint;

DWORD dwWaitHint;

} SERVICE_STATUS, *LPBERVICE_STATUS;

Параметри

dwWin32ExitCode - звичайний код закінчення потоку логічної служби, яка повинна присвоїти йому значення NO_ERROR в ході виконання і при нормальному завершені.

dwServiceSpecificExitCode можна ви користувати для вказання помилок вводу запуску або закінчення служби, але це значення буде проігнорованим, якщо dwWin32ExitCode не присвоєне значення ERROR_SERVICE_SPECIFIC_ERROR.

dwCheckPoint - контрольний показчик проходження службою всіх її значень разом з ініціалізацією і закінченням, які служба повинна періодично зчитувати. Це значення не використовується, якщо служба не має затримки при закінченні, зупинці і відновлені.

dwWaitHint - інтервал в мілісекундах між викликами Set ServiceSpecificExitCode і збільшеним значенням dwCheckPoint або зміненим значенням dwCurrentState. SCM може припустити, що виникла помилка, якщо інтервал протікає без такого виклику SetServiceStatus.

Тип служби

Елемент dwServiceType повинен мати одне із значень, які приведені в таблиці 3.

Для наших цілей тип служби майже завжди буде мати значення SERVICE_WIN32_OWN_PROCESS, хоча різні значення свідчать про те, що служби можуть грати різні ролі.

Таблиця 3. Типи служб.

Стан служби

Параметр dwCurrentState визначає поточний стан служби. Можливі значення цього параметра приведені в табл.4.

Таблиця 4. Значення стану служби.

Коди керування, що сприймаються

Параметр dwControlsAccepted визначає коди керування, які служба сприймає і обробляє в своєму обробнику керування. Можливі значення перераховані в таблиці 5; декілька значень можуть об'єднуватися порозрядним „або”. Приведена нижче версія serverSK для служби сприймає всі три значення. Додаткові значення описані в документації MSDN.

Таблиця 5. Коди керування, які сприймаються службою

Код служби

Коли обробник зареєстрований і встановлений стан служби SERVICE_START_PENDING, служба може ініціалізувати себе і встановити стан знову. В прикладі перетворення serverSK після того, як сокети ініціалізовані і сервер буде готовий до прийому клієнтів, слідує встановити стан SERVICE_RUNNING.

Обробник керування служби

Обробник керування служби, який вказаний в функції RegisterServiceCtrlHandler, має наступну форму:

VOID WINAPI ServerCtrlHandler (DWORD fdwControl)

Єдиний параметр цієї функції, fdwControl, містить сигнал керування, який передається диспетчером SCM для обробки. Таким чином, обробник керування є узагальненою формою обробника керування консолі.

Сигнали керування можуть мати слідуючи значення:

SERVICE_CONTROL_STOP

SERVICE_CONTROL_PAUSE

SERVICE_CONTROL_CONTINUE

SERVICE_CONTROL_INTERROGATE

SERVICE_CONTROL_SHUTDOWN

Також допускаються значення користувача в діапазоні 128-255, але тут вони не розглядаються.

Обробник викликається диспетчером SCM в тому ж потоці, що і головна програма, і звичайно будується на базі оператора switch.

Керування службами Windows NT

Наступна задача після написання коду - передача служби під керуванням SCM, щоб її можна було запускати, закінчувати і виконувати інші керуючі операції.

Для цього потрібно виконати декілька дій з відкриття SCM, створення служби під керуванням SCM і потім з її запуску. Ці дії не керують службою безпосередньо; вони представляють собою команди для SCM, який працює з вказаною службою.

Відкриття SCM

Для створення служби необхідний окремий процес, який грає роль „адміністратора”. Перша дія - відкриття SCM і отримання дескриптору, який потім дозволяє створити службу.

SC_HANDLE OpenSCManager (

LPCTSTR lpMachineName,

LPCTSTR lpDatabaseName,

DWORD dwDesiredAddress)

Параметри

lpMachineName рівний NULL, якщо SCM знаходиться в локальній системі, хоча можна звертатися до SCM і на інших машинах в мережі.

lpDatabaseName - також звичайно NULL.

dwDesiredAddress - звичайно SC_MANAGER_ALL_ACCESS, але можна задати більш обмежені права доступу, як описано в вбудованій документації.

Створення і видалення служби

3.1 Main