Seguramente todos hemos escuchado alguna vez el término de “toolkit”, pero ¿qué significa este término realmente?

Supuestamente, se trata de un tipo de herramientas de programación que nos ayuda en determinadas tareas. En algunos ordenadores estos toolkits pueden ser herramientas software diseñadas para llevar a cabo tareas específicas, como una serie de rutinas listas para usar y que simplifican al programador la escritura de software complejo.

En el QL, la interpretación de este término estuvo influenciado desde el día en el que Sinclair y Tony Tebby liberaron las versiones del Toolkit 1 y Toolkit 2.

El Toolkit 1 fue un predecesor del Toolkit 2. Fue vendido en cartuchos Microdrive por la división software de Sinclair Research. Un poco más tarde, Tony Tebby liberó las primeras versiones del Toolkit 2 que nosotros conocemos y apreciamos hoy en día.

Las primeras ediciones del Toolkit 2 eran suministradas generalmente en EPROM’s de 16K que se conectaban el conector de la expansión ROM de la parte trasera del QL. Había también una versión en cartucho microdrive, en el cual tú podías seleccionar las partes del Toolkit que necesitabas, lo que era muy útil para QL’s sin expansión donde la memoria era muy limitada. Aparecieron también versiones recortadas que se suministraban con las interfaces de disco – los comandos eran los mismos que el Toolkit 2 completo, pero no todos los comandos estaban disponibles, sólo aquellos que correspondían a la interfaz de disco.

El Toolkit 2 nos da un conjunto de nuevos comandos en SuperBASIC y suministra muchas facilidades así como la mejora de otras características disponibles en el QL estándar. Entre ellas está el manejo de la red local, los directorios por defecto y el la utilización de comodines para la gestión de ficheros, así como otras muchas.

Todo esto era percibido por los usuarios con el término de “toolkit” – para la mayoría de nosotros era una EPROM o un paquete de software que nos daba comandos extra en SuperBASIC.

Con el paso del tiempo, prácticamente la mayoría de los sistemas se suministraban con el Toolkit 2 preinstalado. Entre los ejemplos más destacados tenemos las interfaces de Miracle System (Trump Card y Gold Card por ejemplo) las cuales tenían una implementación completa del Toolkit 2 en placa. Aquellos que usan SMSQ/E en sus sistemas de forma estándar, todas las facilidades del Toolkit 2 están incluidas en el SBASIC.

Tony Tebby permite actualmente una distribución limitada del Toolkit 2 para quienes lo necesiten, por ejemplo, en el uso de emuladores QL.

Lo que pretendo hacer con esta serie de artículos es examinar algunos toolkits disponibles que suministran extensiones al SuperBASIC o al SMSQ/E. Hay muchos de ellos por ahí que son gratuitos y se pueden obtener de las librerías de dominio público y de varios sitios Web.

Aunque yo nunca he visto el libro, me han dicho que la mayoría de las extensiones en forma de toolkits para el QL se enumeran en el manual de referencia SuperBASIC de Rich Mellor – véase el detalle en los anuncios de publicidad de RWAP, aunque te advirtió que cuesta 20,00 libras.

INSTALACIÓN DE TOOLKIT’s

La mayoría de los toolkits son suministrados en discos. Generalmente se suelen instalar en el área de procedimientos residentes con las sentencias RESPR, LBYTES, y CALL.

El comando RESPR reserva una cantidad de espacio en memoria (a especificar) en el área de procedimientos residentes. Este espacio es generalmente del mismo tamaño que el tamaño del fichero que contiene el toolkit en el disco. La mayoría de los toolkits vienen en un sólo fichero que contiene todas las extensiones. El nombre del fichero generalmente tiene una extensión o sufijo de 3 o 4 caracteres como uno de estos ejemplos (aunque algunos no tienen extensión o tienen otra extensión menos común):

_BIN, _CDE, _REXT, _RXT, _EXT

BIN es una abreviatura de binario, CDE es de código (code), REXT es de “Runtime Extensions” y EXT de extensión. Mientras que el requisito de memoria es al menos el mismo que la longitud del fichero, puedes averiguar el espacio a reservar con la función FLEN que te devuelve el tamaño del archivo. Supón que tienes un toolkit llamado FLP1_TOOLKIT_EXT, el comando PRINT FLEN(“FLP1_TOOLKIT_EXT”) te dirá cuanta memoria necesitas reservar.

