BREVE HISTORIA de SMSQ

Tony Tebby

Le Grand Pressigny, FRANCE

“Incompatibilidades y Mejoras, Errores y Características”

“¿Fue todo una terrible equivocación?” Yo sabía desde el principio que no debía hacerlo, pero había tanta gente pidiendo que SMS fuera destapado que, a principios de 1992, perfilé una estrategia (con Miracle Systems y Jochen Merz) para hacer disponible una versión de SMS “compatible con QL”.

El perfil era bastante simple. Existía un núcleo SMS compatible con QDOS (y había estado en uso habitual desde 1990). Existía un conjunto completo de procedimientos y funciones SuperBASIC. Existía un conjunto completo de controladores de dispositivo (al estilo del QL extendido) para la serie Atari ST así como controladores “portables” para disco, puertos serie y paralelo para otro hardware. Había un entorno que soportaba programas compilados con QLiberator. Todo lo que se requería era el núcleo de un intérprete de SuperBASIC.

Tras el éxito de la Gold Card, Miracle Systems estaba buscando un sistema operativo legítimo para su (por entonces sin definir) siguiente ordenador y Jochen Merz necesitaba un sistema operativo para legitimar el emulador QL de la serie Atari ST. Estaba claro que sería mejor proveer también una versión para la Gold Card pero como Miracle Systems no quería involucrarse en vender software, el asunto de la Gold Card quedó al margen.

Me embarqué en tratar de averiguar lo que hacía el intérprete de SuperBASIC de Sinclair. No era difícil definir lo que debería hacer, pero Jan Jones lo había construido sobre los principios de una máquina GIGO (garbage in, garbage out). Con limitado espacio en ROM, no había sitio para comprobación real de errores así que Jan sólo intentó asegurarse de que cualquiera que fuera la basura con la que tenía que tratar el SuperBASIC, la recogía y hacía algo. El “algo” no siempre era obvio.

Mientras NOSOTROS (QJUMP, esa gente maravillosa de QVIEW, Jochen Merz, Albin Hessler, etc.) nunca hubiéramos explotado deliberadamente “agujeros” en SuperBASIC, esto mismo no era necesariamente cierto de otros proveedores de software o contribuyentes a bibliotecas de dominio público. Además, había sido conocido que incluso NOSOTROS habíamos caído en un agujero por accidente.

La compatibilidad, por lo tanto, no sólo significaba reproducir el SuperBASIC como era de suponer, sino reproducir tantas rarezas como fuera necesario para ejecutar la mayoría del software de QL. Los dos “compiladores” de SuperBASIC proporcionaron un punto de partida. La ayuda fue proveer un intérprete BASIC que proporcionara:

1. mejor compatibilidad con SuperBASIC que cada uno de los compiladores,

2. ejecución a al menos la mitad de velocidad de QLiberator,

3. un entorno que soporte programas compilados por QLiberator y Turbo.

Claramente, puesto que algún software para QL ni siquiera funcionará en todas las ROMs de QDOS, la compatibilidad total con una ROM QDOS en particular sólo se puede conseguir copiando el código de esa ROM. Incluso un ligero reordenamiento de las rutinas de la ROM QDOS (como en el Thor XVI) puede causar considerable incompatibilidad. En esta etapa, no había intención de proveer mejoras. La “Experiencia Minerva” había enseñado hasta qué punto las más ligeras mejoras podían dar amplias incompatibilidades. ¡Demasiado para las intenciones!

El Nacimiento de la QXL

“¡Ellos tampoco deberían haberlo hecho!” En principio, la implementación de SMSQ en un procesador 680x0 embebido en un PC debería haber sido bastante clara. La Gold Card usaba la controladora de disco del IBM PC, la interfaz de disco duro IDE no es muy diferente de la Hardcard usada en el Miracle QL Hard disk y los puertos serie y paralelo del PC son básicamente lo mismo que los puertos serie y paralelo que puedes encontrar en cualquier sitio excepto en el QL.

