MX2015002906A

MX2015002906A - Generacion de codigo nativo a partir de un codigo de lenguaje intermediario para una aplicacion.

Info

Publication number: MX2015002906A
Application number: MX2015002906A
Authority: MX
Inventors: Sameer Tejani; Adina M Trufinescu; Yasser Shaaban; Ashish Babbar; Mei-Chin Tsai; Subramanian Ramaswamy; Casimir Lakshan Fernando; Abolade Gbadegesin
Original assignee: Microsoft Corp
Priority date: 2012-09-05
Filing date: 2013-09-03
Publication date: 2015-06-03
Also published as: PH12015500405A1; MX348681B; PH12015500405B1; US20170109148A1; EP3249526A1; SG11201501527RA; CN104781785A; EP2893441A1; AU2013312865B2; JP2015531502A; WO2014039458A1; RU2015107557A; ZA201501182B; RU2643484C2; US10795652B2; EP3249526B1; AU2013312865A1; CA2883571A1; US20140068583A1; NZ705379A

Abstract

La presente describe modalidades representativas de herramientas y técnicas para instalar, ejecutar, y/o actualizar aplicaciones manejadas a través de la generación de código nativo a partir de un código en un lenguaje intermediario. De acuerdo con una técnica ilustrativa, un dispositivo de cómputo recibe el código de lenguaje intermediario dependiente de máquina (código MDIL) generado por un proveedor en línea para una aplicación. Además, el dispositivo de cómputo instala la aplicación en el dispositivo de cómputo al generar una imagen nativa para la aplicación, que incluye unir una porción del código MDIL con una o más bibliotecas en el dispositivo de cómputo. También, la imagen nativa es almacenada en el dispositivo de cómputo para usarse para cargar la aplicación para ejecución.

Description

GENERACION DE CODIGO NATIVO A PARTIR DE UN CODIGO DE LENGUAJ E INTERMEDIARIO PARA U NA APLICACION ANTECEDENTES Varios dispositivos móviles también soportan aplicaciones que pueden ser descargadas en una representación que no puede ejecutarse directamente sino que puede ejecutarse cuando se recopila en un dispositivo móvil utilizando recopilación justo a tiempo (recopilación JIT) . Aunque se ha utilizado recopilación J IT de código para ejecutar aplicaciones en una computadora, ejecutar aplicaciones utilizando recopilación J IT tiene limitaciones, incluyendo tiempo adicional necesario para recopilación cuando se ejecuta la aplicación, y decisiones potencialmente no óptimas tomadas durante recopilación.

BREVE DESCRIPCION DE LA INVENCION Entre otras innovaciones aquí descritas, esta descripción presenta varias modalidades representativas de herramientas y téenicas para instalar, ejecutar, y actualizar aplicaciones manejadas a través de la generación de código nativo de código en lenguaje intermediario. De acuerdo con una técnica ilustrativa, un dispositivo de cómputo recibe código de lenguaje intermediario dependiente de máquma (código MDI L, según siglas en inglés) generado por un proveedor en línea para una aplicación. El dispositivo de cómputo instala la aplicación en el dispositivo de cómputo al generar una imagen nativa para la aplicación, incluyendo al unir una porción del código MDI L con una o más bibliotecas en el dispositivo de cómputo. También, la imagen nativa es almacenada en el dispositivo de cómputo para uso cuando se carga la aplicación pare ejecución.

De acuerdo con una herramienta ilustrativa, un dispositivo de cómputo recibe, de un proveedor en línea, un paquete de instalación para una aplicación, en donde el paquete de instalación incluye un grupo de archivos de lenguaje intermediario dependientes de máquma (archivos MDIL). Adicionalmente, se proporciona una carpeta del dispositivo de cómputo al menos para un archivo de grupo de archivos MDI L y una o más bibliotecas que se van a unir al menos a un archivo. La carpeta genera una imagen nativa para la aplicación al unir código MDI L del por lo menos un archivo MDI L utilizando la una o más bibliotecas.

En otra téenica ilustrativa, un proveedor en l ínea genera código MDIL a partir de código preliminar para una aplicación. Un sistema de computadora genera un grupo de archivos MDI L para la aplicación al recopilar código preliminar de la aplicación en código MDIL, entonces señala archivos respectivos del grupo de archivos MDI L para indicar los archivos respectivos que son confiados como siendo de un mercado en línea. El sistema de computadora genera una lista de unión que identifica los archivos respectivos del grupo de archivos MDI L, y también genera un paquete de instalación para la aplicación que comprende el grupo de archivos MDI L para la aplicación y realizar unión . El sistema de computadora entonces proporciona, en el mercado en línea, el paquete de instalación para descarga.

Cuando recibe el paquete de instalación, un dispositivo de cómputo recibe el código MDI L y genera una imagen nativa para la aplicación para instalar la aplicación en el dispositivo de cómputo. Adicionalmente, un procesador en tiempo de ejecución del dispositivo de cómputo y/o una o más bibliotecas utilizadas por la aplicación instalada puede actualizarse en el dispositivo de cómputo durante una actualización al dispositivo de cómputo, y la aplicación se actualiza automáticamente en respuesta a esta. La aplicación se actualiza al generar una imagen nativa actualizada para la aplicación utilizando una o más bibliotecas que se actualizaron. La imagen nativa actualizada es generada de manera que se pueda ejecutar utilizando el procesador de tiempo de ejecución actualizada en el dispositivo de cómputo. Después que se genera la imagen nativa actualizada, la aplicación se ejecuta al cargar la imagen nativa actualizada en lugar de la imagen nativa previamente generada.

Esta Breve Descripción se proporciona para introducir una selección de conceptos en una forma simplificada que además se describe a continuación. Esta Breve Descripción no pretende identificar características clave o características esenciales del tema reclamado, ni pretende utilizarse para limitar el alcance del tema reclamado. Los objetivos, características, y ventajas anteriores de las teenolog ías se harán más evidentes a partir de la siguiente descripción detallada, que procede con referencia a las figuras anexas.

BREVE DESCRIPCION DE LOS DIBUJOS La Figura 1 es un diagrama que ilustra un proveedor/mercado en línea ilustrativo y dispositivos de cómputo ilustrativos que cargan una imagen nativa de una aplicación instalada por código de lenguaje intermediario dependiente de máquma de unión (código MDIL).

La Figura 2 es un diagrama de flujo de un método ilustrativo para unir el código MDI L de una aplicación para instalar la aplicación en un dispositivo de cómputo.

La Figura 3 es un diagrama que ilustra un proveedor/mercado en l ínea ilustrativo y dispositivo de cómputo ilustrativo que puede instalar una o más aplicaciones manejadas al generar una o más imágenes nativas a partir de un código en un lenguaje intermediario que se proporciona y genera por el proveedor/mercado en línea (u otros proveedores/mercados en línea).

La Figura 4 es un diagrama de flujo de un método ilustrativo para instalar y actualizar una aplicación a través de generación de código nativo utilizando código en un MDI L.

La Figura 5 es un diagrama de flujo de un método ilustrativo para generar un paquete de instalación para una aplicación, en donde el paquete de instalación puede proporcionarse para descarga.

La Figura 6 es un diagrama de un dispositivo de cómputo que puede generar una o más imágenes nativas actualizadas para una o más aplicaciones instaladas.

La Figura 7 es un diagrama de flujo de un método ilustrativo para actualizar una aplicación al generar una imagen nativa para la aplicación de código en un MDI L.

La Figura 8 es un diagrama esquemático que ilustra un dispositivo móvil ilustrativo con el cual pueden implementarse al menos algunas de las modalidades descritas.

La Figura 9 es un diagrama esquemático que ilustra un ejemplo generalizado de un ambiente de implementación adecuado para al menos algunas de las modalidades descritas.

La Figura 10 es un diagrama esquemático que ilustra un ejemplo generalizado de un ambiente de cómputo adecuado para al menos algunas de las modalidades descritas.

DESCRIPCION DETALLADA Esta descripción presenta varias modalidades representativas de herramientas y téenicas para instalar, ejecutar, y/o actualizar aplicaciones manejadas a través de la generación de un código nativo a partir de código en un lenguaje intermediario. Por ejemplo, un dispositivo de cómputo recibe un código MDI L generado por un proveedor en línea para una aplicación. El dispositivo de cómputo instala la aplicación al generar una imagen nativa para la aplicación . Como parte de la generación de la imagen nativa, el dispositivo de cómputo une una porción del código MDI L con una o más bibliotecas en el dispositivo de cómputo. El dispositivo de cómputo almacena la imagen nativa para usarse cuando se carga la aplicación para ejecución. De esta forma, el desempeño de la aplicación puede beneficiarse de la recopilación fuera de línea previa de al menos parte de la aplicación (para producir un código MDI L apropiado para el dispositivo). Al mismo tiempo, este metodo puede facilitar la actualización de la aplicación cuando hay un cambio a una biblioteca utilizada por la aplicación y/o código MDI L para la aplicación.

Las varias características de las téenicas y herramientas aquí descritas pueden utilizarse en combinación o separadamente, dependiendo de implementación. Diferentes características de las técnicas y herramientas aquí descritas afectan diferentes etapas de procesamiento, incluyendo ingesta, instalación , ejecución, actualización de aplicación y actualización de dispositivo. El término ingesta generalmente se refiere al proceso en el cual un desarrollador carga una aplicación a un proveedor en l ínea, que procesa la aplicación para ejecución eficiente en uno o más tipos de dispositivos de cómputo, valida la aplicación, y pone a disponibilidad la aplicación para descarga. El término instalación generalmente se refiere al proceso de adaptar la aplicación para ejecutarse en un dispositivo de cómputo específico, que convierte la aplicación a una forma más adecuada para incitar y asegurar la ejecución en el dispositivo (por ejemplo, convertir código MDI L a instrucciones nativas durante unión al resolver referencias a bibliotecas y otros recursos, almacenando la imagen nativa que puede ser cargada pare ejecución, marcando la aplicación como confiada, etc. ). Durante la ejecución, la imagen nativa confiada para la aplicación puede cargarse y ejecutarse rápidamente. El término actualización de aplicación se refiere generalmente al proceso en el cual se actualiza una aplicación (por ejemplo, código MDI L para la aplicación) , que puede involucrar reinstalación de la aplicación en el dispositivo. El término actualización de dispositivo de cómputo se refiere generalmente al proceso que sigue después de un procesador de tiempo de ejecución, una biblioteca u otro recurso indicado por una aplicación que ha sido actualizada, que típicamente involucra aplicaciones de nueva unión que dependen de la biblioteca u otro recurso que ha cambiado.

