ES2798184T3 - Procedimiento, sistema y fragmento de código ejecutable para la virtualización de un recurso de soporte físico asociado a un sistema informático - Google Patents

Procedimiento, sistema y fragmento de código ejecutable para la virtualización de un recurso de soporte físico asociado a un sistema informático Download PDF

Info

Publication number
ES2798184T3
ES2798184T3 ES13778383T ES13778383T ES2798184T3 ES 2798184 T3 ES2798184 T3 ES 2798184T3 ES 13778383 T ES13778383 T ES 13778383T ES 13778383 T ES13778383 T ES 13778383T ES 2798184 T3 ES2798184 T3 ES 2798184T3
Authority
ES
Spain
Prior art keywords
data
hardware resource
application
computer system
resource
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES13778383T
Other languages
English (en)
Inventor
Gonzalez Alejandro Pajuelo
Mulà Javier Verdu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Universitat Politecnica de Catalunya UPC
Original Assignee
Universitat Politecnica de Catalunya UPC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Universitat Politecnica de Catalunya UPC filed Critical Universitat Politecnica de Catalunya UPC
Application granted granted Critical
Publication of ES2798184T3 publication Critical patent/ES2798184T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/542—Intercept

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Devices For Executing Special Programs (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Procedimiento para virtualizar recursos de

Description

DESCRIPCIÓN
Procedimiento, sistema y fragmento de código ejecutable para la virtualización de un recurso de soporte físico asociado a un sistema informático
La presente invención versa acerca de un procedimiento para la virtualización de un recurso de soporte físico asociado con un sistema informático que utiliza un fragmento de código ejecutable adaptado para ser inyectado en un procedimiento que pertenece a una aplicación que es ejecutado en un sistema operativo que comprende al menos una interfaz para programación de aplicaciones (API) que es ejecutada en el sistema informático.
La invención también versa acerca de un sistema y acerca de un fragmento de código ejecutable para llevar a cabo este procedimiento
Antecedentes de la invención
Desde hace algunos años, básicamente desde que se ha consolidado el modelo informático en nube, el concepto de “virtualización” ha venido destacando en el mundo de los ordenadores.
La virtualización puede definirse, básicamente, como la creación por medio de soporte lógico de una versión virtual de un recurso tecnológico, tal como una plataforma de soporte físico, un sistema operativo, un dispositivo de almacenamiento de datos u otros recursos de red, de forma que se pueda dividir este recurso en uno o más entornos de ejecución. Es importante resaltar que también es posible el caso en el que este soporte lógico es asistido por tecnología de soporte físico de virtualización, tal como Intel-VT o AMD-V (véase, por ejemplo, la Wikipedia en español - http://es.wikipedia.org/wiki/Virtualizacion).
Uno de los recursos tecnológicos que es virtualizado con más frecuencia es un sistema informático (por ejemplo, un ordenador personal o un servidor), que permite que este sistema informático ejecute al mismo tiempo múltiples casos de distintos sistemas operativos. De esta forma, el sistema informático es capaz de ejecutar distintas aplicaciones que requieren distintos sistemas operativos.
También se conoce un tipo de virtualización para permitir la emulación de recursos de soporte físico de un sistema informático. Con ese fin, es necesario instalar un soporte lógico de virtualización en el sistema informático cuyo objetivo es hacer que los recursos de soporte físico del sistema informático sean accesibles para todos los sistemas operativos instalados. Otro objetivo de este soporte lógico de virtualización es coordinar el acceso a recursos virtualizados de soporte físico para los distintos sistemas operativos instalados en el sistema informático.
A pesar del hecho de que la virtualización de recursos de soporte físico de un sistema informático (aunque es aplicable a cualquier otro tipo de virtualización) tiene algunas ventajas (por ejemplo, según se ha expuesto anteriormente, permite ejecutar al mismo tiempo varios sistemas operativos en un solo sistema informático), también tiene un número significativo de desventajas.
Por lo tanto, por ejemplo, tal virtualización puede conllevar una reducción en el rendimiento del sistema informático como resultado de la sobrecarga conllevada en la ejecución del soporte lógico de virtualización en el sistema informático. Entre otros, se puede efectuar la ejecución de las aplicaciones, que pueden ejecutarse más lentas que en sistemas que no son virtuales.
Con respecto a la desventaja precedente, en muchos casos tal virtualización puede virtualizar recursos que en ningún caso van a ser utilizados o en ningún caso necesitan ser virtualizados. Por lo tanto, por ejemplo, si el teclado de un sistema informático ha de ser virtualizado de forma que cada aplicación que se ejecuta tenga un teclado virtual, según el estado de la técnica sería necesario crear tantos sistemas virtuales de ordenador (máquina virtual más sistema operativo) como teclados virtuales sean requeridos por las distintas aplicaciones que están siendo ejecutadas. Esto conlleva un consumo innecesario de recursos del sistema que, según se ha descrito anteriormente, afecta al rendimiento del sistema.
El documento US2011/157196 da a conocer distintas características que pueden ser utilizadas para implementar un sistema que permite a un usuario ejecutar, operar e interactuar con una aplicación de soporte lógico, tal como un videojuego, en un cliente en el que la aplicación de soporte lógico se ejecuta en un servidor remoto. Las características permiten que el sistema sea implementado de una forma optimizada. Por ejemplo, una característica conlleva la interceptación de instrucciones gráficas generadas por la aplicación de soporte lógico que son dirigidas a una interfaz para programación de aplicaciones (API) gráficas, la manipulación de las instrucciones gráficas interceptadas para producir instrucciones gráficas manipuladas que tienen un tamaño reducido en comparación con las instrucciones gráficas interceptadas, y la transferencia de las instrucciones gráficas manipuladas desde el servidor hasta el cliente para su representación en el mismo.
El documento WO 2011/152816 A1 da a conocer una memoria que tiene una página para almacenar código ejecutable por un procesador. Un componente de gestión ha de inyectar el código en una máquina virtual e indicar en una tabla de memoria para la máquina virtual que la página de la memoria tiene un tipo de código inyectado. En esta solicitud de patente, se inyecta código específico a un recurso dado de soporte físico según sea necesario en la máquina virtual para que la máquina virtual acceda directamente a este recurso de soporte físico. Por ejemplo, un hipervisor que gestiona una máquina virtual identifica los recursos de soporte físico de los dispositivos informáticos que están albergando la máquina virtual, y determina a cuáles de estos recursos de soporte físico ha de acceder esta máquina virtual.
El documento “'Extending applications using advanced approach to DLL injection and API hooking” (Berdajs et Bosnic, SOFTWARE PRACTICE & EXPERIENCE, vol. 40, n°7) versa sobre inyección de DLL y enganche de API, dos técnicas que pueden ser utilizadas para modificar aplicaciones sin intervenir en su código fuente. Este planteamiento documental permite la extensión de las aplicaciones en situaciones en las que no llegan a funcionar planteamientos comparables. Como tal, tiene un valor práctico notable para aplicaciones prácticas beneficiosas de planteamientos de inyección y de enganche, que están presentes en programas de detección de programas malignos y en herramientas de seguridad de ordenador.
Descripción de la invención
Por lo tanto, un objetivo de la presente invención es proporcionar un procedimiento para la virtualización de un cierto recurso de soporte físico asociado con un sistema informático, sin tener que virtualizar todos sus recursos de soporte físico del sistema.
Este objetivo se logra mediante un procedimiento, un sistema y un programa de ordenador según las reivindicaciones independientes. En las reivindicaciones dependientes se caracterizan mejoras adicionales.
Por lo tanto, a diferencia del estado de la técnica, cada aplicación que es ejecutada en el sistema operativo del sistema informático que utiliza el fragmento de código inyectado, puede virtualizar esos dispositivos de soporte físico requeridos para la ejecución, sin tener que virtualizar todos los recursos de soporte físico asociados con el sistema. Esto conlleva una reducción en el consumo de los recursos del sistema, dado que no se virtualizan recursos (el sistema operativo o cualquier recurso de soporte físico del sistema informático, por ejemplo) que en ningún caso van a ser utilizados o en ningún caso necesitan ser virtualizados. En realidad no hay ningún soporte lógico de virtualización en la presente invención para virtualizar todos los recursos del sistema informático, como ocurre en el estado de la técnica, más bien, el fragmento de código inyectado en cada aplicación ejecutada en el sistema informático es el que decide o ha establecido anteriormente qué recursos de soporte físico debe virtualizar para una correcta ejecución de la aplicación.
Continuando con el ejemplo de virtualización del teclado de un sistema informático, la presente invención simplemente requiere la creación del teclado virtual en vez de todo el sistema informático. Por lo tanto, la aplicación es ejecutada directamente en la máquina actual, no en la máquina virtualizada, reduciendo mucho la sobrecarga introducida por la virtualización: únicamente se produce una sobrecarga, aunque bastante pequeña, cuando se leen datos de teclado, en vez de que haya una sobrecarga significativa en la ejecución de cada instrucción del programa. Por otra parte, es importante señalar que la expresión “gestión del flujo de datos” está relacionada con la transmisión y/o el control del flujo de datos, de forma que los servicios a los que llama el proceso estén relacionados con la gestión del flujo de datos. De forma que cuando el fragmento de código inyectado intercepta la llamada, el fragmento de código controla esta gestión enviando el contenido de la memoria intermedia virtual, por ejemplo.
Para lograr el objetivo descrito anteriormente, en primer lugar es necesario interceptar las llamadas que el proceso que pertenece a la aplicación realiza a los servicios relacionados con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico. Se interpreta que el término “interceptar” significa que la llamada procedente del proceso al servicio de API conlleva la redirección a un servicio comprendido en el fragmento de código, de forma que el propio fragmento de código reciba la llamada desde el proceso para ejecutar este servicio correspondiente al servicio de API (es decir, la llamada procedente del proceso no alcanza el servicio de API). Con esta interceptación, el fragmento de código puede tomar control del flujo de datos entre el proceso y el recurso de soporte físico cuando el proceso realiza una solicitud al sistema operativo para acceder al mismo, dado que el fragmento de código actúa por encima del sistema operativo.
Antes de esta interceptación, el fragmento de código puede haber redirigido uno o más servicios de una o más API relacionadas con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico a servicios correspondientes comprendidos en el fragmento de código, de forma que, según se ha expuesto anteriormente, la llamada procedente del proceso ya no sea realizada en un servicio de API sino, más bien, en el servicio correspondiente comprendido en el fragmento de código.
Después de la interceptación, dado que el fragmento de código recibe las llamadas procedentes del proceso y los servicios comprendidos en el fragmento de código son los que son ejecutados, el fragmento de código puede gestionar el flujo de datos producido entre el proceso y el recurso de soporte físico y, por lo tanto, virtualizar el recurso de soporte físico, dado que los servicios comprendidos en el fragmento de código están adaptados a ese fin. Es importante señalar que las expresiones “un servicio”, “una API”, “una llamada” o “recurso de soporte físico” están relacionadas con al menos un servicio, al menos una API, al menos una llamada y/o al menos un recurso de soporte físico, respectivamente. Por lo tanto, por ejemplo, es posible redirigir dos servicios de una sola API a dos servicios comprendidos en el fragmento de código (es decir, al menos dos llamadas realizadas por el proceso) o redirigir un servicio de una primera API a un primer servicio comprendido en el fragmento de código y un servicio de una segunda API a un segundo servicio comprendido en el fragmento de código. Asimismo, dependiendo de los servicios redirigidos, es posible que un solo fragmento de código pueda virtualizar uno o más recursos de soporte físico, tales como una tarjeta de vídeo, una tarjeta de sonido, una unidad de disco duro, un teclado o un ratón, dependiendo de las necesidades de la aplicación mientras está siendo ejecutada.
También es importante señalar que una forma de inyectar el fragmento de código ejecutable en el proceso se describe, por ejemplo, en ["Windows NT System-Call Hooking", Mark Russinovich y Bryce Cogswell, Dr. Dobb's Journal, enero de 1997].
Según una realización preferente de la invención, el proceso que pertenece a la aplicación puede ser iniciado en el estado de reposo, y el fragmento de código ejecutable puede ser inyectado en el proceso durante este estado de reposo. Por lo tanto, el procedimiento según la invención debe contemplar la posibilidad de reiniciar el proceso si dicho proceso ha sido iniciado en el estado de reposo. De ese modo, se garantiza la correcta operación del fragmento de código.
Según otra realización de la invención, el servicio de API puede ser una función, y la etapa de redirigir un servicio de API relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico a un servicio correspondiente comprendido en el fragmento de código puede comprender:
■ cargar en la memoria la biblioteca de enlace dinámico que comprende la función de API que ha de ser redirigida;
■ sustituir, en la tabla de punteros a funciones para las funciones de API comprendidas en la biblioteca cargada de enlace dinámico, la dirección inicial de memoria en la que se almacena la función de API que ha de ser redirigida por la dirección inicial de memoria en la que se almacena la función correspondiente comprendida en el fragmento de código.
Por lo tanto, el fragmento de código puede redirigir una o más funciones de una o más API a funciones correspondientes comprendidas en el fragmento de código, de forma que el fragmento de código pueda interceptar las llamadas realizadas por el proceso a estas funciones y, por lo tanto, gestionar el flujo de datos producido entre el proceso y el recurso de soporte físico (o recursos de soporte físico si la aplicación requiere la virtualización de más de uno), lo que permite la virtualización del mismo.
Además, la etapa de redirigir un servicio de API relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico a un servicio correspondiente comprendido en el fragmento de código también puede comprender almacenar en una primera variable la dirección inicial de memoria en la que se almacena la función de API que ha de ser redirigida, de forma que esta función de API (es decir, la función original) pueda ser llamada desde el propio fragmento de código ejecutable en caso de que sea necesario en cualquier momento mientras la aplicación está siendo ejecutada.
Por otra parte, el servicio de API puede ser un método objeto, y la etapa de redirigir un servicio de API relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico a un servicio correspondiente comprendido en el fragmento de código puede comprender:
■ cargar en la memoria la biblioteca de enlace dinámico que comprende el método objeto que ha de ser redirigido;
■ verificar si el objeto asociado con el método que ha de ser redirigido es creado por primera vez;
■ en el caso de un resultado positivo en la verificación,
o sustituir, en la tabla de punteros a métodos, para los métodos objeto comprendidos en la biblioteca cargada de enlace dinámico, la dirección inicial de memoria en la que se almacena el método objeto que ha de ser redirigido, por la dirección inicial de memoria en la que se almacena el método correspondiente comprendido en el fragmento de código.
Como en el caso de las funciones, también es posible redirigir uno o más métodos que pertenecen a un objeto a uno o más métodos comprendidos en el fragmento de código, de forma que el fragmento de código pueda interceptar las llamadas realizadas por el proceso a estos métodos y, por lo tanto, gestionar el flujo de datos producido entre el proceso y el recurso de soporte físico.
Dado que es posible, según se ha expuesto anteriormente, redirigir al menos un servicio de al menos una API, es posible que uno de los servicios sea una función y otro de los servicios sea un método, de forma que ambas realizaciones descritas puedan llegar a ser complementarias para una sola aplicación que esté siendo ejecutada.
Además, la etapa de redirigir un servicio de API relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico a un servicio correspondiente comprendido en el fragmento de código también puede comprender almacenar en una segunda variable la dirección inicial de memoria en la que se almacena el método objeto que ha de ser redirigido, de forma que, si se requiriese en cualquier momento mientras que la aplicación está siendo ejecutada, este método (es decir, el método original) podría ser llamado desde el propio fragmento de código.
Según otra realización de la invención, la etapa de interceptación de una llamada procedente del proceso que pertenece a la aplicación a un servicio de API relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico puede comprender la recepción de una llamada procedente del proceso al servicio comprendido en el fragmento de código correspondiente al servicio de API relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico. Dependiendo de la dirección del flujo de datos (es decir, proceso-recurso o recurso-proceso), los servicios comprendidos en el fragmento de código a los que el proceso realiza llamadas pueden ser distintos.
Preferentemente, la etapa de gestionar el flujo de datos producido entre el proceso y el recurso de soporte físico puede comprender:
■ verificar si se ha generado un recurso virtualizado de soporte físico correspondiente al recurso de soporte físico;
■ en el caso de un resultado negativo en la verificación, generar el recurso virtualizado de soporte físico.
Para la mayoría de recursos de soporte físico de un sistema informático, para gestionar el flujo de datos producido entre el proceso y el recurso de soporte físico puede ser necesario generar un recurso de soporte físico que virtualice el recurso de soporte físico del sistema informático (es decir, generar un recurso virtual de soporte físico). Por lo tanto, dependiendo del recurso de soporte físico del sistema informático, el fragmento de código puede tener que verificar si existe o no el recurso virtualizado correspondiente de soporte físico. En el caso de que no exista, la generación de este recurso virtualizado de soporte físico puede comprender:
o generar una memoria intermedia que virtualice la memoria intermedia asociada con el recurso de soporte físico y/o
o generar un hilo de ejecución que emule el comportamiento del recurso de soporte físico.
La razón para la generación de la memoria intermedia virtualizada es que la mayoría de los recursos de soporte físico del sistema informático comprenden o están asociados con al menos una memoria intermedia (más específicamente, cada recurso de soporte físico puede tener al menos un área de memoria que está reservada) en el que el recurso de soporte físico puede almacenar datos, de forma que alcancen el proceso (el proceso normalmente realiza una solicitud para obtenerlos), o en el que el proceso puede almacenar datos, de forma que alcancen el recurso (el recurso está normalmente habilitado para capturarlos), es decir, la memoria intermedia sirve de herramienta para intercambiar datos entre el proceso y el recurso. El fin de la generación de la memoria intermedia virtual o virtualizado es que el área de memoria reservada para intercambiar datos entre el proceso y el recurso sea un área distinta que no se encuentre bajo el control del sistema operativo y/o los controladores asociados con los recursos reales, sino que, más bien, se encuentre bajo el control del fragmento de código. Además, para cada recurso de soporte físico, cada aplicación que está siendo ejecutada que tiene un fragmento de código inyectado en la misma según la invención puede tener, por lo tanto, al menos una memoria intermedia propia y no una compartido con las otras aplicaciones, que pertenece al recurso de soporte físico.
En algunos casos, una vez se han almacenado los datos en la memoria intermedia virtualizada, puede ser necesario informar al proceso que todas las acciones han sido llevadas a cabo de forma correcta. Además, puede ser necesario indicar al proceso cuántos datos han sido escritos en la memoria intermedia, bien debido a que hay espacio restante en la memoria intermedia o bien debido a que todos los datos podrían no ser almacenados en la memoria intermedia y será necesaria otra etapa u otras etapas para el almacenamiento de datos.
Con respecto al hilo de ejecución, puede ser necesario generarlo principalmente de forma que simule el comportamiento del recurso de soporte físico del sistema informático y, entre otros, de forma que lleve a cabo una gestión adecuada de los datos generados por el fragmento de código, a través del recurso virtualizado de soporte físico, y de los datos generados por el proceso que son intercambiados entre ellos a través de la memoria intermedia virtualizada, según se ha expuesto anteriormente. Es importante señalar que el hilo de ejecución puede ser representado, por ejemplo, por al menos una función comprendida en el fragmento de código, de forma que la ejecución del hilo conlleve en realidad la ejecución de esta función.
Además, la etapa de gestión del flujo de datos producido entre el proceso y el recurso de soporte físico también puede comprender almacenar en la memoria intermedia virtualizada los datos enviados por el proceso al recurso de soporte físico. El fragmento de código puede gestionar, por lo tanto, el flujo de datos producido entre el proceso y el recurso de soporte físico dado que los datos son almacenados en la memoria intermedia virtualizada, que se encuentra bajo el control del fragmento de código. El destino de estos datos generados por el proceso fue realmente el recurso de soporte físico del sistema informático (es decir, el recurso de soporte físico real), pero la interceptación de las llamadas procedentes del proceso a ciertos servicios de API mediante el fragmento de código permite que estos datos se encuentren bajo su control.
Por otra parte, la etapa de gestionar el flujo de datos producido entre el proceso y el recurso de soporte físico puede comprender:
■ suspender el hilo generado de ejecución que emula el comportamiento del recurso de soporte físico durante un tiempo predeterminado;
■ obtener los datos almacenados en la memoria intermedia virtualizada, enviados anteriormente por el proceso al recurso de soporte físico;
■ procesar los datos obtenidos.
En caso de que el recurso virtualizado de soporte físico tenga un hilo de ejecución que simule el comportamiento del recurso de soporte físico del sistema informático, el fragmento de código debe suspender el hilo de ejecución durante un tiempo predeterminado (normalmente del orden de milisegundos), de forma que el hilo de ejecución obtenga, entonces, los datos que el proceso ha almacenado en la memoria intermedia virtualizada. Una vez se obtienen estos datos, el hilo de ejecución debe procesarlos igual que lo haría el recurso de soporte físico del sistema informático. Por lo tanto, por ejemplo, si el recurso de soporte físico es una tarjeta de sonido, el procesamiento de estos datos puede conllevar convertirlos, por ejemplo, en un formato mp3 (es decir, según el estándar de audio MPEG-1, capa III), de forma que dichos datos sean entonces interpretables.
Según una realización preferente de la invención, la etapa de gestionar el flujo de datos producido entre el proceso y el recurso de soporte físico puede comprender enviar los datos procesados a un primer sistema remoto de ordenador. Dado que después de que se procesan los datos continúan siendo controlados por el fragmento de código a través del recurso virtualizado de soporte físico, estos datos pueden ser enviados a un sistema remoto de ordenador (distinto del sistema informático que comprende el recurso de soporte físico real) que realmente hace uso de los mismos, aunque también pueden ser enviados al propio sistema informático en el que se ejecuta la aplicación o a cualquier otro sistema local de ordenador. Por lo tanto, continuando con el ejemplo de la tarjeta de sonido, dado que el fragmento de código tiene control de los datos de audio, dicho fragmento de código puede hacer que estos datos de audio sean escuchados a través de la tarjeta real de sonido del sistema remoto de ordenador (por ejemplo, un dispositivo o terminal móvil, tal como un teléfono inteligente o una tableta) en vez de que sean escuchados a través de la tarjeta real de sonido asociada con el sistema informático. Una vez se procesan los datos por medio del hilo de ejecución (téngase en cuenta que esto es solo al menos una función comprendida en el hilo de ejecución), si tales datos son interpretables por la tarjeta de sonido del sistema informático, evidentemente no debe haber ningún problema para que tales datos sean interpretables por la tarjeta de sonido de cualquier otro sistema informático, dado que tales datos ya han sido adaptados a ese fin.
Como puede comprenderse con claridad, hasta ahora se ha descrito de forma general un procedimiento para la virtualización de un recurso de soporte físico asociado con un sistema informático, y también de una forma más específica en función, entre otros, de la gestión del flujo de datos producido desde el proceso, que pertenece a la aplicación, hasta el recurso de soporte físico, es decir, hasta ahora la presente invención ha descrito cómo controla el fragmento de código los datos que van del proceso al recurso. A continuación se describen el procedimiento de la invención cuando se produce el flujo de datos entre el recurso (más específicamente, el recurso virtualizado de soporte físico) y el proceso que pertenece a la aplicación.
El procedimiento puede comprender, por lo tanto, la gestión del flujo de datos producido desde el recurso virtualizado de soporte físico hasta el proceso que pertenece a la aplicación.
Esta gestión del flujo de datos en la dirección específica puede comprender:
■ recibir datos procedentes de un segundo sistema remoto de ordenador;
■ procesar los datos recibidos;
■ almacenar los datos procesados en la memoria intermedia virtualizada.
El fragmento de código puede recibir datos en cualquier momento procedentes de un segundo sistema remoto de ordenador (aunque normalmente los sistemas remotos primero y segundo de ordenador serán el mismo sistema remoto de ordenador), datos que deben ser procesados y almacenados en la memoria intermedia virtualizada creada anteriormente, de forma que sean accesibles para el proceso. Por lo tanto, en el caso en el que el recurso de soporte físico que está siendo virtualizado sea el teclado del sistema informático, por ejemplo, el fragmento de código (más específicamente, el hilo de ejecución que simula el comportamiento del recurso de soporte físico) puede recibir datos de teclado procedentes del sistema remoto de ordenador (por ejemplo, una tableta), tales como datos generados en función de un teclado en el que el usuario actúa a través de la pantalla táctil de la tableta. Estos datos deben ser procesados por el hilo de ejecución y almacenados en la memoria intermedia.
Subsiguientemente, cuando el proceso requiere la obtención de estos datos, debe efectuar llamadas a ciertos servicios de API relacionados con la gestión del flujo de datos entre el recurso de soporte físico (entendiéndose que es el recurso de soporte físico real, dado que la virtualización del recurso de soporte físico es transparente para el proceso) y el proceso, estas llamadas que están siendo interceptadas por el fragmento de código, de forma que el fragmento de código recupere los datos almacenados en la memoria intermedia virtualizada (no los datos almacenados en la memoria intermedia del recurso de soporte físico del sistema informático, es decir, el recurso de soporte físico real) y hace que sean accesibles para el proceso, que, después de haberlos obtenido, puede procesarlos si es necesario.
Por lo tanto, la etapa de interceptación de una llamada procedente del proceso que pertenece a la aplicación a un servicio de API relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico puede comprender:
■ interceptar una llamada procedente del proceso que pertenece a la aplicación a un servicio de API relacionado con la gestión del flujo de datos producido desde el recurso de soporte físico hasta el proceso;
mientras que la etapa de gestión del flujo de datos producido desde el recurso virtualizado de soporte físico hasta el proceso que pertenece a la aplicación puede comprender:
■ recuperar los datos almacenados en la memoria intermedia virtualizada;
■ enviar los datos recuperados al proceso.
Según se ha descrito anteriormente para la situación general (es decir, para el flujo de datos entre el proceso y el recurso), la etapa de interceptación de una llamada procedente del proceso a un servicio de API relacionado con la gestión del flujo de datos producido desde el recurso de soporte físico hasta el proceso puede comprender la recepción de una llamada procedente del proceso al servicio comprendido en el fragmento de código correspondiente al servicio de API relacionado con la gestión del flujo de datos producido desde el recurso de soporte físico hasta el proceso.
Finalmente, el procedimiento también puede comprender la gestión del flujo de datos producido desde el recurso de soporte físico del sistema informático (es decir, el recurso de soporte físico real) hasta el proceso con el fin de garantizar que el recurso virtualizado continúa controlando correctamente la aplicación, y no el recurso real. Con ese fin, la etapa de gestión del flujo de datos producido entre el proceso y el recurso de soporte lógico puede comprender:
■ gestionar el flujo de datos producido desde el recurso de soporte físico hasta el proceso, que puede comprender:
o verificar si hay datos procedentes del recurso de soporte físico en la memoria intermedia;
o en el caso de un resultado positivo en la verificación, eliminar estos datos.
Dado que la virtualización del recurso de soporte físico del sistema informático que se lleva a cabo es transparente para este recurso, es posible que continúe enviando datos a su memoria intermedia asociada, de forma que la memoria intermedia pueda acabar llenándose en algún momento, y, dada esta situación, el recurso de soporte físico real podría saturar las estructuras internas del sistema operativo del sistema informático real, que podría actuar en respuesta a ello o podría dejar de funcionar correctamente. Para evitar esto, el fragmento de código puede verificar cada poco tiempo, por ejemplo, si hay datos almacenados en la memoria intermedia y, en el caso de un resultado positivo en la verificación, eliminar tales datos.
Según un segundo aspecto, la invención proporciona un fragmento de código ejecutable que puede comprender instrucciones para ejecutar un procedimiento para la virtualización de un recurso de soporte físico asociado con un sistema informático tal como el descrito anteriormente, estando adaptado este fragmento de código para ser inyectado en un proceso que pertenece a una aplicación cuando se ejecuta esta aplicación en un sistema operativo que comprende al menos una interfaz para programación de aplicaciones (API) que es ejecutada en el sistema informático.
Este fragmento de código ejecutable puede ser almacenado en medios de almacenamiento físicos, tales como medios grabables, una memoria de ordenador, o memoria de solo lectura, o puede ser transportado por una onda portadora, tal como una onda eléctrica u óptica.
Según un tercer aspecto de la invención, la presente invención proporciona un sistema para la virtualización de un recurso de soporte físico asociado con un sistema informático en el que se ejecuta un sistema operativo que comprende al menos una interfaz para programación de aplicaciones en la que se ejecuta una aplicación que comprende un proceso, pudiendo comprender el sistema:
- medios de ordenador para interceptar una llamada procedente del proceso que pertenece a la aplicación a un servicio de interfaz para programación de aplicaciones relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico;
- medios de ordenador para gestionar el flujo de datos producido entre el proceso y el recurso de soporte físico por medio del fragmento de código en función de la interceptación de la llamada procedente del proceso al servicio de interfaz para programación de aplicaciones relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico.
Preferentemente, la invención también proporciona un sistema informático en el que se ejecuta un sistema operativo que puede comprender al menos una interfaz para programación de aplicaciones, sistema operativo en el cual se ejecuta al menos una aplicación, pudiendo comprender el sistema informático una memoria y al menos un procesador, pudiendo almacenar esta memoria instrucciones ejecutables por un procesador correspondientes a un fragmento de código ejecutable, tal como el descrito anteriormente, inyectado en un proceso que pertenece a la aplicación, pudiendo comprender las instrucciones funcionalidades para:
- interceptar una llamada procedente del proceso que pertenece a la aplicación a un servicio de interfaz para programación de aplicaciones relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico;
- gestionar el flujo de datos producido entre el proceso y el recurso de soporte físico mediante el fragmento de código en función de la interceptación de la llamada procedente del proceso al servicio de interfaz para programación de aplicaciones relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico.
Según una realización de la invención, en el sistema informático descrito pueden ejecutarse al menos dos aplicaciones en el sistema operativo, y la memoria puede almacenar instrucciones ejecutables por un procesador correspondientes a un fragmento de código para cada aplicación que está siendo ejecutada.
Además, la invención también puede proporcionar una aplicación que puede ser ejecutada en un sistema operativo que es ejecutado en un sistema informático, pudiendo comprender esta aplicación un fragmento de código ejecutable tal como el que se ha descrito anteriormente.
Según una posible realización de la invención, el recurso de soporte físico puede ser una tarjeta de sonido, la etapa de interceptación de una llamada procedente del proceso que pertenece a la aplicación a un servicio de interfaz para programación de aplicaciones (API) relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico puede comprender la interceptación de una llamada procedente del proceso a un servicio de API relacionado con la gestión del flujo de datos de audio producido desde el proceso hasta la tarjeta de sonido; y la etapa de gestionar el flujo de datos producido entre el proceso y el recurso de soporte físico mediante el fragmento de código puede comprender la gestión del flujo de datos de audio producido desde el proceso hasta la tarjeta de sonido.
Más específicamente, la etapa de gestión del flujo de datos de audio producido desde el proceso hasta la tarjeta de sonido puede comprender verificar si se ha generado una tarjeta virtualizada de sonido correspondiente con la tarjeta de sonido del sistema informático; y en el caso de un resultado negativo en la verificación, generar la tarjeta virtualizada de sonido.
La etapa descrita de generación de la tarjeta virtualizada de sonido puede comprender la generación de al menos una memoria intermedia que virtualiza la memoria intermedia asociada con la tarjeta de sonido del sistema informático, y la generación de un hilo de ejecución que emula el comportamiento de la tarjeta de sonido del sistema informático.
Además, la etapa de gestionar el flujo de datos de audio producido entre el proceso y la tarjeta de sonido puede comprender almacenar en la memoria intermedia virtualizada los datos de audio enviados por el proceso a la tarjeta de sonido.
Por otra parte, la etapa de gestión del flujo de datos de audio producido entre el proceso y la tarjeta de sonido puede comprender la suspensión del hilo generado de ejecución que emula el comportamiento de la tarjeta de sonido del sistema informático durante un tiempo predeterminado; obtener los datos de audio almacenados en la memoria intermedia virtualizada, enviados anteriormente por el proceso a la tarjeta de sonido, por medio del hilo de ejecución;
y procesar los datos obtenidos de audio por medio del hilo de ejecución.
Esta etapa de procesamiento de los datos de audio obtenidos de la memoria intermedia virtualizada mediante el hilo de ejecución puede comprender la mezcla de los datos obtenidos de la al menos una memoria intermedia virtualizada, y convertir los datos mezclados de audio en un formato interpretable (por ejemplo, a un formato mp3).
Según otra realización de la invención, el recurso de soporte físico puede ser una tarjeta de vídeo, la etapa de interceptación de una llamada procedente del proceso que pertenece a la aplicación a un servicio de interfaz para programación de aplicaciones (API) relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico puede comprender la interceptación de una llamada procedente del proceso a un servicio de API relacionado con la gestión del flujo de datos de vídeo producido desde el proceso hasta la tarjeta de vídeo; y la etapa de gestionar el flujo de datos producido entre el proceso y el recurso de soporte físico mediante el fragmento de código puede comprender la gestión del flujo de datos de vídeo producido desde el proceso hasta la tarjeta de vídeo.
Más específicamente, la etapa de gestión del flujo de datos de vídeo producido desde el proceso hasta la tarjeta de vídeo puede comprender la verificación de si se ha generado una tarjeta virtualizada de vídeo correspondiente a la tarjeta de vídeo del sistema informático; y en el caso de un resultado negativo en la verificación, la generación de la tarjeta virtualizada de vídeo.
La etapa descrita de generación de la tarjeta virtualizada de vídeo puede comprender la generación de una memoria intermedia que virtualiza la memoria intermedia asociada con la tarjeta de vídeo del sistema informático, y la generación de un hilo de ejecución que emula el comportamiento de la tarjeta de vídeo del sistema informático. En el caso de una tarjeta de vídeo, se denomina contexto de dibujo (DC) a esta memoria intermedia y puede definirse como un área de memoria en la que la tarjeta de vídeo almacena los gráficos resultantes fotograma a fotograma y siempre está asociada con una ventana.
Por otra parte, la etapa de gestión del flujo de datos de vídeo producido entre el proceso y la tarjeta de vídeo puede comprender la suspensión del hilo generado de ejecución que emula el comportamiento de la tarjeta de vídeo del sistema informático durante un tiempo predeterminado; obteniendo los (fotogramas de) datos de vídeo almacenados en el DC virtualizado, generado anteriormente por la tarjeta de vídeo, mediante el hilo de ejecución; y procesar los datos de vídeo obtenidos mediante el hilo de ejecución.
Esta etapa de procesamiento de los datos de vídeo obtenidos de la memoria intermedia virtualizada mediante el hilo de ejecución puede comprender la codificación del fotograma por medio de un códec, por ejemplo, H.264.
Según otra realización más de la invención, el recurso de soporte físico puede ser un dispositivo de entrada de datos, tal como un teclado o un ratón. En este punto se debería indicar que si el sistema operativo que es ejecutado en el sistema informático utiliza un sistema de colas de mensajes, también puede ser necesario virtualizar esta cola de mensajes.
Para virtualizar la cola de mensajes, puede ser necesario generar una memoria intermedia y un hilo de ejecución que emule el sistema de colas de mensajes (es decir, enviar mensajes a la cola de mensajes asociada con la aplicación en función de alguna entrada de datos, tal como, por ejemplo, una tecla pulsada) e interceptar la consulta y la función de tratamiento de los mensajes (es decir, una función (también conocida como una función de ventana) que el programador define para determinar el comportamiento de la aplicación en respuesta a un cierto mensaje) que, según se ha expuesto anteriormente, está comprendida en el fragmento de código, para llevar a cabo funciones del sistema de colas de mensajes. En este caso, el fragmento de código debería interceptar la llamada procedente del proceso a la función que interroga (saca el mensaje de la cola para leerlo) y trata (lleva a cabo una cierta acción) los mensajes que pueden encontrarse en la cola de mensajes que el sistema operativo tiene asociada con la aplicación. La función del fragmento de código que trata los mensajes de la cola de mensajes puede eliminar, por lo tanto, los mensajes que no se de desea que sean tratados por la aplicación (es decir, que deben ser ignorados) o puede llamar, a su vez, a la función original, de manera que la aplicación trate el mensaje (es decir, se concibe que actúe en respuesta a dicho mensaje).
En el caso de que el recurso de soporte físico sea un dispositivo de entrada de datos (un ratón o un teclado, por ejemplo), la etapa de interceptación de una llamada procedente del proceso que pertenece a la aplicación a un servicio de interfaz para programación de aplicaciones (API) relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico puede comprender la interceptación de una llamada procedente del proceso a un servicio de API relacionado con la gestión del flujo de datos producido desde el dispositivo de entrada hasta el proceso; y la etapa de gestión del flujo de datos producido entre el proceso y el recurso de soporte físico mediante el fragmento de código puede comprender la gestión del flujo de datos producido desde el dispositivo de entrada hasta el proceso.
Más específicamente, la etapa de gestión del flujo de datos producido desde el dispositivo de entrada hasta el proceso puede comprender la verificación de si se ha generado un dispositivo virtualizado de entrada correspondiente al dispositivo de entrada del sistema informático; y en el caso de un resultado negativo en la verificación, generar el dispositivo virtualizado de entrada.
La etapa descrita de generación del dispositivo virtualizado de entrada puede comprender la generación de una memoria intermedia que virtualiza la memoria intermedia asociada con el dispositivo de entrada del sistema informático, y la generación de un hilo de ejecución que emule el comportamiento del dispositivo de entrada del sistema informático.
Además, la etapa de gestionar el flujo de datos producido desde el dispositivo virtualizado de entrada hasta el proceso que pertenece a la aplicación puede comprender recibir datos de un sistema remoto de ordenador, generándose estos datos por medio de un dispositivo de entrada (tal como un teclado, un ratón, ya sea a través de una pantalla táctil o no) del sistema remoto de ordenador; procesar los datos recibidos y almacenar los datos procesados en la memoria intermedia virtualizada.
Por otra parte, la etapa de gestionar el flujo de datos producido desde el dispositivo virtualizado de soporte físico hasta el proceso que pertenece a la aplicación también puede comprender recuperar los datos almacenados en la memoria intermedia virtualizada; y enviar los datos recuperados al proceso.
Finalmente, según otra realización de la invención, el recurso de soporte físico puede ser una unidad de almacenamiento, tal como una unidad de disco duro; la etapa de interceptación de una llamada procedente del proceso que pertenece a la aplicación a un servicio de interfaz para programación de aplicaciones (API) relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico puede comprender la interceptación de una llamada procedente del proceso a un servicio de API relacionado con la gestión del flujo de datos producido desde el proceso hasta la unidad de almacenamiento; y la etapa de gestión del flujo de datos producido entre el proceso y el recurso de soporte físico mediante el fragmento de código puede comprender la gestión del flujo de datos producido desde el proceso a la unidad de almacenamiento.
Más específicamente, la etapa de gestión del flujo de datos producido desde el proceso a la unidad de disco duro puede comprender cambiar la ruta del directorio en el que se almacenan los datos procedentes del proceso.
Según se ha expuesto anteriormente, para una aplicación dada, el fragmento de código tiene que ser capaz de virtualizar uno de los recursos descritos de soporte físico, o una pluralidad de ellos. Por esta razón, se debe adaptar el fragmento de código y debe contener las instrucciones necesarias para lograr la virtualización de uno o varios de estos dispositivos.
A lo largo de la descripción y de las reivindicaciones, no se concibe que la palabra “comprende” y variantes de la misma excluyan otras características técnicas, suplementos, elementos o etapas. Para los expertos en la técnica, objetos, ventajas y características adicionales de la invención se deducirán en parte de la descripción y en parte de la puesta en práctica de la invención. Los ejemplos y dibujos se proporcionan a título ilustrativo, y no se concibe que limiten la presente invención. Solo se contempla que los números de referencia relacionados con los dibujos y colocados entre paréntesis en una reivindicación intenten mejorar la comprensión de la reivindicación y no debe interpretarse que limiten el alcance de protección de la reivindicación. Además, la presente invención abarca todas las posibles combinaciones de realizaciones particulares y preferentes indicadas en la presente memoria.
Breve descripción de los dibujos
Para comprender mejor lo que se ha descrito anteriormente, se adjuntan dibujos que muestran esquemáticamente realizaciones prácticas a modo de ejemplo no limitante.
En los dibujos,
La Figura 1 es un diagrama de bloques que muestra las capas de ejecución de una aplicación en un sistema informático, según el estado de la técnica;
la Figura 2 es un diagrama de bloques que muestra las capas de ejecución de una aplicación en un sistema informático que incorpora, además, una capa que representa un fragmento de código inyectado en un proceso que pertenece a la aplicación, concibiéndose este fragmento de código para virtualizar al menos un recurso de soporte físico asociado con el sistema informático en el que se ejecuta la aplicación según la invención.
Descripción de una realización preferente de la invención
A continuación se proporcionará la descripción de un procedimiento y de un fragmento de código ejecutable según la invención para la virtualización de un recurso de soporte físico asociado con un sistema informático. Un sistema operativo que comprende al menos una interfaz para programación de aplicaciones (API) está instalado en este sistema informático. El fragmento de código ejecutable descrito está adaptado para ser inyectado en un proceso que pertenece a una aplicación que está siendo ejecutada en el sistema operativo descrito.
La Figura 1 muestra un diagrama que muestra las capas de ejecución de una aplicación (por ejemplo, un juego) en un sistema informático (por ejemplo, un ordenador personal, un servidor, etc.), según el estado de la técnica.
En este diagrama, la capa 10 de menor nivel representa los recursos de soporte físico del sistema informático, tales como el microprocesador (CPU), la memoria, la unidad de procesamiento gráfico (GPU), el teclado, el ratón, la tarjeta de vídeo, la tarjeta de sonido y las unidades de disco duro, entre otros.
En una segunda capa 11 dispuesta un nivel superior, se ubica el sistema operativo, que tiene los controladores necesarios para una comunicación y una interacción bidireccionales (pudiendo enviar y/o recibir información acerca de estos recursos, tales como señales 14 de control o datos 15) con los recursos de la capa inferior 10.
En una tercera capa 12 dispuesta encima de la capa 11 que representa el sistema operativo, hay ubicadas interfaces para programación de aplicaciones (mejor conocidas como API), tanto aquellas que están comprendidas en el sistema operativo como aquellas que son el resultado de la instalación de los controladores de un recurso de la capa inferior 10. Estas API se implementan normalmente en bibliotecas de enlace dinámico, con independencia del sistema operativo utilizado. La comunicación entre la capa 12 que comprende las API y la capa 11 que representa el sistema operativo también es una comunicación bidireccional, pudiendo intercambiar tanto señales 14 de control como datos 15.
Finalmente, la Figura 1 también muestra una cuarta capa o capa 13 de nivel máximo que muestra la aplicación que está siendo ejecutada. Mientras está siendo ejecutada, esta aplicación accede a la capa 12 que representa las API, intercambiando tanto señales de control como datos.
Por lo tanto, según esta configuración, si, por ejemplo, la aplicación que está siendo ejecutada 13 requiere la generación de una ventana en la pantalla de visualización del sistema informático en el que está siendo ejecutada, la aplicación debe acceder a ciertos servicios de las API 12 (bien funciones o bien métodos) concebidos para la generación de ventanas. Para poder generar la ventana en la pantalla, estos servicios necesitan intercambiar información (señales de control y datos) con el sistema operativo 11, que tiene las herramientas necesarias (es decir, los controladores) para comunicarse con la pantalla 10 y provocar, de esta manera, la generación de la ventana deseada.
La principal desventaja de esta configuración es que cada recurso de soporte físico del sistema informático solo es utilizable por una única aplicación, que es la que el usuario tiene (o la que el sistema operativo ha seleccionado como) activa en el primer plano (es decir, la ventana activa), es decir, si el recurso de soporte físico es la tarjeta de sonido, entre todas las aplicaciones que están siendo ejecutadas en ese momento, solo la aplicación que el usuario tiene activa en el primer plano tendrá capacidad para utilizar ese recurso y, por lo tanto, será la única aplicación con capacidad para enviar datos de audio a la tarjeta de sonido para reproducirlos.
También es posible una situación en la que el recurso de soporte físico tiene capacidad para recibir datos desde distintas aplicaciones que están siendo ejecutadas, pero en este caso, los datos estarán mezclados. Por lo tanto, continuando con el ejemplo de la tarjeta de sonido, si este recurso puede recibir datos de audio procedentes de más de una de las aplicaciones que están siendo ejecutadas, la tarjeta de sonido reproduce una mezcla de los distintos datos de audio que recibe.
Para solucionar estas desventajas, la invención proporciona un fragmento de código ejecutable que debe ser inyectado en cada aplicación en el momento de iniciar la ejecución (por ejemplo, el proceso que pertenece a la aplicación que está siendo iniciada en el estado de reposo), que tiene capacidad para ejecutar un procedimiento para virtualizar uno o más recursos de soporte físico asociados con un sistema informático en el que se ejecuta la aplicación. Por lo tanto, el objetivo principal de este fragmento de código es virtualizar los recursos de soporte físico que la aplicación requiere del sistema informático para su ejecución, de forma que tenga capacidad para generar recursos virtualizados de soporte físico utilizable únicamente por la aplicación en cuyo proceso ha sido inyectado, y gestionar el flujo de datos entre el proceso que pertenece a la aplicación y el recurso de soporte físico. Por lo tanto, cada aplicación que está siendo ejecutada tiene sus propios dispositivos virtualizados de soporte físico, al igual que una herramienta (el fragmento de código) que tiene capacidad para gestionar los flujos de datos generados entre ellos y el proceso.
La Figura 2 muestra un diagrama basado en el de la Figura 1, pero comprende, además, una capa 16 que representa el fragmento de código ejecutable que, después de ser inyectado en el proceso asociado con la aplicación, está dispuesto a nivel lógico entre la capa 13 de la aplicación y la capa 12 que representa las API, de forma que el fragmento de código pueda interceptar llamadas procedentes de la aplicación a ciertos servicios de API (por ejemplo, funciones o métodos) y, por lo tanto, virtualizar los recursos 10' de soporte físico.
Como puede verse en la Figura 2, la función principal de la capa 16 que representa el fragmento de código es interceptar distintas llamadas que el proceso que pertenece a la aplicación realiza a servicios de API relacionados con el flujo de datos generado entre el proceso y los recursos de soporte físico del sistema informático, y, en función de la interceptación de estas llamadas, gestionar el flujo de datos producido entre el proceso y los recursos de soporte físico del sistema informático, al igual que entre el proceso y los recursos virtualizados 10' de soporte físico descritos anteriormente.
Más específicamente, el procedimiento ejecutado por el fragmento de código es como sigue. Debe describirse en función de una situación inicial en la que, cuando un usuario ejecuta una aplicación, se inicia el proceso que pertenece a la aplicación en la etapa de reposo. Durante esta etapa de reposo, se inyecta el fragmento de código ejecutable en el proceso.
Una vez que se inyecta el fragmento de código en el proceso, este fragmento de código carga en la memoria todas aquellas bibliotecas de enlace dinámico que contienen los servicios (bien funciones o bien métodos) que contienen interfaces para programación de aplicaciones (API) relacionados con la gestión del flujo de datos entre el proceso y los distintos recursos de soporte físico del sistema informático y que van a ser requeridos por la aplicación mientras está siendo ejecutada. Entonces, después de que el sistema operativo ha llenado la tabla de punteros a servicios para los servicios de las distintas API cargadas en la memoria según las direcciones iniciales de memoria en las que se han almacenado estos servicios, sustituye en esta tabla de punteros la dirección inicial de memoria de los servicios que pueden ser requeridos, o que lo serán, por la aplicación mientras está siendo ejecutada, por la dirección inicial de memoria en la que se ubica cada uno de los servicios correspondientes comprendidos en el fragmento de código. Por lo tanto, en función de esta redirección llevada a cabo, el fragmento de código es capaz de interceptar llamadas que el proceso realiza a estos servicios relevantes para la ejecución de los mismos, es decir, las llamadas que el proceso realiza a los distintos servicios relevantes de las distintas API son recibidas por el fragmento de código, dado que los punteros no apuntan a los servicios de API, sino a los servicios correspondientes comprendidos en el fragmento de código.
En función de dicha interceptación, el fragmento de código adquiere la capacidad para gestionar el flujo de datos producido entre el proceso y el recurso de soporte físico del sistema informático, es decir, el fragmento de código toma el control, de una forma que sea transparente para el proceso, del flujo de datos producido entre el proceso y el recurso de soporte físico del sistema informático.
Más específicamente, cuando el proceso busca acceder a un recurso de soporte físico del sistema informático por medio de llamadas a ciertos servicios de API, el fragmento de código ejecuta sus propios servicios (es decir, lleva a cabo una interceptación de estas llamadas). En función de esta interceptación, para tomar control del flujo de datos es necesario generar un recurso virtualizado 10' de soporte físico correspondiente al recurso de soporte físico del sistema informático al que el proceso busca acceder, si no había sido generado anteriormente.
La generación del recurso virtualizado 10' de soporte físico puede conllevar varias acciones.
Una primera acción puede ser generar al menos una memoria intermedia que virtualice el al menos una memoria intermedia asociada con el recurso de soporte físico del sistema informático, es decir, el fragmento de código reserva un área específica de memoria, que representa la memoria intermedia virtualizada, en el que el proceso debe almacenar los datos que, al principio, está enviando al recurso de soporte físico del sistema informático, pero que han sido interceptados por el fragmento de código.
Una segunda acción que ha de llevarse a cabo puede ser la generación de un hilo de ejecución que emula el comportamiento del recurso de soporte físico del sistema informático. Básicamente, este hilo de ejecución puede ser una función comprendida en el propio fragmento de código.
Una vez se genera el recurso virtualizado 10' de soporte físico (si no existía anteriormente), el fragmento de código almacena los datos enviados por el proceso en la memoria intermedia virtualizada y genera el hilo de ejecución descrito anteriormente (si es necesario). El fragmento de código suspende el hilo de ejecución (que es una función comprendida en el mismo fragmento de código y, por lo tanto, sobre la que tiene control) durante un tiempo predeterminado (aproximadamente unos milisegundos), de forma que lea subsiguientemente los datos almacenados en la memoria intermedia virtualizada (téngase en cuenta que dichos datos son procedentes del proceso) y los procese. Una vez se procesan los datos, el fragmento de código tiene la capacidad para enviarlos a un primer sistema remoto de ordenador, aunque esta realización se describirá a continuación.
Es importante señalar que normalmente será necesario que el fragmento de código comunique al proceso que los datos han sido recibidos correctamente, como ocurriría si el recurso de soporte físico no fuese el recurso virtualizado de soporte físico, sino más bien el propio recurso de soporte físico del sistema informático.
Por otra parte, también es posible que el hilo generado de ejecución reciba datos desde un segundo sistema remoto de ordenador (aunque los sistemas remotos primero y segundo de ordenador serán normalmente el mismo sistema remoto de ordenador). En esta situación, el hilo de ejecución procesa los datos recibidos y, una vez procesados, los almacena en la memoria intermedia virtualizada que es parte del recurso virtualizado 10' de soporte físico.
En cualquier momento mientras está siendo ejecutada la aplicación, el proceso llama a un cierto servicio de API para verificar si el recurso de soporte físico del sistema informático ha generado datos para la aplicación. Dado que todos los servicios de API relacionados con la gestión del flujo de datos entre el proceso y los recursos de soporte físico del sistema han sido redirigidos, la llamada es recibida y procesada por el fragmento de código (más específicamente, un servicio comprendido en el fragmento de código). Con ese fin, el fragmento de código recupera los datos contenidos en la memoria intermedia virtualizada (téngase en cuenta que los datos correspondientes a los datos contenidos en la memoria intermedia virtualizada (es decir, los datos recibidos y procesados por el hilo de ejecución) han sido recibidos por el hilo de ejecución de un sistema remoto de ordenador) y los envía al proceso, de forma que pueda utilizarlos.
Normalmente, dado que el recurso de soporte físico del sistema informático puede generar datos para la aplicación (téngase en cuenta que el fragmento de código solo interviene al nivel del flujo de datos y no al nivel de la señal de control), el fragmento de código debe verificar cada poco tiempo si hay datos en la memoria intermedia del recurso de soporte físico y, en el caso de un resultado positivo, eliminar tales datos. Por lo tanto, se evitan problemas mientras se está ejecutando la aplicación.
A continuación se describirá una realización preferente de la invención, en la que el sistema operativo es uno cualquiera de la familia Windows, por ejemplo Windows 7; el sistema informático es un servidor de aplicaciones, más específicamente un servidor de juegos; las aplicaciones que han de ser ejecutadas son juegos y/o distintos casos de un solo juego; y el recurso de soporte físico en el que está siendo ejecutado el juego que realiza una solicitud de acceso es la tarjeta de sonido del servidor de juegos. A continuación se describen una realización de la invención en la que el recurso de soporte físico es una tarjeta de vídeo, una realización de la invención en la que el recurso de soporte físico es un dispositivo de entrada de datos (por ejemplo, un teclado o un ratón) y una realización de la invención en la que el recurso de soporte físico es una unidad de disco duro.
Más específicamente, la presente realización tiene la siguiente operación. El objetivo del servidor de juegos es permitir que usuarios del servicio jueguen distintos juegos o incluso el mismo juego (por ejemplo, juegos de ordenador (PC) o de consola) desde sus terminales móviles o sistemas remotos de ordenador, tales como teléfonos inteligentes o tabletas. La ejecución de cada juego o de cada caso del mismo juego puede ser enviada por medio de técnicas de difusión en continuo desde el servidor de juegos a los dispositivos móviles de los usuarios. Por lo tanto, desde un dispositivo móvil que pertenece al usuario, dicho usuario puede seleccionar el juego que ha de ser jugado, solicitando la ejecución del mismo mediante el accionamiento de un elemento de control (por ejemplo, un icono representativo del juego) que aparece en una interfaz gráfica de usuario mostrada en la pantalla del terminal móvil del usuario. Este accionamiento por parte del usuario sobre el elemento de control genera una señal de control para el servidor de juegos, lo que provoca la ejecución del juego seleccionado en el servidor.
Dado que puede haber un gran número de usuarios que solicitan la ejecución de un juego (es decir, puede haber un gran número de juegos que estén siendo ejecutados), el fin de la presente invención es que cada juego, en función del fragmento de código inyectado en el mismo, pueda virtualizar los recursos de soporte físico del servidor de juegos requeridos para su ejecución y, por lo tanto, hacer que estén disponibles de forma exclusiva.
Cuando un usuario solicita la ejecución de un juego desde su terminal móvil, se crea el proceso principal de la aplicación que está siendo ejecutada (es decir, el juego) en el servidor de juego, en el estado de reposo. Con ese fin, se utiliza la función CreateProcess, asignando el valor CREATE_SUSPENDED al parámetro del modo de creación (CreateFlags). Una vez que se ha iniciado el proceso en el estado de reposo, se inyecta el fragmento de código ejecutable según la invención en el proceso, cuyo objetivo es virtualizar los recursos de soporte físico del servidor de juegos.
En este punto es importante señalar que la expresión “virtualizar un recurso de soporte físico” conlleva no solo la generación de un recurso virtualizado de soporte físico correspondiente al recurso de soporte físico del sistema informático, sino también comprende la gestión completa del flujo de datos que se genera a posteriori.
Antes de reanudar la ejecución del proceso (debe tenerse en cuenta que el proceso se inicia en el estado de reposo), el fragmento de código inyectado redirige las funciones de API relacionadas con la gestión del flujo de datos producido entre la aplicación (o más específicamente el proceso que pertenece a la aplicación) y los distintos recursos de soporte físico del servidor de juegos (en la presente realización, se cargarían al menos las funciones concebidas para la gestión del flujo de datos entre la aplicación y la tarjeta de sonido). Por lo tanto, por ejemplo, en la presente realización las funciones de interés podrían ser lAudioClient o lAudioRenderClient.
Dado que en la presente realización el sistema operativo que es ejecutado en el servidor de juegos es uno de la familia Windows (más específicamente, Windows 7), estas API descritas son implementadas normalmente en bibliotecas de enlace dinámico (DLL). Por esta razón, el fragmento de código carga, mediante la función LoadLibrary, la o las bibliotecas que contienen las funciones de interés, por ejemplo, GetBuffer y ReleaseBuffer de la API IAudioRenderClient, a través de la biblioteca dxgi.dll. Básicamente, LoadLibrary carga la biblioteca en la memoria y el sistema operativo rellena la tabla de direcciones de indexación (IAT), que es una tabla de punteros a funciones para las funciones de API, con las direcciones iniciales en la memoria de las funciones de API. Mediante la función RedirectIAT, el fragmento de código modifica los punteros necesarios, haciendo que se correspondan con las funciones comprendidas en el fragmento de código inyectado en el proceso. Al mismo tiempo, se guarda en una variable el contenido original de la tabla, es decir, el valor inicial de los punteros antes de la modificación en caso de que el fragmento de código tenga que llamar a cualquiera de las funciones originales redirigidas en cualquier momento.
Cuando termina la interceptación, es decir cuando todas las funciones de todas las API necesarias han sido redirigidas, el fragmento de código reanuda la ejecución del proceso que ha sido iniciado en el estado de reposo. Por otra parte, cuando el proceso solicita la creación de una interfaz de tipo IAudioRenderClient (una interfaz de tipo COM) mediante el método GetService de la interfaz IAudioCLient, el fragmento de código verifica si esta interfaz ha sido modificada ya o no (es decir, redirigida) por el fragmento de código. En el caso de un resultado negativo en la verificación, es necesario modificar la tabla de punteros de la interfaz para sustituir los métodos que han de ser interceptados, tales como, por ejemplo, lAudioRenderClient, GetBuffer y ReleaseBuffer. La tabla de punteros a métodos para métodos de una interfaz de tipo COM es modificada con un código específico. Por ejemplo, GetBuffer se corresponde con la posición 4 de la tabla de métodos de la interfaz lAudioRenderClient y tiene que ser modificada de forma que apunte a la función comprendida en el fragmento de código inyectado. Al mismo tiempo, se guarda el contenido original de esta posición en una variable en caso de que haya necesidad de llamar al método original. Según se ha expuesto, la modificación de la tabla de punteros de una interfaz de tipo COM solo tiene que llevarse a cabo la primera vez que se crea un objeto de ese tipo.
Una vez que se ha creado la interfaz lAudioRenderClient y ha sido interceptada por el fragmento de código inyectado en el juego que intenta obtener acceso a la tarjeta de sonido, el fragmento de código devuelve el objeto lAudioRenderClient correspondiente al proceso.
Cuando el proceso que pertenece a la aplicación llama al método GetBuffer de lAudioRenderClient para solicitar una memoria intermedia en la que pueden escribirse los datos de audio para la tarjeta de sonido (más específicamente, solicita la dirección del área de memoria en la que tiene que escribir los datos de audio), el fragmento de código intercepta esta llamada (debe tenerse en cuenta que el método GetBuffer es redirigido a un método correspondiente comprendido en el fragmento de código, de forma que el proceso realmente llame al método correspondiente comprendido en el fragmento de código). El método correspondiente comprendido en el fragmento de código llama al método original de la API (aunque el fragmento de código podría comprender todo el método) y genera una memoria intermedia que virtualiza la memoria intermedia asociada con la tarjeta de sonido, es decir, el método pasa una dirección de un área de memoria en la que la aplicación ha de escribir los datos de audio en el proceso. Por lo tanto, el proceso no almacena los datos de audio en la memoria intermedia de la tarjeta de sonido del servidor de juegos sino, más bien, en la memoria intermedia virtualizada correspondiente a la memoria intermedia de la tarjeta real.
Una vez que la aplicación escribe todos los datos de audio en la memoria intermedia virtualizada, realiza una llamada a la función ReleaseBuffer para indicar que acaba de terminar de escribir los datos de audio y cuánto ha escrito. Esta llamada es interceptada de nuevo por el fragmento de código, de modo que es posible conocer cuándo se han escrito todos los datos de audio en la memoria intermedia virtualizada y cuántos datos de audio han sido escritos.
Además, debido a problemas relacionados con el control de la aplicación por parte de la tarjeta de sonido, el fragmento de código envía una memoria intermedia del mismo tamaño a la tarjeta de sonido, que solo comprende silencio. Por lo tanto, el fragmento de código se asegura de que la tarjeta de sonido continúe controlando correctamente la aplicación.
En paralelo a lo que ha sido descrito, el fragmento de código genera un hilo de ejecución simulando el comportamiento de la tarjeta de sonido del servidor de juegos. Es importante indicar que este hilo de ejecución no es más que una función comprendida en el mismo fragmento de código. El fragmento de código suspende la ejecución del hilo durante aproximadamente unos milisegundos, bien de forma síncrona o bien de forma asíncrona. Tras la suspensión, el hilo de ejecución lee los datos de audio del proceso almacenado en la memoria intermedia virtualizada, los procesa y los envía al terminal móvil para su reproducción.
El procesamiento de los datos de audio puede comprender la mezcla de distintos datos de audio (por ejemplo, la música de fondo escuchada mientras se ejecuta el juego y el audio escuchado debido a la intervención del usuario en el juego (por ejemplo, disparos, motores de coche, espadas, etc.)) y puede convertirlos en un formato adecuado de audio tal como mp3 (según el estándar MPEG-1 Audio capa III). Una vez que los datos de audio tienen el formato correcto, el fragmento de código los envía al terminal móvil a través de cualquier red de comunicaciones (por ejemplo, Internet), de forma que sean reproducidos mientras que el usuario disfruta del juego.
En la presente realización preferente, se ha descrito una solicitud por parte de un juego de acceder a la tarjeta de sonido. En realidad, se pueden ejecutar simultáneamente una pluralidad de juegos y/o una pluralidad de casos de un solo juego en el servidor de juegos, de forma que cada uno de ellos debería comprender un fragmento de código inyectado para ejecutar el procedimiento descrito.
En el caso de que el recurso de soporte físico que ha de ser virtualizado por el juego sea la tarjeta de sonido del servidor de juegos, y en función de una situación en la que el procedimiento principal del juego en cuestión fue iniciado en el estado de reposo, y en la que se ha inyectado el fragmento de código en el proceso, el procedimiento para la virtualización de la tarjeta de vídeo es como sigue.
Como en el caso de otros recursos de soporte físico, antes de reanudar la ejecución del proceso el fragmento de código inyectado redirige las funciones necesarias de API, en este caso, por ejemplo, la función ShowWindow o CreateDevice de la API DirectX. De nuevo, el objetivo principal de este procedimiento es que el fragmento de código se haga cargo, de una forma transparente, la gestión del flujo de datos producido entre la tarjeta de vídeo y el proceso que pertenece a la aplicación.
Según se ha expuesto anteriormente, estas API son implementadas en bibliotecas de enlace dinámico (en la presente realización en la que el sistema operativo es uno de la familia Windows, estas bibliotecas son DLL). Por lo tanto, el fragmento de código carga, por medio de la función LoadLibrary, la biblioteca o las bibliotecas que comprenden las funciones que han de ser redirigidas, por ejemplo la función ShowWindow, a través de la biblioteca user32.dll. Una vez cargadas, y después de que el sistema operativo ha rellenado la tabla de direcciones de indexación (IAT) con punteros a funciones para las funciones de API en función de las direcciones iniciales de memoria en las que se almacenan estas funciones, por medio de la función RedirectAIT, el fragmento de código modifica los punteros de las funciones que pueden ser de interés para virtualizar la tarjeta de vídeo. Con ese fin, sustituye las direcciones iniciales de memoria en las que se almacenan estas funciones de API por las direcciones iniciales de memoria en las que se almacenan las funciones correspondientes comprendidas en el fragmento de código. De forma alternativa, la IAT también podría ser modificada con código específico si es necesario.
Por otra parte, para redirigir los servicios de las interfaces de tipo COM tales como IDirect3DDevice9, es necesario modificar la tabla de punteros de la interfaz para sustituir los métodos relevantes. La tabla de punteros a métodos para métodos de una interfaz de tipo COM se modifica con un código específico. Por lo tanto, por ejemplo, Present se corresponde con la posición 18 de la tabla de métodos para métodos de la interfaz IDirect3DDevice9 y tiene que ser modificada de forma que apunte a la función correspondiente comprendida en el fragmento de código. Al mismo tiempo, se guarda el contenido original de esta posición en una variable en caso de que el método original tenga que ser llamado desde el fragmento de código. La modificación de la tabla de punteros de una interfaz de tipo COM solo tiene que ser efectuada la primera vez que se crea un objeto de ese tipo. Cuando termina la interceptación, es decir, se han redirigido todas las funciones de todas las API necesarias para llevar a cabo la virtualización de recursos, el fragmento de código tiene la responsabilidad de reanudar la ejecución del proceso de la aplicación.
Cuando el proceso solicita que se muestre una ventana en la que se van a dibujar gráficos o solicita la creación de una interfaz de tipo IDirect3DDevice9 por medio de la función CreateDevice de la API DirectX, estas llamadas son interceptadas para capturar o virtualizar el contexto de dibujo (DC) (en este caso puede realizarse con el DC original o se puede proporcionar un DC virtualizado). El DC puede definirse como un área de memoria en la que la tarjeta de vídeo almacenará los gráficos resultantes fotograma a fotograma y siempre está asociada con una ventana en Windows. Por lo tanto, para la virtualización de la tarjeta de vídeo del servidor de juegos, se debe acceder a esta área por medio de la función getDG. El acceso a este DC es mutuamente excluyente; es decir, si la tarjeta de vídeo está accediendo a esta área de memoria, ningún hilo de ejecución de ningún proceso puede acceder a ella.
Una vez que la aplicación ha creado la interfaz IDirect3DDevice9 o ha mostrado, al menos, la ventana en la que se mostrarán los gráficos, comienza a enviar los datos necesarios a la tarjeta de vídeo, de manera que comience todo el procesamiento de esta información y se cree el fotograma resultante. Esto es independiente del fragmento de código.
Cada poco tiempo, el hilo de virtualización del vídeo captura el contenido del DC. Puede hacerlo de una forma síncrona o de una forma asíncrona con la aplicación.
De una forma síncrona, significa que cuando el proceso realiza una solicitud de acceder a la tarjeta de vídeo invocando el método Present de la interfaz IDirect3DDevice9, de forma que muestre el fotograma generado, el fragmento de código intercepta este método Present. En ese momento, el hilo de ejecución accede al DC (en este caso se denomina BackBuffer) para capturar el fotograma generado. Subsiguientemente, si es necesario, el fragmento de código llama al método Present original de la interfaz. Este procedimiento es sincronizado debido a que hay un punto, cuando se llama al método Present, en el que el fragmento de código sabe perfectamente que el trabajo que ha de realizarse para dibujar el fotograma ha terminado.
De una forma asíncrona, consiste en acceder directamente al DC de la ventana (en la que la tarjeta de vídeo deja el resultado de generar el fotograma) para acceder al contenido. Debe tenerse en cuenta que el acceso a este DC tiene que ser done de una forma mutuamente excluyente. Con ese fin, el hilo de ejecución intenta obtener acceso, por medio de una inspección, a esta área mutuamente excluyente. Cuando lo hace, accede al contenido del DC para capturar el resultado del fotograma generado. Este método es asíncrono, dado que la tasa de captura de fotogramas y la tasa de generación de fotogramas no tienen que ser idénticas.
En cualquiera de los dos métodos, en cuanto se ha capturado el contenido del DC, es decir, el fotograma, comienza el procesamiento de esta información, y puede basarse en la codificación por medio de un códec adecuado, tal como H.264 por ejemplo, y el envío de esta codificación por Internet.
En el caso de que el recurso de soporte físico sea un elemento de entrada de datos, tal como un ratón o teclado, el procedimiento específico es como sigue. A diferencia de lo que se ha descrito hasta ahora, este procedimiento gestiona un flujo de datos que va del elemento de entrada de datos al proceso que pertenece a la aplicación; es decir, el procedimiento busca enviar instrucciones procedentes del usuario que disfruta del juego (por ejemplo, a través de la pantalla táctil o desde el teclado del terminal móvil) al juego que está siendo ejecutado en el servidor de juegos para el desarrollo del juego.
Por lo tanto, en función de una situación en la que ya se ha inyectado el fragmento de código en el proceso (es decir, en el juego), el fragmento de código ha redirigido los servicios relevantes y generado el recurso virtualizado de soporte físico (es decir, ha generado una memoria intermedia que virtualiza la memoria intermedia del elemento de entrada de datos, al igual que un hilo de ejecución que emula el comportamiento del elemento de entrada de datos), el fragmento de código (más específicamente, el hilo de ejecución que simula el comportamiento del elemento de entrada) recibe datos procedentes del terminal móvil del usuario, datos que tienen que ser enviados al proceso, de forma que pueda modificar, por ejemplo, los datos referentes al audio y al vídeo, que enviará subsiguientemente al terminal móvil. Con ese fin, dependiendo del elemento de entrada desde el cual se reciben los datos, el fragmento de código almacena estos datos recibidos en la memoria intermedia virtualizada correspondiente (bien los correspondientes a los del teclado virtualizado o bien los del ratón virtualizado).
Cuando el proceso realiza una llamada al servicio correspondiente para obtener datos procedentes del elemento de entrada (el teclado o ratón real, es decir, el asociado con el servidor de juegos), el fragmento de código intercepta esta llamada y provoca la ejecución del servicio correspondiente comprendido en el fragmento de código, de forma que este servicio lea los datos almacenados en la memoria intermedia virtualizada y no en la memoria intermedia del elemento real de entrada.
Tomando en cuenta que el sistema operativo de la presente realización preferente es uno de la familia Windows, es necesario tener en cuenta Windows Messages. En este caso, el hilo de ejecución que emula la cola de mensajes recibe las entradas de datos (por ejemplo, el teclado o ratón) procedentes del sistema remoto (es decir, el terminal móvil) a través de la red (por ejemplo, Internet). Estos datos pueden ser instrucciones y/o eventos que el usuario envía desde el terminal móvil. Por lo tanto, para cada entrada de datos el hilo de ejecución introduce un mensaje en la cola de mensajes (por medio de las funciones SendMessage y PostMessage de la biblioteca user32.dll) asociado con la ventana de la aplicación. Esta cola de mensajes interroga a la aplicación automáticamente por medio del mecanismo del sistema de formación de colas de mensajes ofrecido por el sistema operativo. Además, para completar la virtualización de la cola de mensajes, puede ser necesario cambiar la consulta y la función de tratamiento de la cola de mensajes (por medio de la función SetWindow-LongPtr de la biblioteca user32.dll), de forma que, en vez de ejecutar la función de tratamiento del mensaje original de la cola de mensajes (también conocida como método o función ventana, que es una función que el programador define para determinar el comportamiento de la aplicación en respuesta a un cierto mensaje), se ejecute una función del fragmento de código. En otras palabras, se intercepta el método o función ventana de la ventana correspondiente a la aplicación. Dicha función del fragmento de código puede: eliminar los mensajes que no han de ser tratados por la función original de la ventana de la aplicación (es decir, no se lleva a cabo ninguna acción en respuesta al mensaje) y, por lo tanto, lograr que la aplicación ignore dichos mensajes dado que la función original nunca los trata realmente; o, partiendo desde la función del fragmento de código, llamar a la función de tratamiento del mensaje original, dado que la aplicación ha de reaccionar en respuesta a estos mensajes tanto debido a que son mensajes que han sido introducidos por el hilo de ejecución del fragmento de código que emula el recurso virtualizado de soporte físico que introduce datos (teclado o ratón) en función de instrucciones enviadas por el terminal móvil, y debido a que son mensajes que no alteran el comportamiento de la aplicación desde la perspectiva del usuario del terminal móvil (la ventana ha sido movida en la pantalla del sistema informático real, pero esta posición es completamente irrelevante para el usuario del sistema remoto).
Finalmente, en el caso de que el recurso de soporte físico en el que el proceso realiza la solicitud de acceso sea una unidad de almacenamiento, tal como una unidad de disco duro, el procedimiento es como sigue. En este caso, se supone que el fragmento de código ya ha sido inyectado en el proceso.
Antes de reanudar la ejecución del proceso (téngase en cuenta que en la presente realización preferente se inicia el proceso en el estado de reposo), el fragmento de código inyectado redirige todas las funciones de API requeridas, por ejemplo CreateFile y CreateDirectory. El objetivo principal es que el fragmento de código se haga con el control del flujo de datos entre el proceso y la unidad de disco duro.
Según se ha expuesto para los recursos restantes de soporte físico, dado que se implementan estas API en bibliotecas de enlace dinámico, el fragmento de código debe cargarlas en la memoria por medio de la función LoadLibrary. Por lo tanto, LoadLibrary carga la biblioteca que contiene las funciones que han de ser redirigidas, por ejemplo CreateFile y CreateDirectory de la biblioteca kernel32.dll. Entonces, el sistema operativo rellena la IAT con la dirección inicial de memoria en la que se almacena cada una de las funciones de API. Los punteros necesarios son modificados por medio de la función RedirectIAT, haciendo que tales punteros apunten a las funciones correspondientes comprendidas en el fragmento de código. Cuando el fragmento de código termina de redirigir las funciones relevantes para la gestión del flujo de datos entre el proceso y la unidad de disco duro, el propio fragmento de código es responsable de reanudar la ejecución del proceso que pertenece a la aplicación que fue iniciada en el estado de reposo.
Cuando el proceso desea crear y/o abrir un fichero por medio de la función CreateFile, el fragmento de código intercepta la solicitud y ejecuta la función correspondiente comprendida en el fragmento de código. En función de la interceptación, esta función verifica si el fichero que ha de ser abierto por el proceso es un fichero para la sesión del juego o si es cualquier otro fichero. En el caso de que sea un fichero para la sesión, la función modifica, si es necesario, la ruta al fichero que ha de ser creada y/o abierta por medio de cualquier tipo de algoritmo. Una vez se ha modificado la ruta, se ejecuta la función CreateFile original con la nuevo ruta creado, aunque también se podría ejecutar una función correspondiente comprendida en el fragmento de código. El método para crear un directorio por medio de la función CreateDirectory es equivalente al descrito para la función CreateFile.
Evidentemente, en la presente realización preferente se ha descrito por separado la virtualización de cada recurso de soporte físico. En caso de que un solo fragmento de código tenga capacidad para virtualizar varios recursos de soporte físico, las primeras etapas del procedimiento; por ejemplo, la etapa de cargar en la memoria las distintas bibliotecas de enlace dinámico o la etapa de sustituir los punteros a servicios, pueden ser comunes, es decir, todas las bibliotecas de enlace dinámico que comprenden API con servicios relevantes para todos los recursos de soporte físico que el fragmento de código tiene capacidad para virtualizar pueden ser cargadas en la memoria al mismo tiempo, y se pueden sustituir los punteros de todos los servicios que han de ser redirigidos de forma que el fragmento de código pueda virtualizar todos los recursos de soporte físico que tiene capacidad de virtualizar.
Aunque se ha descrito y mostrado una realización específica de la presente invención, es evidente que el experto en la técnica puede incluir variantes y modificaciones o sustituir los detalles por otros detalles técnicamente equivalentes sin alejarse del alcance de protección definido por las reivindicaciones adjuntas.
Aunque las realizaciones de la invención descritas con referencia a los dibujos comprenden sistemas de ordenador y procesos llevados a cabo en sistemas de ordenador, la invención también abarca programas de ordenador, más en particular programas de ordenador en o sobre medios portadores, adecuados para poner la invención en práctica. El programa de ordenador puede tener la forma de un código fuente, un código objeto o de un código intermedio entre un código fuente y un código objeto, tal como una forma parcialmente compilada, o cualquier otra forma adecuada para su uso en la implementación de los procesos según la invención. El medio portador puede ser cualquier entidad o dispositivo con capacidad de contener el programa.
Por ejemplo, el medio portador puede comprender un medio de almacenamiento, tal como una ROM, por ejemplo, un CD r Om o una ROM de semiconductor o un medio magnético grabable, por ejemplo un disquete o un disco duro. Además, el medio portador puede ser un medio portador transmisible, tal como una señal eléctrica u óptica que puede ser transmitida a través de un cable eléctrico u óptico o por medio de radio u otros medios.
Cuando el programa de ordenador está contenido en una señal que puede ser transmitida directamente por medio de un cable u otro dispositivo o medio, el medio portador puede formarse mediante dicho cable u otro dispositivo o medio.
De forma alternativa, el medio portador puede ser un circuito integrado en el que se embebe el programa de ordenador, siendo adecuado dicho circuito integrado para llevar a cabo los procesos relevantes, o para ser utilizado llevando a cabo los mismos.

Claims (14)

REIVINDICACIONES
1. Un procedimiento para la virtualización de un recurso de soporte físico asociado con un sistema informático, comprendiendo dicho procedimiento:
- inyectar un fragmento de código ejecutable en un proceso que pertenece a una aplicación que es ejecutado en un sistema operativo que comprende al menos una interfaz para programación de aplicaciones que es ejecutada en el sistema informático;
- interceptar una llamada procedente del proceso que pertenece a la aplicación a un servicio de interfaz para programación de aplicaciones relacionado con la gestión de un flujo de datos producido entre el proceso y el recurso de soporte físico, comprendiendo la interceptación al menos la redirección de un servicio de interfaz para programación de aplicaciones relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico a un servicio correspondiente comprendido en el fragmento de código;
- gestionar el flujo de datos producido entre el proceso y el recurso de soporte físico mediante el fragmento de código en función de la interceptación de la llamada procedente del proceso al servicio de interfaz para programación de aplicaciones relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico, comprendiendo dicha gestión del flujo de datos:
o verificar si se ha generado un recurso virtualizado de soporte físico correspondiente al recurso de soporte físico; y
o en el caso de un resultado negativo en la verificación, generar el recurso virtualizado de soporte físico, generándose dicho recurso virtualizado de soporte físico generando una memoria intermedia que virtualiza la memoria intermedia asociada con el recurso de soporte físico, y/o generando un hilo de ejecución que emula el comportamiento del recurso de soporte físico,
en el que las dos etapas citadas de interceptación y de gestión son llevadas a cabo por medio del sistema informático y en el sistema operativo;
en el que el servicio de interfaz para programación de aplicaciones es una función o un método objeto; y en el que la redirección de un servicio de interfaz para programación de aplicaciones relacionado con la gestión del flujo de datos entre el proceso y el recurso de soporte físico a un servicio correspondiente comprendido en el fragmento de código comprende:
■ cargar en la memoria una biblioteca de enlace dinámico que comprende el método objeto o la función de la interfaz para programación de aplicaciones que ha de ser redirigido;
■ sustituir, en una tabla de punteros a funciones para los métodos objeto o funciones comprendidos en la biblioteca cargada de enlace dinámico, la dirección inicial de memoria en la que se almacena el método objeto o la función de la interfaz para programación de aplicaciones que ha de ser redirigido por la dirección inicial de memoria en la que se almacena el método objeto o la función correspondiente comprendido en el fragmento de código, llevándose a cabo la sustitución, en caso de el servicio de interfaz para programación de aplicaciones sea un método objeto que se lleva a cabo después de haber verificado que el objeto asociado con el método que ha de ser redirigido ha sido creado por primera vez.
2. El procedimiento según la reivindicación 1 en el que, si el servicio de interfaz para programación de aplicaciones es una función que redirige un servicio de interfaz para programación de aplicaciones relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico a un servicio correspondiente comprendido en el fragmento de código, comprende:
■ almacenar en una primera variable la dirección inicial de memoria en la que se almacena la función de interfaz para programación de aplicaciones que ha de ser redirigida,
y en el que, si el servicio de interfaz para programación de aplicaciones es un método objeto que redirige un servicio de interfaz para programación de aplicaciones relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico a un servicio correspondiente comprendido en el fragmento de código, comprende:
■ almacenar en una segunda variable la dirección inicial de memoria en la que se almacena el método objeto que ha de ser redirigido.
3. El procedimiento según la reivindicación 1, en el que la interceptación de una llamada procedente del proceso que pertenece a la aplicación a un servicio de interfaz para programación de aplicaciones relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico comprende:
■ recibir una llamada procedente del proceso al servicio comprendido en el fragmento de código correspondiente al servicio de interfaz para programación de aplicaciones relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico.
4. El procedimiento según la reivindicación 1, en el que el proceso que pertenece a la aplicación fue iniciado en el estado de reposo, y comprende:
- reanudar la ejecución del proceso que pertenece a la aplicación que se encuentra en el estado de reposo.
5. El procedimiento según la reivindicación 1, en el que la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico comprende:
■ almacenar en la memoria intermedia virtualizada los datos enviados por el proceso al recurso de soporte físico.
6. El procedimiento según la reivindicación 5, en el que la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico comprende:
■ suspender el hilo generado de ejecución que emula el comportamiento del recurso de soporte físico durante un tiempo predeterminado;
■ obtener los datos almacenados en la memoria intermedia virtualizada, enviados anteriormente por el proceso al recurso de soporte físico; y
■ procesar los datos obtenidos.
7. El procedimiento según la reivindicación 6, en el que la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico comprende:
■ enviar los datos procesados a un primer sistema remoto de ordenador.
8. El procedimiento según la reivindicación 5, que comprende:
- gestionar el flujo de datos producido desde el recurso virtualizado de soporte físico hasta el proceso que pertenece a la aplicación.
9. El procedimiento según una cualquiera de las reivindicaciones 1,6 o 7, que comprende:
- gestionar el flujo de datos producido desde el recurso virtualizado de soporte físico hasta el proceso que pertenece a la aplicación, que comprende:
■ recibir datos procedentes de un segundo sistema remoto de ordenador;
■ procesar los datos recibidos;
■ almacenar los datos procesados en la memoria intermedia virtualizada.
10. El procedimiento según la reivindicación 9, en el que la interceptación de una llamada procedente del proceso que pertenece a la aplicación a un servicio de interfaz para programación de aplicaciones relacionado con la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico comprende:
■ interceptar una llamada procedente del proceso que pertenece a la aplicación a un servicio de interfaz para programación de aplicaciones relacionado con la gestión del flujo de datos producido desde el recurso de soporte físico hasta el proceso;
y en el que la gestión del flujo de datos producido desde el recurso virtualizado de soporte físico hasta el proceso que pertenece a la aplicación comprende:
■ recuperar los datos almacenados en la memoria intermedia virtualizada;
■ enviar los datos recuperados al proceso.
11. El procedimiento según la reivindicación 10, en el que la interceptación de una llamada procedente del proceso a un servicio de interfaz para programación de aplicaciones relacionado con la gestión del flujo de datos producido desde el recurso de soporte físico hasta el proceso comprende:
■ recibir una llamada procedente del proceso al servicio comprendido en el fragmento de código correspondiente al servicio de interfaz para programación de aplicaciones relacionado con la gestión del flujo de datos producido desde el recurso de soporte físico hasta el proceso,
y en el que la gestión del flujo de datos producido entre el proceso y el recurso de soporte físico comprende:
■ gestionar el flujo de datos producido desde el recurso de soporte físico hasta el proceso, lo cual comprende:
o verificar si hay datos procedentes del recurso de soporte físico en la memoria intermedia;
o en el caso de un resultado positivo en la verificación, eliminar estos datos.
12. Un sistema informático, que comprende:
- un sistema operativo mediante el cual se ejecuta al menos una interfaz para programación de aplicaciones; - una memoria; y
- al menos un procesador,
en el que la memoria almacena instrucciones ejecutables por un procesador correspondientes a un fragmento de código ejecutable que comprende instrucciones para ejecutar un procedimiento para la virtualización de un recurso de soporte físico asociado con un sistema informático según una cualquiera de las reivindicaciones 1 a 11 y adaptado para ser inyectado en un proceso que pertenece a la aplicación.
13. El sistema informático según la reivindicación 12, en el que al menos dos aplicaciones son ejecutadas en el sistema operativo, y en el que la memoria almacena instrucciones ejecutables por un procesador correspondientes a un fragmento de código para cada aplicación que esté siendo ejecutada.
14. Un programa informático de aplicación que puede ser ejecutado en un sistema operativo de un sistema informático, comprendiendo el programa de ordenador un fragmento de código ejecutable que comprende instrucciones, que, cuando son ejecutadas por un procesador, implementan el procedimiento según cualquiera de las reivindicaciones 1 a 11 anteriores.
ES13778383T 2012-04-19 2013-04-18 Procedimiento, sistema y fragmento de código ejecutable para la virtualización de un recurso de soporte físico asociado a un sistema informático Active ES2798184T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ES201230581A ES2439804B1 (es) 2012-04-19 2012-04-19 Procedimiento, sistema y pieza de código ejecutable para virtualizar un recurso de hardware asociado a un sistema informático
PCT/ES2013/070247 WO2013156654A1 (es) 2012-04-19 2013-04-18 Procedimiento, sistema y pieza de código ejecutable para virtualizar un recurso de hardware asociado a un sistema informático

Publications (1)

Publication Number Publication Date
ES2798184T3 true ES2798184T3 (es) 2020-12-09

Family

ID=49382969

Family Applications (2)

Application Number Title Priority Date Filing Date
ES201230581A Active ES2439804B1 (es) 2012-04-19 2012-04-19 Procedimiento, sistema y pieza de código ejecutable para virtualizar un recurso de hardware asociado a un sistema informático
ES13778383T Active ES2798184T3 (es) 2012-04-19 2013-04-18 Procedimiento, sistema y fragmento de código ejecutable para la virtualización de un recurso de soporte físico asociado a un sistema informático

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES201230581A Active ES2439804B1 (es) 2012-04-19 2012-04-19 Procedimiento, sistema y pieza de código ejecutable para virtualizar un recurso de hardware asociado a un sistema informático

Country Status (9)

Country Link
US (1) US9176757B2 (es)
EP (1) EP2840497B1 (es)
JP (1) JP2015517158A (es)
KR (1) KR102059219B1 (es)
CN (1) CN104380256B (es)
DK (1) DK2840497T3 (es)
ES (2) ES2439804B1 (es)
HU (1) HUE049385T2 (es)
WO (1) WO2013156654A1 (es)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2439803B1 (es) 2012-04-19 2014-10-29 Universitat Politècnica De Catalunya Procedimiento, sistema y pieza de código ejecutable para controlar el uso de recursos de hardware de un sistema informático
ES2439804B1 (es) 2012-04-19 2014-10-29 Universitat Politècnica De Catalunya Procedimiento, sistema y pieza de código ejecutable para virtualizar un recurso de hardware asociado a un sistema informático
US9424429B1 (en) 2013-11-18 2016-08-23 Amazon Technologies, Inc. Account management services for load balancers
US10834587B2 (en) 2014-09-22 2020-11-10 American Greetings Corporation Live greetings
US10425459B2 (en) * 2015-03-27 2019-09-24 Intel Corporation Technologies for a seamless data streaming experience
US9971542B2 (en) * 2015-06-09 2018-05-15 Ultrata, Llc Infinite memory fabric streams and APIs
EP3332321B1 (en) * 2015-09-24 2023-06-07 Hewlett Packard Enterprise Development LP Process and thread launch features
CN107045474B (zh) * 2016-02-05 2020-12-04 阿里巴巴集团控股有限公司 一种Fuzz测试中的程序流跟踪方法及装置
CN106601263A (zh) * 2016-12-01 2017-04-26 武汉斗鱼网络科技有限公司 一种获取声卡和麦克风声音并进行混音的方法及系统
CN108958905B (zh) * 2017-05-25 2024-04-05 北京忆恒创源科技股份有限公司 嵌入式多核中央处理器的轻量级操作系统
CN107213634B (zh) * 2017-06-13 2020-07-07 北京凯罗天下科技有限公司 一种游戏用户管理方法、游戏服务器及系统
CN109814939B (zh) * 2017-11-20 2021-10-15 华为技术有限公司 一种动态加载方法、目标文件的制作方法及装置
CN108566424B (zh) * 2018-04-11 2021-04-20 深圳市腾讯网络信息技术有限公司 基于服务器资源消耗预测的调度方法、装置和系统
US10742725B2 (en) * 2018-05-04 2020-08-11 Citrix Systems, Inc. Detection and repainting of semi-transparent overlays
CN110275722B (zh) * 2019-06-21 2023-08-08 北京百度网讯科技有限公司 用于升级应用的方法、装置、设备和存储介质
CN111223036B (zh) * 2019-12-29 2023-11-03 广东浪潮大数据研究有限公司 一种gpu虚拟化共享方法、装置及电子设备和存储介质
WO2022269870A1 (ja) * 2021-06-24 2022-12-29 日本電信電話株式会社 リソース動的割り当て装置、リソース動的割り当てプログラム、リソース動的割り当てシステム、および、リソース動的割り当て方法

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IL132916A (en) * 1999-11-14 2004-02-08 Mcafee Inc Method and system for intercepting an application program interface
JP2003515219A (ja) * 1999-11-14 2003-04-22 クリックネット ソフトウエア，インク． アプリケーションプログラムインターフェースを阻害する方法及びシステム
US6990663B1 (en) * 2000-06-08 2006-01-24 International Business Machines Corporation Hypervisor virtualization of OS console and operator panel
US6832460B2 (en) * 2003-02-18 2004-12-21 Robert E. Fligg Method and apparatus for insulating building roofs from above
USH2202H1 (en) * 2004-04-28 2007-09-04 Symantec Corporation Method and apparatus to dynamically hook runtime processes without interrupting the flow of execution
US8606891B2 (en) * 2004-09-10 2013-12-10 Freestyle Technology Pty Ltd Client processor device for building application files from file fragments for different versions of an application
US20060020940A1 (en) * 2004-07-08 2006-01-26 Culter Bradley G Soft-partitioning systems and methods
US7757231B2 (en) * 2004-12-10 2010-07-13 Intel Corporation System and method to deprivilege components of a virtual machine monitor
US20110157196A1 (en) * 2005-08-16 2011-06-30 Exent Technologies, Ltd. Remote gaming features
US7844442B2 (en) 2005-08-16 2010-11-30 Exent Technologies, Ltd. System and method for providing a remote user interface for an application executing on a computing device
US8116312B2 (en) * 2006-02-08 2012-02-14 Solarflare Communications, Inc. Method and apparatus for multicast packet reception
WO2010030703A1 (en) * 2008-09-09 2010-03-18 Kace Networks, Inc. Deployment and management of virtual containers
KR20110051028A (ko) * 2009-11-09 2011-05-17 주식회사 케이티 보안 기능이 구비된 클라우드 컴퓨팅 시스템
US20130061012A1 (en) * 2010-05-30 2013-03-07 Yoshio Turner Virtual machine code injection
ES2439804B1 (es) 2012-04-19 2014-10-29 Universitat Politècnica De Catalunya Procedimiento, sistema y pieza de código ejecutable para virtualizar un recurso de hardware asociado a un sistema informático
ES2439803B1 (es) 2012-04-19 2014-10-29 Universitat Politècnica De Catalunya Procedimiento, sistema y pieza de código ejecutable para controlar el uso de recursos de hardware de un sistema informático

Also Published As

Publication number Publication date
KR102059219B1 (ko) 2019-12-24
JP2015517158A (ja) 2015-06-18
HUE049385T2 (hu) 2020-09-28
CN104380256B (zh) 2017-09-12
DK2840497T3 (da) 2020-06-08
ES2439804A1 (es) 2014-01-24
US9176757B2 (en) 2015-11-03
WO2013156654A1 (es) 2013-10-24
ES2439804B1 (es) 2014-10-29
EP2840497A4 (en) 2015-11-11
CN104380256A (zh) 2015-02-25
EP2840497B1 (en) 2020-03-18
US20150135200A1 (en) 2015-05-14
EP2840497A1 (en) 2015-02-25
KR20140147140A (ko) 2014-12-29

Similar Documents

Publication Publication Date Title
ES2798184T3 (es) Procedimiento, sistema y fragmento de código ejecutable para la virtualización de un recurso de soporte físico asociado a un sistema informático
US9830176B2 (en) Methods, systems, and media for binary compatible graphics support in mobile operating systems
US9098437B2 (en) Cross-environment communication framework
US9092627B2 (en) Apparatus and method for providing security information in virtual environment
RU2436149C2 (ru) Мигрирование виртуальной машины, которая владеет ресурсом, таким, как аппаратное устройство
CN107273199B (zh) 用于管理虚拟化环境中的中断的体系结构和方法
US9542224B2 (en) User space function execution from a kernel context for input/output filtering from a thread executing in the user space
EP2843552B1 (en) Method and system for executing callback functions delivered via a communication between a user-space application and the operating system kernel
US20160077850A1 (en) Methods, systems, and media for binary compatibility
US9842091B2 (en) Switching to and from native web applications
CN108509251B (zh) 一种适用于可信执行环境中的安全虚拟化系统
US8132167B2 (en) Context based virtualization
EP2622490A2 (en) Cross-environment communication framework
US20180196584A1 (en) Execution of multiple applications on a device
JP2023509630A (ja) メディアアプリケーションのためのマルチメディアリダイレクト
US10733005B1 (en) Providing access to mobile applications by heterogeneous devices
US20150381766A1 (en) Application transfer system, application transfer method, terminal, and program
CN108351888B (zh) 生成可推迟数据流
Almisreb et al. A review on mobile operating systems and application development platforms
WO2013185664A1 (zh) 一种操作方法及装置
Andrus Multi-Persona Mobile Computing
KR20210086263A (ko) 이기종 다중 기기 상호작용을 위한 안전한 사용자 인터페이스 분산 방법
Oh et al. Supporting Flexible and Transparent User Interface Distribution across Mobile Devices
Smaldone et al. Safe transient use of local storage for VM-based mobility
Kajaria et al. Music Player in Android