ES2582164T3 - Capa de abstracción y protección del sistema operativo - Google Patents

Abstract

Un sistema para crear un entorno de software de aplicación sin cambiar un sistema (10) operativo de un equipo cliente, comprendiendo el sistema una capa (100) de abstracción y protección de sistema operativo, en el que dicha capa de abstracción y protección está interpuesta entre una aplicación (50, 52, 54) de software en ejecución y dicho sistema operativo, por lo que se proporciona un entorno virtual en el que pueden ejecutarse una aplicación y por lo que dicho sistema operativo es un sistema operativo Windows que comprende un registro de Windows, en el que la capa de abstracción y protección de sistema operativo responde con una clave y su valor si dicha clave y el valor se almacenan dentro de la capa de abstracción y protección de sistema operativo, si no se almacenan, la capa de abstracción y protección de sistema operativo permite la solicitud para pasar a través del registro de Windows.

Description

5

10

15

20

25

30

35

40

45

50

55

DESCRIPCION

Capa de abstraccion y proteccion del sistema operativo

La presente invencion se refiere a un software informatico, y mas espedficamente a un software de sistema operativo.

Antecedentes de la invencion

En muchos entornos, pero sobre todo en entornos en los que una aplicacion se presenta a traves de una red, la caractenstica mas importante es la capacidad de ejecutar aplicaciones sobre la marcha, sin una instalacion compleja. Por lo general, en ciertos sistemas de la tecnica anterior, se han hecho grandes esfuerzos para modificar un sistema cliente para aparecer como si un programa estuviese instalado, o para instalar realmente el software en sf mismo, y a continuacion volver atras estas modificaciones para restaurar la configuracion original. Al hacer esto, se presentan multiples problemas: conflictos entre una aplicacion y la configuracion actual del equipo, multiples instancias de las mismas o diferentes aplicaciones, la complejidad del procedimiento de volver atras requiere que una aplicacion se ponga a traves de un procedimiento riguroso para garantizar que todas sus modificaciones puedan tenerse en cuenta, y el uso de archivos compartidos y componentes del sistema por multiples aplicaciones complica la vuelta atras y el procedimiento de instalacion.

Sumario de la invencion

Es el objeto de la presente invencion mantener la integridad del sistema. Este objeto se resuelve mediante el objeto de la reivindicacion independiente. Las realizaciones preferidas estan definidas por las reivindicaciones dependientes.

La presente invencion proporciona un sistema para crear un entorno de software de aplicacion sin cambiar un sistema operativo de un equipo cliente, comprendiendo el sistema una capa de abstraccion y proteccion de sistema operativo, en el que dicha capa de abstraccion y proteccion esta interpuesta entre una aplicacion de software en ejecucion y dicho sistema operativo, por lo que se proporciona un entorno virtual en el que una aplicacion puede ejecutarse y se eliminan sustancialmente las interacciones a nivel de aplicacion. Preferentemente, cualquier cambio directamente en el sistema operativo se realiza de manera selectiva dentro del contexto de la aplicacion en ejecucion y la capa de abstraccion y proteccion cambia de manera dinamica el entorno virtual de acuerdo con la configuracion administrativa. Ademas, en ciertas realizaciones, el sistema monitoriza continuamente el uso de los recursos y los actos del sistema compartidos como un servicio de aplicar y quitar los cambios a los componentes del sistema.

Asf, por ejemplo, en las realizaciones dentro de los sistemas operativos basados en Windows, y en los que todas las operaciones en el registro de Windows son a traves de la API de Win32, el sistema proporciona preferentemente un medio para las funciones de interceptacion, por lo que cada vez que se invocan dichas funciones otra funcion o aplicacion intercepta la llamada, y el sistema intercepta mas preferentemente cada funcion API adecuada para dar servicio a una solicitud si se hace por una aplicacion ejecutada desde un servidor o si se hace por una aplicacion contra una clave de configuracion que se administra activamente.

En otras realizaciones preferidas de la presente invencion, se proporciona una funcionalidad adicional, tal como estas realizaciones en las que la capa de abstraccion y proteccion de sistema operativo administra la integracion de multiples instancias de una aplicacion reconociendo cuantas instancias de una aplicacion estan en ejecucion, y en tales realizaciones mas preferentemente se evita hacer cambios en el arranque y el apagado a menos que solo haya una instancia de la aplicacion en ejecucion. En esta realizacion es posible tambien soportar los sistemas operativos multiusuario en los que pueden estar en ejecucion multiples instancias de una aplicacion en nombre de los diferentes usuarios.

Por lo tanto, la capa de abstraccion y proteccion de sistema operativo presenta al entorno a una aplicacion que parece ser un entorno de instalacion sin realizar una instalacion, por lo que se crea una “pseudo instalacion” en la que todos las configuracion se ponen en un entorno virtual en el momento de ejecutar la aplicacion. O en el caso de una aplicacion instalada, actua para modificar dinamicamente el comportamiento de la aplicacion en el tiempo de ejecucion. Las realizaciones preferidas proporcionan un medio para evitar que la informacion en el equipo cliente interfiera o modifique el comportamiento de una aplicacion, y lo mas preferentemente proporciona un medio para cambiar dinamicamente el entorno virtual de acuerdo con las configuraciones administrativas. Como se ha mencionado anteriormente, en ciertas realizaciones sera posible tener mas de una instancia de una unica aplicacion de software en ejecucion en el mismo equipo cliente, incluso si originalmente no se autorizo a hacerlo. En tales realizaciones, se proporcionan contextos compartidos y controlados en los que al menos dos de dichas instancias de una unica aplicacion comparten una o mas configuraciones virtuales.

El documento US 5.752.005 describe un equipo que incluye un sistema operativo que tiene un administrador de sistema y un sistema de archivos nativo. Un sistema de archivos instalable instala unas interceptaciones en una interfaz central entre el administrador de sistema y el sistema de archivos nativo. Las interceptaciones se instalan en solo una parte de las muchas rutinas de funcion nativas proporcionadas por el sistema de archivos nativo. Un

controlador virtual se comunica con el sistema de archivos nativo y Simula un dispositivo de almacenamiento de archivos que no tiene substancialmente ningun archivo almacenado en el mismo. El dispositivo de sistema de archivo externo solicita que las rutinas de funcion que no se ha interceptado se manejen por el sistema de archivos nativo y el dispositivo virtual. El dispositivo de sistema de archivo externo solicita que las rutinas de funcion 5 interceptadas se manejen por un sistema de archivo externo.

El documento US 6.026.402 describe un procedimiento y un aparato para restringir un procedimiento o jerarqrna de procedimientos para un subconjunto del sistema(s) de archivos de un equipo central en un entorno en el que todos los sistemas de archivos estan disponibles al mismo tiempo para una aplicacion. Una persona que llama esta provista de la capacidad de organizar la restriccion de una jerarqrna de procedimientos (que consiste en un 10 procedimiento y todos los procedimientos que pueden crearse posteriormente) para un conjunto de subjerarqmas de sistemas de archivos. Cuando se ejecuta un procedimiento dentro de un dominio de restriccion en el que se ha especificado una subjerarqma para cada uno de los sistemas de archivos disponibles, una realizacion modificara el funcionamiento habitual de la interfaz de sistema operativo del equipo central de tal manera que cualquier intento de acceso al sistema de archivos por el procedimiento afectado esta obligado a producirse logicamente dentro del 15 dominio de restriccion.

Breve descripcion de los dibujos

La figura 1 es un diagrama de bloques esquematico que muestra la relacion relativa de la presente invencion, un sistema operativo y una aplicacion de software;

La figura 2 es un diagrama de bloques esquematico que muestra

20 La figura 3 es un diagrama de bloques esquematico que muestra

La figura 4 es un diagrama de bloques esquematico que muestra

Descripcion detallada de las realizaciones preferidas

Haciendo referencia ahora a la figura 1, se ilustra un diagrama de bloques esquematico que muestra la relacion relativa de la presente invencion, un sistema operativo y una aplicacion de software. Las realizaciones preferidas de 25 la presente invencion proporcionan una capa 100 de abstraccion y proteccion de sistema operativo denominada “restriccion de sistema operativo”. Internamente, muchos sistemas 10 operativos proporcionan dominios de fallo para proteger las aplicaciones 50 de afectarse entre sf cuando se ejecutan. Sin embargo, los recursos de sistema compartidos y muchas otras caractensticas de sistema operativo permiten que este dominio de proteccion se vea comprometido. Una capa 100 de abstraccion y proteccion de sistema operativo proporcionara una barrera adicional 30 controlada mediante programacion entre las aplicaciones 50 para eliminar la mayona de las interacciones a nivel de aplicacion. Dispuesta entre la aplicacion 50 y el sistema 10 operativo, la capa 100 de abstraccion y proteccion de sistema operativo permite selectivamente cambios directamente en el sistema 10 operativo, frente a contener el cambio dentro del contexto de la aplicacion en ejecucion. Como un ejemplo, en los sistemas basados en Windows, todas las operaciones en el registro de Windows se realizan normalmente a traves de la API de Win32. Como se 35 explica a continuacion, las funciones de sistema como QueryRegEx y GetProfileString pueden interceptarse de tal manera que cada vez que se invocan, otra funcion o aplicacion intercepta la llamada. La restriccion 100 de sistema operativo de la presente invencion interceptara cada funcion API adecuada para dar servicio a la solicitud, si se hace por una aplicacion que se administra activamente o si se hace por una aplicacion contra un elemento de configuracion que se administra activamente. De esta manera, a menos que se configure explfcitamente para 40 hacerlo asf, la presente invencion puede crear el entorno de aplicacion sin realizar cambios reales en el sistema del usuario final. Por lo tanto, cualquier modificacion que se realice en tiempo de ejecucion por la aplicacion puede persistirse o eliminarse facilmente.

Como se usa en el presente documento, la expresion “restriccion de sistema operativo”, define una capa entre una aplicacion en ejecucion y el sistema operativo de un equipo de destino o equipo cliente que proporciona un entorno 45 virtual en el que la aplicacion puede ejecutarse. Este entorno virtual tiene diversos fines. En primer lugar, evita que una aplicacion en ejecucion realice cambios en el equipo cliente. Si una aplicacion intenta cambiar la configuracion de sistema operativo subyacente de un equipo cliente, tal configuracion esta protegida y solo se “realiza” en el entorno virtual. Por ejemplo, si una aplicacion intenta cambiar la version de un objeto compartido como MSVCRT.DLL, este cambio se localiza en la aplicacion y el codigo residente en el equipo cliente se deja intacto.

50 En segundo lugar, la invencion presenta un entorno para una aplicacion en ejecucion que parece ser un entorno de instalacion sin realizar una instalacion, y es, por lo tanto, una “pseudo instalacion” o “como una instalacion”. Todas las configuraciones se ponen en un entorno virtual en el momento en que la aplicacion se sirve en ejecucion, o justo en el momento cuando la aplicacion necesita una configuracion espedfica. Por ejemplo, si un programa de ordenador tal como Adobe Photoshop® espera ver un conjunto de entradas del registro de Windows bajo 55 HKEY_LOCAL_MACHINE\Software\Adobe y no estan allf en el equipo cliente ya que Photoshop nunca se ha instalado, un sistema realizado de acuerdo con este aspecto de la presente invencion “mostrara” esas entradas de registro en el codigo de programacion Photoshop exactamente como si estuvieran residentes en el equipo cliente.

5

10

15

20

25

30

35

40

45

50

55

A continuacion, la invencion evita que la informacion que puede existir en la maquina cliente/usuarios interfiera con o modifique el comportamiento de una aplicacion. Por ejemplo, si el usuario tiene ya las entradas del registro que existen bajo:

HKEY_LOCAL_MACHINE\Software\Adobe

para una version anterior de Photoshop, pero ahora desea hacer funcionar una version mas reciente, esas entradas pueden ocultarse a la nueva aplicacion para evitar conflictos.

Finalmente, la presente invencion desbloquea el comportamiento de aplicacion que puede no existir cuando la aplicacion se escribe actualmente. Esto se hace a traves de la capacidad para cambiar dinamicamente el entorno virtual de acuerdo con las configuraciones administrativas. Por ejemplo, en una instancia tfpica de una aplicacion de software empresarial, una aplicacion cliente puede esperar para leer una configuracion de la direccion de la base de datos a la que el usuario debena conectarse a partir de una configuracion en el registro. Debido a que esta clave de registro se almacena a menudo en HKEY_LOCAL_MACHINE, la configuracion es global para todo el equipo cliente. Un usuario solo puede conectarse a una base de datos sin reinstalar el cliente, o sabiendo como modificar esta clave de registro, y hacerlo cada vez que se desee ejecutar la aplicacion. Sin embargo, implementando la presente invencion, ahora pueden ejecutarse dos instancias de la aplicacion en el mismo equipo cliente, cada una conectada a una base de datos diferente.

CONTEXTOS

Al proporcionar esta funcionalidad, cada aplicacion es capaz de ejecutarse en un contexto privado dentro del sistema. Para la aplicacion, esto tiene su propia vista privada de lo que parecen el sistema y su comportamiento. La presente invencion proporciona esto por su naturaleza inherente. Haciendo referencia a la figura 2, pueden proporcionarse dos aplicaciones separadas 52, 54, o dos instancias de la misma aplicacion (50 ilustradas en la figura 1), en contextos privados en los que pareceran tener copias separadas o diferentes de los servicios, la configuracion y los datos del sistema. En la realizacion preferida, este es el comportamiento por defecto del sistema.

Con la extension de este concepto, la restriccion 100 de sistema operativo de la presente invencion puede proporcionar tambien unos contextos compartidos y controlados en los que dos o mas aplicaciones 52, 54 pueden compartir alguna o la totalidad de sus configuraciones virtuales. Esto es importante para los conjuntos de aplicaciones tales como Microsoft Office, o para las aplicaciones que se comportan de manera diferente en la presencia de otras aplicaciones. Por ejemplo, muchas aplicaciones utilizan Microsoft Word como el motor para hacer la combinacion de correspondencia o la funcionalidad de creacion de documentos. La aplicacion debe conocer la instalacion o la presencia de Word y ser capaz de acceder a sus funciones. En la realizacion preferida, dos instancias de la misma aplicacion compartiran un unico contexto por defecto, mientras que dos aplicaciones individuales mantendran contextos privados. Haciendo referencia a la figura 3, las dos aplicaciones 52, 54 pueden ejecutarse mientras que la restriccion 100 de sistema operativo proporciona una vision compartida de los recursos disponibles del sistema.

DISENO

Como se ilustra en la figura 4, la restriccion de sistema operativo esta compuesta por los siguientes subsistemas: un nucleo 102, un administrador 104 de configuracion, un administrador 106 de archivos, un administrador 108 de objetos compartidos, un administrador 110 de dispositivos, un administrador 112 de fuentes, un administrador 120 de procedimientos, un administrador 114 de entorno de procedimientos, un cargador 116, y un administrador 118 de recuperacion. Con la excepcion del nucleo 102, el administrador 120 de procedimientos, y el cargador 116, todos los demas subsistemas son elementos del sistema de virtualizacion descrito con mas detalle a continuacion. El nucleo 102 es el principal responsable de la administracion de las aplicaciones y su contexto como se define en los archivos de configuracion.

El administrador 120 de procedimientos proporcionado por la restriccion de sistema operativo permite que se informe al nucleo 102 de cualquier procedimiento o evento de subprocedimiento que pueda ser de interes. Esto tambien proporciona una capa de abstraccion a las implementaciones dependientes del sistema operativo para administrar un espacio de procedimiento y manejar el procesamiento de subprocedimientos. Los procedimientos pueden agruparse entre sf en paquetes de aplicaciones. Un paquete de aplicaciones es un grupo de procedimientos en el que todos comparten sus recursos virtuales entre sf. Por ejemplo, Microsoft Word y Microsoft Excel pueden querer compartir el registro virtual y el sistema de archivos virtual para poder trabajar juntos como un conjunto de aplicaciones. El administrador 120 de procedimientos llama a esos paquetes de aplicaciones “aplicaciones”. La informacion acerca de una aplicacion existe hasta que se le dice al administrador 120 de procedimientos que libere la aplicacion. Si otro procedimiento necesita cargarse en el paquete de aplicacion, puede hacerlo siempre y cuando no se haya liberado la aplicacion.

