Windows 2000 Application Specification

Глава 1

Сводка основных требований Windows

Основы Windows

Сводка основных требований Windows

Логическое обоснование

Соответствие данным требованиям гарантирует стабильную и надежную работу приложения в операционных системах Windows.

Преимущества пользователя

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

Требования

1. Выполнение своих первичных функций и обеспечение стабильной работы

2. 32-разрядные компоненты и документирование 16-разрядного кода

3. Поддержка длинных имен файлов и путей в формате UNC

4. Поддержка принтеров с длинными названиями и путями в формате UNC

5. Отсутствие операций чтения и записи в файлы Win.ini, System.ini, Autoexec.bat или Config.sys

6. Наличие сопоставленных всем нескрытым файлам типов файлов и сопоставленных всем типам файлов пиктограмм, описаний и действий

7. Корректная проверка версии Windows

8. Драйверы ядра должны пройти проверку

9. Драйверы для аппаратуры должны пройти WHQL-тестирование

10. Клиентские компоненты должны соответствовать спецификации настольных приложений для Windows 2000

Справочная информация

Поддержка длинных имен файлов:

http://msdn.microsoft.com/isapi/msdnlib.idc?theURL=/library/psdk/winbase/filesio_7qwj.htm

Использование утилиты проверки драйверов:

http://www.microsoft.com/hwdev/driver/driververify.htm

Процедура тестирования общей функциональности и надежности для получения логотипа Certified for Microsoft Windows

http://msdn.microsoft.com/certification/download.asp.

VeriTest-Rational Install Analyzer для Windows 2000

http://www.veritest.com/mslogos/windows2000

Утилита компоновки — Microsoft Platform SDK

Соответствие основным требованиям Windows

1. Выполнение своих первичных функций и обеспечение стабильной работы

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

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

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

· У пользователей должна иметься возможность просмотра всех поддерживаемых ресурсов в ожидаемой области действия приложения, предназначенного для управления ресурсами. Кроме того, должна иметься возможность создания, сохранения, открытия и печати всех поддерживаемых отчетов.

· В приложении для онлайновой аналитической обработки (OLAP) пользователи должны иметь возможность просмотра данных и выполнения всех поддерживаемых анализов.

· Из серверного приложения для резервного копирования пользователи должны иметь возможность резервного копирования всех поддерживаемых файлов, папок или дисков на локальных и удаленных машинах.

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

Пользователи должны иметь возможность использования в приложении системных функций, поддерживаемых Windows 2000. Например:

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

· Локальный пользователь должен иметь возможность копирования и вставки фрагментов из буфера обмена Windows в другие приложения во время работы Вашего приложения.

Более подробную информацию об основных функциях и надежности см. в документе “Процедура тестирования общей функциональности и надежности для получения логотипа Certified for Microsoft Windows”, расположенном по адресу http://msdn.microsoft.com/certification/download.asp.

2. 32-разрядные компоненты и документирование 16-разрядного кода

Приложение должно представлять собой 32-разрядный исполняемый файл в формате Portable Executable (PE). Это означает, что все исполняемые файлы, включая динамически подключаемые библиотеки (DLL) и исполняемые программные файлы (EXE), должны быть 32-разрядными файлами. Вы можете проверить корректность исполняемого формата с помощью утилиты компоновки из Комплекта разработчика программного обеспечения Microsoft Platform SDK или с помощью утилиты VeriTest-Rational Install Analyzer, которую можно загрузить по адресу http://www.veritest.com/mslogos/windows2000.

Если приложение не представлено в формате PE (например, интерпретируемый код), то “ядро среды выполнения” должно быть исполняемым файлом на базе Win32 в формате PE. Например, если Вы разрабатываете приложение в Microsoft Access, оно будет иметь расширение .mdb, а не .exe. Однако файл msaccess.exe представляет собой исполняемый файл на платформе Win32 в формате PE.

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

Замечание: Для гарантии стабильной работы системы каждый 16-разрядный файл должен быть проверен как часть процесса Сертификации. Для этой проверки может потребоваться дополнительное время и дополнительные затраты для оплаты работы тестирующей лаборатории. Время и оплата определяется тестирующей лабораторией в каждом отдельном случае.

При возможности следует избегать использования 16-разрядного кода даже для совместимости с предыдущими версиями, поскольку 64-разрядные версии Windows не будут поддерживать 16-разрядный код.

3. Поддержка длинных имен файлов и путей в формате UNC

Если Ваше приложение демонстрирует пользователям и/или позволяет им вводить имена файлов, оно должно поддерживать все допустимые имена файлов Win32, включая длинные имена файлов (LFN) и имена, соответствующие стандартному соглашению об именах (UNC). Длина длинных имен файлов и имен UNC может превышать длину имен, допустимую в 16-разрядных системах Windows и приложениях DOS; кроме того, они могут включать символы, недопустимые в 16-разрядных системах Windows или DOS.

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

C:\документы и настройки\пользователь joe\мои документы\мое письмо.txt

C:\documents and settings\Joe [joeuser]\my documents\Ca$h;flow\my letter to Andrй.txt

D:\Our folder\project 10\project 11\project 12\project 13\project 14\project 15\ project 16\project 17\project 18\project 19\project 20\project 21\ project 22\project 23\project 24\project 25\project 26\project 27\ project 28\project 29\project 30\filename.ext

\\сервер\имя папки\пользователь joe\мое письмо.txt

Все функции Win32, которые создают, открывают, находят и сохраняют файлы и папки, используют в качестве максимального размера буфера для пути значение MAX_PATH. Ваше приложение должно позволять пользователям создавать файлы с общей длиной пути, не превышающей значения MAX_PATH, и должно открывать создаваемые пользователем файлы всех поддерживаемых типов с помощью самого приложения или других приложений и с использованием путей длиной не более значения MAX_PATH. Константа MAX_PATH определяется в файле поддержки platform SDK windef.h. В текущей версии platform SDK значение MAX_PATH равно 260. Вместо кодирования значения в приложении следует использовать имя константы MAX_PATH. Использование имени вместо значения поможет быстро адаптировать приложение к будущим версиям Windows, которые, возможно, будут поддерживать более длинные пути, но использовать то же имя константы.

Более подробную информацию о допустимых длинных именах файлов Win32 можно получить в Platform SDK или по адресу http://msdn.microsoft.com/isapi/msdnlib.idc?theURL=/library/psdk/winbase/filesio_7qwj.htm.

4. Поддержка принтеров с длинными названиями и путями в формате UNC

В системе Windows допускается присвоение длинных имен принтерам. Если приложение поддерживает печать, оно должно поддерживать названия принтеров длиной до 220 символов и выполнять печать на устройства с такими именами:

\\PrintServer44.domain.com\Дуплексный принтер: номер 0047 (бухгалтерия)

Цветной лазерный принтер - Research & Design Dept IP 123.456.78.9, обратитесь к Антону или Марии

Замечание: Запятые и восклицательные знаки в именах принтеров использовать запрещено.

5. Отсутствие операций чтения и записи в файлы Win.ini, System.ini, Autoexec.bat или Config.sys

Приложение не должно выполнять чтение или запись в файлы Win.ini, System.ini, Autoexec.bat или Config.sys. Эти файлы не используются в системах Windows 2000, и некоторые пользователи удаляют их.

6. Наличие сопоставленных всем нескрытым файлам вне каталога приложения типов файлов и сопоставленных всем типам файлов пиктограмм, описаний и действий

Каждому нескрытому файлу, который создается приложением в каталоге “Program Files” вне каталога приложения (см. требование 2.3), должен быть сопоставлен зарегистрированный тип файла. К нескрытым файлам относятся:

· Файлы, созданные во время установки

· Файлы реализации и файлы данных

· Внутренние файлы приложения, созданные пользователями

Если этот тип файла уже зарегистрирован, не нужно предпринимать никаких действий, хотя Вы можете использовать этот тип файла для своего приложения.

Если этот тип файла еще не зарегистрирован, выполнить для всех новых типов файлов необходимо следующие действия:

· Определить пиктограмму, чтобы файлы, создаваемые приложением, помечались ею, а не пиктограммой Windows, используемой по умолчанию.

· Указать краткое описание типа, например, “Outlook Offline Mail File.”

· Убедиться, что каждому типу файла назначено действие, которое будет выполняться при двойном щелчке (например, запустить приложение и загрузить этот файл), или указано действие “Не открывать”.

Действие “Не открывать” обычно указывается для файлов, которые пользователи не должны открывать. При двойном щелчке на файле с пометкой “Не открывать” операционная система автоматически выдаст пользователю сообщение о том, что этот файл не должен открываться. Необходимо помнить, что если в дальнейшем с типом файла “Не открывать” будет связано какое-то действие, действие “Не открывать” будет отменено.

Исключение: Если приложение позволяет пользователю сохранять или экспортировать файлы типов, которые не являются внутренними типами файлами приложения, пользователь может сохранить файл как тип, которому не назначено ни одного действия на компьютере пользователя. Приложение сохранит файл в соответствии с запросом пользователя, и с ним будет связана пиктограмма Windows, используемая по умолчанию.

Подробности реализации

Чтобы проверить, зарегистрировано ли расширение файла:

· В разделе HKCR найдите параметр, имя которого совпадает с расширением из 3 или более букв, например, “.txt”. Если параметра с таким именем не существует, необходимо зарегистрировать его (см. ниже).

Чтобы зарегистрировать новые типы файлов:

· Создайте тип файла в разделе HKCR. Тип файла – это уникальный идентификатор для всех файлов с заданным расширением. Например, “txtfile” - это тип файлов с расширением .txt. Помните, что на один и тот же тип файла могут указывать несколько расширений. Например, расширения “.txt” и “.log” указывают на один тип файла - “txtfile.” По умолчанию для типа файла используется “заменяющее имя”, которое отображается в Проводнике. Например, расширения, которые указывают на параметр “txtfile”, имеют заменяющее имя “Текстовый документ”.

· В разделе HKCR создайте для этого типа расширение из трех и более символов. Рекомендуется создавать расширения, состоящие из 4 или 5 символов, чтобы избежать конфликтов между типами файлов и легче идентифицировать файлы. Затем укажите значение по умолчанию для расширения, указывающего на только что созданный тип файла. Например, для “.txt” по умолчанию используется тип файла “txtfile”.

Чтобы зарегистрировать пиктограмму для типа файла:

· В параметре типа файла создайте параметр 'DefaultIcon' в форме REG_SZ или REG_EXPAND_SZ и назначьте для него пиктограмму. Например, для “txtfile” значением будет “%SystemRoot%\system32\shell32.dll,-152”, что означает “использовать 152-ую пиктограмму в shell32.dll”.

Чтобы назначить файлу действие “Не открывать”:

· В разделе типа файла укажите значение Reg_SZ “NoOpen”. Затем в значение можно добавить произвольный текст, если Вы хотите настроить сообщение. В качестве примера см. параметр “ocxfile” в разделе HKCR.

Пример: Структура реестра для связи расширения файла “.txt” с типом файла “Txtfile”:

HKEY_CLASSES_ROOT\.txt

(default) = "txtfile"

HKEY_CLASSES_ROOT\txtfile

\DefaultIcon

(default) = %SystemRoot%\system32\shell32.dll,-152

\shell\open\command

(default) = %SystemRoot%\system32\NOTEPAD.EXE %1

7. Корректная проверка версии Windows

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

Например, если для приложения необходима система Windows 2000 с Пакетом обновления 1 (SP1), проверка версии Вашим приложением должна позволять проводить установку в старшей версии 5, младшей версии 0, SP1, а также устанавливаться во всех операционных системах с номером версии больше этого числа (таких как Windows 2000 с Пакетом обновления 2 (SP2) и т.д.)

Исключение: В определенных случаях допускается блокировка установки в более поздних версиях Windows. В этом случае нужно:

1. Документировать это в Анкете поставщика и объяснить причину.

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

Примером могут служить утилиты для работы с диском на низком уровне. Запуск такого приложения в версии системы Windows, для которой оно не было протестировано, может впоследствии привести к потере данных пользователя. Например, в том случае, если в файловой системе произошли изменения, о которых данному приложению неизвестно.

Для приложений, которые будут работать только в Windows 2000 и более поздних версиях, рекомендуется для определения версии операционной системы использовать функцию API VerifyVersionInfo. Однако следует заметить, что эта функция API недоступна на платформах более низкого уровня. Для приложений, которые будут работать также и в Windows NT 4 для определения версии операционной системы следует использовать функцию API GetVersionEx(). Примеры такой реализации можно найти в примерах кода.

Примеры кода с использованием функции VerifyVersionInfo (для Windows 2000 и более поздних версий)

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

#ifdef Windows2000

// Для Windows2000 и выше

BOOL bIsWindowsVersionOK(DWORD dwMajor, DWORD dwMinor, DWORD wSPMajor )

{

OSVERSIONINFOEX osvi;

DWORDLONG dwlConditionMask;

ZeroMemory(&osvi, sizeof(OSVERSIONINFOEX));

osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);

osvi.dwMajorVersion = dwMajor;

osvi.dwMinorVersion = dwMinor;

osvi.wServicePackMajor = wSPMajor;

// Настройка ConditionMask.

VER_SET_CONDITION( dwlConditionMask, VER_MAJORVERSION, VER_GREATER_EQUAL );

VER_SET_CONDITION( dwlConditionMask, VER_MINORVERSION, VER_GREATER_EQUAL );

VER_SET_CONDITION( dwlConditionMask, VER_SERVICEPACKMAJOR, VER_GREATER_EQUAL );

// Вызов функции проверки.

return VerifyVersionInfo(&osvi,

VER_MAJORVERSION | VER_MINORVERSION | VER_SERVICEPACKMAJOR,

dwlConditionMask);

}

#endif

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

Этот код работает на всех 32-разрядных платформах Windows. Если нужно убедиться, что версия Пакета обновления NT4 более ранняя, чем Пакет обновления 4, для определения версии необходимо запросить следующий параметр реестра.

HKLM\system\CurrentControlSet\control\windows\CSDVersion

Значение SDVersion 0x100 соответствует Пакету обновления 1, 0x200 - Пакету обновления 2 и т.д. Пример кода для определения уровня Пакета обновления см. ниже.

BOOL bIsWindowsVersionOK(DWORD dwMajor, DWORD dwMinor, DWORD dwSPMajor )

{

OSVERSIONINFO osvi;

// Инициализация структуры OSVERSIONINFO.

ZeroMemory(&osvi, sizeof(OSVERSIONINFO));

osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);

GetVersionEx((OSVERSIONINFO*)&osvi);

// Сначала старшая версия

if ( osvi.dwMajorVersion > dwMajor )

return TRUE;

else if ( osvi.dwMajorVersion == dwMajor )

{

// Затем младшая

if (osvi.dwMinorVersion > dwMinor )

return TRUE;

else if (osvi.dwMinorVersion == dwMinor )

{

// Проверить Пакет обновления

if ( dwSPMajor &&

osvi.dwPlatformId == VER_PLATFORM_WIN32_NT )

{

HKEY hKey;

DWORD dwCSDVersion;

DWORD dwSize;

BOOL fMeetsSPRequirement = FALSE;

if (RegOpenKeyEx(HKEY_LOCAL_MACHINE,
System\\CurrentControlSet\\Control\\Windows",

0, KEY_QUERY_VALUE, &hKey) == ERROR_SUCCESS)

{

dwSize = sizeof(dwCSDVersion);

if (RegQueryValueEx(hKey, "CSDVersion",

NULL, NULL,

(unsigned char*)&dwCSDVersion,

&dwSize) == ERROR_SUCCESS)

{

fMeetsSPRequirement =

(LOWORD(dwCSDVersion) >= dwSPMajor);

}

RegCloseKey(hKey);

}

return fMeetsSPRequirement;

}

return TRUE;

}

return FALSE;

}

8. Драйверы ядра должны пройти проверку

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

Если Ваше приложение включает какие-либо драйверы ядра, все они должны пройти проверку, включаемую Диспетчером проверки драйверов Windows 2000 (Verifier.exe). Программа Проверки драйверов в системах Windows 2000 находится в папке \system32. Дополнительную информацию по использованию утилиты проверки драйверов и диагностике проблем драйверов можно найти по адресу http://www.microsoft.com/hwdev/driver/driververify.htm .

9. Драйверы для аппаратуры должны пройти WHQL-тестирование

Если продукт содержит драйверы для аппаратных устройств, эти драйверы должны быть протестированы Лабораториями качества аппаратуры Windows (WHQL). Обратите внимание, что тестирование в WHQL может занять до 30 дней. Дополнительную информацию можно найти по адресу http://www.microsoft.com/hwdev/winlogo.

10. Клиентские компоненты должны соответствовать спецификации настольных приложений для
Windows 2000

Для получения логотипа Certified for Windows (Сертифицировано для Windows) все клиентские компоненты, работающие в Windows 2000 Professional и поставляемые с Вашим приложением, должны соответствовать спецификации настольных приложений для Windows 2000. Распределенные приложения, имеющие клиентские компоненты, могут иметь оба обозначения на логотипах Certified for Windows (Сертифицировано для Windows) - Windows 2000 Server и Windows 2000.

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

· Административные утилиты для серверного приложения освобождаются временно до 31 марта 2001 г. После этого они требование соответствия спецификации настольных приложений будет применяться и к ним.

· “Агенты”, не имеющие пользовательского интерфейса

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

Замечание: Тестирование клиентских компонентов будет выполняться в среде Windows 2000 Professional, а не в операционных системах более низкого уровня.

Предварительное тестирование приложений на соответствие фундаментальным требованиям Windows

Проверка того, что приложение действительно является 32-разрядным.

Используйте утилиту VeriTest-Rational Install Analyzer для Windows 2000, которую можно загрузить по адресу http://www.veritest.com/mslogos/windows2000, или утилиту компоновки из Microsoft Platform SDK.

Если Вы используете утилиту компоновки из Microsoft Platform SDK, наберите. “link –dump –headers exename.exe | more”. Если приложение имеет корректный формат PE, Вы увидите на экране следующее:

Microsoft (R) COFF Binary File Dumper Version 5.12.8181

Dump of file exename.exe

PE signature found

File Type: EXECUTABLE IMAGE