Sistema Hustrativo para Instalar y Cargar una Aplicación al Generar Código Nativo a partir de Código en un MDIL La Figura 1 es un diagrama que ilustra un proveedor/mercado en línea ilustrativo y dispositivo de cómputo ilustrativo 100 que carga una imagen nativa 1 10 de una aplicación instalada al unir el código MDI L 120. En la Figura 1 , el código preliminar 130 para la aplicación se recibe por un proveedor en línea 140. Por ejemplo, el código preliminar 130 puede ser un código para la aplicación que es código de fuente o código en un lenguaje intermediario tal como Lenguaje intermediario de Microsoft (MSI L). En 1 35, el código preliminar se proporciona a un recopilador 150 que recopila el código preliminar 130 en el código MDI L 120 para la aplicación. El código preliminar 130 puede ser una representación de nivel superior del código para la aplicación al código MDI L 120. Por ejemplo, el código preliminar 130 está en un lenguaje intermediario (I L) que está a un nivel superior al código MDIL 120, que está en un nivel más cercano al código de máquma. El código MDI L 120 puede ser dependiente de máquina de manera que incluya un código nativo que se basa en un grupo de instrucción de procesador. El grupo de instrucción de procesador puede ser un grupo de instrucción para un procesador ARM, un procesador x86, u otro procesador. El código M DIL 120 también puede incluir pseudo-instrucciones no resueltas con referencias simbólicas que pueden resolverse para generar un código nativo a través de unión.

El código MDI L 120 para la aplicación se recibe en el dispositivo de cómputo 100. Como parte de instalación de la aplicación, se proporciona el código MDI L 120 a una carpeta 160 que une el código MDI L 120 a una o más bibliotecas 170 en el dispositivo. La una o más bibliotecas 170 pueden ser bibliotecas de código y/o bibliotecas de estructura para clases, tipos, o similares. Al unir el código MDI L 120 en el dispositivo de cómputo 100, la carpeta 160 genera la imagen nativa 1 10 de la aplicación. La imagen nativa 1 10 incluye un código nativo para la aplicación y se almacena en el dispositivo. En 180, la imagen nativa es cargada para ejecutar la aplicación.

Método Hustrativo para Unir Código MDIL para Instalar una Aplicación en un Dispositivo de Cómputo La Figura 2 es un diagrama de flujo de un método ilustrativo 200 para unir código MDI L de una aplicación para instalar la aplicación en un dispositivo de cómputo. En varias modalidades, los bloques de método ilustrados de la Figura 2 pueden fusionarse, dividirse en sub-bloques, u omitirse.

En la Figura 2, un dispositivo de cómputo recibe el código MDI L para la aplicación desde un proveedor en línea 210. Por ejemplo, el dispositivo de cómputo puede recibir uno o más archivos que incluyen código para la aplicación, en donde el código es un I L que es dependiente de máquma tal como un Lenguaje intermediario Dependiente de Máquina como se describió en la Publicación de Solicitud de Patente de E. U.A. No. : US 201 1 /0258615 y otro lenguaje intermediario dependiente de máquina. Ya que el código MDI L se recibe en el dispositivo de cómputo desde el proveedor en línea, el código MDIL puede generarse a partir de recopilación por el proveedor en línea o en otra parte en la nube. Por ejemplo, el proveedor en línea recopila código preliminar para que la aplicación genere el código MDI L para la aplicación.

En algunas ¡mplementaciones, un paquete de instalación para la aplicación se recibe y el paquete de instalación incluye un código MDIL para la aplicación. El paquete de instalación para una aplicación puede incluir otra información para la aplicación tal como archivos de recursos para la aplicación. El código MDIL para una aplicación puede almacenarse en el dispositivo de cómputo para instalación de la aplicación y para actualización subsecuente de la aplicación.

En 220, se instala la aplicación en el dispositivo de cómputo al generar una imagen nativa para la aplicación, que incluye enlazar el código MDI L de la aplicación. Por ejemplo, una carpeta puede unir el código MDIL a una o más bibliotecas disponibles en el dispositivo de cómputo para generar una imagen nativa para la aplicación que es ejecutable. La aplicación puede ser una aplicación manejada y ejecutada utilizando un procesador de tiempo de ejecución o ejecución tal como el Tiempo de ejecución de Lenguaje Común de la estructura . NET, u otro procesador de tiempo de ejecución. Un procesador de tiempo de ejecución y/o procesador de ejecución puede ser una capa de software en la cual se ejecuta finalmente la aplicación. En algunas implementaciones, una aplicación manejada es una aplicación que se ejecuta utilizando una estructura que incluye una o más bibliotecas compartidas y uno o más am bientes de tiempo de ejecución de código manejados. Por ejemplo, las bibliotecas son bibliotecas de clase base que son compartidas entre aplicaciones. En algunas aplicaciones, una biblioteca en un dispositivo de cómputo puede ser una imagen de la biblioteca que está en código nativo y/o de máquma, que puede cargarse en memoria para uso por una aplicación manejada que tambien está cargada en la memoria. En algunas implementaciones, la imagen nativa generada puede ser generada por una carpeta de manera que la imagen nativa se pueda ejecutar por un procesador de tiempo de ejecución o ejecución que se utiliza para ejecutar la aplicación en el dispositivo de cómputo. Por ejemplo, la carpeta puede utilizar y/o hacer referencia al procesador de tiempo de ejecución para la aplicación durante unión a la unión que es apropiada para ejecución utilizando el procesador de tiempo de ejecución.

En algunas im plementaciones, la unión , de la carpeta, resuelve el código MDIL y generar código nativo para la aplicación que se incluye en la imagen nativa para la aplicación . El código nativo puede ser código de máquma que es ejecutable en un procesador particular y que utiliza instrucciones desde un conjunto de instrucción de procesador. El conjunto de instrucción de procesador puede ser un conjunto de instrucción para un procesador ARM , un procesador x86, u otro procesador. En algunas modalidades, al generar la imagen nativa, para cada archivo M DIL en el conjunto de archivos recibidos para la aplicación, el archivo MDIL es respectivo y una o más bibliotecas que están unidas al código MDI L del archivo se proporcionan a la carpeta. Por ejemplo, una o más trayectorias de archivo a archivos MDI L y/o archivos de biblioteca pueden proporcionarse a la carpeta. La carpeta une los archivos MDI L respectivos a las bibliotecas proporcionadas a la carpeta para generar la imagen nativa para la aplicación. La imagen nativa puede incluir código nativo tal como código de máquma que es ejecutable por el procesador del dispositivo de cómputo. (Además de la imagen nativa, al menos algo de código para la aplicación puede mantenerse en una forma IL, para recopilación justo a tiempo u otra recopilación antes que se inicie la aplicación o cuando se inicia la aplicación. Esto puede ser útil cuando los recursos cambian frecuentemente, o cuando un valor u otra referencia no pueda resolverse cuando la aplicación está instaladas y el código MDI L restante está unido a bibliotecas en el dispositivo).

En algunas implementaciones, la aplicación puede ser instalada en el dispositivo por un administrador de paquete. Por ejemplo, durante la instalación de la aplicación, un paquete de instalación recibido para la aplicación puede desempacarse por un administrador de paquete. Si el paquete de instalación y/o uno o más de los archivos incluidos en el paquete de instalación se comprimen , entonces el administrador de paquete puede descomprimir tales archivos. Si uno o más archivos no se comprimen entonces el administrador de paquete no descomprime tales archivos. El administrador de paquete puede proporcionar cada uno de los archivos MDI L que se van a unir a la carpeta junto con las bibliotecas que se van a unir a los archivos MDI L respectivos. En algunas implementaciones, el administrador de paquete proporciona los archivos MDI L y/o una o más bibliotecas al proporcionar referencias a los archivos MDI L y/o una o más bibliotecas a la carpeta. La carpeta une los archivos MDI L respectivos a las bibliotecas proporcionadas para los archivos MDI L respectivos para generar la imagen nativa de la aplicación. La imagen nativa puede ser generada por la carpeta de manera que la imagen nativa se puede ejecutar utilizando el procesador de tiempo de ejecución disponible en el dispositivo de cómputo para ejecutar la aplicación.

En 230, la imagen nativa de la aplicación se almacena en el dispositivo de cómputo para usarse cuando se carga la aplicación para ejecución. Por ejemplo, la imagen nativa generada se carga para ejecutar la aplicación (y el código MDI L que no es ejecutable no se utiliza para ejecutar la aplicación). En algunas implementaciones, se determina la imagen nativa como siendo confiada antes de cargarse pare ejecución. En otras implementaciones, el dispositivo de cómputo no hace ninguna determinación sobre si la imagen nativa es confiada antes que se cargue la imagen nativa pare ejecución .

Sistema Hustrativo para Generar Código Nativo a partir de un Código MDI L para Instalación y Ejecución de Aplicación La Figura 3 es un diagrama que ilustra un proveedor/mercado en línea ilustrativo y dispositivo de cómputo ilustrativo 350 que puede instalar una o más aplicaciones manejadas al generar una o más imágenes nativas a partir de código en un lenguaje intermediario tal como un MDI L que se proporciona y genera por el proveedor en línea (u otros proveedores en línea). En la Figura 3, un proveedor en línea 305 utiliza un recopilador 310 para recopilar código preliminar 315 en uno o más archivos MDI L 320, que son archivos que incluyen código en un MDIL. El conjunto de uno o más archivos MDIL 320 se empacan en un paquete de instalación 325 para la aplicación. Cada uno de los archivos MDI L puede firmarse como siendo confiado, como se muestra en 330. Uno o más archivos 335 que incluyen información de soporte tal como archivos de recurso o contenido de aplicación pueden incluirse en el paquete de instalación 325. El paquete de instalación 325 es almacenado por el proveedor en línea 305 y se ofrece para descarga, como se muestran 340. Antes que se descargue el paquete de instalación 325 del proveedor en línea 305, el m ismo paquete de instalación 325 puede ser firmado, confiado, como se muestra en 345.

De esa forma, se ofrece el paquete de instalación 325 como parte de un catálogo de aplicaciones en un mercado en línea. Pueden ofrecerse diferentes versiones de paquete de instalación 325 para diferentes tipos de dispositivos de cómputo. Por ejemplo, se incluyen diferentes tipos de código MDI L (adaptados para diferentes tipos de procesadores) en diferentes paquetes de instalación para los diferentes tipos de dispositivos de cómputo. Los paquetes de instalación disponibles para diferentes tipos de dispositivos de cómputo tambien pueden incluir una versión con código no M DI L (por ejemplo, código MSI L en un archivo XAP) para propósitos de compatibilidad con versiones anteriores.

El dispositivo de cómputo 350 descarga uno o más paquetes de instalación, incluyendo el paquete de instalación 325, del proveedor en línea 355. Como parte de instalar la aplicación, el administrador de paquete 360 y el dispositivo de cómputo 350 desempaca uno o más archivos MDI L 320 y uno o más archivos 335 que incluyen información de soporte para la aplicación . El administrador de paquete también invoca una carpeta 365. Para cada archivo MDI L del grupo de uno o más archivos MDI L 320, el administrador de paquete 360 proporciona el archivo MDI L respectivo tal como archivo MDI L 322 a la carpeta 365 junto con una o más bibliotecas que se van a unir con el archivo MDI L respectivo, tal como una o más bibliotecas 370. La carpeta 365 une el archivo MDI L respectivo a una o más bibliotecas proporcionadas para el archivo MDI L respectivo para generar el código nativo. Las bibliotecas proporcionadas para los archivos MDI L (tal como una o más bibliotecas 370) se incluyen en el grupo de bibliotecas 375 que están en el dispositivo de cómputo 350. Al utilizar el código nativo generado para unir el uno o más archivos MDIL 320, la carpeta genera una imagen nativa 380 para la aplicación. La imagen nativa 380 puede generarse por la carpeta 365 de manera que la imagen nativa 380 se puede ejecutar utilizando un procesador de tiempo de ejecución en el dispositivo de cómputo que puede ejecutar la aplicación. La imagen nativa 380 es almacenada como parte de instalar la aplicación en el dispositivo, como se muestra en 385. El dispositivo de cómputo 350 también puede instalar una o más de otras aplicaciones y almacenar imágenes nativas generadas correspondientes a otras aplicaciones respectivas.