Si la QXL hubiese sido diseñada como una tarjeta enchufada en una placa base estándar AT (sin procesador ni memoria) y provista con controladores para manejar una interfaz estándar de teclado, una tarjeta estándar multi E/S / disquetera / IDE y una tarjeta SuperVGA estándar, habría sido simple.

Para haber hecho esto, sin embargo, Miracle habría tenido que haber suministrado el hardware de PC (por un coste de cerca de la mitad de la tarjeta QXL con una configuración de una sola disquetera / disco duro de 110MB esto habría parecido, para mí, la forma obvia de hacerlo).

Sin embargo, esto habría significado que la máquina no habría sido utilizable como un PC (suspiro de alivio) y habría descartado el uso de portátiles. Además, los PC de segunda mano estaban ampliamente disponibles gratis o por menos de $30.

Una de las razones más comunes para que un PC de segunda mano estuviera disponible a muy bajo precio era que el hardware no era un clon perfecto, así que no había posibilidad de tener una versión de SMSQ que accediera a los dispositivos E/S directamente. Además, si la QXL se fuera a poner en un PC “de trabajo” real, no sólo tendría que coexistir con su anfitrión sino que tendría que funcionar a través de cualquier software de bajo nivel (Stacker, Doublespace, Hypercache, Smartdrive, etc.) que fuera usado para mejorar el rendimiento E/S del PC.

Como resultado, cualquier acceso directo desde la QXL al PC estaba descartado y la QXL iba a ser albergada por un programa DOS. Una decisión lógica, puede ser, pero, desde el punto de vista del software de sistema operativo, era un desastre.

¿Dónde está el problema? El PC viene completo con controladores de dispositivo para todos sus periféricos, todo lo que se necesita hacer es pasar datos desde la QXL a los controladores de dispositivo del PC (usando llamadas al BIOS) y viceversa.

Hay tres problemas con esto.

1. El diseño del BIOS del PC no tiene en cuenta los requerimientos de multitarea (es, por ejemplo, imposible escribir algo en disco mientras estás esperando entrada por el puerto serie).

2. Mientras la exactitud de los manuales de referencia acerca de los puntos de entrada del sistema operativo QDOS dejaba mucho que desear, la (in)exactitud de los manuales de “referencia” para el PC da un nuevo significado a la palabra referencia.

3. Todos los manuales de referencia (los examinados hasta ahora) para el PC fueron escritos en los días del PC y el PC/XT. El BIOS del PC también data de este período. El BIOS ha sido considerablemente, e incoherentemente, cambiado mientras los manuales han sido actualizados superficialmente para tener en cuenta los teclados AT, discos duros de más de 10 MB y disquetes 3.5" y HD.

Toma como ejemplo formatear un disquete en el PC. En QDOS, es una simple llamada al sistema operativo. En el PC, sin embargo, parte de la operación de formateo es llevada a cabo por la aplicación. La rutina de formateo del controlador de disquete de la Gold Card llevó un par de horas de escribir. Como el BIOS del PC hace la mayoría del trabajo por ti, debería ser fácil escribir una rutina de formateo en el PC.

Hay una variedad de llamadas DOS y BIOS para ayudarte a hacer esto: establecer los parámetros del dispositivo, formatear y verificar pistas, etc. Tengo tres manuales de referencia que dan ejemplos de programas de formateo.

Miro al primero y pienso “esto es muy extraño”. Parece que no hay una forma de especificar la densidad y parece que no hay comprobaciones de si las pistas han sido correctamente formateadas: aparenta ser automático. Así que lo pruebo. Bien, hace todos los ruidos correctos y me dice que mi disco DD tiene 1440 sectores. Pruebo un disco HD. Bien, hace todos los ruidos correctos pero me dice que mi disco HD tiene sólo 1440 sectores. Pruebo sin ningún disco. ¡Maravilloso, formatea mucho más rápido y me dice que tengo 1440 sectores! - ¡AU FREE!

