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 en Windows Vista
• Acceso a archivos como usuario estándar
• Acceso al Registro como usuario estándar
• Elevación de privilegios
• Implicaciones de UAC con CreateProcess()
• Establecer el nivel de ejecución en el manifiesto de aplicación
• Inserción de un manifiesto en Visual Studio
• Compatibilidad de UAC con juegos más antiguos
• Escenarios y manifiestos heredados
• Conclusión
• Lecturas adicionales

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 ejecutando la gran mayoría de los 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 permiten 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, tiene varias 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 requieren 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, la ejecución de la mayoría de software como usuario estándar limita considerablemente el posible daño 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. La deshabilitación de UAC nunca debe recomendarse 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 del usuario y confirmación 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 para 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.

Nota

La característica Control de cuentas de usuario introducida en Windows Vista también está presente en Windows 7. Aunque la experiencia del usuario en el trabajo con las distintas características del sistema se ha mejorado con respecto al control de cuentas de usuario, el impacto en las aplicaciones es básicamente el mismo. Todas las recomendaciones de Windows Vista de este artículo también se aplican a Windows 7. Para obtener más información sobre los cambios de la interfaz de usuario de UAC para Windows 7, consulta User Interface - User Account Control Dialog Novedades.

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 con privilegios elevados específicamente. Esta diferencia hace que las cuentas del grupo Administradores sean más seguras al reducir el riesgo de seguridad que supone 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 tal cual, aunque se recomienda agregar un manifiesto de aplicación. (Los manifiestos se describen más adelante en este tema en Establecimiento del nivel de ejecución en el manifiesto de aplicación).

Acceso a archivos como usuario estándar

El aspecto del 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. En Windows Vista, por ejemplo, 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 en el sistema de archivos que el sistema operativo usa y promueve para particionar 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 ha declarado un nivel de ejecución solicitado, sus operaciones de escritura se realizarán correctamente, pero estarán sujetas a 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

Nombre de CSIDL	Ruta de acceso típica (Windows Vista)	Derechos de usuario estándar	Derechos de administrador	Ámbito de acceso	Descripción	Ejemplos
CSIDL_PERSONAL	C:\Users\user name\Documents	Lectura/Escritura	Lectura/Escritura	Por usuario	Los archivos de juego específicos del usuario que se leen y modifican y se pueden manipular fuera del contexto del juego.	Capturas de pantalla. Archivos de juego guardados con una asociación de extensión de archivo.
CSIDL_LOCAL_APPDATA	C:\Users\user name\AppData\Local	Lectura/Escritura	Lectura/Escritura	Por usuario	Los archivos de juego específicos del usuario que se leen y modifican y solo se usan dentro del contexto del juego.	Archivos de caché de juegos. Configuraciones del reproductor.
CSIDL_COMMON_APPDATA	C:\ProgramData	Lectura y escritura si es propietario	Lectura/Escritura	Todos los usuarios	Archivos de juego que un usuario puede crear y leer todos los usuarios. El acceso de escritura solo se concede al creador del archivo (propietario).	Perfiles de usuario
CSIDL_PROGRAM_FILES	C:\Archivos de programa or C:\Archivos de programa (x86)	Solo lectura	Lectura/Escritura	Todos los usuarios	Archivos de juego estáticos escritos por el instalador del juego que leen todos los usuarios.	Activos del juego, como materiales y mallas.

El juego normalmente se instalará en una carpeta bajo la carpeta representada por la constante CSIDL_PROGRAM_FILES. Sin embargo, este 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 comprende estas ubicaciones de carpetas conocidas y moverá los datos al actualizar el sistema operativo desde Windows XP; Por el contrario, 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 privilegio. Se debe tener cuidado para crear nombres de ruta de acceso que sean lo suficientemente únicos como para no entrar en conflicto 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 del sistema de archivos. Se permite a un usuario estándar 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 necesita escribir en cualquier ubicación del Registro distinta de HKEY_CURRENT_USER requiere privilegios administrativos.