Вы не должны получить следующую информацию, соответствующую 16-разрядному приложению:

Microsoft (R) COFF Binary File Dumper Version 5.12.8181

Dump of file exename.exe

LINK : warning LNK4095: " exename.exe" is an NE format executable; use EXEHDR to dump it

Предварительное тестирование записи в файлы Win.ini, System.ini, Autoexec.bat и Config.sys:

1. Перед установкой приложения на компьютер, на котором заново установлена система Windows, создайте и сохраните копии этих файлов.

2. Установите приложение.

3. Запустите приложение, поработайте с ним, затем закройте.

4. Сравните установленные файлы с сохраненными и убедитесь, что они не изменились. Анализатор установки проведет эту проверку для Вас.

Тестирование корректности обработки продуктом длинных имен файлов:

Для длинных имен файлов:

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

· Пробелы в начале или в конце не сохраняются. Это можно проверить, набрав “###test###” или подобный текст в диалоговом окне “Сохранить как”. (В этом разделе знак # обозначает символ пробела. Его код ANSI 0032). Программа должна удалить пробелы, добавить расширение и возвратить имя файла “test.ext”.

Замечание: Символ ANSI 0160, используемый в качестве неразрывного пробела во многих шрифтах, не должен удаляться, даже если он используется в начале или в конце имен файлов и папок.

· Должно поддерживаться число символов не менее значения MAX_PATH (включая путь и расширение).

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

Если Вы наберете...	Должно сохраниться
“test”	“test.ext”
“ test”	“test.ext”
“test “	“test.ext”
“test#;#+#,#=#[#]”	“test#;#+#,#=#[#].ext”
“ test “ (символы неразрывного пробела, код ANSI 0160)	“ test .ext“
“…..test…..”	“…..test……ext”
“\\сервер\общая папка\дерево папок\файл”	“\\сервер\общая папка\дерево папок\файл.ext”

ЗАМЕЧАНИЕ: Если Вы набираете включающее пробелы имя в формате UNC, в командной строке, его необходимо заключить в кавычки.

Запуск тестов для драйверов ядра

1. Подключите отладчик режима ядра к тестирующему компьютеру. Несколько подходящих отладчиков, включая отладчики текстового режима и GUI, имеется на компакт-дисках Windows 2000 SDK и DDK, а также на компакт-диске Windows 2000 Symbols and Support.

2. Установите приложение вместе с его драйверами ядра.

3. Запустите Verifier.exe и выберите закладку Установки. Найдите имя драйвера в списке Драйвер. Выберите все драйверы Вашего приложения в списке и нажмите кнопку “Проверить”. Если в списке Драйвер нет некоторых имен драйверов, введите их в поле “Проверить дополнительные драйверы после следующей перезагрузки”. Разделяйте имена драйверов в этом поле пробелами и используйте только имя драйвера и его расширение. Не включайте путь.

4. Для типа проверки установите только следующие флажки:

а. Специальный пул

б. Принудительная проверка IRQL

в. Контроль пула

г. Проверка ввода/вывода

5. Нажмите кнопки “Применить”, “Выход”, затем произведите перезагрузку.

6. После перезагрузки запустите приложение и проведите серию обычных пользовательских тестов Если в процессе загрузки или пользовательских тестов Ядро обнаружит в драйвере какие-либо ошибки, это приведет к остановке Windows 2000 и выводу соответствующей информации в текстовом режиме (синий экран) и в отладчике ядра. Если в отладчике указано, что пул поврежден, снимите флажок “Контроль пула” в типе проверки и повторите попытку. Устранив ошибки, вновь установите флажок “Контроль пула” и повторите тест.

7. Если ошибок не обнаружено, перезапустите Verifier.exe. Выберите имена всех драйверов еще раз и нажмите кнопку “Проверить” или введите имена драйверов (имя файла и расширение без пути) в поле “Проверить дополнительные драйверы после следующей перезагрузки”, разделяя их пробелами.

8. Снимите все флажки “Тип проверки”, затем установите флажок “Имитация недостатка ресурсов”.

9. Нажмите кнопку “Применить”, выйдите и произведите перезагрузку. Запустите приложение и проведите серию обычных пользовательских тестов.

10. Режим имитации недостатка ресурсов приведет к тому, что ядро будет периодически возвращать драйверу недопустимые данные и коды ошибок. Во время тестов драйвер должен корректно обрабатывать недопустимые коды, возможно, путем отклонения запросов пользователей или выдачи диалогов с сообщением об ошибке. Если драйвер предпринимает попытки использования некорректных данных или игнорирует сообщения об ошибках, приложение станет работать нестабильно и даст сбой. Точные симптомы зависят от приложения и назначения драйвера. Целью этого теста является проверка того, что драйвер не приводит к аварийным ситуациям и не “подвешивает” систему. Допускаются отдельные сбои приложений, использующих Ваш драйвер, но аварийные ситуации в системе НЕ допускаются.

Describes the requirements to help ensure that applications perform a clean installation and can be properly uninstalled.

Глава 2

Установка/Удаление

Сводка требований к установке/удалению

Логическое обоснование

Проблемы установки и удаления являются основными источниками проблем взаимодействия приложений. Эти требования помогают обеспечить успешную установку и удаление пользователем и отсутствие конфликтов данного приложения с остальными.

ЗАМЕЧАНИЕ: НАСТОЯТЕЛЬНО рекомендуется использовать для установки приложения службу Windows Installer. Служба установки Windows Installer – это компонент операционной системы, централизованно управляющий конфигурацией установки приложения, а также его удалением. Использование Windows Installer позволяет операционной системе управлять установкой и конфигурированием приложений, что обеспечивает:

· Управление подсчетом ссылок и проверкой версий совместно используемых компонентов, что помогает обеспечить лучшее сосуществование приложений.

· Самовосстановление поврежденных приложений при запуске: Во время запуска приложения служба Windows Installer проверит корректность его установки и, если установка некорректна, динамически восстановит приложение.

· Установка с использованием транзакций: Если установка не завершена (например, произошел сбой в сети), Windows Installer может вернуться к ранее установленной без ошибки версии приложения.

· Надежное и полное удаление, включая корректную обработку совместно используемых компонентов.

· Возможность установки в защищенных системах (для непривилегированных пользователей и пользователей, не являющихся администраторами).

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

Windows Installer позволяет использовать все эти возможности с помощью пакетов, описывающих конфигурации приложений. Windows Installer поставляется вместе с Windows 2000, а также распространяется с Windows NT 4, Windows 98 и Windows 95.

Дополнительную информацию можно получить в справочнике программиста Windows Installer в Platform SDK.

Преимущества пользователя

· Уменьшение числа проблем, возникающих при установке приложения: Благодаря надлежащей реализации счетчика ссылок и проверки версии снижается вероятность того, что установка и удаление приложений отразится на работе другого приложения.

· Клиенты могут корректно удалить приложение.

Требования

1. Отсутствие попыток замены файлов, защищенных с помощью Защиты файлов Windows

2. Отсутствие попыток замены не принадлежащих приложению файлов их более старыми версиями

3. Установка по умолчанию в каталог Program Files

4. Установка совместно используемых файлов в корректные каталоги

5. Контрольный подсчет всех совместно используемых файлов во время установки

6. Корректная поддержка добавления/удаления программ

7. Уменьшение значения счетчика для совместно используемых файлов во время удаления

8. Корректное удаление

Соответствие требованиям по установке/удалению

ЗАМЕЧАНИЕ: Если приложение использует службу Windows Installer, требования к установке/удалению из Главы 2 спецификации настольных приложений имеют приоритет над требованиями 2.2 - 2.8 этой главы, за исключением того, что требование 2.6 (поддержка оповещений) не относится к серверным приложениям.

1. Отсутствие попыток замены файлов, защищенных с помощью Защиты файлов Windows

Приложение не должно предпринимать попытки замены каких-либо файлов Windows 2000, защищенных с помощью Защиты файлов Windows (WFP). Чтобы гарантировать, что Вы не активизируете WFP, во время установки всех файлов, создателем которых Вы не являетесь, вызывайте функцию SfcIsFileProtected. Служба установки Windows Installer версии 1.1 делает это автоматически.

В число защищенных входят следующие файлы, поставляемые на компакт-диске Windows 2000:

· Почти все файлы .SYS, .DLL, .EXE и .OCX.

· Следующие шрифты: micross.ttf, tahoma.ttf, tahomabd.ttf; fixedsys.fon, dosapp.fon, modern.fon, script.fon и vgaoem.fon

Замечание: Некоторые файлы, которые могут поставляться с Вашим приложением, например, определенные версии библиотек DLL Microsoft Foundation Classes (MFC), устанавливаются Windows 2000 и защищаются WFP.

Защищенные файлы составляют ядро операционной системы, а для стабильной работы системы необходима поддержка соответствующих версий. Обновление этих файлов можно выполнить только с помощью Пакетов обновлений, обновлений операционной системы, QFE-исправлений и пакета Windows Update. Приложения не могут заменить эти файлы, а попытка заменить их другими средствами, отличными от указанных выше, приведет к тому, что они будут восстановлены Защитой файлов Windows (см. ниже).

Если Вашему приложению необходимы новые версии этих компонентов, оно должно обновить эти компоненты с помощью утвержденного Пакета обновлений Microsoft, который устанавливает необходимые версии.

О Защите файлов Windows:

Защита файлов Windows - это функция Windows 2000, которая предотвращает замену важных системных файлов. WFP работает в системе Windows 2000 в фоновом режиме и следит за файлами, перечисленными в предыдущем разделе. Если WFP обнаруживает, что защищенный файл был изменен, она восстанавливает оригинал.

В следующем коде показано, как определить, защищен ли файл (в данном случае “ntdll.dll”) с помощью WFP. Обратите внимание, что функция SfcIsFileProtected определена только для Unicode, и для нее необходимо указать полностью определенный путь.

SHGetFolderPath(NULL,CSIDL_SYSTEM, NULL, 0, szSystemDir);

PathAppend(szSystemDir,"ntdll.dll");

MultiByteToWideChar(CP_ACP, 0, szSystemDir, -1, wzFileName, 265);

if ( SfcIsFileProtected(wzFileName) )

MessageBox(hWnd,szProtected,szSystemDir,MB_OK);

else

MessageBox(hWnd,szNotProtected,szSystemDir,MB_OK);

2. Отсутствие попыток замены не принадлежащих приложению файлов их более старыми версиями

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

Для проверки версии рекомендуется использовать функции API VerInstall или GetFileVersionInfo. Использование функции VerInstall проще, поскольку она использует функцию GetFileVersionInfo сама по себе, что упрощает процесс. Ниже приводится упрощенный пример использования функции VerInstall:

TCHAR szOldDir[MAX_PATH], szTempDir[MAX_PATH];

UINT cchTemp = MAX_PATH;

DWORD dwResult = VerInstallFile(0, TEXT("file.dll"), TEXT("file.dll"), g_tszSetupDirectory, g_tszInstallDirectory, szOldDir, szTempDir, &cchTemp);

if (dwResult != 0) {

Error(dwResult);

}

3. Установка по умолчанию в каталог Program Files

По умолчанию приложение должно устанавливать компоненты, не используемые совместно, в соответствующий подкаталог, где хранятся программные файлы текущего пользователя (например, Program Files). Эта папка представляется CSIDL_PROGRAM_FILES. В английских версиях систем чаще всего это каталог “C:\Program Files”. Однако не храните этот путь в самом приложении: он не является универсальным.

Для поиска этой папки рекомендуется использовать функцию SHGetFolderPath (CSIDL_PROGRAM_FILES,…). Если Вы используете Windows Installer, эта папка в пакете на базе Windows Installer представляется свойством ProgramFilesFolder.

Исключения:

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

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

Рекомендации относительно совместно используемых компонентов

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

4. Установка совместно используемых файлов в корректные каталоги

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

· Компоненты, совместно используемые приложениями только одного производителя программного обеспечения, должны устанавливаться в один из двух следующих каталогов. Не сохраняйте эти файлы в системном каталоге.

каталог общих файлов\<название компании>

%ProgramFiles%\<название компании>\Shared files

Доступ к каталогу общих файлов можно получить путем передачи CSIDL_PROGRAM_FILES_COMMON в функцию API SHGetFolderPath.

· Не являющиеся смежными компоненты OCX и DLL, которые используются совместно несколькими поставщиками программного обеспечения, могут располагаться в системном каталоге для обеспечения совместимости сверху вниз с этими приложениями.

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

· Новые апплеты панели управления (CPL) в Windows 2000 должны устанавливаться в каталог приложения. Зарегистрируйте путь, добавив значение в один из следующих разделов реестра:

HKLM\software\microsoft\windows\CurrentVersion\control panel\cpls

HKCU\software\microsoft\windows\CurrentVersion\control panel\cpls

Пример пары имя/значение в этом разделе:

MyCpl = “%ProgramFiles%\MyCorp\MyApp\MyCpl.cpl”

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

Замечание: Если системный каталог используется привилегированным пользователем или администратором, он не блокируется. Таким образом, в системный каталог можно помещать компоненты для более старых версий или глобальные совместно используемые компоненты. Однако Защита файлов Windows предотвращает замену защищенных файлов операционной системы. См. требование 2.

5. Контрольный подсчет всех совместно используемых файлов во время установки

Если приложение не использует Windows Installer, его программа установки должна подсчитывать все совместно используемые компоненты. Это должно выполняться в следующем разделе реестра:

[HKEY_LOCAL_MACHINE]\SOFTWARE\Microsoft\Windows\Current Version\SharedDLLs

Если Ваша программа установки обнаружит в системе незарегистрированный совместно используемый компонент, счетчик SharedDLL должен быть увеличен на 1 плюс число компонентов Вашего приложения, использующих этот компонент. Например, если Ваше приложение устанавливает три компонента, использующих разделенный файл, и этот файл уже зарегистрирован, программа установки увеличит значение счетчика SharedDLL на 3. Однако если общий файл уже есть в системе, но для него не существует SharedDLL (то есть предыдущая программа установки не создала счетчик), то значение SharedDLL должно быть увеличено на 4. Таким образом, при удалении Вашего приложения для разделенного файла останется значение счетчика 1.

Компоненты, разделенные приложениями, не использующими службу Windows Installer, должны при необходимости регистрации во время установки надлежащим способом использовать записи DLLRegisterServer и DLLUnregisterServer. (Библиотеки DLL, использующие Windows Installer, должны использовать службу регистрации, поддерживаемую Windows Installer).

6. Корректная поддержка добавления/удаления программ

Чтобы функция Добавления/удаления программ в Панели управления могла получить необходимую информацию о приложении, Ваше приложение должно занести всю информацию в следующую таблицу. Эта информация может записываться непосредственно в реестр во время установки или, если Вы используете Windows Installer, эти значения можно установить с помощью свойств пакета на базе Windows Installer.

Значения реестра должны записываться в следующий раздел:

HKEY_LOCAL_MACHINE

\Software

\Microsoft

\Windows

\CurrentVersion

\Uninstall

\{ProductCode}

Значение в реестре	Тип	Соответствующее свойство Windows Installer	Содержит
DisplayName	REG_SZ	ProductName	Отображаемое название приложения.
UninstallPath	REG_EXPAND_SZ	Нет	Полный путь к программе удаления приложения.
InstallLocation	REG_EXPAND_SZ	ARPINSTALLLOCATION	Полный путь к приложению (папке или файлу .exe).
Publisher	REG_SZ	Manufacturer	Разработчик приложения.
VersionMajor	DWORD	ProductVersion	Номер старшей версии приложения.
VersionMinor	DWORD	ProductVersion	Номер младшей версии приложения.

Замечание: Имена свойств учитывают регистр.

Вы можете также определять дополнительные свойства для представления в функции Добавления/удаление программ, такие как идентификатор продукта (ID), информация о его поддержке и т.д. Полную информацию можно найти в Platform SDK.

7. Уменьшение значения счетчика для совместно используемых файлов во время удаления

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

8. Корректное удаление

Приложение должно предоставлять программу автоматического удаления. Программа удаления должна быть корректно зарегистрирована, как это описано в требовании 2.7, и должна удалять следующие компоненты:

· Все файлы и каталоги приложения, не являющиеся совместно используемыми

· Совместно используемые файлы, значение счетчика которых достигло нулевого

· Записи реестра, за исключением тех, которые могут использоваться другими программами

· Все ярлыки из меню Пуск, созданные приложением при установке

· Саму программу удаления

На жестком диске должны оставаться:

· Файлы данных пользователя.

· Совместно используемые файлы, имеющие ненулевое значение счетчика.

· Другие ресурсы, которые могут использоваться другими программами, например, совместно используемые шрифты и записи реестра.

Все компоненты, которые не удаляются, должны быть документированы Анкете поставщика.

Подсказка: Если приложение создает временные файлы, которые должны удаляться в процессе удаления приложения, создайте во время установки файл нулевой длины с таким же именем. Примерами таких файлов могут служить файлы .gid, создаваемые Справкой.

ЗАМЕЧАНИЕ: Если приложение использует Windows Installer, соблюдает правила создания компонентов и использует только стандартные действия Windows Installer для настройки компьютера, возможность удаления предоставляется автоматически.

Предварительное тестирование приложения
на соответствие требованиям по установке/удалению.

Предварительное тестирование удаления:

1. Зафиксируйте состояние дерева каталогов компьютера и реестра, установите приложение, удалите его и снова зафиксируйте состояние дерева каталогов и реестра.

2. Убедитесь, что состояние дерева до установки и после удаления приложения одинаково, за исключением того, что должно остаться на компьютере: созданных пользователем файлов и совместно используемых компонентов, необходимых другим программам.

Утилита VeriTest-Rational Install Analyzer для Windows 2000, которую можно загрузить по адресу http://www.veritest.com/mslogos/windows2000, поможет Вам сделать это.

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

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

	Сценарий 1	Сценарий 2	Сценарий 3	Сценарий 4