El subsistema 116 cargador de la presente invencion se usa para permitir que los entornos virtuales se transfieran dentro y fuera del sistema en ejecucion. Cada uno de los subsistemas de virtualizacion es capaz de serializar su configuracion para el cargador 116, y recuperarla a traves del procedimiento inverso. Ademas, el cargador 116 es capaz de realizar fases de carga/descarga y combinar los resultados de las fases individuales en una unica

5

10

15

20

25

30

35

40

45

50

55

descripcion de entorno.

REGISTRO Y CONFIGURACION

Las aplicaciones requieren cantidades variables de informacion de configuracion para funcionar correctamente. En cualquier lugar existen de cero a miles de registros de configuracion para los que una aplicacion puede leer su configuracion. En Windows, hay dos lugares comunes para la informacion de configuracion, el registro de Windows y los archivos de inicializacion a nivel de sistema win.ini y system.ini. Ademas, el directorio \WINDOWS\SYSTEM es un lugar comun para que las aplicaciones escriban la configuracion espedfica de aplicacion o los archivos de inicializacion. Las aplicaciones usaran tambien los archivos de configuracion o de datos en sus directorios de aplicacion locales para almacenar la informacion de configuracion adicional. A menudo, esta informacion es diffcil de tratar, ya que esta en un formato propietario. En las plataformas que no sean Windows, no existe un equivalente del registro, pero existen directorios comunes para la informacion de configuracion. X Windows tiene un directorio de aplicaciones por defecto (app-defaults). Macintosh tiene la carpeta de sistema (System Folder), y otros sistemas operativos tendran los elementos correspondientes. Es importante observar que en la mayona de los sistemas UNIX, cada aplicacion 52, 54 individual almacenara lo mas a menudo su propia configuracion 152, 154 localmente, como se ve en la figura 2.

La presente invencion, en una realizacion, incluye un componente virtual de registro de Windows, que proporcionara un registro de funcion completo a una aplicacion, pero evita la modificacion del registro de sistema subyacente. Todas las claves que una aplicacion espera acceder estaran presentes, pero solo pueden existir en el registro virtual. De esta manera, la restriccion 100 de sistema operativo de la presente invencion y el registro de Windows forman un procedimiento de dos fases para acceder al registro. Si una aplicacion necesita acceder a una clave, consultara al registro. La restriccion de sistema operativo respondera con la clave y su valor si la conoce. De lo contrario, permitira que la solicitud pase a traves del registro de Windows. Si se hace un intento de modificar el valor, la restriccion de sistema operativo permitira que se produzca la modificacion solamente sobre sf misma. La proxima vez que la aplicacion acceda a la clave, estara presente en la restriccion de sistema operativo y la solicitud no fluira a traves del registro real, dejandolo intacto.

Las claves que usan la restriccion de sistema operativo se especifican en tres secciones individuales. Estas claves de restriccion de sistema operativo se especifican como comandos en esas secciones para modificar una clave existente, eliminar la presencia de una clave, o anadir una nueva clave al registro. De esta manera, el registro virtual puede aparecer exactamente como las intenciones de sistema. Esto es importante cuando la presencia o la ausencia de una clave pueden ser tan importantes como el valor real de la clave.

En la realizacion preferida, la restriccion de sistema operativo carga primero un archivo de datos que contiene unas entradas de registro basicas para la aplicacion. A continuacion, se carga un segundo archivo de datos que contiene las preferencias del usuario. Por ultimo, la restriccion de sistema operativo puede cargar opcionalmente, un conjunto de claves que incluye elementos de polttica que el usuario no esta autorizado a anular. Los tres archivos se cargan uno encima de otro con elementos duplicados en cada archivo anulando los elementos del archivo anterior al mismo. La primera vez que un usuario ejecuta la aplicacion, el segundo archivo de datos no existe, porque no habra informacion espedfica del usuario, solo las predeterminadas de aplicacion. Despues de cada sesion, sin embargo, la restriccion de sistema operativo guardara los cambios del usuario, generando este segundo archivo de datos para su uso en sesiones futuras.

Los archivos de configuracion pueden modificarse de dos maneras. En primer lugar, el archivo puede editarse directamente por una aplicacion. En este escenario, el subsistema de archivos de restriccion de sistema operativo descrito a continuacion abordara la modificacion realizada en el archivo. En segundo lugar, en la realizacion preferida, un aplicacion puede llamar a la familia de llamadas API de Windows GetProfileString, WriteProfileString, u otras para modificar estos archivos. En este caso, la restriccion de sistema operativo de la presente invencion se realiza exactamente como se ha descrito anteriormente interceptando esas llamadas y dandolas servicio desde dentro.

OBJETOS COMPARTIDOS

Muchos componentes usados por los sistemas operativos y las aplicaciones en ejecucion se comparten entre varias aplicaciones o instancias. En general, esta es una muy buena idea. Se ahorra espacio en disco, no requiriendo muchas copias del mismo archivo. Tambien proporciona la capacidad para los proveedores de sistemas operativos y de terceros de crear y distribuir bibliotecas de codigo usado comunmente. En la plataforma Windows, las bibliotecas de enlaces dinamicos, DLL, se comparten a menudo dentro y a traves de las aplicaciones. En otras plataformas, el problema es el mismo. En Macintosh, los INIT y otros componentes del sistema se cargan para las aplicaciones. Estos componentes pueden tener muchas versiones, de las cuales solo se usa una a la vez. En los sistemas UNIX, los objetos compartidos dinamicos, por ejemplo, los archivos de biblioteca “.so”, se usan por las aplicaciones para acelerar el tiempo de carga, ahorrar espacio en disco, y por otras razones. Muchos programas usan el “libc.so” por defecto. Sin embargo, este archivo de biblioteca es normalmente un enlace simbolico a alguna version de sf mismo: como libC.so.3. En la practica, esta caractenstica ha hecho estragos. Estos componentes compartidos han ido a menudo a traves de una revision, con muchas versiones del mismo componente disponible para instalarse. Los

