"support of remote sessions via X Windows" what the.... Does it mean some GUI Linux apps would be able to run into ROS with that new Win32 subsystem??
On Mon, Jul 20, 2009 at 12:16 PM, Aleksey Bragin <alek...@reactos.org>wrote: > 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. > _______________________________________________ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev