- Descripción
- Personal de ReactOS
- Foros
- Wiki
- Listas de Correo
- Canales IRC
- Boletines de Noticias
- Blogs
- FAQ de Usuarios
Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 67
Newsletter 67
by Z98 on 2009-12-09
translated by Gabriel ilardi on 2009-12-11
Depuracion
La ultima vez que hemos hablado del soporte para WinDBG ha sido un ano atrás aproximadamente. El primer paso necesario era un kernel compatible con WinDBG, lo cual ha sido logrado con la ultima re-escritura del mismo hecha unos dos anos atrás. Las características que hacían falta giraban entre manejar el contexto de ejecuci6oacute;n de un "thread" y la lectura de la memoria virtual. Si bien la re-escritura del kernel esto lo había resuelto, había todavía algunos fallos que impedían su uso. La depuración necesita interrumpir el flujo del thread en ejecución pero también restaurarlo para permitir al programa que se esta depurando de continuar. Uno de los fallos corrompía el contexto de ejecución y finalmente como consecuencia colgaba cualquier cosa que se estuviese depurando. Otro problema era la HAL que trataba de mapear la primera pagina física usando el administrador de memoria. Esto fallaba porque la función en el administrador de memoria hacia una sincronización adicional, cosa que non funcionaba si la HAL estaba siendo ejecutada en un contexto de depuración luego del reinicio. Cuando se ejecuta en tal contexto de depuración, no hace falta ninguna de las operaciones de sincronización que se hacían, ademas existía el riesgo de que los bloqueos en cuestíon fuesen ya hechos por algo más. Esto podía resultar en un deadlock y congelar el sistema. Con estos problemas y otros resueltos, Stefan logró conectarse al kernel de ReactOS con WinDBG y realizar acciones como poner un breakpoint, leer I/O y memoria. Sin embargo, para poder conectarse con ReactOS ha tenido que usar el driver KDCOM de Windows 2003.
La razón por la cual Stefan ha usado el driver KDCOM de Windows 2003 era porque el KDCOM de ReactOS simplemente no funcionaba correctamente en el momento en que Stefan empezó su trabajo. A pesar de los esfuerzos de Timo Kreuzer para hacerlo compatible, no había llegado aun al punto en el cual podíamos contar con él y no tener que investigar en que punto fallaba la comunicación entre KDCOM y el kernel. En el mismo momento en que Stefan se interesó por el soporte WinDBG, Timo continuó su trabajo en el driver KDCOM de ReactOS en el branch x64. Una variedad de cuestiones de timing causaban problemas como caracteres faltantes y paquetes descartados, especialmente aquellos de grandes dimensiones, y hacían que el driver fuese poco fiable. Timo agregó controles y manejos de errores adicionales para compensarlo. Una cosa rara derivada del problema de timing era que algunos intentos de escribir en el puerto serie fallaban porque el periférico decía que no estaba listo para enviar, aunque controlando el estado devolvía listo. La solución actual de Timo simplemente agrega un retardo que parece dar el tiempo necesario al puerto serie para aceptar datos, pero esta solución esta lejos de ser la ideal. La plataforma de testeo de Timo es actualmente VirtualBox, la cual tiene una historia de problemáticas de salida a través del puerta sere. El proyecto VirtualBox parece planear una re-escritura de la implementación del puerto serie, que afortunadamente resolvería los problemas que nuestro proyecto ha experimentado y permitiría probar KDCOM y WinDBG en manera mas fiable.
topShell
La shell con la cual los usuarios interactúan es en realidad varios componentes conectados entre si, motivo por el cual una re-escritura no resulta trivial. Ademas de la shell explorer misma están las librerías shell32, browseui, comctl32, y shlwapi, solo por nombrar algunas. En ReactOS, gran parte de la funcionalidad de las librerías se encuentra en la shell explorer porque estas inicialmente no existían. Esto se debe a la herencia de Wine de explorer y al hecho que Wine en realidad no necesita una implementación shell32. Un ejemplo de la funcionalidad que hemos mencionado es el menú inicio mismo. Este no está implementado en realidad en explorer, solo expuesto por el mismo. Otra cosa es el sistema de menú. Tradicionalmente los menús son administrados por user32 en las aplicaciones Windows, pero la shell tiene en realidad unos menús personalizados que se manejan separadamente. Pocas aplicaciones además de una shell usan estos menús por ello su falta ha pasado desapercibida, aunque si alguien trata de utilizar una shell alternativa inmediatamente se daría cuenta de la funcionalidad que falta.
Andrew Hill ha pasado los últimos meses investigando el sistema de la shel en Windows y aquello que falta en ReactOS. Ha logrado compilar con Visual Studio y ejecutar en Windows XP varias librerías relacionadas con la shell así como también explorer_new, el candidato para sostituir a la actual shell de ReactOS. Esto le ha permitido encontrar funcionalidad especifica ausente asi como tambien funcionalidad existente pero que no esta en el lugar adecuado. Un ejemplo de esto es la falta del menú inicio, uno de esos menús personalizados no manejados por
user32. Su objetivo actual es lograr que explorer_new se comporte en modo idéntico a la shell de XP y luego reintegrar su trabajo en ReactOS.
Nuevos desarrolladores
Andrew Hill ha sido mencionado antes y ha estado con nosotros por varios meses, pero ha preferido pasar desapercibido mientras investigaba. Inicialmente ha trabajado con Ged Murphy para prepararse al trabajo y últimamente ha iniciado ha hacer committs de los frutos de su trabajo. Su nick en IRC es ash77, aunque lo verán probablemente con |away al final, independientemente de su actual presencia o no.
Otro nuevo desarrollador que se nos ha unido es Giannis Adamopoulos, conocido como smiley_ en IRC. Giannis ha sido un visitante asiduo de IRC por algún tiempo. Su interés primario yace en el lado kernel del subsistema Win32 y estará ayudando a implementar funcionalidades ausentes.
La reciente afluencia de nuevos talentos ayudara seguramente a ReactOS a avanzar, pero todavía hay tanto trabajo que hacer para el cual sería útil una ayuda. Estamos en el punto donde la re-escritura de componentes viejos y rotos está lo suficientemente completa como para permitir la adición de nueva funcionalidad. Lo que ayudara a ReactOS a ser más compatible, claro, los recursos son escasos y hay tanto por hacer. Afortunadamente el numero de desarrolladores continuará a crecer a medida que el proyecto madure.
top
