La invención se refiere también a un sistema y a la pieza de código ejecutable adecuados para llevar a cabo este procedimiento.

Antecedentes de la invención

Desde hace ya algunos años, principalmente desde la consolidación del modelo de computación en la nube, el concepto de "virtualización" está tomando una posición destacada dentro del mundo de la informática, Básicamente, la virtualización puede definirse como la creación mediante software de una versión virtual de un recurso tecnológico, tal como una plataforma de hardware, un sistema operativo, un dispositivo de almacenamiento de datos u otros recursos de red, de manera que este recurso pueda dividirse en uno o más entornos de ejecución. Es importante destacar que también puede darse el caso en el que este software esté asistido por tecnología hardware de virtualización, tal como Intel-VT o AMD-V (ver, por ejemplo, Wikipedia en español - htíp://es.wikípedia,org/wikiA iríualización},

Uno de los recursos tecnológicos que más comúnmente se virtualiza es un sistema informático (por ejemplo, un ordenador personal o un servidor), que permite a este sistema informático ejecutar múltiples instancias de diferentes sistemas operativos de forma concurrente. De este modo, el sistema informático es capaz de ejecutar diferentes aplicaciones que requieren diferentes sistemas operativos. i Es conocido también un tipo de virtualización que permite emular los recursos de hardware del sistema informático. Para ello es necesario instalar en el sistema informático un software de virtualización que tiene como objetivo hacer accesibles los recursos de hardware del sistema informático a todos los sistemas operativos instalados. Además, este software de virtualización tiene también como objetivo coordinar el acceso a los recursos de hardware virtualizados por parte de los diferentes sistemas operativos instalados en el sistema informático.

La virtualización de recursos de hardware de un sistema informático (aunque también es aplicable a cualquier otro tipo de virtualización), a pesar que presenta algunas ventajas (por ejemplo, como se ha comentado anteriormente, permite la ejecución de varios sistemas operativos de forma concurrente sobre un mismo sistema informático), también presenta un número importante de inconvenientes.

Así, por ejemplo, este tipo de virtualización puede suponer una disminución en el rendimiento del sistema informático, como resultado de la sobrecarga que supone la ejecución del software de virtualización sobre el sistema informático. Entre otras, puede verse afectada la ejecución de las aplicaciones, las cuales pueden correr más lentas que en sistemas que no son virtuales.

Relacionado con el inconveniente anterior, en muchos casos este tipo de virtualización puede virtualizar recursos que en ningún caso van a ser usados o necesitan ser virtualizados. Así, por ejemplo, si se pretende virtualizar el teclado de un sistema informático para que cada aplicación en ejecución disponga de un teclado virtual, sería necesario, de acuerdo con el estado de la técnica, crear tantos sistemas informáticos virtuales (máquina virtual más sistema operativo) como teclados virtuales sean requeridos por las diferentes aplicaciones en ejecución. Ello supone un consumo innecesario de recursos del sistema que, tal como se ha descrito anteriormente, repercute en el rendimiento del mismo. Descripción de la invenci

Por lo tanto, es un objetivo de la presente Invención proporcionar un procedimiento para virtuaíizar un recurso de hardware determinado asociado a 5 un sistema informático, sin necesidad de virtuaíizar la totalidad de sus recursos de hardware del sistema.

Este objetivo se consigue de acuerdo con la reivindicación 1 proporcionando un procedimiento para virtuaíizar un recurso de hardware asociado a un sistema i o informático por parte de una pieza de código ejecutable adaptada para ser inyectada en un proceso perteneciente a una aplicación que se ejecuta sobre un sistema operativo que comprende al menos una interfaz de programación de aplicaciones (API) y que se ejecuta sobre el sistema informático, comprendiendo el procedimiento:

15 - Interceptar una llamada del proceso perteneciente a la aplicación a un servicio de una API relacionado con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware;

- Gestionar el flujo de datos que se produce entre el proceso y el recurso de hardware por parte de la pieza de código, a partir de la interceptación 2 0 de la llamada del proceso al servicio de la API relacionado con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware.

De este modo, a diferencia del estado de la técnica, cada aplicación que se

25 ejecuta sobre el sistema operativo del sistema informático, mediante la pieza de código inyectada, puede virtuaíizar aquellos dispositivos de hardware requeridos para su ejecución, sin necesidad de virtuaíizar la totalidad de los recursos de hardware asociados al sistema. Esto supone una reducción en el consumo de recursos del sistema, al no virtualizarse recursos (por ejemplo, el

3 0 sistema operativo o cualquier recurso de hardware del sistema informático) que en ningún caso van a ser usados o necesitan ser virtualizados. Realmente, en la presente invención no existe un software de virtualización de la totalidad de los recursos del sistema informático tal como sucede en el estado de la técnica, sino que es la pieza de código inyectada a cada aplicación que se ejecuta 35 sobre el sistema informático la que decide o tiene previamente establecido qué recursos de hardware debe virtualizar para la correcta ejecución de la aplicación.

Siguiendo con el ejemplo de la virtualización del teclado de un sistema informático, con la presente invención sólo es necesario crear el teclado virtual, en lugar de todo el sistema informático. De esta forma, se consigue que la aplicación se ejecute directamente en la máquina real, no en la virtualizada, reduciendo mucho la sobrecarga introducida por la virtualización: sólo se produce una sobrecarga, aunque muy reducida, cuando se leen datos del teclado, en lugar de una sobrecarga importante en la ejecución de cada instrucción del programa.

Por otro lado, es importante destacar que la expresión "gestión del flujo de datos" se refiere a la transmisión y/o control del flujo de datos, de manera que los servicios que el proceso llama están relacionados con la gestión del flujo de datos. De este modo, cuando la pieza de código inyectada intercepta la llamada, es la pieza de código la que controla esta gestión, enviando por ejemplo el contenido de un búfer virtual. Para conseguir el objetivo descrito anteriormente es necesario en primer lugar interceptar las llamadas que el proceso perteneciente a la aplicación realiza a los servicios relacionados con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware. Por el término "interceptar" se entiende el hecho que la llamada del proceso al servicio de la API supone una redirección a un servicio comprendido en la pieza de código, de manera que es la propia pieza de código la que recibe la llamada del proceso para ejecutar este servicio correspondiente al servicio de la API (es decir, la llamada del proceso no alcanza el servicio de la API). Con esta interceptación, la pieza de código consigue tomar el control del flujo de datos entre el proceso y el recurso de hardware cuando el proceso hace una petición de acceso al mismo, al sistema operativo, puesto que la pieza de código actúa por encima del sistema operativo.

Previamente a esta interceptación, la pieza de código puede haber redireccionado uno o más servicios de una o más API relacionados con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware hacia servicios correspondientes comprendidos en la pieza de código, de manera que, ta! como se ha comentado más arriba, la llamada de! proceso ya no se realiza sobre un servicio de una API sino sobre el servicio correspondiente comprendido en la pieza de código.

Posteriormente a la interceptación, dado que es la pieza de código la que recibe las llamadas de! proceso y son servicios comprendidos en la pieza de código los que se ejecutan, la pieza de código puede gestionar el flujo de datos que se produce entre e! proceso y el recurso de hardware y así virtualizar el recurso de hardware, ya que los servicios comprendidos en la pieza de código están adaptados para ello.

Es importante destacar que las expresiones "un servicio", "una API", "una llamada" o "un recurso de hardware" se refieren a al menos un servicio, a al menos una API, a al menos una llamada y/o a a! menos un recurso de hardware, respectivamente. Así, por ejemplo, es posible redireccionar dos servicios de una misma API hacia dos servicios comprendidos en la pieza de código (es decir, a! menos dos llamadas realizadas por el proceso), o redireccionar un servicio de una primera API a un primer servicio comprendido en la pieza de código y un servicio de una segunda AP! a un segundo servicio comprendido en la pieza de código. Del mismo modo, dependiendo de los servicios redireccionados, es posible que una misma pieza de código sea capaz de virtualizar uno o más recursos de hardware, tales como una tarjeta de video, una tarjeta de audio, un disco duro, un teclado o un ratón, dependiendo de las necesidades de la aplicación durante su ejecución.

También es importante destacar que una manera de cómo inyectar la pieza de código ejecutable en el proceso se describe por ejemplo en ["Windows NT System-Caíl Hooking", Mark Russínovich and Bryce Cogswell, Dr. Dobb's

Journai, January 1997].

De acuerdo con una realización preferida de la invención, el proceso perteneciente a la aplicación puede iniciarse en un estado de suspensión, y durante este estado de suspensión inyectarse la pieza de código ejecutable en el proceso. Por lo tanto, el procedimiento de acuerdo con la invención debe contemplar la posibilidad de reiniciar el proceso si es que éste se ha iniciado en estado suspendido. De este modo, se asegura el correcto funcionamiento de la pieza de código.

De acuerdo con otra realización de la invención, el servicio de la API puede ser una función, y la etapa de redireccionar un servicio de una API relacionado con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware hacia un servicio correspondiente comprendido en la pieza de código puede comprender:

* Cargar en memoria la librería de enlace dinámico que comprende la función de la AP! a redireccionar;

* Sustituir, en la tabla de punteros a las funciones de la API comprendidas en la librería de enlace dinámico cargada, la dirección de memoria inicial en la que se almacena la función de la API a redireccionar por la dirección de memoria inicial en la que se almacena la función correspondiente comprendida en la pieza de código. De este modo, la pieza de código puede realizar la redirección de una o más funciones de una o varias AP! hacia funciones correspondientes comprendidas en la pieza de código, de manera que ésta puede interceptar las llamadas a estas funciones por parte del proceso y así gestionar el flujo de datos que se produce entre el proceso y el recurso de hardware (o recursos de hardware si la aplicación requiere virtualizar más de uno), lo que permite su virtualización.

Además, la etapa de redireccionar un servicio de una API relacionado con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware hacia un servicio correspondiente comprendido en la pieza de código puede comprender también almacenar en una primera variable la dirección de memoria inicial en la que se almacena la función de la API a redireccionar, de manera que esta función de la AP! (es decir, la función original) podrá ser llamada desde la propia pieza de código ejecutable, en el caso que sea necesario en algún momento durante la ejecución de la aplicación. Por otro lado, el servicio de la API puede ser un método de un objeto, y la etapa de redireccionar un servicio de una API relacionado con la gestión del flujo de datos que se produce entre el proceso y eí recurso de hardware hacia un servicio correspondiente comprendido en la pieza de código puede

Cargar en memoria la librería de enlace dinámico que comprende el método del objeto a redireccionar;

Verificar si el objeto asociado al método a redireccionar se crea por primera vez;

En caso de resultado positivo en ¡a verificación,

Sustituir, en ía tabla de punteros a los métodos del objeto comprendidos en la librería de enlace dinámico cargada, la dirección de memoria inicial en la que se almacena el método del objeto a redireccionar, por la dirección de memoria inicial en la que se almacena el método correspondiente comprendido en la pieza de código.

Igual que en el caso de las funciones, también es posible redireccionar uno o más métodos pertenecientes a un objeto hacia uno o más métodos comprendidos en la pieza de código, de manera que ésta puede interceptar las llamadas a estos métodos por parte del proceso y así gestionar el flujo de datos que se produce entre eí proceso y el recurso de hardware.

Puesto que, como se ha comentado anteriormente, es posible redireccionar al menos un servicio de al menos una AP!, se puede dar el caso que uno de los servicios sea una función y otro de los servicios sea un método, de manera que las dos realizaciones expuestas pueden llegar a ser complementarias para una misma aplicación en ejecución. Además, la etapa de redireccionar un servicio de una API relacionado con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware hacia un servicio correspondiente comprendido en la pieza de código puede comprender también almacenar en una segunda variable la dirección de memoria inicial en la que se almacena el método del objeto a redireccionar, de manera que, si durante algún momento de la ejecución de la aplicación se requiere, podrá llamarse a este método (es decir, el método original) desde la propia pieza de código.

De acuerdo con otra realización de la invención, la etapa de interceptar una llamada del proceso perteneciente a la aplicación a un servicio de una API relacionado con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware puede comprender recibir una llamada del proceso al servicio comprendido en la pieza de código correspondiente al servicio de la API relacionado con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware. Dependiendo del sentido del flujo de datos (es decir, proceso-recurso o recurso-proceso) los servicios comprendidos en la pieza de código a los que el proceso realiza llamadas pueden ser diferentes.

Preferentemente, la etapa de gestionar el flujo de datos que se produce entre el proceso y el recurso de hardware puede comprender:

* Verificar si se ha generado un recurso de hardware virtualizado que se corresponde con el recurso de hardware;

8 En caso de resultado negativo en la verificación, generar el recurso de hardware virtualizado.

Para la mayor parte de los recursos de hardware de un sistema informático, para gestionar el flujo de datos que se produce entre el proceso y el recurso de hardware, puede ser necesario generar un recurso de hardware que virtualice el recurso de hardware del sistema informático (es decir, generar un recurso de hardware virtual). Es por ello, que dependiendo del recurso de hardware de sistema informático, la pieza de código puede tener que verificar si existe o no el correspondiente recurso de hardware virtualizado. En el caso que no exista, la generación de este recurso de hardware virtualizado puede comprender:

o Generar un búfer que vsrtualiza el búfer asociado al recurso de hardware y/o

o Generar un hilo de ejecución que emula el comportamiento del recurso de hardware. generación del búfer virtualizado es debido a que gran parte de los recursos hardware de un sistema informático comprenden o tienen asociado al menos un búfer (más concretamente, cada recurso de hardware puede tener reservada al menos una zona de memoria) en el que el recurso de hardware puede almacenar datos para que ¡leguen al proceso (normalmente, el proceso realiza una petición para su obtención) o en el que el proceso puede almacenar datos para que lleguen al recurso (normalmente, el recurso está capacitado para cogerlos), es decir, el búfer sirve como herramienta de intercambio de datos entre el proceso y el recurso. Lo que se pretende con la generación del búfer virtual o virtualizado es que ía zona de memoria reservada para el intercambio de datos entre el proceso y el recurso sea una diferente que no esté bajo el control del sistema operativo y/o de los controladores asociados a los recursos reales, sino que esté bajo el control de la pieza de código. Además, de este modo, para cada recurso de hardware, cada aplicación en ejecución que tenga inyectada una pieza de código de acuerdo con la invención puede disponer de al menos un búfer propio y no de uno compartido con el resto de aplicaciones, propio del recurso de hardware.

En algunos casos, una vez los datos hayan sido almacenados en el búfer virtualizado, puede ser necesario informar al proceso que todas las acciones se han realizado correctamente. Además, puede ser necesario indicarle al proceso cuántos datos se han escrito en el búfer, ya sea porque queda espacio en el búfer o porque no ha sido posible almacenar todos los datos en el búfer y será necesaria otra o más etapas de almacenamiento de datos.

Con respecto al hilo de ejecución, puede ser necesaria su generación principalmente para que simule el comportamiento del recurso de hardware del sistema informático y, entre otras cosas, haga una gestión adecuada de los datos generados por la pieza de código, a través de la figura del recurso de hardware virtualizado, así como de los datos generados por el proceso, que se intercambian entre ellos a través del búfer virtualizado, tal como se ha comentado más arriba. Es importante destacar que el hilo de ejecución puede estar representado, por ejemplo, por al menos una función comprendida en la pieza de código, de manera que la ejecución del hilo realmente supone la ejecución de esta función. Además, la etapa de gestionar el flujo de datos que se produce entre el proceso y el recurso de hardware puede comprender también almacenar en el búfer virtualizado los datos enviados por el proceso a! recurso de hardware. De este modo, la pieza de código puede gestionar el flujo de datos que se produce entre el proceso y el recurso de hardware, puesto que los datos se almacenan en el búfer virtualizado, que está bajo el control de la pieza de código. Realmente, estos datos generados por el proceso tenían como destino el recurso de hardware del sistema informático (es decir, el recurso de hardware real), pero la interceptación de las llamadas del proceso a determinados servicios de las API por parte de la pieza de código permite que estos datos estén bajo control de la misma.

Por otro lado, la etapa de gestionar el flujo de datos que se produce entre el proceso y el recurso de hardware puede comprender:

* Parar durante un tiempo predeterminado el hilo de ejecución generado que emula el comportamiento del recurso de hardware; « Obtener los datos almacenados en el búfer virtualizado, previamente enviados por el proceso al recurso de hardware:

* Procesar los datos obtenidos,

En el caso que el recurso de hardware virtualizado disponga de un hilo de ejecución que simula el comportamiento del recurso de hardware del sistema informático, la pieza de código debe parar el hilo de ejecución durante un tiempo predeterminado (normalmente del orden de milisegundos), para que después el hilo de ejecución obtenga los datos que el proceso ha almacenado en el búfer virtualizado. Una vez obtenidos estos datos, el hilo de ejecución debe procesarlos tal como lo haría el recurso de hardware del sistema informático. Así, por ejemplo, si el recurso de hardware es una tarjeta de audio, el procesamiento de estos datos puede suponer convertirlos, por ejemplo, al formato mp3 (es decir, de acuerdo con el estándar MPEG- audio, capa III), para que después sean interpretables.

Según una realización preferida de la invención, la etapa de gestionar el flujo de datos que se produce entre el proceso y el recurso de hardware puede comprender enviar los datos procesados a un primer sistema informático remoto. Dado que los datos, después de su procesamiento, siguen estando controlados por la pieza de código a través del recurso de hardware virtualizado, estos datos pueden ser enviados a un sistema informático remoto (diferente del sistema informático que comprende el recurso de hardware real) que es el que realmente hace uso de ellos, aunque también pueden ser enviados al propio sistema informático sobre el que se ejecuta la aplicación o a cualquier otro sistema informático local. Así, siguiendo con el ejemplo de la tarjeta de audio, dado que la pieza de código tiene el control de los datos de audio, ésta es capaz de hacer que estos datos de audio, en lugar de escucharse a través de la tarjeta de audio real asociada al sistema informático, se escuchen a través de la tarjeta de audio real del sistema informático remoto (por ejemplo, un terminal o dispositivo móvil, tal como un smartphone o una tableta). Obviamente, los datos, una vez procesados por el hilo de ejecución (recordemos que no es más que al menos una función comprendida en el hilo de ejecución), si son interpretables por la tarjeta de audio del sistema informático, no debe existir ningún problema para que sean interpretables por la tarjeta de audio de cualquier otro sistema informático, puesto que ya han sido adaptados para ello. Como queda claro, hasta ahora se ha descrito un procedimiento para virtualizar un recurso de hardware asociado a un sistema informático de manera general, y también de manera más concreta a partir de, entre otras cosas, gestionar el flujo de datos que se produce desde el proceso perteneciente a la aplicación al recurso de hardware, es decir, hasta ahora se ha descrito cómo controla la pieza de código los datos que van desde el proceso al recurso. A continuación, se describe el procedimiento de la invención cuando el flujo de datos se produce entre el recurso (más concretamente el recurso de hardware virtualizado) y el proceso perteneciente a la aplicación. Así, el procedimiento puede comprender gestionar el flujo de datos que se produce desde el recurso de hardware virtualizado al proceso perteneciente a la aplicación.

Esta gestión del flujo de datos en el sentido especificado puede comprender:

B Recibir datos desde un segundo sistema informático remoto; ^■ Procesar los datos recibidos;

* Almacenar los datos procesados en el búfer virtualizado.

La pieza de código en cualquier momento puede recibir datos de un segundo sistema informático remoto (aunque normalmente el primer y el segundo sistemas informáticos remotos van a ser el mismo sistema informático remoto), los cuales deben ser procesados y almacenados en el búfer virtualizado previamente creado, para que sean accesibles por el proceso. Así, por ejemplo, en el caso que el recurso de hardware que se está virtualizando sea el teclado del sistema informático, la pieza de código (más concretamente el hilo de ejecución que simula el comportamiento del recurso de hardware) puede recibir datos de teclado desde el sistema informático remoto (por ejemplo una tableta), tal como datos generados a partir de un teclado sobre 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 el búfer.

Posteriormente, cuando el proceso requiera obtener estos datos, debe realizar llamadas a determinados servicios de una API relacionados con la gestión del flujo de datos entre el recurso de hardware (se entiende que el real, puesto que la virtualización del recurso de hardware es transparente para el proceso) y el proceso, siendo interceptadas estas llamadas por la pieza de código, de manera que ésta recupera los datos almacenados en el búfer virtualizado (no los datos almacenados en el búfer del recurso de hardware del sistema informático, es decir, del recurso de hardware real) y las hace accesibles al proceso, el cual, una vez obtenidos, puede procesarlos si es necesario.

Por lo tanto, la etapa de interceptar una llamada del proceso perteneciente a la aplicación a un servicio de una API relacionado con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware puede comprender:

B Interceptar una llamada del proceso perteneciente a la aplicación a un servicio de una API relacionado con la gestión del flujo de datos que se produce desde el recurso de hardware al proceso; mientras que la etapa de gestionar el flujo de datos que se produce desde el recurso de hardware virtualizado al proceso perteneciente a la aplicación puede comprender: * Recuperar los datos almacenados en el búfer virtualizado;

* Enviar los datos recuperados al proceso.

Tal como 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 interceptar una llamada del proceso a un servicio de una API relacionado con la gestión del flujo de datos que se produce desde el recurso de hardware al proceso puede comprender recibir una llamada del proceso al servicio comprendido en ¡a pieza de código correspondiente al servicio de la API relacionado con la gestión del flujo de datos que se produce desde el recurso de hardware al proceso.

Finalmente, el procedimiento puede comprender también gestionar el flujo de datos que se produce desde el recurso de hardware del sistema informático (es decir, el recurso de hardware real) al proceso, con el objetivo de asegurar que es el recurso virtualizado el que sigue controlando correctamente la aplicación, y no el recurso real, Para ello, la etapa de gestionar el flujo de datos que se produce entre el proceso y el recurso de hardware puede comprender:

⁸ gestionar el flujo de datos que se produce desde el recurso de hardware al proceso, que puede comprender:

o Verificar si existen datos en el búfer procedentes del recurso de hardware:

o En caso de resultado positivo en la verificación, eliminar estos datos. Puesto que la virtualización que se realiza del recurso de hardware del sistema informático es transparente para este recurso, es posible que siga mandando datos a su búfer asociado, de manera que en algún momento puede llegar a producirse el llenado del búfer y que, ante esta situación, el recurso de hardware real podría saturar estructuras internas del sistema operativo del sistema informático real, el cual podría actuar ante ello o podría dejar de funcionar correctamente. Para evitarlo, la pieza de código puede verificar, por ejemplo cada cierto tiempo, si hay datos almacenados en el búfer y, en caso positivo en la verificación, borrarlos. De acuerdo con un segundo aspecto, la invención proporciona una pieza de código ejecutable que puede comprender instrucciones para ejecutar un procedimiento para virtualizar un recurso de hardware asociado a un sistema informático tal como el descrito anteriormente, estando esta pieza de código adaptada para ser inyectada en un proceso perteneciente a una aplicación, cuando esta aplicación se ejecuta sobre un sistema operativo que comprende al menos una interfaz de programación de aplicaciones (API) y que se ejecuta sobre el sistema informático. Esta pieza de código ejecutable puede estar almacenada en unos medios de almacenamiento físico, tales como unos medios de grabación, una memoria de ordenador, o una memoria de sólo lectura, o puede ser portada por una onda portadora, tal como eléctrica u óptica. Según un tercer aspecto de la invención, se proporciona un sistema para virtualizar un recurso de hardware asociado a un sistema informático sobre el que se ejecuta un sistema operativo que comprende al menos una interfaz de programación de aplicaciones y sobre el que se ejecuta una aplicación que comprende un proceso, pudiendo comprender el sistema:

- Medios informáticos para interceptar una llamada del proceso perteneciente a la aplicación a un servicio de una interfaz de programación de aplicaciones relacionado con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware;

- Medios informáticos para gestionar el flujo de datos que se produce entre el proceso y el recurso de hardware por parte de la pieza de código, a partir de la interceptación de la llamada del proceso al servicio de la interfaz de programación de aplicaciones relacionado con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware.

Preferentemente, la invención también proporciona un sistema informático sobre el que se ejecuta un sistema operativo que puede comprender al menos una interfaz de programación de aplicaciones y sobre el que 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 el procesador correspondientes a una pieza de código ejecutable tal como la descrita anteriormente inyectada en un proceso perteneciente a la aplicación, pudiendo comprender las instrucciones funcionalidades para:

- Interceptar una llamada del proceso perteneciente a la aplicación a un servicio de una interfaz de programación de aplicaciones relacionado con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware;

- Gestionar el flujo de datos que se produce entre el proceso y el recurso de hardware por parte de la pieza de código, a partir de la interceptación de la llamada del proceso al servicio de la interfaz de programación de aplicaciones relacionado con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware.

Según una realización de la invención, sobre el sistema informático descrito pueden ejecutarse al menos dos aplicaciones sobre el sistema operativo, y la memoria puede almacenar instrucciones ejecutables por el procesador correspondientes a una pieza de código para cada aplicación en ejecución. Además, la invención puede proporcionar también una aplicación ejecutable sobre un sistema operativo que se ejecuta sobre un sistema informático, pudiendo comprender esta aplicación una pieza de código ejecutable tal como la que se ha descrito anteriormente. Según una posible realización de la invención, el recurso de hardware puede ser una tarjeta de audio, la etapa de interceptar una llamada del proceso perteneciente a la aplicación a un servicio de una interfaz de programación de aplicaciones (API) relacionado con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware puede comprender interceptar una llamada del proceso a un servicio de una AP! relacionado con la gestión del flujo de datos de audio que se produce desde el proceso a la tarjeta de audio; y la etapa de gestionar el flujo de datos que se produce entre el proceso y el recurso de hardware por parte de la pieza de código puede comprender gestionar el flujo de datos de audio que se produce desde el proceso a la tarjeta de audio. Más concretamente, la etapa de gestionar el flujo de datos de audio que se produce desde el proceso a la tarjeta de audio puede comprender verificar si se ha generado una tarjeta de audio virtualizada que se corresponde con la tarjeta de audio del sistema informático; y en caso de resultado negativo en la verificación, generar la tarjeta de audio virtualizada.

La etapa descrita de generar la tarjeta de audio virtualizada puede comprender generar al menos un búfer que virtualiza el búfer asociado a la tarjeta de audio del sistema informático, y generar un hilo de ejecución que emula el comportamiento de la tarjeta de audio del sistema informático.

Además, la etapa de gestionar el flujo de datos de audio que se produce entre el proceso y la tarjeta de audio puede comprender almacenar en el búfer virtualizado los datos de audio enviados por el proceso a la tarjeta de audio.

Por otro lado, la etapa de gestionar el flujo de datos de audio que se produce entre el proceso y la tarjeta de audio puede comprender parar durante un tiempo predeterminado el hilo de ejecución generado que emula el comportamiento de la tarjeta de audio del sistema informático; obtener los datos de audio almacenados en el búfer virtualizado, previamente enviados por el proceso a la tarjeta de audio, por parte del hilo de ejecución; y procesar los datos de audio obtenidos por parte del hilo de ejecución. Esta etapa de procesamiento por parte del hilo de ejecución de los datos de audio obtenidos del búfer virtualizado puede comprender mezclar los datos obtenidos de al menos un búfer virtualizado, y convertir los datos de audio mezclados a un formato interpretable (por ejemplo, a un formato mp3). De acuerdo con otra realización de la invención, el recurso de hardware puede ser una tarjeta de video, la etapa de interceptar una llamada del proceso perteneciente a la aplicación a un servicio de una interfaz de programación de aplicaciones (API) relacionado con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware puede comprender interceptar una llamada del proceso a un servicio de una API relacionado con la gestión del flujo de datos de video que se produce desde el proceso a la tarjeta de video; y la etapa de gestionar el flujo de datos que se produce entre el proceso y el recurso de hardware por parte de ía pieza de código puede comprender gestionar el flujo de datos de video que se produce desde el proceso a la tarjeta de video.

Más concretamente, la etapa de gestionar el flujo de datos de video que se produce desde el proceso a la tarjeta de video puede comprender verificar si se ha generado una tarjeta de video virtualizada que se corresponde con la tarjeta de video del sistema informático; y en caso de resultado negativo en la verificación, generar la tarjeta de video virtualizada.

La etapa descrita de generar la tarjeta de video virtualizada puede comprender generar un búfer que virtualiza el búfer asociado a la tarjeta de video del sistema informático, y generar un hilo de ejecución que emula el comportamiento de la tarjeta de video del sistema informático. En el caso de una tarjeta de video, este búfer recibe el nombre de Contexto de Dibujo (en inglés, Drawing Coníext (DC)), y se puede definir como una zona de memoria en la que la tarjeta de video almacena los gráficos resultantes por fotograma y siempre está asociado a una ventana.

Por otro lado, la etapa de gestionar el flujo de datos de video que se produce entre el proceso y la tarjeta de video puede comprender parar durante un tiempo predeterminado el hilo de ejecución generado que emula el comportamiento de la tarjeta de video del sistema informático; obtener los datos de video (fotogramas) almacenados en el DC virtualizado, previamente generados por la tarjeta de vídeo, por parte del hilo de ejecución; y procesar los datos de video obtenidos por parte del hilo de ejecución. Esta etapa de procesamiento por parte deí hilo de ejecución de los datos de video obtenidos del búfer virtualizado puede comprender codificar el fotograma mediante un códec, por ejemplo, H.264.

Aún según otra realización de la invención, el recurso de hardware puede ser un dispositivo de entrada de datos, tal como un teclado o un ratón. En este punto es adecuado indicar que si el sistema operativo que se ejecuta sobre el sistema informático usa un sistema de colas de mensajes, puede ser necesario virtualizar también esta cola de mensajes.

Para la virtualización de la cola de mensajes puede ser necesario generar un búfer y un hilo de ejecución que emula el sistema de cola de mensajes (es decir, enviar los mensajes a la cola de mensajes asociada a la aplicación, a partir de alguna entrada de datos, como por ejemplo una tecla pulsada) e interceptar la función de consulta y tratamiento de los mensajes (es decir, una función (también conocida como función de ventana) que define el programador para determinar el comportamiento de la aplicación ante algún mensaje determinado), la cual, como se ha comentado anteriormente, está comprendida en la pieza de código, para que haga las funciones del sistema de cola de mensajes. En este caso, la pieza de código debería interceptar la llamada del proceso a la función que consulta (substrae el mensaje de la cola para leerlo) y trata (realiza una determinada acción) los mensajes que pueden estar en la cola de mensajes que el sistema operativo ha asociado a la aplicación. De esta forma, la función de la pieza de código que trata los mensajes de la cola de mensajes puede eliminar mensajes que no se desea que la aplicación trate (es decir, se pretende que los ignore) o puede que llame a su vez a la función original para que la aplicación trate el mensaje (es decir, se pretende que actúe ante dicho mensaje).

En el caso que el recurso de hardware sea un dispositivo de entrada de datos (por ejemplo un ratón o un teclado), la etapa de interceptar una llamada del proceso perteneciente a la aplicación a un servicio de una interfaz de programación de aplicaciones (API) relacionado con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware puede comprender interceptar una llamada del proceso a un servicio de una API relacionado con la gestión del flujo de datos que se produce desde el dispositivo de entrada al proceso; y la etapa de gestionar el flujo de datos que se produce entre el proceso y el recurso de hardware por parte de la pieza de código puede comprender gestionar el flujo de datos que se produce desde el dispositivo de entrada al proceso. Más concretamente, la etapa de gestionar el flujo de datos que se produce desde el dispositivo de entrada al proceso puede comprender verificar si se ha generado un dispositivo de entrada virtualizado que se corresponde con el dispositivo de entrada del sistema informático; y en caso de resultado negativo en la verificación, generar el dispositivo de entrada virtualizado.

La etapa descrita de generar el dispositivo de entrada virtualizado puede comprender generar un búfer que virtualiza el búfer asociado al dispositivo de entrada del sistema informático, y generar un hilo de ejecución que emula el comportamiento del dispositivo de entrada del sistema informático.

Además, la etapa de gestionar el flujo de datos que se produce desde el dispositivo de entrada virtualizado al proceso perteneciente a la aplicación, puede comprender recibir datos desde un sistema informático remoto, estando estos datos generados por un dispositivo de entrada (tal como un teclado, un ratón, ya sea o no a través de una pantalla táctil) del sistema informático remoto; procesar los datos recibidos; y almacenar los datos procesados en el búfer virtualizado. Por otro lado, la etapa de gestionar el flujo de datos que se produce desde el dispositivo de hardware virtualizado al proceso perteneciente a la aplicación también puede comprender recuperar los datos almacenados en el búfer virtualizado; y enviar los datos recuperados al proceso. Finalmente, según otra realización de la invención, el recurso de hardware puede ser una unidad de almacenamiento, tal como un disco duro; la etapa de interceptar una llamada del proceso perteneciente a la aplicación a un servicio de una interfaz de programación de aplicaciones (API) relacionado con la gestión del flujo de datos que se produce entre el proceso y el recurso de hardware puede comprender interceptar una llamada del proceso a un servicio de una API relacionado con la gestión del flujo de datos que se produce desde el proceso a la unidad de almacenamiento; y la etapa de gestionar el flujo de datos que se produce entre el proceso y el recurso de hardware por parte de la pieza de código puede comprender gestionar el flujo de datos que se produce desde el proceso a la unidad de almacenamiento. Más concretamente, la etapa de gestionar el flujo de datos que se produce desde el proceso al disco duro puede comprender cambiar la ruta del directorio en la que se almacenan los datos provenientes del proceso.

Tal como se ha comentado anteriormente, la pieza de código, para una aplicación dada, tiene que ser capaz de virtualszar uno de los recursos de hardware descrito, o una pluralidad de ellos. Por este motivo, la pieza de código debe estar adaptada y debe contener las instrucciones necesarias para conseguir la virtualización de uno o varios de estos dispositivos.

A lo largo de la descripción y las reivindicaciones la palabra "comprende" y sus vanantes no pretenden excluir otras características técnicas, aditivos, componentes o pasos. Para los expertos en la materia, otros objetos, ventajas y características de la invención se desprenderán en parte de la descripción y en parte de la práctica de la invención. Los ejemplos y dibujos se proporcionan a modo de ilustración, y no se pretende que sean limitativos de la presente invención. Los signos numéricos relativos a los dibujos y colocados entre paréntesis en una reivindicación, son solamente para intentar aumentar la comprensión de la reivindicación, y no deben ser interpretados como limitantes del alcance de la protección de la reivindicación. Además, la presente invención cubre todas las posibles combinaciones de realizaciones particulares y preferidas aquí indicadas. Breve descripción de los dibujos

Para mayor comprensión de cuanto se ha expuesto se acompaña unos dibujos en los cuales, esquemáticamente y sólo a título de ejemplo no limitativo, se representan unos casos prácticos de realización.

En los dibujos,

La figura 1 es un diagrama de bloques que representa las capas de ejecución de una aplicación sobre un sistema informático, de acuerdo con el estado de la técnica; La figura 2 es un diagrama de bloques que representa las capas de ejecución de una aplicación sobre un sistema informático que incorpora además una capa que representa una pieza de código inyectada en un proceso perteneciente a la aplicación, estando esta pieza de código destinada a virtuaíizar al menos un recurso de hardware asociado al sistema informático sobre el que se ejecuta la aplicación, de acuerdo con la invención.

Descripción de una realización preferida de la invención A continuación se realizará la descripción de un procedimiento y de una pieza de código ejecutable de acuerdo con la invención para virtuaíizar un recurso de hardware asociado a un sistema informático. Sobre este sistema informático está instalado un sistema operativo que comprende al menos una interfaz de programación de aplicaciones (API). La pieza de código ejecutable descrita está adaptada para ser inyectada en un proceso perteneciente a una aplicación que está en ejecución sobre el sistema operativo descrito.

La Figura 1 muestra un diagrama que representa las capas de ejecución de una aplicación (por ejemplo, un juego) sobre un sistema informático (por ejemplo, un ordenador personal, un servidor, etc.), de acuerdo con el estado de la técnica.

En este diagrama, la capa 10 de más bajo nivel representa los recursos de hardware 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 video, la tarjeta de audio, y los discos duros, entre otros.

En una segunda capa 1 1 dispuesta en un nivel superior se encuentra el sistema operativo, que cuenta con los controladores necesarios para comunicarse e interactuar de manera bidireccional (puede mandar y/o recibir información de estos recursos, tal como señales de control 14 o datos 15) con los recursos de la capa inferior 10.

En una tercera capa 12 dispuesta por encima de la capa 1 1 representativa del sistema operativo se encuentran las interfaces de programación de aplicaciones (más conocidas como API), tanto las que vienen 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. Normalmente, estas AP! están implementadas dentro de librerías de enlace dinámico, sea cual sea el sistema operativo utilizado. La comunicación entre la capa 12 que comprende las API y la capa 1 1 representativa del sistema operativo es también bidireccional, pudiendo intercambiar tanto señales de control 14 como datos 15.

Finalmente, en la Figura 1 se muestra también una cuarta capa o capa de nivel superior 13 que representa la aplicación en ejecución. Esta aplicación, durante su ejecución, accede a la capa 12 representativa de las API, intercambiando tanto señales de control como datos.

De este modo, de acuerdo con esta configuración, si, por ejemplo, la aplicación en ejecución 13 requiere de la generación de una ventana en la pantalla de visualszación del sistema informático sobre el que se está ejecutando, la aplicación debe acceder a determinados servicios de las API 12 (ya sean funciones o métodos) destinados a la generación de ventanas. Estos servicios, para poder generar la ventana en la pantalla, necesitan intercambiar información (señales de control y datos) con el sistema operativo 1 1 , el cual dispone de las herramientas necesarias (es decir, controladores) para comunicarse con la pantalla 10 y provocar, así, la generación de la ventana deseada.

El principal inconveniente de esta configuración es que cada recurso de hardware del sistema informático sólo es usable por una única aplicación que es la que el usuario tiene (o el sistema operativo tiene seleccionada como) activa en primer plano (es decir, la ventana activa), es decir, si el recurso de hardware es la tarjeta de audio, únicamente la aplicación que el usuario tiene activa en primer plano, de entre todas las aplicaciones que estén ejecutándose en ese momento, será capaz de usar ese recurso y, por lo tanto, será la única capaz de mandar datos de audio a la tarjeta de audio para que los reproduzca.

También puede darse una situación en la que el recurso de hardware es capaz de recibir datos de diferentes aplicaciones en ejecución, pero en ese caso se va a producir una mezcla de los datos. Así, siguiendo con el ejemplo de la tarjeta de audio, si este recurso puede recibir datos de audio de más de una de las aplicaciones en ejecución, la tarjeta de audio reproduce una mezcla de los diferentes datos de audio que recibe.

Para solucionar estos inconvenientes, la invención proporciona una pieza de código ejecutable que debe inyectarse en cada aplicación en el momento de iniciar su ejecución (por ejemplo, iniciándose el proceso perteneciente a la aplicación en un estado suspendido), que es capaz de ejecutar un procedimiento para virtualizar uno o más recursos de hardware asociados a un sistema informático sobre el que se ejecuta la aplicación. Así, el objetivo principal de esta pieza de código es virtualizar los recursos de hardware que la aplicación requiere del sistema informático para su ejecución, de manera que es capaz de generar recursos de hardware virtualizados usables únicamente por la aplicación en cuyo proceso ha sido inyectada y gestionar el flujo de datos entre el proceso perteneciente a la aplicación y el recurso de hardware. De este modo, cada aplicación en ejecución dispone de sus propios dispositivos de hardware virtualizados, así como de una herramienta (la pieza de código) que es capaz de gestionar los flujos de datos que se generan entre ellos y el proceso.

La Figura 2 muestra un diagrama basado en el de la Figura 1 pero que además comprende una capa 16 que representa la pieza de código ejecutable que, después de ser inyectada en el proceso asociado a la aplicación, se dispone a nivel lógico entre la capa 13 de la aplicación y la capa 12 representativa de las

API, de manera que la pieza de código puede interceptar las llamadas de la aplicación a determinados servicios (por ejemplo, funciones o métodos) de las API y virtualizar así los recursos de hardware 10'. Como se puede ver en la Figura 2, la función principal de la capa 16 que representa la pieza de código es interceptar las diferentes llamadas que el proceso perteneciente a la aplicación realiza a servicios de las API relacionados con el flujo de datos generado entre el proceso y los recursos de hardware del sistema informático, y, a partir de la interceptación de estas llamadas, gestionar el flujo de datos que se produce entre el proceso y los recursos de hardware del sistema informático, así como entre el proceso y los recursos de hardware virtualizados 10' descritos anteriormente.

Más concretamente, el procedimiento que ejecuta la pieza de código es el siguiente. Para su descripción, se parte de una situación inicial en la que, cuando un usuario ejecuta una aplicación, el proceso perteneciente a la aplicación se inicia en un estado suspendido. Durante este estado de suspensión, la pieza de código ejecutable se inyecta en el proceso. Una vez inyectada la pieza de código en el proceso, esta pieza de código carga en memoria todas aquellas librerías de enlace dinámico que contienen las interfaces de programación de aplicaciones (API) que contienen servicios (ya sea funciones o métodos) relacionados con la gestión del flujo de datos entre el proceso y los diferentes recursos de hardware del sistema informático y que van a ser requeridos por la aplicación durante su ejecución. A continuación, después que el sistema operativo haya rellenado la tabla de punteros a los servicios de las diferentes API cargadas en memoria de acuerdo con las direcciones de memoria iniciales en las que se han almacenado estos servicios, sustituye en esta tabla de punteros la dirección de memoria inicial de cada uno de los servicios que pueden o van a ser requeridos por la aplicación durante su ejecución por la dirección de memoria inicial en la que se encuentra cada uno de los servicios correspondientes comprendidos en la pieza de código. De este modo, a partir de esta redirección realizada, la pieza de código es capaz de interceptar las llamadas que el proceso realiza a estos servicios relevantes para su ejecución, es decir, las llamadas que el proceso realiza a los diferentes servicios relevantes de las diferentes API son recibidas por la pieza de código, puesto que los punteros no apuntan a los servicios de las API sino a los servicios correspondientes comprendidos en la pieza de código. A partir de la interceptación comentada, ¡a pieza de código adquiere la capacidad de gestionar el flujo de datos que se produce entre el proceso y el recurso de hardware del sistema informático, es decir, la pieza de código toma el control, de forma transparente para el proceso, del flujo de datos que se produce entre el proceso y el recurso de hardware del sistema informático. Más concretamente, cuando el proceso pretende acceder a un recurso de hardware del sistema informático mediante llamadas a determinados servicios de las API, la pieza de código ejecuta sus propios servicios (es decir, realiza una interceptación de estas llamadas). A partir de esta interceptación, para tomar el control del flujo de datos es necesario generar un recurso de hardware virtualizado 10' que se corresponde con el recurso de hardware del sistema informático al que pretende acceder el proceso, si es que no había sido generado anteriormente. La generación del recurso de hardware virtualizado 10' puede suponer varias acciones.

Una primera acción puede ser la de generar al menos un búfer que virtualice el al menos un búfer asociado al recurso de hardware del sistema informático, es decir, la pieza de código reserva una zona de memoria específica, que representa el búfer virtualizado, en la que el proceso debe almacenar los datos que, en un principio, está mandando al recurso de hardware del sistema informático, pero que han sido interceptados por la pieza de código. Una segunda acción a realizar puede ser la de generar un hilo de ejecución que emule el comportamiento del recurso de hardware del sistema informático. Básicamente, este hilo de ejecución puede ser una función comprendida en la propia pieza de código. Una vez generado el recurso de hardware virtualizado 10' (si es que no existía), la pieza de código almacena los datos enviados por el proceso en el búfer virtualizado, y genera el hilo de ejecución descrito anteriormente (si es que es necesario). La pieza de código para el hilo de ejecución (que es una función comprendida en la misma pieza de código y, por lo tanto, sobre la que tiene control) durante un tiempo predeterminado (aproximadamente durante unos milisegundos), para que posteriormente lea los datos almacenados en el búfer virtualizado (recordar que provienen del proceso) y los procese. Una vez procesados los datos, la pieza de código tiene la capacidad de enviarlos a un primer sistema informático remoto, aunque esta realización será descrita posteriormente. Es importante destacar que normalmente será necesario que la pieza de código comunique al proceso que los datos han sido recibidos correctamente, tal como sucedería si el recurso de hardware no fuera el virtualizado sino el propio del sistema informático.

Por otro lado, también es posible que el hilo de ejecución generado reciba datos provenientes de un segundo sistema informático remoto (aunque normalmente el primer y el segundo sistemas informáticos remotos serán el mismo sistema informático remoto). Ante esta situación, el hilo de ejecución procesa los datos recibidos y los almacena, después de su procesamiento, en el búfer virtualizado que forma parte del recurso de hardware virtualizado 10'.

En algún momento durante la ejecución de la aplicación, el proceso llama a un determinado servicio de una API para verificar si el recurso de hardware del sistema informático ha generado datos para la aplicación. Puesto que todos los servicios de las API relacionados con la gestión del flujo de datos entre el proceso y los recursos de hardware del sistema han sido redireccionados, la llamada la recibe la pieza de código (más concretamente un servicio comprendido en la pieza de código) y la procesa. Para ello, la pieza de código recupera los datos contenidos en el búfer virtualizado (recordar que los datos correspondientes a los datos contenidos en el búfer virtualizado (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 informático remoto) y se los envía al proceso, para que los utilice.

Normalmente, dado que el recurso de hardware del sistema informático puede generar datos para la aplicación (recordar que la pieza de código interviene sólo a nivel de flujo de datos y no de señales de control), la pieza de código debe cada cierto tiempo verificar si existen datos en el búfer del recurso de hardware y, en caso positivo, borrarlos. De este modo, se evitan problemas durante la ejecución de la aplicación.

A continuación se describirá una realización preferida 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 concretamente de juegos; las aplicaciones a ejecutar son juegos y/o diferentes instancias de un mismo juego; y el recurso de hardware sobre el que un juego en ejecución hace una petición de acceso es ¡a tarjeta de audio del servidor de juegos. Posteriormente se describe una realización de la invención en la que el recurso de hardware es una tarjeta de video, una realización de la invención en la que el recurso de hardware 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 hardware es un disco duro,

Más concretamente, la presente realización presenta el siguiente funcionamiento. El servidor de juegos tiene como objetivo permitir a los usuarios del servicio jugar a diferentes juegos o incluso al mismo juego (por ejemplo, juegos de ordenador (PC) o de consolas) desde sus terminales móviles o sistemas informáticos remotos, tales como smartphones o tabletas. La ejecución de cada juego o de cada instancia del mismo juego puede ser enviada mediante técnicas de streaming desde el servidor de juegos a los dispositivos móviles de los usuarios, De este modo, un usuario, desde su dispositivo móvil, puede seleccionar el juego al que desea jugar, solicitando su ejecución mediante la actuación sobre un elemento de control (por ejemplo, un icono representativo del juego) presente en una interfaz gráfica de usuario mostrada en la pantalla de su terminal móvil. Esta actuación del usuario sobre el elemento de control genera una señal de control hacia el servidor de juegos que provoca la ejecución del juego seleccionado, sobre el servidor.

Dado que el número de usuarios que soliciten la ejecución de un juego puede ser elevado (es decir, puede haber un número elevado de juegos en ejecución), la presente invención pretende que cada juego, a partir de la pieza de código que tiene inyectada, pueda virtualizar los recursos de hardware del servidor de juegos que requiera para su ejecución y así disponer de ellos en exclusiva.

Cuando un usuario solicita la ejecución de un juego desde su terminal móvil, en el servidor de juegos se crea el proceso principal de la aplicación en ejecución (es decir, el juego), en estado suspendido. Para ello se utiliza la función CreateProcess, asignando al parámetro de modo de creación (CreateFlags) el valor CREATE_SUSPENDED. Una vez el proceso se ha Iniciado en estado suspendido, se realiza la inyección en el proceso de la pieza de código ejecutable de acuerdo con la invención, que tiene como objetivo virtualizar los recursos de hardware del servidor de juegos.

En este punto es importante destacar que la expresión "virtualizar un recurso de hardware" no supone únicamente generar un recurso de hardware virtualizado que se corresponde con el recurso de hardware del sistema informático, sino que también comprende toda la gestión del flujo de datos que se genera a posterior!.

Antes de reanudar la ejecución del proceso (hay que recordar que el proceso se inicia en estado suspendido), la pieza de código inyectada redirecciona las funciones de las AP! relacionadas con la gestión del flujo de datos que se produce entre la aplicación (o más concretamente el proceso perteneciente a la aplicación) y los diferentes recursos de hardware del servidor de juegos (en la presente realización, como mínimo se cargarían aquellas funciones destinadas a gestionar el flujo de datos entre la aplicación y la tarjeta de audio). Así, por ejemplo, en la presente realización las funciones interesantes podrían ser lAudioClient o lAudioRenderClient.

Dado que en la presente realización el sistema operativo que se ejecuta sobre el servidor de juegos es uno de la familia Windows (más concretamente, Windows 7), estas API descritas normalmente están implementadas dentro de librerías de enlace dinámico (DLL), Por esta razón, la pieza de código carga, mediante la función LoadLibrary, la librería o librerías que contienen las funciones interesantes, por ejemplo, GeiBuffer y ReíeaseBuffer de la API ÍAudioRenderCiient, a través de la librería dxgi.dü. Básicamente, LoadLibrary carga la librería en memoria y el sistema operativo rellena la Index Address Table (!AT), que es una tabla de punteros a las funciones de la API, con las direcciones iniciales en memoria de las funciones de la AP!. Mediante la función RedirecflAT, la pieza de código modifica los punteros necesarios haciendo que éstos correspondan a las funciones comprendidas en la pieza de código inyectada en el proceso. A la vez, el contenido original de la tabla, es decir, el valor inicial de los punteros antes de la modificación, se guarda en una variable por si la pieza de código tiene que llamar en algún momento a alguna de las funciones originales redireccionadas.

En el momento que acaba la intercepción, es decir, todas las funciones de todas las AP! necesarias han sido redirigidas, la pieza de código reanuda la ejecución del proceso que se ha iniciado en estado suspendido.

Por otro lado, cuando el proceso pide la creación de una interfaz de tipo ¡AudioRenderClient (se trata de una interfaz de tipo COM) mediante el método GetService de la interfaz ¡AudioCüent, la pieza de código verifica si esta interfaz ya ha sido modificada (es decir, redireccionada) o no por la pieza de código. En caso de resultado negativo en la verificación, es necesario modificar la tabla de punteros de la interfaz para sustituir los métodos que se desean interceptar, como por ejemplo GetBuffer y ReleaseBuffer de ¡AudioRenderClient. La tabla de punteros a métodos de una interfaz de tipo COM se modifica con código específico. Por ejemplo, GetBuffer corresponde a la posición 4 de la tabla de métodos de la interfaz ¡AudioRenderClient y se tiene que modificar para que apunte a la función comprendida en la pieza de código inyectada. A la vez, el contenido original de esta posición se guarda en una variable por si se tiene que llamar al método original. Como ya se ha comentado, la modificación de la tabla de punteros de una interfaz de tipo COM únicamente se tiene que realizar la primera vez que se crea un objeto de ese tipo. Una vez que la interfaz ¡AudioRenderClient ha sido creada e interceptada por la pieza de código inyectada en el juego que pretende acceder a la tarjeta de audio, la pieza de código devuelve el objeto ¡AudioRenderClient correspondiente al proceso. Cuando el proceso perteneciente a la aplicación llama al método GetBuffer de

¡AudioRenderClient para pedir un búfer en el que escribir los datos de audio para la tarjeta de audio (más concretamente, pide la dirección de la zona de memoria en la que tiene que escribir los datos de audio), la pieza de código intercepta esta llamada (hay que recordar que el método GetBuffer está redireccionado a un método correspondiente comprendido en la pieza de código, por lo que el proceso realmente llama al método correspondiente comprendido en la pieza de código). El método correspondiente comprendido en la pieza de código llama al método original de la API (aunque la pieza de código podría comprender la totalidad del método) y genera un búfer que virtualiza el búfer asociado a la tarjeta de audio, es decir, el método le pasa al proceso una dirección de una zona de memoria en la que se desea que la aplicación escriba los datos de audio. De este modo, el proceso no almacena los datos de audio en el búfer de la tarjeta de audio del servidor de juegos sino en el búfer virtualizado que se corresponde con el búfer de la tarjeta real.

Una vez la aplicación escribe la totalidad de los datos de audio en el búfer virtualizado, realiza una llamada a la función ReleaseBuffer para indicar que ha acabado de escribir los datos de audio y cuánto ha escrito. Esta llamada nuevamente es interceptada por la pieza de código, de manera que es posible conocer cuándo se ha escrito la totalidad de los datos de audio en el búfer virtualizado y cuántos datos de audio se han escrito.

Además, por temas de control de la aplicación por parte de la tarjeta de audio, la pieza de código envía un búfer del mismo tamaño a la tarjeta de audio, que únicamente comprende silencio. De este modo, la pieza de código se asegura que la tarjeta de audio sigue controlando correctamente la aplicación.

Paralelamente a lo descrito, la pieza de código genera un hilo de ejecución que simula el comportamiento de la tarjeta de audio del servidor de juegos. Es importante indicar que este hilo de ejecución no es más que una función comprendida en la misma pieza de código. La pieza de código para la ejecución del hilo durante aproximadamente unos milisegundos, ya sea de manera síncrona o asincrona. Después del paro, el hilo de ejecución lee los datos de audio almacenados en el búfer virtualizado procedentes del proceso, los procesa y los manda a! termina! móvil para su reproducción.

E! procesamiento de los datos de audio puede comprender mezclar diferentes datos de audio (por ejemplo, la música que se oye de fondo durante la ejecución del juego y el audio que se oye por la intervención de! usuario sobre el juego (por ejemplo, disparos, motores de coche, espadas, etc.)) y convertirlos a un formato de audio adecuado como puede ser mp3 (se refiere al Estándar MPEG-1 Audio, capa III). Una vez los datos de audio tienen el formato correcto, la pieza de código los manda al terminal móvil a través de cualquier red de comunicaciones (por ejemplo, Internet) para que sean reproducidos mientras el usuario disfruta del juego.

En la presente realización preferida se ha descrito una petición de acceso por parte de un juego a la tarjeta de audio. Realmente, sobre el servidor de juegos se pueden estar ejecutando una pluralidad de juegos y/o una pluralidad de instancias de un mismo juego, por lo que cada uno de ellos deberá comprender una pieza de código inyectada para ejecutar el procedimiento descrito.

En el caso que el recurso de hardware a virtualizar por parte del juego sea la tarjeta de video del servidor de juegos, y partiendo de una situación en la que el juego en cuestión presenta su proceso principal iniciado en un estado suspendido y en la que la pieza de código ha sido inyectada en el proceso, el procedimiento para virtualizar la tarjeta de video es el siguiente.

Igual que para el resto de recursos de hardware, antes de reanudar la ejecución del proceso, la pieza de código inyectada redirecciona las funciones de las API necesarias, en este caso, por ejemplo, la función ShowWindow o CreateDevice de la API DirectX. Nuevamente, el objetivo principal de este procedimiento es que la pieza de código tome, de forma transparente, la gestión del flujo de datos que se produce entre la tarjeta de video y el proceso perteneciente a la aplicación.

Tal como se ha comentado anteriormente, estas API están implementadas dentro de librerías de enlace dinámico (en la presente realización en la que el sistema operativo es uno de la familia Windows, están librerías son DLL). Por lo tanto, la pieza de código carga, mediante la función LoadLibrary, la librería o librerías que comprenden las funciones a redireccionar, por ejemplo la función ShowWindow a través de la librería user32.dll. Una vez cargada, y después que el sistema operativo haya rellenado la Índex Address Table (IAT) con punteros a las funciones de la API a partir de las direcciones de memoria iniciales en las que están almacenadas estas funciones, la pieza de código, mediante la función RedsrectAÍT, modifica los punteros de aquellas funciones que pueden ser interesantes para vírtualizar la tarjeta de video. Para ello, sustituye las direcciones de memoria iniciales en las que se almacenan estas funciones de la API con las direcciones de memoria iniciales en las que se almacenan las funciones correspondientes comprendidas en la pieza de código. Alternativamente, la IAT también podría modificarse con código específico si fuera necesario.

Por otro lado, para redsreccionar los servicios de las snterfaces de tipo COM como IDÍrect3DDevíce9 es necesario modificar la tabla de punteros de la interfaz para sustituir los métodos relevantes. La tabla de punteros a métodos de una interfaz de tipo COM se modifica con código específico. Así, por ejemplo, Present corresponde a la posición 18 de la tabla de métodos de la interfaz IDirect3DDevice9 y se tiene que modificar para que apunte a la función correspondiente comprendida en la pieza de código. A la vez, el contenido original de esta posición se guarda en una variable por si se tiene que llamar al método original desde la pieza de código. La modificación de la tabla de punteros de una interfaz de tipo COM solamente se tiene que modificar la primera vez que se crea un objeto de ese tipo. En el momento que la intercepción acaba, es decir, todas las funciones de todas las API necesarias para realizar la virtualización de recursos han sido redirigidas, la pieza de código se encarga de reanudar la ejecución del proceso de la aplicación.

Cuando el proceso pide mostrar una ventana donde se van a dibujar los gráficos o pide crear una interfaz del tipo !Direct3DDevice9 mediante la función

CreateDevice de la API DirectX, se interceptan estas llamadas para capturar o vírtualizar el Drawing Context (DC) (en este caso se puede hacer con el DC original o se puede proporcionar un DC virtualizado). El DC puede definirse como una zona de memoria en la que la tarjeta de video va a almacenar los gráficos resultantes por fotograma y siempre está asociado con una ventana en

Windows. Así, para la virtualización de la tarjeta de video del servidor de juegos lo que se tiene que hacer es acceder a esta zona mediante la función getDC. El acceso a este DC es en exclusión mutua, es decir, si la tarjeta de video está accediendo a esta zona de memoria, ningún hilo de ejecución de ningún proceso puede acceder a ella. Una vez la aplicación ha creado la interfaz ÍDirect3DDevice9 o, por lo menos, ha mostrado la ventana donde se van a mostrar los gráficos, empieza a enviar los datos necesarios a la tarjeta de video para que se empiece todo el procesado de esta información y se cree el fotograma resultante. Esto es independiente de la pieza de código.

Cada cierto tiempo, el hilo de virtualización de video captura el contenido del DC. Esto lo puede hacer de forma síncrona o asincrona con la aplicación.

De forma síncrona significa que cuando el proceso realiza una petición de acceso a la tarjeta de video invocando el método Present de la interfaz iDirect3DDevice9 para que muestre el fotograma generado, la pieza de código intercepta este método Present. En ese momento, el hilo de ejecución accede al DC (en este caso se llama BackBuffer), para capturar el fotograma generado. Posteriormente, si es necesario, la pieza de código llama al método Present original de la interfaz. Este procedimiento es sincronizado porque existe un punto, cuando se llama al método Present, en el que la pieza de código sabe perfectamente que el trabajo a realizar para dibujar el fotograma se ha terminado.

La forma asincrona consiste en acceder directamente al DC de la ventana (donde la tarjeta de video deja el resultado de generar el fotograma) para acceder a su contenido. Hay que tener en cuenta que el acceso a este DC se tiene que realizar en exclusión mutua. Para ello, el hilo de ejecución intenta ganar el acceso, mediante encuesta, a esta zona de exclusión mutua. Cuando lo consigue, accede al contenido del DC para capturar el resultado del fotograma generado. Este método es asincrono puesto que la velocidad de captura y el de generación de fotogramas no tienen por qué ser iguales.

En cualquiera de los dos métodos, en el momento que se ha capturado el contenido del DC, es decir, el fotograma, empieza el procesamiento de esta información, que puede basarse en su codificación mediante un códec adecuado, como por ejemplo H.264 y enviar esta codificación por Internet. En e! caso que el recurso de hardware sea un elemento de entrada de datos, tal como un ratón o un teclado, el procedimiento específico es el siguiente. A diferencia de lo descrito hasta ahora, este procedimiento gestiona un flujo de datos que va desde el elemento de entrada de datos al proceso perteneciente a la aplicación, es decir, el procedimiento pretende hacer llegar las órdenes del usuario que está disfrutando del juego (por ejemplo, a través de la pantalla táctil o del teclado del terminal móvil), al juego que se está ejecutando sobre el servidor de juegos, para su evolución.

De este modo, partiendo de una situación en la que ya se ha inyectado la pieza de código en el proceso (es decir, en el juego), la pieza de código ha redirigido los servicios oportunos y ha generado el recurso de hardware virtualizado (es decir, ha generado un búfer que virtualiza el búfer del elemento de entrada de datos, así como un hilo de ejecución que emula el comportamiento del elemento de entrada de datos), la pieza de código (más concretamente, el hilo de ejecución que simula el comportamiento del elemento de entrada) recibe datos desde el terminal móvil del usuario, los cuales tienen que ser mandados al proceso para que modifique, por ejemplo, los datos referentes al audio y al video, que posteriormente mandará al terminal móvil. Para ello, la pieza de código, dependiendo del elemento de entrada del que recibe los datos, almacena estos datos recibidos en el búfer virtualizado correspondiente (ya sea el correspondiente al del teclado virtualizado o al del ratón virtualizado).

Cuando el proceso realiza una llamada al servicio correspondiente para obtener los datos del elemento de entrada (del teclado o del ratón reales, es decir, de los asociados al servidor de juegos), la pieza de código intercepta esta llamada y provoca la ejecución del servicio correspondiente comprendido en la pieza de código, de manera que este servicio lee los datos almacenados en el búfer virtualizado y no en el búfer del elemento de entrada real.

Teniendo en cuenta que el sistema operativo de la presente realización preferida es uno de la familia Windows, es necesario tener en cuenta los Mensajes de Windows. En este caso, el hilo de ejecución que emula la cola de mensajes recibe las entradas de datos (por ejemplo teclado o ratón) desde el sistema remoto (es decir, el terminal móvil) a través de la red (por ejemplo Internet). Estos datos pueden ser órdenes y/o eventos que envía el usuario desde el terminal móvil. De esta forma, por cada entrada de datos el hilo de ejecución introduce un mensaje en la cola de mensajes (mediante las funciones SendMessage y PostMessage de la librería user32.dll) asociada a la ventana de la aplicación. Esta cola de mensajes es la que consulta la aplicación de forma automática mediante el mecanismo de sistema de cola de mensajes que ofrece el sistema operativo. Además, para completar la virtualización de la cola de mensajes, puede ser necesario tener que cambiar la función de consulta y tratamiento de la cola de mensajes (mediante la función SetWindowLongPtr de la librería user32.dl¡) para que, en lugar de ejecutar la función original de tratamiento de mensajes de la cola de mensajes (también conocida como procedimiento o función de ventana, que es una función que define el programador para determinar el comportamiento de la aplicación ante algún mensaje determinado) sea una función de la pieza de código la que se ejecute. Es decir, se intercepta el procedimiento o función de ventana de la ventana correspondiente a la aplicación. Así pues, dicha función de la pieza de código puede: eliminar aquellos mensajes que no se desea que la función original de la ventana de la aplicación trate (es decir, no llevar a cabo ninguna actuación ante el mensaje) y así conseguir que la aplicación ignore dichos mensajes ya que la función original no llega a tratarlos; o bien, desde la función de la pieza de código, llamar a la función original de tratamiento de los mensajes, ya que se desea que la aplicación reaccione ante estos mensajes tanto porque son mensajes que ha introducido el hilo de ejecución de la pieza de código que emula el recurso de hardware virtualizado que introduce datos (teclado o ratón) a partir de órdenes enviadas por el terminal móvil, como porque son mensajes que no alteran el comportamiento de la aplicación desde la percepción del usuario del terminal móvil (la ventana se ha movido en la pantalla del sistema informático real, pero esta posición es totalmente irrelevante para el usuario del sistema remoto).

Finalmente, en el caso que el recurso de hardware sobre el que el proceso hace la petición de acceso sea una unidad de almacenamiento, tal como un disco duro, el procedimiento es el siguiente. En este caso, se supone que la pieza de código ya ha sido inyectada en el proceso. Antes de reanudar la ejecución del proceso (recordar que en la presente realización preferida el proceso se inicia en estado de suspensión), la pieza de código inyectada redirecciona todas las funciones requeridas de las API, por ejemplo CreateFile y CreateDirectory. El objetivo principal es que la pieza de código tome el control del flujo de datos entre el proceso y el disco duro.

Puesto que, tal como se ha comentado para el resto de recursos de hardware, estas API están implementadas en librerías de enlace dinámico, la pieza de código debe cargarlas en memoria mediante la función LoadLibrary, Por lo tanto, LoadLibrary carga la librería que contiene las funciones a redireccionar, por ejemplo CreateFile y CreateDirectory de la librería kernel32.dll. A continuación, el sistema operativo rellena la !AT con la dirección de memoria inicial en la que se almacena cada una de las funciones de la API. Mediante la función RedirectlAT se modifican los punteros necesarios haciendo que estos apunten a las funciones correspondientes comprendidas en la pieza de código. En el momento que la pieza de código finaliza el redireccionamiento de las funciones relevantes para la gestión del flujo de datos entre el proceso y el disco duro, la propia pieza de código se encarga de reanudar la ejecución del proceso perteneciente a la aplicación que se había iniciado en estado de suspensión.

Cuando el proceso quiere crear y/o abrir un fichero mediante la función CreateFile, la pieza de código intercepta esta petición y ejecuta la función correspondiente comprendida en la pieza de código. A partir de la interceptación, esta función verifica si el fichero que el proceso desea abrir es un fichero de la partida del juego o es cualquier otro fichero. En el caso que sea un fichero de la partida, la función modifica, si es necesario, la ruta al fichero que se quiere crear y/o abrir mediante cualquier clase de algoritmo. Una vez se ha modificado la ruta, se ejecuta la función CreateFile original con la nueva ruta creada, aunque también podría ejecutarse una función correspondiente comprendida en la pieza de código. El procedimiento para crear un directorio mediante la función CreateDirectory es equivalente al descrito para CreateFile,

Claramente, en la presente realización preferida se ha descrito la virtualización de cada recurso de hardware por separado. En el caso que una misma pieza de código sea capaz de virtualizar varios recursos de hardware, las primeras etapas del procedimiento, por ejemplo la de cargar en memoria las diferentes librerías de enlace dinámico o la de sustituir los punteros a los servicios, pueden ser comunes, es decir, pueden cargarse en memoria en el mismo momento todas las librerías de enlace dinámico que comprenden AP! con servicios relevantes para todos los recursos de hardware que la pieza de código es capaz de virtualizar, así como sustituir los punteros de todos los servicios que deben redireccionarse para que la pieza de código pueda virtualizar todos los recursos de hardware que es capaz de virtualizar,

A pesar de que se ha descrito y representado una realización concreta de la presente invención, es evidente que el experto en la materia podrá introducir vanantes y modificaciones, o sustituir los detalles por otros técnicamente equivalentes, sin apartarse del ámbito de protección definido por las reivindicaciones adjuntas.

A pesar también de que las realizaciones descritas de la invención con referencia a los dibujos comprenden sistemas de computación y procesos realizados en sistemas de computación, la invención también se extiende a programas de ordenador, más particularmente a programas de ordenador en o sobre unos medios portadores, adaptados para poner la invención en práctica. El programa de ordenador puede estar en forma de código fuente, de código objeto o en un código intermedio entre código fuente y código objeto, tal como en forma parcialmente compilada, o en cualquier otra forma adecuada para usar en la implementación de los procesos de acuerdo con la invención. El medio portador puede ser cualquier entidad o dispositivo capaz de portar el programa.

Por ejemplo, el medio portador puede comprender un medio de almacenamiento, tal como una ROM, por ejemplo un CD ROM o una ROM semiconductora, o un medio de grabación magnético, por ejemplo un floppy disc 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 transmitirse vía cable eléctrico u óptico o mediante radio u otros medios. Cuando e! programa de ordenador está contenido en una señal que puede transmitirse directamente mediante un cable u otro dispositivo o medio, el medio portador puede estar constituido por dicho cable u otro dispositivo o medio.

Alternativamente, el medio portador puede ser un circuito integrado en el que está encapsulado (emhedded) el programa de ordenador, estando adaptado dicho circuito integrado para realizar, o para usarse en la realización de, los procesos relevantes.