Архив: требования к сертификации для классических приложений Windows версии 1.1

Версия документа: 1.1

Дата документа: 26 января 2012 г.

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

Добро пожаловать!

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

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

Комплект сертификации приложений Windows используется для проверки соответствия этим требованиям и заменяет WSLK, используемый для проверки в программе Windows 7 Software Logo. Комплект сертификации приложений Windows является одним из компонентов, включенных в пакет средств разработки программного обеспечения Windows (SDK).

Право на доступ к приложению

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

  • Это должно быть автономное приложение
  • Он должен работать на локальном компьютере Windows 8.1
  • Это может быть клиентский компонент сертифицированного приложения Windows Server
  • Это должен быть код и функция завершены

1. Приложения совместимы и устойчивы

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

1.1 Приложение не должно зависеть от режимов совместимости Windows, сообщений AppHelp и других исправлений совместимости.
1.2 Ваше приложение не должно зависеть от среды выполнения VB6
1.3 Приложение не должно загружать произвольные библиотеки DLL для перехвата вызовов API Win32 с помощью HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dlls.

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

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

2.1 Ваше приложение должно использовать надежные и соответствующие списки ACL для защиты исполняемых файлов 2.2. Ваше приложение должно использовать надежные и соответствующие списки ACL для защиты каталогов 2.3. Ваше приложение должно использовать надежные и соответствующие списки управления доступом для защиты разделов реестра. 2.4 Ваше приложение должно использовать надежные и соответствующие списки управления доступом для защиты каталогов, содержащих объекты 2.5. Ваше приложение должно сократить доступ неадминистратора к службам, которые уязвимы для незаконного изменения версии 2.6. Ваше приложение должно предотвратить быстрые службы. перезапускается с перезапуска более чем дважды каждые 24 часа
**Примечание. Доступ должен предоставляться только сущностям, которым это требуется.**

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

3. Приложения поддерживают Windows функции безопасности

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

3.1 Ваше приложение не должно использовать AllowPartiallyTrustedCallersAttribute (APTCA), чтобы обеспечить безопасный доступ к сборкам со строгими именами
3.2 Приложение должно быть скомпилировано с помощью флага /SafeSEH, чтобы обеспечить обработку безопасных исключений
3.3 Приложение должно быть скомпилировано с помощью флага /NXCOMPAT, чтобы предотвратить выполнение данных
3.4 Приложение должно быть скомпилировано с помощью флага /DYNAMICBASE для случайной выборки макета адресного пространства (ASLR)
3.5. Ваше приложение не должно читать и записывать общие разделы PE

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

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

4.1 Приложение должно надлежащим образом обрабатывать критические завершения работы.
При критическом завершении работы приложения, возвращающие значение FALSE в WM_QUERYENDSESSION, будут отправляться WM_ENDSESSION и закрыты, а время ожидания в ответ на WM_QUERYENDSESSION будет прекращено.

4.2 Приложение графического интерфейса пользователя должно немедленно вернуть значение TRUE при подготовке к перезапуску
WM\_QUERYENDSESSION с LPARAM = ENDSESSION\_CLOSEAPP(0x1). Консольные приложения могут вызывать SetConsoleCtrlHandler, чтобы указать функцию, которая будет обрабатывать уведомления о завершении работы. Приложения-службы могут вызывать RegisterServiceCtrlHandlerEx, чтобы указать функцию, которая будет получать уведомления о завершении работы.
4.3 Приложение должно возвращать 0 в течение 30 секунд и завершать работу
WM\_ENDSESSION с LPARAM = ENDSESSION\_CLOSEAPP(0x1). Как минимум, приложение должно подготовиться, сохранив все пользовательские данные и указав сведения, необходимые после перезапуска.
4.4 Консольные приложения, получающие уведомление CTRL\_C\_EVENT, должны немедленно завершить работу драйверов 4.5 не должны вето на событие завершения работы системы
**Примечание. Приложения, которые должны блокировать завершение работы из-за операции, которая не может быть прервана, должна объяснить причину пользователю.** Используйте ShutdownBlockReasonCreate для регистрации строки, объясняющей причину для пользователя. После завершения операции приложение должно вызвать ShutdownBlockReasonDedb, чтобы указать, что система может быть завершена.

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

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

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