Si la aplicación de 32 bits no contiene un nivel de ejecución solicitado en su manifiesto, se virtualizarán todas las escrituras en HKEY_LOCAL_MACHINE\Software, 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 los 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 los 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 un administrador, UAC solicita al usuario permiso antes de permitir que el programa se ejecute.

Ilustración 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 del administrador y las claves del Registro 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 (Continuar o Cancelar), estas ubicaciones coincidirán con las ubicaciones del usuario actual. Sin embargo, en general, los procesos que requieren elevación no deben funcionar en los datos por usuario. Tenga en cuenta que esto puede afectar sustancialmente 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 que esté escribiendo muy bien 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 CreateProcess() de Win32 para iniciar un ejecutable que esté configurado para requerir un nivel de ejecución superior al 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(), 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 siguiente etiqueta:

<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 se puede informar a 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. Es muy recomendable que ningún juego requiera privilegios de administrador para ejecutarse, ya que no solo este diálogo se vuelve molesto rápidamente, sino que también hace que el juego sea incompatible con los controles parentales. Piense con mucho cuidado antes de agregar este requisito a cualquier ejecutable.

Una idea equivocada común es que agregar un manifiesto que establece requestedExecutionLevel en "requireAdministrator" omite la necesidad de un aviso de elevación. Esto no es cierto. Simplemente impide que el sistema operativo adivine 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 mostrar el símbolo del sistema de UAC. Un archivo ejecutable grande marcado para la 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, por lo tanto, marcarse como "asInvoker" y cualquier parte que deba marcarse como "requireAdministrator" debe colocarse en un 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 protegido 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 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 <bloque trustInfo> 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.

Nota

Hay un error en la Herramienta de manifiesto (mt.exe) proporcionada por Visual Studio 2005 que da como resultado un manifiesto combinado e incrustado que puede causar problemas cuando el ejecutable se ejecuta en Windows XP antes de SP3. El error es el resultado de cómo la herramienta vuelve a definir el espacio de nombres predeterminado tras la declaración del <bloque trustInfo> . Afortunadamente, es fácil omitir el problema por completo declarando explícitamente un espacio de nombres diferente en el <bloque trustInfo> y estableciendo el ámbito de los nodos secundarios en el nuevo espacio de nombres. El XML proporcionado en la sección anterior muestra esta corrección.

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 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 vinculador /MANIFESTUAC. Establecer estas opciones hará que Visual Studio 2008 genere e inserte automáticamente un manifiesto con el bloque trustInfo> adecuado <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 del 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 estar guardando y cargando un archivo correctamente en el directorio Archivos de programa, sin embargo, ninguna 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 realizaron los cambios necesarios para funcionar correctamente en cuentas de usuario limitadas en Windows XP. Sin embargo, en Windows Vista, estas mismas aplicaciones ahora producirían un error 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á miles de aplicaciones heredadas funcionando bien en Windows Vista sin requerir 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 posteriores del registro o archivo) a una ubicación por usuario dentro del perfil del usuario actual. Por ejemplo, si una aplicación intenta escribir en el archivo siguiente:

C:\\Archivos de programa\\Company Name\\Title\\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 tienen acceso 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 virtualización en aplicaciones de 32 bits solo 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 depender de 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 generación de problemas para 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 el .exe con los elementos de manifiesto UAC correctos y garantizar que la aplicación funcione 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 se marca 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 del manifiesto 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 al iniciarse 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 que diseñes tu juego para que funcione de forma eficaz y responsable. El archivo ejecutable principal del juego no debe depender de privilegios administrativos. Esto no solo evita la apariencia 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 la 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 de Vista.

Lecturas adicionales

Para obtener ayuda con el diseño de aplicaciones para Windows Vista compatibles con el control de cuentas de usuario, descargue las notas del producto siguientes: Requisitos de desarrollo de aplicaciones de Windows Vista para la compatibilidad con el 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 sus aplicaciones para jugar 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 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 ejecutable, vea Explorar manifiestos parte 2: Espacios de nombres predeterminados y manifiestos UAC en Windows Vista en el blog de Chris Jackson en MSDN.