Шаг 1	Установите Ваше приложение	Установите Ваше приложение	Установите “другое” приложение	Установите “другое” приложение
Шаг 2	Установите “другое” приложение	Установите “другое” приложение	Установите Ваше приложение	Установите Ваше приложение
Шаг 3	Удалите Ваше приложение	Удалите “другое” приложение	Удалите “другое” приложение	Удалите Ваше приложение
Шаг 4	Убедитесь, что “другое” приложение по-прежнему работает	Убедитесь, что Ваше приложение по-прежнему работает	Убедитесь, что Ваше приложение по-прежнему работает	Убедитесь, что “другое” приложение по-прежнему работает
Шаг 5	Удалите “другое” приложение	Удалите Ваше приложение	Удалите Ваше приложение	Удалите “другое” приложение
Шаг 6	Убедитесь, что все совместно используемые компоненты удалены	Убедитесь, что все совместно используемые компоненты удалены	Убедитесь, что все совместно используемые компоненты удалены	Убедитесь, что все совместно используемые компоненты удалены

Глава 3

Основы пользовательского интерфейса

Describes the requirements for that the application provides a consistent, effective user interface.

Общая информация о требованиях к пользовательскому интерфейсу

ЗАМЕЧАНИЕ: Серверное приложение не обязательно должно иметь графический интерфейс пользователя. Однако если пользовательский интерфейс имеется, он должен отвечать приведенным ниже требованиям. Независимо от наличия или отсутствия пользовательского интерфейса, все приложения должны соответствовать требованию 3.5.

Логическое обоснование

· Согласованность и доступность приложений для Windows повышают уверенность пользователей в приложениях Windows и в платформе Windows.

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

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

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

Преимущества пользователя

· Однотипный пользовательский интерфейс сокращает затраты пользователей на подготовку, поддержку и тестирование.

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

· Соответствие требованиям к пользовательскому интерфейсу позволяет Вашим клиентам приобретать программное обеспечение, соответствующее стандартам использования, таким как HFES/ANSI 200 и ISO 9241. Такие стандарты будут расширяться и включать требования высокого уровня по использованию и доступности программного обеспечения.

· Соответствие требованиям к пользовательскому интерфейсу позволяет использовать Ваш продукт более чем 49 миллионам пользователей в США. По данным департамента по доступу США каждый пятый житель США и каждый восьмой пользователь Интернет имеет некоторые физические недостатки.

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

Требования

1. Поддержка стандартного размера, цвета, шрифта и настроек ввода системы

2. Обеспечение совместимости с параметром Высокая Контрастность

3. Предоставление описанного в документации доступа с клавиатуры ко всем функциям

4. Предоставление информации о местоположении фокуса ввода с клавиатуры

5. Отсутствие ярлыков для документов, справки или функции удаления в меню Пуск

Справочная информация

Принципы разработки доступного программного обеспечения: http://www.microsoft.com/enable.

Microsoft Active Accessibility: Обратитесь к Platform SDK

Информация для медиаплейера фирмы Microsoft:

http://www.microsoft.com/windows/mediaplayer

Принципы разработки пользовательского интерфейса для
Microsoft Windows

Обратитесь к MSDN и MS Press.

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

1. Поддержка стандартного размера, цвета, шрифта и настроек ввода системы

При отображении настраиваемых элементов управления или содержимого окна Ваше приложение должно считывать и использовать системные настройки пользовательского интерфейса. Стандартные элементы управления, предоставляемые USER32.DLL и COMCTL32.DLL, автоматически поддерживают все необходимые установки. Приложения могут добавлять поддержку этих настроек в свои окна, вызывая в процедуре окна функцию DefWindowProc. Приложения должны аккуратно обращаться с этими настройками:

· При создании нестандартных элементов управления

· При создании элементов управления, отображаемых владельцами

· При использовании родительских и дочерних классов для изменения обычного режима работы стандартного элемента управления

· При обработке сообщения без вызова функции DefWindowProc (особенно при отображении областей, не являющихся клиентскими)

· При обработке ввода на низком уровне с обходом обычных сообщений клавиатуры и мыши (например, двойного щелчка и нажатия клавиши Shift)

Эти настройки устанавливаются с помощью функций GetSysColor, GetSystemMetrics и SystemParametersInfo. Дополнительную информацию можно получить в разделе “Функции для работы с системной информацией” в Platform SDK или по адресу.

http://msdn.microsoft.com/library/psdk/sysmgmt/sysinfo_8stv.htm

Все приложения должны поддерживать:

SPI_GETHIGHCONTRAST	Все настройки GetSysColor обязательны для меню, диалоговых окон и других стандартных элементов пользовательского интерфейса. См. требование 2 в этой главе.
SPI_GETWORKAREA	Размер рабочей области основного экрана

Нестандартные поля для выделения или редактирования текста должны поддерживать:

SPI_GETCARETWIDTH

Ширина курсора в поле редактирования

Нестандартные выпадающие списки должны поддерживать:

SPI_GETCOMBOBOXANIMATION

Если значением данной настройки является FALSE, эффект соскальзывания для выпадающих списков должен быть отключен

Нестандартные обработчики клавиатуры (низкоуровневый ввод) должны поддерживать:

SPI_GETKEYBOARDDELAY

SPI_GETKEYBOARDSPEED

Настройка задержки перед началом повтора символов

Настройка скорости повтора символов

SPI_GETFILTERKEYS

Расширенный интервал для указанных выше настроек

Нестандартные меню должны поддерживать:

SM_CYMENUCHECK, CXMENUCHECK	Установленные по умолчанию размеры флажка меню
SM_CYMENU	Высота строки меню
SPI_GETNONCLIENTMETRICS IfMenuHeight lfMenuFont lfMessageFont	Высота меню Шрифт меню Шрифт окна сообщения
SPI_GETSELECTIONFADE	Если значением данной настройки является FALSE, то функция исчезновения элементов меню должна быть отключена
SPI_GETMENUANIMATION	Если значением данной настройки является FALSE, то эффекты анимации меню должны быть отключены
SPI_GETMENUFADE	Если значением данной настройки является FALSE, то эффекты анимации исчезновения меню должны быть отключены

Специальные функции мыши должны поддерживать:

SM_CYDOUBLECLK, SM_CXDOUBLECLK	Максимально допустимое вертикальное и горизонтальное расстояние, на которое мышь может сдвинуться между последовательными щелчками, интерпретируемыми как двойной щелчок.
SM_CYDRAG, SM_CXDRAG	Минимальное вертикальное и горизонтальное расстояние, на которое должна сдвинуться мышь при нажатой кнопке, для начала операции буксировки
SPI_GETMOUSEHOVERHEIGHT SPI_GETMOUSEHOVERWIDTH	Высота и ширина прямоугольника, внутри которого должен находиться указатель мыши для активизации эффекта ожидания ввода
SPI_GETMOUSEHOVERTIME	Время ожидания ввода

Нестандартные полосы прокрутки должны поддерживать:

SM_CYHSCROLL

SM_CXVSCROLL

Высота горизонтальной полосы прокрутки

Ширина вертикальной полосы прокрутки

Звуковые функции приложения должны поддерживать:

SPI_GETSHOWSOUNDS

Если значением является TRUE, то приложение должно представлять всю информацию визуально, а не посредством звуковых эффектов

Нестандартные подсказки и строки состояния должны поддерживать:

SPI_GETNONCLIENTMETRICS

SPI_lfStatusFont

Шрифт, используемый в строках состояния или подсказках

SPI_GETTOOLTIPANIMATION

Если значением является FALSE, то анимация подсказок должна быть отключена

Нестандартные кадры окон должны поддерживать:

SM_CYSMCAPTION	Высота заголовка
SPI_GETNONCLIENTMETRICS IfCaptionFont	Информация о шрифте заголовка
SM_CYBORDER, SM_CXBORDER	Минимальная толщина линии в пикселах. Приложения не должны рисовать линии тоньше, чем указано, потому что на мониторах с высоким разрешением линия толщиной в 1 пиксел будет практически не видна. (Это значение устанавливается драйвером экрана и увеличивается пользователем, когда он выбирает Специальный размер системного шрифта в Панели управления).
SM_CXEDGE SM_CYEDGE	Толщина трехмерной границы в пикселах. Каждая трехмерная граница состоит из двух смежных линий, таким образом, ее толщина равна 2 * SM_CxBORDER.
SM_CXSIZEFRAME SM_CYSIZEFRAME	Толщина (в пикселах) рамки окна, размер которого можно изменять.
SM_CYFIXEDFRAME SM_CYFIXEDFRAME	Толщина (в пикселах) рамки окна, размер которого нельзя изменять. Она состоит из одной трехмерной границы, толщина которой равна SM_CxEDGE плюс одна пустая линия, толщина которой равна SM_CxBORDER.

2. Обеспечение совместимости с параметром Высокая Контрастность

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

Приложения могут определять значение параметра Высокая контрастность с помощью функции SystemParametersInfo с константой SPI_GETHIGHCONTRAST. Если этот параметр установлен, то приложение должно:

· Отображать все меню и диалоговые окна, используя цветовую схему, возвращаемую функцией GetSysColor. Это относится также ко всем остальным элементам пользовательского интерфейса, предназначенным для настройки цветов в пользовательском интерфейсе приложения.

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

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

· Наилучшим способом является использование соответствующих цветов, возвращаемых функцией GetSysColor, но приложение также может обеспечивать собственные настройки экрана.

Всегда выделяйте объекты переднего плана цветами, определенными как цвета переднего плана, и заполняйте фон соответствующими фоновыми цветами. Это требование не зависит от того, выбраны ли цвета с помощью функции GetSysColor или являются собственными настройками приложения. Например, все объекты, которые нарисованы цветом текста окна (COLOR_WINDOWTEXT), должны быть нарисованы на фоновом цвете окна (COLOR_WINDOW), а все объекты, нарисованные с использованием цвета выделенного текста (COLOR_HIGHLIGHTTEXT), должно быть нарисованы на выделенном фоне (COLOR_HIGHLIGHT).

· Гарантировать, что вся информация, передаваемая цветом, передается также и другими способами, например звуком или видом экрана, потому что пользователь мог выбрать черно-белую цветовую схему.

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

Замечание: Пользователи могут изменять режим высокой контрастности из раздела “Специальные возможности” Панели управления, выбрав закладку “Экран” и установив флажок “Высокая контрастность”.

Пользователи могут изменять значения, возвращаемые функцией GetSysColor, с помощью раздела “Экран” Панели управления, выбрав закладку “Оформление”.

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

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

· Палитры и образцы, где пользователь выбирает цвет из набора отображаемых цветов. В этом случае приложение может отображать цвета, но должно также предоставлять текстовое описание, например, название цвета (светло-голубой) или численное значение (RGB 0,255,255).

· Анимация, видео или графические изображения, когда содержащаяся в них информация может быть получена другими способами.

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

Вопрос, может ли функция считаться исключением, решается в каждом отдельном случае. Вы должны подробно описать все исключения в Анкете поставщика.

3. Предоставление описанного в документации доступа с клавиатуры ко всем функциям

Ваше приложение должно так обеспечивать доступ с клавиатуры ко всем своим функциям, чтобы не требовалось использование мыши или другого устройства ввода. Стандартные элементы управления, предоставляемые USER32.DLL и COMCTL32.DLL, автоматически поддерживают все необходимые установки. Приложения должны обеспечивать такую поддержку только при:

· Создании нестандартных классов окон и элементов управления

· Изменении обычного поведения стандартных окон и элементов управления

· Назначении навигации с помощью клавиатуры в диалоговых окнах.

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

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

Пример: Информация может предоставляться в виде справки, текстового файла на компакт-диске с продуктом или на посвященном продукту Web-узле.

Замечание: Реакция на клавиатурный ввод стандартных классов окон документирована в руководстве The Microsoft Windows Keyboard Guide, которое можно найти по адресу http://www.microsoft.com/enable.

Исключение: Исключения могут быть сделаны в следующих случаях:

· Приложения, полагающиеся на специализированные устройства ввода, например графические планшеты.

· Ситуации, когда мышь указывает на объекты размером не более одного пиксела. Например, рисование мышью. Такая функция может полагаться на функцию MouseKeys, встроенную в 32-разрядную операционную систему Microsoft Windows и позволяющую пользователям перемещать указатель мыши с помощью клавиатуры. Однако это неприемлемо для черчения, когда пользователь может независимо управлять текстовыми и графическими объектами. Это исключение применимо к отдельным функциям продукта, а не ко всему приложению.

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

4. Предоставление информации о местоположении фокуса ввода с клавиатуры

Ваше приложение должно визуально отмечать положение фокуса клавиатуры и уведомлять другие программы о его положении с помощью Microsoft Active Accessibility™ или путем перемещения текстового курсора.

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

Если использование Microsoft Active Accessibility не представляется возможным, приложение может отображать положение фокуса путем перемещения текстового курсора. Обычно текстовый курсор представляет собой мигающую вертикальную черту, которую пользователь видит при вводе текста, но его можно поместить в любую точку экрана, изменять его форму и размер и даже сделать невидимым. Невидимый курсор можно перемещать для указания положения фокуса для других приложений, не изменяя содержания экрана.

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

Каждый раз, когда фокус перемещается к новому объекту, имеющему другие размеры, приложение должно вызвать функцию DestroyCaret, а затем функцию CreateCaret для указания размера нового объекта. Курсор должен закрывать прямоугольник, окружающий элемент на экране, чтобы средства увеличения экрана предоставляли возможность пользователю увеличивать различные части области ввода.

Приложение должно отображать индикаторы фокуса ввода и выделения только в активном окне. Если окно неактивно, приложение должно удалить визуальный индикатор и вызвать функцию DestroyCaret.

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

5. Отсутствие ярлыков для документов, справки или функции удаления в меню Пуск

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

· Не помещайте ярлыки документов, например, файлов readme, в меню Пуск. Если пользователь должен получить какую-либо важную информацию, предъявляйте ее в процессе установки.

· Не помещайте ярлыки для файлов справки в меню Пуск. Пользователи получат доступ к справке после запуска приложения.

· Не помещайте ярлыки для удаления программ в меню Пуск. Эта функция доступна из пункта Установка/удаление программ в панели управления.

Рекомендуется (но не обязательно) производить следующие действия:

· Помещать пиктограмму для запуска приложения непосредственно в папку Пуск -> Программы. Не следует помещать ее в отдельную папку. Особенно не следует создавать в меню Пуск папку для одного элемента. Часто приложения создают папку, имеющую название фирмы и помещают в нее единственный ярлык для запуска приложения. Вместо этого переименуйте ярлык таким образом, чтобы название включало в себя название фирмы, и откажитесь от использования папки.

Программы à Моя фирма à Мое приложение (Избегайте этого)

Программы à Моя фирма Мое приложение (Рекомендуется)

· Не следует помещать никаких элементов в верхний уровень меню Пуск, так как пользователи считают его своим пространством.

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

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

Предварительное тестирование поддержки системной метрики:

1. Откройте Панель управления, затем откройте Экран.

2. Выберите закладку Оформление.

3. Выберите схему с пометкой (гигантский шрифт), например схему “Стандартная (гигантский шрифт)”. Щелкните кнопку “Применить”.

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

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

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

· Текст выходит за границу окна, но его можно просмотреть с помощью горизонтальных и вертикальных полос прокрутки.

Предварительное тестирование поддержки режима Высокой контрастности:

1. Откройте Панель управления, затем откройте Специальные возможности.

2. Выберите закладку “Экран”.

3. Установите флажок “Высокая контрастность”.

4. Выберите пункт “Настройка”.

5. Выберите “Настраиваемая” и проверьте, что выбрана Контрастная черная схема. Примените эти настройки.

6. Вернитесь к приложению, проверьте все основные и диалоговые окна, элементы управления и убедитесь, что изменения отражены корректно.

7. Повторите действия, выбрав на шаге 5 схему Контрастная белая.

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

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

Предварительное тестирование документированного доступа с клавиатуры:

1. Откройте Панель управления, затем откройте пункт Специальные возможности.

2. Выберите закладку “Клавиатура”.

3. Установите флажок “Дополнительные сведения о работе с клавиатурой”. Примените эти настройки.

4. Проверьте основные функции приложения, не используя мышь.

5. Убедитесь, что ни для одного действия мышь не требуется.

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

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

6. Убедитесь, что все пункты меню и элементы управления доступны при помощи сочетаний клавиш.

Предварительное тестирование фокуса клавиатурного ввода:

1. Используйте поставляемую с Windows 2000 экранную лупу. В меню Пуск выберите Программы -> Стандартные -> Специальные возможности -> Экранная лупа.

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

· Правильно отображает местоположение фокуса ввода при перемещении или при вводе текста в документ, текстовое поле или таблицу.

· Правильно отображает местоположение фокуса ввода при перемещении по меню, диалоговым окнам, панелям инструментов, спискам и другим элементам управления.

· Правильно отображает местоположение фокуса ввода при изменении размера выделения в тексте и списках или при просмотре древовидных структур.

· Правильно отображает местоположение фокуса ввода при возврате в приложение из диалогового окна, меню или другого приложения.

Глава 4

Активный каталог

Сводка требований к Активному каталогу

Логическое обоснование

Часто в географически распределенных окружениях, где используется локальная и глобальная сеть, используется также Активный каталог. Во многих из таких окружений для обеспечения доступности и масштабируемости могут применяться сотни или тысяч серверов Активного каталога.

Настоящие требования позволят:

· Более эффективно использовать сетевые ресурсы.

· Обеспечить согласованность между приложениями, использующими Активный каталог.

· Улучшить поддержку приложений, использующих Активный каталог.

· Обеспечить совместное существование приложений, расширяющих схему.

Преимущества пользователя

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

Интеграция Вашего приложения с Активным каталогом обеспечит Вашим клиентам:

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

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

· Делегирование администрирования. Управление доступом на уровне атрибутов в Активном каталоге позволяет клиентам делегировать администрирование разных частей приложения соответствующим пользователям.

Требования

1. Корректное использование активного каталога

2. Документирование влияния приложения на хранение и репликацию

3. Документирование использования приложением объектов и атрибутов базовой схемы

4. Информация, хранящаяся в активном каталоге, должна представлять “глобальный интерес”

5. Значения атрибутов не должны превышать 500 КБ, а общий размер объекта не должен превышать 1 МБ

6. При расширении схемы необходимо соблюдать правила расширяемости схемы активного каталога

Справочная информация

Руководство программиста активного каталога:

http://msdn.microsoft.com/developer/windows2000/adsi/actdirguide.asp

Информация об объектах активного каталога:

http://msdn.microsoft.com/library/backgrnd/html/msdn_actdsum.htm

Утилита SchemaDoc.exe для документирования расширений схемы активного каталога

http://msdn.microsoft.com/certification/download.asp

Соответствие требованиям для активного каталога

1. Корректное использование активного каталога

Настоящие требования позволят:

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

· Гарантировать, что приложение имеет самую новую информацию о сетевых ресурсах.

· Минимизировать необходимость ввода и хранения дублирующейся информации о сетевых элементах.

А. Если приложение состоит из нескольких компонентов, выполняющихся на разных машинах, и имеются 'клиентские компоненты', запрашивающие обслуживание 'серверных компонентов'[2], то:

· Если активный каталог доступен в окружении, где применяется приложение, серверные компоненты Вашего приложения должны хранить информацию в активном каталоге, чтобы клиентские компоненты могли находить сервер и подключаться к нему. Эта информация может включать имя сервера, конечную точку RPC, адрес IP и номер порта. Для приложений архитектуры клиент/сервер, где клиент и сервер могут разрабатываться разными производителями, важно, чтобы производитель серверных компонентов публиковал информацию о том, как клиенты могут найти информацию о привязке в активном каталоге.

· Приложения не должны хранить информацию о привязке таким образом, чтобы изменение положения серверных компонентов в сети вызывало необходимость обновления каждого клиентского компонента отдельно. Например, приложения не должны хранить информацию о привязке в текстовых файлах на клиентских машинах.

Примеры:

· Приложения в архитектуре клиент/сервер, имеющие клиентские компоненты на многих компьютерах, подключающиеся к серверу баз данных для чтения и записи.

· “Трехуровневые” приложения, имеющие клиентские компоненты на многих компьютерах, подключающиеся к серверу среднего уровня для удаленных вызовов процедур (RPC) или других удаленных запросов.

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

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

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

Ресурс	Информация о привязке	Пример
Файловая служба	Путь к общей папке в формате UNC.	\\Сервер\Общая_папка
Сервер	Имя DNS	Myserver.example.com
Служба Web	URL	http://www.microsoft.com
Служба RPC	Привязка RPC: специально закодированная информация, используемая для соединения с сервером RPC. Привязки RPC могут преобразовываться в строки и из строк с помощью функций API RPC	ncacn_ip_tcp:server.microsoft.com

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

Публикация службы – Как публиковать ресурсы в активном каталоге

Поиск в активном каталоге – Как находить ресурсы, опубликованные в активном каталоге

Расширение схемы – Как расширить схему активного каталога для хранения информации, относящейся к приложению

Б. Если клиент хранит информацию в активном каталоге, и приложение использует информацию такого типа, приложение должно иметь возможность использования ее из активного каталога.

Это относится к приложениям, использующим информацию о таких сетевых элементах как пользователи, машины или устройства. В таких случаях приложение должно иметь возможность извлечения этой информации из активного каталога. Приложение должно:

· Получить эту информацию напрямую из активного каталога или

· Если приложение поддерживает копию этой информации, оно должно обеспечивать средства синхронизации локальной копии с информацией из активного каталога. В частности, приложение должно:

· Предлагать механизм синхронизации в приложении или

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

Пример:

· Приложения, которые распечатывают отчеты с информацией о пользователях, должны перечислять пользователей путем запроса активного каталога. Приложения не должны хранить дублирующиеся списки активных пользователей Windows 2000 в базе данных, если это потребует обновления информации вручную.

2. Документирование влияния приложения на хранение и репликацию

Чтобы предоставить клиентам необходимую информацию для оценки влияния приложения на их сетевое окружение, необходимо документировать следующее:

А. Объем дискового пространства, необходимый приложению для его объектов в полных репликах.

Б. Объем дискового пространства, необходимый приложению для его объектов каталога в частичных репликах (глобальные серверы каталогов).

В. Сетевой трафик, необходимый приложению для репликации обновлений в полных репликах.

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

Подробная информация приведена ниже.

А. Объем дискового пространства, необходимый приложению для его объектов в полных репликах.

Рассмотрите использование Вашего приложения в каталоге, состоящем из одного домена, работающего на одном контроллере домена. Определите объем дискового пространства, необходимый приложению для данных каталога, т.е. ожидаемое увеличение пространства, в файле NTDS.DIT. Если увеличение связано с некоторыми параметрами (например, с числом объектов Пользователь или с выбором определенных вариантов применения приложения), определите необходимый объем как функцию этих параметров.

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

Формула должна определять верхний предел используемого пространства, и как таковая не обязательно должна быть точной. Если приложение никогда не будет использовать больше, скажем, мегабайта пространства, можно указать один мегабайт.

При оценке исходите из предположения, что срок действия по умолчанию составляет 60 дней.

Для определения пространства, используемого файлом NTDS.DIT, используйте утилиту esentutl. Не полагайтесь на размер самого файла, поскольку размер файла включает нераспределенное пространство в файле.

Чтобы воспользоваться утилитой esentutl, загрузитесь в режиме восстановления сервиса каталогов, откройте командное окно и наберите

C:> esentutl /ms /8 c:\winnt\ntds\ntds.dit

(подставив фактический путь к файлу DIT.) Используемые страницы помечаются в выходных результатах как “owned”. Размер каждой страницы - 8 k байт.

Для получения более реальных результатов можно сначала выполнить дефрагментацию в автономном режиме (в режиме восстановления сервиса каталогов запустить утилиту ntdsutil, выбрать режим “files” и запустить команду “compact to”), а затем запустить утилиту esentutl для получившегося после дефрагментации файла.

Рассмотрите использование Вашего приложения в каталоге, состоящем из двух доменов А и Б, работающего на двух контроллерах доменов. Предположим, Ваше приложение хранит все свои данные на первом контроллере, контроллере домена А. Затем эти данные реплицируются во второй контроллер - домена Б, который является глобальным сервером каталогов и поэтому содержит частичную реплику домена А.

Определите объем дискового пространства, необходимый приложению для данных каталога на втором контроллере, как в предыдущем пункте.

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

В. Сетевой трафик, необходимый приложению для репликации обновлений в полных репликах.

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

Определите сетевой трафик, необходимый приложению для репликации обновлений. Если трафик связан с некоторыми параметрами (например, с числом объектов Пользователь или с тем, сколько раз пользователями были вызваны специфичные для приложения операции), определите необходимый объем как функцию этих параметров.

Если приложение хранит данные в контейнере конфигурации, оцените репликацию контейнера отдельно от репликации домена.

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

Если сетевой трафик, генерируемый во время установки приложения, существенно отличается от трафика во время систематической работы приложения, оцените эти два варианта отдельно.

Для выполнения этого измерения используйте счетчик “Всего исходящих байт DRA с момента загрузки” в “Объекте производительности NTDS”. Поскольку это общий счетчик, нужно будет указать разницу между его значениями до и после репликации.

Рассмотрите использование Вашего приложения в каталоге, состоящем из двух доменов А и Б, работающих на двух контроллерах доменов на одной площадке. Предположим, Ваше приложение выполняет все обновления на первом контроллере, контроллере домена А, и активный каталог реплицирует некоторое подмножество этих изменений во второй контроллер - домена Б, который является глобальным сервером каталогов и поэтому содержит частичную реплику домена А.

Оцените сетевой трафик, как описано в предыдущем пункте.

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

Замечание: Если Ваше приложение записывает в каталог только небольшой фиксированный набор объектов (до 100 K байт данных) и обновляет эти объекты только в нестандартных условиях (например, только при перемещении службы с одной машины на другую), Вы можете просто указать это, не указывая более подробной информации.

3. Документирование использования приложением объектов и атрибутов базовой схемы

Приложение, использующие каталог, часто используют информацию, уже имеющуюся в каталоге; иногда они дополняют эту информацию. Для улучшения взаимодействия между приложениями клиентам необходимо понимание таких зависимостей.

Если Ваше приложение зависит от объектов каталога, которые оно не создает, необходимо документировать такие зависимости:

· Какие необязательные атрибуты приложение читает из объектов, которые оно не создает?

· Какие необязательные атрибуты приложение записывает в объекты, которые оно не создает?

Если приложение создает только свои собственные объекты каталога, это требование не применяется. Однако если Вы создаете или изменяете что-либо в контейнере конфигурации, следует полностью документировать эти операции. В этом случае необходимо указать класс объекта, причину изменения и/или дополнения и местоположение в контейнере конфигурации.

4. Информация, хранящаяся в активном каталоге, должна представлять “глобальный интерес”

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

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

5. Значения атрибутов не должны превышать 500 КБ, а общий размер объекта не должен превышать 1 МБ

Активный каталог не поддерживает потоки значений атрибутов и не подходит для очень больших данных. По этой причине максимальная длина значения атрибута, хранящегося в активном каталоге, не должна превышать 500 КБ, а размер всего объекта не должен превышать 1 МБ.

6. При расширении схемы необходимо соблюдать правила расширяемости

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

Если Ваше приложение расширяет схему активного каталога, для предотвращения таких конфликтов оно должно соблюдать правила, перечисленные в настоящем разделе. Правила подразделяются на следующие категории:

А. Установка расширения схемы

Б. Документация схемы

В. Спецификация Schema-ID-GUID

Г. Именование объектов схемы

Д. Спецификация Link ID

Более подробную информацию о расширяемости схемы можно найти в главе “Расширение схемы” Руководства программиста активного каталога.

А. Установка расширений схемы

Если для приложения требуются расширения схемы:

· Установка расширений схемы должна выполняться отдельной программой или отдельной функцией стандартной программы установки приложения.

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

Это позволяет клиентам выполнять обновление схемы отдельно от остальной установки и раньше нее.

В большинстве случаев рекомендуется вносить изменения в схему программным путем, хотя могут использоваться и другие способы, например, сценарии LDIF.

Б. Документация схемы

Расширения схемы должны быть документированы в виде корректного файла на языке extensible markup language (XML).[3] Документация должна находиться на Вашем Web-сайте. Ссылка на этот Web-сайт должна присутствовать в документации по продукту, поставляемой с приложением.

Для генерации документации о расширениях схемы в формате XML следует использовать утилиту schemadoc.exe. Эту утилиту можно найти по адресу http://msdn.microsoft.com/certification/download.asp. В качестве входного аргумента эта утилита получает имя DNS для именования элементов схемы и генерирует корректный файл XML, содержащий информацию о расширениях схемы и теги, представляющие все три вида информации, которую Вы должны предоставить.

· Описание каждого нового класса и атрибута и его использования.

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

· Предполагаемые привилегии защиты, необходимые для администрирования (создания экземпляров, внесения изменений в значения, удаления экземпляров) атрибута/класса.

Замечание: Чтобы помочь клиентам в определении влияния установки приложения в их окружении, сократить время развертывания приложения и звонки Вам по вопросам поддержки, компания Microsoft предоставляет каталог расширений схемы, созданных сертифицированными приложениями Windows 2000. Этот каталог будет содержать ссылки на документацию по схеме на Вашем web-сайте.

В. Спецификация Schema-ID-GUID

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

При расширении схемы помимо OID Вы должны указать значение атрибута schemaIDGUID в каждом объекте classSchema и attributeSchema. Это гарантирует идентичность атрибута schemaIDGUID во всех установках активного каталога.

Г. Именование объектов схемы

При задании имени схемы как для общего имени (ОИ) так и для отображаемого названия LDAP (ldapDisplayName) объектов схемы необходимо твердо придерживаться следующих правил.

· Начните с указания имени Вашей компании в нижнем регистре

· Следующим символом в ОИ должен быть дефис.

· После дефиса задайте имя атрибута или класса, уникальное для Вашей компании.

В следующей таблице приводится пример:

Название компании	Имя атрибута или класса	Общее имя (ОИ)	Имя отображения LDAP (LDAPDisplayName)
Microsoft	VoiceMailID	microsoft-VoiceMailID	microsoft-VoiceMailID

Это имя следует зарегистрировать у компании Microsoft с помощью Web-сайта: http://msdn.microsoft.com/certification/ad-registration.asp. За регистрацию необходимо будет внести номинальную плату для покрытия расходов. Регистрация завершится только после того, как Вы получите от компании Microsoft уведомление об утверждении.

Исключение:

Если у Вас есть специальные имена LDAP, уже установленные для Вашего приложения или его предшественника, это приложение может быть исключением из этого соглашения об именах, при условии, что существующие специальные имена будут зарегистрированы у компании Microsoft до 1 июня 2000г. Обратиться за этим исключением можно по адресу http://msdn.microsoft.com/certification/ad-registration.asp.

Примечание: Описанные выше требования к документации действуют по-прежнему.

Д. Спецификация Link-ID

Активный каталог поддерживает значения атрибутов, которые ссылаются на другие объекты в активном каталоге. Это обеспечивает способ представления отношений между объектами в активном каталоге. Например, члены группы связаны с объектами, которые представляют членов, или атрибут менеджера пользователя связан с объектом, представляющим менеджера пользователя. Используя связанные атрибуты, Вы можете определить, к каким группам принадлежит пользователь, или найти прямые отчеты менеджера.

Если Вам необходимы связанные атрибуты, следует получить Link-ID у компании Microsoft, используя утилиту по адресу http://msdn.microsoft.com/certification/ad-registration.asp.

Предварительное тестирование приложений для поддержки активного каталога

Предварительное тестирование корректности использования активного каталога (требование 1А)

· Установите активный каталог, запустив DCPROMO на сервере
Windows 2000.

· Установите приложение.

· Убедитесь, что клиентская часть приложения привязана к ресурсу сервера

· Измените информацию о привязке на сервере так, чтобы данные изменились, но остались верными

· Убедитесь, что клиентская часть приложения привязана к “новому” ресурсу сервера, а не к сохраненной в кэше копии “старого” ресурса

· Измените информацию о привязке в активном каталоге так, чтобы данные исказились

· Убедитесь, что клиентская часть приложения не привязана к ресурсу сервера

Предварительное тестирование приложения на способность использования информации из активного каталога (требование 1Б)

Если Вы дублируете информацию в активном каталоге и используете его как основной источник этой информации:

· Убедитесь, что Вы можете синхронизировать данные, дублированные в активном каталоге, с информацией в хранилище данных приложения ИЛИ

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

Предварительное тестирование выполнения приложением правил расширения схемы (требование 6)

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

Б. С помощью утилиты schemadoc.exe экспортируйте расширения схемы из активного каталога и убедитесь, что они совпадают с расширениями на Вашем web-сайте и завершены. Убедитесь также, что сопровождающая приложение документация содержит ссылку на этот web-сайт.

В. Установите приложение в другом лесу активного каталога и убедитесь, что schema-ID-GUID для каждого расширения схемы для обоих лесов одинаковы. Это можно сделать, сравнив документ схемы, созданный при запуске schemadoc.exe в каждом лесу.

Г. Убедитесь, что используются идентификаторы связи, полученные от компании Microsoft.

Глава 5

Службы защиты

Сводка требований защиты

Логическое обоснование

Чтобы приложения архитектуры Клиент/Сервер могли обеспечивать защищенный доступ к ресурсам и защищенное взаимодействие этих приложений, приложение должно сконфигурировать и запустить клиентские и серверные части в корректных контекстах защиты. Это обеспечивает защищенный доступ к необходимым ресурсам и предоставляет защищенный канал для взаимодействия между клиентом и сервером. Корректная конфигурация зависит от:

· Работы сервера в соответствующем контексте защиты.

· Обеспечения идентификации соединения между клиентом и сервером.

· Использования стандартных идентификаторов и дескрипторов защиты для подтверждения правильности доступа к ресурсам и данным.

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

Регистрация с одним вводом пароля (Single Sign-On - SSO) позволяет пользователям сети без проблем получать доступ ко всем авторизованным сетевым ресурсам после единственной идентификации, которая выполняется при первом входе в сеть. SSO повышает производительность работы пользователей сети, сокращает расходы на выполнение операций в сети и улучшает защиту сети.

Преимущества пользователя

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

· Запуск службы в контексте, отличном от контекста Администратора, и предоставление явных разрешений учетной записи службы для обеспечения работы определенных функций.

· Запуск службы в контексте Администратора (или Администратора Домена) и принятие риска нарушения безопасности.

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

Регистрация с одним вводом пароля (Single Sign-On - SSO) позволяет пользователям сети без проблем получать доступ ко всем авторизованным ресурсам сети после единственной идентификации, которая выполняется при первом входе в сеть. Это может привести к:

· Улучшению защиты сети. Все методы SSO, доступные в Windows 2000, обеспечивают защищенную идентификацию и предоставляют основу для шифрования пользовательской сессии с сетевым ресурсом. Сокращение количества паролей также уменьшит количество уязвимых мест в защите - пользователи обычно записывают свои пароли.

· Увеличению производительности труда пользователей. Пользователям не нужно больше запоминать многочисленные пароли для регистрации и для доступа к сетевым ресурсам. Это будет также полезно офисным работникам, которые часто забывают пароли.

· Упрощению процесса администрирования. Задачи, относящиеся к SSO, выполняются “прозрачно” как часть обычного технического обслуживания с использованием тех же инструментов, которые применяются для других административных задач.

· Улучшению административного управления. Вся информация, относящаяся к SSO, хранится в одном хранилище данных, называемом Активным каталогом. Так как все права пользователя представлены в виде отдельного главного списка, администратор может внести изменения в эти права, и внесенные изменения будут распространяться на всю сеть.

· Объединению разнородных сетей. За счет объединения разнородных сетей можно консолидировать административные меры по защите, что обеспечит постоянное совершенствование политики администрирования и корпоративной системы защиты.

Требования

1. Документирование служб, для работы которых необходимы привилегии выше уровня Пользователь

2. Клиенты Win32, работающие в контексте учетной записи доверенного домена, должны поддерживать режим регистрации с одним вводом пароля

Справочная информация

Регистрация с одним вводом пароля в сетях Windows 2000:

http://www.microsoft.com/security/Resources/SSOWhite.asp

Дополнительные материалы по защите в Windows 2000

http://www.microsoft.com/windows/server/Technical/security/

