Control de cuentas de usuario para desarrolladores de juegos

En este artículo se describen las directrices y los procedimientos recomendados para que los desarrolladores de juegos trabajen eficazmente con la característica de seguridad Control de cuentas de usuario (UAC) introducida en Windows Vista.

• Información general sobre el control de cuentas de usuario
• cuentas de usuario de en Windows Vista
• acceso a archivos como de usuario estándar
• acceso al Registro como de usuario estándar
• de elevación de privilegios de
• implicaciones de UAC con createProcess()
• Establecer el nivel de ejecución en el manifiesto de aplicación
• insertar un manifiesto en Visual Studio
• compatibilidad con UAC con juegos antiguos
• escenarios y manifiestos heredados
• conclusión
• leer aún más

Información general sobre el control de cuentas de usuario

El Control de cuentas de usuario (UAC), introducido en Windows Vista, es una característica de seguridad diseñada para ayudar a evitar que atacantes malintencionados usen puntos débiles o errores encontrados en aplicaciones ampliamente usadas para modificar el sistema operativo u otros programas instalados. Esto se logra mediante la ejecución de la gran mayoría de programas y procesos como usuario estándar (también conocido como usuario limitado, usuario restringido o usuario Least-Privileged) incluso si la cuenta del usuario actual tiene credenciales administrativas. Un proceso con privilegios de usuario estándar tiene muchas restricciones inherentes que impiden que realice cambios en todo el sistema.

UAC también es responsable de la elevación de privilegios de un proceso mediante el uso de un esquema de autenticación basado en diálogos iniciado tras la ejecución de determinados procesos designados como que requieren privilegios administrativos. La elevación de privilegios permite a los administradores ejecutar la mayoría de sus aplicaciones en un nivel de privilegio seguro (igual que cualquier otro usuario estándar), pero también permitir procesos y operaciones que requieren privilegios administrativos. UAC admite la autenticación sobre el hombro para que un administrador pueda conceder privilegios elevados a un programa mientras un usuario estándar ha iniciado sesión actualmente en el sistema.

La característica UAC está habilitada de forma predeterminada. Aunque es posible que un administrador deshabilite el sistema UAC en todo el sistema, si lo hace, tiene una serie de ramificaciones negativas. En primer lugar, esto debilita la seguridad de todas las cuentas administrativas, ya que todos los procesos se ejecutarían con credenciales administrativas, incluso cuando la mayoría de las aplicaciones no las requieran realmente. Con UAC deshabilitado, una aplicación de usuario estándar que expone una vulnerabilidad aprovechable en la seguridad puede usarse potencialmente para robar información privada, instalar rootkits o spyware, destruir la integridad del sistema o hospedar ataques zombis en otros sistemas. Mientras que con UAC habilitado, ejecutar la mayoría de software como usuario estándar limita considerablemente los posibles daños de este tipo de error. En segundo lugar, desactivar UAC deshabilita muchas de las soluciones alternativas para la compatibilidad de aplicaciones que permiten a los usuarios estándar verdaderos ejecutar correctamente una amplia gama de aplicaciones. No se recomienda deshabilitar UAC nunca como solución alternativa de compatibilidad.

Es importante tener en cuenta que las aplicaciones deben esforzarse por usar solo los derechos de usuario estándar si es posible. Aunque los administradores pueden elevar fácilmente los privilegios de un proceso, la elevación todavía requiere interacción y confirmación del usuario cada vez que se ejecuta una aplicación que requiere credenciales administrativas. Esta elevación también debe realizarse en el momento en que se inicia el programa, por lo que requerir credenciales administrativas incluso para una sola operación requiere exponer el sistema a un mayor riesgo para todo el tiempo de ejecución de la aplicación. Los usuarios estándar sin ninguna capacidad de elevar sus privilegios también son comunes en la configuración familiar y empresarial. "Ejecutar como administrador" no es una buena solución alternativa para la compatibilidad, expone al usuario y al sistema a un mayor riesgo de seguridad y crea frustración para los usuarios en muchas situaciones.

Cuentas de usuario en Windows Vista

Windows Vista clasifica cada usuario en dos tipos de cuenta de usuario: administradores y usuarios estándar.

