May 2006 - Wine-Devel - list.winehq.org

Re: Re: Wine 1.0 Tasks

by Scott Ritchie

On Tue, 2006-05-30 at 07:19 -0700, Dan Kegel wrote: > On 5/30/06, fenix(a)club-internet.fr <fenix(a)club-internet.fr> wrote: > > >The OpenGL child window bug, > > >http://bugs.winehq.org/show_bug.cgi?id=2398 > > >probably won't be fixed for 1.0 because it requires > > >an X server change. > > > > No it must be doable without X changes > > It might be, but the heavy hitters I know of who have taken a look at > it in detail have concluded that an X change really is needed.] Is this really a problem? Another version of X is due out in about 4 months (probably the earliest we could possibly see Wine 1.0), so why can't we just help write an X extension to tackle the bug? Thanks, Scott Ritchie

May 31, 2006

Re: Wine 1.0 Tasks

by Alex Villacís Lasso

Dan Kegel wrote: > What other bugs should be fixed before 1.0? Let's nominate > a few bugs to add to the 1.0 task list, discuss them a bit, and see > what Alexandre thinks. > > For instance: > I'd like one goal of 1.0 to be "make Windows developers take Wine > seriously." > To achieve that, I think 1.0 has to support at least some Microsoft > development > tools well, including their IDEs and debuggers. It's probably > unreasonable to > require 1.0 to support .NET, so maybe supporting the last pre-.NET > versions of > Visual C++ (6.2?) and Visual Basic (6.0?) would be a good goal. And I > don't > think it's that unreasonable anymore; Wine is pretty close to being > able to do > that. What do y'all think? > - Dan > People who manage to compile VB apps under Wine with VB6 are likely to stumble upon this bug (at least under GNOME/Metacity): Bug 1598 - delphi 3 - managed - missing minimize/maximize buttons http://bugs.winehq.org/show_bug.cgi?id=1598 In addition, if anyone tries to use DBGRID32.OCX, they will surely hit this bug: Bug 3846 - Wine can't run Roderick Colenbrander's DBGRID32.OCX VB test apps yet http://bugs.winehq.org/show_bug.cgi?id=3846 Alex Villacís Lasso

May 30, 2006

Re: How are we doing?

by James Hawkins

On 5/29/06, Mike Hearn <mike(a)plan99.net> wrote: > > * Is Wine improving or is the regression rate matching the improvement > rate? > It's hard for me to answer this question, because I don't regularly run many apps with Wine, but it seems like we've had reports of a lot of regressions lately. A bigger issue is how we should deal with regressions. Most of the bug reports we get are of the type, "This app used to work, now it doesn't..." and we have to ask the reporter to run a regression test. I know these tests are crucial, but they take a long time and many users don't bother going through that process. Even more integration with the AppDB might help with this process. Ideally we would like to inform the user of a "Last known working release", which would be the Wine release that worked with this app. Looking at a sample AppDB entry, I guess this would be the Testing Results->Wine Version->Runs? field. If the 'regression' keyword is provided for a bug, and the bug is linked with an app in the AppDB, we could provide the "Last known working release" info to the tester, so they know where to start testing. > > * Are we turning away potential developers for any reason? Could we do > more to attract new hackers? > It seems a lot of developers are frustrated by our development model (one pathway to commit) and by the amount of effort it takes to get a patch committed. I say too bad for them. We have a great devel model that substantially reduces the amount of bugs and bad code getting into CVS. > * Any other thoughts for improvement? > One of my biggest concerns about the wine development process is lack of direction. A lot of the experienced devels know what they plan to do on an individual level, but it's hard for people new to wine to grasp the whole picture of what needs to be worked on. We have TODO lists, 1.0 goals, and janitorial tasks etc., but sometimes those items lack meaning, even to me. I really enjoy reading KDE's feature plan page [1]. They list in detail what exactly needs to be implemented/fixed. One could say that we have a different development model, in that our goal is to get application x, y, and z to work, but that model is inefficient, and we usually don't work that way anyway. There are features that are missing, important bugs that need to be fixed, and it would be great if we could all take the time to list somewhere, probably on a wiki page, the most important things that need to be implemented/fixed. On a larger scale than individual bugs and features, we could also list dlls that need more attention than others, e.g., ole32.dll is more critical than cards.dll. As Dmitry pointed out, test cases are very important to the devel process, and typically they aren't very difficult to write. Maybe we could have a list of areas that need more testing. Looking at wiki.winehq.org, I don't see anything that shouts out, "Hey! New to Wine development? Check this page out." I'd like to see a one-stop shop that eases a new developer into the process. We could point them to the devel documentation, provide some beginner tips, and show some areas of Wine that they can work on to dip their toes in the water (Janitorial, tests, etc). I'm sure there are lots of new developers that decide they want to work on Wine, stop by, and leave because they have no idea where to start. Granted they should put more effort into it, but it wouldn't hurt to cater to these new developers. We can always use more devels, right? [1] http://developer.kde.org/development-versions/kde-4.0-features.html -- James Hawkins

May 30, 2006

Re: Mac OS X Audio driver