Como se muestra en 390, la imagen nativa 380 puede ser firmada como código confiado que se generó a partir de código confiado por la carpeta 365. La imagen nativa 380 puede ser firmada antes que se almacene y/o cargue para uso al ejecutar la aplicación. En 395, la imagen nativa 380 es cargada para ejecutar la aplicación. Cuando se carga, el código nativo de la imagen nativa se ejecuta por el dispositivo de cómputo 305 para proporcionar la funcionalidad de la aplicación.

Método I lustrativo para I nstalar y actualizar una Aplicación a través de la Generación de Código Nativo Utilizando Código en un M DIL La Figura 4 es un diagrama flujo de un método ilustrativo 400 para instalar y actualizar una aplicación a través de generación de código nativo utilizando código en un MDI L. En la Figura 4, como se muestra en 410, se genera un paquete de instalación que incluye código MDI L. En algunas implementaciones, el código MDI L puede incluirse en uno o más archivos. En algunas implementaciones, puede recopilarse código preliminar para generar el código MDIL.

En algunas implementaciones, el código MDI L para la aplicación incluye código nativo basado en conjunto de instrucción de procesador, pero también puede incluir pseudo-instrucciones. Por ejemplo, una pseudo-instrucción incluye una referencia simbólica y/o clave de campo que no puede resolverse cuando se genera el MDI L. De esa forma, en algunas implementaciones, pseudo-instrucciones pueden incluir referencias simbólicas a campos, tipos, o similares. Por ejemplo, la referencia simbólica pueden ser señales que identifican un campo o un tipo que se va a utilizar sin indicar específicamente el desplazamiento de campo o un tamaño de tipo. En algunas implementaciones, una referencia simbólica puede ser un símbolo que puede ser interpretado por una carpeta para determinar código nativo que se va a generar para la referencia simbólica. Por ejemplo, un símbolo tal como un símbolo de campo que hace referencia a un campo de un objeto, una carpeta en un dispositivo de cómputo particular puede ( 1 ) disponer el objeto como está disponible en el dispositivo de cómputo a través de la biblioteca y (2) determ inar el desplazamiento apropiado para el campo del objeto, cuando genera instrucciones ejecutables para el dispositivo de cómputo. De esa forma, en algunas implementaciones, los desplazamientos de campo para objetos en código MDI L pueden ser simbólicos en lugar de codificados como un desplazamiento numérico (tal como en un código nativo correspondiente).

La pseudo-instrucción puede abstraer detalles de implementación que se van a determinar y/o resolver cuando la pseudo-instrucción está unida a una biblioteca apropiada en un dispositivo de cómputo. En algunas implementaciones, código MDI L incluye pseudo-instrucciones que incluye referencias simbólicas que pueden convertirse por una carpeta para producir instrucciones nativas que son ejecutables por un procesador. Por ejemplo, el código MDI L puede incluir pseudo-instrucciones que pueden convertirse por una carpeta en instrucciones de máquma para acceder a un campo de un objeto que se maneja por un procesador de tiempo de ejecución tal como el Tiempo de ejecución de Lenguaje Común (CLR) de la estructura . N ET o similares. En algunas implementaciones, las pseudo-instrucciones en el código MDI L pueden ser sim ilares a código de máquma en un lenguaje nativo de manera que los registros ya esten distribuidos pero los desplazamientos no están incluidos para una o más bibliotecas y/o clases. Por ejemplo, el desplazamiento de campo incluido en una instrucción nativa como convertido de la pseudo-instrucción puede determinarse por una carpeta y puede depender de una versión de una biblioteca disponible y/o en un dispositivo de cómputo. En algunas implementaciones, el código MDI L puede incluir pseudo-instrucciones que pueden cubrirse por una carpeta en instrucciones de máquina para buscar un inicio o caso de un tipo o método genérico.

Con referencia a la Figura 4, en 420, un dispositivo de cómputo recibe el código MDI L para una aplicación. Por ejem plo, el dispositivo de cómputo puede recibir un paquete de instalación para la aplicación que incluye archivos MDI L que pueden incluir el código MDIL para la aplicación. En algunas implementaciones, el paquete de instalación puede incluir una lista de unión que incluye una lista de los archivos MDI L de la aplicación que se unen para generar una imagen nativa para la aplicación y listado del conjunto de una o más bibliotecas que se van a unir a los archivos MDI L respectivos. En algunas implementaciones, una o más de las bibliotecas que se van a unir al código MDIL de una aplicación son bibliotecas que se declaran y/o incluyen en el código de fuente de la aplicación . Una o más de otras bibliotecas se van a unir al código MDI L de una aplicación que pueden ser bibliotecas que no se declaran y/o incluyen en el código de fuente de la aplicación.

En 430, la aplicación es instalada en el dispositivo de cómputo al generar una imagen nativa para la aplicación. En algunas implementaciones, la aplicación puede ser instalada por un administrador de paquete. Por ejemplo, el administrador de paquete puede determinar que el paquete de instalación es firmado como confiado antes que utilice sus archivos para instalar la aplicación en el dispositivo de cómputo. Si el paquete de instalación no es firmado como confiado, el administrador de paquete no utiliza el paquete de instalación para instalar la aplicación en el dispositivo de cómputo. El administrador de paquete puede proporcionar cada uno de los archivos MDI L que están unidos a la carpeta junto con las bibliotecas que van a estar unidas a los archivos MDI L respectivos. En algunas implementaciones, en lugar o además de determinar si todo el paquete de instalación es firmado como confiado, los archivos MDI L pueden ser determinados para ser firmados como confiados antes de utilizarse para generar una imagen nativa para la aplicación, y archivos M DI L que se determina que no son firmados como confiados no se utilizan para generar una imagen nativa para la aplicación. En algunas implementaciones, el administrador de paquete puede proporcionarse y utilizar una lista de unión para determinar automáticamente identificar los archivos MDI L que van estar unidos y las biblioteca respectivas que van a estar unidas al código de los archivos MDI L respectivos para la aplicación . La lista de unión puede ser un formato legible por máquma tal como en lenguaje de programación, unión, o marcación. Por ejemplo, la lista de unión puede ser incluida en un archivo que incluye información realizada utilizando el Lenguaje de Marcación Extensible (XML).

En algunas simplemente implementaciones, el administrador de paquete proporciona los archivos MDIL y/o una o más bibliotecas a la carpeta al proporcionar referencias a los archivos MDIL y/o una o más bibliotecas a la carpeta. La carpeta une los archivos MDI L respectivos a las bibliotecas proporcionadas para los archivos MDI L respectivos para generar la imagen nativa de la aplicación. En un nivel alto, la carpeta lee instrucciones MDIL, convierte instrucciones IL a instrucciones nativas, y pasa a través de instrucciones que ya están en forma nativa. Por ejemplo, una carpeta puede unir el código MDIL a una o más bibliotecas en el dispositivo de cómputo para generar una imagen nativa para la aplicación que es ejecutable. La imagen nativa puede ser generada por la carpeta de manera que la imagen nativa se puede ejecutar utilizando el procesador o tipo de ejecución en el dispositivo de cómputo, que está disponible para la carpeta, que está ejecutando la aplicación. El procesador de tiempo de ejecución puede ser una capa de software que puede finalmente ejecutar la aplicación en el dispositivo de cómputo. En algunas implementaciones, la carpeta puede estar ejecutándose utilizando información de unión, entrada de usuario y/u otra información. En algunas implementaciones de código de unión, el código MDI L es proporcionada a la carpeta. La carpeta resuelve las pseudo-instrucciones para generar instrucciones nativas correspondientes. Por ejemplo, para referencias simbólicas (por ejemplo, símbolo tomado) en pseudo-instrucciones, la carpeta puede generar código nativo al determinar y especificar desplazamientos numéricos para campos basándose en diseño de tipo. En algunas implementaciones, las pseudo-instrucciones de MDI L pueden utilizarse para crear instrucciones nativas que pueden diferir en longitudes de pseudo-instrucciones. Alternativamente, las instrucciones nativas pueden no diferir en long itud de las pseudo-instrucciones. En algunas implementaciones, al menos algo del código MDIL para una aplicación puede estar cerca del código de máquma incluido en una imagen nativa de la aplicación ; sin embargo, otras partes del código MDIL pueden proporcionar un nivel de abstracción que muestra una porción del código MDI L para estar unido a una biblioteca que puede estar disponible en una o más versiones. A través de unión, el código MDI L puede utilizarse para generar código ejecutable que se ejecuta utilizando una versión particular de la biblioteca. Por ejemplo, unir código MDI L a un grupo de bibliotecas puede generar código ejecutable para la aplicación o, unir el código MDI L al grupo de bibliotecas con una o más de las bibliotecas siendo de diferente versión también puede generar código ejecutable para la aplicación . Los grupos de versiones de una o más bibliotecas pueden tener versiones que se traslapan de bibliotecas.

En algunas implementaciones, unir código MDI L genera código que puede ser directamente ejecutado por un procesador sin recopilación adicional . Por ejemplo, unir código MDI L a una biblioteca incluye generar una instrucción nativa de una instrucción en el código MDIL. En algunas implementaciones, el código MDIL incluye pseudo-instrucciones que incluyen referencias simbólicas que son convertidas y/o unidas por una carpeta para producir instrucciones nativas que son ejecutables por un procesador. Por ejemplo, una carpeta puede convertir pseudo-instrucciones en instrucciones de código nativo para acceder a un campo de un objeto que puede ser manejado por un procesador de tiempo de ejecución en el dispositivo de cómputo. En algunas implementaciones, partes del código MDIL pueden ser similares al código nativo generado de manera que se distribuyen registros, pero en el código MDI L no se han incluido desplazamientos para una o más bibliotecas y/o clases.

En algunas implementaciones, una carpeta puede convertir las pseudo-instrucciones en instrucciones de código nativo para buscar un ejemplo o caso de un tipo o método genérico.

En algunas implementaciones, las instrucciones simbólicas de código MDI L y las instrucciones nativas correspondientes generadas son consistentes con respecto a asignación de ranura de método virtual y/o diseño de campo de objeto. Por ejemplo, el código M DIL y el código nativo ejecutable pueden ser consistentes con respecto al diseño de campo de objeto, de manera que una porción de código MDIL para acceder a objetos que incluye un símbolo de campo pueden utilizarse para generar instrucciones nativas (por ejemplo, instrucciones de máquma) utilizando desplazamientos de campo. En algunas im plementaciones, la carpeta puede generar un desplazamiento numérico de una referencia simbólica para generar una o más instrucciones de máquina ejecutables. Por ejemplo, una referencia simbólica en el código MDIL se convierte por una carpeta en una referencia de campo específica de manera que la referencia de campo específica incluya un tamaño y/o desplazam iento numérico.