Pruebo el segundo programa: éste comprueba el error devuelto de la llamada “Formatea pista y verifica”: incluso me permite especificar la densidad. Lo pruebo con un disco DD. ¡Bien! Me dice que hay 1440 sectores. Lo pruebo con un disco HD. ¡Bien! Me dice que hay 2880 sectores. Lo pruebo sin disco: el formateo falla, ¡excelente! Lo pruebo con un disco DD malo diciendo que es HD. ¡Bien! Me dice que tiene 2880 sectores. Sospechoso, intento copiarle algunos ficheros usando DOS. DOS rechaza reconocerlo. Pruebo los otros dos discos: ninguno es legible. Me pongo en QDOS para mirar los discos: no hay sectores 1, 2 ni 3 en ninguna de las pistas en las que miro. Esto explicaría por qué el primer programa no se molestaba en comprobar el error devuelto de “Formatea pista y verifica”: ¡no verifica!

En el tercer programa. Éste es similar a los otros dos, pero usa las antiguas llamadas BIOS “INT 13h” en lugar de las más poderosas llamadas “función 44h del DOS” (maravillosa esta terminología de DOS). Éste requiere el uso de una llamada separada “verificar sectores”. La llamada para verificar sectores parece funcionar: esta rutina obtiene un error en cada pista: es correcto, después de formatear, ninguna de las pistas es legible en cualquier tipo de disco.

Así que, pruebo por mí mismo. Después de un montón de experimentos con las llamadas al BIOS descritas en varios manuales, soy capaz de escribir pistas DD o HD y verificarlas. El único problema es que escribo demasiados sectores en una pista: los últimos sectores sobreescriben a los primeros sectores de la pista. Después de una semana de trabajo, puedo seleccionar la densidad y casi puedo formatear una pista.

¡Thinks! Microsoft puede hacerlo, yo también debería ser capaz. Ahora empezamos a ver el problema: la rutina de formateo de disquetes de DV3 ocupa menos de 512 bytes. El programa FORMAT de Microsoft es más grande de 32 Kbytes, casi el tamaño de QDOS, todos sus controladores de dispositivo, SuperBASIC y todos sus procedimientos y funciones. No me extraña que todos los manuales estén equivocados. Llevaría unas 200 páginas sólo listar el programa FORMAT de MS-DOS, ¡sin intentar explicar cómo funciona!

Desensamblar todo este programa podría llevar meses. Decido trazar las dos vías de interés: los formatos 720K y 1440K. Resulta que lo que necesitas hacer es meter valores especiales en varias posiciones no documentadas en la memoria baja. Anoto todas las posiciones en las que hay que escribir y configuro una rutina de formateo. Dentro de esta rutina toco todas las posiciones requeridas, formateo el disco y restauro todas las posiciones con sus valores previos.

Éxito, ahora puedo formatear disquetes DD y HD. El único problema es que, a pesar de mi cuidado en restaurar todas las posiciones tocadas, después de un formateo el PC rechaza reconocer cualquier cambio de disco hasta que pulsas el botón de reset. Dos semanas han pasado y todavía no sé realmente cómo se formatea un disco usando MS-DOS.

¿Gasto otras dos semanas en averiguar cómo restaurar el BIOS después de una operación de formateo? Incluso si consigo que funcione en mi PC, ¿funcionará en cualquier otro PC? ¿Cómo puede alguien tener éxito en vender un sistema operativo donde se tarda dos semanas en escribir una rutina usando las llamadas al sistema operativo cuando se tardaría sólo dos horas escribir la misma rutina accediendo al hardware directamente?

Ahora encontramos el coste real de la QXL en desarrollo. Incluso aunque el rendimiento E/S de la QXL está bien, más allá de los niveles que sería razonable esperar, la implementación de los controladores de dispositivo ha costado entre 10 y 20 veces el coste de controladores equivalentes para otras plataformas 680x0. Como resultado, se ha tragado por completo todo el tiempo que había sido reservado para el desarrollo del intérprete SBASIC. Para los primeros compradores de la QXL, las cosas parecían desalentadoras: rendimiento E/S pobre, sin intérprete SBASIC. No es un debut muy prometedor para SMSQ.

