El Blog de ReactOS

Lanzada la versión 0.3.14 de ReactOS

2012-02-08T15:21:00.005+01:00

Ayer (¡por fín!) se publicó la esperada versión 0.3.14 de nuestro sistema operativo. Más de 750 errores corregidos merecen la pena el tiempo de espera, además de varias características interesantes, como son:

Integración de la pila de red lwIP en ReactOS, lo que ha proporcionado mayor fiabilidad y velocidad al sistema
Soporte WiFi, actualmente limitado a las redes abiertas (no encriptadas) y WEP. El soporte WPA / WPA-2 vendrá más adelante.
Soporte ACPI. Ahora es posible apagar completamente el equipo pulsando el botón, o pulsando la opción "Apagar" del menú de inicio.

Y bastantes más. Podéis consultar una lista resumida en la nota de prensa oficial aquí, o en el registro de cambios aquí.

Y como de costumbre, podéis descargaros esta versión desde la página de descargas del proyecto.

Acuerdo de colaboración con ISIMA

2012-02-03T11:32:00.002+01:00

ISIMA es el acrónimo de Institut Supérieur d'Informatique, de Modélisation et de leurs Applications, más o menos como una Facultad de Informática francesa. En esta institución se encuentra estudiando Pierre Schweitzer (HeisSpiter en IRC), uno de los miembros más jóvenes del equipo de desarrollo de ReactOS.

Precisamente él ha sido el promotor de esta colaboración, que incluye el desarrollo de subproyectos de ReactOS como parte de proyectos académicos, o el uso por parte del proyecto ReactOS de las instalaciones del instituto francés.

En internet tenéis colgado parte de la presentación que Pierre ofreció en su centro de estudios en vídeo (enlace) y en formato PDF (enlace).

Ojalá esta colaboración pueda dar buenos frutos para el proyecto. Tenéis algo más de información en la nota de prensa oficial del proyecto aquí (en inglés).

A vueltas con el USB

2012-01-30T18:47:00.003+01:00

Cameron Gutman y Johannes Wald siguen trabajando en el soporte USB, y por fín tenemos algunos resultados preliminares: si bien todavía no podemos tener un entorno completo de ReactOS funcionando en un USB, ya podemos instalar el sistema en nuestro disco duro portátil

Dicho de otra forma menos críptica: los archivos se copian al dispositivo USB, pero no pueden ser leídos de nuevo tras el rearranque..... pero no queda mucho para llegar a este punto.

Para lograr esto se ha contado con la colaboración de Pierre Schweitzer (HeisSpiter en IRC), quien se ha encargado de completar el Gestor de Volúmenes (mountmgr, necesario para poder asignar una letra de unidad válida a las memorias USB.

Ah, y otra cosa. ReactOS está presente, además de en Facebook, en Twitter. Echadle un vistazo cuando queráis, ¡las noticias son casi casi en tiempo real!

Creado el branch de la versión 0.3.14

2012-01-19T18:42:00.003+01:00

Y con la revisión r55011 llega lo que la gran mayoría de nosotros (por no decir todos) llevábamos esperando durante tantos meses: por fín se ha creado el árbol de desarrollo de la versión 0.3.14 de ReactOS, que esperemos sea publicada de aquí a un máximo de 2 semanas.

Lamentablemente, en este arbol sigue incluído el error bloqueante que ya hemos comentado en la antgerior entrada, ya que no ha podido ser resuelto aún. Pero también hay buenas noticias: por primera vez, ReactOS incluirá soporte para redes wifi. Este soporte viene siendo desarrollado también en un arbol alternativo al principal por Camenron Gutman, y fue fusionado en la revisión 55000. Ahora es nuestro turno, el turno de probarlo y reportar las posibles incidencias y errores que se puedan producir.

Como es habitual, a este arbol se añadiran pequeños parches como por ejemplo un fondo de escritorio, y quizá parches críticos de última hora que puedan mejorar algo más la experiencia de usuario. Esperemos que entre ellos esté el parche al bug bloqueante.

Actualización: Los desarrolladores han creado la primera imagen ISO para testear la versión 0.3.14 aquí.

La larga espera...

2011-12-31T18:53:00.007+01:00

Desde el equipo de ReactOS tenemos la obligación moral de pedir disculpas por el gran retraso que está sufriendo la esperada versión 0.3.14 de nuestro Sistema Operativo. Podemos aseguraros que la espera va a merecer (y mucho) la pena, ya que cientos de bugs, algunos de ellos críticos, han sido resueltos durante este periodo, y la estabilidad del sistema ha experimentado una considerable mejora.
Además de dicha mejora en estabilidad, la capa de red también ha sufrido algunos cambios, que han teido como consecuencia que ahora pueda navegarse por Internet de una forma mucho más fluida y eficiente.

Pero, también debemos dar una explicación a este retraso: Se trata de un bug que ha sido catalogado como blocker (bloqueante), esto es, que no puede haber publicación mientras este fallo no sea resuelto.
Efectivamente, sería un tanto negativo publicar una revisión que en bastantes casos no sería capaz de ser instalada. Y es que el bug en cuestión impide el registro de librerías en el sistema durante la ejecución de la segunda fase de instalación (comúnmente llamada 2nd stage entre los miembros del equipo de ReactOS). Podéis tener más información acerca de dicho bug en el informe de erroresd que se creó en su día al respecto aquí

Y tras esta (mala) noticia, una buena: Johannes Wald (janderwald) ha retomado su trabajo sobre la pila USB de ReactOS. Y según él, los ratones USB ya funcionan en el árbol de desarrollo secundario donde está desarrollando dicha pila. Pero aún tendremos que esperar un tiempo antes de ver esta nueva característica integrada en ReactOS. Y personalmente, no creo que la veamos en la versión 0.3.14....

Termino deseando a todos los seguidores del blog, y a todos los seguidores de ReactOS en general unas felices fiestas, felices navidades y un 2012 plagado de salud y buenas noticias. ¡Nos vemos el año que viene!

Actualización: En la última reunión oficial del proyecto, mantenida ayer (5 de Enero de 2012) a través de IRC, se propuso que el branch de la versión 0.3.14 sea creado en dos semanas, con o sin el mencionado error.

Lo logramos

2011-11-16T14:13:00.006+01:00

No hemos quedado entre los 10 primeros, como prometía viendo en qué puesto nos manteníamos en las primeras semanas. Pero el objetivo ha sido cumplido: ReactOS ha ganado 1.000 € en el concurso organizado por el banco alemán ING Diba (el equivalente a ING Direct en España).

El resultado final ha sido el puesto 810 de entre 8.015 proyectos / fundaciones presentadas al concurso. Esto demuestra dos cosas. Primero, que vuestros votos han sido importantísimos, y que la comunidad ha respondido a la llamada que se hizo por correo electrónico. Desde estas líneas, muchísimas gracias a todos por vuestra participación.

Lo segundo es, que tenemos una comunidad de usuarios más grande de lo que pueda parecer a simple vista. Muchos de vosotros estáis expectantes, silenciosos como fantasmas, pero estáis ahí, y apoyáis a ReactOS, aún en la sombra. Este agradecimiento también es para vosotros.

Sabemos que esperáis ansiosos la siguiente versión de ReactOS (0.3.14) pedimos disculpas de antemano por tanto retraso, pero unos errores que provocarían lanzar una versión que no funciona como debiera nos impide publicar ReactOS. Se está trabajando para resolver estos bugs, pero, por el momento, sólo podemos ofreceros echar un vistazo a las daily builds.

De todas formas, sí podemos deciros que la espera merecerá la pena. La versión 0.3.14 promete ser la versión más estable y funcional hasta la fecha.

Actualización: Me termo que he cometido un error en lso posts.... El número 8.015 no se refiuere al número de proyectos / fundaciones inscritos, sino al número de votos que nuestra Fundación ha recibido.... Es lo que tiene no tener ni pajolera idea de alemán.... Disculpad las molestias.

RosBE 2.0 : CMake

2011-10-21T13:23:00.000+02:00

Dentro de muy poco se lanzará la versión final de RosBE 2.0, el entorno de desarrollo predeterminado para ReactOS.

La principal novedad es el objetivo de este hilo, y es el abandono de rbuild como entorno de desarrollo, y adopción de cmake. Por eso, os recomendaría echar un vistazo a la Wiki de ReactOS para aprender a usar el nuevo sistema para compilar el Sistema Operativo.

En sucesivos posts iremos desgranando el uso de este sistema tanto en Unix/Linux como en Windows

¡Vota por ReactOS!

2011-10-18T09:12:00.005+02:00

A última hora de ayer, Aleksey Bragin y Colin Finck mandaron un mensaje a la lista de correo de ReactOS. En él se especifica que un banco alemán (el equivalente a ING Direct en España) ofrece un premio de 1000 € a los 1000 proyectos / fundaciones más votad@s.

Aunque el sitio esté en alemán, ésto es lo que debéis hacer para votar. El procedimiento es sencillo, así que no os asustéis:

* Abrid el link de más abajo.

* Click en el botón naranja "Stimme abgeben" (="Votar")

* Introduce tu dirección de correo electrónico, y rellena el captcha, y después pulsad el botón "Absenden" (="Enviar")

* Recibiréis un correo de confirmación con un enlace en el que debéis pulsar (el primer enlace de todos).

* Y por último, haced click en "Stimme abgeben" de nuevo, y listo.

https://verein.ing-diba.de/sonstiges/33378/reactos-deutschland-ev

Un par de notas para animaros a votar: Podéis votar hasta tres veces. Y no solo eso, sino que además, los tres votos pueden ir a la misma Fundación. Así que, ¡Vota por ReactOS!

Muchas gracias en nombre de todo el equipo de ReactOS, y del equipo de El Blog de ReactOS.

Ratones y Teclados USB

2011-10-14T23:43:00.004+02:00

Y por fín, una de las noticias más esperadas últimamente.

A pesar de que la pila USB no es completamente funcional, ya hay dos tipos de dispositivos que sí deberían funcionar: los ratones y los teclados.

El trabajo hay que agradecérselo a Johannes Anderwald, Cameron gutman, y a muchos otros desarrolladores, que han invertido tiempo y esfuerzo en conseguir este importante hito para el proyecto.

Ahora es nuestro turno, usuarios, testers, de comprobar su funcionamiento, y de reportar los posibles errores que se puedan encontrar.

Como se suele decir en estos casos, "Happy Testing!" ("¡feliz testeo!")

Cambios en los objetivos de ReactOS

2011-10-07T23:05:00.003+02:00

Tan sólo una pequeña nota para anunciar que, en la última reunión del equipo de ReactOS a través de IRC, se acordó por amplia mayoría cambiar los objetivos del proyecto:

Si bien el objetivo último sigue sienbdo el mismo (es decir, total compatibilidad con aplicaciones y drivers de Windows), sí cambia la versión de Windows sobre la que considerar dicha compatibilidad.

Hasta ahora, como recodaréis, ReactOS se había marcado dos objetivos, uno por cada modo de funcionamiento del Sistema Operativo:

Compatibilidad con Windows 2003 para el modo núcleo (kernel mode)
Compatibilidad con la última versión disponible de Windows en ese momento para el modo usuario (user mode)

El problema radica en que, en las últimas versiones de Windows, los cambios efectuados al modo usuario también afectaban al modo núcleo, con lo que es imposible estancar el sistema en un núcleo Win2003 si se querían incorporar las últimas funciones de usuario....

La solución ha sido sencilla y, en princpio, acertada: Tanto el modo núcleo como el modo usuario pasarán a tener el mismo objetivo de compatibilidad. Y este objetivo se ha fijado en Windows 2003 (NT 5.2)

Temas

2011-09-22T16:52:00.000+02:00

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.

No es fácil. Resulta que Windows utiliza unas clases especiales, llamadas SxS, que permiten la existencia de distintas versiones de la misma librería. En teoría esto es útil solamente para las librerías .dll, ¿verdad? Bueno, pues también existen para los temas de Windows.

En concreto, dos de ellas. La primera es una clase por defecto, aquella que no aplica ningún tema en concreto (es decir, lo que vemos actualmente en ReactOS). La segunda dice a ReactOS cómo dibujar un tema en concreto.

¿Por qué dos clases? Sencillamente para permitir personalización por parte del usuario, sin romper compatibilidad. Pongamos como ejemplo un botón: La clase botón original no tiene otro formato que el clásico de Windows 2000 (sin tema aplicado). Al querer aplicarle otro tema, podría perder alguna funcionalidad. Para evitar ésto, se crea otra clase con la funcionalidad de siempre, pero que permita cargar cualquier otra, llamémosle, interfaz (el tema en cuestión).

ReactOS no tiene soporte para estas clases, asi que Giannis ha tenido que añadir hacks al código de ReactOS para simularlas. ¿El resultado? de momento es preliminar, pero las capturas de pantalla que se nos han mostrado nos hacen la boca agua....

ReactOS en la web de la BBC

2011-09-13T22:03:00.004+02:00

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

APIC

2011-09-11T11:40:00.004+02:00

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:

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.
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.

Kernel mode test suite: Lo que nos diferencia de Wine

2011-09-02T21:26:00.006+02:00

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... :)

lwIP integrado en reactOS

2011-08-31T13:29:00.006+02:00

No nos hemos podido resistir. Uno de los estudiantes con proyectos para el Google Summer of Code, Claudiu Mihail (KlausM), completó su trabajo antes de finalizar dicho periodo. Los resultados han sido espectaculares. Gracias al trabajo conjunto suyo y de Cameron gutman (cgutman), la pila de red de ReactOS ha dado un salto de gigante en cuando a fiabilidad y estabilidad.

Las pruebas realizadas incluyen navegación, juego en red, servidor de páginas web, y programas de benchmark. En todas las pruebas el nuevo ReactOS se ha mostrado veloz, estable, y fiable.

Recientemente un usuario del foro nos ha creado un video de demostración mientras jugaba en red al Quake 2, con otro usuario del foro. Y lo ha subido a youtube:

Alguien se anima a una partidilla? ;)

News: Alt+TAB en ReactOS

2011-05-29T15:37:00.000+02:00

En ReactOS ya se puede hacer uso del mítico “ALT+TAB” para seleccionar fácilmente las aplicaciones. La mejora la encontraréis en nuestras daily builds o tendréis que esperar a la 0.3.14.

Para conseguirlo han sido necesarios los esfuerzos conjuntos de Jimtabor y Gigaherz.

Si quieres conocer un poco más de su desarrollo, solo tienes que (como siempre) seguir leyendo…

Gigaherz y su aplicación

Hace un mes Gigaherz nos hizo llegar una pequeña aplicación que capturaba la secuencia ALT+TAB y mostraba una ventana con las aplicaciones abiertas.Además permitía seleccionar cualquiera de las aplicaciones desde dicha ventana.

Podéis encontrar su código fuente aquí.

Jimtabor y la adaptación

Jimtabor es uno de los responsables del User32 en ReactOS. Sobretodo se encarga de reescribir, corregir y pulir el sistema de mensajes: captura de teclas presionadas, envío de los mensajes del ratón a las aplicaciones,y Hooks, entre otros.

Jimtabor ha portado el código de Gigaherz a User32 para soportar la “Switch class” implementando GetAltTabInfo. Además han aparecido ciertos bugs relacionados, por lo que ha necesitado arreglar ciertas APIs para que el código funcione correctamente.

Aún existen algunos problemas con nuestros mensajes, y la secuencia ALT+ESC no parece funcionar correctamente. Jimtabor ya se encuentra trabajando sobre ello.

Un paso mas cerca de poder tener un Sistema Totalmente Operativo.

News: Al ataque con OHCI (USB)

2011-05-25T14:03:00.001+02:00

El soporte USB sigue siendo una prioridad en ReactOS, y Janderwald se ha embarcado en la aventura de dar soporte a este tipo de dispositivos.

Hemos podido hablar un rato con Janderwald y gracias a ello ahora podemos entender un “poco” mejor el trabajo que está desarrollando, el trabajo que queda por desarrollar y a “qué” está centrando su atención en estos momentos.

Si queréis información de primera mano, solo tenéis que seguir leyendo.

UHCI/OHCI/Y las madre que los “engendró”.

Sinceramente no se me ha ocurrido un mejor título para este apartado y es que el soporte USB 1.0 es un “pestiñazo”, si se me permite la expresión.

Janderwald explicaba así la “evolución” de los drivers USB:

“La especificación Universal Serial Bus(UHCI) en su versión 1.0 fue desarrollada por Intel, luego, un par de empresas, NEC y Microsoft entre ellas, se unieron para crear un nuevo standard ya que la 1.0 no estaba bien especificada. Nació así la versión OHCI(O de Open).Otro standard más”

Nacieron así dos standards USB.Y los quebraderos de cabeza para ReactOS. Al ser dos standards completamente diferentes es necesario crear un driver compatible con cada uno de ellos.

Ni más ni menos que dos drivers.Doble trabajo.

“Y por supuesto Intel posteriormente sacó el USB 1.1”, dice Janderwald. ¿Teníamos dos tazas?Pues otra más..

Compatibilidad con ratones, teclados y memorias USB

Si existen 3 dispositivos básicos que necesitan urgentemente soporte son: ratones,teclados y memorias USB.

Aunque muchos teclados siguen haciendo uso de Puerto Serie, los ratones lo abandonaron hace ya mucho tiempo y hoy en dia es casi imposible encontrar un ratón que no sea USB.

Hace poco Janderwald estaba trabajando en la creación del driver EHCI ( USB 2.0 ), ahora se encuentra desarrollando el driver OHCI. El objetivo inicial de Janderwald era dar soporte a memorias USB, las cuales por lo general hacen uso del USB2.0.Sin embargo,una parte importante del Sistema de Archivos aún no está implementado y es necesario para poder “montar” el dispositivo USB. Janderwald no tiene dichos conocimientos y ha solicitado ayuda a Heisspiter. Esto ha provocado que Janderwald se cambie al desarrollo del OHCI mientras Heiss termina de dar soporte en el Sistema de Archivos.

El driver OHCI(1.1) es fundamentalmente usado por ratones y teclados, y algunas viejas memorias.

Cuando termine de desarrollar el driver OHCI solo tendra que crear el “class driver”, una tarea “sencilla y que no debería suponer muchos problemas”, para que los ratones y teclados USB funcionen correctamente.

El driver OHCI de HAIKU

HAIKU es otro sistema operativo libre y gratuito que no se basa en Linux. Las relaciones entre los desarrolladores de ReactOS y Haiku son muy estrechas, hemos compartido varias veces Stands en distintas ferias, y nos ayudamos en todo lo que podemos.

Janderwald ha estado echando un vistazo al driver OHCI de HAIKU, y considera que puede ser facilmente portable a ReactOS y que le ayudará en gran medida el desarrollo del mismo.

En resumen, el driver EHCI (soporte de memorias USB) se encuentra parado hasta que Heiss no termine el soporte del Sistema de Ficheros y mientras tanto Janderwald se encuentra portando OHCI desde Haiku a ReactOS.

Empezaremos a ver los resultados en un par de meses

News: USB, estado actual

2011-05-16T16:37:00.001+02:00

El 2011 es el AÑO de ReactOS.

Como habéis podido comprobar el Blog ha sufrido grandes parones durante este año y los motivos, en contra de los que algunos han podido pensar, es que estamos trabajando mucho no, muchísimo, en el lanzamiento de ReactOS.

Hay miles de noticias, por fortunas todas buenas, que iremos compartiendo las próximas semanas para “poneros al día”. Pero ahora una de esas noticias que estáis esperando: El desarrollo del USB se ha acelerado en el último mes de manera impresionante.

Si quieres saber un poco más, solo tienes que seguir leyendo.

EL USB

El USB apenas necesita presentación, seguramente sea uno de los acrónimos mas reconocidos en el mundo de la informática incluso por los más profanos. Muchos dispositivos necesitan un puerto USB al que conectarse, desde impresoras hasta ratones,pasando por discos duros, teclados,o cargadores de móvil. Esto se debe a su gran modularidad que le dota de una flexibilidad asombrosa. Reconozcámoslo, un sistema no es operativo si no dispone de compatibilidad USB.

El desarrollo USB

En ReactOS han existido varios intentos para conseguir compatibilidad USB. Uno de los más prometedores fue el USB Cromwell stack, un port que quedó incompleto e incapaz de dar soporte a ratones o teclados.

El segundo intento lo comenzó Mjmartin el año pasado. Hicimos varios posts comentando sus avances, por cuestiones personales Mjmartin se vió obligado a parar su desarrollo y sus commits comenzaron a menguar en el tiempo, aunque nunca abandonó.

Hace un mes, Janderwald, decidió aparcar el desarrollo de sonido para centrarse en el desarrollo USB. Dos motivaciones le empujaron a ello: La primera fue el escaso número de reports sobre fallos de sonido o problemas de incompatibilidad con tarjetas de sonido.Debido en gran parte a que la mayoria de los usuarios están probando ReactOS en Virtualizadores.

La segunda fue su propia concienciación sobre las necesidades de ReactOS: Sin USB no hay usuarios, sin usuarios no hay logs. Y los logs son imprescindibles: Actualmente los PCs más modernos(y casi todos los portátiles) han abandonado el puerto serie, por lo que obtener información por dicho puerto es imposible. El USB es la alternativa.

Pero Janderwald no está solo, Mjmartin está ofreciéndole toda su ayuda y, gracias a que Mjmartin está menos ocupado, ha comenzado a mandar nuevos commits. Un nuevo equipo se ha formado.

Durante las dos primeras semanas Janderwald convirtió el codigo C creado por Mjmartin en código C++, más flexible al estar orientado a objetos. Mientras Mjmartin creaba nuevo código(ya en C++) y desde hace varias semanas, los dos, están implementado nuevas funciones.

Desarrollando sobre Windows.

Janderwald y Mjmartin han decidido basar su desarrollo en la sustitución binaria sobre Windows.El stack USB está compuesto por varios “ficheros” en WIndows, como ya fue explicado en esta entrada.

El proceso de sustitucion binaria se basa en reemplazar el fichero original de Microsoft por el fichero que ellos se encuentren creando en dicho momento. De esta manera se va sustityendo uno a uno todos los ficheros facilitando el proceso de debugging.

Objetivo y Estado actual

En estos momentos Janderwald y Mjmartin han decidido centrarse en el desarrollo de soporte para pendrives y discos duros externos.Esto permitirá arrancar ReactOS desde un USB, así como poder “meter y sacar” archivos/programas de manera mucho más sencilla.

Una vez que ReactOS sea compatible con los lápices de memoria, dar soporte USB a ratones y teclados no debería plantear excesivos problemas.

La siguiente imagen muestra el nivel actual de desarrollo:

La imagen muestra un fichero fdo.c, que se encuentra almacenado en un pendrive,abierto en Windows XP. Un Windows XP en el que varios de sus archivos binarios USB han sido sustituidos por sus homólogos de ReactOS.

Aún queda mucho trabajo por hacer, pero en los dos próximos meses habrán importantes novedades.Seguro.

2011: El año del USB para ReactOS.

Servidor CIA cerrado

2011-05-12T08:55:00.001+02:00

Pues vaya. Sin previo aviso, y apenas con explicaciones, pero ayer por la tarde, de repente, nuestro servidor CIA, aquel encargado de recoger los mensajes que se envian al arbol de desarrollo cada vezq ue se modifica este código, dejó de responder. Poco después, y hasta ahora, cada vez que intentamos entrar nos pide un nombre de usuario y contraseña que, por supuesto, no tenemos (no, no es el login y contraseña del sitio de ReactOS).

Y poco después se publica este post (en inglés), donde el autor trata de explicar su decisión.

En fin, habrá que buscar soluciones. Una de ellas, gracias a que el servidor cia.vc es de código abierto, será traernos dicho código a ReactOS. Pero habrá más. Sólo es cuestión de tiempo.

Actualización: El servidor fue levantado de nuevo, por lo visto ahora está en manos de otro grupo de desarrolladores.

Sorpresas de la tercera reunión oficial del equipo de ReactOS: USB y 0.4

2011-05-05T21:20:00.004+02:00

El jueves día 28 de Abril se celebró la III reunión oficial del equipo de ReactOS en el canal #reactos-meeting del IRC. Y la verdad es que no dejó indiferente a nadie. Hay muchos proyectos en curso, y otros pendientes, pero el resultado final puede ser francamente espectacular.

Si optáis por seguir leyendo, vais a descubrir cómo el Sistema Operativo puede dar un paso de gigante en los próximos meses, si todo sale como está previsto.

1. Reescritura del sistema ntdll.exe

El fichero ntdll.exe es el encargado de cxargar en memoria las bibliotecas dinámicas (archivos .dll) según se van necesitando. Como todos habréis podido comprobar, infinidad de veces intentamos ejecutar un programa y ReactOS literalmente se pierde en el intento. Esto es debido a la imposibilidad de cargar dichas librerías.
El ejemplo más acuciante lo tenemos en todas aquellas aplicaciones que hacen uso de los frameworks o entornos de ejecución GTK+ o QT, como por ejemplo, Pidgin, X-Chat, Wireshark......

Aleksey Bragin está encargándose de este tema, y ya lo tiene prácticamente resuelto. Tan sólo tiene pendientes arreglar un par de errores para volcar su código al árbol principal de ReactOS. Y las consecuencias, os las podéis imaginar: la compatibilidad con aplicaciones puede aumentar de forma espectacular. Veamos a ver hasta dónde somos capaces de llegar....

