CAAD

No, no lo he leido bien. Efectivamente estamos duplicando trabajo, y de hecho tú vas más avanzado. Lo verdaderamente preocupante es esa llamada a glk, que por lo que veo el parche aplicado simplemente manda la escritura al limbo, por lo que las pocas funciones que la leen, fallan (el caso de SAVE que has puesto).

Parchear en :nombreanterior como he dicho es necesario, pero al tiempo es muy fácil.

Parchear las llamadas a GLK no tanto, pero supongo que se generará algo como 0x130 0x?? ox?? 0x00 (siendo 0x130 el opcode de 'glk'). Parchear esas llamadas es relativamente fácil, pero además habría que detectar los casos en los cuales después hay un jz o un jnz, que no son muchos, para parchearlos también. Tampoco es que sea imposible, pero me preocupa más saber en que lugar de la RAM podría ponerse eso sin pisar nada. No me queda muy claro como trabajan los intérpretes de Glulx por lo que no me arriesgaría a buscar la ultima dirección utilizada, si es que se puede, y ponerla justo encima, porque lo mismo se hace un malloc justito y la liamos. La única solución en ese caso es machacar algo, pero la posición de todas las demás variables es variable así que creo que la mejor manera de hacerlo es machacar la primera instrucción o esa de las funciones glulx que hay justo detrás del :main, dado que incluso si le damos a "jugar otra vez" saltamos justo detŕas de eso,así que no importa machacarlo:





¿Y donde está eso localizado exactamente? Pues la dirección está en la cabecera de Glulx, en el apartado "Start Func".

Es decir, si StartFunc = 0x7823 habría que cambiar todos los

0x130 ? ? 0x00

por

0x130 ? ? 0x7823

y si luego hay un jz, jnz o lo que sea, cambiar el

jz (0)

por

jz ( 0x7823)

Notese que no se como se almacena eso en memoria, obviamente en un byte no hay un 0x7823 pero no se si se graba como 0x78 0x23, 0x23 0x78, o incluso 0x00 0x00 0x78 0x23 que se trata de una máquina de 32 bits.

No se si le gustará a los interpretes que se machaque la cabecera de la funcion main (el dc.b) pero en el peor de los casos se puede machacar el setiosys, que no hace ya falta para nada, o sea (Start Func + 3)

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com

El lugar natural de destino de la falsa glkresult es la existente glk_result. Tengo un método para obtener su dirección desde el binario, a partir de una llamada correcta que existe. La encuentra en todas las aventuras.

Tengo bastante avanzado un script de parcheo, de forma que todo sea automático. Ya soluciona varios errores. Analizaré lo de nombreanterior, porque seguramente provoca el error que todavía obtengo en las obras parcheadas. Hasta ahora estaba muy centrado alrededor de glk y compañia, con buenos resultados.

Enhorabuena, dddddd. Me alegro de que estés pudiendo avanzar aun sobre los binarios cuyos fuentes no están disponibles.
Este trabajo ameritaría un «artículo técnico» en el SPAC.

Ah genial, en ese caso desde luego es el mejor sitio



Sin duda, corresponde al opcode copy que han parcheado recientemente Zarf y Kinder. Lo bueno es que ese debe ser fácil de localizar por el contexto.

El de canal_sonido que debería ser canal_efectos puede que lo puedas parchear también porque la llamada a glk es única, y poco antes de esa llamada tienes la de :canal_musica, que por suerte es la variable anterior a canal_efectos. Este caso de todos modos no es peligroso en cuanto a que dé error el interprete, pero ya que estás...

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com

Superglus beta 2 (24apr2004) localizada en:

ftp://ftp.funet.fi:21/pub/mirrors/ftp.i ... superglus/

Me la guardo, aunque sea porque esa tendrá además el asunto de los opcodes.

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com

Las instrucciones del juego se consideran --si entiendo bien-- ROM, así que esta opción no sería válida. Aunque ya encontramos alternativa, saco el tema de nuevo porque...

En World of Witchcraft hay un problema extra, ya que parece que el autor utiliza algún truco de reescribir su propio código en tiempo de ejecución, o de utilizar un espacio que ha se dejado entre instrucciones para almacenar algún dato (quizá alguna creación dinámica de objetos). No tengo muy claro lo que pretende, pero debido a ello me parece que el parcheo de esta obra no va a ser posible en primera instancia, puede que nunca. Necesitará un intérprete que no compruebe ninguna escritura en ROM.




Es un poco más complicado que directamente el número de opcode. Hay unas reglas que indican cómo se codifican. En concreto, se representa como 0x81 0x30.

http://eblong.com/zarf/glulx/glulx-spec_1.html#s.5
1.5 Instruction format.


El opcode glk es la primero que parcheó zarf (envío al limbo) en glulxe, antes del añadido de DavidK. Commit 2e182f091461.


Sí, este opcode copy es el que parcheó DavidK y efectivamente es el culpable del error en tiempo de ejecución tras introducir un comando en el juego.

Superglús 1.0 tiene el cambio que mencionas:
Así que parece razonable (y ha funcionado bien) parchear con NOPs.


Como bien decías, es relativamente fácil encontrar la dirección buena. Esto también lo parcheo y mejor reaccionará a la creación del canal.

Entre hoy y mañana te paso una primera versión del script, por si ves algo raro. Por cierto, ya tenemos nombre adecuado para las circunstancias, gracias a la genialidad de Al-K:

Arreglús

Fantástico trabajo el de Arreglús

Lo del Witchcraft me suena un poco raro: Superglús no tiene de por sí posibilidad de meter cosas entre condactos, por lo que cualquier cosa que pueda haber metida por medio de algo ha tenido que ser un retoque de las librerías, lo cual no considero imposible dado que el autor tiene una maña bien conocida, pero sinceramente mi impresión es que ya no es que no pudiera, sino que en la época que creó esto no estaba en esa fase de tocarlo todo, y especialmente teniendo en cuenta que hablamos del puñetero assembler de Glulx. Quizá me equivoque, lo mismo él mismo puede decirnos algo si nos lee.

En cualquier caso, si me puedes dar más detalles al respecto de ese punto quizá se me ocurra algo.

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com

En cuanto al Witchcraft, por suerte el hecho de que el autor haya sacado Héroes de la mazmorra en 2010, época en que Superglús ya no generaba estos binarios que escribían en la ROM, importa que de no ser posible el parcheado en primera instancia junto con las demás obras éste pueda esperar. Y es que en definitiva Héroes de la mazmorra tiene el mismo contenido que Witchcraft y más: jugar con múltiples razas con algunos quests distintos según la elegida, multimedia, hechizos adicionales, guardado y cargado en y desde memoria además del clásico en disco, y alguna cosa más.
No digo que existiendo la primera encarnación de lo que años después sería Héroes de la mazmorra haya que coartar la libertad del usuario de jugar si quiere a esa primera encarnación —adecuada para dispositivos como celulares o tabletas en que por espacio de almacenamiento o uso de otros recursos se prefiera jugar sin multimedia—, pero sí que, existiendo una obra sucedánea que aparte es del mismo autor, afortunadamente se puede esperar para el parcheo mientras se estudia la especial composición de su binario.