5

10

15

20

25

30

35

40

45

50

55

autores de aplicaciones han descubierto que su software trabaja potencialmente con solo una o algunas de las versiones del componente compartido. Por lo tanto, en la practica, las aplicaciones instalan normalmente la version que ellas desean, sobrescribiendo otras versiones actuales. Potencialmente, esto hace que los valores por defecto en otras aplicaciones se ejecuten en un sistema.

En Windows 98, Windows 2000, Microsoft ha creado el sistema de archivos protegidos de Windows (WPFS) para permitir a los administradores de sistemas crear un archivo llamado XXXX.LOCAL en el directorio rafz de una aplicacion, en el que XXXX es el nombre del archivo ejecutable sin la extension. Esto hace que el cargador de Windows altere su procedimiento de resolver las referencias de ruta durante las ejecuciones de LoadLibrary. Esto, sin embargo, no es suficiente para resolver por completo el problema. En primer lugar, la configuracion del archivo XXXX se deja al conocimiento del administrador del sistema, lo que es muy variable. En segundo lugar, una version de componente debe someterse a un retroceso de nuevo al original, a continuacion, instalar este componente en el directorio local y, a continuacion, crear el archivo “.LOCAL”. Este no es un procedimiento sencillo para cualquiera de los componentes mas basicos localizados en WINDOWS\SYSTEM. Tambien, esta solucion no cubre todas las funcionalidades necesarias. Durante LoadLibrary, Windows usa una semantica diferente de resolucion de ruta en funcion de si el componente se resuelve como resultado de una LoadLibrary explfcita o implfcita, y tambien si existe una clave de registro que indique que es una DLL nombrada o bien conocida. En este caso, la llamada de LoadLibrary siempre se resolvera en el directorio WINDOWS\SYSTEM.

Las DLL y otros componentes compartidos conservan tambien la semantica de recuento de referencia para garantizar que un componente no se toca a menos que no haya aplicaciones en ejecucion que se refieran al mismo. En la practica, solo las aplicaciones del proveedor de sistema operativo y el propio sistema operativo han hecho un buen trabajo de obedecer este protocolo.

Como regla general, se desea tener un objeto compartido que siempre se resuelva para el componente correcto. Para proporcionar esta funcionalidad, se requiere entender la version de un componente, o intervalo de versiones, con el que es posible hacer funcionar la aplicacion. A continuacion, cuando la aplicacion se va a ejecutar, la presente invencion garantizana que el componente se resuelve correctamente. Es aceptable, en la presente invencion, para automatizar el uso de WPFS u otro sistema operativo que proporciona la capacidad, si se desea. En este caso, es necesario detectar los componentes necesarios y colocarlos en el sistema de archivos local. Esto es mas complejo que la simple observacion de la instalacion, puesto que un programa de instalacion a menudo no instalara un componente si el necesario ya esta ahr

Esto se desea para identificar un procedimiento para garantizar que los objetos nombrados se cargan correctamente. En la plataforma Windows, MSVCRT.DLL es un responsable significativo dentro de esta area de problemas. Si se mantienen multiples versiones de este objeto, la clave de registro mencionada anteriormente puede cambiarse dinamicamente, lo que permite que la funcion LoadLibrary resuelva la version correcta del componente. Otro procedimiento razonable de garantizar la carga correcta del componente es la edicion dinamica de un entorno de procedimiento para usar una ruta de busqueda valida. Esta ruta de busqueda garantizara que un componente local se resuelve antes que un componente amplio de sistema. Otro posible procedimiento para la resolucion del objeto compartido correcto es a traves del uso de los enlaces simbolicos. Puede hacerse un enlace simbolico para un componente compartido, que se resuelve en tiempo de ejecucion por el sistema de archivos del equipo para el componente necesario. Por ultimo, las solicitudes abiertas/lefdas/cerradas reales de un archivo del objeto compartido pueden interceptarse por la presente invencion y responderse dinamicamente para la version correcta del archivo que pueda existir en el sistema local o dentro de los subsistemas de la invencion.

Existen varias formas especiales. En la plataforma Windows, OLE, ODBC, MDAC,... asf como una serie de otros componentes espedficos de fabricante, estan escritos para compartirse globalmente entre varios o todos los procedimientos en ejecucion. En el caso de OLE, yendo tan lejos como compartir datos y espacio de memoria entre procedimientos individuales. OLE evita mas de una copia de sf mismo en ejecucion al mismo tiempo, al igual que muchos de estos componentes. OLE tiene tambien muchos errores y caractensticas que requieren una version espedfica a cargarse para una aplicacion espedfica. En la presente invencion, una aplicacion es capaz de cargar cualquier version de OLE que se requiera, aun permitiendo la semantica compartida con otros componentes que usan la misma version de OLE.

En general, a menos que se configure espedficamente como tal, los objetos compartidos debenan cargarse privadamente para garantizar la prevencion de conflictos. Nada evitana, acerca del procedimiento usado para permitir que un componente se cargue privadamente, que se descarguen limpiamente o se carguen correctamente para otra aplicacion de software, si se administra o no activamente por la restriccion de sistema operativo. Ademas, si el sistema se bloquea, se requiere para recuperarse de este bloqueo un estado limpio, sin haber sobrescrito o modificado el sistema operativo subyacente.

ARCHIVOS

