 |
|
||||||||||
| Blog | Archivo | Contacto | Administración |
Acerca de
Matemático, informático, aficionado a la electrónica, friki... y otras cosas que no vienen a cuento ni pasan los filtros de palabras.
¿Queríais un blog? Ahí va.
Red antisocial
¡Me van a volver loca! 2.0La Fragata Portuguesa
Z
¡Me van a volver loca!
Últimos posts
El expediente X que nadie pidióeNigma
La cuadratura del píxel
Portando desde Spectrum
Inexorable
Últimos comentarios
HabiNoSupoResolverLaFuncion
Edu
Habi
EnriqueGG
Calendario
No hay fechas.
Categorías
ChorradasParanoias
Posts lúcidos
Tecnoesoterismo
Yuyus
Cenas de Abj
Abj debe 7 cenas.
Frase célebre
Habi dice: Cada persona debería hacerse su propio SO, su propio compilador y su propio sushi.
Malkari
Habi - 
06/01/2009 3:15:04 - TecnoesoterismoHace poco descubrí un juego antiguo de estrategia espacial para Windows que no conocía: el Malkari; así que me dispuse a probarlo de inmediato.
(NOTA: Esto no es lo que parece... no es una reseña.)
No obstante, este juego no funciona en Vista, ni con modos de compatibilidad ni nada, así que me puse a experimentar con él. Haciendo pruebas, comprobé que tampoco era posible hacerlo funcionar en XP, y claro está tampoco en 2000. Sin embargo, en 98 y ME iba perfecto.
¿Por qué no funcionaba en núcleos NT? ¿Qué operación no válida era la que causaba su cierre?
Movido por la curiosidad, le metí un depurador. Cuando se produjo el error vi exactamente qué estaba ocurriendo: estaba accediendo (escribiendo) a una dirección de memoria en el proceso un poco más allá de 0x000B0000.
Por si no lo saben, el Windows mantiene cada proceso en un espacio de direcciones separado. Lo normal es que por la parte baja estén algunas tablas del SO, la aplicación empiece sobre los 16MB y de los 2GB (3GB si se usa cierta opción) en adelante esté el monitor de Windows, con gran parte del código y datos compartidos entre todos los procesos.
Una diferencia fundamental y poco conocida entre los núcleos 9x y NT es que los primeros además mapean la mayor parte de la memoria DOS por debajo del primer MB, compartida además entre todos los procesos. Así es más fácil y exacta la emulación del DOS y además proporciona una cierta capa de compatibilidad para aplicaciones de 16 bits y algunas de 32 antiguas. Por eso este acceso a la memoria no falla en núcleos 9x.
¿Y qué hay en esas direcciones? Pues ese el rango de direcciones de la memoria de video de texto monocromo, una MDA, para la cual no hay drivers de Windows y por tanto los accesos no se virtualizan; ni tampoco se bloquean, por estar mapeada la memoria.
En los tiempos del DOS era una práctica común usar una MDA junto con otra tarjeta gráfica para depurar una aplicación, ya que el rango de monocromo era siempre ignorado por la misma y quedaba libre para el depurador. Es la primera vez que veo esto en Windows, por parte de una aplicación, para sacar sus mensajes de depuración; con lo simple que es usar OutputDebugString o escribir los resultados a un fichero.
La solución es trivial, bien parchear el ejecutable o crear un lanzador que tras crear suspendido el hilo primario del proceso mapee la memoria con VirtualAllocEx. Sigue fallando tras eso por otras causas triviales y fácilmente corregibles, pero eso... es otra historia, como bien dijo el narrador de Conan.
Post cerrado