En algunas implementaciones para unir código MDIL, una carpeta puede interpretar una referencia simbólica que incluye un sím bolo para determinar código nativo que va a ser generado para la referencia simbólica. Por ejemplo, para un símbolo de campo que hace referencia a un campo de un objeto, la carpeta puede disponer el objeto ya que puede estar disponible en el dispositivo de cóm puto y terminar el desplazamiento apropiado para el campo el objeto para generar instrucciones ejecutables para el dispositivo de cómputo. En algunas implementaciones de código MDIL de unión, una carpeta puede unir código MDI L que es más complicado que un enlazador. Por ejemplo, al unir código MDI L, la carpeta puede ajustar uno o más altos en código nativo resultante de manera que los altos están a sus objetivos deseados.

Además del código nativo en la imagen nativa, al menos algo del código para la aplicación puede mantenerse en una forma I L. El código en forma I L se procesa adicionalmente durante la recopilación justo a tiempo u otra recopilación antes que se inicie la aplicación o cuando se inicia la aplicación. Esto puede ser útil cuando un procesador de tiempo de ejecución, una biblioteca, u otro recurso cambia frecuentemente. O puede ser útil cuando un valor o referencia de tipo no puede resolverse durante proceso de unión en donde el código MDIL restante se une a bibliotecas en el dispositivo de cómputo.

En 440, la imagen nativa es almacenada para usarse cuando se carga la aplicación para ejecución. Por ejemplo, cuando un usuario inicia la aplicación en el dispositivo de cómputo, la imagen nativa de la aplicación se carga por un procesador de ejecución y tiempo de ejecución tal como CLR de la estructura . N ET u otro procesador de tiempo de ejecución. En algunas implementaciones, el dispositivo de cómputo puede incluir código MS I L para la aplicación que puede ser recopilado en el dispositivo de cómputo utilizando recopilación justo a tiempo para ejecutar la aplicación, pero en lugar de ejecutar la aplicación utilizando el código MSI L, la imagen nativa para la aplicación se carga o ejecuta para ejecutar la aplicación. En algunas implementaciones, cuando se carga imagen nativa, una o más imágenes o ensambles de biblioteca se cargan y se utilizan por el código de la aplicación como se incluyó en la imagen nativa. Por ejemplo, la imagen nativa puede cargarse para ejecución utilizando un procesador de tiempo de ejecución del dispositivo de cómputo. La imagen nativa para la aplicación puede firmarse por la carpeta antes de almacenarse, para mostrar que se confía en la aplicación.

En 450, el dispositivo de cómputo es actualizado al menos al actualizar un grupo de bibliotecas en el dispositivo de cómputo. Por ejemplo, una o más de las bibliotecas en el grupo de bibliotecas del dispositivo de cómputo pueden actualizarse, reemplazarse, o cambiarse. Esto puede alterar la operación de aplicaciones que se unieron a una versión previa del grupo de bibliotecas. De esa forma, después que se actualizan, reemplazan, o cambian una o más bibliotecas, pueden actualizarse una o más de las aplicaciones en el dispositivo de cómputo de manera que una imagen nativa actualizada para aplicaciones respectivas puede generarse. Una imagen nativa actualizada para una aplicación puede generarse al unir código MDI L para la aplicación (que se almacena en forma MDIL en el dispositivo de cómputo incluso después de instalación) al menos a uno del grupo de una o más bibliotecas que se actualizaron. La re-unión del código MDIL para la aplicación a una o más de las bibliotecas en el dispositivo de cómputo después que se actualizaron bibliotecas puede permitir imágenes nativas para hacer referencia apropiadamente a una o más bibliotecas como están disponibles en el dispositivo de cómputo después de actualizar el dispositivo y/o actualizar bibliotecas del dispositivo. Al mismo tiempo, completar la re-recopilación de código para una aplicación no es necesario cada vez que una biblioteca cambia, ya que el código MDI L para la aplicación puede utilizarse. Cuando se utiliza la biblioteca cambiada por muchas de las aplicaciones en un dispositivo, la re-unión utilizando código MDI L previamente almacenado para las aplicaciones respectivas puede simplificar ampliamente el proceso de actualizar imágenes nativas para las aplicaciones respectivas.

Por ejemplo, suponer que cada una de siete aplicaciones tiene una dependencia en una biblioteca que ha sido cambiada. Para cada una de las siete aplicaciones, la recopilación fuera de línea en la nube (por ejemplo, por un proveedor en línea) puede producir código MDI L eficiente para esa aplicación, utilizando recopilación que es más sofisticada y/o lenta que recopilación justo a tiempo o recopilación de un dispositivo para propósitos de actualización. En lugar de recopilar cada una de las siete aplicaciones cuando la biblioteca cambia, lo que sería lento y de llevar a una imagen nativa menos eficiente, las aplicaciones respectivas se vuelven a unir a bibliotecas en el dispositivo de cómputo, lo que es mucho más fácil que la “elevación pesada" en la optimización de recopilación que se realizó previamente en la nube.

En algunas implementaciones, el dispositivo de cómputo es actualizado de manera que la actualización incluye actualizar un procesador de tiempo de ejecución del dispositivo de cómputo. Por ejemplo, el procesador de tiempo de ejecución, del dispositivo de cómputo, que ejecuta una o más aplicaciones instaladas utilizando imagines nativas para las aplicaciones puede actualizarse, reemplazarse, o cambiar. El procesador de tiempo de ejecución puede ser la capa de software que finalmente ejecuta una aplicación actualizada de manera que cuando se cambia el procesador de tiempo de ejecución una imagen nativa actualizada para una aplicación actualizada puede generarse por una carpeta que va a ser ejecutable utilizando el procesador de tiempo de ejecución actualizado como disponible a la carpeta y en el dispositivo de cómputo. En algunas implementaciones, tanto un procesador de ejecución como bibliotecas del dispositivo de cóm puto cambian con una actualización de dispositivo y una aplicación puede actualizarse de manera que pueda ejecutarse y/o ejecutarse apropiadamente, el procesador de tiempo de ejecución actualizable y bibliotecas actualizadas.

Metodo Hustrativo para Generar un Paquete de Instalación para una Aplicación que Puede Proporcionarse para Descarga La Figura 5 es un método ilustrativo 500 para generar un paquete de instalación para una aplicación que puede proporcionarse para descarga. En varias implementaciones, los bloques de método ilustrados de la Figura 5 pueden fusionarse, dividirse en sub bloques, u omitirse. En la Figura 5, el código preliminar para una aplicación es recibido. Por ejemplo, un desarrollador de una aplicación puede enviar código para la aplicación en un lenguaje y/o estado preliminar, y el código preliminar para aplicación puede recibirse por un proveedor en línea tal como un mercado en línea. En algunas implementaciones, el código preliminar para la aplicación es código de fuente para la aplicación. Por ejem plo, el código de fuente puede ser código escrito en uno o más lenguajes de programación tal como C + + , C#, Visual Basic®, J#, J + + , u otros lenguajes de programación similares. En algunas im plementaciones, el código preliminar para aplicación está en una representación intermedia tal como en un I L. Por ejemplo, el código de fuente para la aplicación puede recopilarse por un recopilador y/o un generador en una representación intermedia en un I L. En algunas implementaciones, el IL puede estar en Lenguaje intermediario de Microsoft (MS I L, según siglas en inglés). En algunas implementaciones, el I L no incluye instrucciones nativas que son dependientes de máquma. El código en IL puede ser recopilado, sin embargo, en código en un MDI L que incluye instrucciones nativas que son dependientes de máquina.

En algunas implementaciones, se recibe otra información para la aplicación así como el código preliminar para la aplicación . Por ejemplo, archivos de recurso para la aplicación pueden recibirse y se utilizan por la aplicación cuando se ejecutan. Archivos de recurso para aplicaciones pueden ser uno o más archivos que incluyen información de sonido, información de música, información de gráficos, información de video, otra información de medios, información de base de datos, información de texto, y similares. En algunas implementaciones, el código preliminar puede ser empacado en y/o recibido en uno o más archivos comprimidos tales como un archivo ZI P o un archivo XAP. Alternativamente, el código prelim inar no está empacado en y/o recibido en uno o más archivos comprimidos. En algunas implementaciones, uno o más archivos con código MDI L para la aplicación se reciben por el proveedor en línea, pero los archivos MDIL recibidos del desarrollador pueden desecharse como archivos no confiados que no se generaron por el proveedor en l ínea. Alternativamente, el proveedor en línea no descarta ninguno de los archivos MDIL recibidos por el proveedor en l ínea. En algunas implementaciones, el código preliminar puede recibirse en uno o más ensambles. Por ejemplo, el código prelim inar (tal como código en MSI L incluido en un ensamble) puede recopilarse en código que está a un nivel binario. Un ensamble que incluye código MSI L puede ser un ensamble MSI L. En algunas implementaciones, un ensamble MSI L puede comprender uno o más archivos.

En 520, el código preliminar de la aplicación se recopila para producir código MDI L que es un código que está en un lenguaje intermediario que es dependiente de máquma. Como una regla general, decisiones y referencias dentro de un archivo I L se resuelven durante el proceso de recopilación, pero decisiones o referencias a una biblioteca, fuente externa, tipo externo, etc. , se dejan sin resolver. El archivo MDI L de esa forma es una mezcla de (a) instrucciones de ensamble, código nativo u otras instrucciones dependientes de dispositivo y (b) instrucciones de pseudocódigo u otras instrucciones independientes de dispositivo que se van a resolver posteriormente. De esa forma, el código MDI L recopilado del código preliminar puede estar en lenguaje intermediario que es un lenguaje de nivel inferior al lenguaje del código preliminar. Por ejemplo, el código preliminar está en un lenguaje intermediario que está en un nivel superior (más allá del código de máquina), y el código MDI L está en un nivel inferior que está más cerca del código de máquma. I ncluso asi, el código MDI L típicamente no es directamente ejecutable sin estar unido, debido a que el código MDI L incluye referencias simbólicas que no son código nativo. En lugar de esto, el código MDI L puede convertirse a código de máquina ejecutable por una carpeta. En algunas implementaciones, el código preliminar para la aplicación no es directamente ejecutable pero puede ser recopilado en código ejecutable cuando se recopila por un recopilado justo a tiempo. Por ejemplo, el código para la aplicación en MSI L puede ser recopilado justo a tiempo para ejecutar la aplicación desde el código MSI L. En algunas implementaciones, el código para una aplicación en MSIL puede proporcionarse a un recopilado para generar código MDIL para la aplicación.

Típicamente, el código MSIL no incluye instrucciones nativas, ni incluye las pseudo-instrucciones incluidas en el código MDIL que se resuelven y/o unen por una carpeta para generar código nativo para la aplicación.

El código MDI L puede ser incluido en uno o más archivos MDI L. En algunas implementaciones, un archivo MDIL puede ser un nombre y/o extensión de archivo tal como “. mdil” que se incluye en el nombre y/o extensión de archivo del archivo MDI L. En otras implementaciones, un archivo MDI L puede tener otra convención de nombre, de manera que " . mdil” no se incluye en el nombre y/o extensión de archivo del archivo MDI L.

En algunas implementaciones, cuando se recopila el código preliminar, además de pseudo-instrucciones, el recopilador produce uno o más ensambles para el código M DI L. Por ejemplo, código MDI L incluido en un ensam ble puede ser recopilado en código que está en un nivel binario. Un ensamble que incluye código MDI L puede ser un ensamble MDI L. En algunas implementaciones, un ensamble MDI L puede comprender uno o más archivos.

