Requisitos de certificación de las aplicaciones del escritorio de Windows
Versión del documento: 10
Fecha del documento: 29 de julio de 2015
Este documento contiene los requisitos técnicos y las calificaciones de idoneidad que debe cumplir una aplicación de escritorio para participar en el programa de certificación de aplicaciones de escritorio de Windows 10.
¡Bienvenido!
La plataforma Windows admite un amplio ecosistema de productos y asociados. Mostrar el logotipo de Windows en el producto representa una relación y un compromiso compartido con la calidad entre Microsoft y su empresa. Los clientes confían en la marca de Windows en el producto porque garantiza que cumple los estándares de compatibilidad y funciona bien en la plataforma Windows. Pasar correctamente la certificación de aplicaciones de Windows permite que la aplicación se muestre en el Centro de compatibilidad de Windows y puede mostrar el logotipo de certificación en su sitio.
El Programa de certificación de aplicaciones de Windows se compone de programas y requisitos técnicos para ayudar a garantizar que las aplicaciones de terceros que llevan la marca de Windows son fáciles de instalar y confiables en equipos que ejecutan Windows. Los clientes valoran la estabilidad, la compatibilidad, la confiabilidad, el rendimiento y la calidad en los sistemas que compran. Microsoft centra sus inversiones en cumplir estos requisitos para las aplicaciones de software diseñadas para ejecutarse en la plataforma Windows para equipos. Estos esfuerzos incluyen pruebas de compatibilidad para la coherencia de la experiencia, el rendimiento mejorado y la seguridad mejorada en equipos que ejecutan software de Windows. Las pruebas de compatibilidad de Microsoft se han diseñado en colaboración con asociados del sector y se han mejorado continuamente en respuesta a los desarrollos del sector y a la demanda de los consumidores.
El Kit para la certificación de aplicaciones de Windows se usa para validar el cumplimiento de estos requisitos y reemplaza las versiones anteriores del kit que se usan para validar en Windows 7, Windows 8 o Windows 8.1. El Kit para la certificación de aplicaciones de Windows es uno de los componentes incluidos en el Kit de desarrollo de software (SDK) de Windows para Windows 10.
Idoneidad de la aplicación
Para que una aplicación cumpla los requisitos de Windows 10 Certificación de aplicaciones de escritorio, debe cumplir los siguientes criterios y todos los requisitos técnicos enumerados en este documento.
- Debe ser una aplicación independiente.
- Debe ejecutarse en un equipo de Windows 10 local.
- Puede ser un componente cliente de una aplicación de Windows Server certificada.
- Debe ser el código y la característica completadas
- No debe comunicarse con las aplicaciones de la Tienda Windows a través de mecanismos locales, incluidos los archivos y las claves del Registro, excepto en los escenarios empresariales admitidos.
- No debe poner en peligro ni poner en peligro la seguridad o la funcionalidad del sistema Windows.
- Debe tener un nombre único y no debe ser marca registrada por otros usuarios
- Todos los componentes externos deben estar certificados por separado o ser compatibles con el Kit de certificación de aplicaciones de Windows
- Debe tener una opción de exclusión para las aplicaciones agrupadas.
Si la aplicación de escritorio se envía a la categoría de productos anti-virus o anti-spyware (es decir, antimalware), debe cumplir con las DIRECTRICES DE LA PLATAFORMA ANTIMALWARE. La LICENCIA Y DESCRIPCIÓN DE LA API ANTIMALWARE DE WINDOWS 10 debe haberse firmado y en vigor antes del envío. El socio debe ser miembro o tener investigadores que sean miembros de y de buena posición en una de las organizaciones enumeradas en el acuerdo. La funcionalidad debe estar certificada en Windows 10 por una de las organizaciones enumeradas en el contrato. La aplicación debe haber sido probada al menos una vez en los últimos 12 meses y certificada para la detección y limpieza.
1. Las aplicaciones son compatibles y resistentes
Las veces en que una aplicación se bloquea o deja de responder provocan mucha frustración del usuario. Se espera que las aplicaciones sean resistentes y estables y eliminen estos errores ayudan a garantizar que el software sea más predecible, fácil de mantener, de alto rendimiento y de confianza.
- 1.1 La aplicación no debe depender de los modos de compatibilidad de Windows, el mensaje AppHelp ni ninguna otra corrección de compatibilidad.
1.2 La aplicación debe tener un manifiesto de compatibilidad y usar los GUID adecuados para las versiones compatibles de Windows
1.3 La aplicación debe ser compatible con PPP mediante el manifiesto de ensamblado de la aplicación en lugar de llamar a SetProcessDPIAware
1.4 La aplicación no debe depender del entorno de ejecución de VB6.
1.5 La aplicación no debe cargar archivos DLL arbitrarios para interceptar las llamadas API de Win32 mediante HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dlls.
2. Las aplicaciones deben cumplir los procedimientos recomendados de seguridad de Windows
El uso de procedimientos recomendados de seguridad de Windows ayudará a evitar la exposición a superficies expuestas a ataques de Windows. Las superficies de ataque son los puntos de entrada que un atacante malintencionado podría usar para aprovechar el sistema operativo aprovechando las vulnerabilidades del software de destino. Una de las peores vulnerabilidades de seguridad es la elevación de privilegios.
Tenga en cuenta que las pruebas 2.1 2.6 solo son aplicables a las aplicaciones de escritorio probadas en Windows 7, Windows 8 o Windows 8.1.
- 2.1 La aplicación debe usar ACL seguras y adecuadas para proteger los archivos ejecutables.
2.2 La aplicación debe usar ACL seguras y adecuadas para proteger los directorios.
2.3 La aplicación debe usar ACL seguras y adecuadas para proteger las claves del Registro
2.4 La aplicación debe usar ACL seguras y adecuadas para proteger los directorios que contienen objetos
2.5 La aplicación debe reducir el acceso no administrador a los servicios que son vulnerables a alteraciones.
2.6 La aplicación debe impedir que los servicios con reinicios rápidos se reinicien más de dos veces cada 24 horas.
Nota: Solo se debe conceder acceso a las entidades que lo requieran.
El Programa de certificación de aplicaciones de Windows comprobará que las superficies expuestas a ataques de Windows no se exponen comprobando que las ACL y los servicios se implementan de forma que no ponga en riesgo el sistema windows.
3. Las aplicaciones admiten características de seguridad de Windows
El sistema operativo Windows tiene muchas características que admiten la seguridad y la privacidad del sistema. Las aplicaciones deben admitir estas características para mantener la integridad del sistema operativo. Las aplicaciones compiladas incorrectamente podrían provocar saturaciones de búfer que, a su vez, pueden provocar la denegación de servicio o permitir la ejecución de código malintencionado.
- 3.1 La aplicación no debe usar AllowPartiallyTrustedCallersAttribute (APTCA) para garantizar el acceso seguro a ensamblados con nombre seguro
3.2 La aplicación debe compilarse con la marca /SafeSEH para garantizar el control de excepciones seguras.
3.3 La aplicación debe compilarse con la marca /NXCOMPAT para evitar la ejecución de datos
3.4 La aplicación debe compilarse con la marca /DYNAMICBASE para la selección aleatoria del diseño del espacio de direcciones (ASLR)
3.5 La aplicación no debe leer y escribir las secciones de PE compartidas
4. Las aplicaciones deben cumplir los mensajes del administrador de reinicio del sistema
Cuando los usuarios inician el apagado, normalmente tienen un gran deseo de ver que el apagado se realiza correctamente; pueden estar en prisa para salir de la oficina y solo quiere que sus ordenadores se apaguen. Las aplicaciones deben respetar este deseo al no bloquear el apagado. Aunque en la mayoría de los casos, es posible que un apagado no sea crítico, las aplicaciones deben estar preparadas para la posibilidad de un apagado crítico.
- 4.1 La aplicación debe controlar correctamente los apagados críticos.
- En un apagado crítico, las aplicaciones que devuelven FALSE a WM_QUERYENDSESSION se enviarán WM_ENDSESSION y se cerrarán, mientras que las que agotan el tiempo de espera en respuesta a WM_QUERYENDSESSION finalizarán.
- WM\_QUERYENDSESSION con LPARAM = ENDSESSION\_CLOSEAPP(0x1).
Las aplicaciones de consola pueden llamar a SetConsoleCtrlHandler para especificar la función que controlará las notificaciones de apagado. Las aplicaciones de servicio pueden llamar a RegisterServiceCtrlHandlerEx para especificar la función que recibirá notificaciones de apagado.
- WM\_ENDSESSION con LPARAM = ENDSESSION\_CLOSEAPP(0x1).
Como mínimo, la aplicación debe prepararse guardando los datos del usuario y guardando la información necesaria después de un reinicio.
5. Las aplicaciones deben admitir una instalación limpia y reversible
Una instalación limpia, reversible, permite a los usuarios administrar correctamente (implementar y quitar) aplicaciones en sus sistemas.
- 5.1 La aplicación debe implementar correctamente una instalación limpia y reversible
- DisplayName
- InstallLocation
- Publicador
- UninstallString
- VersionMajor o MajorVersion
- VersionMinor o MinorVersion
- Si se produce un error en la instalación, la aplicación debería poder revertirla y restaurar la máquina a su estado anterior.
- Reiniciar el equipo nunca debe ser la única opción al final de una instalación, desinstalación o actualización. Los usuarios deben tener la oportunidad de reiniciarse más adelante.
- Las herramientas de inventario de Windows y las herramientas de telemetría requieren información completa sobre las aplicaciones instaladas. Si usa un instalador basado en MSI, MSI crea automáticamente las entradas del Registro siguientes. Si no usa un instalador MSI, el módulo de instalación debe crear las siguientes entradas del Registro durante la instalación:
6. Las aplicaciones deben firmar digitalmente archivos y controladores
Una firma digital Authenticode permite a los usuarios asegurarse de que el software es auténtico. También permite detectar si un archivo ha sido alterado, como si ha sido infectado por un virus. El cumplimiento de la firma de código en modo kernel es una característica de Windows conocida como integridad de código (CI), que mejora la seguridad del sistema operativo comprobando la integridad de un archivo cada vez que la imagen del archivo se carga en la memoria. CI detecta si el código malintencionado ha modificado un archivo binario del sistema. También genera un evento de registro de diagnóstico y auditoría del sistema cuando la firma de un módulo de kernel no se puede comprobar correctamente.
- 6.1 Todos los archivos ejecutables (.exe, .dll, .ocx, .sys, .cpl, .drv, .scr) deben estar firmados con un certificado Authenticode
6.2 Todos los controladores de modo kernel instalados por la aplicación deben tener una firma de Microsoft obtenida a través del programa de certificación de hardware de Windows. Microsoft debe firmar todos los controladores de filtro del sistema de archivos.
6.3 Excepciones y exenciones
- Las exenciones solo se considerarán para los redistribuibles de terceros sin firmar, excepto los controladores. Se requiere una prueba de comunicación que solicite una versión firmada de los redistribuibles para que se conceda esta exención.
7. Las aplicaciones no bloquean la instalación ni el inicio de la aplicación en función de una comprobación de versión del sistema operativo
Es importante que los clientes no estén bloqueados artificialmente para instalar o ejecutar su aplicación cuando no haya limitaciones técnicas. En general, si las aplicaciones se escribieron para Windows Vista o versiones posteriores de Windows, no deben tener que comprobar la versión del sistema operativo.
- 7.1 La aplicación no debe realizar comprobaciones de versión para comprobar si hay igualdad
- Las aplicaciones que se entregan como un paquete que también se ejecutan en Windows 7, Windows 8 y Windows 8.1, y deben comprobar la versión del sistema operativo para determinar qué componentes instalar en un sistema operativo determinado.
- Las aplicaciones que comprueban solo la versión mínima del sistema operativo (solo durante la instalación, no en tiempo de ejecución) mediante solo las llamadas API aprobadas y que enumeran correctamente el requisito de versión mínima en el manifiesto de la aplicación.
- Aplicaciones de seguridad (antivirus, firewall, etc.), utilidades del sistema (por ejemplo, desfragmentación, copias de seguridad y herramientas de diagnóstico) que comprueban la versión del sistema operativo mediante solo las llamadas API aprobadas.
- Si necesita una característica específica, compruebe si la propia característica está disponible. Si necesita Windows 7, busque Windows 7 o posterior (>= 6.2). De este modo, el código de detección seguirá funcionando en versiones futuras de Windows. Los instaladores de controladores y los módulos de desinstalación nunca deben comprobar la versión del sistema operativo.
8. Las aplicaciones no cargan servicios ni controladores en modo seguro
El modo seguro permite a los usuarios diagnosticar y solucionar problemas de Windows. Los controladores y servicios no deben establecerse para cargarse en modo seguro a menos que sean necesarios para las operaciones básicas del sistema de , como controladores de dispositivos de almacenamiento o con fines de diagnóstico y recuperación, como escáneres antivirus, . De forma predeterminada, cuando Windows está en modo seguro, inicia solo los controladores y servicios que se han preinstalado con Windows.
- 8.1 Excepciones y exenciones
- Los conductores y servicios que deben iniciarse en modo seguro requieren una exención. La solicitud de exención debe incluir cada controlador o servicio aplicables escribiendo en las claves del Registro SafeBoot y describir los motivos técnicos por los que la aplicación o el servicio deben ejecutarse en modo seguro. El instalador de la aplicación debe registrar todos estos controladores y servicios mediante estas claves del Registro:
Nota: Debe probar estos controladores y servicios para asegurarse de que funcionan en modo seguro sin errores.
9. Las aplicaciones deben seguir las directrices de control de cuentas de usuario
Algunas aplicaciones de Windows se ejecutan en el contexto de seguridad de una cuenta de administrador y las aplicaciones suelen solicitar derechos de usuario excesivos y privilegios de Windows. Controlar el acceso a los recursos permite a los usuarios controlar sus sistemas y protegerlos frente a cambios no deseados. Un cambio no deseado puede ser malintencionado, como un rootkit que toma el control del equipo, o ser el resultado de una acción realizada por personas que tienen privilegios limitados. La regla más importante para controlar el acceso a los recursos es proporcionar la menor cantidad de acceso al contexto de usuario estándar necesario para que un usuario realice sus tareas necesarias. Las siguientes directrices de control de cuentas de usuario (UAC) proporcionan a una aplicación los permisos necesarios cuando la aplicación los necesita, sin dejar el sistema expuesto constantemente a riesgos de seguridad. La mayoría de las aplicaciones no requieren privilegios de administrador en tiempo de ejecución y deben ejecutarse correctamente como usuario estándar.
- 9.1 La aplicación debe tener un manifiesto que defina los niveles de ejecución e indique al sistema operativo qué privilegios requiere la aplicación para poder ejecutarse.
- Herramientas administrativas o del sistema con el nivel de ejecución establecido en highestAvailable y/o requireAdministrator
- Solo la aplicación de marco de automatización de la interfaz de usuario o accesibilidad establece la marca uiAccess en true para omitir el aislamiento de privilegios de la interfaz de usuario (UIPI). Para iniciar correctamente el uso de la aplicación, esta marca debe estar firmada con Authenticode y debe residir en una ubicación protegida en el sistema de archivos, es decir, Archivos de programa.
- El marcado del manifiesto de la aplicación solo se aplica a los EXE, no a los archivos DLL. Esto se debe a que UAC no inspecciona los archivos DLL durante la creación del proceso. También vale la pena tener en cuenta que las reglas de UAC no se aplican a los servicios de Microsoft. El manifiesto puede ser incrustado o externo.
Para crear un manifiesto, cree un archivo con el nombre <app_name.exe.manifest> y almacénelo en el mismo directorio que exe. Tenga en cuenta que cualquier manifiesto externo se omite si la aplicación tiene un manifiesto interno. Por ejemplo:
<requestedExecutionLevel level=""asInvoker | highestAvailable | requireAdministrator"" uiAccess=""true|false""/>
- Las características administrativas deben moverse a un proceso independiente que se ejecute con privilegios administrativos. Las aplicaciones orientadas al usuario, como las accesibles a través del grupo de programas en el menú Inicio, y que requieren elevación deben estar firmadas con Authenticode.
- Se requiere una exención para las aplicaciones que ejecutan su proceso principal con privilegios elevados (requireAdministrator o highestAvailable). El proceso principal se identifica como el punto de entrada del usuario a la aplicación. Las exenciones se considerarán en los siguientes escenarios:
10. Las aplicaciones deben instalarse en las carpetas correctas de forma predeterminada
Los usuarios deben tener una experiencia coherente y segura con la ubicación de instalación predeterminada de los archivos, al tiempo que mantienen la opción de instalar una aplicación en la ubicación de su elección. También es necesario almacenar los datos de la aplicación en la ubicación correcta para permitir que varias personas usen el mismo equipo sin dañar ni sobrescribir los datos y la configuración de los demás. Windows proporciona ubicaciones específicas en el sistema de archivos para almacenar programas y componentes de software, datos de aplicaciones compartidos y datos de aplicación específicos de un usuario.
- 10.1 La aplicación debe estar instalada en la carpeta Archivos de programa de forma predeterminada
- Claves de ejecución del Registro HKLM y, o HKCU en Software\Microsoft\Windows\CurrentVersion
- Claves de ejecución del Registro HKLM y HKCU en Software\Wow6432Node\Microsoft\windows\CurrentVersion
- Menú Inicio AllPrograms > STARTUP
- Para aplicaciones nativas de 32 y 64 bits en %ProgramFiles%, y %ProgramFiles(x86)% para aplicaciones de 32 bits que se ejecutan en x64. Los datos de usuario o los datos de la aplicación nunca deben almacenarse en esta ubicación debido a los permisos de seguridad configurados para esta carpeta.
- Por ejemplo, la aplicación no debe establecer ninguna de las siguientes opciones;
- Use los métodos correctos para instalar archivos, como fuentes o controladores.
- Cuando se instala la aplicación, no hay ninguna ubicación de usuario correcta en la que almacenar los datos. Los intentos de una aplicación para modificar los comportamientos de asociación predeterminados en un nivel de máquina después de la instalación no se realizarán correctamente. En su lugar, los valores predeterminados se deben reclamar en un nivel por usuario, lo que impide que varios usuarios sobrescriban los valores predeterminados de los demás.
- Se requiere una exención para las aplicaciones que escriben en la memoria caché global de ensamblados (GAC) .NET deben mantener las dependencias de ensamblado privadas y almacenarlas en el directorio de la aplicación a menos que se requiera explícitamente compartir un ensamblado.
11. Las aplicaciones deben admitir sesiones de varios usuarios
Los usuarios de Windows deben poder ejecutar sesiones simultáneas sin conflictos o interrupciones.
- 11.1 La aplicación debe asegurarse de que al ejecutarse en varias sesiones de forma local o remota, la funcionalidad normal de la aplicación no se ve afectada negativamente.
11.2 La configuración y los archivos de datos de la aplicación no deben conservarse entre los usuarios
11.3 Las preferencias y privacidad de un usuario deben estar aisladas en la sesión del usuario.
11.4 Las instancias de la aplicación deben estar aisladas entre sí
- Esto significa que los datos de usuario de una instancia no son visibles para otra instancia de la aplicación. El sonido de una sesión de usuario inactiva no debe escucharse en una sesión de usuario activa. En los casos en los que varias instancias de aplicación usan recursos compartidos, la aplicación debe asegurarse de que no haya ningún conflicto.
- Consulte los requisitos de UAC.
12. Las aplicaciones deben admitir versiones x64 de Windows
A medida que el hardware de 64 bits es más común, los usuarios esperan que los desarrolladores de aplicaciones aprovechen las ventajas de la arquitectura de 64 bits mediante la migración de sus aplicaciones a versiones de 64 bits o que las versiones de 32 bits de la aplicación se ejecuten bien con versiones de 64 bits de Windows.
- 12.1 La aplicación debe admitir de forma nativa 64 bits o, como mínimo, las aplicaciones basadas en Windows de 32 bits deben ejecutarse sin problemas en sistemas de 64 bits para mantener la compatibilidad con versiones de 64 bits de Windows.
12.2 La aplicación y sus instaladores no deben contener ningún código de 16 bits ni confiar en ningún componente de 16 bits
12.3 La configuración de la aplicación debe detectar e instalar los controladores y componentes adecuados para la arquitectura de 64 bits.
12.4 Los complementos de shell deben ejecutarse en versiones de 64 bits de Windows
12.5 La aplicación que se ejecuta en el emulador woW64 no debe intentar subvertir ni omitir los mecanismos de virtualización wow64
- Si hay escenarios específicos en los que las aplicaciones necesitan detectar si se ejecutan en el emulador woW64, deben hacerlo llamando a IsWow64Process.
Conclusión
A medida que evolucionan estos requisitos, observaremos los cambios en el historial de revisiones siguiente. Los requisitos estables son fundamentales para realizar su mejor trabajo, por lo que nos dirigiremos a garantizar que los cambios que realicemos sean sostenibles y continúen protegiendo y mejorando sus aplicaciones.
Gracias de nuevo por unirse a nuestro compromiso con la entrega de excelentes experiencias de los clientes.
Historial de revisiones
| Date | Versión | Descripción de la revisión | Vínculo a documento |
|---|---|---|---|
| 20 de dic, 2011 | 1.0 | Borrador inicial del documento para la versión preliminar. | |
| 26 de enero de 2012 | 1.1 | Actualice a la sección 2. | 1.1 |
| 31 de mayo de 2012 | 1,2 | Se han agregado resultados de pruebas de resumen | 1.2 |
| 29 de junio de 2012 | 3.0 | Windows 8 documento final | 3.0 |
| 18 de junio de 2013 | 3.1 | Windows 8.1 documento | 3.1 |
| 20 de febrero de 2014 | 3.2 | Actualización interna | |
| 18 de marzo de 2014 | 3.3 | Windows 8.1 Update 1 | 3.3 |
| 29 de julio de 2015 | 10 | actualización de Windows 10 | 10 |
Más información sobre la certificación de aplicaciones de escritorio
| Requisito | Descripción |
| Compatibilidad y resistencia | Los bloqueos & bloqueos son una interrupción importante para los usuarios y provocan frustración. Se espera que las aplicaciones sean resistentes y estables, lo que elimina estos errores ayuda a garantizar que el software sea más predecible, fácil de mantener, de alto rendimiento y de confianza. El punto de entrada de la aplicación orientada al usuario debe manifestarse por motivos de compatibilidad, así como declarar el GUID correcto. Los puntos de entrada de la aplicación orientadas al usuario deben manifestarse para el reconocimiento de valores altos de PPP y que se llama a las API adecuadas para admitir valores altos de PPP. Para obtener más información, consulte:
|
| Cumplir los procedimientos recomendados de Seguridad de Windows | El uso de procedimientos recomendados de seguridad de Windows ayudará a evitar la exposición a superficies expuestas a ataques de Windows. Las superficies de ataque son los puntos de entrada que un atacante malintencionado podría usar para aprovechar el sistema operativo aprovechando las vulnerabilidades del software de destino. Una de las peores vulnerabilidades de seguridad es la elevación de privilegios. Para obtener más información, consulte: |
| Características de Seguridad de Windows de soporte técnico | El sistema operativo Windows ha implementado muchas medidas para admitir la seguridad y la privacidad del sistema. Las aplicaciones deben admitir estas medidas para mantener la integridad del sistema operativo. Las aplicaciones compiladas incorrectamente podrían provocar saturaciones de búfer que, a su vez, podrían provocar la denegación de servicio o hacer que el código malintencionado se ejecute. Para obtener más información, consulte la referencia de la herramienta BinScope. |
| Cumplir los mensajes del Administrador de reinicio del sistema | Cuando los usuarios inician el apagado, en la gran mayoría de los casos, tienen un gran deseo de ver que el apagado se realiza correctamente; pueden estar en prisa para salir de la oficina y "sólo quiere" sus ordenadores para apagar. Las aplicaciones deben respetar este deseo al no bloquear el apagado. Aunque en la mayoría de los casos, es posible que un apagado no sea crítico, las aplicaciones deben estar preparadas para la posibilidad de un apagado crítico. |
| Instalación reversible limpia | Una instalación limpia, reversible, permite a los usuarios administrar correctamente (implementar y quitar) aplicaciones en sus sistemas. Para obtener más información, vea How to: Install Prerequisites with a ClickOnce Application. |
| Firmar digitalmente archivos y controladores | Una firma digital Authenticode permite a los usuarios asegurarse de que el software es original. También permite detectar si un archivo se ha alterado, por ejemplo, si ha sido infectado por un virus. La aplicación de firma de código en modo kernel es una característica de Windows conocida como integridad de código (CI), que mejora la seguridad del sistema operativo comprobando la integridad de un archivo cada vez que la imagen del archivo se carga en la memoria. CI detecta si el código malintencionado ha modificado un archivo binario del sistema. También genera un evento de registro de diagnóstico y auditoría del sistema cuando la firma de un módulo kernel no se puede comprobar correctamente. |
| No bloquear la instalación ni el inicio de la aplicación en función de la comprobación de la versión del sistema operativo | Es importante que los clientes no estén bloqueados artificialmente para instalar o ejecutar su aplicación cuando no hay limitaciones técnicas. En general, si las aplicaciones se escribieron para Windows Vista o versiones posteriores, no deberían tener ninguna razón para comprobar la versión del sistema operativo. Para obtener más información, consulte Control de versiones del sistema operativo. |
| No cargar servicios y controladores en modo seguro | El modo seguro permite a los usuarios diagnosticar y solucionar problemas de Windows. A menos que sea necesario para las operaciones básicas del sistema (por ejemplo, controladores de dispositivos de almacenamiento) o con fines de diagnóstico y recuperación (por ejemplo, escáneres antivirus), los controladores y servicios no deben establecerse para cargarse en modo seguro. De forma predeterminada, el modo seguro no inicia la mayoría de los controladores y servicios que no vienen preinstalados con Windows. Deben permanecer deshabilitados a menos que el sistema los requiera para las operaciones básicas o con fines de diagnóstico y recuperación. Para obtener más información, consulte: |
| Seguir las directrices de control de cuentas de usuario (UAC) | Algunas aplicaciones de Windows se ejecutan en el contexto de seguridad de una cuenta de administrador y muchas requieren derechos excesivos de usuario y privilegios de Windows. Controlar el acceso a los recursos permite a los usuarios controlar sus sistemas frente a cambios no deseados (un cambio no deseado puede ser malintencionado, como un rootkit sigilosamente asumir la máquina o una acción de personas que tienen privilegios limitados, por ejemplo, un empleado que instala software prohibido en un equipo de trabajo). La regla más importante para controlar el acceso a los recursos es proporcionar la menor cantidad de acceso al contexto de usuario estándar necesario para que un usuario realice sus tareas necesarias. Siguiendo las directrices de UAC se proporcionan a la aplicación los permisos necesarios cuando sea necesario, sin dejar el sistema expuesto constantemente a riesgos de seguridad. Para obtener más información, consulte: |
| Instalar en las carpetas correctas de forma predeterminada | Los usuarios deben tener una experiencia coherente y segura con la ubicación de instalación predeterminada de los archivos, al tiempo que mantienen la opción de instalar una aplicación en la ubicación que elijan. También es necesario almacenar los datos de la aplicación en la ubicación correcta para permitir que varias personas usen el mismo equipo sin dañar ni sobrescribir los datos y la configuración de los demás. Para obtener más información, consulte Resumen de los requisitos de instalación o desinstalación. |
| Compatibilidad con sesiones multiusuario | Los usuarios de Windows deben poder ejecutar sesiones simultáneas sin conflictos o interrupciones. Para obtener más información, consulte Directrices de programación de Servicios de Escritorio remoto. |
| Compatibilidad con versiones x64 de Windows | A medida que el hardware de 64 bits es más frecuente, los usuarios esperan que los desarrolladores de aplicaciones aprovechen las ventajas de la arquitectura de 64 bits mediante la migración de sus aplicaciones a versiones de 64 bits o que las versiones de 32 bits de la aplicación se ejecuten bien en versiones de 64 bits de Windows. |