“Tú toma la carretera importante y yo tomaré la carretera secundaria”

La estrategia del hardware de la QXL no era el único problema a encarar. Miracle Systems, por razones que deberían ser obvias, quería que la QXL se pareciera lo máximo posible a la Trump Card y a la Gold Card, mientras que Jochen Merz quería un sistema operativo que no fuera sólo desarrollado en la misma línea que los controladores de dispositivo extendidos de Atari QDOS sino uno que fuera mucho más lejos.

La mejora de un hombre es la incompatibilidad de otro hombre. Ahora tenemos el problema de desarrollar (y mantener) dos variaciones diferentes de SMS: SMSQ, la versión básica a lo QL y SMSQ/E, la versión extendida que seguramente irá divergiendo más y más de SMSQ. Jochen Merz, por lo tanto, decidió suministrar SMSQ/E para la QXL así como para el Atari y las Gold Cards. (¡Fácil para él de decidir: era yo el que tenía que hacer el trabajo!)

Más problemas. Parece que los usuarios de computadoras no son muy sensibles a cuánto tienen que pagar por el sistema operativo. Son, sin embargo, ¡muy sensibles a cuánto pagan otros usuarios! Los usuarios de Gold Card y Atari no se quejan de tener que pagar por SMSQ/E (les contamos que sería necesario allá en 1990), pero ponen objeciones a que los usuarios de QXL obtengan una versión “gratis” de SMSQ con la QXL. A los usuarios de QXL no parece importarles que se les pida un pago extra por SMSQ/E (por el momento las diferencias son tan pequeñas que normalmente no merece la pena “promoverse”) pero ponen objeciones a que a los usuarios de Gold Card y Atari no se les pida pagar más.

Incluso peor, hay algunos usuarios de QXL que parece que piensan que se les provee con una versión especialmente caduca de SMSQ ¡para obligarles a apoquinar unos pocos peniques por una “promoción”!

Entonces para rematarlo todo, Miracle Systems produce una Super Gold Card que se parece a una Gold Card, pero resulta ser bastante diferente. Ahora tenemos implementaciones de SMSQ en tres familias diferentes de hardware, siete variantes diferentes de hardware, cuatro tipos diferentes de monitores, con cuatro procesadores de la serie 68000 diferentes, en tres (y a veces más) idiomas. Hasta aquí, hay más combinaciones posibles que usuarios.

Para evitar la necesidad de producir una versión diferente de SMSQ/E para cada usuario, SMSQ ahora usa una estructura de módulos que ha sido tomada prestada del sistema operativo Stella (¿¿¿¿Stella????). Ésta permite que los módulos del sistema operativo sean seleccionados (o ignorados) mientras arranca el sistema. En principio, podría ser distribuida una sola versión de SMSQ que seleccionara automáticamente los módulos correctos para cualquier combinación de hardware. En la práctica, cada familia de hardware (Gold Card, QXL y Atari ST/TT) requiere su propio cargador especial, así que no merece la pena incorporar todos los módulos en cada versión.

En cuanto el número de usuarios comienza a despegar, también lo hace el número de variaciones. Jochen Merz sirve una copia de SMSQ/E a un usuario de Gold Card: al día siguiente hay un mensaje “SMSQ/E no funciona con el teclado XXX”. No es sorprendente, el teclado XXX usa una versión parcheada de la ROM JS. ¿El remedio? Otro módulo de controlador de teclado para las Gold Card y Super Gold Card y otro módulo de idioma (las tablas de teclado). El resultado neto es un nuevo usuario y cuatro nuevas variaciones. Contar variaciones pronto va a ser como contar canicas en un tarro de galletas.

“Hasta que la muerte nos separe”

En los días del divorcio fácil por incompatibilidad de caracteres, es sorprendente encontrar tantos usuarios de QL casados firmemente con los viejos paquetes de software del estilo “úsalo en tu propio riesgo”. Entonces comencé la evaluación de SBASIC, Miracle Systems me envió un manojo de disquetes (unos 10 Mbytes) del tipo de software que ellos pensaban que podría servir de prueba de compatibilidad de SBASIC.