2. USB

Hasta ahora, el soporte USb de ReactOS se limitaba a habilitar, en BIOS, el soporte para "legacy USB". Y aún así, no era seguro que funcionara.

Michael Martin, primero, y Johannes Wald, después, han creado un branch aparte donde están cocinando un driver para el bus USB. Y el primero de los dispositivos USB en ver la luz serán los sistemas de almacenamiento (discos duros, primcipalmente).

Y la cosa va por buen camino. De momento, el driver ya puede usarse (por supuesto, con mil limitaciones, y no os alarméis si ReactOS se cuelga demasiado) en qemu, como nos ha dicho Michael Martin. Pero aún queda mucho trabajo por hacer....

3. 0.4

Vaya por delante, que no hay planes oficiales aún para el lanzamiento de la versión 0.4. Aún se desconoce cuál será la siguiente versión de ReactOS, y no hay fecha de publicación. Pero en la reunión se insinuó que, dependiendo del éxito de ReactOS en el Google Summer of Code, o mejor dicho, del éxito de los estudiantes con los proyectos que han presentado para ReactOS, podríamos ver la nueva versión 0.4 no mucho después del verano. Pero ésto son todo especulaciones y, vuelvo a repetir, para que quede bien claro, que no hay postura oficial al respecto.

El verano va a venir calentito, también de novedades.... veremos a ver en qué acaba todo ésto...

Las nuevas características de ReactOS 0.3.13

2011-03-26T14:13:00.000+01:00

El nuevo ReactOS 0.3.13 fue lanzado la semana pasada tal y como comentamos aquí.

El parto ha sido complicado, aunque es necesario agradecer a la comunidad de usuario de ReactOS su ayuda en el testeo de las aplicaciones que ha permitido acelerar en gran parte el proceso. Dos bugs, que además de ser críticos eran random, nos han tenido en vilo y han sido los responsables de este retraso.

La versión 0.3.13 ( 12+1 para los supersticiosos) es un gran salto de calidad con respecto a la versión anterior. La 0.3.12 fue la versión que introdujo las reescrituras más importantes, en la 0.3.13 estas reescrituras se han pulido y mejorado haciendo que ReactOS pueda demostrar su verdadero potencial.

>>Sigue leyendo para descubrir las importantes novedades de compatibilidad.

Los dos Bugs

Dos bugs han sido principalmente los responsables de demorar el lanzamiento de ReactOS 0.3.13.

El primero de ellos era el mítico USERPNPMODE() failed.
Mítico, porque aquellos usuarios de Arwinss han sentido en sus "carnes" más de una vez este bug. Es un viejo conocido que solo parecía afectar a Arwinss, pero que tras las reescrituras tambíen hizo su aparición en ReactOS. El bug aparecía en la segunda fase de la instalación, e imposibilitaba seguir con la misma.

Había que reiniciar el ordenador una y otra vez para lograr "pasar", por pura estadística, la parte crítica donde tenía lugar el fallo.

El bug parecía apuntar a un problema de "timings" (inicializando "algo2" cuando "algo1" aún no había terminado de inicializarse), por lo que seguramente era un bug antiguo que estaba dando la cara debido a las optimizaciones de velocidad de ReactOS.

Los desarrolladores de ReactOS, gracias a los informes que los propios usuarios del foro les proporcionaron, lograron descubrir varios fallos en las inicializaciones de los servicios que podían dar lugar a este bug. Por un lado el PNP (plug and play) se inicializaba dos veces, siendo la segunda innecesaria y pudiendo dar lugar a este fallo.Además los servicios se inicializaban concurrentemente (al mismo tiempo) hecho que podría darnos problemas en caso de existir dependencias entre servicios. Arreglando ambos se solucionó el bug. Un importante paso para ReactOS, pero aún más para Arwinss.

El segundo de ellos era un problema al final de la primera parte de la instalación al importar hivesys, haciendo que la máquina se quedara colgada y sin que pudiera pasar a la segunda fase. Otro bug random que ha sido descubierto y eliminado, ahora el registro es algo más fiable.

Ambos eran bugs críticos pues lograban sacar de quicio a más de un testeador ;)

Las características de la 0.3.13

Pero no solo han caido estos dos bugs. Más de 282 bugs reportados han sido arreglados incluyendo 50 regresiones. El bug más antiguo arreglado es el #1567 "TaskManager aún muestra procesos tras ser cerrados" que tenía mas de 5 años.

Para aquellos que les guste las estadísticas, la versión 0.3.11 fue descargada por 238.000 usuarios mientras que la 0.3.12 fue descargada por más de 526.000. Esto demuestra que el número de usuarios o curiosos se ha duplicado en apenas unos meses.

Los cambios más importantes han sido:

Implementación de cambio dinámico de resolución de pantalla. Ya no es necesario reiniciar.
Mejorada la compatibilidad con drivers gráficos.
Reescritura completa del heap manager con capacidades de debugging.
Mejorado el manejo de varias lineas de audio,impidiendo que el sonido se escuchara distorsionado por mezcla de las mismas.
Grandes arreglos en el subsistema de modo usuario (mejorando el uso del ratón, mensajes y timers)
Fallos gráficos solucionados en aplicaciones como Firefox o Thunderbird.
Nuevas aplicaciones funcionando, a destacar: Stellarium 0.10.2, LHelp, winpcap,FlashPlayer 10.1 , Mono 2.8, OllyDbg 1.10, Xenon 2000, VLC 1.1.5, Foobar 2000 y Skype 4.0.0
Más dispositivos SATA soportados.
Muchos tests han sido solucionados.
Mejoras en el memory manager que arreglan bugs y lo hacen más compatible con la arquitectura NT.

¿No os parecen suficientes?

Ahora es el momento de difundir nuestra nueva release, para eso contamos con vosotros. Os toca darnos a conocer a traves de vuestros twitters, facebooks y compañía.

Recordad que la versión 0.3.13 es muy ligera (solo necesita 300MB de disco duro y 64MB RAM) por lo que podéis probarla en vuestros abandonados ordenadores cubiertos de polvo ;). La versión 0.3.13 es aún Alfa, por lo que es recomendable no instalarlo en un PC de producción o que soláis utilizar.

Descarga la LiveCd desde aquí: Cd
Descarga el CD de instalación: Cd
Descarga el código fuente: Cd

Página oficial con otras descargas: http://www.reactos.org/es/download.html

Lanzado ReactOS 0.3.13

2011-03-23T09:39:00.002+01:00

Tras un mínimo retraso debido a la presentación de ReactOS en el CLT2011, ya tenemos con nosotros la última versión del sistema operativo.

Lo más significativo para los usuarios es la considerable mejora en el rendimiento del sistema, que se aprecia a simple vista por su rápida ejecución. Más de 280 bugs han sido resueltos desde la versión 0.3.12, además de muchas regresiones.

Aún no hemos tenido tiempo de traducir la nota de prensa oficial, pero os dejamos el enlace a la nota original (en inglés) por si queréis echarle un vistazo.

Como siempre, podéis descargar las imágenes disponibles desde aquí.

Google Summer of Code: ¡por fín!

2011-03-18T20:05:00.003+01:00

Después de varios años ausente, ReactOS ha sido seleccionado para participar en la nueva edición del Google Summer of Code. Y esto implica varias cosas:

En primer lugar, significa que un gigante como Google empieza a tomarse el proyecto en serio, lo cual no es moco de pavo.

Y en segundo lugar, significa que el proyecto ha alcanzado un cierto grado de madurez, lo suficiente para atraer la atención de las grandes empresas.

Esperamos que esta elección sirva para dar un empujón al desarrollo de este nuestro futuro sistema operativo.

¡Si deseas ganar 5000$ en breve te diremos como poder hacerlo!

News: Marzo, el mes de ReactOS

2011-03-07T15:55:00.000+01:00

Cuando el “Blog de ReactOS” recibe menos actualizaciones que de costumbre significa, por lo general, que estamos “tramando” algo.
Realmente estamos saturados de trabajo e ideas. Por fortuna el trabajo se traduce en “más” ReactOS y las ideas en un “mejor” ReactOS.
Aunque en España apenas existan desarrolladores de ReactOS, el esfuerzo por darlo a conocer está poco a poco recogiendo sus frutos.

Durante el mes de Marzo van a tener lugar importantes novedades, os desvelamos un par de ellas en rigurosa primicia…

¡¡¡4 eventos en 2 meses!!!

Ahí es nada. 4 eventos dando a conocer ReactOS en tan solo 2 meses.Más eventos que en todo el año pasado. Y el año no ha hecho más que comenzar..

A finales de Febrero Pierre Schweitzer, presentó ReactOS en ISIMA, en Clermont-Ferrand (Francia). El proyecto levantó una gran expectación y es que aún existen personas que no nos conocen.

El 11 de Marzo presentaremos ReactOS en Chemnitz(Alemania)durante el macro evento CLT2011. Muchos de nuestros desarrolladores alemanes estarán presentes en el mismo.
¿Y los otros 2 donde tendrán lugar? ¡¡En España!! El trabajo se nos acumula..

Los dos eventos en España

Somos pocos, pero “matones”.Y es que sin contar con un gran numero de desarrolladores, somos uno de los países que con más fuerza está difundiendo el proyecto ReactOS.

IMAGINÁTICA 2011

Hace 2 años ya estuvimos presentes en este evento, y aquí nos podréis encontrar otro año más, Imaginática es un encuentro de proyectos y nuevas tecnologías organizado por la Escuela Técnica Superior de Ingeniería Informática de Sevilla.

Del 8 al 11 de Marzo(sí, esta semana) tendremos un pequeño stand para hacer demostraciones del Sistema Operativo, además de dar una charla el día 9 a las 9:30 de la mañana. La charla será totalmente en español, y se retransmitirá por Internet via streaming.

Más info: Imaginática2011

IV Jornadas tecnológicas de Isla Cristina.

Las IV Jornadas Tecnológicas Ciudad de Isla Cristina, organizadas por el IES Miravent y el Ayuntamiento de Isla Cristina en colaboración con la Junta de Andalucía,la Universidad de Huelva, y la Diputación de Huelva, nos han invitado a dar una charla sobre nuestro proyecto.

Las Jornadas tendrán lugar el 31 de Marzo y el 1 de Abril y allí estaremos intentando sorprender a los asistentes con las últimas mejoras.

La entrada es gratuita, por lo que no podéis dejar escapar la oportunidad!
Más Info: Jornadas tecnológicas de Isla Cristina.

Otras novedades….

Además hay interesantes novedades que os desvelamos en total primicia.

Lanzamiento de la versión 0.3.13.

Aunque la versión 0.3.13 está casi preparada para su lanzamiento, nos hemos encontrado con serios bugs que han retrasado su fecha de salida. Algunos provienen de la reescritura del Heap Manager, otros han “despertado” tras las últimas reescrituras: como el bug USERPNPMANAGER() o el fallo al cargar el hivesys.inf, ambos considerados como críticos.
La mayoría han sido resueltos, así pues me arriesgo a decir que casi seguro que el día 10 de Marzo tendremos la 0.3.13 entre nosotros.

Proyecto YUZZ basado en ReactOS

YUZZ es un programa de talento para jóvenes emprendedores que presenten las mejores ideas de base tecnológica. Las personas seleccionadas disponen del soporte y apoyo necesario, así como el espacio y material adecuado durante un curso para el desarrollo de las ideas. Este programa se ha puesto en marcha en 12 ciudades de España. En Sevilla se han seleccionado 20 proyectos entre todas las candidaturas presentadas. Aquí podéis encontrar una relación de los seleccionados.
Victor Martínez ha sido seleccionado para formar parte del mismo, así pues durante los próximos 6 meses se encargará de desarrollar un proyecto basado en ReactOS. No podemos desvelar mucho más, pero seguro que ayudará a difundir aún mas este proyecto.

Testeo Coordinado

Durante el mes de marzo se pondrá en marcha un “Plan de Testeo Coordinado”, el primero de este tipo. De esta manera, y usando el Foro como herramienta, todos los usuarios y visitantes podrán encontrar pequeñas “tareas” para aunar esfuerzos de manera coordinada. ¡Si no sabías como ayudar, ahora sabrás como!

GSOC

Ya tenemos listos los proyectos que presentaremos al Google Summer of Code. Los desvelaremos en una nueva entrada..Esperemos que este año seleccionen alguno de ellos.

Y esto es solo el comienzo, a lo largo de las próximas semana os iremos desvelando más novedades

News: Conclusiones de la “Primera reunión oficial de ReactOS”

2011-02-24T03:34:00.000+01:00

El Proyecto ReactOS está embarcado en una nueva etapa en lo que a la gestión del proyecto se refiere.

Para ello se están tomando una serie de medidas que permitirán mejorar la coordinación y proyección exterior de ReactOS.

Ayer tuvo lugar la primera de las “Reuniones mensuales” donde se debatirán y se tomarán las próximas decisiones de manera consensuada.
Para conocer las decisiones tomadas o incluso aportar alguna sugerencia, solo tienes que seguir leyendo.

Las reuniones mensuales

La necesidad de una mejor coordinación es evidente. Hasta ahora todas las decisiones se tomaban vía Email (en las lista de correo) o vía IRC. Sin embargo esto planteaba varios problemas:

Vía IRC: Aunque era una manera rápida de tomar decisiones tener todos los puntos de vista de cada uno de los miembros de ReactOS era casi imposible ya que no todos se conectan a la misma hora. De esta manera las decisiones eran parciales, no existían puntos del día y la comunicación entre todas las partes, aunque directa, era casi imposible.
Vía Email: Enviar emails a la lista de correo sugiriendo una propuesta permitía llegar a todos los desarrolladores, sin embargo estancaba el intercambio fluido de opiniones. Los debates sobre las propuestas llegaban a eternizarse y muchas veces quedaban “desiertas”.

Por ello se ha optado por una opción intermedia:

Los miembros del proyecto ReactOS sugieren puntos a tratar para la siguiente reunión mandando emails a la lista de correos.
Una semana antes de la reunión se cierra la posibilidad de enviar más puntos.
Las reuniones se celebrarán una vez al mes.
Las reuniones son convocadas a través de las Listas de Correos haciendo públicos los puntos a tratar.
Durante la semana anterior a la reunión se pueden mandar propuestas sobre los puntos de la misma.
Las reuniones se celebrarán en un canal de IRC para realizar votaciones y aclaraciones sobre las propuestas. #reactos-meeting
En las reuniones solo los “Miembros del equipo de ReactOS” tienen voz y voto, pero son abiertas y públicas.

Los puntos a tratar y conclusiones de la primera reunión.

¿Quiénes son “Miembros del Equipo ReactOS”?

La terminología es muy ambigua, ¿podría ser cualquiera un “Miembro del Equipo ReactOS”?¿Son únicamente los desarrolladores “Miembros”?¿O también deberían serlo Testeadores y Usuarios?¿Podría ser un desarrollador que lleva más de 5 años sin mandar un parche un “Miembro del Equipo ReactOS”?
El tema es bastante complejo, pero teniendo en cuenta que solo los “Miembros del Equipo ReactOS” pueden votar, es importante tener una buena definición cuanto antes. Al ser la primera reunión y haber distintas sugerencias, se van a estudiar las propuestas para analizar cual es la mejor de ellas y someterlas a votación en la próxima reunión. Por el momento solo votarán los miembros que fueron designados como “Provisionales” y que asistieron a la primera reunión con voz y voto.

¿Cuándo tendrán lugar las reuniones?

Se decidió que las reuniones se realizarían el último Jueves de cada mes. De esta manera tendríamos tiempo para preparar la siguiente. La hora: las 20:00. El lugar: El canal #reactos-meeting en Freenode.

¿Cómo lanzar la 0.3.13?

En este punto los Coordinadores de Testeo seleccionaron los bugs y las regresiones más importantes que hay que arreglar antes de poder lanzar la versión 0.3.13. Los desarrolladores se asignaron los bugs y ya se han comenzado a mandar parches para arreglarlos.
La reunión se alargó casi 2 horas, fue un debate bastante animado y para ser el primero de estas características logramos encontrar bastantes puntos en común.

Existe una gran lista de propuestas a debatir para las próximas reuniones(de hecho la creación de dicha lista es responsable de la inactividad de las últimas semanas en este blog), y esperamos que poco a poco estas iniciativas vayan dando sus frutos.

Creado el branch de ReactOS 0.3.13

2011-02-16T14:14:00.003+01:00

Tras una seria de mensajes en la lista de correo sugiriendo una publicación únicamente basada en arreglos (bugfixes), hoy se ha creado el arbol de desarrollo de la siguiente versión de ReactOS, la versión 0.3.13.

Como siempre, a este arbol tan sólo se añadirán arreglos críticos de última hora, y los habituales parches.
La revisión base de este nuevo branch es la 50721.

Actualización: El día 22 de Febrero tuvo lugar una reunión urgente del equipo de ReactOS a través del canal #reactos-meeting de IRC. Entre otras cosas, se resolvió posponer la creación del branch para más adelante, lo que implica que el branch creado será eliminado, y una nueva revisión será elegida como la base del nuevo árbol. Volveremos a actualizar el blog en cuanto tengamos más información.

News: ¿Que es eso del [CMAKE]?

2011-02-03T03:35:00.000+01:00

Muchos habréis podido comprobar la existencia de varios cientos de commits haciendo referencia a la “palabra” CMake e incluso conocéis la existencia de un branch llamado “cmake-bringup”.
El objetivo de ese branch no es otro que abandonar nuestro actual jefe Rbuild y adoptar CMake como nuevo jefe durante la compilación.
Si quieres saber que es “Rbuild”, “Cmake”,o las ventajas de uno frente al otro…solo tienes que seguir leyendo… ;)

¿Qué es CMAKE?

CMake se utiliza para controlar el proceso de compilación de ReactOS usando ficheros de configuración sencillos e independientes de la plataforma. Al ser independientes de la plataforma se elimina la necesidad de tener varios conjuntos de ficheros para cada plataforma y el mantenimiento es por lo tanto mucho más sencillo.

Pero no solo eso, Cmake genera makefiles nativos y espacios de trabajo que pueden usarse en el entorno de desarrollo deseado. Existen generadores makefile para Unix, Borland make, Watcom make, MinGW, MSYS y Microsoft NMake. Además es posible generar ficheros de proyecto para Code::Blocks, Eclipse CDT, Microsoft Visual Studio de la 6 a la 10 incluyendo versiones de 64 bits y KDevelop.

STOP, que me embalo…

Tenemos que ver a Cmake como un jefe de producción. Cmake se encarga de ir dirigiendo la creación de las piezas que terminarán ensamblandose al final.¿Y quien las crea?¿quien las compila?Alguno de los compiladores antes mencionados.Normalmente solo se elige un compilador para hacer este trabajo, por ejemplo en ReactOS usamos MinGW. Compilar con varios al mismo tiempo es innecesario y además un caos.Solo tiene sentido usar varios compiladores si usamos distintos tipos de lenguajes en el código fuente, pero no es el caso de ReactOS pues todo está escrito en C/C++.

La relación entre el anterior jefe (Rbuild) y el trabajador (Mingw, Msys,MSVC..) era de odio-odio. Si queríamos que rbuild trabajara con Mingw teníamos que crear unos ficheros específicos, si queríamos que trabajara con MSVC teníamos que crear otros distintos, y así sucesivamente. A esto es lo que se le llama ser “dependiente de plataforma”.Hablamos de más de 1000 ficheros específicos.Una pasada.

Pero Cmake es mucho más flexible,y si creamos unos ficheros con sintaxis Cmake pueden funcionar con cualquier compilador del mercado(bueno, realmente con los que se han mencionado antes).

Rbuild—> CMake

El problema es que actualmente la sintaxis de los ficheros en ReactOS es rbuild, por lo que estamos cambiando todos los ficheros de rbuild por ficheros con sintaxis Cmake. Es un trabajo titánico, pero nos permitirá poder compilar con cualquier herramienta.

Flexibilidad para el usuario a la hora de compilar, y para nosotros un buen testeo de comportamiento frente a diversos compiladores.

Este trabajo titánico se ha realizado en un branch aparte ya que mezclar ambas sintaxis no es nada recomendable.
La buena noticia: El trabajo titánico ha (casi) finalizado. Ya somos capaces de compilar revisiones con Cmake como jefe.

Los nuevos Builders

En las últimas semanas hemos añadido nuevos “Buildbots” ( robots de construcción) que nos permiten construir la misma revisión de ReactOS con distintas herramientas. Esto se debe precisamente a la flexibilidad de CMake.

Antes teníamos los siguientes “Buildbots”:

Trunk_x86_GCCLin Debug :Crea las versiones Debug de ReactOS usando como jefe “rbuild” y usando “Gcc” en Linux
Trunk_x86_GCCLin Release:Crea las versiones Release de ReactOS usando como jefe “rbuild” y usando“Gcc” en Linux

Trunk_AMD64_GCCWin Debug:versiones Debug de la versión 64 bits con jefe “rbuild” y usando”Gcc” en Windows.
Trunk_ARM_GCCWin Debug: versiones Debug de la arquitectura ARM con “rbuild” y usando “Gcc” en Windows.

NOTA1: Los dos últimos nunca han producido una ISO completa pues el port x64 y ARM aún no han finalizado.
NOTA2: Gcc es el compilador integrado en el entorno de compilación MinGW.

A éstos se le añaden ahora dos más:

Ambos usan como jefe a “CMake”,pero uno compila con GCC y otro con Microsoft Visual C.Ambos en Windows.

Actualmente el primero de ellos ya está produciendo ISOs mientras que el segundo aún tiene fallos al compilar. Esto es debido a las exigencias de los compiladores. MSVC es muy exigente y se “queja absolutamente por todo”.

Como muestra un botón:

CMake_x86_GCCWin Debug: 197 Warnings

CMake_x86_MSVCWin Debug: 8353 Warnings.Casi nada. Lo curioso es que es exactamente el mismo código ;)

Los nuevos testeos

Pero esto no es todo,además estamos testeando todas estas ISOs.
Antes en reactos.org/testman solo aparecían los tests realizados a las ISOS creadas por Trunk_x86_GCCLin Debug , pero ahora también aparecen los tests de las nuevas ISOs compiladas por CMake_x86_GCCWin Debug .

Esto explica porqué en Testman aparecen dos testeos de la misma revisión, uno es el testeo de la revisión creada por Trunk_x86_GCCLin Debug y el otro corresponde al testeo de esa misma revisión pero que ha sido compilada por CMake_x86_GCCWin Debug.

El objetivo es comparar si existe alguna diferencia entre ambas ISOs al utilizar distintos jefes para conseguir la ISO final. Si la compilación es correcta, entonces ambas ISOs deberían mostrar el mismo comportamiento durante el testeo.

En un futuro también compararemos las ISOS de CMake_x86_MSVCWin Debug con las ISOS de los dos buildbots antes mencionados. Y como Cmake no pone límites podemos crear buildbots con otras herramientas de compilación y crear así decenas de “buildbots” con sus correspondientes Tests.
¿No es una gozada? Bye.bye Rbuild. :)

News: El Bug navideño en el MM

2011-01-22T01:01:00.002+01:00

Hoy es 22 de Diciembre del 2010. Son las 11 de la noche, lleva lloviendo dos días casi sin parar y apetece quedarse en casa calentito. En la tele siguen echando la misma basurilla de siempre, me acoplo en el sofá,arranco el ordenador y me pongo a testear por enésima vez ReactOS.

“La televisión ha hecho maravillas por mi cultura. En cuanto alguien enciende la televisión, voy a la biblioteca y me leo un buen libro.” dijo Groucho Marx , “o me pongo a testear ReactOS” añadiría yo.

Me bajo la última versión disponible, la 50109, y comienzo a instalarla…De pronto la instalación se congela al 25% y de ahí no avanza. "No pasa nada"-digo,mientras una gota fría comienza a resbalar por la patilla....

Instalando ReactOS.

La instalación comienza de nuevo, esta vez se congela al 45%.¿Pero qué !%$@#….? Reiniciemos otra vez…
Re-re-comienza la instalación y de nuevo se congela al 45%. Esto ya no es normal.

Por un azar del destino tengo instalada la 50085,que es del día anterior(21 de Diciembre).Instalé esa revisión porque incluye un pequeño parche que había creado para arreglar un buffer overrun en el driver de vídeo y quería comprobar que todo funcionara correctamente.

Recordaba precisamente que la instalación de la 50085 había ido como la seda pues estaba atento a cualquier “problemilla” que pudiera aparecer.
Así pues entre la 50109 y la 50085 un bug estaba impidiendo que ReactOS pudiera instalarse.

Analizando el problema…

Expirar,Inspirar…Expirar,Inspirar…Un bug que destroza la instalación del Sistema Operativo es considerado crítico…y hay que encontrarlo cuanto antes.
Mi madre sentada a mi lado,ve mi cara congestionada.”¿Estás bien?”me pregunta.

Hay dos manera de testear. Una es ir probando revisiones hasta encontrar cual introdujo el bug. Otra es analizar las revisiones y descartar a priori cuales no son susceptibles de introducir el bug. A medida que te vas familiarizando con los módulos de ReactOS es muy ¿fácil? ir descartando revisiones.

Asi pues, primero analizas el problema: “ReactOS se cuelga al copiar sus ficheros en el disco duro”.

