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

Re: Wine 1.0 Tasks

by Dan Kegel

On 5/29/06, Dan Kegel <dank(a)kegel.com> wrote: > If you look at http://bugs.winehq.org/ you'll see a link on the left hand side > called "1.0 Tasks", which lists the 1.0 bugs being tracked in bugzilla. > ... I like the idea of using bugzilla to track our progress to 1.0. > > Hmm, maybe. Bugzilla lists have a tendency to come and go though as people > nominate their bugs (Hmm, isn't target a privileged field? It probably should be if it isn't.) > and as they are fixed. That's a GOOD thing :-) > I think it's not quite as satisfying as a mostly static list. Let's use it for a while, then take a snapshot and use it for our static list, maybe. > IMHO we should really nail the window management problems. The WM rewrite > was supposed to fix our woes with unmanaged windows and fullscreening for > ever but it hasn't happened yet. Go ahead and retarget those to 1.0, then, please. >> It's probably unreasonable to require 1.0 to support .NET > >Is it? We already run Java just fine and I am sure Mike M had command line >.NET apps running a year or two ago. It might be plausible. I agree that Sun's Java runtime is probably something we should support for 1.0. But Java isn't "just fine" under Wine; I've run into installers that fail because they crash inside Sun's JVM on Wine. To say we really support Java, though, probably means figuring out how to run the Mauve regression tests under wine. If someone wants to do that, please do! If someone wants to start putting effort into getting .NET, or for that matter Mono, up and running, great. But personally, I'd be just fine with making .NET support a 1.1 feature. - Dan

May 30, 2006

Re: Re: Wine 1.0 Tasks

by fenix＠club-internet.fr

Hi, >> (Note the #3902 should be renamed as 'DIB Engine rewrite' > >Agreed; done. http://bugs.winehq.org/show_bug.cgi?id=3902 :) >> and i don't think is mandatory for 1.0) > >Probably right. Let's create the next milestone after 1.0, say 1.1, and start >retargeting bugs we don't plan to fix for 1.0. (That's what GCC does; >some bugs they retarget early, some just before the release.) > >> But i think we must fix users most hated bugs as: >> - dsound deadlocks/craps >> - openGL problems (multi contexts, fb/visual configs) >> - lotus problems > >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). 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. The only parts who really needs X change are for: - glShareList: sharing fb/visual config between exitings GLX contexts - dinput mouse management >I'm not sure lotus notes problems should block 1.0, as IBM has a native >Linux client now, but if someone wants to fix them (especially the ones >in usp10.dll netapi32.dll, that would be great. agree :) >> Note: it will be interesting to add user votes to wine-bugs (ala kde) to >> better see user needs. > >There are already user votes in bugzilla, that should suffice. >- Dan Oups i never seen it :) Regards, Raphael

May 30, 2006

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

by Tomas Carnecky

Mike Hearn wrote: > It's a bug in WoW itself, it relies upon the exact way NT maps memory > which is different to how Linux does it. I guess they are storing > information in the high bits of a pointer somewhere or some similar > trick. > Since WoW also runs on MacOSX, how does the memory layout on MacOSX differ from NT and Linux? Maybe that's the reason why they won't do a Linux port: because they rely on a certain memory layout and the code can't be changed that easily. tom

May 30, 2006

Text input box with scrollbar

by Augusto Arcoverde da Rocha

Hi all, Where I can find the inputbox drawing code? Some of these box appear with scrollbar when testing Action Request System application under Wine, but not under MS Windows. Thanks, Augusto Arcoverde da Rocha

May 30, 2006

Re: How are we doing?

by Mike Hearn

Got a reply from somebody who would rather remain anonymous: --------------------------------------------------------------------- This may be just me, but the learning curve is probably much more steep for a "general purpose" hacker than for a particular dll. I have some apps I'd like to get working, but I find that the underlying problems tend to take a long time to find, and when I do find them they tend to fall into one of these categories: -relatively simple to hack around, but difficult to really fix -involves implementing or fixing something that's way beyond my skills -it's unclear how to properly fix the problem None of those result in a patch. Usually they only will only result in a bug report or (if it's something the developers are aware of) nothing at all. On the other hand, I'm not really interested in working on a particular dll; I just want my apps to run correctly on wine with as little kludging around things as possible. --------------------------------------------------------------------- ... which is certainly true, it has a steep learning curve. But I think we need more people doing such things :/ thanks -mike

May 30, 2006

Re: Wine 1.0 Tasks

by Dan Kegel