5.2 Приложение никогда не должно принудительно перезагрузить компьютер немедленно
Перезагрузка компьютера никогда не должна быть единственным вариантом в конце установки или обновления. Пользователи должны иметь возможность перезапустить позже.
5.3 Ваше приложение никогда не должно зависеть от коротких имен файлов 8.3 (SFN) 5.4. Ваше приложение никогда не должно блокировать автоматическую установку и удаление 5.5. Установщик приложения должен создать правильные записи реестра, чтобы разрешить успешное обнаружение и удаление.
Windows средства инвентаризации и средства телеметрии требуют полной информации об установленных приложениях. Если вы используете установщик на основе MSI, MSI автоматически создает записи реестра ниже. Если вы не используете установщик MSI, модуль установки должен создать следующие записи реестра во время установки:
  • DisplayName
  • InstallLocation
  • Publisher
  • UninstallString
  • VersionMajor или MajorVersion
  • VersionMinor или MinorVersion

6. Приложения должны подписывать файлы и драйверы цифровой подписью

Цифровая подпись Authenticode позволяет пользователям убедиться, что программное обеспечение является подлинным. Он также позволяет определить, был ли файл изменен, например, если он был заражен вирусом. Принудительное применение подписывания кода в режиме ядра — это функция Windows, известная как целостность кода (CI), которая повышает безопасность операционной системы, проверяя целостность файла при каждой загрузке образа файла в память. CI определяет, изменил ли вредоносный код системный двоичный файл. Также создает событие журнала диагностики и аудита системы, если сигнатура модуля ядра не проходит проверку правильно.

6.1 Все исполняемые файлы (.exe, .dll, .ocx, .sys, .cpl, DRV, SCR) должны быть подписаны с помощью сертификата Authenticode
6.2. Все драйверы режима ядра, установленные приложением, должны иметь подпись Майкрософт, полученную с помощью программы сертификации оборудования Windows. Все драйверы фильтров файловой системы должны быть подписаны корпорацией Майкрософт.
6.3 Исключения и отказы
Отказы будут рассматриваться только для неподписанных сторонних распространяемых компонентов, за исключением драйверов. Подтверждение связи, запрашивающей подписанную версию распространяемых распространяемых компонентов, требуется для предоставления этого отказа.

7. Приложения не блокируют установку или запуск приложения на основе проверки версии операционной системы

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

7.1 Ваше приложение не должно проверять версии на равенство
Если вам нужна определенная функция, проверьте, доступна ли сама функция. Если требуется Windows XP, проверьте наличие Windows XP или более поздней версии (>= 5.1). Таким образом, код обнаружения будет продолжать работать в будущих версиях Windows. Установщики драйверов и модули удаления никогда не должны проверять версию операционной системы.

7.2 Исключения и отказы будут рассматриваться для приложений, удовлетворяющих приведенным ниже критериям:
  • Приложения, которые доставляются как один пакет, который также выполняется в Windows XP, Windows Vista и Windows 7, и необходимо проверить версию операционной системы, чтобы определить, какие компоненты следует установить в данной операционной системе.
  • Приложения, которые проверяют только минимальную версию операционной системы (только во время установки, а не во время выполнения) с использованием только утвержденных вызовов API и правильно перечисляют минимальные требования к версии в манифесте приложения.
  • Приложения безопасности (антивирусная программа, брандмауэр и т. д.), системные служебные программы (например, дефрагментация, резервные копии и средства диагностики), которые проверяют версию операционной системы только с помощью утвержденных вызовов API.

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

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

  • 8.1 Исключения и отказы
    Для драйверов и служб, которые должны быть запущены в безопасном режиме, требуется отказ. Запрос на отказ должен включать каждый применимый драйвер или службу, записываемые в разделы реестра SafeBoot, и описывать технические причины, по которым приложение или служба должны работать в безопасном режиме. Установщик приложений должен зарегистрировать все такие драйверы и службы с помощью следующих разделов реестра:
    — HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal — HKLM/System/CurrentControlSet/Control/SafeBoot/Network

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

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

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

