Ergebnisse der Community-Choice-Awards

Die Gewinner des Community-Choice-Awards stehen fest!

Leider gehört ReactOS nicht zu den 12 Gewinnern :-(

Die einzelnen Ergebnisse mit den genauen Prozentsätzen findet man hier.

PS: Microsoft ist ein Sponsor von Sourceforge :-\

ReactOS Newsletter #62

Das ReactOS Team hat am 21.07.2009 einen neuen Newsletter veröffentlicht.

Die Themen des Newsletters sind:

• PSEH Corruption
• XLATEOBJ
• Arwinss

Den kompletten Newsletter finden Sie auf der ReactOS-Website.

Aleksey Bragin an [ros-dev]

Wie man hier sehen kann, wird zur Zeit viel an ReactOS in "Arwinss" verändert.
Heute hat Aleskey Braign dazu eine Mail geschrieben:

Betreff: [ros-dev] Arwinss

Hello,
I've heard many question about a branch I was working on recently, arwinss, so I'd like to write some explanation (you may skip the boring history part of the message)

Arwinss is a rewrite (the most advanced so far out of all previous attempts) of some parts of the Win32 subsystem, namely the USER32 and GDI32 API interfaces, along with the kernel counterpart win32k.sys. The kernel32.dll, csrss, and other parts remain in their present condition, and getting bugfixes if they come in the way of a rewrite.

[History and reasoning part starts here]
Why rewrite and not fix an existing Win32 subsystem? Timo, James and all our other great developers were and are doing a great work. I put a considerable amount of time in it to fix problems too. But, since our project is a volunteer-driven one, everyone has a real life, real work to do, and is not able to sit 24 hrs researching Windows internal structures, inventing new algorithms, trying out thousands of applications, not to say about graphics drivers. Time is ticking, Win32 is improving, but most annoying bugs are there for years - e.g. vmware installer hang, Firefox move the mouse bug, drawing glitches, concurrency hacks in the code ("if (!a) /* someone else was faster than us and already freed it */"), probable heap misusage (relying on our heap implementation for desktop heaps) and heap memory corruptions (I kept trying to update rtl/heaps to the newest Wine code - and always failed without any obvious reason), inability to change video mode on the fly, and the list can go on.

So I thought, that something should be done with it. I would even want to trade off some speed gain in favor of stability (optimizing is an enjoyable task which could be done later).

After teaming up with Stefan, we created an nwin32 branch - a totally stubbed out win23k, user32 and gdi32. They had exactly matched exports, and win32k had exactly same system calls and Windows 2003 SP1's win32k.sys. However, due to really huge amount of work, the branch didn't went farther than trying to boot Windows 2003 with it and see a few stubbed functions being called.

Since then I started thinking on an alternative design of a Win32 subsystem. The idea turned out to be very simple, and is based on the following questions:
- Why put so much effort into keeping the internal win32k system calls interface the same as in Windows, why put so much effort in converting to internal Windows structures, if we don't have something working first?
- Why base on a stoneage Wine's code which James and Christoph occasionally sync, and all my attempts to get more people into this boring task failed?
- Why not use achievements of our closest project - Wine?

[End of reasoning, fancy stuff starts]

The result came by itself: Try to build up a win32 subsystem based as much on Wine code as possible, and using Wine's modular design. Before publicly announcing it, I have spent a month actually trying all that stuff, and surprisingly it went very well, and a nice byproduct: support of remote sessions via X Windows.

Proof of concept screenshots are here:
http://www.reactos.org/media/screenshots/2009/arw_xlog1.jpg
http://www.reactos.org/media/screenshots/2009/arw_xlog1.jpg

Noone has ever done this before: This is Windows 2003 inside VMware, running my custom Win32 subsystem, with an X graphics driver module, communicating with an X Server running in the host OS (Windows XP, XMing X windows server), and with ReactOS's winlogon.exe and msgina.dll (for ease of debugging and source code availability)!

Let's go straight to the architecture:

GDI32.dll and USER32.dll are ported Wine usermode code, with very few modifications. GDI32 and USER32 depend on two things: Gdi and User driver, and a server.

Gdi and User driver is a loadable DLL, which provides an abstraction of a graphics driver in the system through a certain set of APIs. A typical example of such a driver is winex11.drv, which routes all drawing to the X Windows "client". However, this is not very useful for a local system which has a Windows NT architecture, where there is no need for remote windows displaying.

The server. GDI32 and USER32 rely on the server for managing all global information. In Wine, the server is run as a usermode wineserver.exe process, which communicates with gdi32/user32 via custom RPC, and emulates quite a lof of stuff which Windows NT kernel provides by default. My decision was to convert the RPC protocol from a slow interprocess filedescriptors-based unix-specific invocations to a fast system calls to win32k module. This way, win32k contains small part (~300 kb vs 1.5Mb+) of wineserver's source code, which deals with windows, window classes, atoms, windows stations, desktops and other totally platform/implementation independent stuff. It will be reduced further, because I even ported their own object manager for win32 objects, which will be exchange to our native ntoskrnl's object manager soon, when the testing phase is over.

The graphics driver, kernelmode part. As I said above, it's not very convinient to fully rely on X Windows for graphics output, because it's just not possible to run it in an NT-based OS which has no Win32 subsystem. Thus, I decided to create a totally native gdi/user driver ("winent.drv"), which would rely on win32k module to actually perform all drawing. However, compared to our current implementation, the drawing would be way more simple. For example, if currently LineTo operation in win32k involves complex PATHOBJ, maintaining graphics cursor -- all of that in a strictly windows compatible way because apps depend on it, in this alternative win32k, LineTo is a simple line drawing function: RosGdiLineTo(pDc, x1, y1, x2, y2). Same applies to other functions, including e.g. text output, where all rendering happens using a usermode freetype.dll, and win32k just needs to display bitmap glyphs got from gdi32.

Don't be scared if you don't understand all that right away. I will put up a good short summary, along with a TODO and FIXME lists, and a HACKING guide.

Just a few cool facts about the new win32 subsystem:
- Based on a solid, very well maintained codebase, used by commercial vendors.
- Ease of updating from upstream (vendor importing)
- Tested against more than 12 000 Windows applications (http://
appdb.winehq.org)
- ...

I think it's enough for the first introduction.

WBR,
Aleksey Bragin.

Außerdem unterstützt ReactOS seit kurzem auch mehrere Netzwerkkarten in einem System (DHCP zur Zeit nur für die 1. Karte), so dass ReactOS langsam etwas Servertauglicher wird.

Wichtige Mail von Colin Finck an [ros-dev]

Betreff: [ros-dev] Web and Mail system migration

Hello,

We're planning to migrate the Web and Mail system to a new server and upgrade these components in the next 24 hours. This affects the whole Website at www.reactos.org plus all @reactos.org mail addresses including the mailing lists. During the migration, these services may be temporarily unavailable.

The Web server migration includes upgrading the server components (e.g. Apache, MySQL, PHP) and applications (e.g. RosCMS, phpBB) to newer versions. Besides, the configuration of the server components was tuned for a better overall performance. The mail boxes, mail relays and mailing lists will be moved to a dedicated virtual machine, which will also offer a groupware system for official ReactOS developers and testers.

Our plan is to do this upgrade in two big steps, namely first the Website and afterwards the mail stuff, to keep the downtime as low as possible. Minor problems are expected after the migration and will be fixed shortly. In case of major unforeseen problems, the downtime of particular components might be extended to the next 48 hours.

Best regards,
Colin Finck
______________________________

http://www.reactos.org/mailman/listinfo/ros-dev

Neue Bilder von Gabriel Ilardi

Offtopic: Neues Betriebsystem in Planung

Zuerst die Suchmaschine, dann der Browser und jetzt auch noch ein Betriebsystem.

Geschwindigkeit, Einfachheit und Sicherheit sind die Schlüsselaspekte von Google Chrome OS

konnte man auf dem offiziellen Google-Blog nachlesen.

Google möchte mit dem Chrome OS in den direkten Konkurrenzkampf mit Microsoft gehen und ein eigenständiges Betriebsystem entwickeln.
Das OS soll überwigent auf Netbooks zum Einsatz kommen und eine Einheit aus Browser und Betriebsystem darstellen.

ReactOS im Netz

1.290.000 Suchergebisse auf Google. Wer hätte das gedacht?
ReactOS wird immer beliebter!

Wer immernoch denkt, ReactOS sei niemanden bekannt und ist ein Insider Projekt, der liegt eindeutig falsch.
Nicht nur die größtenteils
englischsprachige offizielle Community Seite mit dem offiziellen Forum, represetiert das ReactOS Projekt.

Auch sehr bekannt Seiten wie:

• PC-Welt - Windows-Klon in neuer Version erschienen
• heise -ReactOS 0.3.10 mit OpenGL-Unterstützung
• Chip Online - reactos: Neue Version des opensource Windows
• WinFuture - ReactOS 0.3.10 - Kostenloser Windows-Ersatz?
• tecChannel -ReactOS 0.3.10 soll besser auf echter Hardware lauf
• Pro-Linux - ReactOS 0.3.10
• OS News - ReactOS 0.3.10 Released oder
• Gulli -ReactOS Windows-Klon erfuhr Update

haben wie es scheint, eine kleine Schwäche für das Opensource Windows endeckt.


Mittlerweile gibt es auch schon einen Hauseingenen Youtubechannel, der Videos wie z.B. den ReactOS 0.3.10 Preview beinhaltet.
Wer nach dem Stichwort "reactos" bei Youtube sucht, wird sicher schnell feststellen, das man dort auch jede menge Videos von anderen Usern des ReactOS Projektes finden kann.
Dazu zählen unter anderen Videos wie: ReactOS @ FOSDEM '09 - Part 1 of 2, ReactOS boot with UniATA (Real Hardware - 41179) oder andere Fanprojekte wie Mac vs. PC vs. ReactOS - South Park Style und ReactOS Commercial - free Windows alternative.
Schaut einfach mal vorbei, guckt euch neue und ältere Videos an oder erstellt selber das eine oder andere Video und ladet es bei Youtube hoch.

Helft mit, werbt in Foren, stellt eure Videos online oder erzählt euren Bekannten und Freunden von diesem großartigen Projekt.
ReactOS ist groß im kommen!

ReactOS 0.3.10 veröffentlicht!

Gestern hat das ReactOS-Team die Version 0.3.10 des gleichnamigen freien OpenSource Windowsähnlichen Betriebssystems "ReactOS" veröffentlicht.

Hier die offizielle Newsmeldung von dem Entwicklerteam: http://www.reactos.org/de/news_page_53.html

Seit 0.3.9 wurde sehr viel am System-Kernel sowie auch am HardwareSupport verändert. (siehe Newsbericht und Changelog) Außerdem hat ReactOS nun guten OpenGL-Support (Software- und Hardware-seitig), so dass einige Spiele und auch Google Earth ( http://react-blog.blogspot.com/2009/06/google-earth-und-qip.html ) in reactos nun gut spielbar sind.

Die InstallationsCD kann unter http://downloads.sourceforge.net/reactos/ReactOS-0.3.10-REL-iso.zip und die LiveCD kann unter http://downloads.sourceforge.net/reactos/ReactOS-0.3.10-REL-live.zip gedownloadet werden.

Releaseschwierigkeiten

Gestern den 03.07.2009 um 12:42Uhr konnte man im ReactOS CIA

ReactOS 0.3.10 is ready!

nachlesen. Doch leider folgte dieser Nachricht eine sehr unerfreuliche von ReactOS auf Twitter.
Dort wurde beschrieben, das es Probleme gibt, die Finale 0.3.10 Version von ReactOs auf Sourceforge hochzuladen.
Auch heute gab es einen Eintrag auf Twitter, der besagt, das es weiterhin Probleme mit dem Upload gibt.

Hoffen wir, das Sourcforge die Probleme so schnell wie möglich in den Griff bekommt.

Autor: rexty