La instalación de ReactOS es muy simple y tiene “dos partes”. En la “primera” se copian los archivos fundamentales al disco duro para controlar la “segunda parte” .Esta “primera” parte es muy rápida y ocurre antes de seleccionar el idioma de instalación. La “segunda” parte consiste básicamente en extraer los ficheros de un fichero comprimido llamado “reactos.cab” y copiarlos al disco duro.

El problema está apareciendo a la hora de “descomprimir” y/o “almacenar en memoria”.
“Sí,ahora ceno, un segundo”, le contesto.

Analizando las revisiones

Por fortuna el rango es muy pequeño 50085-50109,solo 24, veamos cuáles se pueden descartar. Aquí puedes encontrar un log de todas nuestras revisiones:GIT:

50089: [SCSIPORT] //Googleando vemos que es un driver para interconectar ordenadores.No necesitamos este driver para llevar a cabo la segunda parte de la instalación .Descartado.

50091/50093: [FORMATTING] //Como bien dice, es solo una recolocación de formato del código( colocar bien los espacios y demás).Comprobamos que no ha eliminado otras cosas (es típico que se te vaya el dedo y te comas un “{“).Correcto.Descartado,

50100: [CMAKE]//Cmake es un módulo en progreso que no es básico.Descartado

50103: [WIN32K]Silence DebugPrints//Esto solo elimina información mostrada en el DebugLog, es algo trivial.Correcto.Descartado.

50105:[I8042PRT]//googleando te das cuenta que es un driver para controlar el ratón. En esta fase de la instalación solo se utiliza el teclado.La “primera fase” es tan básica que ni se cargan los controladores del ratón. Descartado

Además las revisiones: 50088,50094,50097,50101,50102,50104 no existen (pues se tratan de parches aplicados a otras ramas, como puede ser Arwinss, o Cmake) y por tanto no pueden afectar al comportamiento del trunk.

Hemos descartado por tanto 12 revisiones. Solo quedan 12 candidatas.(Qué optimista!)

El gap 50085-50109 vamos a dividirlo en dos: 50085(Funciona)-50099(¿funcionará?) y 50099(¿funcionará?)-50109(No funciona).

Hay un interesante GAP, el que va de la 50099 a la 50109.

En este GAP hay 10 revisiones, de las que dos son inexistentes(50101 y 50102), 2 que ya han sido descartadas y 6 candidatas.Es interesante probar por tanto si la 50099 funcionaba o ya estaba rota. Si está rota sabemos que el commit culpable está entre la 50085 y la 50099. Si la 50099 funciona entonces el problema está en el segundo GAP el que va de la 50099 a la 50109.

Descargamos la 50099 y vemos que funciona perfecta, sin problemas a la hora de instalarse. Ya sabemos cual es el GAP donde hemos introducido el bug: 50099-50109

Analizando el GAP.

Realmente estaba teniendo mala suerte, no es normal encontrar tantos cambios críticos en el [NTOS]kernel.Y en este GAP había ni más ni menos que 6. Había dos opciones, testear las 6 o revisar el código por si podía encontrar algún bug evidente…

Al menos ,con un rápido chequeo ,se habían reducido las posibilidades de 24 a 6.No hay mal que por bien no venga.

Por mirar que no quede, a si que me propuse revisar los 6 commits sabiendo de antemano que seguramente no entendería ni una línea de código..

¿Por donde empiezo a mirar los cambios?¿De 50099 a 50109 ?¿o en el sentido inverso?

Siempre me han dicho que las casas nunca se construyen por el tejado.

Siempre me ha gustado llevar la contraria:Pruebo de mayor a menor.Venga: la 50108.

La 50108 y la buena suerte…

Parece un commit sencillito, de él 3 líneas son comentarios de código y sólo 2 es código añadido.De haber un bug tiene que estar en el nuevo código añadido(lo marco en verde):

--- a/reactos/ntoskrnl/mm/ARM3/virtual.c
+++ b/reactos/ntoskrnl/mm/ARM3/virtual.c
@@ -2446,6 +2446,9 @@ MiQueryMemoryBasicInformation(IN HANDLE ProcessHandle,
             /* Check if this VAD is too high */
             if (BaseVpn < Vad->StartingVpn)
             {
+                /* Stop if there is no left child */
+                if (!Vad->LeftChild) break;
+
                 /* Search on the left next */
                 Vad = Vad->LeftChild;
             }
@@ -2453,6 +2456,11 @@ MiQueryMemoryBasicInformation(IN HANDLE ProcessHandle,
             {
                 /* Then this VAD is too low, keep searching on the right */
                 ASSERT(BaseVpn > Vad->EndingVpn);
+
+                /* Stop if there is no right child */
+                if (!Vad->LeftChild) break;
+
+                /* Search on the right next */
                 Vad = Vad->RightChild;
             }
         }

Releo, y me doy cuenta que algo no tiene sentido...el bug es casi evidente.

¿Eres capaz de encontrarlo?
Lee las líneas, aplica tus conocimientos de C (la pura intuición también vale) y/o sigue leyendo..

El Bug

Supongo que te habrás dado cuenta.
La primera y segunda línea tienen coherencia.

+                /* STOP si no hay un “child” a la izquierda *
+                if (!Vad->LeftChild) break;
Si no hay un “child” a la izquierda, entonces Vad->LeftChild tendrá un valor cero. Como “!0” es lo mismo que “1” se cumple que efectivamente no hay child a la izquierda y con el break “Paramos!”. El comentario y la linea siguiente parecen tener sentido.

Ahora bien, las dos siguientes no parecen tenerlas:
+                /* STOP si no hay un “child” a la derecha*/
+                if (!Vad->LeftChild) break;

Si estamos mirando el “child” de la derecha,¿porqué comprobamos el valor de LeftChild?Algo está equivocado ¿el comentario o el código?. Una de las principales reglas es hacer siempre caso al comentario
.
Pero aquí hay 3 evidencias que explican porqué se cometió el error y cual está equivocado:

1)Siempre hacer caso al comentario.

2)Comprobar el código.La siguiente línea es:

Vad = Vad->RightChild;
En caso de que RightChild fuera 0, estaríamos asignando el valor 0 a “Vad”. Antes con el LeftChild intentamos evitar esta situación y por eso parábamos. Ahora también deberíamos hacerlo.

3)El Bug es un CopyPasta. Seguramente se copiaron las dos líneas del chequeo anterior pero solo se cambió la palabra “izquierda” con “derecha” en el comentario, y se olvidó cambiar el LeftChild por RightChild. Esto es muy frecuente.

Solo era necesario cambiar una única línea y todo resuelto. AQUÍ podéis ver el parche.

News: ReactOS certifica drivers de código abierto para Windows

2011-01-03T13:50:00.000+01:00

Hoy nos levantamos con una buena noticia:
La Fundación ReactOS ofrece la posibilidad de certificar gratuitamente drivers diseñados para Windows a aquellos proyectos open-source que lo soliciten gracias a nuestro certificado Verisign.

Muchos proyectos de código abierto no pueden permitirse el lujo de pagar el alto coste de una licencia con la que certificar los drivers de sus aplicaciones.Si el driver no está certificado,Windows advierte al usuario dándole la posibilidad de no seguir adelante con la instalación del mismo(drivers 32 bits) e incluso impidiendo totalmente dicha instalación (drivers 64 bits).

Esto juega en contra de las aplicaciones de código abierto ya que, ante una advertencia de "alto riesgo" por parte del Sistema Operativo, el usuario podría decidir no instalar el software.

Gracias a la certificación gratuita que ofrece la Fundación ReactOS aseguramos, además, que nadie pueda añadir rootkits o troyanos que comprometan la seguridad del sistema operativo. Elevando la calidad y seguridad del código abierto.

El código abierto

Uno de los pilares del código abierto es la libre adaptación y modificación del código fuente respetando siempre las licencias bajo las que ha sido publicado.
Sin embargo esta libertad, que favorece al software abierto, se convierte en un arma de doble filo en el que terceras personas pueden modificar fácilmente dichos drivers añadiendo rootkits que comprometan la seguridad del Sistema Operativo.

Si el driver original no está certificado, el usuario "de a pie" no tendría manera de reconocer cual de los dos drivers es el peligroso. Si el driver original está certificado, el sistema operativo advertiría al usuario del peligro y éste podría detener la instalación.

Por desgracia solo los grandes proyectos de software libre pueden tener acceso a licencias de certificación, cuyo coste ronda los 2000 euros anuales, por lo que muchos de los pequeños proyectos de software libre no pueden certificar sus drivers.

Drivers 64 bits.

La situación es incluso peor para aquellos proyectos libres que crean y usan drivers de 64 bits. Cuando Windows detecta un driver de 64 bits no certificado impide automáticamente su instalación, sin dar posibilidad al usuario de continuar con ella.

Este método cuyo objetivo es "proteger al usuario de posibles drivers dañinos" obliga a estos proyectos a pagar una certificación, algo que como hemos dicho no está en los bolsillos de todo el mundo.

De esta manera se limita, indirectamente, el desarrollo del software libre para la nueva generación de los sistema operativos Windows.

Requisitos para la certificación gratuita

Para poder tener acceso a la certificación, deben cumplirse una serie de requisitos:

La certificación solo estará disponible para Drivers de proyectos open source
La Fundación ReactOS construirá el driver binario que va a ser certificado: No aceptamos binarios ya creados. Esto significa que todo el código fuente y las herramientas para construir el driver deben estar accesibles.
El driver no puede ser usado para sortear características de seguridad del Sistema Operativo. Esto incluye intentar romper características DRM así como otros procesos de seguridad.
El driver no puede ser parte de actividades ilegales que intenten sortear la seguridad del sistema operativo.
Se debe colocar un link a la página web de ReactOS en alguna parte del proyecto o del producto. Preferiblemente facilmente visible.

La Fundación se reserva el derecho de rechazar la certificación de un driver incluso si los requisitos anteriores son plenamente satisfechos.

Más Info y Datos de contacto: Driver Signing

News: Todos los servidores operativos.

2011-01-03T10:56:00.000+01:00

En la última entrada os comentábamos que nuestro server Debug&Tester se había tomado un par de días de vacaciones.

Tras un bonito reset manual, nuestro server Osnabrück se encuentra de nuevo operativo, testeando y compilando las nuevas ISOs.

El servidor, que corre un sistema operativo Gentoo,se había quedado totalmente bloqueado y no respondía a ningún tipo de apagado/reset de manera remota. Estas cosas pasan :)

Los testeadores respiran algo más aliviados. La revolución de las máquinas tendrá que esperar. :)

¡Atentos a la próxima entrada!

News: El servidor Debug y Test están de vacaciones

2010-12-29T13:02:00.000+01:00

Durante las navidades todos necesitamos un respiro, y nuestros servidores no iban a ser menos :)
Tras un año ajetreado con cambios en el Memory Manager, el Heap Manager, la Commun Cache, el subsistema Win32...nuestro servidor Osnabrück ha decidido tomarse un descanso.

Si quieres saber los motivos de su "huelga", a qué se dedica nuestro "amigo" Osnabrück,o cómo vamos a resolver esta situación solo tienes que seguir leyendo :)

Osnabrück, esa gran desconocida

Osnabrück es la tercera ciudad más grande de Baja Sajonia en Alemania. Tiene unos 164.000 habitantes....

Pero también es el nombre de uno de los servidores fundamentales del proyecto ReactOS
Actualmente el servidor se encuentra en Braunschweig, otra ciudad de la Baja Sajonia.Por el momento se queda con el nombre de su antigua localización, veremos cuanto le dura... ;)

Osnabrück tiene dos misiones fundamentales:

Crear las ISO tipo Debug

Las ISO tipo Debug son nuestras bootcd-dbg y nuestras livecd-dbg. Ambas ISOs tienen capacidad de debuggeo por lo que son fundamentales para "entender" por qué falla una determinada aplicación. El livecd-dbg permite ejecutar el Sistema Operativo sin necesidad de instalarlo en el disco duro, mientras que el bootcd es un disco "normal" que necesita ser instalado para poder arrancar ReactOS.

Testear la bootcd-dbg

Otra de las misiones fundamentales es el testeo de la ISO.Para ello el servidor instala el bootcd-dbg en una máquina virtual y corremos sobre ReactOS las rostests, que son una mezcla de winetests y tests propios. De aquí sacamos los resultados que se muestran en la página: www.reactos.org/testman
Estos resultados son muy interesantes, pues nos muestra como un Commit puede haber afectado (positiva o negativamente) a ReactOS simplemente comparándolo con resultados anteriores.

Osnabrück, el Hardware.

Es un auténtico bicharraco. A más de uno nos gustaría tener uno así en nuestras casas:

Placa Base: Asus DSBF-DE
CPU: 2x Intel Xeon 5310(4 núcleos), total: 8 núcleos.

Memoria: Kingston ValueRAM FB-DIMM 8 GB DDR2-667
Discos duros: Casi sin limite.

Tiempo en compilar todas las ISOs: menos de 2 minutos.
Como referencia,una ISO de ReactOS en un PC de sobremesa nuevecito(4 núcleos) tarda unos 15min cada una y un dual core alrededor de 1 hora.

Osnabrück en huelga...

Desde hace un par de días el servidor Osnabrück se ha declarado en "huelga", y ha dejado de compilar y testear las ISOs.

Por fortuna contamos con otro servidor,el Höxter, que sigue creando ISOs tipo Release que siguen a disposición de aquellos que quieran descargárselas.

El contrapunto es que las ISOs tipo Release, al carecer de capacidad de debugging, no "sirven" para testear las rostests sobre ellas. Con lo que no sabemos como están afectando los nuevos Commits al proyecto.

Parece ser que el KVM,el virtualizador en el que instalamos ReactOS y que tiene instalado nuestro servidor Osnabrück, se ha quedado "colgado". ¿Quién decía que las apps en Linux no se cuelgan? ;)

El cuelgue es tan "grave" que no somos capaces de reiniciar la aplicación de manera remota y tendremos que reiniciarla de manera manual. El problema es que estamos en Navidades, y el lugar donde tenemos alojado el servidor no abrirá hasta Enero. Ley de Murphy en estado puro.

Llevamos con KVM varios años, y muy pocas veces nos ha fallado tras más de 50000 revisiones y sus correspondientes testeos.Es un software bastante fiable. Además es el primer virtualizador que incluye a "ReactOS" como Sistema Operativo soportado. Podía aprender Vbox un poco ;)

¿Solución?

Hoy vamos a intentar crear un nuevo buildbot, sustituto, en uno de nuestros servidores, con el fin de poder tener las ISOS tipo Debug ,y los testeos de las mismas, lo antes posible.
Además aprovecharemos para hacer pruebas a un nuevo sistema de testeo que Aleksey ha estado desarrollando.
Que Murphy(y su ley) nos pille confesados :)

News: ¡ReactOS alcanza las 50000 revisiones!La Sorpresa y el Caos.

2010-12-21T15:16:00.000+01:00

No todos los días un proyecto llega a los 50000 commits. Por ello decidimos guardarnos una sorpresa especial para esta revisión.
Sin embargo la sorpresa especial se convirtió en Caos y generó una serie de problemas que por fortuna han sido rápidamente resueltos.
En la revisión 50000 hemos activado el NT Heap Manager, del que ya os hemos hablado en entradas anteriores, y aunque los resultados positivos no se han hecho esperar, hemos tenido que enfrentarnos con un par de bugs que han salido a la luz.

A continuación se describen las grandes mejoras que aporta el nuevo Heap Manager comparándolo con el Heap Manager de Wine.

Las 50000 revisiones

Aleksey Bragin ha esperado hasta la revisión 50000 para activar el NT Heap Manager (el cual hasta ahora era compilado pero no era usado por defecto). Esta activación tiene lugar tras meses de testeo para comprobar que el nuevo Heap Manager funciona correctamente ya que es una pieza crítica del Sistema Operativo. Sin embargo,una larga fase de testeo no asegura que se “atrapen” todos los bugs, y únicamente activando el Heap Manager en el trunk hace posible terminar de pulir esta pieza y aquellas en las que se asienta.

El Commit.

En el Commit 50000 Aleksey Bragin ha explicado los cambios y mejoras que el nuevo Heap Manager va a proporcionar a ReactOS, a continuación os dejo una traducción:

“Ha llegado el momento de deshacernos de nuestra ligeramente modificada implementación del Heap de Wine, el cual es un hack basado en la implementación del Heap de Windows95, el cual a su vez es un hack del administrador de memoria de DOS. Nuestro anterior Heap Manager daba soporte a 3 NT Heap Flags de las 18 posibles, no era compatible con rutinas “a medida” de reserva/liberación de memoria y era entre 50 y 80 veces más lenta,con una fragmentación 500 veces superior, si la comparamos con el LFH de NT. ( WINE es afortunada, ya que las características avanzadas del Heap NT son utilizadas normalmente en el modo Kernel, no en el modo usuario, y ellos cruzan sus dedos para que esto sea así )

Nota de "El Blog de ReactOS": Wine no implementa las características avanzadas del Heap NT en el modo usuario, por lo que si una aplicación usara dichas rutinas no funcionaría sobre Wine. En este sentido ReactOS es ahora mucho más compatible, rápido y menos fragmentado que WINE.¿Quién no ha escuchado sobre la “lentitud” de WINE?Aquí teneís algunas de las posibles causas ;)

Varias aplicaciones que hacen un uso intensivo de Base de datos /SQL se beneficiarían de estas características “a medida” proporcionadas por NT. Sin mencionar que eliminamos el soporte cutre de rutinas de envío, el soporte cutre de las Flags definadas por el Usuario y el soporte cutre de los valores definados por el Usuario.

Así pues, el momento glorioso del nuevo Heap Manager, el cual (recordemos) es totalmente nuevo, que se parece al heap manager REAL de NT, y que se basa en estructuras de datos similares a las estructuras “heap” de Windows 2003 y Vista, capaz de dar soporte a Flags avanzadas del Heap(útiles para hacer debugging, por ejemplo), el cual tiene una mucha menor tasa de fragmentación ( y por tanto mayor velocidad y fiabilidad), que además soporta flags y valores definidos por el usuario, con soporte nativo para rutinas de envío propias(importante para el subsistema Win32) ha llegado. También reserva, envía, recibe y libera memoria al vuelo, al contrario que el anterior heap manager que prefiere reservar y enviar tanto como sea posible y que no decomisiona cuando ya no es necesario. Por no hablar del soporte de heaps por proceso, con su propio lock, así como soporte para un debugger especial del heap ( aún por crear en heapdbg.c) que será util para encontrar corrupciones del Heap.

Sí, me aburro mucho.. :D “

Los problemas

Tras el commit nuestro Testman se volvió loco. De pronto dejó de testear algunas suites y otras que antes se ejecutaban sin problemas ahora daban error ( CRASHED). Aquí podéis ver una comparativa entre la 49999 y la 50000.
Sin embargo era lo esperado: ReactOS demostraba que no se sentía cómodo con nuestro nuevo heap manager.

Como ya comentamos esto es algo que suele ocurrir, y que ya nos pasó en la reescritura del Memory Manager, al dejar a la vista varios bugs críticos de otras partes del sistema operativo.
Aún quedan por resolver algunos de estos bugs críticos,que han salido a la luz gracias al nuevo Heap Manager, pero hemos podido comprobar como varias suites de tests han mejorado sensiblemente sus números y además son mucho más estables.

La estabilidad se mide en los números de tests pasados revisión tras revisión y es que con el antiguo heap manager, y sin motivo aparente, dos revisiones consecutivas podían diferir en MILES de test fallados. Aquí podéis ver un ejemplo de la “regular” fiabilidad del antiguo Heap Manager, mientras que aquí podeís ver la fiabilidad actual)

Tras la reescritura del Memory Manager y la del Heap Manager, ahora ReactOS entra en una fase de máxima estabilidad. Pero eso solo lo veremos en la 0.3.13...

News: It is here again , is he here again

2010-12-11T22:37:00.001+01:00

No, no nos hemos vuelto loco ni ingleses de repente. Pero no hay mejor manera de describir las últimas noticias que un:

- It is here again

- Is he here again

Y es que un antiguo desarrollador de ReactOS ha vuelto tras dos años en el “exilio” (termino familiar para indicar que la vida “real” no le ha dejado tiempo para crear código)
No solo ha vuelto, sino que se ha metido de lleno a crear nuevas funciones, a limpiar el código de su antiguo branch, y crear un branch nuevo tras la mencionada limpieza.

Los resultados no se han hecho esperar….

“Is he here again”

GreatLord ha vuelto con nosotros. Y eso es una magnífica noticia.

GreatLord tiene en su palmarés dos grandes méritos: el primero,ser el desarrollador de una de las ramas más prometedoras y diferenciadoras con Wine; el segundo, crear un lenguaje propio llamado GreatLordish (mezcla de GreatLord e Inglés) que demuestra que no hace falta tener grandes conocimientos de inglés para comunicarse, únicamente tener ganas. Tener pocos conocimientos de inglés e intentar hacerse entender es un mérito indiscutible.

GreatLord es un desarrollador de la vieja escuela, de la época en la que ReactOS aún no había conseguido correr su primer explorer.exe, lleno de hacks y basado en un kernel cuyo diseño distaba mucho del NT. Con él hemos recordado los viejos tiempos, a aquellos que abandonaron el proyecto, y al nuevo equipo de desarrollo.

Aunque nos seguía a través de nuestra lista de correo, se ha quedado sorprendido del salto de calidad, estabilidad y compatibilidad al probar la 0.3.12. Tal vez esto le haya motivado a retomar con nuevas energías el proyecto que traía y se trae entre manos.

Como nosotros decimos: He is here again o en GreatLordish: "Is he here again."

“It is here again”

Y GreatLord ha retomado su proyecto dentro de ReactOS. La rama ReactX vuelve a recibir código después de varios años acumulando polvo.

GreatLord ha limpiado el código fuente, ha desechado hacks que actualmente no eran necesarios, y ha conseguido que la branch compile de nuevo (tras los múltiples cambios que han sufrido las cabeceras durante estos dos años).

El branch ReactX tiene por objetivo crear un clon de DirectX que permita una mayor compatibilidad con videojuegos, intentando superar la actual compatibilidad que tiene Wine con los mismos.

Asi pues: “It is here again”

Para conseguir este propósito debe mejorarse el comportamiento de los drivers de video, por lo que se espera que este desarrollo permita alcanzar un mayor grado de compatibilidad con tarjetas de video.

De hecho, algunos de los primeros parches arreglan problemas en nuestros actuales drivers de vídeo (VBE) que son los que “funcionan por defecto”.

Es hora de asediarle con los logs de depuración de esas tarjetas de video que se niegan a funcionar…. ;)

Entrevista con Magnus Olsen (GreatLord): DirectX y ReactX

2010-12-11T13:51:00.004+01:00

La siguiente entrevista es, probablemente, una de las más esperadas de las entrevistas a los desarrolladores de ReactOS. Magnus Olsen (Suecia, 1976) es además una persona carismática, muy querida dentro de la comunidad. No maneja correctamente el inglés, cosa que le ha acarreado más de una broma en el canal IRC, y por lo cual hemos preferido, en El Blog de ReactOS, no publicar la entrevista en su versión original.

Pero lo más importante es el trabajo realizado por este desarrollador: Pretende dotar a ReactOS, nada más ni nada menos, que de una implementación del casi totalmente indocumentado DirectX. Una tarea titánica por su complejidad, precisión, y casi nulo previo conocimiento de su campo de batalla.

Elhoir.: Hola Magnus, buenas tardes.

GreatLord.: Hola

E: En primer lugar, ¿Cuándo entraste a formar parte del proyecto ReactOS, y cuál fue tu primera tarea?
GL: Bueno, empecé a estar interesado en ReactOS allá por el año 2003, porque veía que era un sistema operativo con mucho potencial. Y desde entonces llevo trabajando en un proyecto que es para mí ya como un objetivo personal: Dotar a ReactOS de soporte DirectX.
También tengo conocimientos sobre el subsistema de audio, pero como no puedo trabajar en ambas cosas, he decidido trabajar en aquello que más me gusta.

E: ¿Qué es exactamente DirectX?
GL: DirectX es un conjunto de APIs que proporcionan aceleración hardware tan to de vídeo como de audio.

E: ¿Así que, la aceleración 3D de las tarjetas gráficas viene dada por DirectX?
GL: Exacto. O también por OpenGL. Pero no es necesario implementarlo completamente, tan sólo unas cuantas funciones básicas. Lo demás es opcional.

E: Mucha gente piensa que está aceleración es debida a que DirectX permite saltarse partes en el modo kernel....
GL: ¡No! En la arquitectura NT nada es capaz de saltarse el modo kernel. Este está protegido por el modo del procesador. Lo que sí se salta son las APIs en el modo usuario, permitiendo acceder directamente al hardware gráfico o de sonido, acelerando la ejecución.

E: ¿Y cómo realiza DirectX estos "saltos"?
GL: La DLL llamada gdi32 (gdi32.dll) mapea directamente llamadas al sistema, e interfaces de DirectX, con lo que se obtiene acceso directo tanto a los drivers del dispositivo como al subsistema win32k.

E: Dices que el sistema DirectX está indocumentado... ¿de dónde estás sacando la ayuda que necesitas?
GL: Bueno, se da la paradoja de que DiirectX para Windows XP está practicamente indocumentado, pero, sin embargo, sí existe algo de documentación para Windows CE. Si bien no es completa, sí es más correcta que la documentación existente para Windows XP