On 5/30/06, Raphael <fenix(a)club-internet.fr> wrote: > (Note the #3902 should be renamed as 'DIB Engine rewrite' Agreed; done. http://bugs.winehq.org/show_bug.cgi?id=3902 > and i don't think is mandatory for 1.0) Probably right. Let's create the next milestone after 1.0, say 1.1, and start retargeting bugs we don't plan to fix for 1.0. (That's what GCC does; some bugs they retarget early, some just before the release.) > But i think we must fix users most hated bugs as: > - dsound deadlocks/craps > - openGL problems (multi contexts, fb/visual configs) > - lotus problems 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. I'm not sure lotus notes problems should block 1.0, as IBM has a native Linux client now, but if someone wants to fix them (especially the ones in usp10.dll netapi32.dll, that would be great. > Note: it will be interesting to add user votes to wine-bugs (ala kde) to > better see user needs. There are already user votes in bugzilla, that should suffice. - Dan

May 30, 2006

Re: Wine 1.0 Tasks

by Mike Hearn

On Mon, 29 May 2006 21:01:46 -0700, Dan Kegel wrote: > I suspect a few of these are stale, and a bunch others are missing, > but I like the idea of using bugzilla to track our progress to 1.0. Hmm, maybe. Bugzilla lists have a tendency to come and go though as people nominate their bugs and as they are fixed. I think it's not quite as satisfying as a mostly static list. I appreciate it's easier to set up though :) > What other bugs should be fixed before 1.0? IMHO we should really nail the window management problems. The WM rewrite was supposed to fix our woes with unmanaged windows and fullscreening for ever but it hasn't happened yet. > It's probably unreasonable to require 1.0 to support .NET Is it? We already run Java just fine and I am sure Mike M had command line .NET apps running a year or two ago. It might be plausible. thanks -mike

May 30, 2006

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

by Mike Hearn

On 5/30/06, n0dalus <n0dalus(a)gmail.com> wrote: > It would be really great if someone could document the patch and > explain what exactly is stopping WoW from working (as well as which > changes would cause problems for other programs). It's a bug in WoW itself, it relies upon the exact way NT maps memory which is different to how Linux does it. I guess they are storing information in the high bits of a pointer somewhere or some similar trick. The patch is a hack that makes Wine follow the Windows method - unfortunately it will happily force an allocation to an area that is already allocated. Right now it relies on pure luck to avoid blasting a previous allocation. Expect random undebuggable failures with this technique. > I think there would be more chance of getting developers working on the problem if the > problems involved were clearer and easier to see/understand. The real issue is that it seems not many Wine developers play WoW themselves ;) > Given the amount of users who use wine to run WoW, would it be > possible to have the patch included with a compile-time option? Would > it even be possible to make the patch a runtime feature? Doubtful. You'd have to ask Alexandre. He may know of a different solution also. Wine has a policy of not accepting application specific hacks though there are a few generic hacks in there. You'd be better off IMHO by preparing your own Wine binary install that is specific to WoW itself. thanks -mike

May 30, 2006

Re: wineconsole: Improve 64bit compatibility.

by Alexandre Julliard

Mike McCormack <mike(a)codeweavers.com> writes: > @@ -153,7 +153,7 @@ static LRESULT WINAPI WCUSER_FontPreview > SetWindowLong(hWnd, 0, 0); > break; > case WM_GETFONT: > - return GetWindowLong(hWnd, 0); > + return GetWindowLongPtr(hWnd, 0); > case WM_SETFONT: > SetWindowLong(hWnd, 0, wParam); > if (LOWORD(lParam)) You should fix all the Get/SetWindowLong calls that set the same value, changing only half will make things worse. You also have to reserve the proper size in the window class. -- Alexandre Julliard julliard(a)winehq.org

May 30, 2006

Re: wined3d: GLSL shader status

by Raphael

On Tuesday 30 May 2006 08:53, Jason Green wrote: > I'm working on the conversion from DirectX pixel and vertex shaders to > GLSL function and have made a good bit of progress this weekend. At > the moment, I'm able to run just about every simple vertex shader > (version <= 1.4, and a few 2.0's) that I can find which already works > on ARB_vertex_program (the current way that Wine handles this). I'm > having a bit more trouble with pixel shaders, but I haven't really dug > into it yet. Some of the really simple ones work, but I believe I'm > missing a step in the texture binding code somewhere. > > I've posted a patch to enable this shader generation here: > > http://cmhousing.net/wine/glsl_hack4.diff > > If you want to try this and help debug things, you'll have to apply > the patch (it's against the current git tree as of 2:00 AM EST, May > 30th). Plus, you'll need a video card and driver capable of using > GLSL (type 'glxinfo' and look for "GL_ARB_shading_language_100") . > You'll also have to set a new registry key in your Wine installation > (it is case sensitve): > > HKEY_CURRENT_USER\Software\Wine\Direct3D\UseGLSL = "enabled" > > Here are a few comparison screenshots (note, yes, they should be identical > ;-): > > http://www.cmhousing.net/wine/aniso_arb.png (vanilla wine, or with > UseGLSL != "enabled") > http://www.cmhousing.net/wine/aniso_glsl.png (using GLSL) > > http://www.cmhousing.net/wine/grass_arb.png > http://www.cmhousing.net/wine/grass_glsl.png > > http://www.cmhousing.net/wine/dolphin2_glsl.png (DX8 SDK dolphin sample) > > http://www.cmhousing.net/wine/civ4_glsl.png (not *quite* there yet ;-) > > In theory, once this all works, we'll be able to support shader model > 2.0+, which a lot of newer games either require or strongly suggest > (aka prettier graphics). Now, there are plenty of other bugs to be > worked out in wined3d, so this isn't the holy grail of patches or > anything, but it will take us that much closer to supporting new > games. Please lend a hand if you're able to. Thanks! > > (by the way, many thanks to the entire #winehackers crew for all the > help along the way so far, it's been fun) Impressive :) I'll try to test it today (if i found time) Keek the good job Regards, Raphael

May 30, 2006