9.1 Приложение должно иметь манифест, который определяет уровни выполнения и сообщает операционной системе, какие привилегии требуются приложению для запуска.
Маркировка манифеста приложения применяется только к EXEs, а не к библиотекам DLL. Это связано с тем, что UAC не проверяет библиотеки DLL во время создания процесса. Следует также отметить, что правила UAC не применяются к службам Windows. Манифест может быть внедренным или внешним.
Чтобы создать манифест, создайте файл с именем <app_name.exe.manifest> и сохраните его в том же каталоге, что и EXE. Обратите внимание, что любой внешний манифест игнорируется, если у приложения есть внутренний манифест. Вот несколько примеров.
<requestedExecutionLevel level="asInvoker | самый высокий | requireAdministrator"" uiAccess=""true|false"/>

9.2 Основной процесс приложения должен выполняться как обычный пользователь (asInvoker).
Все административные функции должны быть перемещены в отдельный процесс, который выполняется с правами администратора. Пользовательские приложения, такие как доступные через группу программ в меню "Пуск" и требующие повышения прав, должны быть подписаны Authenticode.
9.3 Исключения и отказы
Отказ требуется для приложений, которые выполняют свой основной процесс с повышенными привилегиями (requireAdministrator или highestAvailable). Основной процесс определяется как точка входа пользователя в приложение. Отказы будут рассматриваться в следующих сценариях:
  • Средства администрирования или системы с уровнем выполнения, для которых задано значение highestAvailable, или requireAdministrator
  • Для обхода изоляции привилегий пользовательского интерфейса (UIPI) задается только приложение для специальных возможностей или платформы автоматизации пользовательского интерфейса. Чтобы правильно запустить использование приложения, этот флаг должен быть подписан Authenticode и должен находиться в защищенном расположении в файловой системе, а именно Program Files.

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

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

10.1 Приложение должно быть установлено в папке Program Files по умолчанию.
Для собственных 32-разрядных и 64-разрядных приложений в %ProgramFiles%, а также %ProgramFiles(x86)% для 32-разрядных приложений, работающих на x64. Данные пользователя или данные приложения никогда не должны храниться в этом расположении из-за разрешений безопасности, настроенных для этой папки.

10.2 Ваше приложение должно избегать автоматического запуска при запуске
Например, приложение не должно задавать ни одно из следующих элементов:
  • Разделы запуска реестра HKLM и HKCU в разделе Software\Microsoft\Windows\CurrentVersion
  • Разделы запуска реестра HKLM и HKCU в разделе Software\Wow6432Node\Microsoft\windows\CurrentVersion
  • Пуск меню AllPrograms > STARTUP
10.3 Данные приложения, которые должны быть общими для пользователей на компьютере, должны храниться в программе ProgramData 10.4 Ваши приложения, которые являются эксклюзивными для конкретного пользователя, и которые не должны использоваться совместно с другими пользователями компьютера, должны храниться в папке Users\\<username>\\AppData 10.5 Ваше приложение никогда не должно записываться непосредственно в каталог "Windows" и или подкаталогов.
Используйте правильные методы для установки файлов, таких как шрифты или драйверы.
10.6 Приложение должно записывать данные пользователя при первом запуске, а не во время установки на компьютере.
При установке приложения нет правильного расположения пользователя, в котором хранятся данные. Попытки приложения изменить поведение сопоставлений по умолчанию на уровне компьютера после установки будут неудачными. Вместо этого необходимо запросить значения по умолчанию на уровне пользователя, что предотвращает перезапись нескольких пользователей по умолчанию.
10.7 Исключения и отказы
Отказ требуется для приложений, которые записывают данные в глобальный кэш сборок (GAC) .NET приложения должны сохранять зависимости сборок закрытыми и хранить их в каталоге приложений, если только не требуется явное предоставление общего доступа к сборке.

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

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

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

