jueves, 22 de septiembre de 2011

Temas

Se han escrito muchísimos comentarios acerca de lo soso que era el escritorio de ReactOS, de lo simple que parecía. Y no os faltaba razón: El (único) tema aplicable a ReactOS recordaba demasiado a los antiguos Windows 95/98, y a Windows 2000. Y mucho ha llovido desde entonces.

Y he dicho único, porque el responsable de que no pudiera ser de otra forma era el inexistente soporte para temas de Windows. En parte fue pensado así a propósito (necesitamos algo muy simple y de fácil implementación para poder empezar a hacer algo, y además, un sistema operativo debe presumir de consumir pocos recursos), pero, tarde o temprano, ésto debería cambiar.

Otro de los estudiantes que ha participado en el programa Google Summer of Code, y que también colaboraba con ReactOS previo a este evento, Giannis Adamopoulos (Smiley), es el encargado de hacer realidad esta multitudinaria petición.

martes, 13 de septiembre de 2011

ReactOS en la web de la BBC

Al ser esta una noticia muy importante para el proyecto, se merece una entrada aparte en el blog, además de las habituales. Es un post rápido, hecho para vosotros. Y es que ReactOS empieza a ser reconocido internacionalmente, como se puede ver en este enlace. No dejéis de visitarlo:

http://www.bbc.co.uk/news/technology-14899507

domingo, 11 de septiembre de 2011

APIC

Como sabéis, ReactOS está aún en fase alfa, lo que implica que no está completo, y le faltan características. Una de ellas, que no es muy visible para el usuario normal, pero que sí es muy importante, es el soporte APIC.

¿Qué narices es eso del APIC? Para resolver esta pregunta, nadie mejor que el desarrollador que lo está trayendo a ReactOS. Hemos podido hablar con Timo Kreuzer (tkreuzer) sobre el tema, para que nos ayude a comprender mejor el funcionamiento de este elemento del sistema.

Advanced Programmable Interrupt Controller

"Controlador Programable de Interrupciones Avanzado", en su traducción al castellano. Las interrupciones son señales que pueden ser enviadas por software, o por los dispositivos, cuando requieren ejecutar operaciones de E/S. Para controlar estas señales, los equipos con arquitectura x86 implementaron originalmente un chip, llamado PIC ("Programmable Interrupt controller", o Controlador Programable de Interrupciones ).

Con la introducción de los sistemas multiprocesador, se añade una nueva gama de interrupciones al sistema: aquellas que van de un procesador a otro. Son las interrupciones IPI ("inter processor interrupt"). Así que se añadieron nuevos chips para manejar esta información: los chips APIC.

¿Dos chips? En realidad el sistema APIC siempre se cuenta como una sola entidad. O se habilita, o no se habilita. Pero Este sistema consta de dos elementos:

  1. APIC local. Este chip no es visible en ninguna parte del sistema, porque va integrado dentro de la CPU. Es responsable del manejo de interrupciones dentro del procesador, y el envío de las mismas a otras CPUs en caso necesario.
  2. IOAPIC (o "I/O APIC"). Es un chip dedicado en la placa base, que puede ser programado para recibir interrupciones del hardware de la máquina y enviarlos al chip APIC local de cada CPU, o incluso a una CPU dedicada.
Como hemos dicho anteriormente, APIC es un subsistema requerido en entornos multiprocesador, dado que se necesita de un sistema que interconecte los procesadores, y que maneje las interrupciones entre ellos. Esto también incluye a los nuevos procesadores multinúcleo, ya que emulan varias CPUs en el sistema. También es requerido en la arquitectura x64. La especificación de dicha arquitectura requiere de la presencia del controlador APIC. No ocurre lo mismo en la arquitectura x86. En este caso, el soporte APIC es opcional (a menos que se haga uso de varias CPUs).

La contrapartida más importante la tenemos cuando se usan máquinas virtuales. Hay que tener presente que la máquina virtual convierte las señales que ejecuta el equipo huésped a aquellas que el anfitrión puede manejar, y viceversa. Esto de por sí ya supone una gran carga de trabajo. Pero si además a ello le unimos las interrupciones APIC, que son muy numerosas, tenemos como resultado una gran ralentización del sistema. ¿es esto un fallo del huésped, o del anfitrión? No, no significa que sea un bug. Sencillamente, muestra el gran número de interrupciones que el sistema realiza en cada ejecución.

viernes, 2 de septiembre de 2011

Kernel mode test suite: Lo que nos diferencia de Wine

Sabido es que el proyecto ReactOS utiliza en gran medida código de Wine, sobre todo en forma de librerías y bibliotecas DLL. Para testear dichas librerías, el proyecto Wine tiene sus propias suites de pruebas, llamadas Winetests. Y dado que ReactOS utiliza librerías de Wine, desde luego, también debería usar sus programas de prueba. Y lo hace: ReactOS usa los Winetests en sus sistemas de testeo automatizado.

Pero el proyecto Wine tan sólo pretende recrear el comportamiento de un sistema Windows en modo usuario. Es decir, pretende simplemente que las aplicaciones Windows que se ejecuten en modo usuario, funcionen. Desde luego sabemos que no es nada fácil, y la labor que realizan los chicos de Wine es inmesa y extraordinaria.

Entonces, ¿qué pasa con los drivers? Éstos son ejecutados en modo núcleo (kernel mode). No forman parte del proyecto Wine, pero sí de ReactOS. Y si no forman parte del proyecto Wine, Wine no puede proporcionarnos sus Winetests. Y aquí es donde entra en juego Google Summer of Code.

Un estudiante alemán, Thomas Faber (ThFabba), que ya había colaborado anteriormente con ReactOS implemmentando código, presentó una suite de pruebas al estilo Winetests, pero diseñada específicamente para código en modo núcleo. No hace falta decir que, de hecho, ha sido diseñada específicamente para ReactOS.
Esta nueva suite proporcionará a los desarrolladores una herramienta con la que podrán comparar su código con el comportamiento de Windows, y hacerlo más compatible, permitiendo, entre otras cosas, el corregir aquellos defectos que hacen que los drivers sigan fallando en ReactOS.

Dicho de otra forma, se acercan buenos tiempos para nuestro SO... :)