20 Jul
2009
20 Jul
'09
10:16 a.m.
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.