La recopilación del código preliminar en código MDI L para la aplicación antes que se reciba el código de aplicación en un dispositivo de cómputo objetivo (en el cual se va a ejecutar la aplicación) puede proporcionar varias ventajas. Por ejemplo, el tiempo de recopilación puede removerse del tiempo que toma instalar la aplicación en el dispositivo de cómputo objetivo. La remoción de la recopilación de la instalación de la aplicación en el dispositivo objetivo también puede permitir que se realicen optimizaciones de tipo de recopilación del código en la nube, sin que se agregue tiempo al tiempo que toma instalar la aplicación en un dispositivo objetivo. En particular, esto puede ayudar a evitar una recopilación lenta en el dispositivo de cómputo objetivo para múltiples aplicaciones que dependen de una biblioteca en cualquier momento que se cambia la biblioteca y/o cuando se cambia un procesador de tiempo de ejecución.

En algunas implementaciones, la recopilación del código preliminar puede producir uno o más archivos de código nativo para la aplicación que puede incluir código nativo para la aplicación y no incluir código MDIL.

En algunas implementaciones, para cada archivo de ensamble MSIL recibido para la aplicación se genera un archivo MDI L correspondiente por un recopilador. El código preliminar puede ser recopilado para generar un código MDI L que es dependiente de un grupo de instrucción para un primer procesador (para un primer tipo de dispositivo de cómputo objetivo), y diferente código MDI L puede generarse y es dependiente de un grupo de instrucción para un segundo procesador (para un segundo tipo de dispositivo de cómputo objetivo). Por ejemplo, la recopilación de un código preliminar para una aplicación puede producir un código MDI L que puede estar unido para ejecutar un dispositivo que tiene un primer procesador, y producir diferente código MDI L para la aplicación que puede unirse para ejecutar en otro dispositivo con diferente segundo procesador. Por ejemplo, el primer procesador puede ser un procesador ARM y el segundo procesador puede ser un procesador x86.

En 530, el código MDI L de la aplicación se firma como confiado. Por ejemplo, los archivos de código M DI L generados del código preliminar pueden firmarse con una clave de editor para indicar que los archivos firmados incluyen código confiado. En algunas implementaciones, el código nativo generado al recopilar código preliminar puede firmarse como confiado. Por ejemplo, los archivos de código nativo que se generan por un recopilador pueden firmarse con una clave de editor para indicar que los archivos firmados incluyen código confiado.

En 540, se genera un paquete de instalación que incluye el código MDI L. Por ejemplo, el código M DI L puede empacarse en un contenedor tal como uno o más archivos que pueden descargarse para instalar la aplicación. En una implementación, el código MDI L en uno o más archivos de código MDI L se empacan en uno o más archivos comprimidos tal como un archivo ZI P o un archivo XAP. Un paquete de instalación comprimido puede disminuir la cantidad de datos que se van a descargar para la aplicación de un proveedor en línea. Alternativamente, el paquete de instalación no está en una forma comprimida. Diferentes tipos de código M DI L (adaptados para diferentes tipos de procesador) pueden incluirse en diferentes paquetes de instalación para diferentes tipos de dispositivos de cómputo. Los paquetes de instalación disponibles para diferentes tipos de dispositivos de cómputo tambien pueden incluir una versión con código no MDI L (por ejemplo, código MSI L en un archivo XAP) para propósitos de compatibilidad con versiones anteriores.

En algunas implementaciones, el paquete de instalación puede incluir otra información para la aplicación tal como archivos de recurso para la aplicación. Por ejemplo, archivos de recurso para la aplicación pueden recibirse y pueden utilizarse por la aplicación cuando se ejecuta. Los archivos de recurso para aplicaciones pueden ser uno o más archivos que incluyen información de sonido, información de música, información de gráficos, información de video, otra información de medios, información de base de datos, información de texto, y sim ilares. El paquete de instalación también puede incluir una lista de archivos que se incluyen en la página de instalación. La lista de archivos puede incluir información sobre los archivos incluidos en el paquete de instalación. Por ejemplo, el paquete de instalación puede incluir un archivo que incluye información organizada utilizando Lenguaje de Marcación Extensible (XML). El archivo XML puede incluir una lista de los archivos que son incluidos en la página de instalación. Para cada uno de los archivos enlistados, el archivo XML puede incluir información asociada con el listado. Por ejemplo, el archivo XML puede enlistar cada uno de los archivos de código MDI L incluidos en el paquete de instalación e indicar que cada uno de los archivos de código MDI L es capaz de unirse. El archivo XML puede indicar también una o más bibliotecas que están unidas al código de archivos de código MDI L enlistados respectivos.

En algunas implementaciones, el mismo paquete de instalación generado es firmado como confiado. Por ejemplo, el paquete de instalación puede ser firmado con una clave de editor para indicar que incluye código y/u otra información que es confiada. En algunas implementaciones, el paquete de instalación puede ser codificado criptográficamente.

En 550, el paquete de instalación es proporcionado para descarga. Por ejemplo, el proveedor en línea y/o socio del proveedor en línea puede almacenar el paquete de instalación para descarga. El proveedor en l ínea puede ser un mercado en línea del cual puede descargarse una o más aplicaciones para instalación en uno o más dispositivos de cómputo. La aplicación puede incluirse en un catálogo de aplicaciones que están disponibles para descargar del mercado en línea. Por ejemplo, la aplicación puede ser descargada por un dispositivo de cómputo utilizando I nternet y/o la nube. La aplicación puede ser descargada de manera que el paquete de instalación para la aplicación se descargue. En algunas implementaciones, la aplicación puede ser descargada a un dispositivo de cómputo después que la aplicación ha sido comprada y autorizada para ser descargada del dispositivo de cómputo. En algunas implementaciones, la aplicación puede ser descargada sin ser comprada. Por ejemplo, la aplicación puede ser ofrecida y descargada gratis.

Sistema Hustrativo para Generar Imágenes Nativas Actualizadas para Aplicaciones Instaladas La Figura 6 es un diagrama de un dispositivo de cómputo 600 que puede generar una o más imágenes nativas actualizadas 605 para una o más aplicaciones instaladas. En la Figura 6, el dispositivo de cómputo incluye una o más imágenes nativas generadas 610 para la una o más aplicaciones instaladas en el dispositivo de cómputo. El dispositivo de cómputo 600 incluye bibliotecas actualizadas 620, que incluyen una o más bibliotecas que se actualizaron después de unirse a código MDIL respectivo en aplicaciones para generar una o más imágenes nativas 610. Debido a que al menos una de las bibliotecas que se unieron a una o más imágenes nativas 61 0 se actualizaron, el dispositivo de cómputo 600 actualiza las aplicaciones instaladas en ésta al generar la una o más imágenes nativas actualizadas 605 para las aplicaciones instaladas. El dispositivo de cómputo también incluye un procesador de tiempo de ejecución actualizado 670.

Al generar la una o más imágenes nativas actualizadas 605 para las aplicaciones instaladas, una carpeta 625 genera una imagen nativa actualizada para cada una o más aplicaciones instaladas. Como se muestra en la Figura 6, para cada aplicación instalada que tenga una imagen nativa que fue unida a por lo menos una biblioteca que ha sido cambiada y/o actualizada, el manejador de paquete 630 proporciona a la carpeta 625 los archivos MDI L de la aplicación respectiva para volver a unir para generar una imagen nativa actualizada para la aplicación que se está actualizando, tal como la imagen nativa actualizada 635. Las imágenes nativas actualizadas pueden ser generadas a través de la carpeta 625 de manera que las imágenes nativas son ejecutables utilizando el procesador de tiempo de ejecución actualizado 670.

Para generar la imagen nativa actualizada 635, para cada archivo MDIL para que se actualice la aplicación, la carpeta 625 se proporciona con el archivo MDI L respectivo de la aplicación tal como archivo MDI L 640 y una o más bibliotecas tal como una o más bibliotecas 645 que se van a unir al archivo MDI L. Una o más bibliotecas proporcionadas para unión al código de archivo MDI L pueden incluir al menos una biblioteca que ha sido actualizada y se incluye en el grupo de bibliotecas actualizadas 620. En algunas implementaciones, una o más bibliotecas unidas al código de un archivo MDI L de una aplicación que se actualiza no han sido actualizadas.

Cuando se genera, la imagen nativa actualizada para la aplicación, tal como la imagen nativa actualizada 635, se almacena como al menos una de una o más imágenes nativas actualizadas 605 para las aplicaciones instaladas en el dispositivo de cómputo. La imagen nativa actualizada tambien puede ser firmada como código confiado, como se muestra en 650, antes que se utilice la imagen nativa actualizada para ejecutar la aplicación. El 655, el dispositivo de cómputo carga una imagen nativa actualizada generada para que una aplicación ejecute la aplicación en lugar de la imagen nativa previamente generada para la aplicación.

Además de manejar actualizaciones para bibliotecas en el dispositivo, el dispositivo puede actualizar una aplicación cuando la aplicación ha cambiado (por ejemplo, código MDI L de la aplicación ha cambiado). En este caso, el dispositivo actualiza la aplicación al generar una imagen nativa actualizada para la aplicación, incluyendo unir la porción del código MDI L con una o más bibliotecas (sin cambios) en el dispositivo. La imagen nativa actualizada para la aplicación puede generarse por la carpeta de manera que las imágenes nativas se pueden ejecutar utilizando el procesador de tiempo de ejecución actualizado.

Como se muestra en 660, la imagen nativa previamente generada puede almacenarse temporalmente durante la generación de la imagen nativa actualizada y/o actualización del dispositivo de cómputo 600 hasta que se verifica la actualización de la aplicación y/o dispositivo de cómputo 600 como exitosa. Si la actualización del dispositivo de cómputo y/o a la aplicación falla, la imagen nativa previamente generada puede ser restaurada a partir de almacenam iento temporal y utilizarse de nuevo como la imagen nativa que se carga por el dispositivo de cómputo para ejecutar la aplicación.

Metodo Hustrativo para Actualizar una Aplicación a través de la Generación de Código Nativo Utilizando Código en un MDI L La Figura 7 es un método ilustrativo 700 para actualizar una aplicación al generar una imagen nativa para la aplicación desde el código en un MDI L. En varias implementaciones, los bloques del método ilustrado de la Figura 7 pueden fusionarse, dividirse en sub bloques, u omitirse. En la Figura 7, se actualiza un grupo de una o más bibliotecas en un dispositivo de cómputo, como se muestra en 710. Por ejemplo, una porción o todas de una o más bibliotecas en el dispositivo de cómputo cambian , se modifican, o de otra forma se actualizan. En algunas im plementaciones, el grupo de una o más bibliotecas actualiza y un procesador de tiempo de ejecución del dispositivo se actualiza como parte de la actualización del dispositivo de cómputo. En algunas implementaciones, para una o más aplicaciones en el dispositivo de cómputo, al menos una de las bibliotecas de una o más bibliotecas que se unieron a código MDI L para la aplicación respectiva (para generar una imagen nativa para la aplicación respectiva durante instalación) se ha cambiado, modificado o de otra forma actualizado. En algunas implementaciones, se actualiza y/o cambia una biblioteca de manera que el código de la imagen nativa para una aplicación que se une a la biblioteca ya no corresponde apropiadamente al menos a un desplazamiento para la biblioteca. Por ejemplo, un desplazamiento para al menos un campo de un objeto ha cambiado en la biblioteca, o similares. Un grupo de bibliotecas en el dispositivo de cómputo puede actualizarse como parte de una actualización de sistema operativo. O, las bibliotecas en el dispositivo de cómputo pueden actualizarse como parte de una actualización a una estructura y/o una actualización de procesador de ejecución. Por ejemplo, el dispositivo de cómputo puede utilizar una estructura para ejecutar aplicación manejada tal como la estructura .N ET, y las bibliotecas que son parte de la estructura son cambios y/o se actualizan y/o el procesador de tiempo de ejecución que es parte de la estructura cambia y/o se actualiza. En la estructura . NET, las bibliotecas de clase base pueden cambiar o actualizarse a una versión diferente y/o más nueva de las bibliotecas de estructura. En algunos casos, no todas las bibliotecas en el dispositivo de cómputo se actualizan y/o cambian. En otros casos, todas las bibliotecas en el dispositivo de cómputo se actualizan y/o cambian.

