Напомним основные ограничения при разработке приложений, которые должны функционировать под управлением Server Core: поддерживается интерфейс только на уровне командной строки (отсутствует Windows Shell); не поддерживаются приложения на управляемом коде — они должны использовать только Windows API; поддержка MSI осуществляется лишь в режиме unattend mode. В целом Server Core предполагает выполнение приложений, обеспечивающих функционирование сетевых и файловых сервисов, средств управления сервером и соответствующих утилит. При его установке разработчикам становятся доступны только те программные интерфейсы, которые реализованы на уровне входящих в состав операционной системы программных компонентов. Данные компоненты и их назначение приведены в таблице.

Программные компоненты Server Core, доступные разработчикам

Дополнительную информацию по функциям, поддерживаемым в Server Core, можно найти на сайте MSDN Library по адресу: http://msdn2.microsoft.com/en-us/library/ms723894.aspx (Server Core Functions by DLL).

Для того чтобы определить, запущено приложение под Server Core или под какой-то другой конфигурацией, следует использовать функцию GetProductInfo из Kernel32.dll, которая доступна только в Windows Vista и Windows Server Longhorn. Если приложение запущено под Server Core, то переменная pdwReturnedProductType, в зависимости от варианта поставки Windows Server Longhorn, будет иметь одно из следующих значений:

• PRODUCT_STANDARD_SERVER_CORE (0x0000000D);
• PRODUCT_ENTERPRISE_SERVER_CORE (0x0000000E);
• PRODUCT_DATACENTER_SERVER_CORE (0x0000000C).

Второй вариант — применить WMI-класс Win32_OperatingSystem и его свойство OperatingSystemSKU, которое в нашем случае должно иметь одно из следующих значений:

• 12 для Datacenter Server Core Edition;
• 13 для Standard Server Core Edition;
• 14 для Enterprise Server Core Edition.

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

И наконец, еще один способ проверить, что работа осуществляется под управлением Server Core, — это проверить наличие в локальной системе такого компонента, как Explorer.exe: если он отсутствует — работа выполняется под управлением Server Core. Для этого можно использовать следующий скрипт:

Dim bServerCore, bExplorer

Const strExplorer = “\explorer.exe”

strRoot = WshEnv(“SYSTEMROOT”)

strExpPath = strRoot + strExplorer

Set objFSO = CreateObject(“Scripting.FileSystemObject”)

If objFSO.FileExists(strExpPath) Then

‘Explorer.exe найден — работаем не под Server Core

     WScript.Quit (0)

     bServerCore = False

     bExplorer = True

Else

     bServerCore = True

     bExplorer = False

End If

Рассмотрим некоторые вопросы, связанные с миграцией существующих приложений под Server Core, а также с созданием приложений, работающих под управлением Server Core.

Для миграции существующих утилит под Server Core необходимо заменить весь управляемый код на так называемый native code, удалить все вызовы функций, которые не поддерживаются в Server Core (см. приведенную выше ссылку на MSDN Library), все зависимости от графического интерфейса (утилиты должны работать только в режиме командной строки) и все интерактивные компоненты. Для удаленного управления системой следует использовать протоколы, поддерживаемые Server Core, например RPC.

При разработке новых утилит для Server Core следует помнить о том, что это не платформа для создания приложений, а конфигурация сервера, поддерживающая выполнение управляющих утилит, агентов, антивирусов и т.п. Такие утилиты могут выполняться локально (в командной строке), под управлением служб Terminal Services, а для удаленного выполнения команд можно применять Web Services for Management (WS-Management). Обеспечивается поддержка Windows Management Instrumentation (WMI), выполнение заданий по расписанию (Task Scheduler), протоколирование событий и их перенаправление (event forwarding). Кроме того, на уровне Server Core обеспечена поддержка удаленной MMC-консоли через RPC и DCOM и протокола SNMP.

При создании скриптовых утилит в качестве основы можно применять скрипты для управления Server Core, которые расположены в каталоге \Windows\System32\Sfscripts.

Чтобы пройти сертификацию на получение логотипа «Certified for Windows Server Lonhgorn», приложения должны соответствовать следующим требованиям:

• отсутствие зависимостей от компонента Common Dialog Box;
• отсутствие зависимостей от Shell и Shell API;
• отсутствие компонентов на управляемом коде;
• при установке приложения должны поддерживать опции командной строки;
• приложения не могут быть независимыми от мультимедийных компонентов;
• приложения не должны использовать беспроводные сети.

Отметим, что требования к приложениям, претендующим на получение логотипа «Certified for Windows Server Longhorn», еще находятся в стадии разработки. При появлении финальной версии мы обсудим их более подробно — подобно тому, как мы рассматривали требования к Windows XP, Windows Server 2003 и Windows Vista (см. «Уроки чистописания. Создание приложений, корректно работающих под Windows XP, Windows Server 2003 и Windows Vista» в № 2’2006 и «Уроки чистописания. Часть 2. На пути к Windows Vista Logo» в № 5’2006).

Продолжим наше знакомство с Windows Server Longhorn. Далее мы расскажем о нескольких новшествах, появившихся в этой версии операционной системы на уровне ядра. К ним, в частности, относятся транзакционная файловая система (доступная также в ограниченном виде в Windows XP и в полноценном в Windows Vista), транзакционный реестр, удаленное сжатие (Remote Differential Compression, RDC), новинки в Task Scheduler API, Windows Remote Management и Boot Configuration Data (BCD). А кроме того, напомним о технологиях Windows Error Reporting, Windows Restart Manager и Application Recovery and Restart.

Транзакционная файловая система

Транзакционная файловая система (TxF) — это расширение файловой системы NTFS, позволяющее выполнять файловые операции над томом файловой системы NTFS в рамках транзакций. Это стало возможным благодаря новой транзакционной инфраструктуре, реализованной на уровне ядра операционной системы и позволяющей сервисам операционной системы участвовать в транзакциях, используя новый компонент — менеджер транзакций Kernel Transaction Manager (KTM). Помимо этого в обеспечении функционирования транзакционной файловой системы задействована подсистема протоколирования Common Log File System (CLFS), впервые реализованная в Microsoft Windows Server 2003 R2. Взаимодействие этих компонентов показано на рисунке.

Применение транзакционной файловой системы делает возможным выполнение следующих типовых сценариев. Благодаря тому что TxF способна полноценно взаимодействовать с MS Distributed Transaction Coordinator (DTC), она может участвовать в транзакциях, использующих не только менеджеры ресурсов, предоставляемые Kernel Transaction Manager, но и другие менеджеры ресурсов, поддерживаемые на уровне DTC. Например, система документооборота может воспользоваться этой возможностью для работы как с файловой системой, так и с базой данных — и все в рамках одной транзакции.

Другой пример применения транзакционной файловой системы — обновление файлов на группе компьютеров. А за счет расширений в протоколе совместного доступа к файлам и папкам — SMB 2.0 — появилась возможность использования в транзакциях распределенных файловых операций, например при работе с клиентами под управлением Windows Vista.

Отметим, что TxF не поддерживает операции над зашифрованной файловой системой (Encrypted File System, EFS), за исключением операций чтения (например, ReadEncryptedFileRaw).

Транзакционная файловая система предоставляет разработчикам новые функции, в том числе:

• CopyFileTransacted;
• CreateDirectoryTransacted;
• CreateFileTransacted;
• CreateHardLinkTransacted;
• CreateSymbolicLinkTransacted;
• DeleteFileTransacted;
• FindFirstFileNameTransactedW;
• FindFirstFileTransacted;
• FindFirstStreamTransactedW;
• GetCompressedFileSizeTransacted;
• GetFileAttributesTransacted;
• GetFullPathNameTransacted;
• GetLongPathNameTransacted;
• MoveFileTransacted;
• RemoveDirectoryTransacted;
• SetFileAttributesTransacted.

В качестве одного из параметров при вызове перечисленных функций указывается ссылка на транзакцию, в рамках которой выполняется данная операция. Транзакция может быть создана путем вызова функции CreateTransaction при применении Kernel Transaction Manager или функции GetKTMHandle — при использовании DTC.

