lunes, 15 de noviembre de 2010

News: Reescritura del Heap Manager

329397A01

Antes de leer esta entrada es altamente recomendable leer : Heap!Heap!Manager.

Una de las sorpresas que teníamos guardadas y que se iban a presentar en la cancelada OSWC era el nuevo Heap Manager.

Tras la cancelación del evento se ha decidido integrar el nuevo Heap Manager en el trunk


PS: Esta entrada debería haber sido publicada hace 2 días, sin embargo una importante noticia nos ha tenido liados durante todo el fin de semana. Estamos investigando una posible violación de código GPL de ReactOS por parte de una importante empresa de software. Os mantendremos informados.



El Heap Manager

 


Como ya sabéis ReactOS tiene implementado un Heap Manager muy básico que no sigue las especificaciones del NT Heap Manager que tomamos como referencia. Este hecho imposibilita que ciertas aplicaciones de gran envergadura, como puede ser el Office2003, funcionen correctamente o ,que si lo hacen, puedan en cualquier momento dar un error y cerrarse automáticamente.


¿Le suena a alguien el error “Memory could not be read or written”?Una de las posibles causas es una mala gestion por parte del Heap Manager ( o también puede ser un problema en capas inferiores como el Memory Manager o problemas a la hora de cargar una DLL)

El antiguo Memory Manager era un coladero de bugs, mientras que el Heap Manager lo considerábamos lo suficientemente bueno para correr aplicaciones.De nada sirve tener un perfecto Heap Manager si debajo  tenemos una capa inestable como el Memory Manager.

Pero entonces llegó sir_richard y el ARM Team y reescribieron el Memory Manager (codename: ARM3), lo que convertía al Heap Manager en el eslabón débil de la cadena. Entonces  reescribir el ReactOS Heap Manager se convirtió en una necesidad básica.


De nada sirve tener un Memory Manager perfecto si luego en la última capa tenemos decenas de bugs. Se habían vuelto las tornas.

En “secreto” Aleksey Bragin (Fireball) ha estado preparando esta sorpresa que íbamos a desvelar en la OSWC. Como la conferencia fue cancelada, pero el trabajo ya estaba hecho, se ha decidido incluirlo inmediatamente en el trunk.





Integración no activa.

 


´La integración al Trunk (árbol principal de desarrollo) se ha realizado de manera inactiva. Esto quiere decir que en las ISOS de ReactOS coexisten dos Heap Managers. Uno activo, el ReactOS Heap Manager y otro durmiente,el nuevo.

Actualmente nos encontramos añadiendo nuevo código crítico tanto en el Memory Manager como en Yarotows. Para evitar mezclar problemas y regresiones, se ha decidido retrasar la activación del nuevo Heap Manager. Si añadiéramos todo de golpe sería mucho mas complicado entender quién o dónde se ha producido la regresión.

Sin embargo, el nuevo Heap Manager está activado en Arwinss sustituyendo al antiguo. De esta manera podemos comparar el comportamiento de las aplicaciones en ambos Heap Managers.

El nuevo Heap Manager, en Arwinss, ha demostrado un comportamiento mucho más fiable y compatible, pero también un par de bugs que en estos momentos Fireball se está encargando de solucionar.









 
 

3 comentarios:

  1. Enhorabuena, nuevas cosas agreagadas.

    Respecto a la violación del codigo, una pregunta al aire: Quien podría ser? Pues quieM $abe. ^_^

    Saludos

    ResponderEliminar
  2. @Anónimo

    Presuntamente sería una famosa compañía de software dedicada a los temas de seguridad.
    De momento son presuntos violadores hasta que confirmemos lo que parece evidente.

    ResponderEliminar
  3. Una pregunta al autor del blog: ¿Qué empresa es la que es posible que esté violando el GPL de ReactOS?

    ResponderEliminar