En 720, el dispositivo de cómputo genera una imagen nativa actualizada para una aplicación. Por ejemplo, una aplicación que se instaló en el dispositivo de cómputo al generar una imagen nativa de código MDI L para la aplicación puede actualizarse de manera que se genera una nueva imagen nativa (por ejemplo, una imagen nativa actualizada) para la aplicación al unir el código MDI L para la aplicación a una o más bibliotecas después de que al menos una o más bibliotecas han sido actualizadas en el dispositivo de cómputo. La generación de la imagen nativa actualizada puede ser similar a la generación de la imagen nativa cuando la aplicación se instaló originalmente. Por ejemplo, la imagen nativa actualizada puede ser generada para la aplicación utilizando al menos una de las bibliotecas actualizadas al dispositivo de cómputo como se describió anteriormente para el proceso de instalación. De esa forma, la generación de una imagen nativa actualizada ocurre después que una primera imagen nativa para la aplicación ya ha sido generada para aplicación y una o más de las bibliotecas se unen durante la generación de la primera imagen nativa que se ha actualizado y/o cambiado en el dispositivo de cómputo. En algunas implementaciones, cuando el procesador de tiempo de ejecución ha sido actualizado junto con bibliotecas del dispositivo de cómputo, la unión del código MDI L de la aplicación que se actualiza puede hacerse de manera que la imagen nativa generada es ejecutable utilizando el procesador de tiempo de ejecución actualizado y las bibliotecas actualizadas como disponibles en el dispositivo de cómputo.

O, puede generarse una imagen nativa actualizada cuando código MDIL para la aplicación se actualiza pero no cambian bibliotecas y/o procesadores de tiempo de ejecución. Por ejemplo, el dispositivo de cómputo recibe nuevo código MDI L para la aplicación como parte de una actualización. El nuevo código MDI L recibido para la aplicación puede instalarse como se describió aquí tal como utilizando el método 200 anterior. Por ejemplo, el dispositivo de cómputo actualiza la aplicación al generar una imagen nativa actualizada para la aplicación, incluyendo unir una porción del nuevo código MDIL con una o más bibliotecas (sin cambios) en el dispositivo de cómputo. El código nativo generado para la aplicación por una carpeta puede generarse de manera que se pueda ejecutar utilizando el procesador de tiempo de ejecución disponible en el dispositivo para ejecutar la aplicación.

En algunas implementaciones, para la aplicación que se actualiza, el código MDIL para la aplicación almacenada en el dispositivo de cómputo para la aplicación puede unirse a una o más bibliotecas del dispositivo. Por ejemplo, una carpeta puede unir el código MDI L a una o más bibliotecas disponibles en el dispositivo de cómputo para generar una imagen nativa ejecutable que se actualiza para la aplicación. La unión resuelve el código MDI L y genera código nativo para la aplicación que se incluye en la imagen nativa actualizada para la aplicación. En alg unas implementaciones, al generar la imagen nativa actualizada, para cada archivo de MDI L en el grupo de archivos MDI L para la aplicación, el archivo MDI L respectivo y una o más bibliotecas que se van a unir al código MDI L del archivo se proporcionan a la carpeta. La carpeta une los archivos MDIL respectivos a las bibliotecas proporcionadas a la carpeta para generar la imagen nativa actualizada para la aplicación. La imagen nativa actualizada puede incluir código nativo, tal como código de máquma que es ejecutable por el procesador del dispositivo de cómputo, y la imagen nativa actualizada típicamente no incluye pseudo-instrucciones no unidas como en el código MDI L. En algunas implementaciones, las imágenes nativas actualizadas generadas pueden ser firmadas como código confiado.

En algunas implementaciones, la imagen nativa actualizada reemplaza la imagen nativa previamente generada para la aplicación como la imagen nativa que es cargada para ejecutar la aplicación. La imagen nativa actualizada es cargada para ejecutar la aplicación debido a que la imagen nativa actualizada incluye código nativo que es ejecutable utilizando por lo menos una de las bibliotecas actualizadas del dispositivo de cómputo. La imagen nativa previamente generada puede ser inestable y/o no confiable, de manera que no funciona apropiadamente o como se espera, debido a que puede hacer referencia inapropiadamente a una versión anterior de una de las bibliotecas disponibles en el dispositivo de cómputo.

En algunas implementaciones, cuando se está generando una imagen nativa actualizada, la imagen nativa previamente generada es almacenada y/o respaldada tem poralmente hasta que la aplicación y/o actualización del dispositivo de cómputo se verifica como exitosa. Por ejemplo, una actualización al dispositivo de cómputo que actualiza bibliotecas del dispositivo de cómputo puede activar la regeneración y/o actualización de imágenes nativas para aplicaciones. Si la actualización al dispositivo de cómputo a la actualización de una imagen nativa para una aplicación falla, la actualización fallida puede ser regresada y la imagen nativa previamente generada de la aplicación que se almacena puede utilizarse como la imagen nativa de la aplicación cuando se ejecuta. En algunas implementaciones, tambien se conservan datos de aplicación. Por ejemplo, un usuario de la aplicación puede generar datos usuario y/o datos de aplicación antes que se actualice la aplicación, y, después de eso se actualiza la aplicación, los datos usuario y/o datos de aplicación pueden ser conservados de manera que la generación de la imagen nativa actualizada no cambia los datos usuario y/o datos de aplicación de la versión previa de la aplicación .

En 730, el dispositivo de cómputo genera una imagen nativa actualizada para una o más de otras aplicaciones instaladas en el dispositivo. Por ejemplo, para cada aplicación adicional instalada en el dispositivo de cómputo que tiene una imagen nativa que fue generada al unir código MDI L a una o más de las bibliotecas que se actualizaron, una imagen nativa actualizada para la aplicación respectiva se generan al unir el código MDIL a una o más bibliotecas como actualizadas. Las líneas punteadas, como se muestra en 730, indican que el bloque 730 puede ser omitido del método incluido en el método en varias implementaciones del método 700. En algunas implementaciones, después que se actualizan una o más bibliotecas de un dispositivo (tal como una actualización de estructura), las aplicaciones de dispositivo pueden ser actualizadas automáticamente, e imágenes nativas actualizadas para las aplicaciones pueden generarse, de manera que las aplicaciones se ejecutan apropiadamente utilizando las bibliotecas actualizadas. Si una aplicación instalada no utiliza bibliotecas compartidas que han sido actualizadas y/o cambiadas, la aplicación no necesita actualizarse, y una imagen nativa actualizada no necesita generarse para la aplicación, ya que la imagen nativa previamente generada para la aplicación puede funcionar apropiadamente con las bibliotecas como disponibles en el dispositivo. En algunas implementaciones, cuando se ha actualizado un procesador de tiempo de ejecución junto con las bibliotecas del dispositivo de cómputo, las imágenes nativas actualizadas para las aplicaciones pueden generarse de manera que la aplicación es ejecutable en el dispositivo de cómputo utilizando el procesador de tiempo de ejecución actualizado y las bibliotecas actualizadas como disponibles en el dispositivo de cómputo.

En 740, la imagen nativa actualizada es almacenada para usarse cuando se carga la aplicación para ejecutar la aplicación en el dispositivo de cómputo. Por ejemplo, la imagen nativa actualizada es cargada en lugar de una imagen nativa de la aplicación generada previa a la generación de la imagen nativa actualizada. La imagen nativa actualizada es cargada para ejecutar la aplicación debido a que la imagen nativa actualizada puede hacer referencia apropiadamente a bibliotecas que utiliza. Al generar imágenes nativas actualizadas al volver a unir código MDI L ya descargado para una aplicación, un dispositivo de cómputo que utiliza imágenes nativas para ejecutar aplicaciones puede actualizarse sin tener que descargar una versión actualizada de la aplicación, sin volver a instalar la aplicación de información recientemente descargada para la aplicación, y sin recopilar la aplicación.

Dispositivo Móvil Hustrativo La Figura 8 es un diagrama de sistema que ilustra un dispositivo móvil ilustrativo 800 que incluye una variedad de componentes de hardware y software opcionales, mostrados generalmente en 802. En general , un componente 802 en el dispositivo móvil puede comunicarse con otro componente, aunque no se muestran todas las conexiones, para facilidad de ilustración. El dispositivo móvil puede ser cualquiera de una variedad de dispositivos de cómputo (por ejemplo, telefono celular, teléfono inteligente, computadora de tableta, computadora portátil, Asistente Digital Personal (PDA), etc.) y puede permitir comunicaciones bidireccionales inalámbricas con una o más redes de comunicaciones móviles 804, tal como una red celular o satelital.

En dispositivo móvil ilustrado 800 puede incluir un controlador o procesador 810 (por ejemplo, procesador de señal , microprocesador, ASIC, u otro circuito de control y de procesamiento) para realizar tareas como codificación de señal, procesamiento de datos, procesamiento de entrada/salida, control de energ ía, y/u otras funciones. Un sistema operativo 812 puede controlar la distribución y uso de los componentes 802 y soportar una o más programas aplicaciones 814 y/o uno o más programas de software 81 5 tal como uno que puede implementar una o más de las teenolog ías aqu í descritas para generar código nativo del código I L en un dispositivo para aplicaciones. Los programas de aplicación pueden incluir aplicaciones de cómputo móvil y software comunes (por ejemplo, aplicaciones de correo electrónico, calendarios, administrares de contacto, navegadores web, aplicaciones de mensajería, un procesador de tiempo de ejecución), o cualquier otra de las aplicaciones de cómputo. La funcionalidad 813 para acceder a un almacenamiento de aplicación, en el mercado en línea, o proveedor en línea también puede utilizarse para adquirir y actualizar código y/u otra información para programas de aplicación 814.