Muchas aplicaciones usan archivos de datos dentro de la aplicacion para almacenar entradas de configuracion u otros datos de aplicacion. La presente invencion proporciona un sistema de archivos virtual al igual que el registro virtual descrito anteriormente. Antes del comienzo de la aplicacion, la presente invencion puede cargar una lista de

5

10

15

20

25

30

35

40

45

50

55

cambios de sistema de archivos, que incluye archivos para ocultar y archivos para agregar al entorno virtual o archivos para redirigir a otro dentro del entorno virtual. Siempre que la aplicacion accede o modifica cualquier archivo, la restriccion de sistema operativo comprueba si el archivo debe redirigirse, y si es asf, en la realizacion preferida redirige la solicitud a una localizacion especificada en la configuracion de la restriccion de sistema operativo.

Si una aplicacion intenta crear un nuevo archivo o abrir un archivo existente para escribir en una unidad local del usuario, la restriccion de sistema operativo debe garantizar que el archivo se crea o se modifica realmente en la localizacion redirigida. Si la aplicacion se vuelve a cargar en un momento posterior, este mapeo de archivo debe recargarse en el entorno virtual de la restriccion de sistema operativo. Cuando la solicitud es para modificar un archivo existente, que reside en una unidad local del usuario, la restriccion de sistema operativo debe copiar el archivo en cuestion al punto de redireccion antes de continuar con la solicitud. Los archivos redirigidos pueden no ser del mismo nombre que el archivo original para garantizar el mapeo seguro de las rutas de archivos. En la realizacion preferida, los archivos INI se manejan de esta manera para ofrecer la maxima seguridad del sistema al tiempo que permiten la maxima compatibilidad de aplicaciones.

La presente invencion es espedficamente util para las aplicaciones distribuidas a traves de una red. En tales implementaciones es importante entender que las aplicaciones de software estan hechas de varios tipos de datos, en las que el grueso de los archivos de aplicaciones que usan una aplicacion de software estan montados lo mas preferentemente en una unidad logica independiente. La configuracion, que incluye tanto la basada en archivo como la basada en el registro, puede ser espedfica del usuario y de todo el sistema. El sistema de distribucion de aplicaciones usado marcana cada archivo para el que de estos tipos hay algun archivo. Esta informacion proporciona consejos al sistema de restriccion de sistema operativo para actuar de manera apropiada.

CONTROLADORES DE DISPOSITIVOS

Muchas aplicaciones usan controladores de dispositivos u otro software a nivel de sistema operativo para implementar algunas de sus funciones tales como el soporte de hardware o las interacciones de bajo nivel directamente con el sistema operativo. En la presente invencion, la restriccion de sistema operativo proporcionara la capacidad de dinamicamente, y tan privadamente como sea posible, agregar y eliminar estos componentes en el entorno virtual de la aplicacion.

Muchos controladores de dispositivos estan disenados para poder cargarse dinamicamente. Si es posible, es la realizacion preferida cargar todos los controladores de dispositivo dinamicamente. Si un controlador de dispositivo requiere una carga estatica en el momento del arranque, debe presentarse este conocimiento al usuario antes de ejecutar la aplicacion. Una vez que el sistema ha reiniciado la aplicacion debena continuar desde donde lo dejo. Sin embargo, un gran porcentaje de los controladores de dispositivos no puede descargarse dinamicamente. Aunque se prefiere descargar de manera dinamica el controlador, si esto no puede realizarse el controlador sera marcado para su eliminacion en el siguiente reinicio, y el usuario debena estar al tanto de esto. Si la aplicacion se ejecuta una segunda vez antes del siguiente reinicio, el sistema debena ser consciente de la presencia del controlador y no intentar una segunda instalacion, esperando a la terminacion para remarcar el componente eliminable en el siguiente reinicio.

Es importante caracterizar las similitudes y las diferencias de base, tal como existen para cada clase de controlador de dispositivo, para garantizar que la presente invencion pueda funcionar correctamente. No se desea realmente cargar y descargar los controladores de dispositivos para el hardware del sistema que esta constantemente presente. Debena entenderse que aunque esto no es una realizacion preferida en terminos de facilidad de programacion, esta dentro del ambito de la presente invencion y puede requerirse por razones espedficas, tales como la restriccion en los acuerdos de concesion de licencias para las aplicaciones que se entregan y ejecutan usando la presente invencion.

En las plataformas que no son de Microsoft, los controladores de dispositivos se manejan normalmente de manera muy diferente. Los sistemas Macintosh soportan tanto los controladores estaticos como dinamicos, pero todos ellos se instalan y se eliminan a traves del mismo procedimiento. Enlazar con la carpeta de sistema de Macintosh proporcionara el soporte necesario. Para los sistemas UNIX, los controladores de dispositivos requieren mas normalmente una modificacion para el nucleo de UNIX en ejecucion, seguido de un reinicio. Este procedimiento puede ser muy complejo. En la realizacion preferida, este procedimiento esta automatizado; incluyendo restablecer el nucleo una vez que la aplicacion esta completa. Los parametros generales del procedimiento son los mismos que se han descrito anteriormente para las aplicaciones de Windows, las etapas de procedimiento reales de la compilacion y las personas familiarizadas con tales sistemas operativos pueden realizar el reinicio.

Finalmente, los expertos en la materia entenderan que es deseable ser capaz de recuperar y eliminar los controladores a traves de los fallos del sistema. Por lo tanto, cualesquiera que sean los datos o procedimientos necesarios para mantener la integridad del sistema es una realizacion preferida de la presente invencion. Los expertos en la materia apreciaran tambien que todo tipo de controladores de dispositivos podnan no proporcionarse conveniente o eficientemente a traves de la presente invencion, mas espedficamente los asociados con los dispositivos de hardware conectados permanentemente.

