"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