El dispositivo móvil ilustrado 800 puede incluir una memoria 820. La memoria 820 puede incluir memoria no removible 822 y/o memoria removible 824. La memoria no removible 822 puede incluir RAM , ROM, memoria flash, disco duro, u otras tecnologías de almacenamiento en memoria bien conocidas. La memoria removible 824 puede incluir memoria flash o una tarjeta de Módulo de Identidad de Suscriptor (SI M), que es bien conocido en sistemas de comunicaciones GSM, u otras tecnolog ías de almacenamiento de memoria bien conocidas, tal como ‘tarjetas inteligentes”. La memoria 820 puede utilizarse para almacenar datos y/o código para ejecutar el sistema operativo 812 y las aplicaciones 814 y 815. Datos ilustrativos pueden incluir páginas web, texto, imágenes, archivos de sonido, datos de video, u otros grupos de datos que se van enviar a y/o recibir de uno o más servidores de red a otros dispositivos a través de una o más redes por cable o inalámbricas. La memoria 820 puede utilizarse para almacenar un identificador de suscriptor, tal como una Identidad de Suscriptor Móvil I nternacional (I MSI ), y un identificador de equipo, tal como un Identificador de Eq uipo Móvil Internacional (IME I). Tales identificadores pueden ser transmitidos a un servidor de red para identificar usuarios y equipo.

El dispositivo móvil 800 puede soportar uno o más dispositivos de entrada 830, tal como una pantalla táctil 832, micrófono 834, cámara 836, teclado físico 838 y/o seguibola 840 y uno o más dispositivos de salida 850, tal como una bocina 852 y una pantalla 854. Otros dispositivos de salida posibles (no mostrados) pueden incluir dispositivos piezoeléctricos u otros de salida apticos. Algunos dispositivos pueden servir más de una función entrada/salida. Por ejemplo, la pantalla táctil 832 y pantalla 854 pueden combinarse en un sólo dispositivo de entrada/salida. Los dispositivos de entrada 830 pueden incluir una Interfase de Usuario Natural (NUI). Una NUI es cualquier teenolog ía de interfase que permite a un usuario interactuar con un dispositivo en una forma “natural”, libre de restricciones artificiales impuestas por dispositivos de entrada tal como ratones, teclados, controles remotos, y similares. Ejemplos de métodos NU I incluyen aquellos que contienen reconocimiento de diálogo, reconocimiento de contacto y estilete, reconocimiento de gesto tanto en pantalla como adyacente a la pantalla, gestos de aire, rastreo de cabeza y de ojos, voz y diálogo, visión, contacto, gestos, e inteligencia de máquma junto a otros ejemplos de una NUI que incluyen detección de gesto utilizando acelerómetros/giroscopios, reconocimiento facial , presentaciones 3D, rastreo de ojo, cabeza, y mirada, realidad aumentada inversiva y sistema de realidad virtual, de los cuales todos proporcionan una interfase más natural, así como teenologías para detectar actividad cerebral utilizando electrodos de detección de campo eléctrico (EEG y métodos relacionados). De esa forma, en un ejemplo específico, el sistema operativo 812 o aplicaciones 814 pueden comprender software de reconocimiento de diálogo como parte de una interfase de usuario de voz que permite a un usuario operar el dispositivo 800 a través de comandos de voz. Además, el dispositivo 800 puede comprender dispositivos de entrada y software que permite interacción de usuario a través de gestos faciales de usuario, tal como detectar e interpretar gestos para proporcionar entrada a una aplicación de juegos para otra aplicación .

Un módem inalámbrico 860 puede ser acoplado a una antena (no mostrada) y puede soportar comunicaciones bidireccionales entre el procesador 810 y dispositivos externos, como se entiende en la técnica. El módem 860 se muestra genéricamente y puede incluir un módem celular para comunicarse con la red de comunicación móvil 804 y/u otros módems basados en radio (por ejem plo, Bluetooth 864 o Wi-Fi 862). El módem inalámbrico 860 típicamente está configurado para comunicación con una o más redes celulares, tal como una red GSM para comunicaciones de datos y voz dentro de una red celular individual , entre redes celulares, o entre el dispositivo móvil y una red de teléfono conmutada pública (PSTN).

El dispositivo móvil además puede incluir al menos un puerto de entrada/salida 880, un suministra de energía 882, un receptor de sistema de navegación satelital 884, tal como un receptor de Sistema de Posicionamiento Global (GPS), un acelerómetro 886, y/o un conector físico 890, que puede ser un puerto USB, puerto I EEE 1394 (firewire), y/o puerto de RS-232. Los componentes ilustrados 802 no se requieren o son todo incluido, ya que cualquiera de los componentes puede eliminarse y pueden agregarse otros componentes.

Ambiente de Implementación Hustrativa La Figura 9 ilustra un ejemplo generalizado de un ambiente de implementación adecuado 900 en el cual pueden implementarse modalidades, téenicas y tecnologías descritas.

En el ambiente ilustrativo 900, se proporcionan varios tipos de servicios (por ejemplo, servicios de cómputo) por una nube 910. Por ejemplo, la nube 910 puede comprender una colección de dispositivos de cómputo, que pueden localizarse centralmente o distribuirse, que proporcionan servicios basados en nube a varios tipos de usuarios y dispositivos conectados a través de una red tal como I nternet. El ambiente de implementación 900 puede utilizarse de diferentes formas para lograr tareas de cómputo. Por ejemplo, algunas tareas (por ejemplo, procesar entrada de usuario y presentar una interfase de usuario) puede realizarse en dispositivos de cómputo locales (por ejemplo, dispositivos conectados 930, 940, 950) mientras otras tareas (por ejemplo, almacenamiento de datos que se van a utilizar en procesamientos subsecuentes) pueden realizarse en la nube 910.

En el ambiente ilustrativo 900, la nube 910 proporciona servicios para dispositivos conectados 930, 940, 950 con una variedad de capacidades de pantalla. El dispositivo conectado 930 representa un dispositivo con una pantalla de computadora 935 (por ejemplo, pantalla de tamaño medio). Por ejemplo, el dispositivo conectado 930 podría ser una computadora personal tal como computadora de escritorio, laptop, notebook, netbook, o similares. El dispositivo conectado 940 representa un dispositivo con una pantalla del dispositivo móvil 945 (por ejemplo, una pantalla de tamaño pequeño). Por ejemplo, el dispositivo conectado 940 podría ser un teléfono móvil, teléfono inteligente, asistente digital personal, computadora de tableta, o similares. El dispositivo conectado 950 presenta un dispositivo con una pantalla grande 955. Por ejemplo, el dispositivo conectado 950 podría ser una pantalla de televisión (por ejemplo, una televisión inteligente) u otro dispositivo conectado a una televisión (por ejemplo, una caja de tv por cable o consola de juegos) o similares. Uno o más dispositivos conectados 930, 940, y 950 pueden incluir capacidades de pantalla táctil. Las pantallas táctiles pueden aceptar entrada en diferentes formas. Por ejemplo, las pantallas táctiles capacitivas detectan entrada táctil cuando un objeto (por ejemplo, una huella digital o estilete) distorsiona o interrumpe una corriente eléctrica que es ejecuta a través de la superficie. Como otro ejemplo, pantallas táctiles pueden utilizar sensores ópticos para detectar entrada táctil cuando se interrumpen haces de los sensores eléctricos. No es necesario el contacto físico con la superficie de la pantalla para que se detecte entrada por las mismas pantallas táctiles. También pueden utilizarse dispositivos sin capacidades de pantalla en el ambiente ilustrativo 900. Por ejem plo, la nube 910 puede proporcionar servicios para una o más computadoras (por ejemplo, computadoras de servidor) sin presentaciones.

Pueden proporcionarse servicios por la nube 910 a través de proveedores de servicio 920, o a través de otros proveedores de servicios en línea (no ilustrados). Por ejemplo, los servicios de nube pueden ser personalizados al tamaño de pantalla, capacidad de presentación , y/o capacidad de pantalla táctil y un dispositivo conectado particular (por ejemplo, dispositivos conectados 930, 940, 950).

En el ambiente ilustrativo 900, la nube 910 proporciona las teenolog ías y soluciones aquí descritas a los varios dispositivos conectados 930, 940, 950 utilizando, al menos en parte, los proveedores de servicio 920 y uno o más proveedores en línea 925. Por ejemplo, los proveedores de servicio 920 pueden proporcionar una solución centralizada para varios servicios basados en nube. Los proveedores de servicio 920 pueden manejar suscripciones de servicio para usuarios y/o dispositivos (por ejemplo, para los dispositivos conectados 930, 940, 950 y/o sus usuarios respectivos) . La nube 910 podría proporcionar recursos para descarga, envío, o recepción en uno o más de un paquete de instalación para una o más aplicaciones como se discutió aquí. Por ejemplo, un código de lenguaje intermediario con una aplicación puede ser recopilado en la nube 910 al menos por uno de los proveedores en línea 925. Como se muestra en 965, se genera una imagen nativa para una aplicación por el dispositivo conectado 930 del código I L o descargado de la nube 910.

Ambiente de Cómputo Hustrativo La Figura 10 ilustra un ejemplo generalizado de un ambiente de cómputo adecuado 1000 en el cual pueden implementarse innovaciones descritas. El ambiente de cómputo 1000 no pretende sugerir ninguna limitación en cuanto al alcance de uso o funcionalidad, ya que las innovaciones pueden implementarse en diversos sistemas de cómputo de propósito general o de propósito especial. Por ejemplo, el ambiente de cómputo 1000 puede ser cualquiera de una variedad de dispositivos de cómputo (por ejemplo, computadora de escritorio, computadora laptop, computadora de servidor, computadora de tableta, reproductor de medios, sistema de juegos, dispositivo móvil, etc. ).

Con referencia a la Figura 10, el ambiente de cómputo 1000 incluye una o más unidades de procesamiento 1010, 1015 y memoria 1020, 1025. En la Figura 10, esta configuración básica 1030 está incluida dentro una línea punteada. Las unidades de procesamiento 1010, 1015 ejecutan instrucciones ejecutables por com putadora. Una unidad de procesamiento puede ser una unidad de procesamiento central de propósito general (CPU) , procesador en un circuito integrado específico de aplicación (ASI C) o cualquier otro tipo procesador. En un sistema de procesamiento múltiple, m últiples unidades de procesamiento ejecutan instrucciones ejecutables por computadora para aumentar energía del procesamiento. Por ejemplo, la Figura 10 muestra una unidad de procesamiento central 1010 así como una unidad de procesam iento de gráficos o unidad de co-procesamiento 101 5. La memoria tangible 1020, 1 025 puede ser memoria volátil (por ejemplo, registros, memoria caché, RAM) , memoria no volátil (por ejemplo, ROM, EPROM , memoria flash, etc. ) , o alguna combinación de los dos, accesibles por la unidad(es) de procesamiento. La memoria 1020, 1025 almacena software 1080 que implementa una o más innovaciones aquí descritas, en la forma de instrucciones ejecutables por computadora adecuadas para ejecución por la unidad(es) de procesamiento.

Un sistema de cómputo puede tener características adicionales. Por ejemplo, el ambiente de cómputo 1000 incluye un almacenamiento 1040, uno o más dispositivos de entrada 1050, uno o más dispositivos de salida 1060, y una o más conexiones de comunicación 1070. Un mecanismo de interconexión (no mostrados) tal como conductor común, controlador, o red interconecta los componentes del ambiente de cómputo 1000. Típicamente, el software de sistema operativo (no mostrado) proporciona un ambiente operativo para otro software que se ejecuta en el ambiente de cómputo 1000, y coordina actividades de los componentes del ambiente de cómputo 1000.

