ES2302031T3 - Trazado de bibliotecas de enlace dinamico en un dispositivo informatico. - Google Patents
Trazado de bibliotecas de enlace dinamico en un dispositivo informatico. Download PDFInfo
- Publication number
- ES2302031T3 ES2302031T3 ES04769039T ES04769039T ES2302031T3 ES 2302031 T3 ES2302031 T3 ES 2302031T3 ES 04769039 T ES04769039 T ES 04769039T ES 04769039 T ES04769039 T ES 04769039T ES 2302031 T3 ES2302031 T3 ES 2302031T3
- Authority
- ES
- Spain
- Prior art keywords
- functions
- dll
- extension
- platform
- library
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 230000006870 function Effects 0.000 claims abstract description 73
- 238000000034 method Methods 0.000 claims abstract description 28
- 238000004590 computer program Methods 0.000 claims 1
- 238000007792 addition Methods 0.000 description 15
- 239000008186 active pharmaceutical agent Substances 0.000 description 5
- 239000000306 component Substances 0.000 description 5
- 238000010586 diagram Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 238000011161 development Methods 0.000 description 4
- 238000013467 fragmentation Methods 0.000 description 2
- 238000006062 fragmentation reaction Methods 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 1
- 238000003339 best practice Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 239000008358 core component Substances 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000037361 pathway Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44552—Conflict resolution, i.e. enabling coexistence of conflicting executables
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Vehicle Body Suspensions (AREA)
- Photoreceptors In Electrophotography (AREA)
- Measuring Pulse, Heart Rate, Blood Pressure Or Blood Flow (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Communication Control (AREA)
- Executing Machine-Instructions (AREA)
Abstract
Un método para hacer funcionar un dispositivo informático que tiene un sistema operativo y una biblioteca de enlace dinámico que contiene una pluralidad de funciones accesibles por un programa ejecutable, caracterizado porque cada función de la biblioteca de enlace dinámico está asociada a un número ordinal, y el método comprende: proporcionar la biblioteca de enlace dinámico como una primera parte y parte de extensión, conteniendo la primera parte y la parte de la extensión cada una de ellas una o varias de la pluralidad de funciones; Hacer que el programa ejecutable enlace a las funciones de la primera parte directamente por medio de los números ordinales asociados; y Hacer que el programa ejecutable enlace con las funciones de la parte de la extensión indirectamente a través de otra biblioteca que contiene unas funciones adicionales.
Description
Trazado de bibliotecas de enlace dinámico en un
dispositivo informático.
La presente invención se refiere a un método
para acceder a los datos de un dispositivo informático y, en
particular a un método para tener acceso a los datos guardados en
una biblioteca de enlace dinámico del dispositivo informático. La
presente invención también se refiere a un dispositivo informático
controlado por el método.
El término dispositivo informático tal como se
utiliza aquí se debe interpretar en un sentido amplio de manera que
cubra cualquier forma de dispositivo eléctrico e incluya, los
dispositivos de grabación de datos, tales como cámaras digitales
fotográficas y de vídeo de cualquier factor de forma, ordenadores de
cualquier tipo o forma, incluyendo los ordenadores manuales y
personales, y los dispositivos de comunicación de cualquier factor
de forma, incluyendo los teléfonos móviles, los teléfonos
inteligentes, los equipos de comunicación que combinan diversos
tipos de comunicaciones, los aparatos de grabación y/o de
reproducción de imagen, y la funcionalidad informática dentro de un
solo dispositivo, así como otras formas de dispositivos de
tratamiento de la información inalámbricos o con hilos.
La mayoría de los dispositivos informáticos
funcionan bajo el control de un sistema operativo. Se puede
considerar el sistema operativo como el software que permite que se
ejecuten todos los programas en el dispositivo informático y puede
ser la clave de una mayor eficiencia en el funcionamiento y para un
desarrollo más fácil de las aplicaciones.
Un sistema operativo gestiona los recursos de
hardware y de software del dispositivo informático. Estos recursos
incluyen cosas tales como la unidad central de proceso (CPU), la
memoria, y el espacio de disco, si un disco forma parte del
dispositivo informático o se utiliza conjuntamente con el mismo.
Como tal, el sistema operativo proporciona un camino estable y
consistente para que las aplicaciones que se ejecutan en el
dispositivo informático traten los recursos de hardware del
dispositivo informático sin que la aplicación necesite saber todos
los detalles de los recursos físicos disponibles para el
hardware.
Esta tarea de gestionar los recursos de hardware
y de software es muy importante, porque los diversos programas y
métodos de introducción compiten por la atención de la CPU y
demandan recursos de memoria, de almacenamiento y de
introducción-salida (I/O) para sus propios
propósitos. En esta capacidad, el sistema operativo se asegura de
que cada programa de aplicación está provisto de los recursos
necesarios, pero tiene siempre la debida consideración a los
recursos físicos finitos disponibles para el dispositivo. Un
programa de aplicación se puede considerar como un programa
completo, autónomo que realiza una función específica directamente
para el usuario del dispositivo.
Otra tarea que se puede realizar por el sistema
operativo es la de proporcionar una interfaz (API) consistente con
el programa de la aplicación, o ejecutable. Esto es especialmente
importante si hay más de un ordenador de un tipo concreto usando el
sistema operativo, o si el hardware que constituye el ordenador está
siempre abierto a cambios. Éste es particularmente el caso cuando
el sistema operativo de núcleo tiene varios usuarios, tal como
ocurre típicamente con los dispositivos informáticos que tienen
forma de dispositivos inalámbricos de comunicaciones, tales como
los teléfonos inteligentes.
Con estos dispositivos no es infrecuente que los
diversos fabricantes de dispositivos y proveedores de dispositivos
adopten ciertos componentes de un sistema operativo de núcleo como
componentes comunes, pero que adapten los otros componentes del
sistema operativo de núcleo a sus requisitos de dispositivo
respectivos. Se destaca que una distinción entre un programa de
aplicación y el sistema operativo es que las aplicaciones se
ejecutan en "modo de usuario" (modo sin privilegios), mientras
que los sistemas operativos y las utilidades relacionadas con ellos
se ejecutan generalmente en "modo de supervisor" (modo con
privilegios). Por lo tanto, aun en el ejemplo del teléfono
inteligente anterior, hay ciertos componentes importantes del
sistema operativo, referidos a menudo como componentes de núcleo,
que se mantienen exclusivamente en el "modo de supervisor".
Una interfaz de programa de aplicación
consistente (API) permite que un programa de aplicación para un
dispositivo informático funcione en otro dispositivo informático
del mismo tipo, a pesar de que la cantidad de memoria o la cantidad
de almacenamiento sean diferentes en los dos dispositivos. Aun en el
caso de que un dispositivo informático particular sea único, el
sistema operativo puede garantizar que los programas de aplicación
continúan funcionando cuando se producen mejoras y actualizaciones
de hardware, porque el sistema operativo y no el programa de
aplicación es responsable de gestionar el hardware y la distribución
de sus recursos.
Para ir más lejos en el uso eficiente de los
recursos del dispositivo, ciertas funciones y módulos que pueden
ser comunes a un número determinado de programas de aplicación se
puede almacenar en forma de una biblioteca de tal modo que estas
funciones y módulos se guarden una sola vez y no se repliquen en
cada uno de los programas de aplicación con los cuales se van a
utilizar. El contenido de la biblioteca por lo tanto se enlaza
selectivamente a los programas de aplicación cuando se cargan o
ejecutan más biporque cuando son compilados dentro de los propios
programas de aplicación individuales. De aquí sigue que el mismo
bloque de código de biblioteca que representa una función o un
módulo se pueda compartir entre varias tareas a ejecutar en el
dispositivo en vez de que cada tarea contenga las copias de las
rutinas que utiliza.
Estas bibliotecas enlazan dinámicamente los
programas de aplicación mientras que se ejecutan los programas y
por lo tanto las bibliotecas se conocen comúnmente como bibliotecas
dinámicas de enlace (DLL). Por tanto, la mayoría de los sistemas
operativos modernos de ordenador proporcionan una instalación de
biblioteca de enlace dinámico que permite que sean dotados ciertos
procedimientos y funciones ejecutables en forma de una biblioteca
que esté separada de los programas de aplicación que se ejecutan en
el dispositivo informático. Típicamente, un programa de aplicación
se enlaza dinámicamente con la biblioteca en el tiempo de
funcionamiento, así que el programa de aplicación puede requerir
uno o varios de los procedimientos y de las funciones que son
exportados desde la biblioteca. Los procedimientos exportados se
denominan comúnmente puntos de entrada en la biblioteca.
A diferencia de los programas de aplicación
regulares, que se ejecutan generalmente desde el principio, un DLL
se puede incorporar en cualquier punto de entrada. Hay dos modos
principales de identificar estos puntos de entrada en un DLL. La
primera opción es referirse a los puntos de entrada por un nombre.
La segunda opción es referirse a los puntos de entrada por un
número ordinal. Esta última opción se denomina con frecuencia como
trazado ordinal de la función o enlace ordinal de la función. Los
nombres son posiblemente largos en comparación con los ordinales y
requieren un código adicional para su definición. Por lo tanto, se
considera generalmente que el uso de nombres es un derroche de los
recursos de Memoria Sólo de Lectura (ROM) y de Memoria de Acceso
Aleatorio (RAM) del dispositivo informático en comparación con la
aplicación de números ordinales. El enlace ordinal de los puntos de
acceso es por tanto la preferencia en ciertos sistemas operativos, y
particularmente en aquellos sistemas operativos para su uso en
teléfonos inteligentes porque estos tipos de dispositivos
informáticos tienen recursos físicos muy restringidos en la
comparación con los disponibles en dispositivos de PC de sobremesa
o portátiles, y por lo tanto el uso eficiente de código es de
importancia suprema.
Las DLL proporcionan, por tanto, una manera
mediante la cual se pueden proporcionar los programas de aplicación
en formato modular de modo que la funcionalidad pueda ser
actualizada y reutilizada más fácilmente. También ayudan a reducir
los gastos indirectos de memoria cuando diversas aplicaciones
utilizan la misma funcionalidad al mismo tiempo, porque aunque cada
aplicación es dotada de una copia de los datos, pueden compartir el
código. Además, el enlace dinámico permite que un módulo incluya
solamente la información que necesita para localizar una función
exportada de la DLL en el tiempo de carga o en el tiempo de
ejecución.
Hay una creciente exigencia de que los sistemas
operativos proporcionen una combinación de compatibilidad capacidad
de habituarse. Éste es particularmente el caso de los sistemas
operativos del teléfono inteligente, tales como el sistema
operativo de Symbian OSTM® provisto por Symbian Limited de Londres,
Inglaterra. Típicamente, un sistema operativo de este tipo se
suministra a los fabricantes del microteléfono, que proporcionan
posteriormente la funcionalidad adicional del dispositivo para su
funcionamiento bajo el control del sistema operativo. Esto
significa que un sistema operativo de este tipo debe mantener
Compatibilidad Binaria en sus API, mientras que permita al mismo
tiempo que se agreguen plataformas y productos derivados innovadores
y de funcionalidad a diferenciadora a estas API para adaptar el
sistema operativo a los requisitos particulares a de los fabricantes
de microteléfono respectivos.
Sin embargo, existen dificultades asociadas a la
coordinación de los puntos de entrada de la DLL conforme evoluciona
un sistema operativo de este tipo a partir desde un lanzamiento al
siguiente.
Según un primer aspecto de la presente
invención, se proporciona un método para hacer funcionar un
dispositivo informático que tiene un sistema operativo y una
biblioteca de enlace dinámico que contienen una pluralidad de
funciones accesibles por un programa ejecutable, caracterizado
porque cada función de la biblioteca de enlace dinámico está
asociada a un número ordinal, y el método comprende: proporcionar la
biblioteca de enlace dinámico como una primera parte y una parte de
la extensión, conteniendo la primera parte y la parte de la
extensión una o varias de la pluralidad de funciones; haciendo que
el programa ejecutable enlace con las funciones de la primera parte
directamente por medio de los números ordinales asociados; y
haciendo que el programa ejecutable enlace con las funciones de la
parte de la extensión indirectamente a través de otra biblioteca que
contiene funciones adicionales.
Según un segundo aspecto de la invención se
proporciona un dispositivo informático dispuesto para funcionar de
acuerdo con el método definido anteriormente.
Según un tercer aspecto de la invención, se
proporcionado un software dispuesto para hacer que un dispositivo
informático funcione de acuerdo con el método definido
anteriormente.
En las reivindicaciones dependientes se
establecen las características preferidas de la invención.
Se describirá a continuación una realización de
la presente invención, solamente a título de ejemplo adicional,
haciendo referencia a los dibujos anexos, en los cuales:
la Figura 1 es un diagrama que muestra
esquemáticamente la evolución de una plataforma de teléfono
inteligente;
la Figura 2 es un diagrama que muestra
esquemáticamente como puede presentarse un conflicto entre los
ordinales de una DLL con la evolución de la plataforma
paralela;
la Figura 3 es un diagrama que muestra
esquemáticamente como un aplicación de un teléfono inteligente puede
tener acceso a funciones originales de una DLL;
la Figura 4 es un diagrama que muestra como se
puede proporcionar una DLL de acuerdo con el método de la presente
invención; y
la Figura 5 es un diagrama que muestra cómo una
aplicación puede tener acceso a una función de una DLL modificada
usando una extensión de DLL proporcionada de acuerdo con el método
de la presente invención.
Haciendo referencia a la Figura 1, se muestra un
ejemplo de una evolución típica de un teléfono inteligente. En aras
de la claridad, esta evolución se muestra en forma de un árbol de
familia. La figura muestra una parte pequeña del "árbol de
familia evolutivo", pero el punto clave en este ejemplo es que no
existe en él ninguna trayectoria linear de evolución a partir de un
lanzamiento de una entidad al siguiente.
Se puede ver en el ejemplo de la Figura 1 que el
sistema operativo evoluciona de la versión X del OS (sistema
operativo) a la versión X+l del OS. Pero, en paralelo la plataforma
del dispositivo, la cual puede ser típicamente la interfaz de
usuario del dispositivo, evoluciona desde la plataforma Y a la
plataforma Y+1, estando basada la plataforma Y en la versión X de
OS y estando basada la plataforma Y+1 en la versión X+1 del OS. El
producto A evoluciona al producto B, y éstos dos se basan en la
plataforma Y. El producto B evoluciona luego a la versión 2 del
producto B, pero ésta se basa en la plataforma Y+1. Esto se debe a
que en cada nivel de la evolución ha habido un requisito para
agregar funcionalidad a la plataforma básica.
Existe un requisito adicional de mantener esa
funcionalidad en las versiones futuras de ese nivel de la familia.
Esto significa que hay múltiples rutas a través de las cuales puede
tener lugar el crecimiento funcional. Por ejemplo, un producto
particular necesitará heredar una funcionalidad adicional de la
transición del OS, de la transición de plataforma, y de su
predecesor de producto.
Unas rutas de herencia funcional múltiple causan
la fragmentación inmediata de la plataforma si el sistema operativo
utiliza un esquema de enlace ordinal para exportar las funciones de
la DLL. Con este tipo de esquema, cada función exportada por la DLL
es numerada secuencialmente. Una aplicación de cliente de la DLL
invoca las funciones para su exportación por este número ordinal.
Las operaciones de búsqueda entre las funciones y los ordinales se
pueden definir en un archivo de definición (DEF) de la aplicación en
cuestión. Sin embargo, este esquema secuencial de enumeración
significa que si dos partes hacen adiciones respectivas de función
a la misma API sin el conocimiento de la otra, la función agregada
por cada parte recibirá el mismo número ordinal (al final del
intervalo de números ordinales usado). Esto significa que el código
del programa construido contra la DLL modificado por una primera de
las dos partes (parte uno) utilizará ese número ordinal para tener
acceso a la funcionalidad que se cree existe en el número ordinal en
cuestión de la versión de la plataforma desarrollada por la parte
uno.
Sin embargo, los problemas comienzan si ese
código de programa se ejecuta siempre contra la versión de la
plataforma desarrollada por la otra de las dos partes (parte dos),
puesto que la función en ese número ordinal desarrollada por la
parte uno no es igual a la función en el mismo número ordinal según
lo desarrollado por la parte dos. Una vez que se haya producido
este problema en un producto lanzado, no hay manera de corregirlo
sin que se rompa la compatibilidad binaria en una u otra plataforma.
La Figura 2 ilustra lo que sucede cuando se amplía una API
independientemente por dos partes en paralelo, y como no se puede
resolver el espacio ordinal resultante.
El uso de rutas múltiples de herencia funcional
no plantea un problema siempre y cuando cada API tenga una sola
ruta de herencia. Esto significa en la práctica un solo propietario
para cada API. Se permite a un propietario agregar a una API
respectiva; sólo a él. Esto significa que la API evoluciona de una
manera lineal. Por ejemplo, tomando el sistema operativo Symbian
OST® como ejemplo, las DLL poseídas y proporcionadas por Symbian
serían solamente extensibles por Symbian, y no serían extensibles
por los desarrolladores de plataformas o de productos derivados.
Sin embargo, este ideal de no permitir la extensión de las
interfaces con excepción las realizadas por el propietario de la
interfaz está en la práctica en desacuerdo con la necesidad
creciente de proporcionar la adaptación a requisitos particulares
de las plataformas y de los productos de un sistema operativo de
núcleo común.
Debido a la necesidad continua de desarrollar
productos nuevos y de aportar éstos al mercado en el intervalo de
tiempo más corto posible, es relativamente corriente que diversos
productos estén en desarrollo por una primera parte, pero que han
agregado funcionalidad a las interfaces poseídas por una o más
partes diferentes. Por ejemplo, esto podría ocurrir si una
plataforma desarrollada por una parte agrega una API a una o más
bibliotecas poseídas por otra parte, o si un producto agrega una
API a una o más bibliotecas de plataforma; el problema es el mismo
en cualquier caso.
Se destaca que el problema no es que la
compatibilidad con la plataforma subyacente haya sido rota. En cada
caso el producto sería compatible con la plataforma actual del
sistema operativo/ interfaz de usuario (OS/UI). El problema es que
si se hace una revisión posterior del producto, basada en una
versión más avanzada de ese OS/ plataforma de UI, solamente puede
ser compatible con la nueva versión de la plataforma, o con la
versión anterior del producto, pero no con ambas. Sin embargo, los
requisitos son que la compatibilidad con ambas es esencial a fin de
no fragmentar la plataforma. Tal fragmentación sería muy perjudicial
para el sistema operativo y muy difícil recuperarse de la
misma.
Por lo tanto, un proveedor de un OS se puede
enfrentar con un panorama en el cual:
- \bullet
- el proveedor del OS está agregando una funcionalidad substancial a sus API en las nuevas versiones del OS (legítimamente);
- \bullet
- los proveedores de la plataforma UI están agregando funcionalidad considerable a sus API en las nuevas versiones (legítimamente)
- \bullet
- los fabricantes de producto están agregando funcionalidad a las APl de OS y plataforma de UI en sus productos, y esto no deja de ser razonable esperarlo porque estos productos requieren la diferenciación y la flexibilidad de la plataforma.
Sin embargo, debido a que las adiciones
funcionales por cada una de las partes anteriores se agregan al
final del intervalo de números ordinales, las adiciones funcionales
de los fabricantes de producto tendrán lugar en el mismo espacio
ordinal que el las adiciones de la plataforma introducidas por el
proveedor de la plataforma de UI, las cuales estarán a su vez en el
mismo espacio ordinal que la funcionalidad adicional proporcionada
por el proveedor del OS. Así, existe un potencial para los
conflictos dentro del espacio ordinal, de un alcance desconocido y
de una fuente desconocida. La razón por la que el alcance es
desconocido es que mucho del trabajo que se realiza en una
plataforma por el fabricante del producto a fin de obtener nuevos
productos no es necesariamente visible para los proveedores del OS o
de la plataforma UI.
En realidad, esta situación no llega a ser
perjudicial hasta que dos productos, o kits de desarrollo de
software (SDK) a través de los que se desarrollan los productos, se
hacen disponibles en el mercado con ordinales que están en
conflicto. Hasta ese momento es posible corregir los productos y SDK
que no hayan sido lanzados al mercado.
Por lo tanto, la presente invención intenta
proporcionar un sistema que permita a los usuarios del sistema
agregar funcionalidad a las API de una manera segura, extensible sin
poner en peligro la compatibilidad futura. De este modo, una
tercera parte pueden agregar funcionalidad a un API existente, y en
particular a un API que esté enlazado por un ordinal, de una manera
que no comprometa la evolución futura de esa API. Un segundo
objetivo es que no pueda producirse ninguna evolución futura de la
API original que comprometa la funcionalidad agregada por una
tercera parte.
La presente invención es aplicable a cualquier
situación en la que una tercera parte requiera agregar funcionalidad
a una API existente que no sea poseída por esa parte. No se aplica
cuando el propietario de una API esté ampliando esa API, porque por
definición el propietario es el mantenedor de la API. Se puede
también utilizar la presente invención para eliminar potencial
adicional de conflicto en los casos en los que se ya hayan hecho
adiciones a una API por una tercera parte.
La Figura 3 muestra un aplicación que enlaza a
las Funciones Originales almacenadas contra una extensión de la
biblioteca (LIB) de una plataforma DLL. La aplicación utiliza las
funciones almacenadas en la DLL vía los ordinales de archivo de la
LIB. Por lo tanto, cuando la aplicación invoca la función original
1, se proporciona un enlace al ordinal 1 de la extensión de la
biblioteca que a su vez exporta la funcionalidad proporcionada por
la Función Original 1 para su uso por la aplicación; y análogamente
para las funciones originales restantes almacenadas en otros
ordinales de la DLL. Éste es un patrón conocido del enlace de la DLL
y se emplea, por ejemplo, en el sistema operativo de Symbian
OSTM®.
La Figura 4 ilustra cómo se puede utilizar un
patrón de la DLL de la extensión por una aplicación para algunas
funciones de adición de producto que se han agregado a las funciones
originales proporcionadas desde la DLL de la plataforma. Estas
adiciones de producto se exportan desde la DLL de la plataforma a
través de los ordinales adicionales 6 y 7. Sin embargo, estos
ordinales adicionales 6 y 7 no están enlazados directamente por la
aplicación sino mediante la DLL de la extensión. Se accede
realmente a la DLL de la extensión a través de una biblioteca de la
extensión que mantiene las direcciones ordinales para la DLL de la
extensión, de una manera similar a la ruta de acceso para la DLL de
la plataforma. Con la presente invención, no se permite que la
aplicación utilice ordinales adicionales de la DLL de la plataforma
directamente. Pero, como se puede ver en la Figura 4, se permite a
la aplicación utilizar las funciones originales 1 a 5 exportándolas
directamente de la DLL de la plataforma. Esto se debe a que se sabe
que las Funciones Originales se pueden exportar tanto para el
sistema operativo como para la aplicación a través, respectivamente,
de los ordinales 1 a 5 para su uso por la aplicación.
Muchos sistemas operativos se escriben ahora
usando un código de programación orientado al objeto, tal como C++.
Con un sistema de este tipo, una manera preferida de llevar a cabo
el método de la presente invención es poner en ejecución las
funciones de adición de producto como miembros privados de clases.
Esto significa que el recopilador de C++ hará cumplir el código de
cliente para utilizar la DLL de la extensión. Además, es bien
sabido en esta técnica que los cambios en el código escrito
originalmente por otra parte se deberían mantener al mínimo. Por lo
tanto, en armonía con la mejor práctica seguida en esta técnica, la
DLL de la extensión no necesita ser proporcionada puramente como un
adaptador para enlazar a la DLL de la plataforma, sino que se puede
también disponer para contener la mayoría del código adicional
requerido para proporcionar la funcionalidad adicional para los
programas de aplicación. Por otra parte, se puede proporcionar la
DLL de la extensión de una manera tal que no sea específica de una
única DLL de plataforma. Por lo tanto, se considera que se puede
proporcionar una única DLL de "Extensión de Producto" en la ROM
del dispositivo informático, pero esta única DLL de la extensión se
dispone para proporcionar la interfaz a la funcionalidad adicional
de más de una, y quizás incluso de todas las DLL de la plataforma.
A partir de esto, se destaca que el método de la presente invención
no está restringido a la disposición de una DLL de la extensión
respectiva para cada DLL de la plataforma. Se deduce que un
fabricante de producto puede escoger agregar una sola DLL de la
extensión para proporcionar un enlace a diversas DLL de plataforma,
o que se puede proporcionar la funcionalidad adicional (funciones
de la extensión) disponiendo la DLL de la extensión como una
extensión real de una DLL de producto existente.
Alternativamente, se pueden agrupar las
funciones de la extensión de una manera que no guarde ninguna
relación con la disposición de las DLL originales de la
plataforma.
En la disposición mostrada en la Figura 4, por
tanto, la aplicación de la tercera parte se enlaza a los ordinales
1 a 5 de Plataform.lib, la extensión de biblioteca de la DLL de
plataforma, y a los ordinales 1 y 2 de la extensión.lib, la
extensión de la biblioteca de la DLL de la extensión. Por lo que se
refiere a la aplicación, no tiene ninguna visibilidad de los
ordinales 6 y 7 Plataform.lib. Consecuentemente, un SDK de tercera
parte para el producto no necesita ni siquiera contener la versión
extendida de Plataform.lib. Por lo tanto, con la presente invención
es posible sustituir la versión original (ordinales 1 a 5) de la
extensión de biblioteca Plataform.lib en el SDK, y usar solamente
la versión extendida (ordinales l a 7) de la biblioteca para el
desarrollo de la plataforma. Esto significa que no hay posibilidad
de que un código producido por una tercera parte use los ordinales
adicionales 6 y 7.
La Figura 5 muestra una versión posterior de la
plataforma, cuando el propietario de la DLL de la plataforma ha
agregado más funcionalidad de núcleo a la API de la DLL de la
plataforma. En este caso, los ordinales 6 y 7 se han utilizado
ahora por el propietario en la adición de las nuevas funciones.
Ahora se presentarían problemas si la aplicación que enlaza a esta
DLL de la plataforma esperaba ver las adiciones 1 y 2 de producto
en estos ordinales, como en la versión de la plataforma mostrada en
la Figura 4, porque ahora los ordinales 6 y 7 se utilizan,
respectivamente, para exportar las Adiciones de Propietario 1 y 2.
Sin embargo, en este caso se evitan los problemas puesto que las
funciones 1 y 2 de adición de producto se invocan siempre a través
de la DLL de la extensión. Por tanto es aceptable que estas
funciones se muevan cada una a una posición ordinal diferente. En
la Figura 5, las adiciones de producto se mueven, respectivamente,
desde los ordinales 6 y 7 a los ordinales 8 y 9. El único
componente del sistema que se enlaza a los ordinales para las
Adiciones de Producto 1 y 2 es la DLL de la extensión, y por lo
tanto debe ser reconstruida. No son necesarios cambios de código,
simplemente volver a establecer un enlace para que la DLL de la
extensión señale a las nuevas posiciones de ordinal 8 y 9 usadas
para exportar las Adiciones de Producto l y 2 a la aplicación.
Puesto que el código de la aplicación de la tercera parte se enlaza
a Extensión.lib, y estos ordinales siguen siendo iguales, el código
de la tercera parte no necesita ser reconstruido.
Un ejemplo de código de programa para la puesta
en práctica de la realización de la presente invención según lo
ilustrado en la Figura 5 puede ser el siguiente. Se destaca que el
ejemplo siguiente es una indicación relativamente simple de cómo se
puede lograr el código de fuente para poner en ejecución la presente
invención.
El extracto de código siguiente muestra cómo se
podría agregar una función a un archivo de encabezamiento de una
DLL de plataforma. En este ejemplo, hay dos funciones agregadas al
encabezamiento. La Función de la extensión pública será puesta en
ejecución en la DLL de la extensión. Por lo tanto, no será exportada
de Plataform.dll, sino de Extension.dll. La función privada
DoExtensionFunction será puesta en ejecución en la Plataform.dll y
por tanto será exportada desde la Plataform.dll. Esta función se
hace privada de modo que el recopilador evite que un código de
tercera parte invoque esta función a través de su exportación
ordinal.
La puesta en práctica en la DLL de la plataforma
consiste en agregar el código correspondiente a la
DoextensionFunction. Éste debería contener el mínimo de código
necesario para que esta función de la extensión fuera incluida en
la DLL, de tal manera que se redujera al mínimo la cuantía del
cambio requerido. Esta función será exportada a Platform.lib.
La puesta en ejecución en la extenson.dll se
realiza sobretodo para permitir la invocación a través de la
DoExtensionFunction privada en la DLL de la plataforma.
DoExtensionFunction es privada, así que solamente se puede invocar
dentro de la misma clase. Se debe observar que la invocación a
DoExtensionFunction está rodeada de otro código que no necesita
estar en la platform.dll, y por tanto se pone en ejecución aquí para
reducir al mínimo el impacto en la DLL de la plataforma
Preferiblemente, el código debería también
asegurar que solamente se realizan cambios esenciales en la DLL de
la plataforma. Por lo tanto, toda cualquier funcionalidad adicional
se debe poner en ejecución preferiblemente en la DLL de la
extensión. Esto proporciona la ventaja adicional de que hay menos
ocasión de colisión con una funcionalidad que surja de cambios
subsiguientes en la plataforma, y de esta manera la futura
integración de plataformas más recientes será menos
problemática.
También, si se proporcionan algunas funciones de
la extensión en la DLL de la plataforma, éstas se deberían hacer
preferiblemente como funciones privadas. Esto hace más difícil que
una tercera parte utilice inadvertidamente una función de la
extensión en la API original en vez de en la DLL de la extensión. El
recopilador ayudará entonces a hacer cumplir la regla que se ha
establecido.
Además, sería también preferible que un SDK
emitido públicamente incluyera solamente los archivos originales
LIB según lo suministrado. Esto significaría que el código de los
terceros no podría posiblemente invocar ninguno de los ordinales
adicionales de la plataforma, pues no se encuentran presentes en los
archivos de LIB. Una tercera parte por lo tanto no tendría ninguna
opción salvo acceder a la funcionalidad de la extensión a través de
la DLL de la extensión, y por lo tanto no encontraría problemas de
compatibilidad con las plataformas futuras.
Haciendo funciones de la extensión privadas, y
excluyendo las bibliotecas modificadas del SDK, se impide a un
código de tercera parte invocar las funciones adicionales de
producto creadas por el proveedor de la DLL de la plataforma. Sin
embargo, es también preferible asegurarse de que el código de la ROM
dentro de un dispositivo utilice también las DLL de la extensión.
De este modo, restringiendo el SDK a los archivos originales de LIB
resulta que no solamente las terceras partes deben utilizar la DLL
de la extensión para tener acceso a las funciones adicionales, sino
también todos los códigos, es decir el código de ROM, que se
incorpora posteriormente al dispositivo. Aunque el código de ROM se
puede reconstruir en algún punto futuro en tiempo contra nuevos
archivos de LIB, es preferible y altamente deseable maximizar la
compatibilidad binaria en los casos porque sea posible y en todo
momento durante el ciclo de vida de cualquier dispositivo concreto.
De aquí sigue que esta compatibilidad puede ser permitida si se
utiliza la DLL de la extensión de la presente invención de la
manera anteriormente indicada.
Aunque se ha descrito la presente invención
haciendo referencia a realizaciones concretas, se apreciará que se
pueden efectuar modificaciones mientras se permanece dentro del
alcance de la presente invención según lo definido por las
reivindicaciones anexas. Por ejemplo, aunque se ha descrito el
método de la presente invención haciendo referencia a DLL con
enlace ordinal, puede también utilizarse con DLL que se enlacen por
nombre. Por otra parte, se pueden proporcionar las funciones
adicionales para su uso por un programa de aplicación en parte
dentro de la DLL de la plataforma y en parte dentro de la DLL de la
extensión, y en este caso se puede disponer la DLL de la extensión
para hacer que enlace a una función adicional bien en la DLL de la
plataforma o bien dentro de la propia DLL de la extensión. Además,
aunque la presente invención se ha descrito haciendo referencia a
un dispositivo informático en la forma de un teléfono inteligente,
se puede también utilizar la presente invención en otras formas de
dispositivos informáticos, tales como PC portátiles o de sobremesa,
agendas digitales personales (PDA), o sistemas informáticos de
naturaleza general.
Claims (7)
1. Un método para hacer funcionar un dispositivo
informático que tiene un sistema operativo y una biblioteca de
enlace dinámico que contiene una pluralidad de funciones accesibles
por un programa ejecutable, caracterizado porque cada
función de la biblioteca de enlace dinámico está asociada a un
número ordinal, y el método comprende:
- proporcionar la biblioteca de enlace dinámico como una primera parte y parte de extensión, conteniendo la primera parte y la parte de la extensión cada una de ellas una o varias de la pluralidad de funciones;
- Hacer que el programa ejecutable enlace a las funciones de la primera parte directamente por medio de los números ordinales asociados; y
- Hacer que el programa ejecutable enlace con las funciones de la parte de la extensión indirectamente a través de otra biblioteca que contiene unas funciones adicionales.
2. Un método según la reivindicación 1 en el que
la biblioteca adicional está dispuesta para enlazar a una
pluralidad de bibliotecas de enlace dinámico del dispositivo
informático.
3. Un método según la reivindicación 1 ó la
reivindicación 2, en el que el código de memoria sólo de lectura
(ROM) para su uso dentro del dispositivo informático es accesible
solamente a través de la biblioteca adicional.
4. Un método según una cualquiera de las
reivindicaciones precedentes, en el que las funciones dentro de la
parte de la extensión son proporcionadas como funciones
privadas.
5. Un método según una cualquiera de las
reivindicaciones precedentes, en el que la una o varias funciones
de la primera parte están integradas en el sistema operativo.
6. Un dispositivo informático dispuesto para
funcionar de acuerdo con un método según una cualquiera de las
reivindicaciones 1 a 5.
7. Producto de programa informático dispuesto
para hacer que un dispositivo informático funcione de acuerdo con un
método según una cualquiera de las reivindicaciones 1 a 5.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB0325145 | 2003-10-28 | ||
| GB0325145A GB2407655B (en) | 2003-10-28 | 2003-10-28 | Mapping of dynamic link libraries in a computing device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2302031T3 true ES2302031T3 (es) | 2008-07-01 |
Family
ID=29725515
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES04769039T Expired - Lifetime ES2302031T3 (es) | 2003-10-28 | 2004-10-28 | Trazado de bibliotecas de enlace dinamico en un dispositivo informatico. |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US7690007B2 (es) |
| EP (1) | EP1678607B1 (es) |
| JP (1) | JP2007510210A (es) |
| AT (1) | ATE386976T1 (es) |
| DE (1) | DE602004011974T2 (es) |
| ES (1) | ES2302031T3 (es) |
| GB (1) | GB2407655B (es) |
| WO (1) | WO2005052790A1 (es) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB0607068D0 (en) * | 2006-04-07 | 2006-05-17 | Symbian Software Ltd | Improvement relating to method of embedding software in computing devices |
| US9098316B2 (en) * | 2008-09-22 | 2015-08-04 | International Business Machines Corporation | Routing function calls to specific-function dynamic link libraries in a general-function environment |
| JP6078515B2 (ja) * | 2014-11-13 | 2017-02-08 | 京セラドキュメントソリューションズ株式会社 | 電子機器およびプログラム |
Family Cites Families (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2143488C (en) * | 1995-02-27 | 2000-01-11 | Robert Paul Duncan | Dynamic link libraries without linker or loader support |
| US6052778A (en) * | 1997-01-13 | 2000-04-18 | International Business Machines Corporation | Embedded system having dynamically linked dynamic loader and method for linking dynamic loader shared libraries and application programs |
| JPH11110194A (ja) * | 1997-10-06 | 1999-04-23 | Toshiba Corp | 外部ライブラリ関数との結合方法ならびに同方法がプログラムされ記録される記録媒体 |
| US6865735B1 (en) * | 1997-10-07 | 2005-03-08 | University Of Washington | Process for rewriting executable content on a network server or desktop machine in order to enforce site specific properties |
| US6292843B1 (en) * | 1998-01-16 | 2001-09-18 | International Business Machines Corporation | Quick loading of run time dynamic link library for OS/2 |
| US6324687B1 (en) * | 1998-12-03 | 2001-11-27 | International Business Machines Corporation | Method and apparatus to selectively control processing of a method in a java virtual machine |
| US6351779B1 (en) * | 1999-03-12 | 2002-02-26 | Agilent Technologies, Inc. | Extension library to standard visa library for support of complex I/O functions |
| US6442752B1 (en) * | 1999-08-26 | 2002-08-27 | Unisys Corporation | Method, apparatus, and computer program product for replacing a dynamic link library (dll) of a first computing environment with a dll of a second computing environment that can be invoked from the first computing environment in a transparent manner |
| US6567093B1 (en) * | 1999-09-09 | 2003-05-20 | Novatek Microelectronics Corp. | Single semiconductor chip for adapting video signals to display apparatus |
| GB2354851B (en) * | 1999-10-01 | 2004-07-21 | Ibm | Web browser extension and method for processing data content of web pages |
| US6658658B1 (en) * | 2000-02-17 | 2003-12-02 | International Business Machines Corporation | Implicit forwarding and resolving of a reference made by an importing module to an exporting module for a specified export |
| US6874148B1 (en) * | 2000-06-14 | 2005-03-29 | National Instruments Corporation | System and method for exporting a graphical program to a shared library |
| FR2820221B1 (fr) * | 2001-02-01 | 2004-08-20 | Cimai Technology | Procede et systeme pour gerer des executables a bibliotheques partagees |
| US6804709B2 (en) * | 2001-02-20 | 2004-10-12 | Microsoft Corporation | System uses test controller to match different combination configuration capabilities of servers and clients and assign test cases for implementing distributed testing |
| US7191184B2 (en) * | 2001-05-02 | 2007-03-13 | National Instruments Corporation | Optimized storage for measurement data |
| US7769823B2 (en) * | 2001-09-28 | 2010-08-03 | F5 Networks, Inc. | Method and system for distributing requests for content |
| US7013423B2 (en) * | 2002-06-27 | 2006-03-14 | International Business Machines Corporation | Omitting forwarder pages in a history list in a browser |
| US20040077309A1 (en) * | 2002-10-18 | 2004-04-22 | Richard Brass | Wireless signal forwarder |
| US20040123308A1 (en) * | 2002-12-20 | 2004-06-24 | Siemens Information And Communication Networks, Inc. | Hybird of implicit and explicit linkage of windows dynamic link labraries |
| US7308684B2 (en) * | 2003-06-16 | 2007-12-11 | Microsoft Corporation | Classifying software and reformulating resources according to classifications |
| US7210124B2 (en) * | 2003-06-16 | 2007-04-24 | Microsoft Corporation | Reformulating resources with nodes reachable from defined entry points |
| US7590736B2 (en) * | 2003-06-30 | 2009-09-15 | Microsoft Corporation | Flexible network load balancing |
-
2003
- 2003-10-28 GB GB0325145A patent/GB2407655B/en not_active Expired - Fee Related
-
2004
- 2004-10-28 DE DE602004011974T patent/DE602004011974T2/de not_active Expired - Lifetime
- 2004-10-28 EP EP04769039A patent/EP1678607B1/en not_active Expired - Lifetime
- 2004-10-28 JP JP2006537413A patent/JP2007510210A/ja not_active Withdrawn
- 2004-10-28 WO PCT/GB2004/004551 patent/WO2005052790A1/en active IP Right Grant
- 2004-10-28 AT AT04769039T patent/ATE386976T1/de not_active IP Right Cessation
- 2004-10-28 ES ES04769039T patent/ES2302031T3/es not_active Expired - Lifetime
- 2004-10-28 US US10/595,549 patent/US7690007B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| ATE386976T1 (de) | 2008-03-15 |
| US7690007B2 (en) | 2010-03-30 |
| EP1678607B1 (en) | 2008-02-20 |
| DE602004011974T2 (de) | 2009-02-12 |
| US20070220508A1 (en) | 2007-09-20 |
| JP2007510210A (ja) | 2007-04-19 |
| WO2005052790A1 (en) | 2005-06-09 |
| GB2407655A (en) | 2005-05-04 |
| GB2407655B (en) | 2009-08-05 |
| EP1678607A1 (en) | 2006-07-12 |
| GB0325145D0 (en) | 2003-12-03 |
| DE602004011974D1 (de) | 2008-04-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR101581796B1 (ko) | 컴퓨팅 플랫폼의 이종 프로세서들 간의 공유 가상 메모리에서의 가상 함수들의 공유 | |
| US9207918B2 (en) | Firmware extension method and firmware builder | |
| US7644406B2 (en) | Update system capable of updating software across multiple FLASH chips | |
| US9710396B2 (en) | Sharing virtual memory-based multi-version data between the heterogeneous processors of a computer platform | |
| ES2209947T3 (es) | Metodo y sistema para la distribucion de programas de ordenador orientados a objetos. | |
| US8719839B2 (en) | Two way communication support for heterogenous processors of a computer platform | |
| JP5957006B2 (ja) | 拡張可能なデータ並列セマンティクス | |
| US10353717B2 (en) | Build-time memory management for multi-core embedded system | |
| CN106796521B (zh) | 独立于产品发布的api版本控制 | |
| Pemstein et al. | The Scythe statistical library: An open source C++ library for statistical computation | |
| US20120017067A1 (en) | On-demand predicate registers | |
| ES2302031T3 (es) | Trazado de bibliotecas de enlace dinamico en un dispositivo informatico. | |
| US10620916B2 (en) | Read-only communication operator | |
| JP2012099155A (ja) | 実行時多態性 | |
| TW201527976A (zh) | 積體電路無線電 | |
| CN101853154A (zh) | 简化具有动态库的接口的方法 | |
| KR100478463B1 (ko) | 응용 프로그램의 동적링크 방법 | |
| Hoemmen | Purging reliance on UVM from Tpetra & downstream solvers. | |
| Edmonds et al. | Extensible PGAS semantics for C++ | |
| CN117492761A (zh) | 应用于多项目的软件开发编译方法、装置、设备及介质 | |
| DASH | GRAPHICAL LCD DEVICE DRIVER DEVELOPMENT AND OPTIMIZATION OF BOOT TIME FOR EMBEDDED DEVICE | |
| Tao | Texas Instruments DSP Dynamic Run-Time Loader | |
| Häkkinen et al. | C++ coding guidelines |