Una cuenta de usuario estándar es similar a una cuenta de usuario limitada en Windows XP. Al igual que en Windows XP, un usuario estándar no puede escribir en la carpeta Archivos de programa, no puede escribir en la parte HKEY_LOCAL_MACHINE del Registro y no puede realizar tareas que modifiquen el sistema, como instalar un controlador en modo kernel o acceder a espacios de proceso de nivel de sistema.

La cuenta de administrador ha cambiado significativamente desde que se publicó Windows XP. Anteriormente, todos los procesos iniciados por un miembro del grupo Administradores tenían privilegios administrativos. Con UAC habilitado, todos los procesos se ejecutan con privilegios de usuario estándar, a menos que un administrador lo eleva específicamente. Esta diferencia hace que las cuentas del grupo Administradores sean más seguras al reducir el riesgo de seguridad que plantea la mayoría de los errores en la mayoría de los programas.

Es importante que todas las aplicaciones, especialmente juegos, funcionen de forma eficaz y responsable cuando se ejecutan como un proceso de usuario estándar. Todas las operaciones que requieren privilegios administrativos deben realizarse en el momento de la instalación o mediante programas auxiliares que soliciten explícitamente credenciales administrativas. Aunque la elevación de privilegios es bastante trivial para un miembro del grupo Administradores, los usuarios estándar deben aplazar a alguien con credenciales administrativas para escribir físicamente su contraseña para elevar privilegios. Dado que las cuentas protegidas por controles parentales deben ser usuarios estándar, esta será una situación muy común para los jugadores que usan Windows Vista.

Si tu juego ya está trabajando en Windows XP con cuentas de usuario limitadas, el traslado al Control de cuentas de usuario en Windows Vista debería ser muy fácil. La mayoría de estas aplicaciones funcionarán as-is, aunque se recomienda encarecidamente agregar un manifiesto de aplicación. (Los manifiestos se describen más adelante en este tema en Establecer el nivel de ejecución en el manifiesto de aplicación).

Acceso a archivos como usuario estándar

El aspecto de tu juego más afectado por las restricciones de usuario estándar es la organización del sistema de archivos y la accesibilidad. Nunca debes suponer que tu juego puede escribir archivos en la carpeta donde está instalado el juego. Por ejemplo, en Windows Vista, el sistema operativo debe elevar los privilegios de un usuario para que una aplicación pueda escribir en la carpeta Archivos de programa. Para evitar esto, debes clasificar los archivos de datos del juego por ámbito y accesibilidad, y usar la función SHGetFolderPath, junto con las constantes CSIDL proporcionadas por el shell de Windows, para generar las rutas de acceso de archivo adecuadas. Las constantes CSIDL corresponden a carpetas conocidas del sistema de archivos que el sistema operativo usa y promueve para crear particiones de archivos globales y específicos del usuario.

Si la aplicación no tiene privilegios administrativos, se producirá un error al intentar crear o escribir un archivo o directorio en una carpeta que no conceda permiso de escritura al proceso en Windows Vista. Si el ejecutable del juego de 32 bits se ejecuta en modo heredado, ya que no declaraba un nivel de ejecución solicitado, sus operaciones de escritura se realizarán correctamente, pero estarán sujetas a la virtualización, como se describe en la sección "Compatibilidad de UAC con juegos anteriores" más adelante en este artículo.

Tabla 1. Carpetas conocidas

El juego se instalará normalmente en una carpeta bajo la carpeta representada por la constante CSIDL_PROGRAM_FILES. Sin embargo, esto no siempre es el caso. En su lugar, debe usar una ruta de acceso relativa del archivo ejecutable al generar cadenas de ruta de acceso a archivos o directorios ubicados en la carpeta de instalación.