Соответствие требованиям системы защиты

1. Документирование служб, для работы которых необходимы права выше уровня Пользователь

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

Для каждой учетной записи службы, для которой требуются права выше уровня Пользователь, необходимо указать следующее:

1. Конкретные системные ресурсы, на доступ к которым у обычных Пользователей по умолчанию нет достаточных прав.

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

3. Минимальные права на ресурсы, указанные в пункте 1, которые должна иметь учетная запись службы для корректной работы.

Например:

Служба	Ресурс или Право Пользователя	Минимальные права ресурса, необходимые для службы
Факс	%systemroot%	Запись (Этот каталог, подкаталоги и файлы)
Почта	HKLM\Software\CompanyA\Mail	Запись (Этот каталог, подкаталоги и файлы)
Резервное копирование	Привилегии резервного копирования и восстановления	нет
Распространение программного обеспечения	Администратор указывает элементы для совместного использования	Чтение\Запись
Web-сервер	Служба HTTP	Остановка\Пуск
Диспетчер диска	Тома NTFS	Открытый дескриптор для изменения

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

Служба отправки факсов - Предположим, она использует каталог %systemroot% для хранения входящих факсов. Хотя для записи в каталог %systemroot% необходимы права административного уровня, у службы отправки факсов нет оснований для использования данного каталога как каталога хранения. Если хранить факсы в несистемном каталоге, права административного уровня для запуска службы не нужны.

Почта - Предположим, что службе почты необходимо загружать только некоторые параметры конфигурации из раздела HKLM\Software\CompanyA\Mail. В этом случае не нужно открывать этот раздел для записи, поэтому требование права на запись в этот раздел необоснованно.

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

ЗАМЕЧАНИЕ:

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

· Запуска службы в неадминистративном контексте и предоставления явных разрешений этой учетной записи службы для успешной работы конкретных функций.

· Запуска службы в контексте Администратор (или Администратор Домена) и принятия связанного с этим риска нарушения безопасности.

· Использования другого продукта с аналогичными функциями, который может использоваться в более защищенном контексте.

Клиенты Win32 должны корректно поддерживать регистрацию с одним вводом пароля. Это означает, что, если пользователь зарегистрирован в контексте учетной записи доверенного домена:

· Клиент не запрашивает сведения для регистрации.

· Клиент использует сведения, указанные пользователем при регистрации.

· Серверное приложение Windows 2000 идентифицирует клиента как этого пользователя.

Замечание: Допускается (а иногда предпочтительно) поддержка регистрации с использованием альтернативных сведений, которая также поддерживает регистрацию клиента с одним вводом пароля. Например, команда “net use” поддерживает параметр “/u:”, что позволяет использовать альтернативные сведения при идентификации на удаленном файловом сервере. Кроме того, оболочка Windows поддерживает возможность “Запустить как...” для запуска процесса в различных контекстах регистрации.

Подробности реализации

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

· Использование именованных каналов автоматически соответствует данному требованию.

· С помощью вызовов RPC (RpcBindingSetAuthInfo и RpcServerRegisterAuthInfo) Вы можете указать определенного провайдера идентификации. SSPI поддерживает несколько провайдеров - NTLM, Kerberos, SSL и т.д. Любой из этих провайдеров может использоваться для регистрации с одним вводом пароля. Рекомендуется использовать RPC_C_AUTHN_GSS_NEGOTIATE (для автоматического выбора Kerberos или NTLM) или RPC_C_AUTHN_GSS_SCHANNEL (для идентификации Общего ключа).

· DCOM предоставляет возможности, аналогичные RPC (CoInitializeSecurity). Подробную информацию можно найти в Windows SDK.

Если Вы не используете ни один из этих протоколов, следует использовать Интерфейс Провайдера Поддержки Системы Защиты (Security Support Provider Interface - SSPI), расположенный поверх протокола приложения. Подробную информацию можно найти в разделе Система защиты в Windows SDK.

Рекомендации по улучшению работы

Для сертификации не необходимо, но желательно, чтобы при выполнении операций от имени клиента сервер выполнял роль контекста системы защиты клиента для доступа к объектам и ресурсам, находящимся вне непосредственного подчинения сервера (например, другие локальные файлы и реестр). Это гарантирует, что для подтверждения выполнения операции используется соответствующий контекст защиты. Если сервер реализует собственную модель управления доступом для частных данных сервера, необходимости в исполнении роли клиента нет, но для определения прав на доступ должны использоваться данные об идентификации пользователя. Серверным приложениям рекомендуется использовать модель управления доступом Windows 2000 путем сохранения прав в дескрипторах защиты с помощью Win32 Private Object Security API и проверять их с помощью Win32 Access Check API.

Олицетворение клиента сервером реализуется с помощью метки доступа в подобранном контексте защиты. Для этого сервер вызывает функцию ImpersonateSecurityContext, передавая ей дескриптор контекста защиты клиента. В случае успешного вызова серверный поток, который сделал этот вызов, считается обладателем идентификационных данных клиента. Допустимость любого доступа к системным ресурсам или данным или к данным или ресурсам, поддерживаемым сервером, может проверяться с помощью стандартных дескрипторов защиты Windows 2000.

Если сервер намерен по-прежнему использовать собственный контекст защиты, он должен вызывать функцию RevertSecurityContext. Например:

// Сервер олицетворяет клиентом с использованием контекста защиты, который

// был создан в ходе обоюдной идентификации.

ImpersonateSecurityContext (pContextHandle);

// Сервер получает стандартный дескриптор защиты Windows 2000 для своего

// частного объекта с помощью серверной процедуры. Объект хранится и

// обрабатывается серверными процедурами, но Дескриптор защиты,

// связанный с данными, имеет стандартный формат Windows 2000.

MyStatus = GetObjectSD(Object,…,&SD);

// Получение метки клиента. Так как происходит олицетворение клиента,

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

Status = OpenThreadToken(…,&Token);

// Выполнить проверку доступа, используя API стандартной проверки доступа Windows 2000.

// Так как SD в частном объекте является стандартным дескриптором защиты Windows 200

// API Windows может осуществлять проверку доступа.

Status = AccessCheck( SD, Token, DesiredAccess, GenericMapping,

&PrivsUsed, &PrivLength, &GrantedAccess,

&Allowed);

// Действовать в зависимости от результата

if (Allowed) {

}

Предварительное тестирование поддержки защиты приложениями

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

1. Установите “начисто” Windows 2000 Server на диск с разделом NTFS, подключая домен согласно требованиям

2. Зарегистрируйтесь как Администратор.

3. Установите приложение.

4. Если учетная запись службы, созданная/используемая программой установки

· НЕ является локальной учетной записью системы и

· НЕ является членом группы “Администраторы” и

· НЕ является членом группы “Администраторы Домена” и

· НЕ является членом группы “Привилегированные Пользователи”,

то

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

4б. Выйдите из программы.

В противном случае перейдите к шагу 5.

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

6. При необходимости переконфигурируйте службу(ы) для работы в качестве члена группы локального Пользователя

а. Если служба сконфигурирована для работы в качестве локальной системы, используйте апплет служб[4] для их запуска в учетной записи, созданной на шаге 5.

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

7. Удалите всех членов локальной группы “Администраторы” за исключением Администратора и Администраторов Домена

8. Удалите всех членов локальной группы “Администраторы Домена”, за исключением Администратора.

9. Удалите всех членов группы “Привилегированные Пользователи”.

10. Согласно документации необходимо явным образом предоставить учетной записи пользователя, под которой работает служба, все необходимые ей права Пользователя. Если программа установки уже сделала это, необходимо проверить соответствие этих прав правам пользователя, указанным в документации ISV. Если эти права не совпадают, необходимо обновить документацию.

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

Замечание: Возможно, эта задача не будет выполнена полностью. Если учетной записи службы необходимы права, которые “жестко” даны только группе “Администраторы”, предоставить их учетной записи службы будет невозможно. К таким правам относится:

- Возможность доступа к ресурсам только ($) администратора.

- Возможность установки других служб или драйверов.

- Возможность чтения/записи драйверов устройств посредством IOCTLS

12. Убедитесь, что приложение работает корректно.

13. Если приложению требуется “жестко” назначенные административные права, например, права, указанные в замечании к шагу 11, убедитесь, что при запросе этих прав происходит ошибка работы службы.

Предварительное тестирование поддержки регистрации с одним вводом пароля

Если в серверной части приложения имеется выбор анонимной регистрации или регистрации с идентификацией, выберите регистрацию с идентификацией.

Если такого выбора нет, используйте вариант, представленный по умолчанию.

· Запустите клиента в анонимном контексте неидентифицированной учетной записи и попробуйте получить доступ к серверу. Клиент должен предложить Вам зарегистрироваться с идентификацией или запретить доступ к ресурсам.

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

Замечание: Если сервер по умолчанию допускает анонимную регистрацию, регистрацию без идентификации и отсутствует возможность разрешить только идентифицированную регистрацию, приложение не может быть сертифицировано для Windows 2000.

Глава 6

Кластерная служба

Сводка требований к кластерной службе

ЗАМЕЧАНИЕ: Эта глава является обязательной для сертификации Windows 2000 Advanced Server и Windows 2000 Datacenter Server [5] Приложения, не соответствующие этим требованиям подходят только для сертификации на Windows 2000 Server.

Логическое обоснование

Серверный кластер - это группа независимых серверов, управляемых как одна система для повышения доступности. Кластерная служба - это набор системных служб в Windows 2000 Advanced Server и Windows 2000 Datacenter Server, которые помогают Вам сформировать серверные кластеры, соединяя вместе множество серверов так, чтобы они представлялись рабочей станции как одна доступная система.

Кластерная служба может автоматически определить сбой приложения или сервера и перезапустить приложение на том же сервере, если он еще работает, или на другом сервере.

Эти требования помогут гарантировать корректную работу приложения с установленной кластерной службой, с тем чтобы:

· Ваше серверное приложение могло передаваться при сбое на другие сервера

· Клиентская часть Вашего приложения правильно обрабатывала ошибки серверной части.

Преимущества пользователя

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

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

Требования

1. Для сертификации Windows 2000 Advanced Server приложения должны быть иметь возможность установки как минимум на 2 ушла, а для Windows 2000 Datacenter Server - на 2, 3 и 4 узла.

2. Приложение должно поддерживать передачу при сбое на все члены кластера

3. Рабочие станции должны продолжать работу при сбое приложения на сервере без отказов или потери стабильности системы.

Справочная информация

Официальное издание по архитектуре кластерной службы:

http://www.microsoft.com/windows/server/Technical/management/default.asp

Кластеризация в Windows 2000 Advanced Server:
http://www.microsoft.com/ntserver/ntserverenterprise/exec/overview/Clustering/ASOverview.asp

Официальная документация по кластеризации в Windows 2000:
http://www.microsoft.com/ntserver/ntserverenterprise/exec/overview/clustering/default.asp

Информация по написанию ресурсных DLL:
http://www.microsoft.com/ntserver/ntserverenterprise/techdetails/moreinfo/ClustAwareApps.asp

“О кластерах серверов” в Platform SDK:

http://msdn.microsoft.com/isapi/msdnlib.idc?theURL=/library/psdk/mscs/cs_about_2var.htm

Общая информация:

In Search of Clusters, Gregory F. Pfister, ISBN: 0-13-437625-0. Отличное введение в технологию кластеризации, включая описание общих программных моделей.

Соответствие требованиям к кластерной службе

1. Для сертификации Windows 2000 Advanced Server приложения должны иметь возможность установки как минимум на 2 узла, для Windows 2000 Datacenter Server - на 2, 3 и 4 узла.

Для прохождения сертификации Windows 2000 Advanced Server приложения должны устанавливаться на 2 узла.

Для прохождения сертификации Windows 2000 Datacenter Server приложения должны устанавливаться на 2, 3 и 4 узла.

Замечание: При установке приложения не должно предполагаться определенное число узлов в кластере. Программа установки должна определить число узлов в кластере и позволить выполнить установку на любую машину, даже если диски, где хранятся данные вашего приложения, физически на ней не располагаются.

2. Приложения должны обеспечивать резервирование на все узлы кластера

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

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

Замечание: Кластерная служба работает в архитектуре “shared nothing”, в которой каждый сервер имеет свои собственные дисковые ресурсы. В случае сбоя сервера принадлежность кластерного диска передается от одного сервера другому. Для корректной поддержки приложением передачи при сбое данные приложения должны храниться на кластерном диске.

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

Все клиенты, поставляемые с Вашим серверным приложением, должны корректно обрабатывать сбои узлов кластера и сбои приложения. Сбои кластера и приложения могут вызвать временную потерю связи клиента с серверным приложением (см. ниже). Клиент должен продолжать работу при неисправности серверного приложения или при сбое узла следующим образом:

· Если потеряна связь с серверным приложением, клиентское приложение не должно выходить из строя или влиять на стабильность работы операционной системы клиента.

· По окончании переноса и перезапуска приложения в другом узле кластера клиент должен заново подключиться к кластеру, используя один из следующих механизмов:

1. Восстановить подключение без вмешательства пользователя и без потери данных, ИЛИ

2. Предложить пользователю возможность подключиться заново и повторить неудавшуюся операцию, например, предложить пользователю обновить данные клиента.

· Если серверное приложение не может перезапуститься, клиент должен уведомить пользователя о невозможности восстановления соединения.

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

· Приложение выходит из строя, а затем перезапускается в том же узле.

· Приложение выходит из строя, а затем перезапускается в новом узле.

· Узел выходит из строя, и все ресурсы переносятся в новый узел.

· Администратор перемещает группу ресурсов, включающую это приложение, в новый узел

· Администратор выключает серверное приложение

· Вышли из строя все узлы в кластере

· Прервано сетевое соединение клиента с кластером, даже хотя кластер и сетевое приложение все еще работают.

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

Принципы разработки:

Приведенные в этом разделе принципы не являются требованиями и не будут специально проверяться при сертификации. Однако следование этим принципам поможет обеспечить соответствие описанным выше требованиям.

1. Используйте протокол TCP/IP

Службы, взаимодействующие с клиентами (и их клиенты), должны использовать протокол TCP/IP, чтобы использовать преимущества передачи по IP-адресу при сбое, обеспечиваемые кластерной службой. Серверы, не взаимодействующие с клиентами, могут не использовать TCP/IP.

2. Для соединения с узлом, на котором располагается серверное приложение, приложения должны использовать имя виртуального сервера и адрес IP.

Чтобы поддерживать передачу при сбое, клиенты, взаимодействующие с ресурсами кластера, должны использовать IP-адрес виртуального сервера или сетевое имя виртуального сервера.

Если серверное приложение публикует сетевое имя или адрес IP для клиентов, оно должно публиковать IP-адрес или сетевое имя виртуального сервера. Серверное приложение, зависящее от имени компьютера или адреса IP, для доступа к этому приложению должно использовать сетевое имя и/или IP-адрес виртуального сервера, используемого клиентами. Серверное приложение не должно давать сбой при перезапуске в другом узле из-за другого имени компьютера этого узла.

В следующем примере кода демонстрируется, как установить среду серверного приложения в виде части оперативной процедуры ресурсной dll.

// Создайте новую среду с имитированным сетевым именем при

// запросе службами функции GetComputerName.

if ( ! ClusWorkerCheckTerminate( pWorker ) )

{

nStatus = ResUtilSetResourceServiceEnvironment(

YOUR_SERVICE_NAME,

pResourceEntry->hResource,

g_pfnLogEvent,

pResourceEntry->hResourceHandle

);

if ( nStatus != ERROR_SUCCESS )

{

break;

} // в случае ошибки установки среды для службы

}

О передаче по адресу IP при сбое:

Для доступа к службам, выполняемым на кластерном сервере Windows 2000, клиентские приложения используют IP-адрес виртуального сервера. Виртуальный сервер - это группа ресурсов кластера, содержащая адрес IP и сетевое имя. Виртуальный сервер может выполняться на любом узле в кластере, однако клиентам, обращающимся к нему, он представляется как одна и та же физическая машина.

IP-адрес виртуального сервера должен быть сконфигурирован как кластерный ресурс в той же группе ресурсов, где было создано серверное приложение. В случае сбоя в узле все группы ресурсов, выполняющиеся в нем, перемещаются на другой узел кластера. Теперь IP-адрес виртуального сервера доступен на другой машине, и все соединения с клиентами могут быть восстановлены.

3. При сбое рабочие станции должны сохранять данные пользователя

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

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

4. Местонахождение данных приложения должно быть изменяемым

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

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

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

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

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

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

7. По крайней мере один экземпляр приложения может выполняться как кластерный ресурс

Кластерная служба управляет приложениями как кластерными ресурсами. Кластерный ресурс - это физический или логический объект, который может принадлежать узлу, использоваться в оперативном режиме и работать автономно, перемещаться между узлами, и которым можно управлять как объектом кластера сервера. Ресурс всегда может принадлежать только одному узлу. Ресурс связан с типом ресурса и управляется им.

Если ресурс поддерживает кластерную службу, она может управлять несколькими экземплярами одного и того же ресурса, но приемлема и поддержка только одного экземпляра.

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

8. Возможность конфигурирования по крайней мере как общей службы или приложения

Возможности мониторинга и перемещения приложения при сбое кластерной службы могут быть расширены для поддержки любого приложения. Кластерная служба использует библиотеки DLL ресурсов для распространения поддержки перемещения приложения при сбое на другие типы ресурсов.

Приложения, не имеющие библиотеки DLL ресурса, специализированной для приложения, могут по-прежнему использовать преимущества кластеризации путем использования общего приложения или общего типа ресурса службы. Такие типы ресурсов предлагают защиту перемещения приложения при сбое от большинства неисправностей, особенно от сбоев в работе узла. Однако они не могут обнаружить сбои в работе Вашего приложения. Если Ваше приложение “зависает” или происходит сбой в его работе, кластерная служба не сможет обнаружить эту неисправность и либо выполнит перезапуск приложения, либо переместит это приложение на другой узел.

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

Предварительное тестирование приложений на соответствие требованиям кластерной службы

Проверка того, что приложение действительно подготовлено для работы с кластерами.

Если программе установки приложения поддерживает кластеризацию, используйте ее для конфигурирования всех узлов.

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