El almacenamiento tangible 1040 puede ser removible o no removible, e incluye discos magnéticos, cintas magnéticas, o cartuchos, CD-ROM, DVD, o cualquier otro medio que puede utilizarse para almacenar información en una forma transitoria y que puede accederse dentro del ambiente de cómputo 1000. El almacenamiento 1040 almacena instrucciones para el software 1080 que implementa una o más innovaciones aquí descritas tal como al generar código nativo a partir de código I L para una o más aplicaciones.

El dispositivo(s) de entrada 1050 puede ser un dispositivo de entrada táctil tal como un teclado, ratón, pluma, o seguibola, un dispositivo de entrada de voz, un dispositivo de escaneo, u otro dispositivo que proporciona entrada al ambiente de cómputo 1000. Para codificación de video, el dispositivo(s) de entrada 1050 puede ser una cámara, tarjeta de video, tarjeta de sintonizador de televisión, o dispositivo similar que acepta entrada de video en forma analógica o digital, un CD-ROM o CD-RW que lee m uestras de video en el ambiente de cómputo 1000. El dispositivo(s) de salida 1060 puede ser una pantalla, impresora, bocina, escritor de CD, u otro dispositivo que proporciona salida desde el ambiente de cómputo 1000.

La conexión(es) de comunicación 1070 permite la comunicación a través de un medio de comunicación a otra entidad de cómputo. El medio de comunicación transporta información tal como instrucciones ejecutables por computadora, entrada de salida de audio o video, u otros datos en una señal de datos modulada. Una señal de datos modulada es una señal que tiene una o más de sus características establecidas o cambiadas de tal forma que codifica información en la señal. A manera de ejemplo, y no de limitación, los medios de comunicación pueden utilizar portador eléctrico, óptico, RF u otro.

Aunque las operaciones de algunos de los métodos descritos se describen en un orden secuencial para presentación conveniente, se debe entender que esta forma de descripción abarca la distribución, a menos que se requiera un orden particular por lenguaje específico descrito a continuación. Por ejemplo, operaciones secuencialmente descritas en algunos casos pueden redistribuirse o realizarse concurrentemente. Además, para búsqueda de simplicidad, las figuras adjuntas pueden demostrar las varias formas en las cuales pueden utilizarse los métodos descritos en conjunto con otros métodos.

Cualquiera de los métodos descritos pueden implementarse como instrucciones ejecutables por computadora almacenadas en uno o más medios de almacenamiento legibles por computadora (por ejemplo, medios legibles por computadora no transitorios, tales como uno o más discos de medios ópticos, componentes de memoria volátil (tal como DRAM o SRAM), o componentes de memoria no volátil (tal como memoria flash o unidades duras)) y ejecutarse en una computadora (por ejemplo, cualquier computadora comercialmente disponible, incluyendo teléfonos inteligentes u otros dispositivos móviles que incluyen hardware de cómputo). Como se debe entender fácilmente, el término medio de almacenamiento legible por computadora no incluye conexiones de comunicación, tal como señales de datos moduladas. Cualquiera de las instrucciones ejecutables por computadora para implementar las téenicas descritas así como cualquiera de los datos creados y utilizados durante la implementación de las modalidades descritas pueden almacenarse en uno o más medios legibles por computadora (por ejemplo, medios legibles por computadora no transitorios, que excluyen señales propagadas) . Las instrucciones ejecutables por computadora pueden ser parte de, por ejemplo, una aplicación de software dedicado o una aplicación de software que se accede o descarga a través de un navegador web u otra aplicación de software (tal como aplicación de cómputo remota). Tal software puede ser ejecutado, por ejemplo, en una computadora local individual (por ejemplo, cualquier computadora adecuada comercialmente disponible) o en un ambiente en red (por ejemplo, a través de Internet, una red de área ancha, una red de área local, una red de cliente-servidor (tal como una red de cómputo de nube), u otra de tales redes) utilizando una o más computadoras de red.

Para claridad, únicamente se describen ciertos aspectos seleccionados de las implementaciones basadas en software. Se omiten otros detalles que son bien conocidos en la téenica. Por ejemplo, se debe entender que la tecnología descrita no está limitada a ningún lenguaje o programa de computadora específico. Por ejemplo, la tecnología descrita puede implementarse por software descrito en C + + , C#, J + + , Java, Perl, JavaScript, Adobe Flash , o cualquier otro lenguaje de programación adecuado. De forma similar, la tecnología descrita no está limitada a cualquier computadora o tipo de hardware. Ciertos detalles de componentes adecuados y hardware son bien conocidos y no necesitan describirse con detalle en esta descripción .

También se debe entender bien que cualquier funcionalidad aquí descrita puede realizarse, al menos en parte, por uno o más componentes de lógica de hardware, en lugar de software. Por ejemplo, y sin limitación, tipos ilustrativos de componentes de lógica de hardware que pueden utilizarse incluyen Matrices de Puerta Programable de Campo (FPGA), Circuitos I ntegrados Específicos de Programa (ASIC), Productos Estándares Específicos de Programa (ASSP), Sistemas de Sistema en un Chip (SOC), Dispositivos de Lógica Programable Compleja (CPLD), etc.

Además, cualquiera de las modalidades basadas en software (que comprenden, por ejemplo, instrucciones ejecutables por computadora para hacer que una computadora realice cualquiera de los métodos descritos) puede cargarse, descargarse, o accederse remotamente a través de un medio de comunicación adecuado. Tales medios de comunicación adecuados incluyen, por ejemplo, I nternet, la red mundial, una Intranet, aplicaciones de software, cable (incluyendo cable de fibra óptica), com unicaciones magnéticas, comunicaciones electromagnéticas (incluyendo comunicaciones de red, de microondas, infrarrojas), comunicaciones electrónicas, u otros medios de comunicación.

Los métodos, aparatos, y sistemas descritos no deben interpretarse como limitantes de ninguna forma. En lugar de esto, la presente descripción está dirigida a características y aspectos novedosos y no obvios de las varias modalidades descritas, solos o en varias combinaciones y sub-combinaciones entre sí. Los métodos, aparatos y sistemas descritos no están limitados a ningún aspecto específico, característica o combinación de los mismos, ni las modalidades descritas requieren que cualquiera o más ventajas específicas estén presentes o se resuelvan problemas. En vista de las muchas modalidades posibles a los cuales pueden aplicarse los principios de invención descrita, se debe reconocer que las modalidades ilustrativas únicamente son ejemplos preferidos de la invención y no deben tomarse como limitantes del alcance de la invención. Más bien, el alcance de la invención se define por las siguientes reivindicaciones. Por lo tanto se reclama como la invención todo lo que viene dentro del alcance de estas reivindicaciones sus equivalentes.

Claims

REIVINDICACION ES

1 .- Un método que comprende: recibir, en un dispositivo de cómputo, un código de lenguaje intermediario dependiente de máquma (código MDI L) generado por un proveedor en línea para una aplicación; en el dispositivo de cómputo, instalar la aplicación en el dispositivo de cómputo al generar una imagen nativa para la aplicación al unir el código MDIL, la generación de la imagen nativa comprende: unir una porción del código MDI L con una o más bibliotecas en el dispositivo de cómputo; y almacenar la imagen nativa en el dispositivo de cómputo para usarse cuando se carga la aplicación para ejecución.

2.- El método de acuerdo con la reivindicación 1 , que además comprende actualizar el dispositivo de cómputo, la actualización del dispositivo de cómputo comprende: actualizar un grupo de bibliotecas en el dispositivo de cómputo, el grupo de bibliotecas incluye al menos una biblioteca de una o más bibliotecas unidas a la porción del código MDI L; actualizar al menos un procesador de tiempo de ejecución del dispositivo de cómputo; después de la actualización del grupo de bibliotecas, generar automáticamente una imagen nativa actualizada para la aplicación al unir la porción de código MDIL con por lo menos una biblioteca de la una o más bibliotecas después de que la una o más bibliotecas se actualizan en el dispositivo de cómputo, la imagen nativa actualizada para la aplicación generada de manera que la imagen nativa actualizada se puede ejecutar utilizando al menos un procesador de tiempo de ejecución actualizado; y almacenar la imagen nativa actualizada en el dispositivo de cómputo para usarse cuando se carga la aplicación para ejecución.

3.- El método de acuerdo con la reivindicación 1 , q ue además comprende cargar la imagen nativa durante la ejecución de la aplicación, en donde la carga de la imagen nativa se realiza por un tiempo de ejecución de lenguaje común.

4.- El método de acuerdo con la reivindicación 1 , en donde el código MDI L comprende una o más instrucciones de código de máquma y una o más pseudo-instrucciones codificadas en un nivel binario, y en donde las instrucciones de código de máquina se basan en un grupo de instrucciones de procesador para un procesador del dispositivo de cómputo.

5.- El método de acuerdo con la reivindicación 4, en donde la unión del código MDIL con la una o más bibliotecas comprende: generar código ejecutable al menos al generar una instrucción de lenguaje nativo de una pseudo-instrucción de las pseudo-instrucciones en el código MDI L.

6.- El método de acuerdo con la reivindicación 5, en donde la generación de una instrucción de lenguaje nativo comprende generar un desplazamiento de campo numérico basándose en una pseudo- instrucción .

7.- El metodo de acuerdo con la reivindicación 6, en donde la pseudo-instrucción incluye un símbolo que identifica un campo y la instrucción nativa incluye el desplazamiento de campo numérico para hacer referencia al campo cuando se ejecuta.

8.- El método de acuerdo con la reivindicación 1 , que además comprende: recibir nuevo código MDI L para la aplicación; actualizar la aplicación en el dispositivo de cóm puto al generar una imagen nativa actualizada para la aplicación, incluyendo unir una nueva porción del código MDI L con una o más bibliotecas en el dispositivo de cómputo; y almacenar la imagen nativa actualizada en el dispositivo de cómputo para usarse cuando carga la aplicación para ejecución .

9.- Un dispositivo de cómputo que incluye un procesador y memoria, la memoria almacenando instrucciones ejecutables por computadora para hacer que el dispositivo de cómputo realice un método, el método comprende: recibir, en el dispositivo de cómputo, al menos un paquete de instalación para una aplicación desde un proveedor en l ínea, el por lo menos un paquete de instalación com prende un grupo de archivos de lenguaje intermediarios dependientes de máquma (archivos MDI L); proporcionar, a una carpeta del dispositivo de cómputo, al menos un archivo MDI L del grupo de archivos M DI L y una o más bibliotecas que se van unir al menos a un archivo MDI L; y con la carpeta, generar una imagen nativa para la aplicación, la generación comprende código de lenguaje intermediario dependiente de máquma de unión (código M DI L) de al menos un archivo MDI L utilizando una o más bibliotecas.

10.- Un método que comprende: generar un grupo de archivos de lenguaje intermediario dependientes de máquina (archivos MDI L) para una aplicación al recopilar código preliminar de la aplicación en código de lenguaje intermediario dependiente de máquina (código MDI L) ; firmar archivos respectivos del grupo de archivos MDI L para indicar que los archivos respectivos son confiados como siendo de un mercado en línea; generar una lista de unión que identifica los archivos respectivos del grupo de archivos MDI L; generar un paquete de instalación para la aplicación que comprende el grupo de archivos MDI L para la aplicación y la lista de unión; y proporcionar, en el mercado en línea, el paquete de instalación para descarga.