También debe evitar las suposiciones codificadas de forma rígida sobre las rutas de acceso de carpeta conocidas. Por ejemplo, en Windows XP Professional Edition de 64 bits y Windows Vista x64, la ruta de acceso de los archivos de programa es C:\Archivos de programa (x86) para programas de 32 bits y C:\Archivos de programa para programas de 64 bits. Estas rutas de acceso conocidas se cambian de Windows XP y los usuarios pueden volver a configurar la ubicación de muchas de estas carpetas e incluso localizarlas en unidades diferentes. Por lo tanto, use siempre las constantes CSIDL para evitar confusiones y posibles problemas. El programa de instalación de Windows entiende estas ubicaciones de carpetas conocidas y moverá los datos al actualizar el sistema operativo desde Windows XP; En cambio, el uso de ubicaciones no estándar o rutas de acceso codificadas de forma rígida puede producir un error después de una actualización del sistema operativo.

Se debe prestar atención a las sutiles diferencias de facilidad de uso entre las carpetas específicas del usuario especificadas por CSIDL_PERSONAL y CSIDL_LOCAL_APPDATA. La práctica recomendada para seleccionar la constante CSIDL que se va a usar para escribir un archivo es usar CSIDL_PERSONAL si se espera que el usuario interactúe con el archivo, como hacer doble clic en él para abrirlo en una herramienta o aplicación, y usar CSIDL_LOCAL_APPDATA para otros archivos. La aplicación puede aprovechar ambas carpetas para almacenar y organizar archivos de datos específicos del usuario, ya que no hay ninguna diferencia en su ámbito de acceso o nivel de privilegios. Se debe tener cuidado para crear nombres de ruta de acceso que sean lo suficientemente únicos como para no colisionar con otras aplicaciones, pero lo suficientemente corto como para mantener el número de caracteres en la ruta de acceso completa menos que el valor de MAX_PATH, 260.

El código siguiente proporciona un ejemplo de cómo escribir un archivo en una carpeta conocida:

#include <windows.h>
#include <shlobj.h>
#include <shlwapi.h>
        ...
        ...
        ...
        TCHAR strPath[MAX_PATH];
        if( SUCCEEDED(
        SHGetFolderPath( NULL, CSIDL_PERSONAL, NULL, SHGFP_TYPE_CURRENT, strPath ) ) )
        {
        PathAppend( strPath, TEXT( "Company Name\\Title" ) );

        if( !PathFileExists( strPath ) )
        {
        if( ERROR_SUCCESS != SHCreateDirectoryEx( NULL, strPath, NULL ) )
        return E_FAIL;
        }

        PathAppend( strPath, TEXT( "gamefile.txt" ) );

        // strPath is now something like:
        // C:\Users\<current user>\Documents\Company Name\Title\gamefile.txt
        // Open the file for writing
        HANDLE hFile = CreateFile(strPath, GENERIC_WRITE, NULL, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

        if( INVALID_HANDLE_VALUE != hFile )
        {
        // TODO: Write to file
        CloseHandle(hFile);
        }
        }

Acceso al Registro como usuario estándar

El acceso del Registro por parte de un usuario estándar está restringido de forma similar al sistema de archivos. Un usuario estándar tiene permiso de acceso de lectura a todas las claves del Registro; sin embargo, el acceso de escritura solo se concede al subárbol HKEY_CURRENT_USER (HKCU), que se asigna internamente a la subclave específica del usuario HKEY_USERS\Security ID (SID) del usuario actual. Una aplicación que necesite escribir en cualquier ubicación del Registro que no sea HKEY_CURRENT_USER requiere privilegios administrativos.

Si la aplicación de 32 bits no contiene un nivel de ejecución solicitado en su manifiesto, todas las escrituras en HKEY_LOCAL_MACHINE\Software se virtualizarán, mientras que las escrituras en otras ubicaciones fuera de HKEY_CURRENT_USER producirán un error.

No se recomienda almacenar datos persistentes en el Registro, como la configuración de un usuario. El método preferido para almacenar datos persistentes del juego es escribir los datos en el sistema de archivos llamando a SHGetFolderPath y para obtener el valor de una constante CSIDL, descrita en la sección anterior.

Elevación de privilegios

En Windows Vista, cualquier aplicación que requiera privilegios administrativos debe declarar una solicitud para un nivel de ejecución administrativa en su manifiesto (descrito en la sección siguiente, Establecer el nivel de ejecución en el manifiesto de aplicación).

La elevación, como se conoce, es el procedimiento impulsado por UAC para promover un proceso a un proceso administrativo. Los privilegios de un proceso solo se pueden elevar en tiempo de creación. Una vez creado, un proceso nunca se promoverá a un nivel de privilegios superior. Por esta razón. Las operaciones que requieren credenciales administrativas deben aislarse para separar instaladores y otros programas auxiliares.

Tras la ejecución de un programa, UAC inspecciona el nivel de ejecución solicitado en el manifiesto y, si se requieren privilegios elevados, solicita al usuario actual uno de dos cuadros de diálogo estándar: uno para un usuario estándar y otro para un administrador.

Si el usuario actual es un usuario estándar, UAC solicita al usuario las credenciales de un administrador antes de permitir que el programa se ejecute.

Figura 1. Solicitar a un usuario estándar que escriba las credenciales de una cuenta administrativa

Si el usuario actual es administrador, UAC solicita al usuario permiso antes de permitir que el programa se ejecute.

Figura 2. Solicitar a un administrador que autorice los cambios en el equipo

La aplicación solo se concederá privilegios administrativos si un usuario estándar proporciona las credenciales administrativas adecuadas o un usuario administrativo proporciona confirmación; cualquier otra cosa hará que la aplicación finalice.

Es importante tener en cuenta que un proceso con privilegios elevados se ejecuta como el usuario administrativo que escribió las credenciales en el símbolo del sistema de UAC en lugar de como el usuario estándar que ha iniciado sesión actualmente. Esto es similar a RunAs en Windows XP, el proceso con privilegios elevados obtiene la carpeta y las claves del Registro del administrador al acceder a los datos por usuario, y todos los programas que inicia el proceso con privilegios elevados también heredan los derechos administrativos y las ubicaciones de la cuenta de usuario. En el caso de los administradores que se le pidan confirmación (Continue o Cancel), estas ubicaciones coincidirán con las ubicaciones del usuario actual. Sin embargo, en general, los procesos que requieren elevación no deben funcionar en datos por usuario. Tenga en cuenta que esto puede afectar considerablemente a cómo debe funcionar el instalador. Si el instalador, que se ejecuta como administrador, escribe en HKCU o en el perfil de un usuario, puede estar escribiendo en la ubicación incorrecta. Considere la posibilidad de crear estos valores por usuario en la primera ejecución del juego.

Implicaciones de UAC con CreateProcess()

El mecanismo de elevación de UAC no se invocará desde una llamada a la función Win32 CreateProcess() para iniciar un archivo ejecutable que esté configurado para requerir un nivel de ejecución mayor que el proceso actual. Como resultado, se producirá un error en la llamada a CreateProcess() con GetLastError() devolviendo ERROR_ELEVATION_REQUIRED. CreateProcess() solo se realizará correctamente cuando el nivel de ejecución del destinatario sea igual o menor que el del autor de la llamada. Un proceso sin privilegios elevados que debe generar procesos elevados debe hacerlo mediante la función shellExecute() de, lo que hará que el mecanismo de elevación de UAC se desencadene mediante el shell.

Establecer el nivel de ejecución en el manifiesto de aplicación

Declaras el nivel de ejecución solicitado del juego agregando una extensión al manifiesto de la aplicación. El código XML siguiente muestra la configuración mínima necesaria para establecer el nivel de ejecución de una aplicación:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
        <ms_asmv2:security>
            <ms_asmv2:requestedPrivileges>
                <ms_asmv2:requestedExecutionLevel level="asInvoker" uiAccess="false" />
            </ms_asmv2:requestedPrivileges>
        </ms_asmv2:security>
    </ms_asmv2:trustInfo>
</assembly>

En el código anterior, se informa al sistema operativo de que el juego solo requiere privilegios de usuario estándar mediante la etiqueta siguiente:

<ms_asmv2:requestedExecutionLevel level="asInvoker" uiAccess="false" />

Al establecer explícitamente requestedExecutionLevel en "asInvoker", en este ejemplo se afirma en el sistema operativo que el juego se comportará correctamente sin privilegios administrativos. Como resultado, UAC deshabilita la virtualización y ejecuta el juego con los mismos privilegios que el invocador, que suele ser privilegios de usuario estándar, ya que el Explorador de Windows se ejecuta como usuario estándar.

El sistema operativo puede informarse de que un juego requiere elevación a privilegios administrativos reemplazando "asInvoker" por "requireAdministrator", para crear la siguiente etiqueta:

<ms_asmv2:requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

Con esta configuración, el sistema operativo solicita al usuario actual uno de los diálogos de elevación de UAC estándar cada vez que se ejecuta el juego. Se recomienda encarecidamente que ningún juego requiera privilegios de administrador para ejecutarse, ya que no solo este cuadro de diálogo se vuelve molesto, sino que también hace que el juego sea incompatible con los controles parentales. Piense detenidamente antes de agregar este requisito a cualquier archivo ejecutable.

Una idea errónea común es que agregar un manifiesto que establece requestedExecutionLevel a "requireAdministrator" omite la necesidad de un mensaje de elevación. Esto no es cierto. Simplemente impide que el sistema operativo adivina si la aplicación de instalación o actualización necesita privilegios administrativos. Todavía se le pide al usuario que autorice la elevación.

Windows comprueba la firma de cualquier aplicación marcada para la elevación antes de que muestre el símbolo del sistema de UAC. Un archivo ejecutable grande marcado para elevación tarda más tiempo en comprobarse que un archivo ejecutable pequeño y más largo que un ejecutable marcado como "asInvoker". Los ejecutables de instalación que se extraen automáticamente deben marcarse como "asInvoker" y cualquier parte que tenga que marcarse como "requireAdministrator" debe colocarse en un archivo ejecutable auxiliar independiente.

El atributo uiAccess, que se muestra en los ejemplos anteriores, siempre debe ser FALSE para los juegos. Este atributo especifica si los clientes de automatización de la interfaz de usuario tienen acceso a la interfaz de usuario del sistema protegida y tiene implicaciones de seguridad especiales si se establecen en TRUE.

Inserción de un manifiesto en Visual Studio

La compatibilidad con manifiestos se agregó por primera vez a Visual Studio a partir de VS2005. De forma predeterminada, un archivo ejecutable integrado en Visual Studio 2005 (o posterior) tendrá un manifiesto generado automáticamente insertado en él como parte del proceso de compilación. El contenido del manifiesto generado automáticamente depende de determinadas configuraciones de proyecto que especifique en el cuadro de diálogo de propiedades del proyecto.

El manifiesto generado automáticamente por Visual Studio 2005 no contendrá un bloque <trustInfo>, ya que no hay ninguna manera de configurar el nivel de ejecución de UAC en las propiedades del proyecto. La manera preferida de agregar esta información es permitir que VS2005 combine un manifiesto definido por el usuario que contenga el <trustInfo> bloque con el manifiesto generado automáticamente. Esto es tan sencillo como agregar un archivo *.manifest a la solución que contiene el XML enumerado en la sección anterior. Cuando Visual Studio encuentra un archivo .manifest en la solución, invocará automáticamente la Herramienta de manifiesto (mt.exe) para combinar los archivos .manifest con el generado automáticamente.

Una advertencia en el uso de la herramienta mt.exe incluida en Visual Studio 2005 es que generará una advertencia al procesar el bloque trustInfo <>, ya que la herramienta no contiene un esquema actualizado para validar el XML. Para solucionar esta advertencia, se recomienda reemplazar todos los archivos de mt.exe en el directorio de instalación de Visual Studio 2005 (hay varias instancias) por el mt.exe proporcionado en el SDK de Windows más reciente.

A partir de Visual Studio 2008, ahora puede especificar el nivel de ejecución de una aplicación desde el cuadro de diálogo de propiedades del proyecto (figura 3) o mediante la marca del enlazador /MANIFESTUAC. Establecer estas opciones hará que Visual Studio 2008 genere e inserte automáticamente un manifiesto con el <trustInfo adecuado> bloque en el ejecutable.

Figura 3. Establecimiento del nivel de ejecución en Visual Studio 2008

La inserción de un manifiesto en versiones anteriores de Visual Studio sin compatibilidad con manifiestos sigue siendo posible, pero requiere más trabajo para el desarrollador. Para obtener un ejemplo sobre cómo hacerlo, examine el proyecto de Visual Studio 2003 incluido en cualquier ejemplo del SDK de DirectX antes de la versión de marzo de 2008.

Compatibilidad de UAC con juegos anteriores

Si tu juego parece guardar y cargar un archivo correctamente en el directorio Archivos de programa, aún no hay evidencia del archivo iOn Windows Vista, cualquier aplicación de 32 bits que no contenga un nivel de ejecución solicitado en su manifiesto se considera una aplicación heredada. Antes de Windows Vista, la mayoría de las aplicaciones se ejecutaban normalmente por los usuarios con privilegios administrativos. Como resultado, estas aplicaciones podían leer y escribir libremente archivos del sistema y claves del Registro, y muchos desarrolladores no hicieron los cambios necesarios para funcionar correctamente en cuentas de usuario limitadas en Windows XP. Sin embargo, en Windows Vista, ahora se produciría un error en estas mismas aplicaciones debido a privilegios de acceso insuficientes en el nuevo modelo de seguridad, lo que exige la ejecución de usuarios estándar para las aplicaciones heredadas. Para mitigar el impacto de esto, la virtualización también se agregó a Windows Vista. La virtualización mantendrá a miles de aplicaciones heredadas funcionando bien en Windows Vista sin necesidad de que esas aplicaciones tengan privilegios elevados en todo momento simplemente para tener éxito en algunas operaciones secundarias. s found, chances are your game is running in legacy mode and was subjected to virtualization.

La virtualización afecta al sistema de archivos y al registro mediante la redirección de escrituras sensibles al sistema (y operaciones de registro o archivos posteriores) a una ubicación por usuario dentro del perfil del usuario actual. Por ejemplo, si una aplicación intenta escribir en el siguiente archivo:

C:\\Archivos de programa\\Nombre de la compañía\\Título\\config.ini

la escritura se redirige automáticamente a:

C:\\Users\\user name\\AppData\\Local\\VirtualStore\\Program Files\\Company Name\\Title\\config.ini

Del mismo modo, si una aplicación intenta escribir un valor del Registro como el siguiente:

HKEY\_LOCAL\_MACHINE\\Software\\Company Name\\Title

se redirigirá en su lugar a:

HKEY\_CURRENT\_USER\\Software\\Classes\\VirtualStore\\MACHINE\\Software\\Company Name\\Title

Las operaciones de archivo y registro de las aplicaciones virtualizadas que se ejecutan como usuario actual solo acceden a los archivos y las claves del Registro afectadas por la virtualización.

Sin embargo, hay muchas restricciones para la virtualización. Una es que las aplicaciones de 64 bits nunca se ejecutan en modo heredado para las operaciones de compatibilidad sujetas a la virtualización en aplicaciones de 32 bits simplemente producirán un error en 64 bits. Además, si una aplicación heredada que se ejecuta como usuario estándar intenta escribir cualquier tipo de archivo ejecutable en una ubicación que requiera credenciales administrativas, no se producirá la virtualización y se producirá un error en la escritura.

Figura 4. Proceso de virtualización

Cuando una aplicación heredada intenta realizar una operación de lectura en ubicaciones sensibles al sistema en el sistema de archivos o en el registro, primero se buscan las ubicaciones virtuales. Si no se encuentra el archivo o la clave del Registro, el sistema operativo accede a las ubicaciones predeterminadas del sistema.

La virtualización se quitará de las versiones posteriores de Windows, por lo que es importante no confiar en esta característica. En su lugar, debe configurar explícitamente el manifiesto de aplicación para privilegios administrativos o de usuario estándar, ya que esto deshabilitará la virtualización. La virtualización tampoco es obvia para los usuarios finales, por lo que aunque la virtualización pueda permitir que la aplicación se ejecute, puede generar llamadas de soporte técnico y dificultar la ejecución de estos clientes.

Tenga en cuenta que si UAC está deshabilitado, la virtualización también está deshabilitada. Si la virtualización está deshabilitada, las cuentas de usuario estándar se comportan exactamente igual que las cuentas de usuario limitadas en Windows XP y es posible que las aplicaciones heredadas no funcionen correctamente para los usuarios estándar que, de lo contrario, se habrían realizado correctamente debido a la virtualización.

Escenarios y manifiestos heredados

Para la mayoría de los escenarios de uso, basta con marcar la .exe con los elementos de manifiesto UAC correctos y asegurarse de que la aplicación funciona correctamente como un usuario estándar es suficiente para una excelente compatibilidad con UAC. La mayoría de los jugadores ejecutan Windows Vista o Windows 7 con el control de cuentas de usuario habilitado. Para Windows XP y los usuarios de Windows Vista o Windows7 con la característica Control de cuentas de usuario deshabilitada, normalmente se ejecutan con cuentas de administrador. Aunque se trata de un modo de operación menos seguro, generalmente no se encontrará con ningún problema de compatibilidad adicional aunque, como se indicó anteriormente, deshabilitar UAC también deshabilita la virtualización.

Hay un caso especial que merece la pena tener en cuenta cuando el programa está marcado como "requireAdministrator" en el manifiesto de UAC. En Windows XP y en Windows Vista o Windows 7 con control de cuentas de usuario deshabilitado, el sistema omite los elementos de manifiesto de UAC. En esta situación, los usuarios con cuentas de administrador siempre ejecutarán todos los programas con derechos de administrador completos y, por tanto, estos programas funcionarán según lo previsto. Sin embargo, los usuarios restringidos de Windows XP y los usuarios estándar que se ejecutan en Windows Vista o Windows 7, siempre ejecutarán estos programas con derechos restringidos y se producirá un error en todas las operaciones de nivel de administrador. Por lo tanto, se recomienda que los programas marcados como "requiretAdministrator" llamen a IsUserAnAdmin en el inicio y muestren un mensaje de error irrecuperable si devuelve FALSE. Para el escenario de mayoría anterior, esto siempre se realizará correctamente, pero proporciona una mejor experiencia de usuario y un mensaje de error claro para esta situación poco frecuente.

Conclusión

Como desarrollador de juegos destinado al entorno multiusuario de Windows, es imperativo diseñar el juego para que funcione de forma eficaz y responsable. El archivo ejecutable principal del juego no debe depender de privilegios administrativos. Esto no solo impide la aparición de mensajes de elevación cada vez que se ejecuta el juego, lo que puede afectar negativamente a la experiencia general del usuario, sino que también permite que el juego aproveche otras características que requieren ejecución con privilegios de usuario estándar, como controles parentales.

Las aplicaciones que están diseñadas correctamente para funcionar como con las credenciales de un usuario estándar (o usuario limitado) en versiones anteriores de Windows no se verán afectadas por UAC que se ejecutarán sin elevación. Sin embargo, deben incluir un manifiesto con su nivel de ejecución solicitado establecido en "asInvoker" para cumplir los estándares de aplicación para Vista.

Lectura adicional

Para obtener ayuda con el diseño de aplicaciones para Windows Vista que son compatibles con el control de cuentas de usuario, descargue las siguientes notas del producto: Requisitos de desarrollo de aplicaciones de Windows Vista para la compatibilidad de control de cuentas de usuario.

En este documento técnico se proporcionan pasos detallados sobre el proceso de diseño, junto con ejemplos de código, requisitos y procedimientos recomendados. En este documento también se detallan las actualizaciones técnicas y los cambios en la experiencia del usuario en Windows Vista.

Para obtener más información sobre el Control de cuentas de usuario, visite Windows Vista: Control de cuentas de usuario en Microsoft TechNet.

Otro recurso útil es el artículo Enseñar tus aplicaciones para jugar bien con el control de cuentas de usuario de Windows Vista, de MSDN Magazine, enero de 2007. En este artículo se describen los problemas generales de compatibilidad de aplicaciones, así como las ventajas y los problemas de uso de paquetes de Windows Installer en Windows Vista.

Para obtener más información sobre el error y la corrección de mt.exe, la herramienta usada por Visual Studio 2005 para combinar e insertar automáticamente un manifiesto en un archivo ejecutable, vea Exploración de manifiestos parte 2: Espacios de nombres predeterminados y manifiestos de UAC en Windows Vista en el blog de Chris Jackson en MSDN.