Для сертификации Datacenter повторите эту процедуру для конфигураций из 3 и 4 узлов.

Проверка того, что приложение поддерживает перемещение на другой узел в случае сбоя

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

2. Вызовите сбой в работе узла, на котором выполняется приложение таким образом, чтобы произошло перемещение приложения на другой узел. Ниже предлагаются способы инициирования неисправности:

a. Сбой в работе оборудования - инициируется путем жесткой
перезагрузки

б. Сбой ОС - вызывается путем выдачи команды Ctrl+C, после
которой следует команда “.reboot” от удаленного отладчика ядра.

в. Сбой в работе приложения – имитируется с помощью функции
Конец процесса в Диспетчере задач или Программе просмотра
процессов (Pview.exe в Windows SDK).

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

3. Убедитесь, что приложение перезапускается на новом узле в кластере.

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

5. Для проверки для сертификации Datacenter повторите шаги 2 - 4, чтобы убедиться, что приложение последовательно перемещается по всем остальным узлам.

Проверка того, что клиенты преодолевают сбой и последующую перезагрузку серверного приложения

Инициируйте сбой в работе серверного приложения по одному из следующих сценариев.

1. Отключите серверное приложение обычным способом и оставьте все узлы в кластере в рабочем состоянии.

2. Прервите работу приложения (не используйте обычную последовательность отключения), но оставьте узлы в рабочем состоянии

3. Отключите узел. Замечание: Не используйте обычный способ отключения. Данный узел и приложение не должны иметь времени для постепенного прекращения работы. Ниже приведены приемы для различных режимов сбоев:

а. Сбой в работе оборудования - инициируется путем жесткой
перезагрузки

В каждом случае

· Убедитесь, что не произошел сбой в работе клиента, и работа клиента во время сбоя в работе серверного приложения стабильна.

· После перезагрузки серверного приложения на том же самом узле или на другом узле убедитесь, что клиент:

· Восстановил подключение без вмешательства пользователя и без
потери данных, ИЛИ

· Выдал пользователю запрос повторить попытку восстановления
подключения, а затем приложение установило подключение.

Замечание: если необходимо вручную сконфигурировать клиента для доступа к серверному приложению, сконфигурируйте его для использования виртуального сервера, а не имени узла.

Проверка того, что клиенты преодолевают состояние сбоя без последующей перезагрузки серверного приложения

1. Инициируйте сбой приложения таким образом, чтобы приложение не смогло перезапуститься в кластере. Для этого Вы можете отключить ресурс или оба узла.

2. Убедитесь, что клиенты работают стабильно и без сбоев.

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

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

Приложение А

Рекомендации по улучшению работы

Важно: Соответствие перечисленным в этом приложении принципам не обязательно для признания приложения соответствующим спецификации для Windows 2000, но настоятельно рекомендуется для улучшения работы пользователей.

A-1 Для установки приложения в Windows 2000 не должна требоваться перезагрузка

A-2 Для получения путей к специальным папкам следует использовать функцию SHGetFolderPath

A-3 Приложение должно быть протестировано со Службами терминала

A-4 Глобализация

A-5 Возможность локализации

A-6 Использование 64-разрядных совместимых типов данных

A-7 Дополнительная информация относительно кластерной службы

A-8 Инструменты управления Windows

A-9 Обеспечение встраиваемых модулей MMC для средств управления

A-10 Демонстрация модели сценариев на базе COM

A-11 Использование COM+ для распределенных приложений

A-12 Выполнение без NetBIOS в окружении только Windows 2000

A-1 Для установки приложения в Windows 2000 не должна требоваться перезагрузка

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

· Пакет обновления операционной системы.

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

Вообще перезагрузка Windows 2000 не должна требоваться, даже если в системе выполняются приложения. В прошлом основная причина перезагрузки заключалась в том, что приложение заменяло файл, который в это время использовался. Однако в Windows 2000, если придерживаться данной спецификации, число таких ситуаций будет существенно сокращено с помощью Защиты файлов Windows (WFP):

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

Кроме того, приложениям, использующим службу Windows Installer, вряд ли понадобится перезагрузка. Служба Windows Installer автоматически проверит, не используются ли обновляемые файлы другими приложениями или обслуживающими процессами. В этих случаях Windows installer предложит пользователю прекратить работу приложений, использующих эти файлы. Если пользователь сделает это, приложение будет установлено без перезагрузки. Если пользователь не закроет приложение, Windows Installer выдаст запрос на перезагрузку.

По результатам отзывов пользователей рекомендуется, ЧТОБЫ ПЕРЕЗАГРУЗКА ВЫПОЛНЯЛАСЬ ТОЛЬКО В ТОМ СЛУЧАЕ, ЕСЛИ ОНА ДЕЙСТВИТЕЛЬНО НЕОБХОДИМА.

A-2 Для получения путей к специальным папкам следует использовать функцию SHGetFolderPath

При обращении к любой из специальных папок, перечисленных в следующем списке, приложение должно использовать Win32 API для динамического получения корректных названий папок в зависимости от языка. Предпочтительным способом является использование функции SHGetFolderPath API и соответствующей константы CSIDL. Эта функция выполняется одинаково в Windows 95, Windows 98, Windows NT 4.0 и Windows 2000. Она поставляется с библиотекой SHFOLDER.DLL. Продавцам программного обеспечения настоятельно рекомендуется как можно более активно распространять этот компонент с целью обеспечения такой поддержки в операционных системах Windows версий, предшествующих Windows 2000. Windows 2000 включает эту библиотеку DLL в виде защищенного системного файла, поэтому ее невозможно заменить в Windows 2000 или более поздних версиях.

Замечание: Чтобы гарантировать работу приложения в Windows 9x, Windows NT 4 и Windows 2000, всегда устанавливайте связь с реализацией функции SHGetFolderPath в библиотеке SHFOLDER.DLL., Windows 2000 реализует функцию SHGetFolderPath из библиотеки SHELL32.DLL, но другие версии Windows не содержат функции SHGetFolderPath в библиотеке SHELL32.DLL.

Стандартная папка	Имя константы CSIDL
Альтернативный запуск ([пользователь], DBCS)	CSIDL_ALTSTARTUP
Папка альтернативного запуска (профиль Все пользователи, DBCS)	CSIDL_COMMON_ALTSTARTUP
Данные приложения (профиль [пользователь])	CSIDL_APPDATA
Данные приложения (профиль Все пользователи)	CSIDL_COMMON_APPDATA
Виртуальная папка Панели управления	CSIDL_CONTROLS
Папка файлов cookie	CSIDL_COOKIES
Рабочий стол (корень пространства имен)	CSIDL_DESKTOP
Папка Рабочего стола (профиль [пользователь])	CSIDL_DESKTOPDIRECTORY
Папка Рабочего стола (профиль Все пользователи)	CSIDL_COMMON_DESKTOPDIRECTORY
Папка предпочтений (профиль [пользователь])	CSIDL_FAVORITES
Папка предпочтений (профиль Все пользователи)	CSIDL_COMMON_FAVORITES
Виртуальная папка шрифтов	CSIDL_FONTS
Папка журнала	CSIDL_HISTORY
Папка кэша Интернет	CSIDL_INTERNET_CACHE
Виртуальная папка Интернет	CSIDL_INTERNET
Локальное (неперемещаемое) хранилище данных для приложений	CSIDL_LOCAL_APPDATA
Виртуальная папка Мой компьютер	CSIDL_DRIVES
Папка Мои изображения	CSIDL_MYPICTURES
Каталог Сетевое окружение	CSIDL_NETHOOD
Корень Сетевого окружения	CSIDL_NETWORK
Персональная папка (профиль [пользователь])	CSIDL_PERSONAL
Виртуальная папка Принтеры	CSIDL_PRINTERS
Папка PrintHood (профиль [пользователь])	CSIDL_PRINTHOOD
Папка Program Files	CSIDL_PROGRAM_FILES

Стандартная папка	Имя константы CSIDL
Папка Program Files для приложений x86 в системах Alpha	CSIDL_PROGRAM_FILESX86
Папка Программы (в меню Пуск в профиле [пользователь])	CSIDL_PROGRAMS
Папка Программы (в меню Пуск в профиле Все пользователи)	CSIDL_COMMON_PROGRAMS
Папка Недавно использовавшиеся (профиль [пользователь])	CSIDL_RECENT
Папка Урна	CSIDL_BITBUCKET
Папка Отправить (профиль [пользователь])	CSIDL_SENDTO
Меню Пуск (профиль [пользователь])	CSIDL_STARTMENU
Меню Пуск (профиль Все пользователи)	CSIDL_COMMON_STARTMENU
Папка Автозагрузка (профиль [пользователь])	CSIDL_STARTUP
Папка Автозагрузка (профиль Все пользователи)	CSIDL_COMMON_STARTUP
Папка System	CSIDL_SYSTEM
Папка System для приложений x86 в системах Alpha	CSIDL_SYSTEMx86
Папка Шаблоны (профиль [пользователь])	CSIDL_TEMPLATES
Папка профиля пользователя	CSIDL_PROFILE
Каталог Windows или SYSROOT	CSIDL_WINDOWS

A-3 Приложение должно быть протестировано со Службами терминала

Многие корпоративные клиенты используют Службы терминала для обеспечения наличия приложений Windows 2000 на ряде рабочих столов и у мобильных клиентов. Приложения, работающие со службами терминала, выполняются только на сервере. Клиент сервера терминала не выполняет локальной обработки приложений. Это означает, что в среде служб терминала несколько экземпляров одного приложения могут работать на одной и той же машине в одно и то же время, обслуживая различных пользователей.

Рекомендации для разработчиков

Поскольку несколько пользователей выполняют приложение одновременно, крайне важна корректность хранения данных приложения и пользователя. Более подробную информацию можно найти в Главе 4, “Управлением данными и установками” в Спецификации настольных приложений.

В среде Служб терминала несколько экземпляров приложения будут выполняться на одной и той же машине. Файлы .EXE и .DLL приложения должны быть написаны так, чтобы несколько пользователей могли выполнять это приложение на одной и той же машине в одно и то же время. Рекомендации:

· Блокировка файлов: Во время использования файлы не должны блокироваться, поскольку это может помешать запуску нескольких экземпляров приложения или процессов приложения, например, мастеров.

· Доступ к файлам: Пользователи не могут получать доступ к системным файлам и не могут иметь тот же уровень доступа, что и администратор, установивший приложение.

· Местоположение файлов: Данные пользователей и файлы конфигурации должны храниться отдельно во избежание противоречий и управления правами. В частности, приложения должны хранить временную информацию для каждого отдельного пользователя во избежание конфликтов между информацией и настройками пользователей. Это следует делать с помощью функции API GetTempPath, а не жестко закодированного пути.

Службы терминала управляют объектами для отдельных клиентов. Вам нужно самостоятельно реализовывать управление объектами, только если Вы не хотите, чтобы это делала операционная система. Если определенный объект должен быть доступен всем экземплярам приложения, зарегистрируйте файл .DLL или .EXE, который создает этот объект, с помощью команды “register имя_файла /system” или измените приложение так, чтобы в начале имени объекта при создании присоединялась строка Global\ (в языке C - строка “Global\\”).

Руководство по предварительному тестированию

1. Установите компьютер с Windows 2000 Server как хост сервера терминала и сконфигурируйте его для административного и неадминистративного доступа.

2. Установите приложение на машине, зарегистрировавшись как Администратор.

· Приложение должно быть установлено в режиме установки сервера терминала. Используйте командную строку “change user /install” или пункт Установка/удаление программ в Панели управления. Сервер терминала должен соответствующим образом управлять реестром для каждого пользователя. Кроме того, для коррекции настроек файла и реестра для нескольких пользователей может понадобиться сценарий. См. документ “Использование и разработка сценариев для совместимости приложений”.

3. На отдельной клиентской машине зарегистрируйтесь на хосте сервера терминала с привилегиями обычного пользователя (непривилегированного и не администратора).

4. Убедитесь, что этому пользователю доступны все сочетания клавиш, файлы и папки.

5. Запустите каждую программу в приложении.

6. Выполните весь набор тестов на функциональность приложения.

7. Настройте для пользователя интерфейс, параметры файлов и новые параметры по умолчанию.

8. Зарегистрируйтесь как другой пользователь и убедитесь, что изменения настроек, сделанные для первого пользователя, не являются новыми настройками по умолчанию для нового пользователя.

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

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

Диагностика общих проблем

· Если при работе в качестве пользователя, не имеющего прав администрирования, возникли проблемы, попытайтесь воспроизвести проблему на консоли сервера Служб терминала в качестве того же пользователя. Если проблема не повторяется, это означает, что приложение использует системный ресурс или конфигурацию. В консольной сессии имеются все системные процессы, такие как SMSS.exe, RPCSS.exe, SERVICES.exe и LSASS.exe, а также связанные с ней службы Windows 2000.

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

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

Справочная информация

Оптимизация приложений для Служб терминала Windows 2000 и Windows NT Server 4.0, Terminal Server Edition
http://www.microsoft.com/windows/server/Technical/terminal/TSAppDev.asp

Понятия и использование API для Terminal Server:
http://www.microsoft.com/ntserver/terminalserver/techdetails/prodarch/api.asp

Использование и разработка сценариев совместимости приложений:
http://www.microsoft.com/ntserver/terminalserver/techdetails/prodarch/AppCompSc.asp

A-4 Глобализация

Глобализация – это практика разработки и применения программного обеспечения, не зависящего от географического региона применения, т.е. работающего с любыми региональными настройками. В разработке программного обеспечения региональные настройки – это набор настроек пользователя, связанных с языком. Региональные настройки в Windows 2000 включают форматы для даты, времени, валюты и чисел; правила и таблицы сортировки и сравнения; а также таблицы классификации символов.

В число прочих настроек, с которыми должно работать глобализованное приложение, входят язык интерфейса пользователя, выбор шрифтов по умолчанию, правила языка для использования при проверке орфографии и грамматики, а также методы ввода, такие как раскладки клавиатуры и редакторы способа ввода. Подробнее см. по адресу http://www.microsoft.com/globaldev.

Рекомендации по разработке глобализованного приложения:

· В качестве кодировки для представления текста используйте Unicode. Если приложение должно работать и под Windows 9x, выберите способ использования Unicode на этих платформах, как описано в статьях Microsoft Systems Journal в номерах за ноябрь 1998 и апрель 1999 гг. Эти статьи можно найти по адресам:

http://www.microsoft.com/globaldev/articles/singleunicode.asp

http://www.microsoft.com/globaldev/articles/multilang.asp

Если Вы не можете использовать Unicode, нужно будет реализовать такие функции как включение DBCS, включение BiDi, переключение кодовых страниц и теги текстов. Принципы, относящиеся к этим функциям, можно найти по адресу www.microsoft.com/globaldev.

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

· Для обработки данных, использующих региональные настройки, используйте функции Win32 API NLS.

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

· Используйте Script API (Uniscribe) для расположения форматированного текста на странице. Благодаря этому Ваше приложение сможет отображать многоязыковой текст и сложные языки, такие как арабский, иврит, хинди, тамильский и тайский.

· Протестируйте приложение в следующих сценариях:

· Когда системные региональные настройки, региональные настройки пользователя, входные региональные настройки и язык интерфейса пользователя имеют разные значения, не совпадающие с языком локализации приложения

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

· С новыми региональными настройками Windows 2000 (например, хинди)

· Когда в языке интерфейса пользователя используется направление справа налево, например, с арабским языком.

· Для приложения клиент/сервер, где у клиента и сервера различные региональные настройки

· Изменив региональные настройки пользователя с помощью пункта Региональные настройки (возможно более необычные)

A-5 Возможность локализации

В отличие от глобализации, локализация – это процесс изменения приложения таким образом, чтобы интерфейс пользователя был представлен на языке пользователя. Хорошо разработанное программное обеспечение можно локализовать на любой из языков, поддерживаемых Windows 2000, без изменения исходного кода, т.е. без перекомпиляции. Помимо принципов глобализации, принципы локализации включают следующие:

· Изолируйте все элементы интерфейса пользователя от исходного кода программы. Поместите их в файлы ресурсов, файлы сообщений или приватные базы данных.

· Используйте одни и те же идентификаторы ресурсов за все время существования проекта. Смена идентификаторов затрудняет обновление локализованных ресурсов после повторной сборки проекта.

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

· Не помещайте в ресурсы строки, которые не должны локализоваться. Оставьте их в исходном коде в виде строковых констант.

· Динамически распределяйте текстовые буферы, поскольку размер строки при переводе может увеличиться. Если Вам необходимо использовать статические буферы, сделайте их очень большими, чтобы не было проблем с локализованными строками (например, вдвое больше, чем для английского языка).

· Помните, что размеры диалогов при локализации могут увеличиваться. Таким образом, большое диалоговое окно, занимающее весь экран в режиме с низким разрешением, может при локализации принять невозможные размеры.

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

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

· Не составляйте текст с помощью нескольких параметров вставки в форматированную строку (например, в функциях sprintf или wsprintf), поскольку порядок вставки аргументов при переводе на некоторые языки изменяется.

· При локализации на языки Среднего Востока, такие как арабский и иврит, используйте API для направления текста справа налево. Подробнее см в статье в номере Microsoft Systems Journal за апрель 1999 г. по адресу http://www.microsoft.com/globaldev/articles/singleunicode.asp.

· Тестируйте локализованные приложения во всех языковых вариантах Windows 2000. Если в приложении используется кодировка Unicode, как рекомендуется, оно должно работать без изменения. Если в приложении используется кодовая страница Windows, нужно будет изменить региональные настройки системы и указать соответствующие значения для локализованного приложения, а затем перезагрузить машину.

A-6 Использование 64-разрядных совместимых типов данных

Разработчики могут использовать один исходный код для приложений для Win32 и Win64™. Компания Microsoft обеспечивает такую поддержку путем ввода новых типов данных в Platform SDK для Windows 2000.

