RFC: Presentation for Desktop Architecture meeting
I'm preparing for the Desktop Architecture meeting; each project is being asked to prepare a presentation using a standard format. I've filled in their template and was hoping to ask for feedback. The Open Office file is available for download here: http://dl.codeweavers.com access key 'deskarch' It's about 327K; I'm also including, in line, the outline, which is about 1.5K <grin>. I'd appreciate thoughts/suggestions/comments. I gather the main purpose of the meeting is to try to increase cooperation between projects. Cheers, Jeremy ----- Wine Project Overview Purpose: Implement Windows API for Unix Wine loader – run Windows Applications Winelib – port Windows applications Deliverables (the dream) All PE format files (.exe + .dll) 'just work' with binary loader. C/C++ code recompiles and 'just works' with Winelib Affiliations CodeWeavers ReactOS project Wine Project History Founded 1993 Single Maintainer 797 Contributors over Lifetime, ~40 active Alpha Software, limited functionality, through 2005 First Beta (0.9) released October 2005 Many things work Server interface stable Some ABI stability Associations With Other Desktop Organizations Wine is a power user of the kernel, glibc, and x.org Have very specific needs around memory, threading, and display control We break X more than any other app I know We get no respect exec shield, glibc threading changes, feels like a constant arms race; be nice if we could be more involved, given time to respond Also touch: OpenGL, ALSA/Jack/ESD/Arts/OSS Hurray for Freedesktop.org Menu Specifications Xembed Protocol Gap Analysis In Current Implementations Missing capabilities Many things don't work == a whole lotta bugs Developing capabilities Most core pieces are there, most things 'should' work DirectX coming along nicely Sound still needs work Many things at 90%+, but still need work Top priority development items in plan “We have not yet begun to optimize” Regression testing Driving to 1.0 Major Plans 6 month plan Refine beta releases of 0.9, drive towards 1.0 2 year plan World Domination?
On Sun, 2005-11-13 at 22:55 -0600, Jeremy White wrote:
The Open Office file is available for download here: http://dl.codeweavers.com access key 'deskarch'
Yeah, not there :(
Wine Project History Founded 1993 Single Maintainer 797 Contributors over Lifetime, ~40 active Alpha Software, limited functionality, through 2005 First Beta (0.9) released October 2005 Many things work Server interface stable Some ABI stability
I'd say we have the best ABI stability, since we follow MS, and they typically don't break it. It's a lot more likely we'll break the server interface, there's no real reason not to, all calls to the server should be generated through the base DLLs, and _that_ interface is stable :)
Associations With Other Desktop Organizations Wine is a power user of the kernel, glibc, and x.org Have very specific needs around memory, threading, and display control We break X more than any other app I know We get no respect exec shield, glibc threading changes, feels like a constant arms race; be nice if we could be more involved, given time to respond Also touch: OpenGL, ALSA/Jack/ESD/Arts/OSS Hurray for Freedesktop.org Menu Specifications Xembed Protocol
I guess we need to spell out what we need from other projects to better integrate Win32 apps with the rest of Linux. These things take time, and we need to bring them on their radar. Also, if OSDL is willing to put some of their uber-kernel hackers on Desktop Linux, would be nice if we could come up with a spec on what needs to be done on the kernel side to speed up Wine. I know, this has been hashed out to death before, but I guess it would be interesting to probe and find out their willingness to help us out on the kernel side of things. Not to mention X, and OpenGL. What else? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.
The Open Office file is available for download here: http://dl.codeweavers.com access key 'deskarch'
Yeah, not there :(
Sorry; uploaded to the wrong directory. Fixed now.
I'd say we have the best ABI stability, since we follow MS, and they typically don't break it. It's a lot more likely we'll break the server interface, there's no real reason not to, all calls to the server should be generated through the base DLLs, and _that_ interface is stable :)
Well, to me, ABI stability is whether or not a comctl32.dll.so from Wine 0.9.1 can be dropped in and 'just work' in a Wine 0.9.8 environment. More to the point, it's whether or not my winelib 'foo.dll.so' can be so dropped in. And my gut sense was that we were pretty close to that, but not certain. Am I wrong?
I guess we need to spell out what we need from other projects to better integrate Win32 apps with the rest of Linux. These things take time, and we need to bring them on their radar.
Any first cut items? I'm sure the x.org guys will be there in force, and I've always had the sense that they'd be happy to help us, if we just asked.
Also, if OSDL is willing to put some of their uber-kernel hackers on Desktop Linux, would be nice if we could come up with a spec on what needs to be done on the kernel side to speed up Wine. I know, this has been hashed out to death before, but I guess it would be interesting to probe and find out their willingness to help us out on the kernel side of things.
Yah.
Not to mention X, and OpenGL. What else?
Could someone (Lionel?) remind me of the bug # that contains the OpenGL request we have? So far, that's the one concrete request we seem to have, and I don't want to misrepresent it. Thanks for the feedback; much appreciated. Cheers, Jeremy
"Jeremy White" <jwhite(a)codeweavers.com> wrote:
Any first cut items? I'm sure the x.org guys will be there in force, and I've always had the sense that they'd be happy to help us, if we just asked.
How about inability of X server to handle pixmaps larger than 32767 x 32767 and an ugly workaround introduced by the following patch: ftp://ftp.x.org/pub/X11R6.8.2/patches/xorg-CAN-2005-2495.patch This has been discussed under the "Re: Regression: Winrar fails to start" topic. -- Dmitry.
From: "Jeremy White" <jwhite(a)codeweavers.com>
Well, to me, ABI stability is whether or not a comctl32.dll.so from Wine 0.9.1 can be dropped in and 'just work' in a Wine 0.9.8 environment. More to the point, it's whether or not my winelib 'foo.dll.so' can be so dropped in. And my gut sense was that we were pretty close to that, but not certain. Am I wrong?
No, we had slightly different definitions for ABI :) But yeah, the .dll.so format is a custom Wine setup, and only Alexandre knows how stable that is. But the rest is basically defined by MS, and so it's set in stone. However, note that this is not a big problem -- you can simply ship PE .dll if you are concerned about stability <g>. I agree that would be nice if we can say that the .dll.so format is stable. With the winecrt0 and debug channel work that Alexander did lately I think we are close. But if we are there yet, only he knows. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.
"Dimi Paun" <dimi(a)lattica.com> writes:
I agree that would be nice if we can say that the .dll.so format is stable. With the winecrt0 and debug channel work that Alexander did lately I think we are close. But if we are there yet, only he knows.
I don't have any plans to change the format, but there is a slight chance that the upcoming copy protection work will require changes, so I'd say backwards compatibility is only 99% guaranteed at this point. The plan is to guarantee it 100% once 1.0 is out. -- Alexandre Julliard julliard(a)winehq.org
Wrt X.Org stuff, relative mouse movement reporting would probably be usefull to have, as described here: http://wiki.winehq.org/DInput Perhaps there's room for that in the upcoming XInput redesign (http://wiki.x.org/wiki/XInputHotplug) ?
Jeremy White wrote:
Wine Project Overview Purpose: Implement Windows API for Unix Wine loader – run Windows Applications Winelib – port Windows applications Deliverables (the dream) All PE format files (.exe + .dll) 'just work' with binary loader. C/C++ code recompiles and 'just works' with Winelib Affiliations CodeWeavers ReactOS project
Wine Project History Founded 1993 Single Maintainer 797 Contributors over Lifetime, ~40 active Alpha Software, limited functionality, through 2005 First Beta (0.9) released October 2005 Many things work Server interface stable
This isn't a current goal. I believe Alexandre has said that the server interface can and will change. This shouldn't affect users at all, since we don't support upgrading components of Wine independently.
Some ABI stability
Associations With Other Desktop Organizations Wine is a power user of the kernel, glibc, and x.org Have very specific needs around memory, threading, and display control We break X more than any other app I know We get no respect exec shield, glibc threading changes, feels like a constant arms race; be nice if we could be more involved, given time to respond Also touch: OpenGL, ALSA/Jack/ESD/Arts/OSS Hurray for Freedesktop.org Menu Specifications Xembed Protocol
Gap Analysis In Current Implementations Missing capabilities Many things don't work == a whole lotta bugs Developing capabilities Most core pieces are there, most things 'should' work DirectX coming along nicely Sound still needs work Many things at 90%+, but still need work Top priority development items in plan “We have not yet begun to optimize” Regression testing Driving to 1.0
Major Plans 6 month plan Refine beta releases of 0.9, drive towards 1.0 2 year plan World Domination?
-- Rob Shearman
OK, here is my wish list from the X.org guys: - relative mouse movement reporting. This is a must-have to have proper DInput support without the hacks we currently have in the code. Extension already discussed with X people on the mailing lists and they seem OK with it. Now we just need to find someone who codes it :-) As said, need to check if the XInput stuff could be re-used (last time I checked no as you cannot take control with XInput of the 'core' device - i.e. the mouse). - full support for resolution / depth switching. A nice idea was discussed the other day on the fd.o lists: what about being able to easily start a new display using an X API which would start a new X screen. This screen could then be used for full-screen games and would support any requested depth / resolution change (the problem with the former - depth change - is that clients need to support it and so the 'new screen' idea would solve this problem as one could still have legacy X applications running on the 'main screen' while still have complete control of depth / resolution on this secondary screen). Then some 'nice to have' which would help in the GL / D3D front but may be out of FD.O scope (and for which work-arounds are known): - GL (GLX ?) extension which would remove the 'thread-affinity' from GL. I.e. a GL context would be at the process level and not at an application level. An even better solution would to be able to create 'shareable' contexts which another thread could attach to (i.e. remove the one thread <=> one context rule). - GLX extension that would export the 'clip-list' functionnalities of cards (or at lest the one which is in the X code itself). Would help on applications (like Wine) that do their own in-window clipping. - same point as before but for Xv the day we will re-add this code for accelerated YUV display. Some 'misc' stuff that is really in the 'we could use it' category: - have 'connection-level' configuration. Basically, if a client X change an X setting (resolution, mouse acceleration, ...), as soon as this client exits, restore the previous configuration. Would be useful to prevent having people restarting X because Wine crashed after having changed the resolution using XRand. - have a non-connection limited mouse-grab. To explain better, this would enable one to grab the pointer into a window (i.e. the mouse would never leave this window) while still sending events to all connections and not only to the connection which started the grab. This could be nice to simulate 'full-screen desktop mode' or for DXGrab. No idea if with Wine's current event model this is still usefull though. Another 'let's dream' possibilities: - direct frame buffer access :-) And finally, not in my domain, but investigate re-using something from FD.O for the fabled DIB engine (extensions to Cairo, ...) ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Lionel Ulmer wrote:
OK, here is my wish list from the X.org guys:
I have updated my presentation to add some of these items to a separate slide, and added Dmitry's comment about the > 32767 bug. (Lionel, let me know if the meat of your presentation was powerpointed to death or not). Most other comments didn't prompt me to make a change, or were more related to presentation strategy. I tried to add such comments as notes to the presentation, but not to the slides. Candidly, I think we may not get a particularly long time window - there are a *lot* of competing interests coming to this meeting, so I suspect no one .org is going to get much attention. This makes the presentation a bit more relevant, as it may be that folks are expected to review this brief prior to the meeting, in lieu of a more formal project introduction. An updated version is here: http://dl.codeweavers.com access key of deskarch Further comments are much appreciated; I'm going to relay this to the working group shortly. Cheers, Jeremy
participants (7)
-
Alexandre Julliard -
Dimi Paun -
Dmitry Timoshkov -
H. Verbeet -
Jeremy White -
Lionel Ulmer -
Robert Shearman