Empecé a mirar los discos en el Atari ST con JS y los controladores de nivel E. Después de reiniciar el Atari ST por décima vez sin haber encontrado ningún software que ni siquiera empezara a funcionar, abandoné y probé a usar una Gold Card.

Después de un día o así, encontré dos programas que podían ser ejecutados, jugar con ellos y terminados sin colgar el sistema. Todos los demás o se colgaron justo al empezar, o no se podía hacer nada sensible, o sólo se podían terminar reiniciando (empiezo a entender por qué algunos usuarios han estado pidiendo un reinicio rápido). Me han contado que mucho más software habría funcionado si hubiese establecido el tamaño de memoria a 128Kbytes, pero si vas a reiniciar la máquina a 128Kbytes, usar un programa y después reiniciar otra vez, no hay punto en absoluto en usar SMSQ: también podrías aguantar con QDOS en tu viejo y fiable QL. En serio, ¿alguien usa este tipo de software aún?

Las primeras pruebas de compatibilidad fueron muy alentadoras: todos los programas que se colgaron en un QL con JS se colgaron con SMSQ. Parecía que habíamos obtenido más del 95% de compatibilidad. Es más, uno de los dos programas que funcionaba en el QL funcionaba con SMSQ: la figura subía a un 98% de compatibilidad.

“Lámparas nuevas por las antiguas”

Una de las mejores formas de comprobar la originalidad del software es investigar los errores. Si dos elementos de software desempeñan las mismas funciones correctamente, uno podría ser una copia del otro, o podrían estar ambos escritos según la misma especificación. Si, en cambio, dos elementos de software exhiben los mismos errores, se puede asumir que uno está copiado del otro.

Hay muy pocos errores de “primer nivel” (errores que impiden que el sistema funcione correctamente bajo condiciones “normales”) en QDOS. Debido a la política GIGO y el deseo de reducir la comprobación de errores al mínimo para mantener la eficacia, hay un número mucho más grande de errores de “segundo nivel” (donde el sistema se comporta mal cuando se le pasan parámetros o estructuras de datos incorrectos) e incluso más “agujeros” (donde una llamada a una función del sistema con parámetros deliberadamente incorrectos tiene un efecto bizarro reproducible).

Durante las pruebas de SMSQ y SBASIC, un gran número de errores de segundo nivel fueron descubiertos en las ROMs JS. Muchos de éstos se asomaron también en Minerva, ninguno en SMSQ o SBASIC. De vez en cuando, los usuarios descubren un número de errores de segundo nivel en SMSQ y SBASIC. Todos éstos eran totalmente nuevos y no tenían conexión con los viejos errores de la ROM del QL: ¡SMSQ y SBASIC son enteramente originales!

Reestructurar el código tiene el efecto de eliminar, alterar o introducir agujeros. No es sorprendente, por lo tanto, encontrar que muchos de los agujeros que son explotados por algún software común, han desaparecido o han sido alterados en Minerva (dando lugar a quejas por problemas de compatibilidad).

Uno de estos casos es el vector SuperBASIC xx.xxxxx que es el mismo en todas las ROMs de QL. Se supone que este vector será usado con estructuras de datos creadas por el intérprete SuperBASIC. Éste tiene tres caminos definidos controlados por el valor de un byte (0, 2 ó 3). Alguien descubrió que se podía conseguir producir un efecto bizarro si se pasaba un valor de 1 en el byte de control. El fragmento de código resultante (que es más grande que usar una llamada legítima) ha sido incorporado en una utilidad, que ha encontrado camino en un número más grande de programas para el QL. El código reestructurado de Minerva ya no tenía este agujero así que una gran cantidad de software dejó de funcionar en Minerva. El Mago no consiguió encontrar al auténtico villano en el código, pero tuvo éxito en recuperar la “compatibilidad” asignando a un registro un valor que tendría normalmente con SuperBASIC. Esto, a su vez, alteró otro agujero e introdujo diferentes problemas de compatibilidad.

