SISTEMAS Y MÉTODOS PARA ADMINISTRAR DRIVERS EN UN SISTEMA INFORMÁTICO
Campo de la Invención La presente invención se refiere a sistemas y métodos para administrar drivers en un sistema informático. Antecedentes de la invención En el contexto del diseño de sistemas informáticos, los drivers son componentes de software que exponen las capacida-des del hardware al sistema operativo, de manera que el sistema operativo exponga a su vez dichas capacidades a las aplicaciones. El sistema operativo interactua típicamente con un driver mediante una Interface de Driver de Dispositivo ("DDI", un protocolo definido con esmero que permite al sis-tema operativo cargar el driver, averiguar las capacidades que proporciona el hardware, y poner dichas capacidades a disposición de las aplicaciones. Las interfaces de software proporcionadas a las aplicaciones por el sistema operativo se conocen como Interfaces de Programas de Aplicación ("APls") . Las APIs proporcionadas por el sistema operativo proporcionan a las aplicaciones abstracciones de software que pueden asemejarse estrechamente o no a las características del hardware subyacente. Un ejemplo de un alejamiento drástico del hardware subyacente es la abstrae-ción de software de directorio/archivo proporcionada para almacenamiento masivo. Otra abstracción de software que no se asemeja al hardware subyacente es la memoria virtual, que permite a las aplicaciones usar de forma transparente almace-namiento en disco duro local como si fuese una memoria de acceso aleatorio. Cuando las APIs hacen que los recursos de hardware sean utilizados, el sistema operativo llama al driver mediante la DDI para hacer uso de tales recursos. Debido a las diférencias entre las abstracciones de software proporcionadas por las APIs y el hardware subyacente, esta traducción de llamadas APIs a llamadas DDI puede comportar cantidades considerables de lógica y código. En el contexto de esta memoria descriptiva, el software entre la API de nivel de aplicación y la DDI de nivel de driver se denomina en conjunto "tiempo de ej ecución" . La aplicación, los drivers, etc, se escriben en general en un lenguaje de alto nivel tal como C. Tales lenguajes se han implementado típicamente primariamente mediante compila-ción a código nativo. En tales casos, los drivers se escriben por separado de la aplicación y otros programas que operan en un sistema. La aplicación y los drivers se enlazan después típicamente durante el proceso de instalación o dinámicamente (por ejemplo, DLL) cuando se ejecuta la aplicación. La venta-ja de tal sistema es que el compilador se pueda diseñar para optimizar el código para una clase particular de procesador (por ejemplo, X86) . Sin embargo, el compilador puede no optimizar el código para un microprocesador particular, por ejem-pío, PENTIUM IV frente a PENTIUM III. Además, el compilador no optimiza el código para otros parámetros del sistema incluyendo las versiones de driver y otros componentes de hardware o tiene en cuenta las limitaciones del sistema particular del sistema destino. En cambio, la aplicación o sistema de nivel de tiempo de ejecución debe emplear lógica computa-cionalmente cara para determinar tales parámetros y las restricciones del procesador de manera que el programa se pueda compilar para ejecución en una clase completa de sistemas informáticos . Otro paradigma de programación común es compilar código en tiempo de ejecución. Un compilador justo a tiempo (JIT) es un ejemplo de tal sistema. Otros sistemas que compilan en tiempo de ejecución incluyen sistemas de compilación continua que inician inmediatamente la ejecución en un estado inter-pretativo, pero compilan el código en el tiempo y optimizan continuamente la compilación. Con compiladores justo a tiempo, cuando se cargan clases en la máquina virtual, los indicadores de método en la tabla de método virtual son sustituidos por indicadores al compilador JIT. Entonces, la primera vez que se reclama cada método, se invoca el compilador JIT para compilar el método. El indicador en la tabla de método virtual se parchea después para indicar la versión de código nativo del método de manera que las futuras llamadas al méto-do salten al código nativo. Estos sistemas de compilador JIT tienen la ventaja de transmitir código a la máquina destino en un lenguaje intermedio (IL) tal como códigos de byte JAVA, instrucciones CLRT, etc. El compilador está diseñado para convertir el IL en instrucciones ejecutables por el procésador nativo. Como resultado, las mismas instrucciones IL pueden ser enviadas a ordenadores que tienen diferentes procesadores nativos y ejecutarse, no obstante, en el procesador destino . Aunque tales compiladores de lenguaje intermedio compi-lan las instrucciones de lenguaje intermedio en el sistema informático destino, tampoco optimizan el código para un sistema informático destino particular, incluyendo tener en cuenta las versiones de driver y otros componentes de hardware . Compendio de la invención En vista de lo anterior, la presente invención proporciona código administrado incluyendo aplicaciones y tiempo de ejecución, y/o driver. El código administrado es compilado por un compilador que tiene conocimiento a priori de la con-figuración exacta del hardware del sistema informático destino, de la misma manera que el compilador JIT tiene conocimiento a priori del tipo de procesador del cliente. Al tiempo de la compilación, se conoce la versión efectiva del sistema de los varios drivers de hardware, de modo que si se administra una aplicación y un driver, el compilador puede emitir un ejecutable sintonizado para una versión de driver particular.
Por consiguiente, la invención incluye un sistema y método que administran código para compilar código configurado para un sistema operativo que tiene un procesador seleccionado y un driver que interactúa con un componente informático. El sistema incluye una pluralidad de instrucciones de aplicación que se reciben en un lenguaje intermedio legible por un compilador de lenguaje intermedio y una pluralidad de ins-trucciones de tiempo de ejecución que también son recibidas en un lenguaje intermedio legible por un compilador de lenguaje intermedio. Un compilador de lenguaje intermedio compila las instrucciones de aplicación y las instrucciones de tiempo de ejecución en un conjunto de instrucciones de código administrado ejecutables por el procesador para interactuar con el driver seleccionado. El driver (o una porción del driver) se puede facilitar también en el lenguaje intermedio y compilar junto con las instrucciones de aplicación y las instrucciones de tiempo de ejecución en un conjunto de instruc-ciones de código administrado. Breve descripción de los dibujos El sistema y los métodos para administrar código se describen mejor con referencia a los dibujos acompañantes, en los que: La figura 1 es un diagrama de bloques que representa un entorno de red ejemplar que tiene varios dispositivos informáticos en los que se puede implementar la presente invención. La figura 2 es un diagrama de bloques que representa un dispositivo informático ejemplar no limitativo en el que se puede implementar la presente invención. Las figuras 3A y 3B ilustran diferentes modelos de dri-vers para varios sistemas informáticos. La figura 4 es un diagrama de bloques de un sistema informático que tiene una arquitectura DLL de driver de modo de usuario según un aspecto de la invención. La figura 5 ilustra la secuencia de eventos que se producen cuando una aplicación hace llamadas API en una aplica-ción gráfica ejemplar. La figura 6 ilustra la aplicación de compilación JIT a aplicación y tiempo de ejecución según un aspecto de la invención . Y la figura 7 ilustra la aplicación de compilación JIT a aplicación, driver y tiempo de ejecución según un aspecto de la presente invención. Descripción detallada de la invención Visión general Los que proponen modeles de drivers en línea citan las ventajas de rendimiento como la principal motivación para unir la implementación API al driver. Esta unión tiene muchos efectos colaterales indeseables, debido principalmente a la incapacidad de que las versiones siguientes de Tiempo de Eje-cución añadan características, mejoras de rendimiento, o cambios de la política API encima de los drivers anteriores a la versión del Tiempo de Ejecución. La invención aquí descrita reconoce que el código administrado, incluidas las aplicaciones, tiempo de ejecución y driver, deberán tener un conocimiento a priori de la configuración exacta del hardware del cliente, de la misma manera que el compilador JIT tiene un conocimiento a priori del tipo de microprocesador del cliente. Por ejemplo, en el tiempo JIT, el sistema conoce la versión efectiva del driver gráfico (DirectX 6.0, DirectX 7.0, etc) , de modo que si se administran la aplicación y el driver, el compilador JIT puede emitir un ejecutable sintonizado para una versión de driver particular . Entornos en red y distribuidos ejemplares Los expertos en la materia pueden apreciar que un ordenador u otro dispositivo cliente o servidor se puede desplegar como parte de una red informática, o en un entorno informático distribuido. A este respecto, la presente invención se refiere a cualquier sistema informático que tenga cualquier número de unidades de memoria o almacenamiento, y cualquier número de aplicaciones y procesos que se producen a través de cualquier número de unidades o volúmenes de almacenamiento. La presente invención se puede aplicar a un entorno con orde-nadores servidores y ordenadores clientes desplegados en un entorno de red o entorno informático distribuido, que tiene almacenamiento remoto o local . La presente invención también se puede aplicar a dispositivos informáticos autónomos, que tienen funcionalidad de lenguaje de programación, capacidades de interpretación y ejecución para generar, recibir y transmitir información en conexión con servicios. La informática distribuida facilita el compartir recursos informáticos y servicios por intercambio directo entre dispositivos y sistemas informáticos. Estos recursos y servi-cios incluyen el intercambio de información, almacenamiento cache, y almacenamiento de archivos en disco. La informática distribuida aprovecha la conectividad de red, permitiendo a los clientes apalancar su potencia colectiva en beneficio de toda la empresa. A este respecto, varios dispositivos pueden tener conjuntos de datos para los que sería deseable realizar las técnicas de definición de límite de imagen de la presente invención . La figura 1 proporciona un diagrama esquemático de un entorno informático en red o distribuido ejemplar. El entorno informático distribuido incluye calcular objetos 10a, 10b, etc, y calcular objetos o dispositivos 110a, 110b, 110c, etc. Estos objetos pueden incluir programas, métodos, memorias de datos, lógica programable, etc. Los objetos pueden incluir porciones de dispositivos idénticos o diferentes tales como PDAs, televisores, reproductores MP3 , televisiones, ordenadores personales, etc. Cada objeto puede comunicar con otro objeto por medio de la red de comunicaciones 14. Esta red puede incluir otros objetos de cálculo y dispositivos informáticos que proporcionan servicios al sistema de la figura 1. Según un aspecto de la invención, cada objeto 10 o 100 pueden contener datos para los que sería deseable realizar definición de límite o corte de imagen. También puede ser deseable comparar un corte de imagen de un objeto 10 o 110 con un corte de imagen de otro objeto 10 o 110. En arquitectura informática distribuida, los ordenadores, que tradicionalmente han sido utilizados únicamente como clientes, comunican directamente entre sí y pueden actuar como clientes y como servidores, asumiendo el papel que sea más eficiente para la red. Esto reduce la carga en los servidores y permite a todos los clientes acceder a recursos disponibles en otros clientes, incrementando por ello la capacidad y eficiencia de toda la red. La informática distribuida puede ayudar a las empresas a distribuir servicios y capacidades más eficientemente a través de diversos límites geográficos. Además, la informática distribuida puede aproximar más los datos al punto donde se consumen los datos actuando con un mecanismo cache de red. La informática distribuida también permite a las redes informáticas operar dinámicamente utilizando agentes inteligentes. Los agentes residen en ordenadores pares y comunican varios tipos de información en ambos sentidos. Los agentes también pueden iniciar tareas por cuenta de otros sistemas pares. Por ejemplo, se puede utilizar agentes inteligentes para priori-zar tareas en una red, cambiar el flujo de tráfico, buscar archivos localmente o determinar un comportamiento anómalo, tal como un virus, y pararlo antes de que afecte a la red. También se puede contemplar todo tipo de otros servicios. El los) algoritmo (s) de corte de imagen de la presente invención se puede (n) implementar en tal entorno. Se puede apreciar que un objeto, tal como 110c, puede estar alojado en otro dispositivo informático 10 o 110. Así, aunque el entorno físico ilustrado puede mostrar los disposi-tivos conectados corno ordenadores, tal ilustración es meramente ejemplar, y el entorno físico se puede ilustrar o describir alternativamente incluyendo varios dispositivos digitales como PDAs, televisores, reproductores MP3 , etc, objetos de software, como interfaces, objetos COM y análogos. Hay varios sistemas, componentes y configuraciones de red que soportan entornos informáticos distribuidos. Por ejemplo, los sistemas informáticos pueden estar conectados por sistemas alámbricos o inalámbricos, por redes locales o redes ampliamente distribuidas. En la actualidad, muchas redes están conectadas a Internet, que proporciona la infraestructura para informática ampliamente distribuida y abarca muchas redes diferentes. Internet se refiere de ordinario al conjunto de redes y portales que utilizan la serie de protocolos TCP/IP, que son conocidos en la técnica de las redes informáticas. TCP/IP es un acrónimo de "Protocolo de Control de Transporte/Programa de Interface". Internet se puede describir como un sistema de redes informáticas remotas distribuidas geográficamente in-terconectadas por ordenadores que ejecutan protocolos de red que permiten a los usuarios interactuar y compartir información en las redes. A causa de la difundida compartición de información, las redes remotas, como Internet, han evolucionado hasta ahora en general a un sistema abierto para el que los desarrolladores pueden diseñar aplicaciones de software para realizar operaciones especializadas o servicios, esencialmente sin restricción. Así, la infraestructura de red permite gran cantidad de topologías de red, como cliente/servidor, par a par o arquitecturas híbridas. El "cliente" es un miembro de una clase o grupo que utiliza los servicios de otra clase o grupo con el que no está relacionado. Así, en informática, un cliente es un proceso, es decir, en sentido amplio un conjunto de ins-trucciones o tareas, que pide un servicio proporcionado por otro programa. El proceso cliente utiliza el servicio solicitado sin tener que "conocer" detalles operativos acerca del otro programa o servicio propiamente dicho. En una arquitectura de cliente/servidor, en particular un sistema en red, un cliente suele ser un ordenador que accede a recursos en red compartidos proporcionados por otro ordenador, por ejemplo, un servidor. En el ejemplo de la figura 1, los ordenadores 110a, 110b, etc, se pueden considerar como clientes y el ordenador 10a, 10b, etc, se puede considerar como servidor, donde el servidor 10a, 10b, etc, mantiene los datos que después son replicados en los ordenadores clientes 110a, 110b, etc . Un servidor es típicamente un sistema informático remoto accesible por una red remota tal como Internet . El proceso cliente puede estar activo en un primer sistema informático, y el proceso servidor puede estar activo en un segundo sistema informático, que comunican entre sí por un medio de comunicaciones, proporcionando así funcionalidad distribuida y permitiendo que múltiples clientes se aprovechen de las capacidades de recogida de información del servidor. Cliente y servidor comunican entre sí utilizando la funcionalidad que proporciona una capa de protocolo. Por ejemplo, el Protocolo de Transferencia de Hipertexto (HTTP) es un protocolo común que se usa en unión con la World ide Web (WWW) o simplemente la "Web". Se utiliza típicamente una dirección de red informática, como Localizador de Recursos Universales (URL) o una dirección de Protocolo de Internet (IP) , para identificar entre sí los ordenadores servidor o cliente. La dirección de red se puede denominar dirección de Localizador de Recursos Universales. Por ejemplo, se puede establecer comunicación por un medio de comunicaciones. En particular, el cliente y el servidor pueden estar acoplados entre sí mediante conexiones TCP/IP para comunicación de alta capacidad. Así, la figura 1 ilustra un entorno en red o distribuido ejemplar, con un servidor en comunicación con ordenadores clientes mediante una red/bus, en el que se puede emplear la presente invención. Con más detalle, varios servidores 10a, 10b, etc, están interconectados mediante una red/bus de comu-nicaciones 14, que puede ser una LAN, WAN, intranet, Internet, etc, con varios dispositivos informáticos clientes o remotos 110a, 110b, 110c, HOd, llOe, etc, tal como un ordenador portátil, ordenador de mano, cliente fino, aparato en red, u otro dispositivo, tal como VCR, TV, horno, luz, calefactor y análogos según la presente invención. Así, se contempla que la presente invención se pueda aplicar a cualquier dispositivo informático en conexión con el que es deseable comunicar con otro dispositivo informático con respecto a servicios de definición de corte o límite. En un entorno de red en el que la red de comunicaciones/bus 14 es Internet, por ejemplo, los servidores 10 pueden ser servidores Web con los que los clientes 110a, 110b, 110c, HOd, llOe, etc, comunican mediante alguno de varios protoco-los conocidos, tal como protocolo de transferencia de hiper-texto (HTTP) . Los servidores 10 también pueden servir como clientes 110, según puedan ser característicos de un entorno informático distribuido. Las comunicaciones pueden ser alámbricas o inalámbricas, según sea apropiado. Los dispositivos clientes 110 pueden comunicar o no mediante la red de comunicaciones/bus 14, y tienen tener comunicaciones independientes asociadas. Por ejemplo, en el caso de un TV o VCR, puede haber o no un aspecto de red para su control . Cada ordenador cliente 110 y cada ordenador servidor 10 puede estar equipado con varios módulos de programa de aplicación u objetos 135 y con conexiones o accesos a varios tipos de elementos de almacenamiento u objetos, mediante los que se puede almacenar archivos o a los que se puede descargar o migrar una porción o porciones de archivos. Cualquier ordenador 10a, 10b, 110a, 100b, etc, puede ser responsable del mantenimiento y actualización de una base de datos 20 u otro elemento de almacenamiento según la presente invención, tal como una base de datos 20 para almacenar software de procesado de imágenes para procesar imágenes según la presente invención. Así, la presente invención se puede utilizar en un entorno de red informática que tiene ordenadores clientes 110a, 110b, etc, que pueden acceder e interactuar con una red informática/bus 14 y ordenadores servidores 10a, 10b, etc, que pueden interactuar con ordenadores clientes 110a, 110b, etc, y otros dispositivos 111 y bases de datos 20. Dispositivo informático ejemplar La figura 2 y la explicación siguiente tienen la finalidad de proporcionar una breve descripción general de un en-torno informático adecuado en el que se puede implementar la invención. Se deberá entender, sin embargo, que se contempla dispositivos informáticos de mano, portátiles y otros y objetos informáticos de todo tipo para uso en conexión con la presente invención. Aunque a continuación se describe un or-denador de propósito general, esto es sólo un ejemplo, y la presente invención se puede implementar con un cliente fino que tenga interoperabilidad e interacción red/bus. Así, la presente invención se puede implementar en un entorno de ser-vicios agrupados en red en el que están implicados muy pocos o mínimos recursos de cliente, por ejemplo, un entorno de red en el que el dispositivo cliente sirve solamente como una in-terface con la red/bus, tal como un objeto colocado en un aparato. En esencia, cualquier lugar en el que se puedan al-macenar datos o del que se pueda recuperar datos es un entorno deseable o adecuado para la operación del (de los) algoritmo (s) de corte de imagen de la invención. Aunque no es preciso, la invención se puede implementar mediante un sistema operativo, para uso por un desarrollador de servicios para un dispositivo u objeto, y/o incluirse dentro de un software de aplicación que contribuya al procesador de datos de imagen. El software se puede describir en el contexto general de instrucciones ejecutables por ordenador, tal como módulos de programa, que son ejecutadas por uno o varios ordenadores, tal como estaciones cliente, servidores u otros dispositivos. En general, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos y análogos que realizan tareas particulares o imple-mentan tipos de datos abstractos particulares. Típicamente, la funcionalidad de los módulos de programa se puede combinar o distribuir según se desee en varias realizaciones. Además, los expertos en la materia apreciarán que la invención se puede llevar a la práctica con otras configuraciones de sis-temas informáticos. Otros sistemas informáticos conocidos, entornos, y/o configuraciones que pueden ser adecuados para ser utilizados con la invención incluyen, aunque sin limitación, ordenadores personales (PCs) , cajeros automáticos, ordenadores servidores, dispositivos de mano o portátiles, sis-temas multiprocesadores , sistemas basados en microprocesador, electrónica programable de consumidor, PCs en red, aparatos, luces, elementos de control ambiental, miniordenadores , ordenadores centrales y análogos. La invención se puede llevar a la práctica en entornos informáticos distribuidos donde las tareas son realizadas por dispositivos de procesado remotos que están conectados mediante una red de comunicaciones/bus u otro medio de transmisión de datos. En un entono informático distribuido, los módulos de programa pueden estar situados en un medio de almacenamiento informático local o remoto incluyendo dispositivos de almacenamiento en memoria, y los nodos clientes se pueden compoíiéafig Ba de un entorno de sistema informático adecuado 100 en el que se puede implementar la invención, aunque, como se ha aclarado anteriormente, el entorno de sistema informático 100 es sólo un ejemplo de un entorno informático adecuado y no se pretende sugerir ninguna limitación del alcance de uso o funcionalidad de la invención. Tampoco se deberá interpretar que el entorno informáti-co 100 tiene dependencia o requisitos relativos a alguno o a la combinación de componentes ilustrados en el entorno operativo ejemplar 100. Con referencia a la figura 2, un sistema ejemplar para implementar la invención incluye un dispositivo informático de propósito general en forma de un ordenador 110. Los componentes del ordenador 110 pueden incluir, aunque sin limitación, una unidad de procesado 120, una memoria de sistema 120, y un bus de sistema 121 que acopla varios componentes de sistema incluida la memoria del sistema a la unidad de proce-sado 120. El bus de sistema 121 puede ser alguno de varios tipos de estructuras de bus incluido un bus de memoria o con-trolador de memoria, un bus periférico, y un bus local que utilice alguna de varias arquitecturas de bus. A modo de ejemplo, y no como limitación, tales arquitecturas incluyen el bus Industry Standard Architecture (ISA) , el bus Micro Channel Architecture (MCA) , el bus ISA Mejorado (EISA) , el bus local Video Electronics Standards Association (VESA) , y el bus Peripheral Component Interconnect (PCI) (también llamado bus Mezzanine) .
El ordenador 110 incluye típicamente varios medios legibles por ordenador. Los medios legibles por ordenador pueden ser cualesquiera medios accesibles por el ordenador 110 e incluyen medios tanto volátiles como no volátiles, medios ex-tralbles y no extraíbles. A modo de ejemplo, pero no de limitación, los medios legibles por ordenador pueden incluir medios de almacenamiento informático y medios de comunicaciones. Los medios de almacenamiento informático incluyen medios tanto volátiles como no volátiles, extraíbles y no extraíbles implementados en cualquier método o tecnología para almacenamiento de información, tal como instrucciones legibles por ordenador, estructuras de datos, módulos de programa u otros datos. Los medios de almacenamiento informático incluyen, aunque sin limitación, RAM, ROM, EEPROM, memoria flash u otra tecnología de memoria, CDROM, discos digitales versátiles (DVD) u otro almacenamiento en disco óptico, casetes magnéticas, cinta magnética, almacenamiento en disco magnético u otros dispositivo de almacenamiento magnéticos, o cualquier otro medio que se pueda usar para almacenar la información deseada y al que pueda acceder el ordenador 10. Los medios de comunicaciones incorporan típicamente instrucciones legibles por ordenador, estructuras de datos, módulos de programa u otros datos en una señal de datos modulada tal como una onda portadora u otro mecanismo de transporte, e incluyen cuales-quiera medios de suministro de información. El término "señal de datos modulada" significa una señal que tiene una o varias de sus características establecidas o cambiadas de tal manera que codifique información en la señal. A modo de ejemplo, y no como limitación, los medios de comunicaciones incluyen medios alámbricos, como una red alámbrica o conexión alámbrica directa, y medios inalámbricos, como medios acústicos, RF, infrarrojos y otros medios inalámbricos. Las combinaciones de cualquiera de los anteriores también se deberán incluir de-ntro del alcance de los medios legibles por ordenador. El sistema de memoria 130 incluye medios de almacenamiento informático en forma de memoria volátil y/o no volátil, como la memoria de lectura solamente (ROM) 121 y la memoria de acceso aleatorio (RAM) 132. Un sistema básico de en-trada/salida 133 (BIOS) , conteniendo las rutinas básicas que contribuyen a transferir información entre elementos dentro del ordenador 110, por ejemplo durante el arranque, se almacena típicamente en la ROM 131. La RAM 132 contiene típicamente datos y/o módulos de programa que son accesibles inme-diatamente y/o están siendo puestos actualmente en operación por la unidad de procesado 120. A modo de ejemplo, pero no como limitación, la figura 2 ilustra un sistema operativo 134, programas de aplicación 135, otros módulos de programa 136 y datos de programa 137.
El ordenador 110 también puede incluir otros medios de almacenamiento informático extraíbles/no extraíbles, volátiles/no volátiles. A modo de ejemplo solamente, la figura 2 ilustra una unidad de disco duro 141 que lee o escribe en un disco magnético extraíble, no volátil 152, y una unidad de disco óptico 155 que lee o escribe en un disco óptico extraíble, no volátil 156, tal como un CD ROM u otros medios ópticos. Otros medios de almacenamiento informáticos extraíbles/no extraíbles, volátiles/no volátiles que se puede usar en el entorno operativo ejemplar incluyen, aunque sin limitación, casetes de cinta magnética, tarjetas de memoria flash, discos digitales versátiles, cintas vídeo digitales, RAM de estado sólido, ROM de estado sólido, y análogos. La unidad de disco duro 141 está conectada típicamente al bus de sistema 121 mediante una interface de memoria no extraíble tal como la interface 140, y la unidad de disco magnético 151 y la unidad de disco óptico 155 están conectadas típicamente al bus de sistema 121 mediante una interface de memoria extraíble, tal como la interface 150. Las unidades y sus medios de almacenamiento informático asociados antes explicados e ilustrados en la figura 2 proporcionan almacenamiento de instrucciones legibles por ordenador, estructuras de datos, módulos de programa y otros datos para el ordenador 110. En la figura 2, por ejemplo, la unidad de disco duro 141 se ilustra almacenando el sistema operativo 144, programas de aplicación 145, otros módulos de programa 146 y datos de programa 147. Obsérvese que estos componentes pueden ser los mismos o diferentes del sistema operativo 134, programas de aplicación 135, otros módulos de programa 136 y datos de programa 137. El sistema operativo 144, los programas de aplicación 145, otros módulos de programa 146 y datos de programa 147 reciben aquí números diferentes para ilustrar que, como mínimo, son copias diferentes. Un usuario puede introducir órdenes e información en el ordenador 110 mediante dispositivos de entrada tal como un teclado 162 y dispositivo puntero 161, denominado de ordinario ratón, trackball o panel de contacto. Otros dispositivos de entrada (no representados) pueden incluir un micrófono, joys-tick, teclado de juego, plato de satélite, escáner o análogos. Estos y otros dispositivos de entrada están conectados frecuentemente a la unidad de procesado 120 mediante una in-terface de entrada de usuario 160 que está acoplada al bus de sistema 121, pero puede estar conectada por otras estructuras de interface y bus, tal como un puerto paralelo, puerto de juegos o bus serie universal (USB) . Una interface gráfica 182, tal como Northbridge, también puede estar conectada al bus de sistema 121. Northbridge es un conjunto de chips que comunica con la CPU o unidad central de procesado 120, y asu-me responsabilidad para comunicaciones AGP. Una o varias unidades de procesado gráfico (GPUs) 184 pueden comunicar con la interface gráfica 182. A este respecto, las GPUs 184 incluyen en general almacenamiento en memoria en chip, como el almace-namiento de registros, y las GPUs 184 comunican con una memoria vídeo 186. Un monitor 191 u otro tipo de dispositivo de visualización también está conectado al bus de sistema 121 mediante una interface, tal como una interface vídeo 190, que a su vez puede comunicar con la memoria vídeo 186. Además del monitor 191, los ordenadores también pueden incluir otros dispositivos periféricos de salida, como altavoces 197 e impresora 196, que pueden estar conectados mediante una interface de periférico de salida 195. El ordenador 110 puede operar en un entorno en red o distribuido usando conexiones lógicas con uno o varios ordenadores remotos, tal como un ordenador remoto 180. El ordenador remoto 180 puede ser un ordenador personal, un servidor, un ruter, un PC en red, un dispositivo par u otro nodo de red común, e incluye típicamente muchos o todos los elementos an-tes descritos con relación al ordenador 110, aunque sólo se ha ilustrado en la figura 2 un dispositivo de almacenamiento en memoria 181. Las conexiones lógicas ilustradas en la figura 2 incluyen una red de área local (LAN) 171 y una red de área ancha (WAN) 173, pero también pueden incluir otras re-des/buses. Tales entornos de red son lugares comunes en viviendas, oficinas, redes informáticas de empresa, intranets e Internet . Cuando se utiliza en un entorno de red LAN, el ordenador 110 está conectado a la LAN 171 mediante una interface de red o adaptador 170. Cuando se utiliza en un entorno de red WAN, el ordenador 110 incluye típicamente un módem 172 u otros medios para establecer comunicaciones por la WAN 173, como Internet. El módem 172, que puede ser interno o externo, puede estar conectado al bus de sistema 121 mediante la interface de entrada de usuario 160, u otro mecanismo apropiado. En un entorno en red, los módulos de programa ilustrados con relación al ordenador 110, o sus porciones, se pueden almacenar en el dispositivo remoto de almacenamiento en memoria. A modo de ejemplo, pero no de limitación, la figura 2 ilustra programas de aplicación remotos 185 residentes en el dispositivo de memoria 181. Se apreciará que las conexiones de red mostradas son ejemplares y se puede usar otros medios de establecer un enlace de comunicaciones entre los ordenadores. Estructuras o arquitecturas informáticas distribuidas ejemplares Se han desarrollado y se están desarrollando varias estructuras informáticas distribuidas a la luz de la convergencia de la informática personal e Internet. Los usuarios indi-viduales y comerciales reciben una interface interoperable continua y habilitada en Web para aplicaciones y dispositivos informáticos, que hace las actividades informáticas cada vez más orientadas a red o examinador de Web. Por ejemplo, la plataforma .Net de MICROSOFT® incluye servidores, servicios de módulos funcionales, como almacenamiento de datos a base de Web y software descargable para dispositivos. En términos generales, la plataforma .Net proporciona (1) la capacidad de hacer que una gama completa de dispositivos informáticos operen juntos y que la información de usuario se actualice y sincronice automáticamente en todos ellos, (2) mayor capacidad interactiva para páginas Web, habilitada por un mayor uso de XML en vez de HTML, (3) servicios en línea que incluyen acceso y suministro personalizados de productos y servicios al usuario desde un punto inicial central para la administración de varias aplicaciones, como correo electrónico, por ejemplo, o software, como Office. Net,
(4) almacenamiento centralizado de datos, que incrementará la eficiencia y facilidad de acceder a información, así como sincronización de información entre usuarios y dispositivos,
(5) la capacidad de integrar varios medios de comunicaciones, como correo electrónico, faxes y teléfonos, (6) para los des-arrolladores , la capacidad de crear módulos reutilizables , incrementando por ello la productividad y reduciendo el núme-ro de errores de programación, y (7) también puede hacer otras muchas características de integración a través de plataformas . Administración de drivers en un sistema informático Las figuras 3A y 3B son una simple ilustración de cómo interactúan un programa de aplicación 135, tiempo de ejecución 302 y driver 303 mediante una API y DDI . En el contexto del despliegue API/DDI de gráficos, actualmente hay dos modelos de drivers predominantes : un modelo de driver en línea y un modelo de driver en capas. La figura 3A ilustra un driver en línea, esencialmente una implementa-ción API plena que ha sido instrumentada para ejecutarse en una pieza particular de hardware, por ejemplo, la interface vídeo 190 (figura 2) . Los ejemplos de APIs que utilizan mode-los de driver en línea incluyen APIs gráficas de propiedad, como 3Dfx Glide y ATI CIF, así como OpenGl . Los drivers en capas, como ge ilustra en la figura 3B, introducen un nivel adicional de indirección en el que la im-plementación API implementa cierta lógica (tal como valida-ción de parámetros) y código (tal como conducto de geometría) antes de llamar al driver 303 mediante la DDI. El término "driver en capas" se refiere no sólo a la idea de que la API llama a la DDI después de realizar el trabajo, sino también a la idea de que el driver 303 puede implementar diferentes "capas" dependiendo de cuánta funcionalidad sea implementada por el hardware 306. Por ejemplo, la DDI para un producto de hardware gráfico que implementase rasterización solamente sería de nivel inferior a la de un producto que implementase transformación e iluminación así como rasterización. El soporte de varios drivers en capas aumenta la complejidad de una implementación de tiempo de ejecución 302. Por ejemplo, DIRECTX 7.0 de MICROSOFT, que tiene soporte para transformación e iluminación aceleradas por hardware, debe comprobar que el driver subyacente 303 implementa dicha característica. Si es así, las aplicaciones 135 pueden crear y usar dispositivos con la característica; de otro modo, la característica debe ser emulada por tiempo de ejecución 302 en software. Como resultado, los recorridos de código ejecutados por DIRECTX 7.0 son considerablemente diferentes dependiendo de si se están ejecutando en un driver de estilo DIRECTX 7.0 o un driver pre-DIRECTX 7.0. La figura 4 ilustra también las capas de una aplicación ejemplar, tiempo de ejecución y driver en un sistema. La aplicación 135, tiempo de ejecución 302 y parte del driver 303 operan en modo de usuario para escribir órdenes de dibujo en memorias intermedias de órdenes específicas de hardware en memoria DMA. En un sistema PC contemporáneo, estas escrituras serían típicamente escrituras no temporales en memoria AGP; y como se ilustra en este ejemplo de implementación, la aplicación 135 reside en un EXE y tiempo de ejecución 302 y el driver de modo de usuario 303 reside en DLLs que están conectadas dinámicamente con la aplicación 135. Estos detalles de la porción de modo de usuario del sistema pueden variar; específicamente, la aplicación 135, la aplicación 135 y el tiempo de ejecución 302, o la aplicación 301, el tiempo de ejecución 203 y el driver de modo de usuario 303 podrían ser potencial -mente código administrado. Para defenderse de la sustitución no autorizada de un driver de modo de usuario (por ejemplo, 303) , un sistema consulta típicamente al driver de núcleo 405 (puesto que se confía en el código núcleo desde el punto de vista de la seguridad) para que cargue la DLL de driver de modo de usuario 303. El programador de memoria intermedia de órdenes 404
("programador" y driver núcleo 405 operan juntos en modo núcleo para repartir memorias intermedias de órdenes al hardware 406 (el programador 404 decide qué memoria intermedia de órdenes se deberá repartir, mientras que el driver núcleo 405 ordena al hardware 406 que reparta una memoria intermedia de órdenes a petición del programador 404) . Este sistema contempla que la mayor parte de la lógica de driver residirá en la DDL de driver de modo de usuario 403, no el driver núcleo 405. Mientras que el driver de modo de usuario 403 puede con-tener grandes cantidades de código que correlaciona llamadas de nivel DDI a órdenes específicas de hardware (operación que puede ser complicada y propensa a errores, especialmente al compilar un programa vértice y/o sombra), el driver núcleo 405 es comparativamente pequeño y simple, maximizando la robustez del sistema. La figura 5 esclarece la secuencia de eventos que se producen cuando una aplicación 135 está haciendo llamadas API en un ejemplo de operaciones gráficas. Las memorias interínedias de órdenes no se ilustran específicamente en la figura 5 como un componente de hardware; según la figura 4, el driver de modo de usuario 303 escribe órdenes específicas de hardware en la memoria intermedia de órdenes corriente del dispositivo, el programador de memoria intermedia de órdenes (parte del soporte núcleo del sistema 530) reparte la memoria intermedia de órdenes al hardware 306 mediante el driver de modo núcleo 405, y las memorias intermedias de órdenes acabadas son recicladas para ser usadas por una aplicación 135 en el sistema. Obsérvese que múltiples aplicaciones 135 pueden com-partir potencialmente el grupo de memorias intermedias de órdenes disponibles, arbitrando el soporte núcleo del sistema 530 la compartición de dicho recurso. Cuando la aplicación 135 crea inicialmente un contexto de dibujo 501, el soporte núcleo de sistema 530 comprueba si se puede crear una nueva memoria intermedia de órdenes 531. Si es así, se crea la nueva memoria intermedia de órdenes 532 y se inicializa 533, y el hilo obtiene una memoria intermedia de órdenes inicializada 534 antes de que la aplicación 135 pueda realizar llamadas de dibujo 502. Si no se pudo crear una memoria intermedia de órdenes en el paso 531, la aplicación 135 debe esperar hasta que esté disponible 534 una memoria intermedia de órdenes inicializada. Una vez que la aplicación 135 ha obtenido una memoria intermedia de órdenes, la aplicación 135, el tiempo de ejecución 302 y el driver de modo de usuario 303 entran en la interacción típica entre los tres componentes que hacen que se escriban las órdenes específicas de hardware en la memoria intermedia de órdenes. Las llamadas de dibujo 503 de la aplicación 135 son validadas 511 por tiempo de ejecución 302; una comprobación 512 determina entonces si hay que vaciar la memoria intermedia de órdenes corriente. En caso negativo, la orden de dibujo se traduce a una llamada DDI canónica más simple 513 y se pasa al driver de modo de usuario 520. El driver traduce la llamada DDI a órdenes específicas de hardware e intenta escribirlas en la memoria intermedia de órdenes. Si la comprobación 522 de vaciado determina que no hay espacio en la memoria intermedia de órdenes, la memoria intermedia de órdenes debe ser presentada al soporte núcleo de sistema 530 y se puede escribir una nueva memoria intermedia de órdenes obtenida de la misma orden anterior y puede continuar la ejecución. Si tiempo de ejecución 302 o el driver de modo de usuario 303 determinan que es necesario un vaciado, según el paso 535 la memoria in-termedia de órdenes se añade a la cola de espera. Entonces, el núcleo de sistema puede comprobar 536 si la memoria intermedia de órdenes puede ser presentada inmediatamente (típicamente porque ninguna memoria intermedia de órdenes está funcionando) . En caso negativo, la memoria intermedia de órdenes se deja en la cola de espera y hay que obtener una orden ini-cializada adecuada 534. Obsérvese que este bloque funcional, que espera hasta que esté disponible una memoria intermedia de órdenes inicializada adecuada y después la asigna al dispositivo, es idéntica a la operación que necesita la aplicáción 135 antes de que pueda empezar a dibujar. Cuando se selecciona una memoria intermedia de órdenes de Listo para envío 540, el soporte núcleo de sistema 530 hace que el driver núcleo 409 conmute el hardware al contexto apropiado 551 y envíe la memoria intermedia de órdenes al hardware 552. El hardware 306 lee entonces y ejecuta la memoria intermedia de órdenes 561, hasta que se prevacía o termina la memoria intermedia de órdenes. Si la memoria intermedia de órdenes termina normalmente 563, el hardware indica una interrupción y se ejecuta la rutina de servicio de interrup-ciones 553. La ISR puede desear guardar entonces el contexto de hardware 554, aunque el driver puede desear diferir esta operación al interruptor de contexto 551, en caso de que el hardware pidiese ejecutar dos memorias intermedias de órdenes en fila que operen en el mismo contexto. Después de este paso 554, el soporte de sistema núcleo 530 puede liberar los recursos que necesita la memoria intermedia de órdenes 538, así como indicar a cualesquiera mecanismos de notificación tales eventos para dejar que los clientes interesados sepan que la memoria intermedia de órdenes está terminada. Después de este paso 538, el soporte de sistema núcleo tiene dos tareas distintas: debe reinicializar la memoria intermedia de órdenes recientemente disponible y añadirla al grupo inicializado 533, y debe desbloquear las memorias intermedias de órdenes de Espera y pasarlas a la cola Listo 539. Después del paso 539, se puede seleccionar otra memoria intermedia de órdenes para envío 540. La complejidad de las comunicaciones entre-procesos descritas con respecto a las figuras 4 y 5 ilustra la necesidad del código administrado según un aspecto de la invención. En particular, el sistema descrito con respecto a la figura 5 podría apalancar el código administrado, en el que porciones de la aplicación 135, el tiempo de ejecución 302 y/o driver de modo de usuario 303 se suministran en forma de lenguaje intermedio y son compilados JIT en el cliente. Los tres componentes se enviarían por separado al cliente en forma de lenguaje intermedio. El compilador JIT los sintetizaría en una pieza unificada de código objeto que incluyese porciones de los tres componentes. Tal arquitectura permitiría un sistema donde se ejecutará más código objeto óptimo. Además, las constantes en la llamada de la aplicación 135 a un punto de entrada se propagarían al tiempo de ejecución 302 y el driver de modo de usuario 303, dando lugar potencialmente al código objeto que escribió unas pocas palabras constantes en la memoria intermedia de órdenes en lugar de cruzar varios límites de llamada de función para lograr el mismo resultado. La forma de lenguaje intermedio de la aplicación 135 seguiría siendo independiente de hardware, porque el driver de modo de usuario 303 sería específico del hardware gráfico en el cliente. Además, todo el código administrado se podría enviar al sistema por una red, como se ha descrito anteriormente en la figura 1. Aunque se lograrían las mejores mejoras de rendimiento potenciales generando código administrado para los tres componentes (es decir, aplicación 135, tiempo de ejecución 302 y driver de modo de usuario 303) , un sistema podría hacer que la aplicación 135 y el tiempo de ejecución 302 fuesen administrados e interactuar con un driver de modo de usuario se-parado 303, o incluso que la aplicación 135 fuese administrada e interactuar con un tiempo de ejecución separado 302 y driver de modo de usuario 303. De hecho, se podría hacer que tales subsistemas coexistiesen pacíficamente, a condición de que las formas de lenguaje intermedio y DLL de modo de usuario del tiempo de ejecución 302 y/o el driver de modo de usuario 303 estuviesen disponibles. Los sistemas se podrían beneficiar también del código administrado tardío, en gran parte como ya se ha descrito. Si se adminístrase el tiempo de ejecución 302, un JIT podría realizar optimizaciones tales como verificaciones de validación de parámetros en el tiempo de ejecución. En el sistema de la figura 5, el código objeto generado por el JIT emitiría datos a una memoria intermedia para su análisis y traducción por el driver de modo núcleo 405. La sección siguiente describe con más detalle el sistema y las ventajas de los aspectos de código administrado de la invención. Código administrado El mecanismo tradicional para despliegue de software ha comportado escribir código fuente, compilar el código fuente en forma ejecutable para un tipo específico de ordenador, e instalar el código ejecutable en el ordenador cliente de manera que se pueda ejecutar. Otra metodología, habilitada en la infraestructura .Net, añade un paso adicional a este pro-ceso. El código fuente se traduce a una forma intermedia fácilmente compilable que se instala en el ordenador cliente. El ordenador cliente usa entonces un compilador JIT ("justo a tiempo") para traducir el código intermedio a código "admi-nistrado" nativo ejecutable de manera que se pueda ejecutar. Este método tiene varias ventajas. Una ventaja es que el código intermedio es independiente de plataforma; dado que la traducción a código ejecutable tiene lugar en el cliente, el cliente que separa cómo compilar el código intermedio puede ejecutar la aplicación. Una ventaja relacionada es que el código intermedio independiente de plataforma se puede transmitir y ejecutar en una plataforma que no existía cuando se escribió el código. Sin embargo, en el contexto de la invención, la ventaja más importante de la compilación JIT es que, mientras se está generando el código administrado, el compilador JIT tiene conocimiento a priori de la naturaleza exacta del ordenador destino (es decir, el cliente en el que se está ejecutando el compilador JIT) . Si el ordenador cliente tiene un tipo parti-cular de microprocesador, el compilador JIT puede emitir un código que sea nativo para dicho microprocesador específico. Por ejemplo, el microprocesador Pentium Pro añadió instrucciones de movimiento condicional al conjunto de instrucción x86, y el microprocesador Pentium 3 añadió preextracción y otras instrucciones de administración de cache que no estaban disponibles en sus predecesores. El soporte de estas instrucciones específicas de microprocesador en software desplegado tradicionalmente requiere que el desarrollador escriba código fuente que use todas las diversas características, escribir después software de detección para calcular qué ruta de código ejecutar en el cliente en el que el código esté ejecutándose. El paso JIT libera al desarrollador de esta tarea e incluso ofrece al desarrollador protección contra futuras innovaciones. En otros términos, un ordenador que incluyese una instrucción nueva que beneficiaría a la aplicación del desarrollador, podría incluir un compilador JIT que conozca cómo emitir dicha instrucción; la aplicación se beneficiaría de la nueva instrucción aunque no existiese cuando se desarrolló la aplicación. Quienes proponen modelos de driver en línea citan ventajas de rendimiento como la principal motivación para unir la implementación API al driver. Esta unión tiene muchos efectos colaterales indeseables, debido principalmente a la incapacidad de que versiones siguientes del tiempo de ejecución añadan características, mejoras de rendimiento o cambios de la política API encima de drivers de fecha anterior a la versión del tiempo de ejecución. Hay un amplio precedente en la historia de DIRECTX que resalta la utilidad de las mejoras API que funcionan en una base instalada de drivers. Estas mejoras API pueden ir desde joras API pueden ir desde métodos de dibujo más fáciles de usar, como la DIRECTX 5.0 DrawPrimit ive API que funcionaba en drivers anteriores a DIRECTX 5.0; mejoras de rendimiento, tales como el conjunto de geometría DIRECTX 6.0 que funcionaba en drivers anteriores a DIRECTX 6.0; y cambios de política de nivel API, como el administrador de textura de DIRECTX 6.0 que funcionaba en drivers anteriores a DIRECTX 6.0. Estos tipos de mejoras son difíciles o imposibles de proporcionar si los drivers en cuestión son drivers en línea. De la misma manera que el compilador JIT tiene conocimiento a priori del tipo de microprocesador del cliente, también tiene conocimiento a priori de la configuración exacta del hardware del cliente. En particular, conoce el tipo de procesador gráfico y el driver asociado en el cliente. Por ejemplo, al tiempo de JIT, el sistema conoce la versión efectiva del driver gráfico (DIRECTX 6,0, DIRECTX 7.0, etc) , de modo que si se administran la aplicación y el driver, el compilador JIT puede emitir un ejecutable sintonizado con la versión del driver. La figura 6 ilustra tal sistema. La aplicación 135 y el tiempo de ejecución 302 se reciben en una forma de lenguaje intermedio (IL) tal como CLRT de MICROSOFT. El compilador JIT 602 toma la aplicación IL 135 y el tiempo de ejecución IL 302 y loa une en una sola aplicación administrada compilada 604. Dicha aplicación comunicaría con el driver 303 y el hardware 306 como se ha descrito anteriormente . El método a base de JIT ilustrado en la figura 6 permite muchas optimizaciones, incluyendo: El soporte para diferentes DDIs sería más eficiente, puesto que el tipo de DDI es conocido al tiempo de la compilación. Esto elimina grandes cantidades de código condicional . Se puede eliminar el código condicional si la condición es conocida al tiempo JIT, por ejemplo, se puede eliminar la validación de parámetros por parámetros válidos garantizados. Las funciones de tiempo de ejecución triviales puede estar en línea, permitiendo la programación de instrucciones en forma a las llamadas de función. El código ejecutable ( implementación tanto en línea como en tiempo de ejecución) se podría dirigir al tipo de procesador central específico. La importancia de las optimizaciones específicas de procesador está creciendo a medida que los proveedores de microprocesadores aumentan la velocidad a la que modifican los conjuntos de instrucciones. El rendimiento de esta arquitectura se puede mejorar más apalancando un driver a base de lenguaje intermedio (IL) .
La figura 7 proporciona una realización alternativa del sistema de código administrado. Aquí, la arquitectura permitiría que la aplicación compilada 135 escribiese órdenes específicas de hardware directamente en memorias intermedias de órdenes o FIFOs. Además de las implicaciones de rendimiento, otros beneficios potenciales incluyen reducir el esfuerzo técnico requerido para que los IHV suministren drivers de plataforma cruzada y permitir mejores herramientas de validación para garantizar la corrección de los drivers. La aplícación 135, el tiempo de ejecución 302 y el driver 303 se suministran a JIT 603 en forma IL. JIT 602 los convierte a una aplicación administrada 604. Históricamente, DIRECTX ha implementado un modelo de driver en capas en el que el tiempo de ejecución traducía gráficos y órdenes de dibujar a un flujo de testigos simplificados independientes de hardware. Cuando la rutina DIRECTX determine que se precisa vaciado (es decir, las órdenes del flujo deben ser ejecutadas por el hardware) , pasaría a modo núcleo y pasaría la serie de órdenes al driver de gráficos. El driver analizaría después la serie de órdenes y la traduciría a órdenes específicas de hardware, y escribiría típicamente estas órdenes en una memoria intermedia para su consumo por parte del hardware. Con referencia de nuevo a la figura 4 en unión con las figuras 6 y 7, el driver de modo núcleo 405 sería de tamaño mínimo, implementando sólo suficiente código para inicializar el hardware, iniciar una operación DMA para consumir una memoria intermedia de órdenes ya compuesta, y preparar y mane-jar interrupciones. La implementación de la invención en el contexto de la figura 4 tomaría dos formas. Primera: como se ha explicado anteriormente, la aplicación 135 y el tiempo de ejecución 302 podrían ser compilados por JIT 602 de manera que el código administrado tardío interactuase con el driver DLL 303. JIT 602 conocería entonces las características exactas del driver DLL 303 al tiempo de la compilación (por ejemplo, si implemento aceleración de transformación e iluminación) , y podría aprovechar ese conocimiento al generar código objeto para el ordenador cliente. La segunda variante de "driver administrado" de la invención implementada en el contexto de la figura 4 comportaría que el JIT 602 compilase la aplicación 135, el tiempo de ejecución 302 y el driver DLL 303, de modo que una pieza unificada de código ejecutable realizase la traducción de API y escribiese órdenes específicas de hardware en la memoria DMA 410. Esta arquitectura combina la robustez y otras ventajas de un modelo de driver en capas con la eficiencia obtenida por la especificidad del hardware de un modelo de driver en línea. Por lo tanto, este "modelo de driver administrado" brinda un mayor potencial de rendimiento en comparación con otras arquitecturas de driver. Como se ha mencionado anteriormente, aunque se ha descrito realizaciones ejemplares de la presente invención en conexión con varios dispositivos informáticos y arquitecturas de red, los conceptos subyacentes se pueden aplicar a cualquier dispositivo o sistema informático en el que se desee administrar aplicaciones y drivers . Así, las técnicas para administrar aplicaciones según la presente invención se pue-den aplicar a varias aplicaciones y dispositivos. Por ejemplo, las ventajas de la invención se pueden aplicar al sistema gráfico de un dispositivo informático, previsto como un objeto separado en el dispositivo, como parte de otro objeto, como objeto descargable de un servidor, como "mediador" entre un dispositivo u objeto y la red, etc. La aplicación administrada generada se puede almacenar para uso posterior, o enviar a otro proceso o servicio independiente, dependiente o relacionado. Aunque los lenguajes de programación ejemplares, los nombres y los ejemplos se han elegido aquí como represen-tativos de varias opciones, estos lenguajes, nombres y ejemplos no pretenden ser limitativos. Las varias técnicas aquí descritas se pueden implementar en conexión con hardware o software o, cuando sea apropiado, con una combinación de ambos. Así, los métodos y aparatos de la presente invención, o algunos aspectos o porciones de la misma, pueden tomar la forma de código de programa (es decir, instrucciones) realizadas en medios tangibles, como disque-tes, CD-ROMs, discos duros o cualquier otro medio de almace-namiento legible por máquina, donde, cuando el código de programa se carga y es ejecutado por una máquina, tal como un ordenador, la máquina se convierte en un aparato para poner en práctica la invención. En el caso de ejecución de código de programa en ordenadores programables , el dispositivo in-formático incluirá en general un procesador, un medio de almacenamiento legible por el procesador (incluidos elementos de memoria y/o almacenamiento volátiles y no volátiles) , al menos un dispositivo de entrada, y al menos un dispositivo de salida. Uno o varios programas que pueden utilizar las técni -cas de descubrimiento límite de la presente invención, por ejemplo, mediante el uso de una API de proceso de datos o análogos, se implementan preferiblemente en un lenguaje de programación orientada a objetos o procedimental de alto nivel para comunicar con un sistema informático. Sin embargo, el (los) program (s) se pueden implementar en lenguaje ensamblador o máquina, si se desea. En cualquier caso, el lenguaje puede ser un lenguaje compilado o interpretado, y combinarse con implementaciones de hardware. Los métodos y aparatos de la presente invención también se pueden llevar a la práctica mediante comunicaciones realizadas en forma de código de programa que se transmite por algún medio de transmisión, tal como por hilos o cables eléctricos, fibra óptica o mediante cualquier otra forma de transmisión, donde, cuando el código de programa es recibido y cargado y ejecutado por una máquina, tal como una EPROM, una red de puertas, un dispositivo lógico programable (PLD) , un ordenador cliente, una grabadora vídeo o análogos, o una máquina receptora que tenga técnicas de driver como las des-critas en las realizaciones ejemplares anteriores, se convierta en un aparato para llevar a la práctica la invención. Cuando se implementa en un procesador de propósito general, el código de programa se combina con el procesador para proporcionar un aparato único que sirve para invocar la funcio-nalidad de la presente invención. Además, las técnicas de almacenamiento usadas en conexión con la presente invención pueden ser invariablemente una combinación de hardware y software . Aunque la presente invención se ha descrito en conexión con realizaciones preferidas de las varias figuras, se ha de entender que se pueden usar otras realizaciones similares o se pueden hacer modificaciones y adiciones en la realización descrita para realizar la misma función de la presente invención sin apartarse de ella. Por ejemplo, aunque los entornos de red ejemplares de la invención se describen en el contexto de un entorno en red, tal como un entorno en red de par a par, los expertos en la materia reconocerán que la presente invención no se limita a ello, y que los métodos, descritos en la presente solicitud, se pueden aplicar a cualquier dispositivo o entorno informático, tal como una consola de juegos, ordenador de mano, ordenador portátil, etc, tanto alámbrico como inalámbrico, y se pueden aplicar a cualquier número de dichos dispositivos informáticos conectados mediante una red de comunicación, e interactuar a través de la red. Además, se debe recalcar que se contemplan varias plataformas informáticas, incluidos los sistemas operativos de dispositivos de mano y otros sistemas operativos específicos de aplicación, especialmente a medida que el número de dispo-altivos inalámbricos en red sigue proliferando . Además, la presente invención se puede implementar en o mediante una pluralidad de chips o dispositivos de procesado, y el almacenamiento se puede efectuar igualmente mediante una pluralidad de dispositivos. Por lo tanto, la presente invención no se deberá limitar a ninguna realización única, sino que su ámbito y alcance se deberán interpretar según las reivindicaciones anexas.