5

10

15

20

25

30

35

40

45

50

55

OTROS ARTICULOS

En la presente invencion, se reconoce que hay varios componentes de la invencion, el comportamiento o la presencia de lo que es diferente en los sistemas operativos alternativos. Estos componentes incluyen fuentes, procedimientos, variables de entorno, y otros.

Algunas aplicaciones requieren fuentes a instalarse con el fin de funcionar correctamente. Cualquier fuente requerida sera especificada en el archivo de configuracion de la restriccion de sistema operativo. La restriccion de sistema operativo habilitara esas fuentes antes de ejecutar la aplicacion y si es necesario las eliminara posteriormente. La mayona de los sistemas tienen un area comun para el almacenamiento de fuentes, ademas de un procedimiento de registro de las mismas o para hacer que el sistema sea consciente de su presencia, la restriccion de sistema operativo utilizara estos procedimientos disponibles.

En Windows, una fuente se copia en el directorio WINDOWS\FONTS. Sin embargo, esto no garantiza que la fuente este disponible para el programa en ejecucion. En la realizacion preferida, si el programa usa la API de Windows

para acceder a las fuentes, la fuente necesitara registrarse con una ApI de Win32 llamada tal como

CreateScalableFontResource/AddFontResource. Esto insertara la fuente en la tabla de fuentes del sistema. Una vez completo, la restriccion de sistema operativo puede eliminar la fuente con otra API apropiada llamada como RemoveFontResource, a continuacion, elimina el archivo del sistema. Como una realizacion alternativa, la restriccion de sistema operativo podna interceptar las funciones API como se describe en el procedimiento de registro virtual. Ademas, la restriccion de sistema operativo puede usar su subsistema de archivos para evitar colocar el fichero de fuente real en el sistema en ejecucion.

En Macintosh, el procedimiento es extremadamente similar y basado en los archivos de la carpeta de sistema y el registro de activacion de Macintosh. En UNIX, sin embargo, el procedimiento depende de la aplicacion. Lo mas normal, los recursos de fuentes se agregan al sistema como archivos regulares resueltos en la localizacion adecuada, por lo que pueden accederse por el nombre. Con muchos sistemas Motif, necesita colocarse una

descripcion de la fuente en un archivo de recursos de fuente, lo que permitira que la fuente se resuelva. La

aplicacion Motif o X puede invocar la fuente o a traves del subsistema de resolucion o mediante una llamada directa. Recientemente, muchos sistemas basados en Motif y en CDE utilizan fuentes postscript escalables de Adobe. Estas fuentes necesitan administrarse a traves del sistema de administracion de tipo Adobe. Sin embargo, hay excepciones, y como se ha indicado anteriormente, hay alternativas a los sistemas de administracion de fuentes por defecto de Windows u otro sistema operativo. El administrador tipo Adobe proporciona algunas interfaces alternativas para este procedimiento, como hacen otros tipos de sistemas de administracion de terceras partes. En la mayona de los casos, debena decidirse si soportar la interfaz o ignorarla. El fin de la restriccion de sistema operativo no es proporcionar una capa universal para todos estos sistemas, solo hacerlo asf para el propio subsistema del sistema operativo.

Muchas aplicaciones requieren que se configuren las variables de entorno. Esto es muy comun en los sistemas UNIX, pero tambien se usa mucho por el software, que fue escrito originalmente en UNIX y portado a los sistemas operativos Windows. Las aplicaciones en los sistemas operativos Windows dependen en gran medida de la variable de entorno DOS PATH y a menudo configurar sus propias entradas espedficas de aplicacion. En los entornos de Windows 9x/Me, hay muchas configuraciones de entorno, que pueden aplicarse cuando en su nucleo esta el subsistema DOS. Si una aplicacion requiere la presencia de unas variables espedficas, o valores a configurarse en las variables de entorno existentes, las variables de entorno necesarias se especificaran en el archivo de configuracion de la restriccion de sistema operativo. La restriccion de sistema operativo configurara esas variables para el procedimiento principal de la aplicacion cuando se ponga en marcha. Puesto que las aplicaciones no cambian normalmente las configuraciones de entorno cuando estan en funcionamiento, el entorno virtual no atrapara esas llamadas, ni las proporcionara el complemento completo de la funcionalidad que hacen el registro y el subsistema de configuracion.

RECUPERACION

En algunos casos mostrados en las secciones anteriores, las modificaciones reales deben hacerse al sistema operativo. Esto es frecuente con los controladores de dispositivos y las fuentes. Ademas, pueden realizarse cambios al entorno virtual que se necesite para persistirse y estar disponible la proxima vez que se ejecute la aplicacion. Se requiere que el sistema de restriccion de sistema operativo sea capaz de recuperarse de cambios en el sistema, eliminando el cambio del sistema en la primera oportunidad posible. Como alternativa, si el sistema se bloquea durante una ejecucion de la aplicacion, la restriccion de sistema operativo debena realizar un seguimiento de la suficiente informacion para eliminar cualquier cambio en el sistema si se reinicia o no, y debena realizar un seguimiento de los cambios hechos en el entorno virtual. En la realizacion preferida, esto se implementa como un registro de transacciones, pero en otras realizaciones puede hacerse como cualquier otro componente similar, que puede leerse al iniciar el sistema de manera que pueden anularse los cambios.

5

10

15

20

25

30

35

40

CONTROL DE VIRTUALIZACION