En SBASIC, sin embargo, el agujero nunca existió. Una vez que el código villano había sido identificado (el trabajo de una semana) era, por lo tanto, una simple cuestión de detectar el caso villano y emular el agujero directamente. Era una pérdida de tiempo y esfuerzo, y ralentizaba SBASIC, pero eso es de lo que se trata, ¿verdad?

La frontera entre un error y un agujero es muy fina y si algún software depende de un error en la ROM del QL ¿necesito reproducir este error? Desafortunadamente, la respuesta es a veces GRRRRRR SÍ.

Dos veces recientemente, he recibido informes de “errores” que han aparecido en el manejo de cadenas en versiones recientes. Estos “errores” han sido introducidos en SBASIC para mejorar la compatibilidad con SuperBASIC (todavía hay tres “errores” en el manejo de cadenas de SuperBASIC que no están emulados en SBASIC). Ninguno de estos usuarios estaba enterado de que los errores existían en SuperBASIC: SBASIC se está usando ahora donde SuperBASIC nunca lo fue antes.

“En cualquier caso, ¿de quién es el fallo?”

Una carta bastante técnica se quejaba de que SBASIC era muy frágil en comparación con SuperBASIC: al usar una pieza de software comercial bien conocida: “SBASIC se colgaba”. Esto era enfocar erróneamente la culpa. Puesto que el software era invocado correctamente por SBASIC y nunca volvía a SBASIC, SBASIC difícilmente podría tener la culpa.

Esta bien conocida extensión de SuperBASIC comenzaba tratando de identificar un fragmento de la ROM del QL, y, cuando no podía encontrar ningún código de ROM de QL (no hay ninguno en SMSQ), saltaba a una dirección completamente arbitraria. BANG. El remedio: Reescribí la extensión y la incorporé (con mejoras) en SBASIC.

De hecho, SBASIC es más robusto al respecto que SuperBASIC: la captura de errores es mucho más rigurosa (y contundente). Si hubiera sucedido en una SBASIC hija: podría simplemente haber sido eliminada sin ningún efecto lateral perjudicial. (Quizás debería implementar un “reinicio” por teclado para el Job 0.)

Otra diferencia entre QDOS y SMSQ que podría dar la impresión de que SBASIC es más frágil que SuperBASIC es el manejo por defecto de errores: QDOS continúa pero SMSQ se para para permitir que se lance un depurador. Si el trabajo ya está monitorizado por un depurador, no hay diferencia. En el estado normal, sin embargo, permitir continuar a un trabajo que ha producido una instrucción ilegal o errores de direccionamiento podría fácilmente terminar en un daño generalizado a las estructuras de datos del sistema, posiblemente resultando en la pérdida de parte o todos los datos de un disco duro. SMSQ es, por lo tanto, mucho más seguro, incluso si los trabajos parece que se paran más a menudo.

Muchos programas compilados con la versión actual de Turbo son ejemplos maravillosos de esto. Al comienzo de estos programas encontramos algo de código que asigna 0 a una posición de memoria. Más tarde en varias ocasiones, el valor de esta posición se mueve al registro A2 y entonces hay una instrucción que mueve el contenido de la dirección 0 (A2) a D4, se compara D2 con el nuevo valor de D4 y entonces hay un salto condicional.

MOVE.W (A2),D4

....... .......

SUB.W D2,D4

BLT.S ......

En el QL el MOVE asigna 3 a D4 de modo que la operación del código depende de si D2 es mayor o menor que 3.

En los Atari ST modificados para el antiguo emulador de QL, el MOVE asigna 24.622 a D4. El comportamiento de este código Turbo será, por lo tanto, significativamente diferente en estos STs ya que la operación ahora depende de si D2 es mayor o menor de 24.622.

En los STs no modificados y con una versión parcheada de las ROMs JS, el MOVE causará un “bus error” que QDOS ignora de modo que la ejecución continuará sin cambiar el valor de D4. D2 es, por lo tanto, comparado con un valor desconocido: esto dará un comportamiento diferente, y bastante impredecible, de los programas Turbo.