E: Creo que necesitaremos más tiempo para hablar de DirectX.... Es un sistema ampliamente desconocido para los usuarios.. y ni siquiera yo me he enterado aún de cómo funciona exactamente...
GL: Claro, cuando quieras.

E: Muchas gracias por esta primera parte de la entrevista. Hasta la próxima.
GL: Gracias a vosotros, un saludo.
GL:

News: Un nuevo Explorador para ReactOS

2010-12-03T14:45:00.000+01:00

Una de las principales sugerencias de cualquier recién llegado a ReactOS es la de actualizar el diseño de nuestro Escritorio/Explorador a uno mas “moderno”, ya que el actual es “simple” y “viejo”.

Como sabéis,estamos desarrollando el “mucho más vistoso” explorer-new.exe, sin embargo su progreso es lento ya que fue escrito usando C (en vez de C++) y además hace uso de código COM/OLE que no tenemos implementado aún. Esto nos impide hacer la “sustitución” obligándonos a “soportar” al actual Explorador.

Dax (un colaborador italiano) está desarrollando un Explorador en C++ mucho más completo que el actual Explorador de ReactOS. Además incluye importantes novedades, como un menú de inicio a dos columnas (al estilo XP), y la presencia de menús expandibles en la ventana del Explorador de ficheros.

Más info a continuación…

Un breve apunte…

La mayoría de los usuarios provenientes de Windows relacionan XP con una barrita azul y un botón de Inicio en verde.

Curiosamente esta no es la apariencia real de Windows XP sino un Theme que viene aplicado por defecto ( el Luna Theme).

La verdadera apariencia de Windows XP es la que podéis ver sobre estas líneas, muy similar a la apariencia “simple” y “vieja” de ReactOS.

El truco, por tanto, consiste en dar soporte a los “Themes” para que de esta manera el Escritorio sea personalizable a gusto del usuario, pudiendo cargar el Luna original o cualquier otro de los miles que se pueden encontrar por Internet.

Uno de los objetivos del Dax Explorer es ser capaz de cargar estos “Themes” diseñados para XP.

El Dax Explorer…

El Dax Explorer está siendo escrito desde cero en C++ simplificando enormemente su interacción con objetos COM/OLE (que son una auténtica pesadilla en C). Actualmente se encuentra en desarrollo y aunque ajeno, en principio, al proyecto ReactOS, podría llegar a convertirse en parte del mismo.

Una de las principales mejoras es su “doble menú de inicio”, algo de lo que carece el actual Explorer y que es bastante útil. Los Themes para XP están creados para dar soporte a menús dobles de inicio, por lo que es necesario mantener dicha estructura.

Además se han simplificado enormemente las ventanas de navegación por ficheros y carpetas, eliminando botones innecesarios o no funcionales, y creando menús expandibles que ocupan el lateral izquierdo de la ventana.

Actualmente su interfaz está en Italiano, pero tendrá soporte multilenguaje.
Su consumo de RAM es inferior al del actual explorer.exe, si bien es cierto que no todas las funcionalidades se encuentran activas.

Próximamente publicaremos una pequeña “review” con la última versión de este Explorador comentando las mejoras,avances y compatibilidad del mismo.

News: ReactOS en ARM (Vídeo)

2010-11-29T09:51:00.004+01:00

El ARM-team está “ansioso” por tener ReactOS corriendo en su dispositivo ARM, algo lógico si tenemos en cuenta que se vieron obligados a hacer un pequeño alto en el camino que les ha durado 12 meses.

En esta entrada nos mostraron algunas capturas de su kit de desarrollo (una Texas Instruments OMAP…) intentando cargar ReactOS.

Pero las fotos no eran suficiente, y nos han grabado un pequeño vídeo donde nos muestran sus últimos avances.

El Vídeo

El cargador de arranque sobre dispositivo ARM.

En este vídeo se puede ver como el cargador de arranque (bootloader) funciona correctamente, las opciones son seleccionables mediante el teclado e incluso funciona el temporizador de 10 segundos. La carga de ReactOS se detiene al llamar al punto de entrada del Kernel ( el entrypoint).

Es justo en ese momento cuando el kernel de ReactOS tomaría el control y comenzaría la carga del Sistema Operativo.

El Kernel aún tiene que adaptarse a las particularidades del micro ARM, por lo que tendremos que esperar para ver el escritorio de ReactOS.

Todo es cuestión de tiempo :)

News: ReactOS en microprocesadores ARM

2010-11-24T16:46:00.003+01:00

El proyecto ReactOS tiene varias versiones en desarrollo de su Sistema Operativo.Y aunque nos centramos en la versión para PC de ReactOS, también estamos desarrollando una versión para los microprocesadores ARM.

¿Quién no ha usado nunca una Nintendo DS, un Ipod o una Gameboy Advance ?Pues todos ellos hacen uso de microprocesadores ARM

En una escueta nota, el ARM-team nos ha mostrado un hardware ARM en el que han instalado ReactOS de manera satisfactoria.

Y es que una imagen vale más que 111101000|2 palabras.

(Edit: El dispositivo en cuestión es un Texas Instrument OMAP34x-II Mobile Development Platform, que usa un micro ARM Cortex-A8. Gracias Heisspiter.)

Los procesadores ARM

En el mercado existen una gran variedad de microprocesadores, pero seguramente la arquitectura mas conocida sea la x86 en sus versiones de 32 o 64 bits, ya sean de AMD o de INTEL.

Sin embargo, con el auge de los smartphones, la arquitectura ARM ha ido cobrando importancia, ya que permite una gran potencia de cálculo con un consumo muy bajo de energía. Uno de los “buques insignias” de esta arquitectura es el SnapDragon, un micro desarrollado por Qualcomm, y que es el “corazón” de móviles como el Google Nexus One, la HTC HD2,o la HTC Desire HD entre otros.

También usan un micro ARM los móviles: Iphone 4, Iphone 3Gs, Samsung Omnia HD, Samsung Omnia II, Samsung Wave, Motorola Droid X. O Tablets PCs como: Ipad, Archos 5, o el Nokia N900
Pero ya estaban entre nosotros desde mucho antes y es que, gracias a su bajo consumo, son perfectos para todo tipo de dispositivos móviles.
¿Quién no ha tenido entre sus manos una GameBoy Advance, o un “IPod”, o una Nintendo DS?.

Sistemas Operativos para microprocesadores ARM

En la actualidad varios Sistemas Operativos tienen versiones que son capaces de funcionar sobre un micro ARM, a destacar: AndroidOS, distribuciones Linux ( Chrome OS, Fedora, Gentoo, Ubuntu …), distribuciones BSD (FreeBSD, NetBSD), o Windows Mobile.

Y a esta lista se le sumará ,en breve, ReactOS, que gracias a sus bajos requisitos (la versión de ordenador solo necesita 42MB Ram) es un candidato ideal para estos dispositivos.

Portando ReactOS a la plataforma ARM

Uno de los principales obstáculos para portar ReactOS a la plataforma ARM era el antiguo Memory Manager(MM). Nuestro antiguo Memory Manager era muy dependiente de la arquitectura x86, lo que imposibilitaba que pudiera funcionar sobre un micro ARM. Por ello, el ARM-team ha reescrito el Memory Manager , al que ha denominado ARM3(Another Rewrite of the Memory Manager), haciendo que ahora sea portable a cualquier arquitectura, solucionando decenas de bugs e incluyendo además nuevas características que han mejorado ostensiblemente la estabilidad del Sistema Operativo.

Hace apenas un par de semanas se concluyó la reescritura del MM, tras más de 12 meses, y la “desaparición” del ARM-team pronosticaba que algo se traían entre manos. Andaban liados intentando instalar una versión de ReactOS en un dispositivo ARM.
En esta captura se puede ver como no solo han conseguido instalar ReactOS en un dispositivo de desarrollo ARM, sino que además han sido capaces de arrancar ReactOS y de hacer funcionar el teclado.

Aún queda trabajo por delante pero el port de ReactOS a la arquitectura ARM se siente mucho mas cerca.
La carrera ha comenzado…

News: Reescritura del Heap Manager

2010-11-15T10:05:00.000+01:00

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.

Manual: Heap!Heap!…Manager

2010-11-10T20:52:00.000+01:00

Las dos últimas semanas han estado cargadas de novedades, y apenas hemos tenido tiempo ni de respirar.

Tras el lanzamiento de la ansiada 0.3.12 ,que ha demostrado estar al nivel esperado, es la hora de añadir código crítico a ReactOS.

Los lanzamientos aseguran un ReactOS con pocas regresiones, estable, debuggeado y pulido.

Es por tanto el momento perfecto de añadir nuevo código y de realizar las sincronizaciones con WINE, de tal manera que podamos corregir los nuevos fallos antes de la próxima versión: ¿0.3.13 ó 0.4?.

Ya hemos hablado de “Yarotows” que no solo simplificaba sino que añadia nuevas funcionalidades como por ejemplo el cambio de resolución en caliente.
Ahora es el turno de hablar del “Heap Manager ”…¿Lo quéeee?
Sigue leyendo para "diversificar el conocimiento”.

El Heap Manager

Si buscamos en un diccionario inglés-español veremos que Heap Manager es algo así como el “Manejador de Cacharros / Montones”. Ahora sí que está todo clarito, ¿verdad? [/ironic]
El Heap Manager es un manejador/ gobernador /administrador de Heaps. ¿Pero qué es un Heap?

Un Heap es un área de memoria reservada para los datos cuando una aplicación es lanzada. Lo del “area de memoria reservada” suena peor de lo que realmente es: Una zona de memoria que no puede ser utilizada por nadie, únicamente por ~~la aplicación~~ el proceso.

Algo así como un “Coto privado de caza” en el que nadie puede entrar salvo la propia aplicación para “cazar” memoria.

Una aplicación puede crear varios procesos o solo lanzar un único proceso.

(Muchas veces asociamos erróneamente el concepto de proceso con aplicación, una aplicación puede crear varios procesos que corren paralelamente creando un “Árbol de procesos”. Si vais al Administrador de Tareas, y hacéis click sobre la aplicación con el boton secundario del ratón veréis la opción de “Terminar árbol de procesos” )

Resumiendo: Una aplicación crea uno o varios procesos. Y cada proceso, al iniciarse, crea su propio “Process Heap”. El “Process Heap”, que como hemos dicho es un área reservada de memoria, se eliminará cuando el proceso termine. Si no se liberara, esa zona de memoria quedaría inaccesible para siempre (o hasta que apaguemos el ordenador). De ahí la importancia de eliminar el “Process Heap” cuando el “Process”(proceso) ha terminado.

El Proceso por defecto “acapara” 1MB de memoria para su Heap por defecto, aunque por supuesto podemos hacer que “acote” una mayor cantidad de memoria. (Esto está codificado en la propia aplicación que crea el proceso). Además puede expandirse si el proceso necesita almacenar más de 1MB de datos.
Imaginemos que el “Process Heap” está lleno de datos y que aún necesita almacenar algunos más.

//( Info extra para quien sepa algo de C: el malloc() ,asignación dinámica de memoria,usa la memoria del Heap)

Repetimos: Imaginemos que el “Process Heap” está lleno de datos y que aún necesita almacenar algunos más.

Entonces podemos encontrarnos con dos posibilidades: Se devuelve un error al proceso indicando que la memoria está llena y que el “Coto Privado de Caza” se ha quedado sin Memoria o se solicita al Sistema Operativo otro MB adicional. Entonces el Process Heap pasaría a tener 2MB de espacio reservado. Y luego 3MB, y 4, 5….si fuera necesario.

¿Y quien se encarga de crear el Heap de un proceso, gestionar la solicitud de nuevos MB de memoria o de liberar del Process Heap cuando el proceso ha finalizado? El Heap Manager.

NT Heap Manager

A estas alturas debería haber quedado patente la gran necesidad de tener un Heap Manager muy compatible con el NT Heap Manager.
Tengamos en cuenta que las aplicaciones van a hacer (ab)uso de reserva de memoria dinámica y que todo esto va a estar gestionado por el Heap Manager.

Si existieran bugs en la implementación del Heap Manager podríamos hacer que la aplicación muriera súbitamente,ya sea porque no le hemos asignado la memoria extra que necesita o porque no le hemos indicado que “ya no hay más memoria disponible” para la misma.

También podemos encontrarnos con fallos a la hora de liberar memoria, que pudiera quedar marcada como “Utilizada” cuando realmente el proceso ya ha terminado.

El NT Heap Manager es , en definitiva, la interfaz entre el Manejador de Memoria (Memory Manager) y los procesos de una aplicación. Si el Memory Manager está lleno de bugs, nuestro NT Heap Manager se verá resentido (siendo incapaz de localizar memoria disponible, por ejemplo) lo que hará que la aplicación muera súbitamente. De igual manera un Memory Manager perfecto pero un Heap Manager repleto de bugs nos llevaría a un desastre similar. Filosofia barata: Una cadena se parte por el eslabón más debil aunque el resto sean perfectos.

ReactOS Heap Manager

ReactOS está utilizando un Heap Manager compatible con el NT Heap Manager. Y compatible significa eso: similar, parecido, implementación propia, incompatible con ciertas aplicaciones. El Heap Manager de ReactOS tiene una compatibilidad limitada con el NT Heap Manager, o lo que es lo mismo, no es 100% compatible y esto afecta a las grandes aplicaciones.

Una gran aplicación hace mucho más uso del Heap que una aplicación pequeña, lo que empuja al limite de la compatibilidad a nuestro ReactOS Heap Manager. Las pequeñas aplicaciones, en principio, no necesitan extender su “Process Heap” lo que facilita la labor del Heap Manager, pero cuando constantemente se solicitan nuevos rangos de memoria se complica exponencialmente la gestión.

Y toda esta “interesantísima” explicación ¿Para qué?…
CONTINUARÁ

PS: Solicito la clemencia de todos los estudiantes/ingenieros informáticos por este resumen simplista del Heap y del Heap Manager.
PS: Solicito la clemencia de los que han llegado a CONTINUARÁ, prometo que en 2 días tendréis la Continuación ;)

News: Yarotows integrado en el Trunk

2010-10-29T00:13:00.000+02:00

Hace un par de días hablábamos de Yarotows y de algunas de las bondades que traía bajo el brazo.

Los problemas que quedaban por resolver ya han sido resueltos y ahora podemos descubriros todas las novedades que trae esta reescritura/implementación.

En estos momentos nos encontramos testeando los cambios y seguramente nos encontraremos con algunas regresiones, si deseais colaborar solo teneis que instalar la versión 0.3.12 (que no tiene Yarotows) y comparar el comportamiento con la última revisión de ReactOS (que si la lleva). Si encontraís diferencias, dejad un comentario indicando el bug que habeís encontrado. Ya nos encargaremos nosotros de reportarlo :)

Sigue leyendo si quieres conocer todas las novedades…

Las reescrituras

Como ya comentamos ( ver ), Yarotows es una mezcla de reescrituras e implementaciones de nuevas características en el subsistema Win32.
Las reescrituras realizadas son:

Reescritura del “Locking de Dispositivos”, necesario para cambiar la resolución de pantalla de manera dinámica.

El “Locking” es un concepto bastante complejo, básicamente cuando un dispositivo está siendo usado es bloqueado para evitar que sea usado por el Sistema Operativo. Esto no solo ocurre con los dispositivos hardware propiamente dicho, sino tambien con otros conceptos de software, como evitar acceder a una zona de memoria restringida o que está siendo usada para evitar corrupciones de memoria.

Reescritura del manejo de funciones Eng para conseguir un código mas limpio y compatible.

Las funciones “Eng” son aquellas que se encargan de pintar superficies y apenas existe documentación sobre las mismas.

Reescritura del manejo de código DIB.

Un DIB es un un formato usado para definir bitmaps independientes del dispositivo en varias resoluciones distintas. El propósito de los DIBs es permitir que los bitmaps puedan ser pasados de un dispositivo a otro (de ahí lo de “independiente”).

Reescritura de la creación y eliminación de DC.

Ahora la eliminación y la limpieza de DC se realiza mediante callbacks. Ya no perdemos objetos DC al terminar un proceso como hacíamos antes.
Un DC es un Device Context (“Contexto de dispositivo”) ,una estructura de datos de Windows que contiene información sobre los atributos de dibujado de un dispositivo como una pantalla o una impresora. Lógicamente no todas las pantallas son iguales, algunas usan una resolución 800x600, otras son 1024x700, unas son monocromas, otras a color…todo esto lo tiene que conocer el SO para “adaptarse” a las características del mismo. Lo mismo entre impresoras.
El proceso (simplificadamente) es crear un objeto CDC, dibujar y luego destruirlo. Ahora lo hacemos bajo demanda.

Las implementaciones (nuevo código)

Implementar la api LDEVOBJ.

Esta APIs ( o funcion ) es la responsable de cargar DLLs (drivers de visualización, drivers de fuentes, layout de teclados…

Implementar PDEVOBJ

Un PDEVOBJ representa un dispositivo físico y es el componente principal para manejar multiples dispositivos de representación.

Implementación de cambio de resolución de manera dinámica

Ahora podemos cambiar de resolución y de colores en “caliente”. Mas info aqui.

Implementación de funciones de mapeo ENG
Mejora el código BRUSH y XLATE eliminado varios viejos Hacks.
Mejora del código de representación de iconos.

News: El Branch Yarotows..

2010-10-25T22:07:00.001+02:00

Muchos habéis preguntado por este Branch, y ya va siendo hora de resolveros las principales dudas sobre el mismo.

¿Qué es?¿Para que sirve?¿Que estáis creando en él?¿Y porqué en un Branch?…

Seguramente no seamos capaces de saciar tanta curiosidad suelta, por lo que si tenéis alguna duda tras este mini-reportaje dejad un comentario y la resolveremos cuanto antes.

Yarotows:¿Qué significa?

Todos nuestros branchs con nombres “raros” son acrónimos que “esconden” la utilidad del propio Branch.Por ejemplo ARWINSS significa Another Rewrite of the WIN32 Sub System del que ya hemos hablado
Yarotows es el “Yet Another Rewrite Of The Old Win32 Subsystem” (Otra reescritura más del viejo subsistema Win32).

El objetivo de este branch es la reescritura del antiguo subsistema Win32. Actualmente contamos con dos subsistemas Win32, el denominado Win32Ros( que es el actual) y el “nuevo”(y aun experimental) ARWINSS. Por lo tanto en Yarotows estamos reescribiendo parte del subsistema para alcanzar el nivel de compatibilidad de Arwinss (muy superior a Win32Ros).

¿Quién está trabajando en él?

El branch Yarotows es una idea de Timo Kreuzer al que se han ido añadiendo Zefklop, Kamil Hornicek, Giannis Adamopoulos y otros desarrolladores del actual Win32Ros.

La creación de Yarotows nació como una reacción a Arwinss intentando demostrar que ReactOS con Yarotows podría alcanzar e incluso superar al actual Arwinss.

Esto es algo lógico pues Yarotows sigue la arquitectura NT (no como Arwinss) lo que asegurará en un largo plazo una mejor compatibilidad con las aplicaciones y drivers. En el Blog de ReactOS ya hemos hablado de esta cuestión y de la necesidad de comenzar cuanto antes un rewrite del antiguo subsistema mientras hacemos uso de las bondades Arwinss. (Remember: Aquí)

De Arwinss hablaremos próximamente pues se están acercando novedades.

¿En qué se está centrando Yarotows ahora?

Uno de los objetivos principales de Yarotows es la simplificación y reescritura del actual Win32Ros. Uno de los principales males de los que adolece Win32Ros es la excesiva complejidad y nulos comentarios en el código fuente. Ha sido descrito como una “auténtica jungla” con gran cantidad de follaje y “caminos tan (estúpidamente) tortuosos” que hacen imposibles seguir los fallos o encontrar la salida. De hecho ha devorado a varios desarrolladores que han osado intentar cruzarla…

Yarotows pretende simplificar y hacer más comprensible esta “selva” evitando caminos innecesarios pero siguiendo siempre la estructura NT. Una limpieza de código en toda regla que permita seguir los bugs y cazarlos.

Pero el objetivo no es únicamente abrillantar y pulir a Win32Ros, sino añadir nuevas funcionalidades por el camino.

Actualmente se ha conseguido crear soporte para cambiar la resolución(800x600, 1024x760, etc) y la profundidad del color (16,32 bits..etc) sin necesidad de reiniciar. Esto es fundamental para muchos juegos, pues habréis notado (sobre todo en juegos antiguos como Starcraft, Diablo II…) que los juegos modifican la resolución de Windows para adaptarla a sus propias necesidades, por poner un ejemplo. En el actual Win32Ros no se puede hacer, pues no es posible cambiar dichos parámetros “en caliente”, obligando al usuario a cambiar la resolución manualmente y a reiniciar el ordenador.

Esta característica no está disponible en Arwinss y es debido a que Yarotows sigue la arquitectura NT.

¿Por qué se está desarrollando en un branch?

El subsistema Win32 (ya sea Win32Ros o Arwinss) es una pieza clave del sistema operativo ReactOS ( y de Windows) por lo que es altamente recomendable hacer las modificaciones en un branch para evitar incluir regresiones durante el proceso de desarrollo. Cuando Yarotows sea estable, demuestre que tiene una compatiblidad similar a la del Trunk y las nuevas funcionalidades no presenten bugs se integrará en el trunk principal.

En breve veremos las nuevas funcionalidades en el trunk, la cuenta atrás ha comenzado :)

Lanzada versión 0.3.12 de ReactOS

2010-10-20T19:03:00.064+02:00

El dicho dice que "más vale tarde que nunca"... Y es que ha pasado casi un año desde la publicación de la versión 0.3.11, y vosotros, los usuarios, empezábais a impacientaros.

Pero la espera ha merecido la pena: más de 500 errores corregidos, muchos de ellos críticos para la estabilidad del sistema, decenas de mejoras introducidas....y en definitiva, una experiencia de usuario muy depurada con respecto a su antecesor.
Pero, claro está, aún queda mucho por hacer.

Hoy Aleksey Bragin, el coordinador del proyecto, ha comunicado oficialmente el lanzamiento de ReactOS 0.3.12 y detallado las novedades que podreís encontraros en esta versión.
Algunas de ellas ya han sido comentadas en este Blog, pero esperamos sorprenderos con muchas otras que han permanecido "ocultas" hasta el día de hoy.
Si quereís conocerlas todas solo tenéis que seguir leyendo.

Transcripcion del anuncio oficial

" El equipo de ReactOS está orgulloso de anunciar el lanzamiento de la versión 0.3.12.
Este es un lanzamiento gigantesco para el equipo, no solo por el numero de mejoras introducidas sino por el gran salto adelante desde el punto de vista de la arquitectura, estabilidad y de la adopción de algunos de los aspectos mas modernos del kernel NT en ReactOS.

Ha pasado casi un año desde el último lanzamiento, y aunque es comprensiblemente excesivo, era necesario para estabilizar el Sistema Operativo debido a la naturaleza del trabajo que se estaba realizando.

Al principio nos centramos en un único area, el mecanismo manejador de "trampas" (el trap handler mechanism) que terminamos reescribiendo completamente. Esto nos obligó a hacer cambios en muchas otras áreas realizando una gran puesta a punto y desarrollando nuevas tecnologías que fueron integradas en el núcleo.
Lo que obtuvimos fue un kernel muchísimo más moderno con un código que había sido probado menos que el código al que reemplazaba. Esto desencadenó en una gran fase de testeo para conseguir unos niveles de estabilidad y compatibilidad superiores al código sustituido.

Durante la preparación de este lanzamiento 259 bugs fueron solucionados, incluidas 61 regresiones algunas de las cuales fueron originadas en la época de ReactOS 0.3.7.
10 de estos bugs tienen más de 3 años de antiguedad, siendo el más viejo el número #969 (5 años de antiguedad)

A continuación se muestra una muy reducida lista de algunos de los cambios más importantes que han sido introducidos durante este año:

Memory Manager (Manejador de Memoria) - El Manejador de memoria ha recibido muchísimo trabajo ya que el equipo ARM ha reemplazado cada componente pieza a pieza mientras se mantenía la funcionalidad del antiguo manejador. Aunque la 0.3.12 no hace uso completamente del nuevo manejador sí que se nota una gran mejora de la velocidad,estabilidad y compatibilidad de este nuevo modelo.
Soporte NMI - ReactOS puede manejar NMIs con un Pantallazo Rojo de la Muerte, útil para capturar errores de hardware detectados por la CPU o el Bus. Además, se ha implementado el soporte para llamadas NMI de terceros, algo muy util para ciertos sistemas de servidores. Para concluir, se ha implementado parcialmente la generación de "Crash dumps" lo cual puede ayudar cuando se utiliza un interruptor NMI externo en una máquina congelada o colgada.
Reescritura del "Tral Handler"- Ahora casi todo el código de llamadas de sistemas, excepciones, trampas y fallos de la CPU está escrito en C en vez de Ensamblador. Muchos de los códigos antiguos o ya no utilizados han sido eliminados y las rutas de debugeo que consumen más recursos han sido desactivados por defecto. Además ahora los ports x64 y ARM comparten más codigo. Por último, el código está mucho más limpio y puede aprovecharse de las optimizaciones del compilador para generar el mejor código posible para la CPU en vez del antiguo código ensamblador creado a mano que era específico para ciertos modelos de CPU. El trabajo continúa con el fin de eliminar las rutinas de ensamblador restantes.
EMS - El soporte para el "Emergency Management System" ( o Headless) ha sido implementado parcialmente. Las flags de arranque documentadas por Microsoft son ahora soportadas y la información de debuggeo es mandada al puerto serie correctamente. Actualmente estamos trabajando para conseguir que EMS pueda logar y mover nuestro actual KDBG debugger a EMS. Para ello estamos creando un driver denominado SAC ("Special Administration Console").
Compatibilidad PnP- Se han hecho varias mejoras para mejorar la compatibilidad con el Hardware y el soporte de drivers de terceros.
Mejoras ACPI - El equipo ARM ha implementado drivers básicos para soportar baterías y drivers para baterías UPS de terceros, incluyendo soporte para la especificación "ACPI Composite Battery". Este soporte no está activado en esta versión porque aún queda parte de trabajo por hacer.
Un driver PCI-X nuevo - El equipo ARM ha estado trabajando en el nuevo driver de bus PCI. Anteriormente ReactOS estaba usando un driver PCI muy simple que era incapaz de soportar características de los PCIs del mundo-real, puentes PCI-PCI, etc. Con este nuevo driver la compatibilidad en hardware real , no solo en máquinas virtuales, debería aumentar sensiblemente, así como su rendimiento.
Soporte SxS - Se ha añadido código Side-by-Side así como la capacidad de cargar y encontrar manifiestos.Es un paso muy importante para ser compatibles con aplicaciones modernas que hacen uso de esta tecnología.
Arreglo de corrupciones de nuestras Pools - Las fugas mas importantes fueron solucionadas gracias a los esfuerzos combinados de varios desarrolladores de ReactOS utilizando métodos avanzados, incluyendo una versión tuneada de la máquina virtual Qemu.
Reescritura del manejo de Timers y Mensajes - El incorrecto manejo de mensajes no-encolables provocaban puntos muertos ("Deadlocks") en algunas aplicaciones que han sido resueltos con la reescritura del manejo de mensajes. La reescritura de la implementación de los Timers arregla muchos de los problemas asociados a los mismos como el conocido "mover el ratón para poder descargar en Firefox"
x64 - Aunque nuestro port x64 se encuentra en una fase temprana de desarrollo de acuerdo con la funcionalidad de su kernel, los problemas de compilación están resueltos y las funcionalidades básicas del núcleo han sido implementadas. Estos esfuerzos han sido añadidos al trunk, de tal forma que el trunk puede ser compilado como x64. Con la ayuda de las builds automáticas podemos detectar y resolver rápidamente cualquier problema. ¡No esperéis que el port arranque hasta la GUI!

El Changelog para la versión 0.3.12 es significativamente diferente al de anteriores lanzamientos, con el objetivo de crear un comprensible y conciso resumen de cambios en esta versión. Para evitar duplicar el resumen aquí, os invitamos a revisar su contenido y ver que hemos logrado. (VER)
Aunque el equipo de ReactOS ha estado presente en muchos eventos públicos y conferencias en diferentes países, hemos estado fuera de las noticias dando la sensación de que hemos reducido nuestra actividad.
Esperamos que con este lanzamiento podamos demostrar que hemos estado mucho mas ocupados que nunca tras las bambalinas."

Escrito por Aleksey Bragin

Descarga la versión 0.3.12: AQUI

unknown Exception: 0x80004005

2010-10-20T12:12:00.003+02:00

¿Alguno de vosotros ha usado el LiveCD de ReactOS? ¿sí? ¿Y habéis sacado logs de depuración? En ese caso, os habréis dado cuenta de que, al pulsar el botón de inicio, y pasar el ratón por encima de los distintos menús (no es necesario bajar ningún subnivel), el sistema nos devuelve este código de error.

Más concretamente, el error devuelto es el siguiente:

unknown Exception: 0x80004005
Context: explorer_main
Location: base/shell/explorer/utility/shellclasses.h:986
Context Trace:
- explorer_main
- WinMain()

Pero, ¿Qué clase de error desconocido es ese? ¿Es realmente un error? Mejor dicho, ¿es realmente una excepción? y en caso de serlo, ¿por qué la ejecución de ReactOS continúa normalmente, sin saltar el depurador del núcleo?

Software propietario y piratería.

Hay que recordar que Windows es un sistema operativo comercial, creado por personal que dedica su esfuerzo y tiempo para tratar de hacer la vida más fácil a los usuarios de ordenador. Estos programadores, no trabajan gratis. Con este trabajo sustentan sus familias, compran sus caprichos... ganan su sueldo, en definitiva. Lo cual es la base de cualquier empleado, de cualquier compañía, y de cualquier sector.

De ahí que la piratería de software pueda implicar perjuicio para estos empleados. Su producto (Windows, en este caso), en lugar de ser vendido millones de veces, y generar ingresos ingentes, podría ser vendido una única vez, y copiado millones de veces. Y los programadores que tanto esfuerzo y tiempo han invertido en el desarrollo, no verían su esfuerzo recompensado.

Claves de activación.

La forma más común de evitar ésto siempre ha sido la de incluir claves de activacion en el software. Winzip, WinRAR, Nero, Winamp, y, por supuesto, Windows, son un ejemplo. En el caso de Windows, el sistema se valida de vez en cuando a si mismo, e incluso, en actualizaciones aleatorias, el sistema de generado de claves puede cambiar, para así interferir en el funcionamiento de los llamados KeyGens (generadores de claves), o de otras herramientas que puedan intentar engañar al sistema de validación del sistema.

Pues bien, si buscamos dicha expeción en el sitio MSDN de Microsoft, encontramos lo siguiente:

Código de error 0x80004005

Este problema puede ocurrir si falta un archivo necesario para la Activación de productos de Windows (WPA) o si está dañado. Este comportamiento tiene lugar si se cumple alguna de las dos condiciones siguientes:

Una utilidad de copia de seguridad o un programa antivirus de otro fabricante interfiere con la instalación de Windows XP.

Un archivo que WPA requiere se modifica manualmente.

(Extraído de http://support.microsoft.com/kb/914232/es )

Desde luego, el LiveCD de ReactOS no trae actualmente programas de copia de seguridad incorporados, y mucho menos ningún antivirus activo. Luego la única opción posible es la modificación de algún archivo que requiera WPA. Y esto sí tiene bastante sentido.

Porque ReactOS no es software propietario, sino libre. Y, por supuesto, sin licencia que restrinja su uso. Así que, no tiene ningún sentido incluir ninguna herramienta de validación (WPA). Pero, por compatibilidad con Windows, estas llamadas deben hacerse. Y ReactOS siempre va a ser legal, por lo que dicha validación, efectivamente modificada manualmente, siempre dará un resultado positivo (o debería, al menos).

Esta es la razón por la cual vemos dicha excepción en el log. Y, como no es ningún error real de ninguna aplicación, ni del sistema operativo, el depurador del núcleo sencillamente lo ignora. Y continúa adelante.

News: 0.3.12..Changelog acabado, Testeo finalizado..

2010-10-18T23:37:00.000+02:00

Durante estas semanas hemos estado tremendamente liados con los últimos testeos de la 0.3.12 Release Candidate (versión candidata). Sin embargo, el principal motivo de que aún no se haya lanzado la versión 0.3.12 es nuestro Changelog.

El Changelog es un “resumen” de todos los cambios que se han producido/introducido en la versión 0.3.12, y por fortuna son muchos, demasiados. La versión 0.3.11 fue lanzada hace casi un año ya y desde entonces hemos resuelto más de 259 bugs, arreglado 61 antiguas regresiones, e introducido innumerables mejoras..

Zwabbit ha terminado por fin el Changelog de la versión 0.3.12. Sin duda ha sido un trabajo titánico pues ha resumido todos los cambios haciendo que (por primera vez) puedan ser comprendidos por los usuarios. Es la primera vez que el Changelog está orientado hacia el Usuario en vez de a los Desarrolladores, de tal manera que cualquier persona pueda comprenderlo.

Al mismo tiempo los Testeadores se han encargado de chequear la nueva Release Candidate,que podéis descargar desde aquí. Por fortuna no nos hemos encontrado con problemas extras y es sorprendente la estabilidad y compatibilidad de esta nueva versión.

En esta página podéis ver un resumen de los tests realizados. Disfrutad de ese precioso color verde :)
Tras aplicar los parches, crear el Changelog y testear la RC es hora de lanzar la versión 0.3.12.

El lanzamiento es inminente, así pues permaneced atentos 4…3…2…1 :)

La Conferencia Internacional del Software Libre se CANCELA

2010-10-07T22:50:00.002+02:00

Una muy triste noticia. ReactOS no podrá estar presente en la OSWC 2010 porque el evento ha sido cancelado.

La Open Source World Conference que iba a tener lugar los días 27 y 28 de Octubre en Málaga ha sido cancelada debido a problemas presupuestarios.

Comenzó la andadura en 2004 y tras 6 ediciones ininterrumpidas había logrado convertirse en un punto de referencia en la difusión y acercamiento del Software Libre a nivel mundial. Este año tenían prevista una asistencia de más de 8000 personas, y habían seleccionado 100 proyectos de nivel nacional e internacional.

Hoy mismo hemos recibido el comunicado oficial, que a continuación os mostramos, agradeciéndoos todo el apoyo mostrado a nuestro proyecto y alentando a la organización a que sigan apostando por el Software Libre.

Desde el “Blog de ReactOS” esperamos que esto solo sea un pequeño alto en el camino para retomar con renovadas fuerzas la OSWC 2011.

Para este evento el Proyecto ReactOS estaba preparando un par de sorpresas como la presentación de nuestro nuevo subsistema Arwinss (con increible compatibilidad mejorada) y el lanzamiento de la versión 0.3.12.

Sin más, os dejamos el comunicado recibido en el correo:

PS: “Hacen referencia a la 2012 porque la 2011 (en principio) será organizada por la Junta de Extremadura”

News: 0.3.12. Fase III.

2010-09-28T02:19:00.000+02:00

Como ya adelantamos la release 0.3.12 está muy cerca de ser lanzada.

Hoy se ha completado la Tercera Fase del protocolo de lanzamiento y ya estamos calentando motores.

Durante esta semana los testeadores van a tener un gran trabajo que hacer.

Si deseas colaborar y aportar tu granito de arena, podemos ayudar un poquito entre todos y de paso ser los primeros en poder toquetear la versión candidata de la 0.3.12.
Si quieres saber de que va esto de la “Tercera Fase” sigue, como siempre, leyendo.

La Tercera Fase

Si recordamos, en el anterior post hemos descrito el “Protocolo de lanzamiento”. Resumiendo era:

Elección de la revisión candidata. Hecho
Creación de un Branch específico. Hecho
Añadir los Hacks para el lanzamiento. Hecho ==> LA TERCERA FASE
Preparación de la ISO.
Testeo a fondo de la ISO.
Lanzamiento.

Las dos primeras fases ya han sido completadas y hoy Khornicek ha comenzado la “Tercera Fase”.

¿En qué consiste “La Tercera Fase”?

En la FASE II se creó un Branch específico para la release: El “ Branch de Lanzamiento “ . Su nombre es: ros-branch-0_3_12

La ros-branch-0_3_12 es una “carpeta” que contiene una copia del código fuente del trunk, concretamente de la revisión 48848 del Trunk.

Mientras que al Trunk se le han continuado añadiendo parches y commits, la Branch ha sido ajena a los mismos. De esta manera se evita que nuevos fallos o regresiones sean introducidas en el Branch de Lanzamiento. Así pues toda nueva característica que se envíe al Trunk no aparecerá en la versión 0.3.12, salvo que ( expresamente ) mandemos dicho Commit también al Branch.

Además podemos mandar Commits o Parches a la ros-branch-0_3_12 sin que afecten al Trunk. Por eso es seguro trabajar en Branchs, todo lo que se haga o deshaga en las mismas no repercute al Trunk.

La Tercera Fase consiste en mandar un “Parche Especial” a la “Branch de Lanzamiento” que permite resolver las regresiones que hemos sufrido. Este “Parche Especial” es en general un conjunto de Hacks que no se deben aplicar al Trunk ya que son soluciones “ políticamente incorrectas” (aunque funcionen).
Khornicek ha aplicado varios de estos Hacks al Branch de Lanzamiento, como se puede ver en el siguiente commit:

****Commit by khornicek on ros-branch-0_3_12 :: r48911 /reactos/ (6 files in 5 dirs)****
Fixes for bugs: 5591, 5482, 5517, 5472, 5554 and 5567

These issues are either already fixed in the yarotows branch or will be solved with next sync of corresponding libs. Merging or doing full syncs before release could cause more troubles so I hope these (hack)fixes are justified.
********************************************************************************************************

Además khornicek aclara que estos problemas ya han sido resueltos en el Branch Yarotows (otro Branch de desarrollo) o que serán resueltos en la próxima sincronización con Wine. Además recalca el hecho de que hacer una sincronización con Wine (full syncs) antes de hacer un lanzamiento podría causar más problemas que beneficios y por eso se ha tomado la decisión de hacer uso de estos Hacks.

¿Y ahora qué?

Pues pasamos a la FASE IV: Creación de la ISO.
Como ya adelantamos, esta fase tendrá lugar a lo largo de esta semana, y antes del Sábado esperamos poder tener la primera (y esperemos única) ISO para comenzar a testearla.
Pero ya hablaremos de la IV fase en cuanto llegue. ;)

News: 0.3.12 preparándose para ser lanzada…

2010-09-24T02:40:00.000+02:00

Tras varios meses de esfuerzo, de matar y aniquilar regresiones, hemos conseguido una release estable y con una gran cantidad de mejoras.

Como ya comentamos en esta entrada , todos los bugs bloqueadores han sido resueltos por lo que la cuenta atrás para el lanzamiento de la 0.3.12 ha comenzado.

Ayer Zwabbit , nuestro Ingeniero de Lanzamiento, creó el branch que contendrá la versión candidata 0.3.12

Si queréis conocer un poco mas de cerca la release, los bugs arreglados y otros datos curiosos, solo tenéis que seguir leyendo :)

Fases de lanzamiento

El proyecto ReactOS sigue, desde hace bastante tiempo, un protocolo bien definido a la hora de lanzar una nueva versión del Sistema Operativo.

Elección de la revisión candidata. Hecho
Creación de un Branch específico. Ayer lo hizo Zwabbit.
Añadir los Hacks para el lanzamiento. En progreso: Añadiremos un par de Hacks y revertiremos el código ole32 y comctl32.
Preparación de la ISO. Se espera para la semana que viene.
Testeo a fondo de la ISO. No esperamos nuevas regresiones, así pues será bastante rápido.
Lanzamiento.

Datos curiosos

La release 0.3.12 es una de las más esperadas. La 0.3.12 ha sido depurada durante 10 meses antes de ser lanzada.
En la release 0.3.12 se han arreglado 259 bugs mandados a ReactOS Bugzilla.
Además se han solucionado 61 regresiones, algunas de las cuales son anteriores a la versión 0.3.7 de ReactOS.
Se han añadido traducciones a 11 lenguajes distintos.
Se han eliminado más de 10 bugs con cerca de 3 años de antigüedad.
El bug más antiguo solucionado es el número #969 (ver siguiente sección) el cual tiene 5 años de antigüedad.

Bugs solucionados

Aquí podéis encontrar un listado completo de los Bugs solucionados.
A resaltar los siguientes:

#969 FIX: Ventanas minimizadas son mostradas en el escritorio.

Ya nunca mas (eso esperamos) al minimizar la ventana se quedará minimizada en el escritorio, sino que se minimizará a la barra de tareas.

#1225 FIX: El fundido alfa en los iconos no funciona. No hay soporte para el canal alfa en el control “lista de imágenes”

El canal alfa nos permite “fundir” los iconos con el escritorio. Es bastante usado para hacer la típica sombra debajo del icono. Antes ReactOS únicamente pintaba una sombra negra, ahora pinta una sombra translucida (canal alfa)

#2393 FIX: Firefox: Necesitas mover el ratón para descargar.

Debido a nuestro regular manejo de los mensajes , era necesario empujar la cola de mensajes creando nuevos mensajes(moviendo el ratón) para que Firefox y otras aplicaciones pudieran navegar/ejecutarse correctamente.

#2733 FIX: No se puede instalar con un GRUB, Lilo, previamente instalado

Un bug que ha molestado a mas de uno, por fortuna ya está resuelto. Aún será mas fácil de testear ReactOS.

#2835 FIX: Opera 9.64: Incapaz de localizar timer en la cola de mensajes

Y una vez resuelto el bug podemos navegar con Opera 9.64, probadlo porque funciona magníficamente en la versión 0.3.12

#3481 FIX: Firefox 3 – El texto de la página desalineado

No solamente en Firefox3, en otras aplicaciones también hemos encontrado estos problemas gráficos (Celtx, el nuevo SeaMonkey, Songbird,etc..). Ahora Firefox 4 es también utilizable.

Ya daremos mas detalles una vez hecha la release. Estad atentos ;)

News: Resultados de las votaciones en el OpenSourceWorld Conference

2010-09-22T00:37:00.000+02:00

Como sabréis ReactOS desea participar en la “Conferencia Internacional del Software Libre” que tendrá lugar los días 27 y 28 de Octubre en Málaga.

Con este fin hemos presentado la ponencia “ReactOS no es Windows…pero se le parece” (en un alarde de imaginación sin precedentes ).

Este año la organización ha permitido que los asistentes a dicha Conferencia pudieran votar los proyectos mas interesantes y así realizar una preselección.

Si queréis saber algo más de este evento y como ha quedado ReactOS en las votaciones, solo tenéis que continuar leyendo.

La Conferencia Internacional del Software Libre

La Conferencia Internacional de Software Libre, Open Source World Conference (OSWC), es probablemente el evento europeo más importante relacionado con las tecnologías de fuente abierta.

Además queremos fomentar las oportunidades de networking que promuevan el intercambio de experiencia, colaboraciones y nuevos negocios y dispondremos de salas de reuniones para facilitar el contacto y organizar encuentros in situ entre los asistentes, especialmente entre empresas y profesionales del sector TIC.

Este Conferencia gana cada año en importancia y de nuevo hemos logrado organizar un evento incomparable. La asistencia prevista supera los 8.000 participantes y nuevamente contaremos con el patrocinio de las empresas más importantes del sector y la presencia activa de instituciones europeas, nacionales y autonómicas, y de las comunidades de Software Libre a nivel mundial.
(Extraído de: http://www.opensourceworldconference.com/malaga10/?q=node/9 )

ReactOS y las votaciones

Aunque la candidatura de ReactOS fue presentada de manera tardía ( con la gran fortuna de que prorrogaron el plazo de aceptación de papers), ha demostrado ser una de las ponencias que más interés han levantado entre los futuros asistentes de esta Conferencia.

ReactOS ha conseguido 231 votos y una media de 4.0 ( sobre 5 ). ReactOS ha sido no solo el proyecto más votado sino, además ,el que mejor media ha obtenido.

Sin embargo esto no asegura un lugar en la Conferencia para ReactOS ya que ahora al comité organizador le toca la ardua tarea de seleccionar las mejores propuestas.

OpenOffice, Fedora, Android, Proyectos de la Junta de Andalucía y Extremadura, VoIP, Drupal, KDE, han sido algunas de las ponencias más votadas, por lo que el nivel y la calidad de la Conferencia están aseguradas. Esperemos que tomen a ReactOS en consideración y nos permitan asombrar a los asistentes con la…si,sí,…versión 0.3.12 de ReactOS y su hermana Arwinss.

Aunque no es seguro, es posible que la ponencia pudiera contar con la presencia de Aleksey Bragin, el Coordinador del Proyecto ReactOS.

Desde “El Blog de ReactOS” os animamos a que os acerquéis por la Ciudad de Congresos de Málaga y disfrutéis de todas las charlas y talleres. Es abierto y gratuito.

News: Wine nos impide lanzar la 0.3.12 ;)

2010-09-21T02:34:00.000+02:00

Ciertamente el título es un poco (bastante) sensacionalista. Pero en parte es real...

Como ya sabéis la versión 0.3.12 de ReactOS se encuentra bloqueada debido a un conjunto de regresiones.

Las regresiones (problemas que antes no ocurrían) son lo bastante graves e importantes como para que hayamos detenido el proceso de lanzamiento, congelado el árbol de desarrollo(trunk) y estemos creando parches para las mismas.

Si queréis conocer cuales son los Bugs bloqueadores, por qué Wine nos impide lanzar la 0.3.12 y cuanto queda para poder tener la 0.3.12 en vuestras manos....sigue leyendo.

Los Bugs Bloqueadores

Los bugs bloqueadores son aquellos bugs que , por su importancia, deben ser reparados antes de realizar un lanzamiento. El proyecto ReactOS es bastante exigente en lo que a esto se refiere por lo que somos capaces de congelar 4 meses el trunk de desarrollo si es necesario(como viene siendo el caso).
Los actuales bloqueadores son:

La regresión azul: Ya tratado aquí. (Bug #5517)
Acrobat Reader 7.1 no arranca. (Bug #5560)
Los atajos de teclado no funcionan (Bug #5472)
Acrobat Reader "pierde" memory (Bug #5560)
Opera 9.64 y Firefox 3 no arrancan (Bug #5598)
Explorer Xp muestra cuadrados negros en el control Treeview(Bug #5482)
En el Administrador de Dispositivos se muestran iconos erroneos (Bug #5591)

Parecen muchos, pero veréis que todos tienen "Truco". Empecemos.

La regresion azul.

Sin duda es la regresión que más llama la atención. Esta regresión proviene de Yarotows (un branch donde se está haciendo parte de un rewrite muy interesante).
Yarotows estaba siendo integrado poco a poco en el arbol principal cuando detectamos este Bug.
Lo curioso es que este Bug no existe en Yarotows, así pues, cuando se integre totalmente no tendremos este problema.

Lo importante es que ya existe un Hack que parece resolver este "mundo azul" de problemas.

Problema resuelto. Una regresión menos.

Acrobat Reader 7.1 no arranca.

Tal y como suena. Instala Acrobat Reader 7.1, inténtalo arrancar y verás que ocurre: Nada.
Al buscar el causante de la regresión descubrimos que es debido a un WINE Sync. (Una sincronización de las DLLs con las DLLs de Wine).
Por lo general es culpa de ReactOS ya que las actualizaciones revelan nuevos "Bugs Ocultos" (Underlying Bugs) o puede ser debido a un Hack que no hemos añadido. (Tras sincronizar ,a veces, tenemos que añadir varios Hacks a las DLLs sincronizadas y puede que alguno se nos olvide)
En este caso es una regresión...pero una regresión de Wine, no de ReactOS.
Este Bug existe en Wine.Lo podéis ver aquí: Bug de Wine
Por lo visto lo han introducido entre la versión 1.2 y la 1.3.

Estamos a la espera de un FIX.

Los atajos del teclado no funcionan

La frase es incompleta. Realmente sería: Los atajos del teclado no funcionan en la fase de instalación pero sí después. De todas formas ya existe un Hack que resuelve este problema.

Otra regresión menos.

Acrobat Reader pierde memoria

No es que la pierda, sino que la "desperdicia" (comúnmente llamado Memory Leak).
Acrobat Reader la desperdiciaba antes de que la regresión "Acrobat Reader no arranca" apareciera. Según el desarrollador actualmente este bug ya está resuelto (comprobado en otras aplicaciones a las que también afectaba este Memory leak) pero hasta que Wine no nos mande el FIX no podemos comprobarlo.

¿Otra regresión menos?

Opera 9.64 y Firefox 3 no arrancan.

De nuevo frase incompleta. Curiosamente arrancan cuando se instala ReactOS en inglés, en español, en francés,etc...Únicamente no funcionan en caso de que ReactOS haya sido instalado en Ruso/Lituano/Ucraniano. Este problema se soluciona revertiendo los cambios en el fichero: kernel32/nls/rus.nls ... que también procede de una sincronización de Wine.

Otra regresión menos.

Explorer XP muestra cuadrados negros en el control Treeview

¿Y adivinais?En Wine también ocurre. Otra regresión introducida en Wine. En este caso entre la versión 1.1.13 de Wine y la versión 1.2.
Aqui podéis ver su Bug report.
Un bug en Comctl32.

Estamos en espera de un FIX por parte de Wine.

En el Administrador de dispositivos se muestran iconos erroneos.

¿Y re-adivinaís? Efectivamente. También es un bug introducido por Wine y que ellos han sufrido. Por fortuna ya lo han resuelto. Por lo que en cuanto sincronicemos esta DLL con Wine debería de resolverse este problema.

Un bug menos.

Resumiendo

Existen 7 regresiones.
De las cuales 4 ya están resueltos.
1 aún debe ser comprobado (el Memory leak)
Y en 2 estamos esperando el correcto FIX de Wine.

Como anécdota: Wine desconocía los bugs de Acrobat Reader y Explorer XP (además de otro de Abiword ya resuelto hace semanas) hasta que no han sido reportados desde el proyecto ReactOS. Esta es la manera (y la ventaja) de trabajar en el Software Libre.

News: Avances en el USB

2010-09-17T13:45:00.005+02:00

Hace ya mucho tiempo que no decimos nada de este stack en ReactOS.

Lo cierto es que su desarrollo está siento algo lento, sobre todo debido a que ninguno de los actuales desarrolladores de ReactOS poseen (poseían) conocimientos previos acerca de los intríngulis del USB.....

Pero, a juzgar por el comentario del último commit hecho por mjmartin, su investigación y desarrollo va viento en popa a toda vela:

"Together with the usbehci driver, ReactOS at least runs the device installation wizard with the correct device description." (revision r48771)"

¿Qué se ha implementado?

O lo que es lo mismo, dicho en español:

"Al menos, ReactOS ejecuta el asistente para instalación de nuevo hardware con una descripción de dispositivo correcta"

¿Bueno, y qué significa ésto?

Pues muy sencillo, y a la vez muy importante: que el stack USB ya reconoce que se ha enchufado un nuevo dispositivo a un puerto USB, que el kernel de ReactOS es capaz de reconocer dicho mensaje, y que, en el modo usuario, el usuario (perdón por la redundancia) ve el resultado de instalar dicho dispositivo, a través del Asistente para instalar nuevo Hardware...

Sin embargo, lo único realmente implementado son ciertos mensajes de control entre la pila USB y el kernel de ReactOS. Lo justo y suficiente para que el sistema sepa que se ha enchufado un dispositivo USB, o que se ha desenchufado un dispositivo USB, y el tipo de dispositivo... y ya. Todavía no puede haber transferencias de datos, sean del tipo que sean, debido a que el actual driver no reconocería dichos datos.. y seguramente provocaría un precioso pantallazo azul (bugcheck)

¿Qué falta?

Primero, implementar estas transferencias de datos... que, debido al gran número de dispositivos diferentes entre sí que existen, no se antoja precisamente fácil...

En segundo lugar, poder instalar el driver del nuevo dispositivo.

Y tercero, acoplar dicho driver al nuevo subsistema USB, para lograr comunicar definitivamente dispositivo y sistema...

Además, recordad que el nuevo driver USB que está siendo implementado, está actualmente deshabilitado en el código fuente, o lo que es lo mismo, no se añade a la imagen .ISO del CD, aunque sí se compila.

¿Cómo incluir el driver USB en la ISO?

Para incluirlo, debéis añadir el módulo al archivo boot/bootdata/packages/reactos.dff ... pero, advertidos estáis, de que ReactOS fallará muchísimo más con el nuevo stack habilitado que sin él...

...de momento...

News: Problemas con GRUB y LILO resueltos.

2010-09-13T04:17:00.002+02:00

Si en tu ordenador tenías instalado GRUB o LILO como gestores de arranque (para lanzar por ejemplo Ubuntu) y posteriormente intentabas instalar ReactOS en otra partición, seguro que te encontraste con mensajes de error del tipo:

“Node is not a directory” (El nodo no es un directorio).

ReactOS aniquilaba el arranque de GNU/Linux.

Ahora este bug ha sido resuelto y deberías poder instalar sin problemas ReactOS para arrancarlo dualmente.

Podrás comprobarlo en la versión 0.3.12 de ReactOS.

Si no sabes que es Grub, ni Lilo, ni “gestor de arranque”, ni te suena eso del “arranque dual”, o quieres saber algo más del Bug, sigue leyendo ;)

Grub/Lilo

GRUB (GRand Unifier Bootloader) es un gestor de arranque: es lo primero que se carga cuando se inicia el ordenador.

Permite tener diferentes sistemas operativos, y diferentes versiones de ellos, en el mismo disco duro. Por ejemplo podemos tener Windows y GNU/Linux en el mismo ordenador, GRUB se cargará antes que cualquiera de éstos permitiéndonos elegir cuál iniciar.

El gestor de arranque GRUB viene preinstalado en la mayoría de las distribuciones de GNU/Linux modernas, entre ellas Debian, Ubuntu y sus derivadas. Anteriormente, el gestor de arranque más usado era LILO.

El Bug

El problema ocurría cuando Grub o Lilo se encontraba ya instalados en el ordenador(como parte de la instalación de Ubuntu por ejemplo).

Sin embargo, si se instalaba ReactOS primero y posteriormente Ubuntu, el problema no se daba.

Más info sobre el bug, aquí: Bug 2733

El Master Boot Record (MBR)

Lilo y Grub modifican una sección denominada Master Boot Record. El Master Boot Record es el primer sector del disco duro.

En informática todo empieza contando desde CERO, asi que a este primer sector también se le conoce como “Sector Cero” o “Sector de Arranque”.

En el Master Boot Record se almacenan varias informaciones:

El Gestor de Arranque+Una Tabla con las Particiones del Disco Duro+ Firma de Unidad Arrancable.

Hemos dicho que Grub y Lilo modifican el MBR, pero realmente modifican la sección “Gestor de Arranque” del mismo,con el fin de permitir tener 2 Sistemas Operativos distintos y “arrancar” Ubuntu o ReactOS en función de la elección del usuario.

Dos posibilidades

Ubuntu instalado+Instalando ReactOS:

Cuando instalábamos Ubuntu, Grub/Lilo modificaba el MBR.

Cuando (posteriormente) instalábamos ReactOS, ReactOS reescribía sobre el “Sector Cero” y aniquilábamos a Grub/Lilo ignorando la existencia de otros Sistemas Operativos previamente instalados. Entonces aparecía el Bug.

ReactOS instalado+Instalando Ubuntu:

Cuando instalábamos ReactOS el MBR era modificado.

Cuando (posteriormente) instalábamos Ubuntu, ReactOS era detectado y Grub/Lilo tenían en consideración la existencia de una instalación anterior. Todo perfecto.

Conclusión

El problema (como podéis imaginar) es mucho más complejo que esto, ya que entra en juego también la BIOS, el Volume Boot Record y la Tabla de las Particiones…

Lo importante es que el Bug ya está resuelto (o debería).

Si alguno se atreve a probarlo, solo necesita descargarse una Daily Build. En caso de encontrar algún problema, dejad un comentario con los detalles técnicos y se lo haremos llegar a los desarrolladores.

Gracias por vuestra colaboración :)

News: Parecidos razonables..

2010-09-07T16:49:00.001+02:00

(ReactOS antes de ser colonizado por una colonia de extrañas regresiones…)

(Foto de las adorables y extrañas criaturas…)

(Sonido de la regresión: Dale al play)

(ReactOS y su “Pitufitis”)

Esta es una de las regresiones que impiden el lanzamiento de ReactOS 0.3.12.

PS: ¿Alguien nos presta un Gargamel ?
PS: Gracias Usurp por el "Da ba dee"...
PS: I'm blue...

News: 0.3.12 ¿Dónde está?

2010-09-06T11:44:00.001+02:00

¿Cuándo se va a lanzar la 0.3.12?

¿Por qué no se lanza ya?

¿Qué problemas existen?

¿Cuáles se han resuelto?

¿Os habéis cansado de crear código?

¿Cómo puedo seguir su evolución?

¿Será tan buena como dicen? ¿O será mejor?

Estas y otras respuestas a continuación…

Mejoras

La versión 0.3.12 va a ser un enorme salto cualitativo de ReactOS. De eso no tenemos duda alguna. Resumiendo los mejores cambios:

Reescritura de gran parte del Memory Manager.
Resolución de múltiples problemas de Timers/Mensajes.
Resolución de graves problemas en el pintado/repintado
Soporte de “Alpha Channels”.
Grandes mejoras en el Networking.
Decenas de regresiones arregladas.

Muchos de estos cambios y arreglos han tenido lugar en la zona denominada “Kernel Área” (los cimientos de ReactOS) . Este área es sumamente delicada pues es la base de todo el Sistema Operativo y está formada por varias “subareas” muy interrelacionadas.

Memory Manager y la Tubería.

Por un momento imagina que eres Fontanero.

Supongamos que tenemos 2 Tuberías de distintos diámetros (5 y 10 cm) y un cuerpo acoplador para poder unirlos.

De pronto sentimos que el agua nos llega hasta las rodillas. La fuga solo puede venir de estas uniones.

Comprobamos las tuberías y el cuerpo acoplador, y lo que descubrimos es que el cuerpo acoplador tiene 3 salidas, 2 están ocupados por las tuberías, pero por el tercero se escapa el agua libremente.

¿3 orificios?Revisamos las especificaciones de la arquitectura NT, y efectivamente, el cuerpo acoplador solo une 2 tuberías. Alguien la “cagó” al hacerle una salida extra.

Existen dos opciones: Crear un parche de caucho que selle la 3ª salida ( a esto lo llamamos un “HackFix” ) o resolverlo correctamente(Creando un cuerpo acoplador que sigue las especificaciones de la arquitectura NT)

El Fontanero decide hacer un cuerpo acoplador con 2 orificios (uno de 5 cm y otro de 10 cm) y tras meses de esfuerzo decide cambiar uno por otro.

Vuelve a dejar correr el agua y un par de semanas más tarde vuelven a avisarle de que hay agua escapándose. El problema se ha agravado, ahora sale agua de la junta entre las tuberías y el cuerpo acoplador. Antes esto no ocurría. Es lo que denominamos “Regresiones”..

¿Pero cómo puede ser que el problema se haya agravado si ahora la pieza acopladora sigue PERFECTAMENTE las especificaciones de la Arquitectura NT?

La respuesta es sencilla. Las tuberías no son exactamente de 5 y 10 cm sino de 3 y 8 cm. Así pues el antiguo cuerpo acoplador no solamente tenía un agujero de más, sino que tampoco seguía las especificaciones de la arquitectura NT a lo que a diámetros se refiere.

Probablemente el que diseñó el antiguo cuerpo acoplador se encontró con las tuberías de diámetro incorrecto y decidió tirar “pa’lante”, pues reescribir (rediseñar) las dos tuberías le habría llevado un buen tiempo.

Así pues, al colocar el nuevo cuerpo acoplador se han provocado fugas que no tienen relación con la nueva pieza, sino con otras ya existentes. A esto se le denomina “underlying Bug” : Son fallos que ya existían pero que ahora se ponen de manifiesto.

El problema es que las dos tuberías de 3 y 8 cm “bailan” en los agujeros correctos de 5 y 10 cm.¿Qué hacemos?

Volvemos a poner un cuerpo acoplador que no sigue la arquitectura NT y que provoca fugas.
Colocar el nuevo cuerpo acoplador que sigue la arquitectura NT pero que provoca muchas más fugas.
Arreglar las tuberías para que éstas también sigan las especificaciones de la arquitectura NT.

La decisión es la tercera. No podemos lanzar la versión 0.3.12 si nuestro sistema hace aguas por todas partes(opción 2) , tampoco sería correcto volver a colocar la pieza antigua(opción 1) pues nunca mejoraríamos el Sistema Operativo. No queda más opción que rediseñar las tuberías.

El cuerpo acoplador es en este caso nuestro “Memory Manager”. Es una pieza fundamental, pues se encarga de manejar la memoria. Tener fugas aquí implica comprometer la estabilidad y rendimiento del Sistema Operativo.

Las tuberías son la “Common Cache” y otros módulos de los depende el “Memory Manager”.

Y son precisamente estos problemas los que están bloqueando,actualmente, el lanzamiento de la 0.3.12.

Algunos de estos problemas relacionados con el manejador de memoria ya han sido resueltos: Problemas del MM

Otros bloqueadores

Otro de los bloqueadores es un problema con algunos iconos que se muestran en azul. Lo que llamamos “Pitufitis”. Es un bug relacionado con el nuevo código de “Alpha Channels”.

La “Pitufitis” solo aparece cuando ReactOS corre bajo resolución de 16bits, pero se soluciona al cambiar a 32 bits.

Tal vez la solución provenga de integrar el branch Yarotows a ReactOS, ya que no sufre este problema. Pero para poder integrarlo es necesario resolver varios bugs de dicho branch.

Yarotows es una pieza muy compleja por lo que tras la integración sería necesario un gran testeo y tal vez nos encontremos con bugs inesperados.

Conclusión

El lanzamiento de la 0.3.12 se espera antes de Octubre, si los bugs actuales no nos dan quebraderos de cabeza extras.

No se lanza ya porque no está en condiciones de ser lanzada. Por un lado su estabilidad(cuelgues) se ve comprometida por los “underlying bugs” que han aparecido al reescribir el manejador de memoria(“Memory Manager”). Por otro la “Pitufitis” destroza los ojos de los usuarios.

No nos hemos cansado de crear código. Ahora solo unos pocos desarrolladores tienen acceso al árbol de desarrollo por lo que el envío de parches se ha visto mermado, pero los desarrolladores siguen haciendo parches que serán mandados al árbol en cuanto se abra.

Puedes seguir la evolución uniéndote a nuestros canales IRC (#reactos, #reactos-dev,#reactos-es)

Y sí, la 0.3.12 es muchísimo mejor que su antecesora(la 0.3.11). Prometido.

News: Otro bug mítico eliminado…

2010-08-25T14:38:00.001+02:00

El lanzamiento de la versión 0.3.12 se está haciendo esperar.Sin embargo el equipo de desarrolladores no está con los brazos cruzados.

Las razones por las que la versión 0.3.12 se está demorando son varias y las comentaremos proximamente, mientras tanto los desarrolladores de ReactOS continúan eliminando Bugs míticos.

Los dos Bugs míticos por excelencia eran/son:

Ti~~mer Bug: Mover el ratón para navegar por Internet en Firefox.~~ RIP

Contenido mostrado incorrectamente en Firefox 3.6 y superiores.

El primero cayó hace unas cuantas semanas de manos de Mjmartin.

El segundo ha sido eliminado este fin de semana.

Firefox 3.6

Las versiones posteriores a Firefox 3.6 (inclusive) hacen uso de un nuevo método para renderizar el texto mostrado.

El método es bastante complejo en el que intervienen distintas librerias.

Por un lado está Gfx, por otro Cairo/Thebes y finalmente Pango.

El texto es pasado a Cairo en forma de “Glyphs”(dibujos) para de esta manera poder manejar tanto texto “normal” como texto “especial”(hebreo,árabe, chino, indio,etc..).

Pango es la librería encargada de calcular las posiciones de los “Glyphs” en la página, para ello Gfx no utiliza las APIs de Pango de alto nivel, sino las funciones mas complejas y profundas. Pango calcula, pero no renderiza.

Del renderizado final se encarga Gfx.

¿Dónde está el fallo?¿Estamos pasando incorrectamente los “Glyphs” a Cairo?¿Está Pango fallando a la hora de elegir la posición de los “Glyphs”?¿O es GFX la que en el último momento no renderiza bien?

Cuando decimos que Pango, Cairo y GFX están fallando queremos decir que “una (o varias) de las funciones de ReactOS usadas por estas librerías tiene algun Bug que impide el correcto funcionamiento de las mismas.”

Bug resuelto

Tras indagar en las funciones, y tras miles de opiniones/investigaciones vertidas, Timo Kreuzer ha resuelto este bug.

Este Bug también afecta a muchas otras aplicaciones como “SeaMonkey 2.0” o “SongBird” entre otras.

[WIN32K] / [GDI32]
- GetTextExtentExPointI and GetTextExtentPointI take an array of glyph indices, not characters.

Pass a flag GTEF_INDICES (This is a reactos specific definition and not exactly like on Windows XP, but the real names/values are undocumented and this is the easiest way.) to NtGdiGetTextExtent/NtGdiGetTextExtentExW and handle this flag in TextIntGetTextExtentPoint to account for this.
Fixes bug 3481

Por lo visto estábamos pasando a las funciones GetTextExtentExPointI y GetTextExtentPointI un array de carácteres, cuando deberíamos pasarles un array de “Glyphs”(Sobra decir que no es lo mismo un dibujo que un carácter).

Además NtGdiGetTextExtent/NtGdiGetTextExtentExW no tenían soporte para “Glyphs” por ello se ha creado un “Flag” especial(de esta manera le decimos “Ey, que lo que te estoy pasando es un glyph.Y NO un carácter!")

Firefox 4

Firefox 4 BETA, al igual que las versiones anteriores, usa el mismo método de renderizado, por lo que el texto también se mostraba desalineado.

A la izquierda tenéis la Beta de Firefox 4 funcionando en ReactOS tras solucionar el problema de renderizado.

Newsletter 75

2010-08-11T01:28:00.000+02:00

La Newsletter 75 ha sido escrita por Zwabbit. Aquí os traemos la versión en castellano.También podéis encontrarla en Myreactos.com siguiendo esta URL.

Bitmap Drawing

LiveCD Networking

CMake

Bitmap Drawing

Los Bitmaps son,mas o menos, la principal manera en la que el subsistema Win32 dibuja las cosas. Sin embargo, el término se refiere a mucho más que al formato ampliamente utilizado para las imágenes. Este formato es generalmente considerado como un Bitmap Independiente del Dispositivo(DIB). Si existe una versión independiente existe por lo tanto una versión dependiente, que es el formato soportado por un dispositivo gráfico en concreto, para dibujar.

Convertir de uno a otro correctamente es fundamental para pintar las ventanas correctamente ya que un error puede causar decoloraciones y otros desperfectos visuales.

Jérôme Gardou ha arreglado estos problemas en el branch yarotows. Los DIBs contienen una gran cantidad de información para asegurarse de que la imagen es correctamente interpretada, tales como el formato del color, la resolución, la paleta del dispositivo que lo ha creado, información sobre la comprensión, y por supuesto, el rojo,verde,y azul que define los colores de los que la imagen está compuesta. La información está almacenada en una serie de estructuras de datos de las cuales ReactOS , por desgracia, no tiene soporte completo(especialmente para las más antiguas).

Jérôme se encuentra arreglando estos agujeros y está,casi, acabando.Solamente una función no está funcionando correctamente. Pronto debería haber otra gran fusión de código proveniente del branch yarotows.

LiveCD Networking

Cameron Gutman continúa arreglando el stack de redes y esta vez ha arreglado una serie de bugs que impedían a nuestro LiveCD conectarse a Internet. Las tarjetas de red y ciertos protocolos,como el TCP/IP , necesitan de drivers para ser manejados. NDIS es otro driver que se encargar de gestionar las interacciones entre las tarjeras de red.En concreto se encarga de informar a los drivers de protocolos(como el de TCP/IP) de la existencia de tarjetas de red.

Para que sean informados, los drivers de Protocolo tienen que registrarse con NDIS. En el caso de ReactOS, el driver TCP/IP no era arrancado tras ser instalado y NDIS también fallaba a la hora de notificar a los drivers de protocolo cuando un nuevo dispositivo de red era añadido al sistema.

Cualquiera de estos bugs impedirían conectarse a la red, pero juntos,no solo impedían al LiveCD conectarse online, sino que,ignoraban un tercer problema del servicio DHCP el cual no podía encontrar dispositivos de red que fueran añadidos posteriormente. Los dos primeros problemas ha sido resueltos mientras que el bug DHCP ha sido hackeado, por lo que necesita una solución definitiva en el futuro.

Por ahora, al menos, la gente que esté jugueteando con nuestra LiveCD será capaz de conectarse online y hacer más testeos.

CMake

RBuild ha sido un demonio necesario para el proyecto ReactOS. Mientras que las intenciones originales, desde hace tiempo perdidas, eran claramente buenas, RBuild se ha convertido en algo totalmente salvaje y difícil de mantener.

Como sistema de compilación ha fallado en la intención de proveer una buena abstracción entre las herramientas subyacientes(como compiladores y linkers), atando a ReactOS al stack GCC imposibilitándonos el uso de otros compiladores que los desarrolladores desean utilizar como el MSVC.

Muchos esfuerzos han sido realizados para intentar arreglar este problema, el último fue el intento de KJK::Hyperion. Sin embargo, desde su marcha del proyecto, nadie mas ha demostrado un deseo real de encargarse de este trabajo y muchos han cuestionado por qué ReactOS necesita tener un sistema de compilación propio. La respuesta es que no hay una buena razón.

CMake ya había atraído la atención de los desarrolladores antes, pero no había un gran empuje dentro de ReactOS para la conversión.Sin embargo, durante las pasadas semanas Amine Khaldi y el equipo ARM han comenzado a trabajar en un branch para hacer el cambio.

Han realizado un progreso considerable, haciendo que muchas librerías del modo usuario compilen. Aún falta mucho trabajo por hacer, pero con un poco de suerte, CMake sustituirá a RBuild, tras lo cual vendrán otros cambios en la infraestructura que los desarrolladores están deseando debatir.

News: 3 Regresiones menos

2010-08-05T01:31:00.001+02:00

Actualmente el trunk de ReactOS se encuentra congelado, tal y como avisamos en el post anterior.

El objetivo era bloquear la entrada de código nuevo, y permitir únicamente el envío de parches para corregir las regresiones existentes.

Hoy se han conseguido eliminar 3 regresiones críticas, y que podrían haber estado afectando a cientos de aplicaciones. Estas aplicaciones, desde ahora, vuelven a funcionar.

Si quieres saber más, continua leyendo :)

3 Regresiones, 1 único Bug.

La importancia de este bug estaba relacionada con la gran pérdida de compatibilidad que provocaba. Por ello ha sido el centro de atención de nuestros desarrolladores.

Los testeadores suelen probar regularmente un conjunto de aplicaciones denominadas “GoldenApps” (aplicaciones que tienen un nivel medio-alto de compatibilidad con ReactOS). Esto permite encontrar regresiones o controlar si la compatibilidad se ha visto incrementada.

Tras un testeo rutinario se descubrió que 3 aplicaciones habían dejado de funcionar, y las 3 mostraban un comportamiento similar. La aplicación no llegaba a abrirse pero el proceso era mostrado en el Administrador de Tareas. Las 3 aplicaciones eran: VLC 0.8.6i, Mirc 6.35, Far Manager 1.7

Si tenemos en cuenta que las GoldenApps son aproximadamente 20, y que 3 de ellas habían dejado de funcionar, esto podría suponer (extrapolando al “mundo real”) una gran perdida de compatibilidad.

El commit responsable…

Tras un largo proceso de Regtesting, se descubrió que la Commit culpable era…

Revision guilty: r47533.
Commiter: Timo Kreuzer

*********************************************

Merge 46523 from amd64 branch:

- Fix assert macro
- Add crt="MSVC" to a number of modules to resolve _assert

**************************************************

Sin embargo, este commit no había provocado la pérdida de compatibilidad,sino que arreglaba la macro “assert”.

Al arreglar esta macro (y hacer que funcionara correctamente) ReactOS ejecuta una comprobación Assert que antes no hacía correctamente.

El Assert se encuentra en:

Fichero: dll/win32/riched20/wrap.c
Línea 260
Expresión evaluada: i<len

Se puede ver el fichero aquí.

La solución.

El problema radicaba en GetTextExtentExPointA/W. Antes ReactOS no comprobaba en esta función si los parámetros eran o no válidos. De hecho, tomaba como válidos cualquier parámetro que se le pasara y hacía uso del mismo de manera indiscriminada. Esto provocaba, posteriormente, el Assert.

Un ejemplo: Supongamos que pasamos como variable Divisor el valor CERO. La función “float Dividir(Dividendo,Divisor)” debería comprobar que el valor de Divisor no es CERO antes de ejecutar la división y parar la ejecución de la función, ya que no puede dividirse por CERO. Si no se para la ejecución, el Sistema Operativo dividirá por CERO y almacenará el resultado( Quién sabe qué estará almacenando) y a partir de ahí todos los Asserts comprobatorios serán completamente erróneos.

Por tanto,es fundamental comprobar que los parámetros que una función está recibiendo son totalmente válidos, y “reaccionar” en caso de que no lo sean.

Kamil Hornicek ha creado un parche precisamente con esto en la revisión 48446, ahora GetTextExtentExPointA/W detecta parámetros inválidos y muestra un error correspondiente.

+ if(nMaxExtent < -1)
+ {
+ SetLastError(ERROR_INVALID_PARAMETER);
+ return FALSE;
+ }

Y con una cosa tan simple, las 3 aplicaciones funcionan de nuevo… :)

News: Trunk congelado

2010-08-03T18:08:00.001+02:00

Los desarrolladores y los testeadores han solicitado congelar el árbol (trunk) de desarrollo.

En los últimos meses habían aparecido varios Bugs que impedían el lanzamiento de la versión 0.3.12. Además, los desarrolladores continuaban mandando nuevo código lo que agravaba el problema al añadir nuevas regresiones.

En el estado actual es imposible lanzar la versión 0.3.12, por lo que el Jefe del Proyecto (Aleksey Bragin) ha congelado el árbol para poder (al fin) lanzar una versión que,tras la correción de estos Bugs y Regresiones, promete grandes mejoras en estabilidad y compatibilidad. El anuncio (en Inglés) se puede leer AQUI.

Desde hoy solo tienen acceso al repositorio los siguientes desarrolladores: lassy, Fireball y Tkreuzer. Limitar el acceso permite tener un mejor control sobre el código en estos momentos, controlando y revisando los parches. Esta limitación es temporal.

Además Tkreuzer ha asignado los Bugs críticos y las regresiones a los desarrolladores correspondientes. También ha solicitado a los Testeadores que localicen los commits que provocaron las regresiones, para solucionar los bugs lo antes posible.

Podéis encontrar aquí una lista de las regresiones. Tenemos más de 30 por delante, aunque varias son provocadas por el mismo bug.

Para más información sobre el bloqueo del trunk, es recomendable leer esta entrada.

La cuenta atrás para ver la 0.3.12 ha comenzado ;)

News: Sorpresa#1.La solución

2010-07-30T01:53:00.000+02:00

Dejamos de jugar a esto de los criptogramas y vamos con la solución a los mismos.

La Solución y La Sorpresa.

Solución a la primera parte:

-Efectivamente era un criptograma: “MyReactOS”

Solución a la segunda parte:

-En el texto ficticio de Tintín aparecían alusiones a : Chrome, Safari, Opera y Firefox.

-Además había un “error ortográfico” en el título del mismo: “Tintín en el Comgo”. Tal vez muy sutil. COM. La M no era una falta de ortografía ;)

¿Y qué se puede hacer con un Navegador y una palabra clave: “MyReactOS”?Pues lo evidente parecería colocarlo en la dirección de la URL y visitar:

www.myreactos.com

¿Y qué es www.Myreactos.com ? Sigue leyendo…

MyReactOS.com

MyReactOS.com es un nuevo portal de la Comunidad de ReactOS.

El actual equipo de reactos.wordpress.com moverá hasta allí su blog, en una página que ha sido creada para satisfacer las necesidades de los seguidores de ReactOS.

Las novedades que podréis encontrar son:

All+In+1: Toda la Información en 1 solo click
Sistema MultiBlog: Múltiples Blog en una única página.
IRC-CHAT: Contacta fácilmente con nosotros.
FAQ: Mucho más extensas y con videotutoriales
RosKarma: Un módulo para el nuevo Foro.
Answered Post: Un módulo de respuestas para el Foro.
RosQuests: Una divertida manera de ayudar a ReactOS

Y todo en Multilenguaje (Español incluido) ;)

All+In+1

Toda la información en un solo click.

Imagínate una única página donde encontrar todos los cambios que se han realizado en las últimas horas en el código fuente, los nuevos posts/respuestas en el foro, los últimos cambios en la Wiki de ReactOS,o las ultimas conversaciones de las Listas de Correo.

Todo sin moverte de una única página.

Para conseguir toda esta información antes era necesario visitar las siguientes páginas:

http://www.reactos.org/serendipity/

http://www.reactos.org/forum/search.php?search_id=active_topics

http://cia.vc/stats/project/ReactOS

http://www.reactos.org/es/community_mailinglists.html

http://www.reactos.org/wiki/Special:RecentChanges

Sistema Multiblog

Múltiples Blogs manejados desde un único sistema Blogging. Entre ellos, el Blog de ReactOS.

Para ello solo hay que seleccionar,de un Menú desplegable,el Blog que deseamos leer. De esta manera, y sin cambiar de página, veremos las últimas entradas de dicho Blog.

Así podréis seguir varios Blogs desde una única página. Incluso podréis crear vuestro propio Blog, si así lo deseáis. Estarán ordenados por Idioma.

IRC-Chat

Actualmente la página web de ReactOS no posee un cliente IRC integrado.

En www.myreactos.com encontraréis un cliente IRC para conectar directamente con nosotros. De esta forma podréis preguntar cualquier duda, que será resuelta (casi) al instante.

FAQs

En MyReactOS hemos añadido nuevas FAQs, más extensas y actualizadas.

Algunas redirigen a videotutoriales, otras a entradas en la Wiki de ReactOS, y otras a las entradas del Multiblogging System.

Las FAQs estarán “vivas” adaptándose a los grandes cambios que está sufriendo ReactOS.

RosKarma

MyReactOS ha creado un nuevo foro. El objetivo es tener un lugar donde la Comunidad pueda ayudarse. Para ello hemos actualizado el foro, incluyendo un módulo de RosKarma.

Ahora puedes puntuar las respuestas de manera positiva o negativa de un usuario y además podrás ganar RosKarma al escribir o contestar posts.

De esta sencilla manera se acabarán los Trolls, que serán baneados automáticamente cuando su RosKarma sea –666.

Answered Post

Hemos creado otro nuevo módulo para el Foro. Ahora el usuario que ha abierto un Topic, o un desarrollador, puede seleccionar una de las respuestas como “La Respuesta”. Automáticamente la respuesta cambia su fondo a Verde, y en el Foro se indica que dicho Topic ha sido solucionado.

Una manera rápida de encontrar las soluciones.

RosQuests

Las RosQuests son pequeñas misiones que se publicarán en el Foro. Estas misiones pueden ir desde comprobar la existencia de un Bug, testear una o dos aplicaciones, o mandar una captura de pantalla. Tendrán un tiempo limitado de resolución, y quien las resuelva obtendrá Karma.

Así podréis ayudar al desarrollo de ReactOS sin un gran esfuerzo y de manera coordinada. Con un puñado de granos de arena formaremos una montaña.

Y muchas novedades más como integración con las Redes Sociales (Facebook, Tweeter,…), Multivideo Box, Galería de Imágenes Imageflow, entre otras…

Borrador automático

2010-07-29T12:41:00.000+02:00

Borrador automático

2010-07-29T11:01:00.000+02:00

Borrador automático

2010-07-29T08:22:00.000+02:00

News: Sorpresa #1.Final

2010-07-29T00:09:00.000+02:00

El post anterior ha batido el record de visitas (más de 500 visitas en solo 24 horas), pero sobre todo el record de comentarios, lo que demuestra que hay ganas de novedades :)

Casi todos habéis descubierto el mensaje “oculto”, lectores de habla no española incluidos.

Algunos os habéis quedado en la primera parte del mensaje, tal vez lo más complicado era saber que hacer con él (pues no había pista alguna).

“Tintín y el profesor Tornasol, acompañados de la cantante de ópera Bianca Castafiore cogieron el cromado avión en Paris con dirección a Kinshasa. Su intención era embarcarse en un safari durante 2 semanas en busca del legendario zorro de cola de fuego.”

En este párrafo, extraído de la versión ficticia “Tintín en el Comgo”, se encuentra la pista definitiva para llegar a la sorpresa.

La cuenta atrás (como dijimos) ya ha comenzado…

Sorpresa #1: Se va acercando..

2010-07-27T01:37:00.000+02:00

“ Mientras los desarrolladores prosiguen su frenético trabajo en ReactOS, algunas sorpresas van tomando su forma definitiva.

Y aunque los principales beneficiados seran los seguidores de “El Blog de ReactOS”, esta sorpresa #1 promete alcanzar a todos y cada uno de los seguidores de este Sistema Operativo.

ReactOS se ha ido haciendo cada día mas grande. Más de 6 millones de descargas lo atestigua.

Es hora de pequeños avances para alcanzar grandes metas.

Ahora será más de todos, y menos de cada uno.

Cada hora cuenta.La cuenta atrás ha comenzado.

Todavía quedan un par de días antes de la llegada definitiva.

Os hemos dejado un mensaje oculto en esta entrada…

Solo tenéis que encontrar la pista definitiva…“

¿Quién será el primero en encontrarlo?

News: Conferencia Internacional de Software Libre (Málaga)

2010-07-23T01:14:00.000+02:00

La Conferencia Internacional de Software Libre 2010 se desarrollará este año en Málaga durante el 27 y 28 de Octubre.

Como no podía ser menos, ReactOS se ha inscrito en este ciclo de Conferencias con la ponencia “ReactOS: El Sistema Operativo que no es Windows..pero se le parece.”

Este año ante la cantidad y calidad de las ponencias enviadas han habilitado un sistema de votaciones para que el público demuestre sus preferencias.

Si queréis que apoyar a ReactOS (y su difusión) nada mejor que dejar vuestro voto(para ello seleccionad el número de estrellas, cuanto más estrellas iluminadas mejor) y de paso, no dejéis escapar la posibilidad de ver algunos de los mejores proyectos software libre.

Podéis dejar vuestros votos aquí:

En español:

http://www.opensourceworldconference.com/malaga10/?q=node/953

En Ingles:

http://www.opensourceworldconference.com/malaga10/?q=en/node/135

Fecha límite 31 de Julio.

Arwinss: Arwinss Vs Win32Ros (II)

2010-07-20T16:23:00.000+02:00

Ayer publicamos la primera parte del estudio comparativo entre Arwinns y Win32Ros.

Es recomendable su lectura antes de continuar leyendo esta entrada, pues allí se detalla qué estamos haciendo, cómo lo estamos haciendo y se explican las gráficas que veréis a continuación.

El estudio se ha realizado con Arwinss 47966 y con Win32Ros 47966.

Sin más …la primera parte de los resultados…

Comctl32

Comctl32.dll es una librería de controles comunes ( Common control). Un control común es una ventana que permite la interacción con el usuario. Las Tooltips , la vista tipo árbol (Treeview), las flechas arriba/abajo (Updown) de una barra de desplazamiento, o las barras de progreso (Progress bar),entre otros controles, forman parte de esta librería.

Para más información de los Controles: MSDN

A continuación la tabla que recoge los resultados del testeo de esta Suite:

Analizando la gráfica de la izquierda destacan los resultados de la subsuite “Monthcal” : En Arwinss se ejecutan más tests, y además con un menor número de fallos.

La Monthcal suite se encarga de testear el control tipo calendario. Este es el tipo de control con el que cambiamos la fecha de Windows(por ejemplo).

De manera similar la subsuite “Status” ejecuta más tests en Arwinss que en Win32Ros y además con un menor número de errores.

La subsuite “Status” testea la “Status Bar” (Barra de Estado). Esta es la barra que aparece en la parte inferior de las ventanas y que sirve para mostrar distinta información.

Sin embargo, la subsuite “Updown” demuestra que el comportamiento del control up-down funciona mejor en Win32Ros que en Arwinss. No solo se ejecutan más tests, sino que además con menos fallos.

A la derecha se muestra la gráfica relativa, que permite ver mejor las diferencias entre Arwinss y Win32Ros en cada SubSuite.

Este gráfico nos permite ver fácilmente donde Arwinss es mejor y peor que Win32Ros.

Arwinss es peor en: Updown.

Arwinss es ligeramente peor en: Datetime, Mru, Tooltips.

------------------------------------

Arwinss es mejor en: Trackbar, Treeview

Arwinss es mucho mejor en: Monthcal, Status.

Links:

About Common Controls: MSDN
Control Library: MSDN

Gdi32

Gdi32.dll es la librería de interfaz gráfica, la cual contiene las funciones de dibujado de ventanas y objetos, y de manejo de fuentes, entre otras.

Arwinss ha demostrado que presenta menos fallos gráficos que Win32Ros al testear aplicaciones. Por lo tanto deberíamos observar un (mucho )mejor rendimiento de la Suite GDI32 en Arwinss que en Win32Ros. Aquí hay varios ejemplos: Adobe Reader, Gimp, Evince,

A continuación la tabla que recoge los resultados del testeo de esta Suite:

Los resultados,obviamente, no son los esperados. Los tests ejecutados y fallados son muy similares como para explicar la notable diferencia visual entre ambos Subsistemas. ¿Cuál es la razón entonces?

En Win32Ros la SubSuite “Font” no llega a finalizar. Todas las SubSuites tienen asignadas un tiempo para terminar el testeo. En caso de que no finalice en el tiempo indicado, la SubSuite es marcada como CANCELADA.

Sin embargo, Arwinss no tiene este problema y la Subsuite “Font” finaliza correctamente. Esto podría explicar porqué Arwinss no sufre el problema de fuentes que sí sufre Win32Ros en Firefox 3.5 y superiores. Pero esto no explica la menor cantidad de fallos visuales y gráficos que tiene Arwinss.

Los tests ejecutados en Arwinss y Win32Ros son exactamente los mismos, sin embargo Arwinss parece mostrar un mejor resultado en casi todas las SubSuites.

Llama la atención que Arwinss saque peor nota que Win32Ros en las SubSuites “Palette” y “Pen”.

Arwinss es ligeramente peor en: Palette, Pen

-------------------------------------

Arwinss es ligeramente mejor en: Gdiobj,Mapping

Arwinss es mejor en: Path,Clipping,

Arwinss es mucho mejor en : Fonts

User32

User32.dll es la libreria encargada de manejar las ventanas, los mensajes , los timers , los menus y las comunicaciones.

A continuación la tabla que recoge los resultados del testeo de esta Suite:

Los resultados de cuatro SubSuites llaman poderosamente la atención.

Por un lado tenemos la SubSuite User32:CursorIcon. Esta Subsuite no termina de completarse en Win32Ros debido a que agota el tiempo asignado para el testeo( CANCELED) mientras que en Arwinss se ejecuta perfectamente. La Subsuite CursorIcon se encarga de testear la creación, carga y destrucción de Iconos y Cursores.

En segundo lugar sorprende los resultados obtenidos de la SubSuite “Input”, mientras que en Win32Ros se ejecutan más de 15000 tests, en Arwinss solo se ejecutan 1300. La SubSuite “Input” testea las APIs relacionadas con el teclado como son: BlockInput, GetKeyboardState, IsWindowEnabled, SendInput… ¿El talón de Aquiles de Arwinss? Arwinss 0-Win32Ros 1

En tercer lugar la SubSuite “MSG”. En Arwinss se ejecutan más de 16000 tests, mientas que en Win32Ros solo se ejecutan 40. En esta SubSuite Arwinss devuelve el tanto anterior. 1-1.

El fallo clamoroso que presenta Win32Ros en esta SubSuite puede explicar los problemas gráficos que sufre y que no eran explicados con los resultados del test GDI32.

Todos los botones de las Toolbars, cada elemento clickable, cada caja de texto, cada menú desplegable, cada vista tipo árbol, es una Ventana. Todo en Windows y ReactOS son Ventanas. Si tenemos en cuenta que la SubSuite “MSG” se encarga de testear la correcta creación,muestra y posicionamiento/reposicionamiento de Ventanas(ya sean ventanas hijas, ventanas inicialmente no visibles,etc…) mediante las funciones CreateWindow,ShowWindow y SetWindowPos (entre otras), es comprensible que si ReactOS no coloca en el lugar adecuado la Ventana,podamos encontrarnos con ventanas semiocultas y zonas en las que se ve el fondo de escritorio, o,directamente,con ventanas que no abren.

En Arwinss,además, se completa la SubSuite “Win”, mientras que en Win32Ros no lo hace. Esta SubSuite se encarga de comprobar cual es el dueño de una determinada ventana, para ello va creando y eliminando ventanas padres(de las que dependen las ventanas hijas), asigna como padres a ventanas hijas,muta a ventanas padres para que se comporten como ventanas hijas,etc. Teniendo en cuenta que la SubSuite “MSG” es incapaz de crear correctamente Ventanas, es bastante razonable encontrar muchos problemas en esta SubSuite. Arwinss 2- Win32Ros 1.

Otro pequeño fallo de Arwinss es que aún no parece tener implementada la funcionalidad de Portapapeles como demuestra la SubSuite “Clipboard”. Esta situación va a cambiar pronto ya que los Desarrolladores se encuentran implementándola.

Arwinss 2-Win32Ros 2.

Arwinss, por contra, destaca en la SubSuite “dde”, donde no solo corre más tests sino que además lo hace con un menor numero de fallos. La “dde” testea las funciones DDEML, que permite el intercambio de datos en la memoria compartida. Arwinss3-Win32Ros2

Intentando remontar Win32Ros demuestra una ligera superioridad en “Sysparams”. Si bien Arwinss corre 14 test más,lo hace con 70 fallos más. Por lo tanto el balance queda negativo. Arwinss3-Win32Ros3

Algo parecido ocurre con “Listbox” donde Win32Ros ejecuta mayor número de tests(+200) y solo falla en 27 más. Arwinss3-Win32Ros4.

Por último Arwinss consigue reducir el número de fallos en las Suites: “broadcast”,”combo”,”dce”,”dialog”,”edit”,”resource”,”scroll”. Arwinss4(ó 5)-Win32Ros4

Arwinss es mucho peor en: Input

Arwinss es peor en: Clipboard,listbox

Arwinss es ligeramente peor en: sysparams

-------------------------------------

Arwinss es ligeramente mejor en: broadcast, combo, dce, dialog, edit, resource, scroll

Arwinss es bastante mejor en : Dde

Arwinss es mucho mejor en: CursorIcon, Msg, Win

Links:

User32:Input: MSDN
DDEML: MSDN

Y mientras vais analizando y digiriendo toda esta gran cantidad de datos, el equipo de “El Blog de ReactOS” continúa creando nuevas gráficas para la tercera y última parte de este estudio…

Arwinss: Arwinss VS Win32Ros (I)

2010-07-19T14:22:00.000+02:00

Hasta ahora la manera de comparar la mayor o menor compatibilidad de Arwinss respecto a Win32Ros consistía en instalar y ejecutar aplicaciones. O lo que es lo mismo, un estudio cualitativo de Arwinss.

El equipo del “Blog de ReactOS” ha realizado en primicia un completo estudio cuantitativo y comparativo entre Arwinss y Win32Ros. Los números no mienten:

6 horas de testeo y recopilación de información.

Casi 10.000.000 de tests.

¿Quién pasará mas tests: Arwinss o Win32Ros? ¿Quién será,por tanto, más compatible?

¿Descubrirá este estudio algún punto débil de Arwinss?

¿Encontraremos algún resultado inesperado?

Tras el salto podréis ver la primera parte de este primer estudio comparativo entre Win32Ros y Arwinss, donde se demuestran las virtudes y los defectos de ambos subsistemas.

Un estudio realizado en primicia por el equipo de “El Blog de ReactOS” y que no podréis encontrar en ningún otro lugar.

La verdad de Arwinss al descubierto.

¿Que son los Winetests ?

Los Winetests son pequeños tests cuya misión es comprobar que la implementación de las APIs es correcta. Para ello compara el resultado devuelto por la API con el que devolvería Windows.Si ambos resultados coinciden,el test se considera pasado,de lo contrario, el test es fallido.

Los Winetests son creados por el proyecto WINE con el fin de testear las APIs desarrolladas por ellos; sin embargo su concepción es independiente del Sistema Operativo, y de hecho los Winetests son utilizados por ReactOS(Win32Ros) para evaluar su nivel de compatibilidad.

En la actualidad se testean sobre ReactOS más de 10 millones de Winetests ( las cuales están subdivididas en “Suites” ) por lo que estadísticamente los resultados de compatibilidad son bastante fiables.

De la misma manera que ReactOS(Win32Ros) y Wine comprueban su nivel de compatibilidad con estos Winetests, el equipo de “El Blog de ReactOS” ha decidido correr dichos Winetests sobre ReactOS (Arwinss) con el objetivo de comparar los resultados entre ambos subsistemas.

Esta es la primera vez que se corren estos tests sobre Arwinss.

Consideraciones Previas

Arwinss y Win32Ros pueden parecer muy diferentes, sin embargo comparten gran cantidad de código. Los resultados más interesantes se obtendrán en aquellas áreas donde Arwinss y Win32Ros aborden la codificación de sus APIs de manera radicalmente diferente.

Estas áreas ( o Suites de testeo ) son: User32, comctl32, gdi32

Y en menor medida: Kernel32

Aunque el estudio se ha realizado de todas las Suites ( y que publicaremos próximamente), aquí nos centraremos en estas 4, ya que son los elementos diferenciadores de compatibilidad.

Crashed Suites

Tanto Win32Ros como Arwinss sufren las denominados “Crashed Suites”. En cada Suite se testean decenas de Winetests(en algunas Suites incluso millones), si alguno de ellos consigue bloquear el Sistema Operativo entonces la Suite se cuelga y es considerada como CRASHED.

Hasta que no se testean todos los Winetests de una Suite no podemos conocer cuantos han fallado o cuantos han sido correctos, por lo tanto si la Suite se cuelga antes de finalizar, no nos informará del numero de tests realizados y fallidos. Es una limitación del proceso de testeo. Por ello el resultado de testeo (de esa suite) se marca como “Crashed” sin indicar el número de tests fallidos.

Hay formas de evitar que una Suite se cuelgue y sea marcada como “CRASHED”, por ejemplo eliminando el Winetest que provoca el cuelgue de la Suite. De esta manera la Suite termina correctamente y nos indica cuantos Winetests han sido testeados y (de esos) cuantos han sido fallidos.

A ReactOS(Win32Ros) se le han añadido varios HACKS para evitar el cuelgue de varias de sus Suites. Esto nos permite llegar hasta el final y obtener información muy valiosa del resto de los winetests de la Suite.

Sin embargo, aún no se han añadido estos hacks al código de Arwinss. Esto provoca que varias Suites se cuelguen en Arwinss mientras que no lo hacen en Win32Ros. Por ello hemos sido benevolentes con Arwinss,ignorando las Suites que se cuelgan en Arwinss pero que funcionan en Win32Ros(debido, en parte, a estos Hacks).

Como comprobaréis,realizando el estudio nos hemos encontrado que Arwinss no se cuelga en ciertas Suites en las que sí se cuelga Win32Ros. Teniendo en cuenta que no se han añadido hacks a Arwinss, y que Win32Ros es un sistema estable(y no en desarrollo como lo es Arwinss) , hemos optado por no eliminar las Suites en las que Win32Ros se cuelga y en las que Arwinss no lo hace. Puede sonar bastante estricto, pero si Arwinss no se cuelga en una Suite (y sí lo hace Win32Ros) es debido a méritos propios y tiene que ser valorado.

Tests Dependientes

En los Winetests aparece el concepto de Test Dependientes. A veces fallar un test implica que varios cientos de tests no son ejecutados por tener una dependencia directa.Un ejemplo: Supongamos que Win32Ros es incapaz de crear una ventana, entonces es inútil (y peligroso) hacer tests de minimizado, maximizado o de trasladado de una ventana “inexistente”. Estos tests son dependientes del anterior (“crear ventana”) y por lo tanto no son ejecutados.

Esto explica porqué el número de tests ejecutados por una misma Suite en Win32Ros y Arwinss puede ser totalmente diferente.

Interpretación de las gráficas

Cada Suite está dividida en SubSuites. Por ejemplo: La Suite GDI32 está dividida en las Subsuites GDI32:FONT, GDI32:BITMAP (entre otras).

Cada Subsuite es testeada, y son representados 4 valores: El número de tests ejecutados en Arwinss (Azul oscuro) , el número de tests ejecutados en Win32Ros (Azul claro) , el número de tests fallados en Arwinss (Rojo oscuro), el número de tests fallados en Win32Ros (Rojo claro).

Con el fin de resaltar las diferencias entre Arwinss y Win32Ros, se ha creado una segunda gráfica, una gráfica relativa. Esta segunda gráfica muestra las diferencias de Arwinss respecto a Win32Ros en cada SubSuite. Ejemplo: Si en Arwinss se ejecutan 10000 tests y en WIn32Ros se ejecutan 9800, en la gráfica relativa se representará la diferencia (200). Si el valor es positivo(200) indica que en Arwinss se han ejecutado 200 tests más que en Win32Ros. Si el número fuese negativo indica que en Arwinss se han ejecutado menos tests que en Win32Ros. Cuantos más tests se ejecuten mucho mejor.

Además en esta gráfica también se comparan los Tests fallidos (también de manera relativa). Ejemplo: Si en Arwinss fallan 100 tests y en Win32Ros fallan 150 tests, en la gráfica se representará la diferencia(-50). Si el valor es negativo (-50) indica que Arwinss falla menos que Win32Ros.De hecho falla en 50 tests menos.

Hasta aquí la primera parte de este Estudio.

Mañana publicaremos los resultados… ;)