by Robert Reif

Emmanuel Maillard wrote: > Hi, > > This patch is the initial Audio Driver for Mac OS X, quiet big > (contain all winecoreaudio dir) tell me if you want i split this in > separated patches. > > Thanks > > Emmanuel > > Authors: > Ken Thomases <ken at codeweavers dot com> > Emmanuel Maillard <mahanuu at opendarwin dot org> > > Changelog: > Initial Audio Driver for Mac OS X. > Could you add this to winecfg? Should be a one line patch.

May 30, 2006

Re: Wine 1.0 Tasks

by Raphael

On Tuesday 30 May 2006 16:19, Dan Kegel wrote: > On 5/30/06, fenix(a)club-internet.fr <fenix(a)club-internet.fr> wrote: > > >The OpenGL child window bug, > > >http://bugs.winehq.org/show_bug.cgi?id=2398 > > >probably won't be fixed for 1.0 because it requires > > >an X server change. > > > > No it must be doable without X changes > > It might be, but the heavy hitters I know of who have taken a look at > it in detail have concluded that an X change really is needed. > > > (But X additions as GLX_EXT_texture_from_pixmap will help a lot). > > Only problem is to find time to fix it (as lionel, i have no time for > > now). Anyway i having a simple and downloadable application to reproduce > > this problem (not lightwave) must help. > > There are already simple test apps linked to from > http://wiki.winehq.org/OpenGL > > > The only parts who really needs X change are for: > > - glShareList: sharing fb/visual config between exitings GLX contexts > > - dinput mouse management > > Are those 1.0 blockers? For the first no For the second need users request (but it only impact games) > - Dan Regards, Raphael

May 30, 2006

Re: World of Warcraft (WoW) patch/more address space layout stuff

by Raphael

On Tuesday 30 May 2006 16:37, Mike Hearn wrote: > > Interesting.. if MacOSX has a similar memory layout as linux, maybe we > > could get Blizzard to include a workaround that is only active when it > > sees that it's running under wine/cedega. > > Well if you can get the email address of a WoW developer then maybe we > can track down where the problem in WoW is and work with them to fix > it. I don't think Wine-specific workarounds make any sense: the > address space layout when not requesting a specific address is not > guaranteed. Vista already includes ASLR which is likely to break such > software. It will need to be fixed sooner or later, might as well be > sooner :) Yes ia agree, maybe asking them to try it on vista may help :) Regards, Raphael

May 30, 2006

Re: Wine 1.0 Tasks

by Raphael

On Tuesday 30 May 2006 16:27, Huw Davies wrote: > On Tue, May 30, 2006 at 04:11:41PM +0200, fenix(a)club-internet.fr wrote: > > >The OpenGL child window bug, > > >http://bugs.winehq.org/show_bug.cgi?id=2398 > > >probably won't be fixed for 1.0 because it requires > > >an X server change. > > > > No it must be doable without X changes > > (But X additions as GLX_EXT_texture_from_pixmap will help a lot). > > How does this help? http://people.freedesktop.org/~davidr/GLX_EXT_texture_from_pixmap.txt they are better than FBO for this specific need. Anyway for using it, we need a lot of modifications on x11drv (in the fameous window management code) acting as a composing manager. Note: it will help a lot to provide a DIB engine not dependant to X limitations > Thanks, > Huw. Regards, Raphael

May 30, 2006

Re: Wine 1.0 Tasks

by Dan Kegel

On 5/30/06, Brian Vincent <brian.vincent(a)gmail.com> wrote: > On 5/30/06, Dan Kegel <dank(a)kegel.com> wrote: > > I guess there are two main use cases: > > 1) developer wants to debug an app that misbehaves on Linux/Wine but > > not on Windows > > 2) manager or clueless pundit who are into VB or VC++ wants to say > > Wine is useless, > > and by supporting Visual Studio we convince them otherwise > > 3) Source code management lives in Visual Source Safe and VS .NET or > MSVC++ 6.0 is needed to access it. Oh, good point. Yes, we should include Visual Sourcesafe integration support in our Visual Studio testing. (I used VSS for years with Wine; see http://kegel.com/wine/vss-howto.html, but I seldom used the GUI and never used Visual Studio.) - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

May 30, 2006

Re: Wine 1.0 Tasks

by Dan Kegel

Mike Hearn wrote: >What's the use case for running VS on Linux; is the idea that as >developers migrate they can continue working on their old software? Or >that they can use these tools to write new software that targets Win32? I guess there are two main use cases: 1) developer wants to debug an app that misbehaves on Linux/Wine but not on Windows 2) manager or clueless pundit who are into VB or VC++ wants to say Wine is useless, and by supporting Visual Studio we convince them otherwise

May 30, 2006

Re: wine.inf: Add user "Shell Folders\Font" entry.

by Alexandre Julliard

Vitaliy Margolen <wine-patch(a)kievinfo.com> writes: > ChangeLog: > wine.inf: Add user "Shell Folders\Font" entry. This should go with the other shell folder registration stuff in shell32. -- Alexandre Julliard julliard(a)winehq.org

May 30, 2006