En STs no modificados y con SMSQ, el MOVE es atrapado y estos programas Turbo se paran. Es posible establecer un “modo Turbo” especial (PROT_MEM 0) que emula el acceso de la ROM del QL asignando 3 a D4 y continuando. El comportamiento de los programas Turbo en estos STs es, por lo tanto, el mismo que en un QL: ¡SMSQ es más compatible con el QL que QDOS!

“No Veo las Naves”

Mientras SMSQ con SBASIC marca una gran mejora en rendimiento y capacidad sobre las viejas ROMs de QDOS, esto no se ha conseguido sin crear unos pocos problemas. El SMSQ y SBASIC original tenía muy pocos errores intrínsecos, pero muchas incompatibilidades. Desafortunadamente, uno de los hechos de la vida de la computación es que hacer cualquier cambio a un software existente bordea el vandalismo. La clara estructura de la concepción original empieza a desmoronarse y pronto cada pequeño “arreglo” tiene el riesgo de introducir una multitud de nuevos problemas. Arreglar cada uno de éstos introduce más. Es un tributo a la concepción del SuperBASIC original de Jan Jones que durante los primeros días de “desarrollo activo”, cuando se añadían nuevas características cada día, la razón de cambios a errores introducida era de más de 10:1.

SBASIC es una pieza de software mucho más compleja que tiene la desventaja de que se le requiere que emule todas las peculiaridades del primer intento de alguien de escribir un intérprete BASIC. Empieza, por lo tanto, no siendo muy claro y tiene tendencia a degenerar más rápidamente. La razón de cambios a errores de SBASIC introducida está más cercana a 5:1 – suficientemente pequeña para ser convergente, pero demasiado grande para la comodidad.

Afortunadamente, los errores introducidos desde la versión 2.11 (SBASIC experimental) hasta la versión 2.25 (la primera versión “liberada”) a la versión 2.42 (actual en el momento de la escritura) han sido habitualmente menores que los que sustituían.

Aunque algunos problemas de compatibilidad con algunas variaciones de hardware siguen sin estar resueltos y hay uno o dos programas que todavía se resisten a funcionar con SMSQ, las aspiraciones originales de compatibilidad y rendimiento han sido bien excedidas y SMSQ se establece a sí mismo como un sustituto viviente del QDOS.

Así que, ¿es SMSQ/E al fin estable? La respuesta debe ser no. A medida que más y más gente empieza a usar SMSQ/E hay más y más requerimientos de mejoras (esto es, disminuyendo la compatibilidad). SMSQ/E ahora ha pasado el punto sin retorno: hay más requerimientos de capacidad mejorada que de compatibilidad mejorada. Las versiones actuales de SMSQ/E son al menos tan fiables como cualquier versión ROM de QL y están consiguiendo estar tan cerca del 100% de compatibilidad como es posible mientras proveen mejor rendimiento y más servicios.

SMSQ/E es un producto comercial y como tal necesita satisfacer las demandas de los usuarios. Si los usuarios requieren cambios, y es comercialmente viable proveerlos, los conseguirán. SMSQ/E no puede, sin embargo, ser desarrollado en todas las direcciones a la vez.

Para el desarrollo de software, un Mega STE basado en un 68000 a 16 MHz (1 MIP con 2 Megabytes de memoria) corriendo bajo SMSQ/E (mi configuración “estándar”) es más que una pareja para una estación de trabajo “estándar” de 50 MIP y 32 Mbyte. Un TT o una QXL en una buena máquina 486 es más impresionante aún. Las Gold Card y Super Gold Card tienen los mismos estándares de rendimiento en bruto, pero sufren de capacidades de pantalla limitadas, teclado y E/S pobres.

¿Qué más es razonable hacer con SMSQ, que, por su necesidad de compatibilidad con un ordenador de 10 años, está bloqueado en un diseño de 10 años? ¿Hay suficiente interés en el tipo de conceptos de sistema operativo liderados por QDOS para hacer que merezca la pena producir un sistema completamente nuevo? El futuro depende de tu respuesta.