Entrevistas: Un nuevo desarrollador

2010-07-11T13:17:00.000+02:00

Poco a poco nuevos desarrolladores van uniéndose al equipo de ReactOS.

En este caso Gabriel_it ha conseguido tal preciado mérito.

Gabriel_it comenzó como testeador, y se ha convertido en uno de los principales testeadores de Arwinss, encargándose de probar este nuevo subsistema. Poco a poco ha ido adquiriendo el nivel necesario para convertirse en Desarrollador.

Gabriel_it es argentino pero vive actualmente en Italia. Y por supuesto habla español, así pues…nada mejor que hacerle una entrevista. ;)

Entrevista

Estoy preparándome para ver el partido de semifinales entre Alemania y España. El canal de #reactos está muy tranquilo, al mirar la lista de OPs del canal veo el nick de gabriel_it. Vamos a molestarle un rato… ;)

Pregunta: Muy buenas Gabriel.¿Te puedo robar dos minutillos?

Gabriel_it: Muy buenas.Si claro.Dime

Pregunta: ¿Cuando te uniste al equipo de Reactos?

Gabriel_it: Bueno, unirme no lo se con precisión, sigo el proyecto desde el 2005, me inscribí al foro en el 2006, mis primeros bugs los mande a mediados del 2006( problemas y traducciones ) y de ahí me fui acercando cada día mas al proyecto.

Pregunta: ¿Que fue lo que mas te atrajo del proyecto?

Gabriel_it: Conocí Reactos buscando un sistema gratuito y compatible con Windows. Eso y el hecho de que es de código abierto es lo que mas me atrajo.

Dónde habré oído yo eso. Creo que todos hemos recalado en ReactOS buscando exactamente lo mismo. Bendito y Maldito Google.

Pregunta: Recientemente te has convertido en desarrollador. ¿Cuando entraste en Reactos sabias programar?

Gabriel_it: Bueno, yo programaba desde chico, en BASIC para zx spectrum, y algo asembler de z80, varios años después aprendí pascal y recién ahora estoy aprendiendo C/ y las Api Win32 .

Pregunta: Así pues estás aprendiendo C y las Apis desde que entraste en ReactOS

Gabriel_it: Algo así, sí.

Pregunta:¿Y en que parte de ReactOS estas interesado?

Gabriel_it: Me interesa todo, pero por el momento me limito a cosas simples, que puedo entender. Me gustaría algún día mejorar la usabilidad y la apariencia de Reactos, que son una de las cosas que a mi entender están mas atrasadas.

