En programación de computadoras, un programa auto-reubicable es un programa que reubica sus propias instrucciones y datos dependientes de la dirección cuando se ejecuta y, por lo tanto, es capaz de cargarse en la memoria en cualquier dirección. [1] [2] En muchos casos, el código de reubicación automática también es una forma de código de modificación automática .
Descripción general
La autorreubicación es similar al proceso de reubicación empleado por el vinculador - cargador cuando un programa se copia desde el almacenamiento externo a la memoria principal; la diferencia es que es el programa cargado en sí mismo y no el cargador en el sistema operativo o shell el que realiza la reubicación.
Una forma de auto-reubicación ocurre cuando un programa copia el código de sus instrucciones de una secuencia de ubicaciones a otra secuencia de ubicaciones dentro de la memoria principal de una sola computadora, y luego transfiere el control del procesador de las instrucciones que se encuentran en las ubicaciones de origen de la memoria. a las instrucciones que se encuentran en las ubicaciones de destino de la memoria. Como tal, los datos sobre los que opera el algoritmo del programa son la secuencia de bytes que definen el programa.
La autorreubicación suele ocurrir en el momento de la carga (después de que el sistema operativo haya cargado el software y le haya pasado el control, pero aún antes de que finalice su inicialización), a veces también cuando se cambia la configuración del programa en una etapa posterior durante el tiempo de ejecución . [3] [4]
Ejemplos de
Cargadores de arranque
Como ejemplo, la auto-reubicación se emplea a menudo en las primeras etapas de los sistemas operativos de arranque en arquitecturas como IBM PC compatibles , donde los cargadores de arranque de cadena de nivel inferior (como el registro de arranque maestro (MBR), el registro de arranque de volumen (VBR) y etapas de arranque de sistemas operativos como DOS ) se mueven fuera de lugar para cargar la siguiente etapa en la memoria.
controladores DOS x86
Bajo DOS , la auto-reubicación a veces también es utilizada por controladores más avanzados y RSX / TSR que se cargan "alto" en la memoria superior de manera más efectiva de lo que es posible para los cargadores "altos" provistos externamente (como LOADHIGH / HILOAD , INSTALLHIGH / HIINSTALL o DEVICEHIGH / HIDEVICE etc. [5] desde DOS 5) con el fin de maximizar la memoria disponible para las aplicaciones. Esto se debe al hecho de que el sistema operativo no tiene conocimiento del funcionamiento interno de un controlador que se va a cargar y, por lo tanto, tiene que cargarlo en un área de memoria libre lo suficientemente grande como para contener todo el controlador como un bloque, incluido su código de inicialización, incluso si eso se liberaría después de la inicialización. Para los TSR, el sistema operativo también tiene que asignar un Prefijo de segmento de programa (PSP) y un segmento de entorno . [6] Esto podría hacer que el controlador no se cargue en el área de memoria libre más adecuada o incluso evitar que se cargue demasiado alto. En contraste con esto, un controlador de auto-reubicación se puede cargar en cualquier lugar (incluso en la memoria convencional ) y luego reubicar solo su porción residente (típicamente mucho más pequeña) en un área de memoria libre adecuada en la memoria superior. Además, los TSR avanzados de reubicación automática (incluso si el sistema operativo ya los ha cargado en la memoria superior) pueden reubicarse en la mayor parte de su propio segmento de PSP y búfer de línea de comandos y liberar su segmento de entorno para reducir aún más la huella de memoria resultante y evitar fragmentación . Algunos TSR que se reubican automáticamente también pueden cambiar dinámicamente su "naturaleza" y transformarse en controladores de dispositivos incluso si se cargan originalmente como TSR, por lo que normalmente también liberan algo de memoria. [4] Finalmente, es técnicamente imposible que un cargador externo a los conductores Reubicar en memoria expandida (EMS), el área de memoria alta (HMA) o memoria extendida (a través de DPMS o de camuflaje ), debido a que estos métodos requieren pequeñas conductor específicos talones a permanecen en la memoria convencional o superior para coordinar el acceso al área de destino de reubicación, [7] [nb 1] [nb 2] y en el caso de controladores de dispositivos también porque el encabezado del controlador debe permanecer siempre en el primer megabyte. [7] [6] Para lograr esto, los conductores deben estar especialmente diseñados para soportar la auto-reubicación en estas áreas. [7]
Algunos controladores de DOS avanzados también contienen un controlador de dispositivo (que el sistema operativo cargaría con un desplazamiento + 0000h) y TSR (cargado con un desplazamiento + 0100h) que comparten una parte de código común internamente como binario gordo . [6] Si el código compartido no está diseñado para ser independiente de la posición , requiere alguna forma de corrección de la dirección interna similar a lo que de otra manera ya habría realizado un cargador de reubicación ; esto es similar a la etapa de reparación de la auto-reubicación, pero el cargador del sistema operativo ya está cargando el código en la ubicación de destino (en lugar de hacerlo el propio controlador).
Programas IBM DOS / 360 y OS / 360
IBM DOS / 360 no tenía la capacidad de reubicar programas durante la carga. A veces, se mantenían varias versiones de un programa, cada una construida para una dirección de carga diferente ( partición ). Se codificó una clase especial de programas, denominados programas de reubicación automática, para reubicarse después de la carga. [8] IBM OS / 360 reubicó los programas ejecutables cuando se cargaron en la memoria. Solo se requería una copia del programa, pero una vez cargado, el programa no se podía mover (lo que se denomina código de una sola vez independiente de la posición ).
Otros ejemplos
Como ejemplo extremo de auto-reubicación (muchas veces), es posible construir un programa de computadora para que no permanezca en una dirección fija en la memoria, incluso mientras se ejecuta. El Apple Worm [9] es un autorrelocalizador dinámico.
Ver también
- Eliminación dinámica de códigos muertos
- RPLOADER : una API de DR-DOS para ayudar al código de inicio remoto / de red a reubicarse mientras se inicia DOS
- Recolección de basura
- Autorreplicación
- Autorreferencia
- Quine (informática)
Notas
- ^ Una excepción al requisito de un stub es cuandoel administrador de memoria convierte la memoria expandida en memoria superior permanente a través de EMSUMB y, por lo tanto, se accede a ella como memoria superior , no a través de EMS .
- ^ Hay dos excepciones al requisito de stub para que un controlador se cargue en el HMA : No es necesario un stub cuando la memoria alta está habilitada permanentemente en máquinas sinlógica de puerta A20 , sin embargo, como esta condición no se cumple en general, DOS genérico los conductores no pueden aprovecharlo (a menos que prueben explícitamente esta condición de antemano). De lo contrario, tampoco es necesario un stub en DR DOS 6.0 y superior, cuando las extensiones del sistema residente (como SHARE y NLSFUNC ) solo enganchan la interrupción multiplex INT 2Fh, porque luego pueden utilizar una interfaz de puerta trasera para engancharse a la cadena de interrupciones en el espacio del kernel para que el controlador de puerta A20 del kernel proporcione la funcionalidad del stub. Aún así, el conductor tiene que realizar una reubicación automática para funcionar correctamente en el HMA.
Referencias
- ^ Dhamdhere, Dhananjay M. (1999). Programación de sistemas y sistemas operativos . Nueva Delhi: Tata McGraw-Hill Education. pag. 232. ISBN 0-07-463579-4. Archivado desde el original el 1 de febrero de 2020 . Consultado el 8 de noviembre de 2011 . (658 páginas)
- ^ Dhamdhere, Dhananjay M. (2006). Sistemas operativos: un enfoque basado en conceptos . Nueva Delhi: Tata McGraw-Hill Education. pag. 231. ISBN 0-07-061194-7. Archivado desde el original el 20 de febrero de 2020 . Consultado el 20 de febrero de 2020 . (799 páginas)
- ^ Paul, Matthias R .; Frinke, Axel C. (1997-10-13) [1991], FreeKEYB - Controlador de consola y teclado DOS mejorado (Manual del usuario) (6.5 ed.) [1] (NB. FreeKEYB es un controlador configurable dinámicamente basado en Unicode que admite la mayoría de diseños de teclado , páginas de códigos y códigos de país . Utiliza un ensamblador de macros listo para usar y un marco de análisis de procesamiento previo y posterior automático herramientas para generar dependencia y metadatos de morphing de código para ser incrustados en el archivo ejecutable junto con el código binario y un cargador auto-descartable, relajante y reubicable , el controlador admite la carga e instalación de diversas formas como TSR o controlador de dispositivo e implementa avanzadas técnicas de auto-reubicación (incluso en memoria DOS normal , UMB , memoria de video no utilizada o memoria sin procesar que también utiliza sobrecarga de prefijo de segmento de programa y recombinación de segmento de entorno ) y eliminación de código muerto dinámico granular a nivel de byte en tiempo de carga , así como auto-modificación código y reconfigurabilidad en tiempo de ejecución para minimizar su huella de memoria según el hardware, el sistema operativo y la configuración del controlador, así como la hazaña seleccionada configuración y configuración regional.)
- ^ a b Paul, Matthias R .; Frinke, Axel C. (2006-01-16), FreeKEYB - Controlador de consola y teclado DOS internacional avanzado (Manual del usuario) (7 (preliminar) ed.)
- ^ "Capítulo 10 Gestión de la memoria" . Guía del usuario de Caldera DR-DOS 7.02 . Caldera, Inc. 1998 [1993, 1997]. Archivado desde el original el 30 de agosto de 2017 . Consultado el 30 de agosto de 2017 .
- ^ a b c Paul, Matthias R. (6 de abril de 2002). "Re: [fd-dev] ANUNCIO: CuteMouse 2.0 alpha 1" . freedos-dev . Archivado desde el original el 7 de febrero de 2020 . Consultado el 7 de febrero de 2020 .
[…] Agregue un encabezado de controlador de dispositivo SYS al controlador, de modo que CTMOUSE pueda ser tanto en uno , un TSR normal como un controlador de dispositivo, similar a nuestro controlador de teclado avanzado FreeKEYB. […] Esto no es realmente necesario bajo DR DOS porque INSTALL = es compatible ya que DR DOS 3.41+ y DR DOS preservan el orden de las directivas [ d] config.sys […] pero mejoraría […] la flexibilidad […] en sistemas MS-DOS / PC DOS , que […] siempre ejecutan directivas device = antes de cualquier instrucción INSTALL =, independientemente de su orden en el archivo. […] El software puede requerir que el controlador del mouse esté presente como un controlador de dispositivo, ya que los controladores del mouse siempre han sido controladores de dispositivo en los viejos tiempos. Estos controladores de mouse tienen nombres de controladores de dispositivo específicos según el protocolo que usaron (" PC $ MOUSE " para el modo de sistemas de mouse, por ejemplo), y algunos programas pueden buscar estos controladores para encontrar el tipo correcto de mouse que se utilizará. . […] Otra ventaja sería que los controladores de dispositivos usualmente consumen menos memoria (sin entorno , sin PSP ) […] Es básicamente un encabezado de archivo complicado, un código diferente para analizar la línea de comando, un punto de entrada y una línea de salida diferentes, y algunos Magia de segmento para superar la diferencia ORG 0 / ORG 100h. Autocargar un controlador de dispositivo es un poco más complicado, ya que debe dejar el encabezado del controlador donde está y solo reubicar el resto del controlador […]
- ^ a b c Paul, Matthias R. (2 de febrero de 2002). "Treiber dynamisch nachladen" [Carga de controladores dinámicamente] (en alemán). Grupo de noticias : de.comp.os.msdos . Archivado desde el original el 9 de septiembre de 2017 . Consultado el 2 de julio de 2017 .(NB. Ofrece una descripción general de los métodos de carga alta en DOS, incluido el uso de comandos LOADHIGH, etc. y los métodos de reubicación automática en UMB que utilizan la API XMSUMB . También analiza los métodos más sofisticados necesarios para que los TSR se reubiquen en el HMA utilizando intra -reubicación de compensación de segmento .)
- ^ Boothe Management Systems (1 de noviembre de 1972). "Rendimiento - ¿Está obteniendo todo lo que se merece? - DOSRELO" . Computerworld - The Newsweekly For The Computer Community (anuncio). VI (44). San Francisco, California, EE.UU .: Computerworld, Inc. p. 9. Archivado desde el original el 6 de febrero de 2020 . Consultado el 7 de febrero de 2020 .
[…] DOSRELO proporciona un método para hacer que los programas problemáticos de DOS se reubiquen automáticamente. DOSRELO logra la capacidad de reubicación automática para todos los programas, independientemente del idioma, agregando lógica de punto de entrada al código objeto del programa antes de que Linkage Editor lo catalogue en la Biblioteca de imágenes principal . […]
- ^ Dewdney, Alexander Keewatin (marzo de 1985). "Recreaciones informáticas: un bestiario de virus, gusanos y otras amenazas a las memorias informáticas de Core War" . Scientific American . 285 : 38–39. Archivado desde el original el 4 de julio de 2017 . Consultado el 4 de julio de 2017 .
Otras lecturas
- Kildall, Gary Arlen (febrero de 1978). "Una técnica sencilla para la reubicación estática de código máquina absoluto" . Revista de Calistenia y Ortodoncia por Computadora del Dr. Dobb . Empresa de informática del pueblo . 3 (2): 10–13 (66–69). ISBN 0-8104-5490-4. # 22. Archivado desde el original el 9 de septiembre de 2017 . Consultado el 19 de agosto de 2017 . [2] [3] [4] (Este método de "cambio de tamaño", llamado reubicación del límite de página , podría aplicarse estáticamente a una imagen de disco CP / M-80 usando MOVCPM para maximizar el TPA para que los programas se ejecuten. también se utilizó dinámicamente por el CP / M depurador herramienta de depuración dinámico (DDT) para reubicar sí mismo en la memoria superior. el mismo enfoque fue desarrollado independientemente por Bruce Van Natta de IMS Associates para producir reubicable PL / M código. Como el párrafo reubicación límite otra La variante de este método fue posteriormente utilizada por TSR de auto-reubicación de HMA dinámicamente como KEYB , SHARE y NLSFUNC bajo DR DOS 6.0 y superior. Un método de reubicación de desplazamiento granular a nivel de bytes mucho más sofisticado basado en un enfoque algo similar se concibió y implementado por Matthias R. Paul y Axel C. Frinke para su eliminación dinámica de código muerto para minimizar dinámicamente la huella de tiempo de ejecución de los controladores residentes y TSR (como FreeKEYB).)
- Huitt, Robert; Eubanks, Gordon ; Rolander, Thomas "Tom" Alan ; Leyes, David; Michel, Howard E .; Halla, Brian; Wharton, John Harrison ; Berg, Brian; Su, Weilian; Kildall, Scott ; Kampe, Bill (25 de abril de 2014). Leyes, David (ed.). "Legacy of Gary Kildall: The CP / M IEEE Milestone Dedication" (PDF) (transcripción de video). Pacific Grove, California, EE.UU .: Museo de Historia de la Computación . Número de referencia CHM: X7170.2014. Archivado (PDF) desde el original el 27 de diciembre de 2014 . Consultado el 19 de enero de 2020 .
[…] Leyes: […] " relocalización dinámica " del SO. ¿Puede decirnos qué es y por qué fue importante? […] Eubanks : […] lo que hizo Gary […] fue […] alucinante. […] Recuerdo el día en la escuela que él vino brincando al laboratorio y dijo, he descubierto cómo reubicarme . Aprovechó el hecho de que el único byte siempre sería el byte de orden superior . Y entonces creó un mapa de bits . […] No importaba cuánta memoria tuviera la computadora, el sistema operativo siempre se podía mover a la memoria alta. Por lo tanto, podría comercializar esto […] en máquinas de diferentes cantidades de memoria. […] No podría estar vendiendo un CP / M de 64K y un CP / M de 47K. Sería ridículo tener una compilación difícil en las direcciones. Así que Gary descubrió esto una noche, probablemente en medio de la noche pensando en algo de codificación, y esto realmente hizo posible comercializar CP / M. Realmente creo que sin esa reubicación habría sido un problema muy difícil. Para que la gente lo compre, les parecería complicado, y si agregabas más memoria, tendrías que comprar un sistema operativo diferente. […] Intel […] tenía los bytes invertidos , a la derecha, para las direcciones de memoria. Pero siempre estaban en el mismo lugar, por lo que podría reubicarlo en un límite de 256 bytes , para ser precisos. Por lo tanto, siempre puede reubicarlo con solo un mapa de bits de dónde se encuentran esas […] Leyes: Sin duda, la explicación más elocuente que he tenido sobre la reubicación dinámica […]
[5] [6] (33 páginas) - Mitchell, Bridger (julio-agosto de 1988). Carlson, Art (ed.). "Z3PLUS y reubicación: información sobre ZCPR3PLUS y cómo escribir el código Z80 de reubicación automática" . The Computer Journal (TCJ): programación, soporte al usuario, aplicaciones . CP / M avanzado. Columbia Falls, Montana, EE. UU. (33): 9-15. ISSN 0748-9331 . arca: / 13960 / t36121780 . Consultado el 9 de febrero de 2020 . [7] [8]
- Sage, Jay (septiembre-octubre de 1988). Carlson, Art (ed.). "ZCPR3 Corner - Más sobre código reubicable, archivos PRL, ZCPR34 y programas Type-4" . The Computer Journal (TCJ): programación, soporte al usuario, aplicaciones . CP / M avanzado. Columbia Falls, Montana, EE. UU. (34): 20–25. ISSN 0748-9331 . arca: / 13960 / t0ks7pc39 . Consultado el 9 de febrero de 2020 . [9] [10]
- Harrell III, John B. (octubre de 1983). "DOSPLUS 3.5" . 80 Micro . Revisar. 1001001, Inc. (45): 160, 162, 164-168, 170. ISSN 0744-7868 . arca: / 13960 / t8z906r42 . Consultado el 6 de febrero de 2020 . [11] [12]
- Smith, Lee; Haines, Lionel (2 de febrero de 1989) [14 de agosto de 1987]. Formato de imagen de la aplicación RISC OS (anteriormente Arthur Image Format) (Memorando técnico) (1.00 ed.). Cambridge, Reino Unido: Acorn Computers Limited , Grupo de lenguajes de programación. PLG-AIF. Archivado desde el original el 30 de agosto de 2017 . Consultado el 30 de agosto de 2017 .
- Propiedades del formato de imagen ARM . 1993. Archivado desde el original el 31 de agosto de 2017 . Consultado el 31 de agosto de 2017 .
- Huck, Alex (14 de agosto de 2016). "Nachladbare Treiber unter CP / M - PRL2COM" . Homecomputer DDR (en alemán). Archivado desde el original el 21 de febrero de 2020 . Consultado el 21 de febrero de 2020 ;Pohlers, Volker (24 de abril de 2017) [20 de febrero de 2012, 2009, 2002, 26 de julio de 1988, 11 de octubre de 1987]. "PRL2COM" . Homecomputer DDR (en alemán). Archivado desde el original el 21 de febrero de 2020 . Consultado el 21 de febrero de 2020 .