11.5 Приложения, установленные для нескольких пользователей, должны хранить данные в правильных папках и расположениях реестра.
Ознакомьтесь с требованиями К UAC.
11.6 Пользовательские приложения должны иметь возможность выполняться в нескольких сеансах пользователя (быстрое переключение пользователей) для локального и удаленного доступа 11.7. Ваше приложение должно проверять другие сеансы службы терминалов (TS) для существующих экземпляров приложения.
**Примечание.** Если приложение не поддерживает несколько пользовательских сеансов или удаленный доступ, оно должно четко указывать это при запуске из такого сеанса.

12. Приложения должны поддерживать версии Windows x64

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

12.1 Приложение должно поддерживать 64-разрядную версию или, как минимум, 32-разрядные приложения на основе Windows должны работать без проблем в 64-разрядных системах для обеспечения совместимости с 64-разрядными версиями Windows
12.2. Приложение и его установщики не должны содержать 16-разрядный код или полагаться на любой 16-разрядный компонент.
12.3 Программа установки приложения должна обнаруживать и устанавливать соответствующие драйверы и компоненты для 64-разрядной архитектуры.
12.4 Все подключаемые модули оболочки должны работать в 64-разрядных версиях Windows
12.5 Приложение, работающее в эмуляторе WoW64, не должно пытаться отменить или обойти механизмы виртуализации Wow64
Если существуют определенные сценарии, в которых приложениям необходимо определить, работают ли они в эмуляторе WoW64, они должны сделать это путем вызова IsWow64Process.

Заключение

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

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

История редакций

Дата Версия Описание редакции Ссылка на документ
20 декабря 2011 г. 1,0 Первоначальный черновик документа для предварительной версии.
26 января 2012 г. 1,1 Обновление до раздела 2. 1,1

Дополнительные сведения о сертификации классических приложений