Имеется три класса новых типов данных: типы данных с фиксированной точностью, с точностью указателя и с определенной точностью. Эти типы добавлены в среду Windows (точнее, в файл Basetsd.h) для обеспечения разработчикам возможности подготовки к 64-разрядной системе Windows до ее распространения. Эти новые типы унаследованы от основных типов целое и длинное языка C и поэтому работают и в существующем коде. В связи с этим следует использовать эти типы данных в коде уже сейчас, тестировать код как приложение Win32 и перекомпилировать его как приложение Win64, когда будет выпущена 64-разрядная система Windows.

Тип с фиксированной точностью

Типы данных с фиксированной точностью в программировании имеют одинаковую длину для Win32 и Win64. Для простоты запоминания точность включается в название типов данных. Ниже перечислены типы данных с фиксированной точностью.

Тип	Определение
DWORD32	32-разрядное беззнаковое целое
DWORD64	64-разрядное беззнаковое целое
INT32	32-разрядное знаковое целое
INT64	64-разрядное знаковое целое
LONG32	32-разрядное знаковое целое
LONG64	64-разрядное знаковое целое
UINT32	Беззнаковое INT32
UINT64	Беззнаковое INT64
ULONG32	Беззнаковое LONG32
ULONG64	Беззнаковое LONG64

Тип с точностью указателя

Поскольку разрядность указателей изменяется (т.е. указатели имеют 32 разряда в коде Win32 и 64 в коде Win64), эти типы данных соответственно отражают ее. При выполнении арифметических операций с указателями их можно свободно преобразовывать в один из этих типов; если разрядность указателя составляет 64 бита, тип будет 64-разрядный. Исчисляемые типы также отражают максимальный размер, на который может указывать указатель. Ниже перечислены типы точности указателей и исчисляемые типы.

Тип	Определение
DWORD_PTR	Тип беззнаковое целое для точности указателя.
HALF_PTR	Половина размера указателя. Используется в структурах, содержащих указатель и два небольших поля.
INT_PTR	Тип знаковое целое для точности указателя.
LONG_PTR	Тип знаковое длинное для точности указателя.
SIZE_T	Максимальное число байт, на которое может указывать указатель. Используется для счета, который может занимать весь диапазон указателя.
SSIZE_T	Знаковый тип SIZE_T.
UHALF_PTR	Беззнаковый тип HALF_PTR.
UINT_PTR	Беззнаковый тип INT_PTR.
ULONG_PTR	Беззнаковый тип LONG_PTR.

Типы с определенной точностью указателя

Кроме того, теперь существуют новые типы, которые явно устанавливают размер указателя. Будьте осторожны при использовании 64-разрядного кода: Если Вы объявите указатель с использованием 32-разрядного типа, система создаст его путем усечения 64-разрядного указателя. (Все указатели на 64-разрядной платформе имеют разрядность 64).

Тип

Определение

POINTER_32

32-разрядный указатель. В 32-разрядной системе это “родной” указатель. В 64-разрядной системе это усеченный 64-разрядный указатель.

POINTER_64

64-разрядный указатель. В 64-разрядной системе это “родной” указатель. В 32-разрядной системе это 32-разрядный указатель, дополненный знаком.

Обратите внимание, что предположение определенного состояния старшего бита указателя может вызвать ошибки.

Более подробную информацию Вы можете найти в Microsoft Platform SDK или по адресу: http://msdn.microsoft.com/library/psdk/buildapp/64bitwin_410z.htm

A-7 Дополнительная информация относительно кластерной службы

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

1. Не используйте системный реестр для хранения больших структур данных или часто изменяющихся данных

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

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

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

2. Подготовьте приложение (создайте специальную библиотеку DLL ресурсов) для улучшенного контроля и обнаружения сбоев

Для защиты приложения от сбоев программного обеспечения типа зависания и медленного реагирования следует предусмотреть библиотеку DLL ресурсов, расширяющую возможности кластерной службы в области контроля и обнаружения сбоев Вашего приложения.

3. Поддержка нескольких экземпляров одного и того же типа ресурса кластера

Для полного использования емкости всех узлов в кластере Ваше приложение должно поддерживать режим активный/активный, когда несколько экземпляров приложения могут сосуществовать в одном кластере.

Возможность перемещения при сбое вперед и назад активный/активный позволяет двум различным экземплярам типа ресурса работать в разных узлах, при этом каждый экземпляр работает с разными наборами данных, располагающимися на различных дисках на общей шине SCSI. (Это означает, что, хотя данные и не являются общими, этот тип ресурса активен в обоих узлах. По определению может существовать только один экземпляр ресурса; однако может быть несколько экземпляров типа ресурса.) Если экземпляр типа ресурса дает сбой на одном узле, он перемещается на следующий доступный узел. Например, если тип Вашего ресурса - приложение для управления базами данных, копию ресурса этого типа можно запустить в каждом узле. Затем Вы можете определить конкретную базу данных (db1) в виде ресурса. Поддержка режима активный/активный позволяет перемещать db1 из узла 1 в узел 2, сообщая приложению для управления базами данных в каждом узле о необходимости освободить или получить базу данных соответственно. Такое взаимодействие не может происходить с ресурсами типа общего приложения или сервиса.

4. Поддержка последовательного обновления Windows 2000 и приложения

Время, затрачиваемое на плановые обновления операционной системы и приложения, можно минимизировать за счет выполнения последовательного обновления.

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

Поддержка последовательного обновления операционной системы осуществляется кластерной службой. Однако Вы несете ответственность за обеспечение корректного функционирования Вашего приложения во время последовательного обновления. Вы также ответственны за поддержку такого обновления Вашего приложения.

5. Поддержка “комбинированного” ресурса, если в одном кластере может быть установлено много экземпляров одного и того же ресурса

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

Если Ваше приложение поддерживает режим активный/активный, и кластер может быть сконфигурирован так, чтобы содержать большое количество ресурсов этого типа приложения, рекомендуется разработать библиотеку DLL ресурсов для контроля и обнаружения сбоев всех экземпляров Вашего приложения, использующих один “комбинированный” ресурс.

6. Управляющий компонент приложения должен обнаруживать кластерную установку и использовать для запуска/останова приложения корректные функции API кластера

Поскольку приложение находится под управлением кластерной службы, оно не должно использовать для запуска/останова служб, сконфигурированных как кластерные приложения, API диспетчера управления службой.

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

Для определения того, установлена ли и используется ли в конкретном узле кластерная служба, используйте функцию API GetNodeClusterState.

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

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

Приложения с поддержкой кластеров считаются трудными в установке и управлении. Приложение с поддержкой кластеров должно поставляться с программой установки, максимально упрощающей процесс установки приложения и поддерживающей следующие сценарии:

· Полная установка во всех узлах кластера

· Надежная переустановка и восстановление в одном узле

· Установка приложения в только что добавленный узел

· Надежная и полная установка приложения в узле, выделенном из кластера

Программа установки приложения с поддержкой кластеров должна выполнять следующие действия:

· Обнаружить кластер. Обратиться к функции GetNodeClusterState.

· Перечислить все узлы кластера Обратиться к функциям ClusterNodeOpenEnum, ClusterNodeEnum, ClusterNodeCloseEnum

· Установить приложение во всех доступных узлах и запланировать установку в недоступных на данный момент узлах. Для определения состояния узла обратиться к функции GetClusterNodeState.

· Установить библиотеку DLL ресурсов приложения во всех узлах и зарегистрировать новый тип ресурса в кластере с помощью функции API CreateClusterResourceType.

· Зарегистрировать библиотеку DLL расширения администрирования кластера в кластере с помощью функции API DllRegisterCluAdminExtension.

· Опубликовать библиотеки DLL расширения администратора кластера в хранилище класса, чтобы они были доступны на любой рабочей станции, на которой будет работать администратор кластера.

· Сконфигурировать кластер, добавить и сконфигурировать новые ресурсы.

Кроме того, она должна удовлетворять следующим требованиям:

· Транзакционная установка: если установка во всех выбранных узлах не завершена, программа установки с поддержкой кластеров должна иметь возможность без ошибки вернуться к ранее установленной версии приложения.

· Поддержка автоматического режима.

8. Обеспечение возможности удаленного администрирования

Приложение должно поддерживать удаленное администрирование.

A-8 Инструментарий управления Windows

Инструментарий управления Windows (Windows Management Instrumentation, WMI) - это ключевой компонент служб управления Microsoft Windows. WMI обеспечивает согласованную и полностью описательную модель конфигурационных, статусных и операционных аспектов приложений и систем. WMI базируется на общей информационной модели (Common Information Model, CIM) распределенного управления задачами (Distributed Management Task Force, DMTF) и поддерживает унифицированное управление системой, устройствами и приложениями в операционных системах Windows.

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

Предлагаемое соответствие

1. Доступ к данным управления через WMI

2. Предоставление данных управления WMI

3. Соответствие правилам расширения пространства имен CIMV2

4. Соответствие правилам определения зависящих от поставщика пространств имен

Преимущества пользователя

Использование WMI в продуктах дает пользователям следующие преимущества:

· Продукты для управления и управляемые продукты строятся на повсеместно принятых стандартах управления.

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

· Решения для “прозрачного” управления как локальными, так и удаленными системами и приложениями через общую инфраструктуру управления на базе операционной системы.

Информация о реализации

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

1. Доступ к данным управления через WMI

WMI обеспечивает доступ к широкому спектру системной управляющей информации Windows посредством пространства имен CIMV2, расширения схемы CIM для Win32. С помощью WMI приложение получает доступ к различным объектам управления, включая данные Win32, Монитора производительности, реестра, службы Windows Installer, активного каталога и протоколирования событий.

Если в Вашем продукте используются функции управления и данные, предоставляемые системой и/или другими продуктами, и доступ к этим данным можно получить через пространство имен CIMV2, для доступа к управляющей информации вместо функций API этот продукт должен использовать WMI.

2. Предоставление данных управления WMI