El fichero que contiene el toolkit debe ser cargado en esa área de memora con el comando LBYTES, a continuación debemos usar el comando CALL para hacer que el ordenador ejecute una pequeña pieza de código en el toolkit que lo vincula al sistema y le dice al QL el nombre de los nuevos comandos y funciones contenidos en él. Aquí hay un ejemplo. Nosotros asumimos que el tamaño del fichero TOOLKIT_EXT es de 1234 bytes:

100 base = RESPR(1234)
110 LBYTES FLP1_TOOLKIT_EXT,base
120 CALL base

La mayoría de los toolkits son inicializados mediante una llamada a la dirección base del bloque de código que se utilizó cuando éste fue cargado en la memoria. Algunos de ellos tienen ciertas necesidades específicas y requerimientos bastante diferentes, los cuales suelen estar documentados en sus instrucciones. También hay toolkits que tienen requerimientos diferentes cuando se intentan enlazar dentro de un programa compilado en Basic, pero esto es un tema aparte.

Las tres líneas del ejemplo anterior son incluidas generalmente en un fichero de arranque de algún tipo. La mayoría de los toolkits vienen son sus propios programas de arranque, y mirando su código generalmente podemos averiguar cómo añadir ese código de inicialización a nuestros propios programas de arranque con sólo rastrear las líneas con los comandos RESPR/LBYTES/CALL. Muchos programas de gran tamaño suelen cargar también pantallas de presentación durante el proceso de arranque. Debes también tener cuidado porque muchos programas suelen incluir secuencias de inicio propias y algo enrevesadas, por eso a veces es difícil extraer el mínimo de información que tú necesitas.

Si tu sistema dispone del comando LRESPR, puedes reemplazar las tres líneas anteriores con una sola llamada, por ejemplo:

100 LRESPR FLP1_TOOLKIT_EXT

El comando LRESPR automáticamente reserva la memoria que coincide con la longitud de archivo, carga el fichero y hacen un CALL a para enlazar el toolkit en el Basic.

EL ORDEN EN UN PROGRAMA DE INICIO

No hay una regla fija para establecer un orden correcto en la secuencia de arranque en los programas de inicio, pero a medida que tienes más experiencia esto suele ser cada vez más fácil. En general, el código del QL no es muy quisquilloso en cuanto al orden en el que debe ser cargado las distintas extensiones y toolkits, pero hay algunas reglas simples que te pueden ayudar:

Si tu sistema tiene una copia del Toolkit 2, que exige un comando para ser inicializado, éste debería ser cargado al inicio del programa de arranque. Por ejemplo, 100 TK2_EXT es un ejemplo de un comando necesario, en algunas expansiones de disco que vienen con el Toolkit 2 integrado, para hacer visible el toolkit desde el SuperBASIC.

Si tu sistema tiene algunos aceleradores de pantalla como el Speedscreen o el Lightning, generalmente es mejor cargar estas extensiones primero en el arranque de tu sistema, antes que otras extensiones y toolkits.

Si tu sistema usa el entorno de ventanas (pointer environment o PE), que es proporcionado con los archivos llamados PTR_GEN, WMAN y HOT_REXT, éstos deben ser instalados generalmente antes que otros toolkits.

PE (Pointer Environment) integra una facilidad llamada HOTKEY, que está generalmente configurada por un comando como HOT_GO. Los toolkit se cargan generalmente antes de este comando. Asimismo, los toolkits deberían ser cargados antes que cualquier otro programa ejecutable. Esto es debido a que no se puede asignar memoria del área de procedimientos residentes (RESPR) mientras se esté ejecutando cualquier otra tarea, en estos casos recibirás un mensaje parecido a “Not Complete”.

Así que tu programa de inicio probablemente tendrá una secuencia de carga en el siguiente orden:

- TK2_EXT en caso de ser necesario para hacer disponible el Toolkit 2 .
- Instalar cualquier software de aceleración de pantalla.
- Instalar PE (pointer environment) si lo usas.
- Instalar calquier Toolkit .
- Definir las teclas rápidas, etc
- Enviar un comando HOT_GO para despertar las teclas de acceso rápido en caso de que las utilices.

Estas son sólo unas directrices sencillas si bien pueden variar de programa a programa.

—
Autor: David Denham
Traducción y adaptación: afx
—