Pregunta: ¿Piensas que con una mejor apariencia ReactOS sería mas conocido y/o que atraería mas desarrolladores?

Gabriel_it: Pienso que atraería a mas gente, y mas gente a la larga atraerá mas desarrolladores, tal vez en una relación de 100-1 (si no mas)

Pregunta: ¿En tu opinión, que funcionalidad básica le falta a ReactOS?

Gabriel_it: Lamentablemente muchas cosas. Diría el soporte USB, mínimo para teclado y ratón, pero mas que nada para llaves USB.Esta frase es corta, pero su soporte implica muchas cosas, y varios componentes internos.

Ciertamente el soporte USB y la apariencia son dos piedras fundamentales. Del USB ya hemos hablado con Mjmartin AQUI.

Pregunta: ¿Piensas que es necesario buscar un patrocinador para acelerar el desarrollo de ReactOS?

Gabriel_it: Desde mi punto de vista, es la única posibilidad para que Reactos sea una realidad en tiempo útil.

Gabriel es el principal testeador de Arwinss. Vamos a aprovechar para preguntar cómo va su desarrollo.

Pregunta: ¿Podría ser Arwinss capaz de atraer mas desarrolladores gracias a su mayor compatibilidad con aplicaciones?¿Será Arwinss "el gancho" para atraer patrocinadores?

Gabriel_it: Pienso que si Arwinss estuviese lista, ReactOS seria mas apetecible, y tal vez podría atraer patrocinadores.

Pregunta: Eres uno de los principales testeadores de Arwinss, ¿le queda mucho a Arwinss para estar lista?

Gabriel_it: No le queda mucho, pero lamentablemente últimamente trabaja solo Fireball en ella, eso se traduce en tiempos largos para poder ver mejoras
Pregunta: ¿Ayudaras a Fireball en Arwinss?¿o trabajaras en el trunk?

Gabriel_it: Me gustaría poder ayudar a Fireball, pero no es algo que podre hacer en un futuro cercano, no poseo los conocimientos necesarios para poder hacerlo.

Pregunta: En estos 5 años que llevas siguiendo el proyecto,¿has visto grandes cambios?

Gabriel_it: Sí, muchos, creo que Reactos en el 2010 es mucho mas maduro que en el 2005, como dije en el foro, desde el punto de vista de un usuario, en el 2005 Reactos podía ser mas que nada un juguete, hoy se acerca mas a un Sistema Operativo.

Vamos a ponerle en un aprieto…

Pregunta: ¿Qué mejora o bug arreglado te ha causado mayor satisfacción?

Gabriel_it: Hmm, es difícil , hay muchas cosas… pero sin duda la posibilidad de escuchar audio en Reactos ha sido todo un suceso(N.R: logro).

Pregunta: ¿Qué pregunta te hubiera gustado que te hiciera y no te he hecho?

Gabriel_it: jajaja.Bueno, ninguna, porque recién empiezo, mejor hacemos la entrevista de vuelta dentro de un año y vemos ?

Pregunta: Te has escapado esta vez…jaja

Gabriel_it: jajaj… claro

Pregunta: Te tomo la palabra, y en un año una entrevista mas larga.No sabes donde te has metido ;) y gracias por los 2(0)minutillos.

Gabriel_it: gracias a ti!

News: Los misterios del Servidor

2010-07-07T16:38:00.000+02:00

Cloong!Cloong!!

Hace 4 semanas tuvimos problemas con el servidor. El Servidor compilaba las ISOS, pero cuando ejecutaba los tests(más de 9 millones de tests) la máquina se colgaba con un error bastante extraño.

Durante una semana nuestros desarrolladores estuvieron analizando el DebugLog de la maquina virtual del Servidor. Lo curioso de la situación era que si compilábamos la ISO en nuestros ordenadores con RosBE y ejecutábamos la ISO en nuestros ordenadores, todo parecía funcionar perfectamente.Incluso los tests funcionaban!!

Varios testeadores y desarrolladores compilaron las ISOS en sus PCs y las probaron, efectivamente, todo funcionaba perfectamente. Pero el Servidor seguía dando una y otra vez el mismo error al testear la ISO en su máquina virtual.

Entonces comenzamos a aplicar el “Método Científico” para resolver este misterio…

Analizar la situación

Observar.Observa.Y comparar. ¿Cuáles son las diferencias entre compilar, ejecutar y testear ReactOS en el Servidor y en nuestros PCs?¿Por qué en uno funciona y en otro no?

La principal diferencia es que el servidor corre una máquina virtual QEMU. Nosotros estábamos probando máquinas virtuales VBOX(por lo general) en nuestros PCs.

La segunda diferencia es el compilador. El servidor no utiliza RosBE (aunque sí sus herramientas) mientras que en los PCs utilizamos RosBE. ¿Tendría esto algo que ver?

Hipotesis #1: QEMU vs VBOX

Esta hipótesis era la más factible.

Cada virtualizador “virtualiza” un Hardware distinto. Existía la posibilidad de que el último commit hubiera roto la compatibilidad con el Hardware que virtualizaba Qemu mientras que el hardware de Vbox siguiera siendo compatible.

Lo extraño es que el último commit no tenía porqué perder compatibilidad alguna respecto al hardware.

Para eliminar o confirmar esta posibilidad instalamos QEMU en nuestros PCs y ejecutamos la ISO compilada por nosotros mismos. La ISO funcionaba perfectamente. Los tests tambien eran correctamente ejecutados.

Descartada esta opción nos quedaba la segunda diferencia.

Hipotesis #2: Buildbot vs RosBE

En el servidor el encargado de compilar ReactOS es un Buildbot mientras que en los PCs se usa RosBE. Siempre pedimos que los testeadores prueben las ISOs creadas por el Buildbot y que eviten testear ISOs creadas por RosBE. Queremos a RosBE,pero a veces existen pequeñas diferencias en la compilación, introducidas por ser dos entornos distintos y para que todos testeen realmente la misma ISO.(Unos podrían estar ejecutando RosBE 1.4.4 y otros RosBE 1.5)

Para ello Caemyr nos ofreció su buildbot. Caemyr creó hace varias semanas un builbot para trastear con él y aprender su funcionamiento. El Buildbot hace uso de las mismas herramientas que el buildbot oficial.

Caemyr ordenó a su buildbot compilar y testear la ISO,esperábamos que fallara,sin embargo todo fue correcto.

Esto nos abría otro mar de dudas,¿Cómo es posible que dos buildbots iguales en servidores distintos fallaran?

Sin pistas…

Mientras tanto, nuestros desarrolladores seguían añadiendo DPRINTS y buscando información en los DebugLogs, intentando encontrar la pista definitiva. Una semana totalmente perdida.

EL mismo buildbot en dos servidores distintos fallaban.

…Dos servidores distintos…

La unica posibilidad estaba en la palabra “distintos”. Sin embargo, las maquinas virtuales tienen por objetivo “engañar” a ReactOS ya que ellas virtualizan un mismo hardware. Para la ISO de ReactOS los servidores son idénticamente iguales si se ejecutan en la misma versión de QEMU. Y ambas eran la misma versión.

Y mientras que seguíamos pegándonos cabezazos apareció la solución de mano de Collibri. Collibrí llego diciendo que había resuelto el problema.

¿Cómo?,le preguntamos. Añadiendo más disco duro, respondió.

Habíamos ocupado toda la memoria disponible.El servidor tenía toda la memoria ocupada. La máquina virtual no podía hacer uso de más memoria y había instalado ReactOS a medias. Por mucho que digamos a una máquina virtual que use 10 GB de HDD, si solo tenemos 100MB disponibles en el DiscoDuro, poco puede hacer. Instalación incompleta.

Los cabezazos fueron múltiples y repetidos.

Aún resuenan los Cloooong! contra la pared.

Aplicaciones: Exploradores de ficheros

2010-06-28T23:57:00.000+02:00

Una de las principales debilidades de ReactOS (hasta que llegue el explorer-new ) es su explorador de ficheros. Sin duda se ha quedado anticuado y ademas es bastante pesado a la hora de mostrar los contenidos de las carpetas.

Por fortuna existen alternativas en la red que podemos utilizar.A continuación una pequeña review de varias de ellas y su comportamiento en ReactOS.

Explorer XP 1.07

Su principal característica es el uso de las pestañas, y es que con Explorer XP 1.07 podemos tener unas rudimentarias,pero útiles, pestañas donde poder tener a un solo clic varias carpetas abiertas.

Tanto la selección de ficheros múltiples, como la visualización del arbol de ficheros es perfecta. No se actualiza “a golpes” como ocurre actualmente con el explorador de ficheros de ReactOS, sino que el contenido de las carpetas se muestra “de golpe”.

Los principales comandos de copiar,cortar y mover funcionan correctamente, y el único fallo,descubierto hasta ahora,es que la Toolbar no muestra los botones. Por fortuna se puede acceder a todas las opciones a través de los menús desplegables.

Descarga: http://www.explorerxp.com/explorerxpsetup.exe

Qmmander 0.1.0

Qmmander es otro explorador de ficheros que basa la exploración de las carpetas en el uso de pestañas. Además permite diferentes formas de visualización (partiendo la ventana por la mitad, mostrando un arbol de directorios,etc..).

Al igual que Explorer XP, la navegación por directorios es bastante ligera y al copiar un archivo a una carpeta es automáticamente mostrado sin necesidad de refrescar el contenido(como sucede con el actual explorador de ficheros de ReactOS).

Además permite acceder directamente a la consola de comandos(Cmd.exe) y a la calculadora sin más que apretar un botón.

En este caso Qmmander muestra sus iconos en la Toolbar sin problemas, y es bastante configurable. Su interfaz gráfica es un poco más vistosa que la de Explorer XP.

El único bug encontrado es el relacionado con las opciones“Compress” , “Uncompress” y “Rename”. Al pinchar sobre cualquiera de ellas, otra ventana debería aparecer preguntando por información adicional. El caso es que la ventana se crea, sin embargo no es mostrada(es lo que llamamos una “ghost” window).Al ser una ventana del tipo “robafocus”(la aplicación no deja que pulses en ninguna otra opción hasta que no cierres la nueva ventana) Qmmander parece que se queda bloqueado. Una forma de forzar el cierre de esta “fantasmal” ventana hija es pulsando la tecla ESC. Y todo vuelve a la normalidad. Ya estamos tras la pista de este Bug :)

Descarga:

http://qmmander.googlecode.com/files/Qmmander_0.1.0-a5-7_01102010.zip

Arwinss: The GIMP Funcionando

2010-06-24T22:12:00.000+02:00

Como ya todos saben, las aplicaciones que usan las librerías GTK+ tienen un desempeño mucho mejor cuando corren bajo el subsitema Arwinss, en contraposición a lo que suele ocurrir con Win32Ros.

Pero a pesar de los últimos testeos, nos era necesaria una prueba más evidente para confirmar lo antes dicho, y qué mejor que ponerlo a prueba con el software más conocido del medio: The GIMP. The GNU Image Manipulation Program es el legendario editor fotografico, ícono del Open Source. Justamente no es por nada, que las librerías GTK+ significan nada más ni nada menos que GIMP Tool Kit.

Instalación:

La instalación del programa sobre Arwinss es casi perfecta, sin bugs gráficos. Apenas al finalizar la instalación, aparece un mensaje de error, el cual no interfiere en nada la ejecución del programa.

Iniciación:

Una vez iniciado, la aplicación busca archivos de datos, fuentes, etc,. Claramente se nota la estabilidad del programa.

Funcionamiento:

Una vez cargados los componentes, las distintas ventanas se comportan de una manera muy similar a como en Windows, claramente se ve que casi no existen bugs gráficos, y lo mejor de todo es que la gran mayoria de herramientas son completamente usables.

En esta imagen se muestra cómo usamos la herramienta Texto sin mayor problemas:

Luego de haber testeado por algunos minutos esta aplicación, quedamos totalmente convencidos de que la compatibilidad del subsistema Arwinss con las librerías GTK+ es muy similar a la que existe en un sistema Windows, es gratificante observar el progreso que se está llevando y cómo programas open source como The GIMP funcionan estupendamente bajo ReactOS.

Hasta la próxima :)

News: Opera 9.64

2010-06-16T04:12:00.000+02:00

El principal problema que estaban experimentando los navegadores en ReactOS fue solucionado hace un par de semanas(como ya comentamos AQUI).

Esto nos ha animado a retestear varios de los navegadores con el fin de encontrar aquél que proporciona (actualmente)una mejor experiencia al usuario en ReactOS. Y el resultado ha sido sorprendente: Opera 9.64

La review a continuación..

Opera 9.64

El comportamiento de este navegador ha sido una completa sorpresa para el equipo de testeadores. Desde la sombra y sin hacer ruido ha ido alzándose como el navegador más completo y más compatible con ReactOS.

Tal vez el famoso Bug de Firefox 3.5 (que muestra incorrectamente las imágenes) nos ha tenido tan pendientes de la familia Firefox que hemos relegado a un segundo plano al resto de los navegadores.

O tal vez puede ser que no esperábamos que un navegador incapaz de abrirse correctamente (llegando incluso a “congelar” ReactOS) hace menos de un año pudiera convertirse,de noche a la mañana, en el navegador más compatible.

La compatibilidad de Opera 9.65 ha llegado incluso a superar al mítico Firefox 2 y nos ha pillado tan de sorpresa que ni tan siquiera Opera 9.65 está incluida en la lista de aplicaciones a descargar desde el ReactOS Application Manager.

Y es que, además, Opera 9.64 es una aplicación mucho más exigente que Firefox 2 en lo que ha pintado/repintado se refiere.

Firefox 2 utiliza la típica ventana tipo Windows creada a partir de nuestra API “CreateWindow”, mientras que Opera 9.64 pinta ventanas totalmente personalizadas con menus que aparecen y desaparecen en tiempo real además de ventanas flotantes de previsualización que ponen a prueba nuestras APIs de más bajo nivel.

La fluidez de Opera en ReactOS es comparable con la fluidez de Opera en Windows, tanto en la navegación como en el manejo de la aplicación. Y esto es algo sorprendente, aún más si cabe al tener en cuenta que las pruebas se realizaron dentro de una máquina virtual.

Incluso la navegación es increiblemente rápida, tanto que nos dan ganas de comprobar en un mismo equipo el tiempo de carga en XP y ReactOS.

De hecho, como una imagen vale más que mil palabras, y un vídeo vale más que mil imágenes, nos hemos atrevido(por primera vez) a capturar una sesión de navegación con Ópera para demostraros todo esto.

[vimeo 12600701]

Cada día ReactOS se va acercando un poco más al concepto de Sistema Operativo: Un Sistema capaz de satisfacer las necesidades del usuario.

Y sí, esto ha sido grabado usando Win32Ros.El trunk de toda la vida vamos :). Esperaremos a nuevas versiones de Arwinss para comparar ambas. ;)

News: 2 nuevos desarrolladores

2010-06-10T00:33:00.000+02:00

Hoy dos nuevos desarrolladores han entrado a formar parte de la gran familia de ReactOS.

Desde ahora AmineKhaldi y Zefklop ya son oficialmente ReactOS Developers.

AmineKhaldi

AmineKhaldi lleva con nosotros varios años, pero su tarea fundamental consistía en mantener nuestro Bugzilla (Bugzilla Mantainer), dedicándose a revisar los Bugs y asignarlos correctamente a los distintos desarrolladores.

Desde hace varios meses AmineKhaldi se está dedicando a limpiar y corregir los Headers incorrectos de ReactOS, de esta manera podremos compilar ReactOS con los headers de Microsoft. Esto es necesario para lograr que ReactOS sea compilable con MSVC y hacer uso de las herramientas de debuggeo de MSVC.

Zefklop

Zefklop es bastante mas nuevo en el Proyecto ReactOS.Sin embargo,desde el primer día se ha dedicado a enviar parches y actualmente se encuentra trabajando con Physicus en el Subsistema Yarotows que está siendo desarrollado en el branch “reactos-yarotows”.

¿Qué es el Subsistema Yarotows?Os lo cuento en la siguiente entrega ;)

News: Tarjetas Voodoo3 funcionando.

2010-06-07T13:20:00.000+02:00

Una de las ventajas de ReactOS frente a otras combinaciones como Wine+Linux es la “compatibilidad” de ReactOS con los drivers diseñados para Windows.

Sin embargo, los drivers de las tarjetas Voodoo 3 provocaban un Assert en la última parte de la instalación de ReactOS. Este problema no estaba limitado únicamente a estas tarjetas,por lo que la compatibilidad con tarjetas de video ha pegado un interesante salto adelante.

Si quieres saber qué es un Assert, qué problema estábamos teniendo y cuando ha sido solucionado….sigue leyendo…

¿Qué es un Assert?

Un Assert es una comprobación de seguridad.

En un código tan complejo como es el de un Sistema Operativo es casi imprescindible la existencia de Asserts. Vamos a poner un ejemplo para ver el “potencial” de los Asserts:

Supongamos que tenemos dos funciones, la Función A y la Función B.

La Función A calcula un número que va a ser utilizado por la Función B. Una particularidad de la Función A es que siempre el resultado de la Función A va a ser un número positivo.

La Función B usa este número positivo para realizar otra serie de operaciones y se lo pasa a otras Funciones. Todo correcto.

Imaginémonos que cometemos un pequeño fallo al crear la Función A, resultando que algunas veces devuelve números positivos, pero otras veces su resultado es un número negativo o cero.

La función B cogerá el valor que le ha calculado A y operará con él como si fuera SIEMPRE un número positivo. Si el cálculo de A era un número positivo, entonces el resultado de B es correcto. Pero si el cálculo de A era negativo, entonces lo que devuelva B es totalmente erróneo, y lo que es peor, este error se pasará a las funciones siguientes que hagan uso de este valor.

Si tenemos mas de 50 funciones encadenadas que usan este valor, ¿cómo sabemos quién provocó el error?Podría llevarnos bastantes horas de debuggeo.

Para eso están los Asserts.

¿Cómo usamos los Asserts en este caso?

Sabemos que la Función A SIEMPRE debería calcular un número positivo. Entonces en la Función B lo primero que hacemos es comprobar que EFECTIVAMENTE lo que nos ha devuelto A es un número positivo.

Algo tan fácil como preguntar: ¿ ES_LO_QUE_HA_DEVUELTO_A > 0?

En caso de que A no haya devuelto un número positivo, entonces obligamos a que se detenga la ejecución del código ( ¿para qué vamos a seguir si sabemos que todo lo que venga después es erróneo? ) .

El Assert es exactamente la línea de comprobación:

¿ES_LO_QUE_HA_DEVUELTO_A > 0?

De esta manera podemos localizar rápidamente dónde está el fallo (pues el resto de código no es ejecutado)

Videoprt ASSERT al instalar los drivers de la Voodoo3

Al intentar instalar los drivers de la Voodoo 3 y al arrancar ReactOS de nuevo, ReactOS “golpeaba” contra un Assert. Algo había funcionado incorrectamente y,llegados a cierto punto de comprobación, no se obtenía lo esperado.

La comprobación era la siguiente:

'FullList->InterfaceType == PCIBus && FullList->BusNumber ==
DeviceExtension->SystemIoBusNumber && 1 ==
FullList->PartialResourceList.Version && 1 ==
FullList->PartialResourceList.Revision'

Al no cumplirse estos requisitos, ReactOS evitaba continuar la ejecución de código.

Resuelto en 47068

Aicom ha resuelto este Bug en la revisión 47068.

Así pues, la versión 0.3.12 de ReactOS será capaz de cargar drivers de las tarjetas Voodoo 3 y de ,seguramente, otras tarjetas que presenten el mismo bug.

El problema era que no guardábamos correctamente el número del Bus en la la lista de recursos.

Bug - - ;

Compatibilidad ++;

News: Regresión Tworld y DosBox arreglada.

2010-06-03T16:29:00.000+02:00

Una de las regresiones que nos traía de cabeza era la que impedía a Tworld y DosBox funcionar.

Estas aplicaciones, basadas en la consola de comandos, se colgaban o no llegaban a lanzarse.

Smiley se ha encargado de solucionar este bug y ambas vuelven a funcionar sin problemas.

DosBox y Tworld

DosBox es una aplicación,basada en consola de comandos, que permite ejecutar aplicaciones DOS. Bastante útil para correr esas aplicaciones que actualmente ya no tienen soporte.

Tworld es un pequeño juego que se ejecuta sobre la consola y que es bastante adictivo, aunque sus gráficos sean de otra era(lo cual le añade un toque retro bastante curioso) :)

Ambas aplicaciones funcionaban correctamente en 0.3.10 pero dejaron de hacerlo en la version 0.3.11 de ReactOS. El motivo: Una regresión introducida en la revisión 43119

Regresión

En el caso de DosBox la ventana se congelaba nada mas mover el ratón, y al cabo de un tiempo indefinido volvía a descongelarse. Si solo se utilizaba el teclado,y no se movía el ratón,podías escribir indefinidamente. Así pues el ratón tenía algo que ver en el juego.

En el caso de Tworld, el fallo era mas grave, y no funcionaba ni el teclado ni el ratón.

Curiosamente ambas eran aplicaciones de consola, y curiosamente ambas dejaron de funcionar en la misma revisión. La número 43119

Revisión culpable: 43119

La revisión 43119 era una de esas revisiones consideradas como “WOW”, resolvía uno de los mayores problemas que los testeadores y usuarios tenían en Vmware.

Los que hayan probado antiguas versiones de ReactOS en Vmware, se habrán dado cuenta que algunas veces y sin motivo aparente, la instalación se colgaba en la segunda fase(la parte de instalación con Interfaz Gráfica), teniendo que reiniciar la máquina. Esto podía ocurrir una vez, diez veces o nunca. Era uno de esos Bugs aleatorios. Difícil de pillar y difícil de arreglar.

***********************************
The guilty commit is: 43119
***********************************
[win32k]
- Giannis Adamopoulos: Don't do callbacks to usermode when holding the lock.
Fixes the famous "VMWare video driver installer 2nd stage hang" bug. Signed off by James Tabor.
See issue #2666 for more details.
***********************************

Ciertamente, desde la revisión 43119 no hemos vuelto a tener este problema en Vmware.

Pero…¿que tiene que ver el parche de este Bug con un fallo en una aplicación de consola que se “casca” al mover el ratón? ¿Cómo pueden estar relacionados...?

… 4000 revisiones más tarde

(casi) 4000 revisiones más tarde, y ante el llamamiento de Aleksey Bragin para eliminar regresiones, Smiley decidió coger el toro por los cuernos…e indagar en el problema que su commit había revelado.

Al ya no hacer callback al usermode cuando tenemos un lock(algo que hacíamos antes y que era incorrecto), se reveló que no manejábamos correctamente dos mensajes: WH_MOUSE_LL y WH_JOURNALRECORD.

Como se ve, el primero tiene relación directa con el ratón y producía el cuelgue que DosBox y Tworld sufrían.

Aquí podeís ver el commit de Giannis Adamopoulus, alias Smiley:

***********************************
Commit by gadamopoulos :: r47058 ***********************************
[win32k]
Do not do callbacks to user mode while holding a lock
Fix when WH_MOUSE_LL and WH_JOURNALRECORD are called See issue #4926 for more details.

***********************************

Asunto arreglado y una regresión menos: regresion -- ;

3 Sorpresas

2010-06-01T15:24:00.000+02:00

Este periodo de “inactividad” bloguera se debe a que el equipo de “EL Blog de ReactOS” está inmerso de lleno en 3 proyectos que darán lugar a 3 Sorpresas.

La Sorpresa que nos robaba mas tiempo ya se ha finalizado( o al menos ya no está en nuestras manos) por lo que volvemos de nuevo(para vuestra desgracia) a la carga en el Blog.

Si quieres saber un poco más de estas sorpresas…sigue leyendo :)

La Sorpresa #1

El equipo de “El Blog de ReactOS” lleva varios meses(concretamente desde Diciembre) creando una pequeña(gran) sorpresa.

Estas dos últimas semanas nos han servido para terminar de darle forma, o de lo contrario nos veíamos en 2012.

Solo podemos decir que afectará a la Comunidad de ReactOS (ya no solo a la gente que nos sigue en este Blog, sino también a la Comunidad Internacional).

Una idea(o conjunto de ideas mejor dicho) que han sorprendido a Aleksey Bragin (el Coordinador del Proyecto ReactOS) y que nos ha ofrecido todo su apoyo.

No podemos decir mucho más…tendréis que esperar :)…pero seguro que otros proyectos copiaran (en parte) alguna de estas ideas innovadoras.

La Sorpresa #2

En esta sorpresa el equipo de “ El Blog de ReactOS ” es un mero crítico y testeador.

Esta sorpresa afecta directamente al Sistema Operativo y se ha comenzado a trabajar en ello hace un par de semanas.

De nuevo el principal beneficiado será el Usuario del Sistema Operativo.

Los resultados no serán visibles hasta dentro de un par de meses. Así pues Julio y Agosto se prometen más calentitos de lo habitual.

La Sorpresa #3

Esta pequeña sorpresa está exigiendo a los Desarrolladores y a los Testeadores un trabajo extra brutal.

Si conseguimos los objetivos que nos hemos planteado es posible que se produzca un pequeño gran revuelo alrededor de ReactOS.

Crucemos los dedos.

3 Sorpresas que irán llegando a lo largo de los dos próximos meses. El Blog de ReactOS vuelve a la normalidad ;)