Сертификационные требования для классических приложений для Windows
Версия документа: 10
Дата документа: 29 июля 2015 г.
В этом документе содержатся технические требования и квалификации, которым должно соответствовать классическое приложение для участия в программе сертификации классических приложений Windows 10.
Добро пожаловать!
Платформа Windows поддерживает широкую экосистему продуктов и партнеров. Отображение логотипа Windows на вашем продукте представляет отношения и общую приверженность качеству между корпорацией Майкрософт и вашей компанией. Клиенты доверяют торговой марке Windows в вашем продукте, так как она гарантирует, что она соответствует стандартам совместимости и хорошо работает на платформе Windows. Успешное прохождение сертификации приложений для Windows позволяет продемонстрировать ваше приложение в Центре совместимости Windows, а вы можете отобразить логотип сертификации на своем сайте.
Программа сертификации приложений для Windows состоит из программных и технических требований, которые помогают гарантировать, что сторонние приложения с торговой маркой Windows легко устанавливаются и надежны на компьютерах под управлением Windows. Клиенты ценят стабильность, совместимость, надежность, производительность и качество в системах, которые они покупают. Корпорация Майкрософт фокусирует свои инвестиции на соответствие этим требованиям для программных приложений, предназначенных для работы на платформе Windows для компьютеров. Эти усилия включают в себя тесты совместимости для согласованности взаимодействия, повышения производительности и повышенной безопасности на компьютерах под управлением программного обеспечения Windows. Тесты совместимости Майкрософт разработаны в сотрудничестве с отраслевыми партнерами и постоянно совершенствуются в ответ на отраслевые события и потребительский спрос.
Комплект сертификации приложений для Windows используется для проверки соответствия этим требованиям и заменяет все предыдущие версии комплекта, используемые для проверки в Windows 7, Windows 8 или Windows 8.1. Комплект сертификации приложений для Windows является одним из компонентов, включенных в пакет средств разработки программного обеспечения Windows (SDK) для Windows 10.
Соответствие требованиям для приложений
Чтобы приложение соответствовало требованиям Windows 10 сертификации классических приложений, оно должно соответствовать следующим критериям и всем техническим требованиям, перечисленным в этом документе.
- Это должно быть автономное приложение.
- Он должен выполняться на локальном компьютере Windows 10
- Это может быть клиентским компонентом сертифицированного приложения Windows Server.
- Это должен быть код и функция завершена
- Он не должен взаимодействовать с приложениями Магазина Windows через локальные механизмы, включая файлы и разделы реестра, за исключением поддерживаемых корпоративных сценариев.
- Он не должен ставить под угрозу или ставить под угрозу безопасность или функциональность системы Windows.
- Он должен иметь уникальное имя и не должен быть товарным знаком других
- Все внешние компоненты должны быть сертифицированы отдельно или соответствовать комплекту сертификации приложений для Windows
- Он должен иметь возможность отказа для всех упакованных приложений
Если классическое приложение отправляется в категорию антивирусных и (или) анти-шпионских (т. е. антивредоносных) продуктов, оно должно соответствовать рекомендациям по платформе защиты от вредоносных программ. Перед отправкой необходимо подписать и действовать соглашение о лицензировании и листинге НА API ЗАЩИТЫ ОТ ВРЕДОНОСНЫХ ПРОГРАММ WINDOWS 10. Партнер должен быть членом или иметь исследователей, которые являются членами и имеют хорошую репутацию в одной организации, перечисленных в соглашении. Функциональность должна быть сертифицирована в Windows 10 одной из организаций, перечисленных в соглашении. Приложение должно быть протестировано по крайней мере один раз за последние 12 месяцев и сертифицировано для обнаружения и очистки.
1. Приложения совместимы и устойчивы
Время, когда приложение завершает работу или перестает отвечать на запросы, вызывает много разочарований пользователей. Ожидается, что приложения будут устойчивыми и стабильными, а устранение таких сбоев помогает обеспечить более предсказуемость, удобство обслуживания, производительность и надежность программного обеспечения.
- 1.1. Приложение не должно зависеть от режимов совместимости Windows, сообщения AppHelp и других исправлений совместимости.
1.2. Приложение должно иметь манифест совместимости и использовать соответствующие идентификаторы GUID для поддерживаемых версий Windows.
1.3. Ваше приложение должно поддерживать DPI с помощью манифеста сборки приложения, а не путем вызова SetProcessDPIAware.
1.4. Ваше приложение не должно зависеть от среды выполнения VB6
1.5 Приложение не должно загружать произвольные библиотеки DLL для перехвата вызовов API Win32 с помощью HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dlls.
2. Приложения должны соответствовать рекомендациям по обеспечению безопасности Windows
Рекомендации по обеспечению безопасности Windows помогут избежать уязвимости к атакам Windows. Уязвимые зоны — это точки входа, которые злоумышленник может использовать для использования операционной системы, используя уязвимости в целевом программном обеспечении. Одной из худших уязвимостей системы безопасности является повышение привилегий.
Обратите внимание, что тесты 2.1 2.6 применимы только к классическим приложениям, протестированным в Windows 7, Windows 8 или Windows 8.1.
- 2.1. Приложение должно использовать надежные и соответствующие списки управления доступом для защиты исполняемых файлов.
2.2 Приложение должно использовать надежные и соответствующие списки управления доступом для защиты каталогов.
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, будут завершены.
- WM\_QUERYENDSESSION с LPARAM = ENDSESSION\_CLOSEAPP(0x1).
Консольные приложения могут вызывать SetConsoleCtrlHandler, чтобы указать функцию, которая будет обрабатывать уведомления о завершении работы. Приложения-службы могут вызывать RegisterServiceCtrlHandlerEx, чтобы указать функцию, которая будет получать уведомления о завершении работы.
- WM\_ENDSESSION с LPARAM = ENDSESSION\_CLOSEAPP(0x1).
Как минимум, приложение должно подготовиться, сохранив все пользовательские данные и указав сведения, необходимые после перезапуска.
5. Приложения должны поддерживать чистую и обратимую установку
Чистая, обратимая установка позволяет пользователям успешно управлять (развертывать и удалять) приложения в своих системах.
- 5.1. Приложение должно правильно реализовать чистую, обратимую установку
- DisplayName
- InstallLocation
- Publisher
- UninstallString
- VersionMajor или MajorVersion
- VersionMinor или MinorVersion
- В случае сбоя установки приложение сможет выполнить откат и восстановить предыдущее состояние компьютера.
- Перезагрузка компьютера никогда не должна быть единственным вариантом в конце установки, удаления или обновления. Пользователи должны иметь возможность перезапустить позже.
- Средства инвентаризации Windows и средства телеметрии требуют полных сведений об установленных приложениях. Если вы используете установщик на основе MSI, MSI автоматически создает указанные ниже записи реестра. Если вы не используете установщик MSI, модуль установки должен создать следующие записи реестра во время установки:
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 7, Windows 8 и Windows 8.1, и должны проверка версию операционной системы, чтобы определить, какие компоненты следует установить в данной операционной системе.
- Приложения, которые проверка только минимальную версию операционной системы (только во время установки, а не во время выполнения), используя только утвержденные вызовы API, и правильно перечисляют минимальные требования к версии в манифесте приложения.
- Приложения безопасности (антивирусная программа, брандмауэр и т. д.), системные служебные программы (например, дефрагментация, резервное копирование и средства диагностика), которые проверка версию операционной системы, используя только утвержденные вызовы API.
- Если вам нужна определенная функция, проверка, доступна ли сама функция. Если вам нужна Windows 7, проверка для Windows 7 или более поздней версии (>= 6.2). Таким образом, код обнаружения будет продолжать работать в будущих версиях Windows. Установщики драйверов и модули удаления никогда не должны проверка версию операционной системы.
8. Приложения не загружают службы или драйверы в безопасном режиме
Безопасный режим позволяет пользователям диагностировать и устранять неполадки Windows. Драйверы и службы не должны загружаться в безопасном режиме, если они не требуются для базовых системных операций, таких как драйверы запоминающих устройств, или для диагностики и восстановления, таких как антивирусные сканеры. По умолчанию, когда Windows находится в безопасном режиме, она запускает только драйверы и службы, которые были предустановлены вместе с Windows.
- 8.1 Исключения и отказы
- Драйверы и службы, которые должны быть запущены в безопасном режиме, требуют отказа. Запрос на отказ должен включать все применимые драйверы или службы, записываемые в разделы реестра SafeBoot, и описывать технические причины, по которым приложение или служба должны работать в безопасном режиме. Установщик приложений должен зарегистрировать все такие драйверы и службы с помощью следующих разделов реестра:
Примечание: Необходимо протестировать эти драйверы и службы, чтобы убедиться, что они работают в безопасном режиме без ошибок.
9. Приложения должны следовать рекомендациям по контролю учетных записей
Некоторые приложения windows выполняются в контексте безопасности учетной записи администратора, и приложения часто запрашивают чрезмерные права пользователя и привилегии Windows. Управление доступом к ресурсам позволяет пользователям контролировать свои системы и защищать их от нежелательных изменений. Нежелательные изменения могут быть вредоносными, например, когда rootkit получает контроль над компьютером, или быть результатом действий, выполненных людьми с ограниченными привилегиями. Наиболее важным правилом для управления доступом к ресурсам является предоставление минимального объема контекста стандартного пользователя, необходимого пользователю для выполнения необходимых задач. В соответствии с рекомендациями по контролю учетных записей (UAC) приложение предоставляет приложению необходимые разрешения, когда они необходимы приложению, не оставляя систему постоянно подверженной риску безопасности. Большинству приложений не требуются права администратора во время выполнения. Они должны работать как обычные пользователи.
- 9.1. Приложение должно иметь манифест, который определяет уровни выполнения и сообщает операционной системе, какие привилегии требуются приложению для запуска
- Средства администрирования или системы с уровнем выполнения, для которых задано значение highestAvailable, и (или) requireAdministrator
- Только приложение для специальных возможностей или платформы автоматизации пользовательского интерфейса устанавливает для флага uiAccess значение true, чтобы обойти изоляцию привилегий пользовательского интерфейса (UIPI). Для правильного запуска использования приложения этот флаг должен быть подписан Authenticode и находиться в защищенном расположении в файловой системе, а именно Program Files.
- Маркировка манифеста приложения применяется только к exes, но не к библиотекам DLL. Это связано с тем, что UAC не проверяет библиотеки DLL во время создания процесса. Также стоит отметить, что правила контроля учетных записей не применяются к службам Майкрософт. Манифест может быть внедренным или внешним.
Чтобы создать манифест, создайте файл с именем <app_name>.exe.manifest и сохраните его в том же каталоге, что и EXE-файл. Обратите внимание, что любой внешний манифест игнорируется, если у приложения есть внутренний манифест. Пример:
<requestedExecutionLevel level=""asInvoker | highestAvailable | requireAdministrator"" uiAccess=""true|false""/>
- Все административные функции должны быть перемещены в отдельный процесс, который выполняется с правами администратора. Приложения для пользователей, например те, которые доступны через группу программ в меню "Пуск" и требуют повышения прав, должны быть подписаны Authenticode.
- Отказ требуется для приложений, которые выполняют процесс main с повышенными привилегиями (requireAdministrator или highestAvailable). Процесс main определяется как точка входа пользователя в приложение. Отказ будет рассматриваться в следующих сценариях:
10. По умолчанию приложения должны устанавливаться в правильные папки
Пользователи должны иметь согласованный и безопасный интерфейс с расположением установки файлов по умолчанию, сохраняя возможность установки приложения в выбранном ими расположении. Кроме того, необходимо хранить данные приложения в правильном расположении, чтобы несколько пользователей могли использовать один и тот же компьютер без повреждения или перезаписи данных и параметров друг друга. Windows предоставляет определенные расположения в файловой системе для хранения программ и программных компонентов, общих данных приложений и данных приложений, относящихся к пользователю.
- 10.1. По умолчанию приложение должно быть установлено в папку Program Files
- Запустите разделы реестра HKLM и или HKCU в разделе Software\Microsoft\Windows\CurrentVersion.
- Запустите разделы реестра HKLM и или HKCU в разделе Software\Wow6432Node\Microsoft\windows\CurrentVersion
- Меню "Пуск" Все Программы > STARTUP
- Для собственных 32-разрядных и 64-разрядных приложений в %ProgramFiles% и %ProgramFiles(x86)% для 32-разрядных приложений, работающих на 64-разрядных системах. Данные пользователя или данные приложения никогда не должны храниться в этом расположении из-за разрешений безопасности, настроенных для этой папки.
- Например, приложение не должно задавать следующие параметры.
- Используйте правильные методы для установки файлов, таких как шрифты или драйверы.
- При установке приложения нет правильного расположения пользователя для хранения данных. Попытки приложения изменить поведение связи по умолчанию на уровне компьютера после установки будут неудачными. Вместо этого значения по умолчанию должны быть заданы на уровне каждого пользователя, что предотвращает перезапись значений по умолчанию для нескольких пользователей.
- Отказ требуется для приложений, которые записывают данные в приложения .NET глобального кэша сборок (GAC), должны сохранять зависимости сборок закрытыми и хранить их в каталоге приложений, если только не требуется совместное использование сборки.
11. Приложения должны поддерживать многопользовательские сеансы
Пользователи Windows должны иметь возможность выполнять параллельные сеансы без конфликтов или прерываний.
- 11.1. Ваше приложение должно гарантировать, что при выполнении в нескольких сеансах локально или удаленно нормальное функционирование приложения не оказывает негативного влияния.
11.2 Файлы параметров и данных приложения не должны сохраняться между пользователями
11.3. Конфиденциальность и предпочтения пользователя должны быть изолированы для сеанса пользователя.
11.4 Экземпляры приложения должны быть изолированы друг от друга
- Это означает, что пользовательские данные из одного экземпляра не видны другому экземпляру приложения. Звук в неактивном сеансе пользователя не должен быть слышен в активном сеансе пользователя. В случаях, когда несколько экземпляров приложения используют общие ресурсы, приложение должно гарантировать отсутствие конфликта.
- Ознакомьтесь с требованиями UAC.
12. Приложения должны поддерживать 64-разрядные версии Windows
По мере того как 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 |
| 31 мая 2012 г. | 1,2 | Добавлены сводные результаты тестирования | 1.2 |
| 29 июня 2012 г. | 3,0 | Windows 8 заключительного документа | 3.0 |
| 18 июня 2013 г. | 3.1 | документ Windows 8.1 | 3.1 |
| 20 февраля 2014 г. | 3.2 | Внутреннее обновление | |
| 18 марта 2014 г. | 3.3 | Windows 8.1 с обновлением 1 | 3.3 |
| 29 июля 2015 г. | 10 | Обновление Windows 10 | 10 |
Дополнительные сведения о сертификации классических приложений
| Требование | Описание |
| Совместимость и устойчивость | Сбои & зависания являются серьезным нарушением работы пользователей и вызывают разочарование. Ожидается, что приложения будут устойчивыми и стабильными. Устранение таких сбоев помогает обеспечить более предсказуемость, удобство обслуживания, производительность и надежность программного обеспечения. Точка входа в приложение, обращенная к пользователю, должна быть манифестирована для обеспечения совместимости, а также объявления правильного GUID. Точки входа в приложения, доступные пользователям, должны быть проявятся для информирования о высоком уровне DPI и что для поддержки high-DPI вызываются соответствующие API. Дополнительные сведения см. в разделах:
|
| Соблюдайте рекомендации по Безопасность Windows | Рекомендации по обеспечению безопасности Windows помогут избежать уязвимости к атакам Windows. Уязвимые зоны — это точки входа, которые злоумышленник может использовать для использования операционной системы, используя уязвимости в целевом программном обеспечении. Одной из худших уязвимостей системы безопасности является повышение привилегий. Дополнительные сведения см. в разделах: |
| Функции поддержки Безопасность Windows | В операционной системе Windows реализовано множество мер по обеспечению безопасности и конфиденциальности системы. Приложения должны поддерживать эти меры для поддержания целостности ОС. Неправильно скомпилированные приложения могут привести к переполнению буфера, что, в свою очередь, может привести к отказу в обслуживании или выполнению вредоносного кода. Дополнительные сведения см. в справочнике по инструменту BinScope. |
| Соблюдение сообщений диспетчера перезапуска системы | Когда пользователи инициируют завершение работы, в подавляющем большинстве случаев у них есть сильное желание, чтобы завершить работу успешно; они могут спешить покинуть офис и "просто хотят", чтобы их компьютеры выключились. Приложения должны соблюдать это желание, не блокируя завершение работы. Хотя в большинстве случаев завершение работы не может быть критическим, приложения должны быть подготовлены к возможности критического завершения работы. |
| Очистка обратимой установки | Чистая, обратимая установка позволяет пользователям успешно управлять (развертывать и удалять) приложения в своих системах. Дополнительные сведения см. в разделе Практическое руководство. Установка необходимых компонентов с помощью приложения ClickOnce. |
| Цифровая подпись файлов и драйверов | Цифровая подпись Authenticode позволяет пользователям быть уверенными в подлинности программного обеспечения. Это также позволяет определить, был ли файл изменен, например, если он был заражен вирусом. Принудительное применение подписывания кода в режиме ядра — это функция Windows, известная как целостность кода (CI), которая повышает безопасность операционной системы за счет проверки целостности файла при каждой загрузке образа файла в память. CI определяет, изменил ли вредоносный код системный двоичный файл. Кроме того, создает событие журнала диагностики и аудита системы, если сигнатура модуля ядра не проходит проверку правильно. |
| Не блокируйте установку или запуск приложения на основе версии операционной системы проверка | Важно, чтобы пользователи не блокировали установку или запуск приложения, если нет технических ограничений. Как правило, если приложения были написаны для Windows Vista или более поздних версий, у них не должно быть оснований для проверка версию операционной системы. Дополнительные сведения см. в разделе Управление версиями операционной системы. |
| Не загружать службы и драйверы в безопасном режиме | Безопасный режим позволяет пользователям диагностировать и устранять неполадки Windows. Если это не требуется для основных операций системы (например, драйверов запоминающих устройств) или для диагностики и восстановления (например, антивирусных сканеров), драйверы и службы не должны быть настроены для загрузки в безопасном режиме. По умолчанию безопасный режим не запускает большинство драйверов и служб, которые не были предустановлены вместе с Windows. Они должны оставаться отключенными, если система не требует их для базовых операций или для диагностики и восстановления. Дополнительные сведения см. в разделах: |
| Следуйте рекомендациям по контролю учетных записей (UAC) | Некоторые приложения для Windows выполняются в контексте безопасности учетной записи администратора, и для многих из этих приложений требуются чрезмерные права пользователя и привилегии Windows. Управление доступом к ресурсам позволяет пользователям контролировать свои системы от нежелательных изменений (нежелательные изменения могут быть вредоносными, такими как скрытый захват компьютера rootkit или действие со стороны людей с ограниченными привилегиями, например, сотрудник, устанавливающий запрещенное программное обеспечение на рабочем компьютере). Наиболее важным правилом для управления доступом к ресурсам является предоставление минимального объема стандартного пользовательского контекста доступа, необходимого пользователю для выполнения необходимых задач. Следуя рекомендациям по UAC, приложение предоставляет необходимые разрешения при необходимости, не оставляя систему постоянно подверженной риску безопасности. Дополнительные сведения см. в разделах: |
| Установка в правильные папки по умолчанию | Пользователи должны иметь согласованный и безопасный интерфейс с расположением установки файлов по умолчанию, сохраняя возможность установки приложения в выбранном расположении. Кроме того, необходимо хранить данные приложения в правильном расположении, чтобы несколько пользователей могли использовать один и тот же компьютер без повреждения или перезаписи данных и параметров друг друга. Дополнительные сведения см. в разделе Сводка требований к установке и удалению. |
| Поддержка многопользовательских сеансов | Пользователи Windows должны иметь возможность выполнять параллельные сеансы без конфликтов или прерываний. Дополнительные сведения см. в статье Рекомендации по программированию служб удаленных рабочих столов. |
| Поддержка 64-разрядных версий Windows | По мере того как 64-разрядное оборудование становится все более распространенным, пользователи ожидают, что разработчики приложений воспользуются преимуществами 64-разрядной архитектуры, перенося свои приложения на 64-разрядную версию, или что 32-разрядные версии приложения хорошо работают в 64-разрядных версиях Windows. |
См. также раздел
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по