Требование Описание Дополнительные сведения
Совместимость и устойчивость Сбои & висит являются серьезным нарушением работы пользователей и вызывают разочарование. Ожидается, что приложения будут устойчивыми и стабильными, устраняя такие сбои, помогают гарантировать, что программное обеспечение является более предсказуемым, обслуживаемым, устойчивым и надежным. Windows Vista, операционные системы Windows 7 и Windows 8
Средство проверки приложений
Библиотеки DLL AppInit
Придерживайтесь рекомендаций по Безопасность Windows Использование Windows рекомендаций по обеспечению безопасности поможет избежать воздействия на Windows направлений атак. Уязвимые зоны — это точки входа, которые злоумышленник может использовать для использования операционной системы, используя уязвимости в целевом программном обеспечении. Одной из худших уязвимостей безопасности является повышение привилегий. Анализатор направлений атак
Списки управления доступом
Функции поддержки Безопасность Windows Операционная система Windows реализовала множество мер по обеспечению безопасности и конфиденциальности системы. Приложения должны поддерживать эти меры для поддержания целостности ОС. Неправильно скомпилированные приложения могут привести к переполнению буфера, что, в свою очередь, может привести к отказу в обслуживании или выполнению вредоносного кода. Справочник по инструменту BinScope
Придерживайтесь сообщений Диспетчера перезапуска системы Когда пользователи инициируют завершение работы, в большинстве случаев у них есть сильное желание убедиться в успешном завершении работы; они могут быть в спешке покинуть офис и "просто хотят" их компьютеры, чтобы отключить. Приложения должны соблюдать это желание, не блокируя завершение работы. Хотя в большинстве случаев завершение работы может быть не критически важным, приложения должны быть подготовлены для возможности критического завершения работы. Изменения завершения работы приложения в Windows Vista
Перезапуск разработки диспетчера
Чистая обратимая установка Чистая, обратимая установка позволяет пользователям успешно управлять (развертывать и удалять) приложения в своих системах. Практическое руководство. Установка необходимых компонентов при помощи ClickOnce-приложения
Установка приложений в 64-разрядных системах
Файлы и драйверы цифровой подписи Цифровая подпись Authenticode позволяет пользователям убедиться, что программное обеспечение является подлинным. Он также позволяет определить, был ли файл изменен, например, если он был заражен вирусом. Принудительное применение подписывания кода в режиме ядра — это функция Windows, известная как целостность кода (CI), которая повышает безопасность операционной системы, проверяя целостность файла при каждой загрузке образа файла в память. CI определяет, изменил ли вредоносный код системный двоичный файл. Также создает событие журнала диагностики и аудита системы, если сигнатура модуля ядра не проходит проверку правильно. Цифровые подписи для модулей ядра в Windows
Не блокируйте установку или запуск приложения на основе проверки версии операционной системы Важно, чтобы клиенты не блокировали установку или запуск приложения, если технических ограничений нет. Как правило, если приложения были написаны для Windows Vista или более поздних версий, у них не должно быть оснований проверять версию операционной системы. Управление версиями операционной системы
Не загружайте службы и драйверы в режиме Сейф режим Сейф позволяет пользователям диагностировать и устранять неполадки Windows. Если это не требуется для основных операций системы (например, драйверов запоминающих устройств) или для целей диагностики и восстановления (например, антивирусных сканеров), драйверы и службы не должны загружаться в безопасном режиме. По умолчанию безопасный режим не запускает большинство драйверов и служб, которые не были предварительно установлены с Windows. Они должны оставаться отключенными, если система не требует их для основных операций или для диагностики и восстановления. Определение того, работает ли операционная система в режиме Сейф
Следуйте рекомендациям по контролю учетных записей (UAC) Некоторые Windows приложения выполняются в контексте безопасности учетной записи администратора, и многие из которых требуют чрезмерных прав пользователя и Windows привилегий. Управление доступом к ресурсам позволяет пользователям контролировать свои системы от нежелательных изменений (нежелательные изменения могут быть вредоносными, такими как скрытая смена rootkit, или действие от людей, имеющих ограниченные привилегии, например, сотрудник, устанавливающий запрещенное программное обеспечение на рабочем компьютере). Наиболее важным правилом управления доступом к ресурсам является предоставление минимального объема доступа к стандартному контексту пользователя, необходимого пользователю для выполнения необходимых задач. Следуя рекомендациям UAC, при необходимости приложение предоставляет приложениям необходимые разрешения, не выходя из системы, постоянно подверженной рискам безопасности. Контроль учетных записей пользователей
UAC: рекомендации по обновлению приложений
Установка в правильные папки по умолчанию Пользователи должны иметь согласованный и безопасный интерфейс с расположением установки файлов по умолчанию, сохраняя при этом возможность установки приложения в выбранное расположение. Кроме того, необходимо сохранить данные приложения в правильном расположении, чтобы несколько пользователей могли использовать один и тот же компьютер без повреждения или перезаписи данных и параметров друг друга. Сводка требований к установке и удалению
Поддержка сеансов с несколькими пользователями Windows пользователи должны иметь возможность запускать одновременные сеансы без конфликтов или прерываний. Рекомендации по программированию служб удаленных рабочих столов
Поддержка версий Windows x64 Так как 64-разрядное оборудование становится более распространенным, пользователи ожидают, что разработчики приложений будут использовать преимущества 64-разрядной архитектуры путем переноса приложений в 64-разрядную или 32-разрядные версии приложения работают хорошо в 64-разрядных версиях Windows. Совместимость приложений: Windows Vista 64-разрядная версия

См. также раздел