Если в Вашем продукте имеются управляющие функции и данные, позволяющие осуществлять управление или контроль продукта другими приложениями для управления, доступ к ним должен даваться через WMI в соответствии со следующими рекомендациями (подробности разработки и правила расширения схемы см. в WMI SDK по адресу http://msdn.microsoft.com/developer/sdk/wmisdk):

· Следует использовать или расширять существующие классы CIM в пространстве имен CIMV2 или создавать другое пространство имен с новыми классами, представляющее функции и данные управления.

· Правила расширения пространства CIMV2 описаны в WMI SDK (ранее назывался WBEM SDK).

· В случаях, когда добавление новых классов или экземпляров в пространство CIMV2 использовать нельзя (в соответствии с документацией SDK), должно быть создано новое пространство имен.

· Обеспечение экземпляров для вновь определенных классов. Это можно сделать с помощью статических экземпляров, определенных в файле формата управляемого объекта (Managed Object Format, MOF), или динамических экземпляров, генерируемых во время исполнения провайдером WMI. Если экземпляры предоставляются с помощью файла MOF, поставщик отвечает за компиляцию файла MOF компилятором WMI MOF во время установки продукта.

· Если продукт генерирует события, должен быть реализован провайдер событий. Провайдер событий отправляет уведомления о событиях в WMI, который затем передает их в приложения, зарегистрированные для получения этих событий. Рекомендации по реализации провайдеров событий включены в документацию WMI SDK.

3. Правила расширения пространства имен CIMV2

Если Ваш продукт расширяет пространство имен CIMV2, он должен соответствовать следующим принципам.

Замечания:

· Различные типы данных имеют различные правила расширения.

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

Данные приложения

При установке приложения с помощью службы Windows Installer автоматически создаются следующие классы и экземпляры. Если Вы моделируете информацию о конфигурации, не создаваемые автоматически службой Windows Installer, см. ниже раздел ‘Данные установок’:

· Приложение представляется экземпляром Win32_ApplicationService (подклассом CIM_Service), представляющим наличие (объявляемого или установленного) приложения в системе.

· Командная строка для выполнения приложения представляется экземпляром Win32_CommandLineAccess (подклассом CIM_ServiceAccessPoint). Они связаны с экземплярами Win32_ApplicationService с помощью связи Win32ApplicationCommandLine (подкласса CIM_ServiceAccessBySAP).

· Первичные компоненты приложения представляются экземплярами Win32_SoftwareElement (подклассом CIM_SoftwareElement). Некоторыми примерами первичных компонентов являются исполняемые файлы, библиотеки DLL и файлы баз данных.

· Конфигурация установки приложения представляется экземплярами объектов, являющихся подклассами CIM_Setting. Они связаны с установленными Win32_SoftwareElements с помощью связи Win32_SoftwareElementResource.

· Конфигурация установки драйвера ODBC представляется подклассами связи Win32_SettingCheck.

· Если у приложения имеется информация о конфигурации, она видна как подкласс класса CIM_Setting и должна быть связана с корректным экземпляром Win32_ApplicationService (представляющим приложение в системе). Экземпляр CIM_Setting связан с экземпляром Win32_ApplicationService с помощью подкласса класса связи CIM_ElementSetting. Обратите внимание, что может быть несколько экземпляров класса CIM_Setting, представляющих возможные конфигурации. Информация о конфигурации устанавливается с помощью класса CIM_Setting. Однако текущая информация о конфигурации обычно хранится в экземпляре Win32_ApplicationService.

Данные установок

Правила расширения схемы для установок (например, устанавливаемых параметров служб, систем, приложений или устройств):

· Установка должна быть выражена через подкласс класса CIM_Setting. Обратите внимание, что может быть несколько экземпляров класса CIM_Setting, представляющих возможные конфигурации. Информация о конфигурации устанавливается с помощью класса CIM_Setting. Однако текущая информация о конфигурации обычно хранится в экземпляре-потомке CIM_ManagedSystemElement.

· Для установки отношения между CIM_Setting и соответствующим потомком CIM_ManagedSystemElement (службой, системой, приложением или устройством, к которому применяется эта установка) должен быть определен экземпляр подкласса связи CIM_ElementSetting.

Данные статистики

Правила расширения схемы для статистики:

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

Если данные тесно связаны с управляемым системным элементом и должны загружаться как естественные свойства объекта, они помещаются в виде свойств самого объекта (например, пакеты, передаваемые или получаемые через адаптер Ethernet).

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

· Для установки отношения между CIM_StatisticalInformation и соответствующим потомком CIM_ManagedSystemElement производитель должен определить экземпляр подкласса связи CIM_Statistics.

Данные устройства

Правила расширения схемы для представления устройства:

· Определяемые производителем классы должны выводиться из самых дальних “листовых” подклассов CIM_LogicalDevice.

· Если у устройства имеется информация о конфигурации, она должна быть видна как подкласс класса CIM_Setting и должна быть связана с корректным экземпляром CIM_LogicalDevice (представляющим устройство в системе) с использованием подкласса класса связи CIM_ElementSetting. Обратите внимание, что может быть несколько экземпляров класса CIM_Setting, представляющих возможные конфигурации. Информация о конфигурации устанавливается с помощью класса CIM_Setting. Однако текущая информация о конфигурации обычно хранится в экземпляре-потомке CIM_ManagedSystemElement.

· Не создавайте подклассы непосредственно в CIM_LogicalDevice. Подробная информация о классах, для которых могут создаваться и инициализироваться подклассы, имеется в WMI SDK.

Данные компьютерной системы (обычно относится к OEM)

Правила расширения схемы для представления компьютерной системы:

· Производитель должен определить прямой подкласс Win32_ComputerSystem.

· Не создавайте подклассы непосредственно в CIM_UnitaryComputerSystem.

Данные физической конфигурации

Правила расширения схемы для представления физической конфигурации:

· Определяемые производителем классы должны выводиться из самых дальних “листовых” подклассов CIM_PhysicalElement, если только компания Microsoft не предоставляет класс схемы Win32 для конкретного физического элемента. В последнем случае определяемые производителем классы должны выводиться из этого класса Win32.

Руководство по предварительному тестированию

Корпорация Microsoft разрабатывает инструментарий, позволяющий автоматизировать процесс проверки соответствия рекомендациям WMI. Самую новую информацию можно найти по адресу http://msdn.microsoft.com/developer/sdk/wmisdk/. Временно для проверки корректности построения схемы рекомендуется использовать CIM Studio. CIM Studio поставляется с WMI SDK. Чтобы использовать CIM Studio для предварительного тестирования, убедитесь, что у Вас:

· Установлен комплект WMI SDK

· Созданы необходимые файлы MOF с расширениями схемы

· Схема скомпилирована в хранилище с помощью mofcomp.exe

· Установлено соединение с пространством имен root\CIMV2

· Определено местоположение всех классов, добавленных в пространство имен (чтобы сделать это, нажмите кнопку “Найти”)

Предварительное тестирование корректности расширения схемы для данных приложения:

1 Убедитесь, что Ваш продукт устанавливается с помощью службы Windows Installer. Это гарантирует корректность расширения пространства имен CIMV2 для данных продукта.

2. Если в продукте имеется информация о конфигурации, следует протестировать данные установок

Предварительное тестирование корректности расширения схемы для данных установок:

1. Убедитесь, что Ваш класс выводится из класса CIM_Setting непосредственно или из самого дальнего “листового” подкласса класса CIM_Setting.

2. Убедитесь, что Вы определили подкласс связи CIM_ElementSetting, устанавливающий отношение между CIM_Setting и потомком класса CIM_ManagedSystemElement, определенного для службы, системы, приложения или устройства, к которому применяется установка.

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

Предварительное тестирование корректности расширения схемы для данных статистики:

1. Если статистические данные тесно связаны с управляемым элементом и должны всегда загружаться как естественные свойства объекта, убедитесь, что Вы включили их в виде свойств подкласса класса CIM_ManagedSystemElement.

2. Если статистические данные не всегда доступны, выводятся из существующих или не нужны для управления системным элементом, убедитесь, что определен подкласс класса CIM_StatisticalInformation.

3. Убедитесь, что Вы определили подкласс связи CIM_Statistics, устанавливающий отношение между CIM_StatisticalInformation и потомком класса CIM_ManagedSystemElement для службы, системы, приложения или устройства, к которому применяется статистика.

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

Предварительное тестирование корректности расширения схемы для данных устройства:

1. Убедитесь, что Вы определили подкласс самого дальнего “листового” потомка класса CIM_LogicalDevice.

2. Убедитесь, что подклассы не создаются непосредственно из CIM_LogicalDevice.

3. Если в устройстве имеется информация о конфигурации, следует протестировать данные установок

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

Предварительное тестирование корректности расширения схемы для системных данных:

1. Убедитесь, что Вы определили прямой подкласс класса Win32_ComputerSystem.

2. Убедитесь, что Провайдер обеспечивает динамические экземпляры этого класса.

Предварительное тестирование корректности расширения схемы для данных физической конфигурации:

1. Если корпорация Microsoft предоставляет класс схемы Win32 для конкретного физического элемента, убедитесь, что Вы определили его подкласс.

2. Если корпорация Microsoft не предоставляет класс для конкретного физического элемента, убедитесь, что Вы определили подкласс самого дальнего “листового” потомка класса CIM_PhysicalElement.

3. Убедитесь, что Провайдер обеспечивает динамические экземпляры этого класса.

A-9 Управляющая консоль Microsoft (MMC)

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

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

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

Предлагаемое соответствие

1. Дополните встраиваемые модули Управления компьютером и/или пользователями и группами пунктами контекстных меню, соответствующих принципам пользовательского интерфейса MMC для пунктов контекстных меню.

2. Напишите встраиваемый модуль MMC для пространства имен.

Преимущества пользователя

Если приложение использует MMC, системные администраторы в корпоративной среде получают следующие преимущества:

· Сокращение времени обучения: Более простой и сходный интерфейс приложений помогает администраторам быстрее изучить Ваш продукт, максимально увеличивая преимущества использования продукта в кратчайшие сроки. Пакет Microsoft BackOffice® использует MMC для снабжения своих функций управления визуальным интерфейсом на базе Windows, предоставляя администраторам знакомый интерфейс, так что они быстро могут освоить новые приложения и информацию.

· Логическая группировка функций: MMC группирует функции управления в общие категории, что упрощает поиск необходимой утилиты.

· Интеграция управляющих утилит: MMC предоставляет основу для интеграции управляющих утилит, ранее работавших отдельно друг от друга. Такая интеграция функциональности предоставляет администратору более эффективное средство решения проблем и управления окружением.

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

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

Информация о реализации

1. Дополните встраиваемые модули Управления компьютером и/или пользователями и группами пунктами контекстных меню, соответствующих требованиям к пользовательскому интерфейсу MMC для пунктов контекстных меню.

Самым простым способом интеграции приложения с MMC является добавление пункта контекстного меню для запуска Вашей утилиты управления из одного или нескольких основных встраиваемых модулей Windows 2000. Более тесная интеграция достигается за счет написания расширения пространства имен. В этом разделе демонстрируется, как создать расширение для контекстного меню. Полную информацию о расширениях пространств имен можно найти в разделе MMC SDK комплекта Microsoft Platform SDK.

1. Определите, какой узел нужно расширить. Пространство имен корневого узла управления компьютером расширяться не должно, но его меню или страницы свойств могут быть расширены. В приведенном ниже примере предполагается, что Вы добавляете элемент контекстного меню в корневой узел управления компьютером. Если Вы хотите расширить другой узел, следует использовать его GUID.

2. Зарегистрируйте свой встраиваемый модуль, как описано в разделе MMC SDK комплекта Microsoft Platform SDK. Кроме того, добавьте значение с GUID Вашего модуля в следующий раздел реестра:

HKLM\Software\Microsoft\MMC\Nodetypes\
{476e6446-aaff-11d0-b944-00c04fd8d5b0}\Extensions/ContextMenu

3. Создайте встраиваемый модуль, реализующий функцию IExtendContextMenu(). Этот модуль будет вызывать Вашу утилиту при выборе этого пункта контекстного меню. Поместите модуль в точку вставки CCM_INSERTIONPOINTID_3RDPARTY_TASK. Более подробную информацию о точках вставки можно найти в документации MMC SDK в Platform SDK. Возможно, проще будет использовать мастер Microsoft Visual C++® 6.0 ATL для MMC.

Если Вы расширяете встраиваемый модуль для управления пользователями и группами, а не для управления компьютером, нужно будет использовать GUID класса расширяемого узла. GUID класса можно найти в разделе Службы каталогов Microsoft Platform SDK. Используйте утилиту регистрации класса Служб каталогов, находящуюся в этом разделе SDK, и выполните действия, описанные ранее в этом требовании, чтобы заменить GUID управления компьютером на корректный GUID Служб каталогов.

2. Напишите встраиваемый модуль MMC для пространства имен.

Корпорация Microsoft рекомендует написать встраиваемый модуль MMC для пространства имен в качестве альтернативы расширению контекстного меню. Встраиваемый модуль пространства имен обеспечивает большие удобства пользователю MMC за счет полного использования преимуществ функций MMC.

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

Это руководство можно найти по адресу http://www.microsoft.com/management/mmc.

Руководство по предварительному тестированию

Предварительное тестирование встраиваемого модуля:

· Автономный режим.

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

· Расширение управления компьютером.

Если модуль расширяет Управление компьютером, запустите файл консоли Управления компьютером из меню Пуск и убедитесь, что модуль ведет себя должным образом.

· Расширение управления пользователями и группами

Если модуль расширяет модуль Пользователи и группы, запустите файл консоли Пользователей и групп из меню Пуск и убедитесь, что модуль ведет себя должным образом.

· Расширение контекстного меню.

Если модуль расширяет контекстное меню, убедитесь, что Вы не добавляете разделители, что каскады меню используются корректно и это происходит только в меню Создать и Задача и что все пункты меню отображаются в нужном порядке.

A-10 Демонстрация модели сценариев на базе COM

Все приложения должны предоставлять модель сценариев на базе COM, которая позволит системным администраторам и интеграторам обращаться к функциям приложения или его информации о конфигурации программным путем. Доступ к этой модели сценариев должен иметься из Windows Scripting Host и Active Server Pages.

Предлагаемое соответствие

· Приложения должны предоставлять один или несколько компонентов COM, открывающих функции приложения или его информации о конфигурации.

· Компоненты должны демонстрировать интерфейсы Автоматизации (т.е. на базе IDispatch) или двойные интерфейсы.

· В приложениях должна иметься документация для программистов, в которой описывается использование модели сценариев.

Преимущества пользователя

Обеспечивая модель сценариев, Вы предоставляете пользователям возможности:

· Автоматизации конфигурирования процедур и административных задач

· Разработки настраиваемых пользовательских интерфейсов

Информация о реализации

· В разделе Службы объектов COM и ActiveX, Автоматизация комплекта Platform SDK описана Автоматизация и реализация компонентов COM, демонстрирующих интерфейсы Автоматизации на языках C или C++.

· В книге “The Basics of Programming Model Design”, Dave Stearns, библиотека MSDN, описано определение модели сценариев.

· В книге “Building COM Components That Take Full Advantage of Visual Basic and Scripting”, Ivo Salmre, библиотека MSDN, описано определение моделей сценариев, особо внимание уделяется доступа с помощью языка Visual Basic и языков сценариев.

· В руководстве Visual Basic Component Tools Guide, Creating ActiveX Components описана реализация компонентов COM, демонстрирующих интерфейсы Автоматизации, с помощью языка Visual Basic.

A-11 Использование COM+ для распределенных приложений

Для использования всех преимуществ, предоставляемых COM+, серверные приложения должны конфигурироваться как приложения COM+. Используйте встраиваемый модуль Служб компонентов для MMC, чтобы добавить Ваше приложение в папку Приложения COM+ для компьютера, на котором оно установлено.

Принципы совместимости

Приложения COM+ создаются из одного или нескольких компонентов, использующих службы COM+ и устанавливаются в каталог COM+.

· Все компоненты должны реализовываться в динамически подключаемых библиотеках (DLL)

· Каждый компонент должен демонстрировать один или несколько интерфейсов Автоматизации (т.е. на базе IDispatch) или двойные интерфейсы.

· Используйте встраиваемый модуль Служб компонентов для MMC или API администрирования COM+ для регистрации каждого компонента COM как части одного приложения COM+.

· Используйте встраиваемый модуль Служб компонентов для MMC или API администрирования COM+ для экспорта приложения COM+.

· Используйте встраиваемый модуль Служб компонентов для MMC или API администрирования COM+ для экспорта информации необходимой удаленным клиентам для доступа к приложению COM+.

· Обеспечьте документацию для каждого компонента COM.

· Опишите синтаксис и ожидаемые результаты для каждого метода в каждом интерфейсе, предназначенном для использования разработчиками и администраторами.

Преимущества пользователя

COM+ определяет модель программирования общего назначения для построения распределенных покомпонентных серверных приложений. Разработчики определяют архитектуру своих серверов приложений и строят их как Компоненты COM+, которые будут содержаться в Приложениях COM+, которые, в свою очередь, используют рабочую среду Служб компонентов Windows 2000 (также называемую рабочей средой Служб COM+). Эта среда выполнения обеспечивает высокую масштабируемость, надежность и целостность, обычно присущие только высокотехнологичным системам обработки транзакций. Среда выполнения COM+ автоматически и незаметно обрабатывает сложные места управления транзакциями, включая: синхронизацию управления совместно используемыми ресурсами, процессами и потоками, управления контекстом, защитой с использованием ролей и балансом нагрузки.

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

Приложения COM+ могут устанавливаться и управляться с использованием стандартных пользовательских API и Win32 API. Приложения могут управляться локально и удаленно с помощью утилиты администрирования Служб компонентов, предоставляя сетевым администраторам простой способ управления приложением по сети.

Более подробная информация о построении приложений COM+ приводится в Platform SDK.

Информация о реализации

· Более подробную информацию о разработке приложений COM+ Вы можете найти на web-сайте COM+ компании Microsoft по адресу: http://www.microsoft.com/com.

· Реализация пользовательских событий COM+ описана в Component Services Programmer’s Guide.

· В разделе Службы объектов COM и ActiveX, Автоматизация комплекта Platform SDK описана Автоматизация и реализация компонентов COM, демонстрирующих интерфейсы Автоматизации в системах разработки Microsoft® C или C++.

· В книге “The Basics of Programming Model Design”, Dave Stearns, библиотека MSDN, описано определение модели сценариев.

A-12. Выполнение без NetBIOS в окружении только Windows 2000

Среду только Windows 2000 можно сконфигурировать для работы без NetBIOS и без службы имен NetBIOS (т.е. Windows Internet Name System - WINS).

Поэтому, чтобы гарантировать возможность работы приложений в окружении только Windows 2000:

· Приложения должны иметь возможность принимать в виде ввода пользователя как имена NetBIOS, так и имена DNS для компьютеров и доменов.

· Приложения, которые будут работать только на платформе Windows 2000 и получать имена программным путем, всегда должны запрашивать версию имени компьютера или домена для DNS.

Определения максимальной длины имени компьютера и API проверки имени описаны в Руководстве программиста активного каталога.

Работа с именами компьютеров

Для приложений, работающих исключительно на платформе Windows 2000:

· Вызвать GetComputerNameEx и запросить ComputerNameDnsFullyQualified для получения имени локального компьютера. Эта функция API имеет приоритет над функцией GetComputerName на платформе Windows 2000.

· Вызвать функцию SetComputerNameEx и передать ComputerNameDnsHostname или ComputerNameDnsDomain для установки локального полностью различимого имени компьютера. Эта функция API имеет приоритет над функцией SetComputerName на платформе Windows 2000.

Для приложений, созданных для работы на всех платформах, обрабатывающих имена в формате Unicode для разрешения имени компьютера вместо функции gethostbyname следует использовать семейство функций API WSALookupService.

Работа с именами доменов

Для разрешения имен доменов в имена контроллеров доменов:

· Вызвать функцию DsGetDcName с флагом DS_PDC_REQUIRED для получения имени первичного контроллера домена для данного домена. Эта функция API имеет приоритет над функцией NetGetDCName на всех платформах.

· Вызвать функцию DsGetDcName для получения имени первичного контроллера домена для данного домена. Эта функция API имеет приоритет над функцией NetGetAnyDCName на всех платформах.

1 Находится по адресу http://msdn.microsoft.com/certification/appspec.asp

[2] В этом контексте “клиент” относится к той части приложения, которая запрашивает обслуживание, а “сервер” - это та часть приложения, которая выполняет это обслуживание. Обратите внимание, что в некоторых случаях “клиент” может работать на компьютере с ОС Windows 2000 Server, а “сервер” - на компьютере с ОС Windows 2000 Professional.

[3] "Документ" XML – это набор тегов языка XML и содержимое, построенные в соответствии с правилами языка XML. Для прохождения сертификации этот документ должен быть хорошо построен, что означает, что он должен соблюдать правила языка XML и быть допустимым документом, т.е. соответствовать некоторой схеме. Последнюю информацию по стандартам XML можно найти по адресу http://www.w3.org/.

[4] Для запуска службы в определенной учетной записи 1) щелкните правой кнопкой мыши Мой компьютер и выберите “Управление” 2) Дополните узел “Службы и приложения” 3) в левой части окна выберите узел “Службы” 4) в правой части окна дважды щелкните службу, для которой Вы хотите настроить свойства учетной записи 5) выберите закладку “Регистрация”. Щелкните кнопку с зависимой фиксацией “Эта учетная запись”. Укажите нужный тип учетной записи.

[5] Windows 2000 Datacenter Server - это другая реализация операционных систем Windows 2000. В данный момент Microsoft принимает решение о необходимости дополнительных требований специально для Datacenter при сертификации серверов Windows 2000 Datacenter.

Ресурс	Адрес
Спецификация настольных приложений для Windows 2000	http://msdn.microsoft.com/certification/
Программа тестирования на получение логотипа “Certified for Windows” (“Сертифицировано для Windows”)	http://msdn.microsoft.com/certification/
Адрес электронной почты испытательной лаборатории логотипов VeriTest	LogoLab@veritest.com
Адрес электронной почты для обращения по вопросам о логотипе “Certified for Windows” (“Сертифицировано для Windows”)	Winlogo@microsoft.com
Информация для разработчиков для Windows 2000	http://msdn.microsoft.com/windows2000
Программа тестирования для получения логотипа BackOffice	http://www.microsoft.com/backoffice/designed
База знаний	http://www.microsoft.com/support/
Microsoft Platform SDK (Software Developer Kit- Комплект средств разработчика программ) Документация по программным интерфейсам приложений (API) Win32® и Win64™.	Поставляется с Microsoft Developer Network (MSDN) Professional Subscription. Если Вы хотите подписаться, посетите web-страницу по адресу http://msdn.microsoft.com/subscriptions/

	Основы Windows
X	1.1 Обеспечение основной функциональности и стабильной работы
X	1.2 Наличие 32-разрядных компонентов
X	1.3 Поддержка длинных имен файлов и путей UNC (если демонстрируются имена файлов)
X	1.4 Поддержка принтеров с длинными именами и путей UNC (если поддерживается печать)
X	1.5 Отсутствие чтения или записи в файлы Win.ini, System.ini, Autoexec.bat или Config.sys в любой операционной системе Windows на базе технологии NT.
X	1.6 Наличие сопоставленных всем нескрытым файлам типов файлов и всем типам файлов пиктограмм, описаний и действий
X	1.7 Выполнение корректной проверки версии Windows (при необходимости определения версии Windows)
X	1.8 Поддержка Автоматического воспроизведения компакт-дисков (если продукт распространяется на компакт-дисках)
X	1.9 Драйверы режима ядра должны пройти проверку на платформе Windows 2000 (если таковые имеются)
X	1.10 Драйверы оборудования должны пройти проверку WHQL (если таковые имеются)


	Установка/удаление
X*	2.1 Установка с помощью пакета на базе Windows Installer, прошедшего испытание на корректность
X*	2.2 Соблюдение правил разбивки приложений на компоненты
X*	2.3 Идентификация совместно используемых компонентов
	2.4 Установка по умолчанию в каталог Program Files
	2.5 Корректная поддержка Добавления/Удаления программ
X*	2.6 Поддержка приложением оповещения
	2.7 Корректная поддержка удаления
Элементы управления * ActiveX должны быть укомплектованы с использованием MSI для работы в защищенном окружении. Дополнительную информацию см. в статье базы знаний Q241163

	Совместное использование компонентов
X	3.1 Отсутствие попыток перемещения файлов, защищенных с помощью Защиты системных файлов
	3.2 Производителям компонентов следует разрабатывать смежные компоненты
	3.3 Разработчикам приложений следует использовать и устанавливать смежные компоненты
X	3.4 Установка совместно используемых файлов, не являющихся смежными, в корректные каталоги

	Управление данными и настройками
X	4.1 По умолчанию для хранения данных, созданных пользователем (если в приложении имеется файловый ввод/вывод) должна использоваться папка “Мои документы”
X	4.2 Корректная классификация и хранение данных приложения
X	4.3 Корректная обработка запрета доступа
X	4.4 Работа в защищенной среде Windows
X	4.5 Использование установок Политики группы системного уровня
X	4.6 Приложения, создающие файлы ADM, должны соответствующим образом хранить настройки файлов ADM в реестре (если файлы ADM поддерживаются)

	Основы пользовательского интерфейса
X	5.1 Поддержка стандартного размера, цвета, шрифта и настроек ввода системы
X	5.2 Обеспечение совместимости с параметром Высокая контрастность
X	5.3 Обеспечение документированного доступа с клавиатуры ко всем функциям
X	5.4 Предоставление информации о местоположении фокуса ввода с клавиатуры
X	5.5 Отсутствие зависимости только от звуковых эффектов
X	5.6 Отсутствие ярлыков для документов, справки или функции удаления в меню Пуск
X	5.7 Поддержка работы с несколькими мониторами (если в исполняемом коде задаются координаты экрана, необходимо убедиться в их корректности)

	Поддержка OnNow/ACPI
	6.1 Корректное указание состояния “приложение занято”
	6.2 Корректная реакция на запросы операционной системы о переходе в “спящий” режим
	6.3 Корректная обработка уведомления о “спящем” режиме
	6.4 Сохранение данных при нормальном возврате из “спящего” режима
	6.5 Корректная обработка перехода из критического “спящего” режима

	Миграция приложений
нет	7.1 Приложение должно по-прежнему функционировать после перехода на Windows 2000 Professional без необходимости переустановки

Введение iv

Для кого предназначена эта спецификация?__________________________ viii

Приложение А Рекомендации по улучшению работы___________________ 59