Un aspecto importante de la invencion se refiere al control de las muchas facetas de la virtualizacion que es capaz de hacer la restriccion de sistema operativo. En la realizacion preferida existe una instrumentacion programable para determinar los aspectos correctos de un sistema de software a controlar. Tambien se incluye un procedimiento para permitir a los administradores y a los usuarios finales para ver y modificar los elementos a virtualizarse por el sistema.

En el programa automatizado, se observa la aplicacion a controlarse con el fin de evaluar los aspectos de control. El programa automatizado es capaz de realizar esta tarea durante el procedimiento de instalacion de la aplicacion, durante el tiempo de ejecucion de la aplicacion, o una combinacion de ambos. En la realizacion preferida, la restriccion de sistema operativo esta integrada en una aplicacion contenedora. Tras la instalacion, o despues de uno o muchos usos del software, la aplicacion contenedora consultara a la restriccion de sistema operativo para obtener una lista detallada de todas sus acciones. A partir de esta lista de acciones, la aplicacion contenedora creara los archivos de configuracion necesarios para cargar y hacer funcionar la restriccion de sistema operativo en usos posteriores.

Si se usa como parte del procedimiento de instalacion, la restriccion de sistema operativo, en la realizacion preferida, actuara como una capa virtual que permite la instalacion que se introducira solo en su entorno. Despues de la instalacion, todos los archivos, configuraciones, y col. pueden volcarse para una recarga posterior. De esta manera, la instalacion dejara el sistema original intacto y habra creado automaticamente los archivos de configuracion necesarios. Cuando se usa durante el uso de la aplicacion, la restriccion de sistema operativo es capaz de grabar o las modificaciones diferenciales del entorno, o recodificar los archivos de configuracion.

La restriccion de sistema operativo pasara su informacion a la aplicacion contenedora para un procesamiento posterior. En la realizacion preferida, ademas de las entradas automaticas que puede crear el sistema, la aplicacion contenedora esta programada con un sistema operativo espedfico y el conocimiento espedfico de la aplicacion o del dominio. Este conocimiento se usa para alterar la salida del procedimiento para reflejar los usos conocidos de los elementos de configuracion o de otras entradas. En la realizacion preferida, se emplea un sistema basado en reglas para comparar los comportamientos observados con los escenarios conocidos con el fin de efectuar cambios en la codificacion.

La aplicacion contenedora se usa como un visor y/o un editor para la salida de configuracion del procedimiento. Este editor, en la realizacion preferida, permite a un administrador de sistema anadir, editar o eliminar elementos o grupos de elementos de la configuracion. Al observar la configuracion a traves del editor, el administrador puede hacer tambien replicas de la configuracion, cambiar elementos espedficos cuando sea necesario para efectuar los cambios a nivel de aplicacion o personalizados por el usuario.

Haciendo referencia ahora a la figura 1, se ilustra funcionalmente una realizacion de la presente invencion. En esta realizacion, se ilustran dos conjuntos de datos de aplicacion/usuario 60. La restriccion 100 de sistema operativo mantiene las dos instancias de la aplicacion 50 de que interfieran entre sf. Ademas, como se ha explicado anteriormente, la restriccion 100 de sistema operativo sirve como una capa de abstraccion y como tal recoge los comandos y las comunicaciones entre el software 50 de aplicacion y el sistema 10 operativo real del equipo cliente. Como se ilustra graficamente por las flechas, ciertos comandos estan entre la restriccion de sistema operativo y la aplicacion de software, esto es a diferencia de las instalaciones tfpicas en las que estos comandos senan ejecutados en su lugar por el propio sistema operativo, lo que resulta en cambios en el equipo cliente que podnan no ser necesariamente los que el operador ha previsto. Por otro lado, otros comandos pasan a traves de la restriccion de sistema operativo y a continuacion se transfieren al propio sistema operativo.

Claims (4)

1. REIVINDICACIONES

   1. Un sistema para crear un entorno de software de aplicacion sin cambiar un sistema (10) operativo de un equipo cliente, comprendiendo el sistema una capa (100) de abstraccion y proteccion de sistema operativo,

   en el que dicha capa de abstraccion y proteccion esta interpuesta entre una aplicacion (50, 52, 54) de software en 5 ejecucion y dicho sistema operativo, por lo que se proporciona un entorno virtual en el que pueden ejecutarse una aplicacion y por lo que dicho sistema operativo es un sistema operativo Windows que comprende un registro de Windows,

   en el que la capa de abstraccion y proteccion de sistema operativo responde con una clave y su valor si dicha clave y el valor se almacenan dentro de la capa de abstraccion y proteccion de sistema operativo, si no se 10 almacenan, la capa de abstraccion y proteccion de sistema operativo permite la solicitud para pasar a traves del registro de Windows.
2. 2. El sistema de la reivindicacion 1, en el que todas las operaciones en el registro de Windows y los archivos .ini son a traves de la API de Win32, comprendiendo ademas el sistema un medio para funciones de interceptacion, por lo que cada vez que se invocan dichas funciones otra funcion o aplicacion intercepta la llamada.

   15 3. El sistema de la reivindicacion 2, en el que el sistema intercepta cada funcion API adecuada para dar servicio a

   una solicitud si se hace por una aplicacion ejecutada desde un servidor o si se hace por una aplicacion contra una clave de configuracion que se administra activamente.
3. 4. El sistema de la reivindicacion 1, que comprende ademas un componente de registro de Windows virtual para proporcionar un registro de funcion completo a una aplicacion, pero evitar la modificacion del registro de sistema

   20 subyacente.
4. 5. El sistema de la reivindicacion 1, en el que si se hace un intento de modificar el valor de dicha clave, la capa de abstraccion y proteccion de sistema operativo permite que la modificacion se produzca solamente sobre sf misma.