Появление транзакционной файловой системы привело к внесению ряда изменений в работу следующих функций: CloseHandle, CreateFileMapping, FindNextFile, GetFileInformationByHandle, GetFileInformationByHandleEx, GetFileSize, GetFileSizeEx, GetVolumeInformation, MapViewOfFile, MapViewOfFileEx, ReadDirectoryChangesW, ReadFile, ReadFileEx, ReadFileScatter, SetEndOfFile, WriteFile, WriteFileEx и WriteFileGather. В MSDN Library в разделе FileIO Functions and Transactional NTFS подробно описаны изменения, внесенные в эти функции транзакционной файловой системой.

Компоненты транзакционной файловой системы

Последовательность действий при транзакционной работе с файловой системой может быть следующей:

1. Создание транзакции на уровне ядра:

IntPtr tx = CreateTransaction(IntPtr.Zero,

IntPtr.Zero, 0, 0, 0, 0, null);

2. Транзакционное удаление файла:

if (!DeleteFileTransactedW(file1, tx))

3. Завершение транзакции при успешном выполнении п. 2:

CommitTransaction(tx);

4. Откат транзакции при ошибке:

RollbackTransaction(tx);

5. Закрытие ссылки на транзакцию:

CloseHandle(tx);

Транзакционный реестр

По аналогии с файловой системой операции над реестром тоже могут выполняться в рамках транзакций. Это стало возможным благодаря механизму, расширяющему набор функций Registry API — Transactional Registry (TxR) и применяющему вышеупомянутый менеджер транзакций на уровне ядра — Kernel Transaction Manager. Как и в случае с транзакционной файловой системой, TxR может использовать и менеджер ресурсов, предоставляемый DTC. Возможный сценарий применения данной функциональности — транзакционная работа с базами данных, файловой системой и операциями с реестром. К функциям для работы с реестром, поддерживающим транзакции, относятся: RegCreateKeyTransacted, RegDeleteKeyTransacted и RegOpenKeyTransacted. Как и в случае с функциями, поддерживающими транзакционную файловую систему, требуется указать ссылку на транзакцию, созданную либо средствами KTM, либо DTC. Последовательность действий при транзакционных операциях с реестром может быть следующей (на примере удаления ключа реестра):

1. Создание транзакции на уровне ядра:

IntPtr tx = CreateTransaction(IntPtr.Zero, IntPtr.Zero,

0, 0, 0, 0, null);

2. Транзакционное удаление ключа реестра:

if (RegDeleteKeyTransacted(HKEY_CURRENT_USER,

 key1, RegSam.KEY_WOW64_32KEY, 0, tx, IntPtr.Zero)

!= 0)

3. Завершение транзакции при успешном выполнении п. 2:

CommitTransaction(tx);

4. Откат транзакции при ошибке:

RollbackTransaction(tx);

5. Закрытие ссылки на транзакцию:

CloseHandle(tx).

В приведенных примерах транзакционных операций с файловой системой и реестром использовалась функция CreateTransaction, предоставленная Kernel Transaction Manager (Ktmw32.dll). Как мы уже отмечали, можно также применять транзакции на уровне DTC. Первое, что необходимо сделать в этом случае, — получить ссылку на KTM-транзакцию средствами DTC. Для этого следует использовать новый интерфейс — IKernelTransaction, который служит связующим звеном между DTC и KTM при выполнении транзакционных операций. Для получения ссылки на транзакцию нужно реализовать метод GetHandle. Вот как это можно сделать на управляемом коде:

[ComImport]

 [InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]

 [Guid(“79427A2B-F895-40e0-BE79-B57DC82ED231”)]

 internal interface IKernelTransaction

   {

      void GetHandle([Out] out IntPtr handle);

   }

Для получения ссылки на транзакцию применяется следующий код:

// Используем пространство имен System.Transactions

IKernelTransaction tx = (IKernelTransaction)

TransactionInterop.GetDtcTransaction(Transaction.Current);

IntPtr txh;

tx.GetHandle(out txh);

После этого нужно использовать полученную ссылку в транзакционных операциях и завершить работу вызовом функции CloseHandle(txh).

В следующем номере мы продолжим знакомство с новинками, появившимися в Windows Server Longhorn на уровне ядра.