December 2005 - Wine-Devel - list.winehq.org

Re: [lostwages] Remove winetools from download page

by Tom Wickline

On 12/21/05, James Hawkins <truiken(a)gmail.com> wrote: winetools will > eventually no longer be needed (which is a good thing!), and this is > one of the first steps towards that process and wine 1.0. So you agree that is currently needed, I believe it should stay until 1.0 Tom > > -- > James Hawkins >

Dec. 22, 2005

Re: Bug 3885

by Aric Cyr

Tom Spear <speeddymon <at> gmail.com> writes: > > Aric Cyr wrote: > >>>I took a look at the D3D_OK hack, and I believe the problem to be > >>>CheckDeviceFormat in wined3d/directx.c. This function should return an > >>>error if > >>>D3DFMT_D32 is checked for on cards which don't support 32bit depth. > >>>Currently > >>>it just returns OK for most formats though. This code is really just a > >>>stub as > >>>it stands, and needs to be converted to check if there are any visuals that > >>>meet > >>>the requested format's requirements, and if there is, return D3D_OK, > >>>otherwise > >>>D3D_NOTAVAILBLE. > >>> > >>>To test my theory, try returning D3D_NOTAVAILABLE for the D3DFMT_D32 case > >>>(you'll need to add it) in wined3d/directx.c in > >>>IWineD3DImpl_CheckDeviceFormat() > >>>and see if that fixes that issue or not. This would be just another hack > >>>though, so a real patch would still be necessary as I decribed above. > > Well I took a stab at adding the case for D3DFMT_D32, to the bottom of > the other cases, and let it return the D3DERR_NOTAVAILABLE (as opposed > to D3D_NOTAVAILABLE), and ran the benchmarks again.. Now it finishes > the first one and then goes to do the second one, but crashes in a > different spot, so it seems we also have some stack corrupion (as was > mentioned in the bug).. So that hack works for now, I would suggest > that since the rest of that code is stubbed out, we should probably go > ahead and submit a patch so we can at least run the darn thing and then > start debugging the stack corruption issue. Thanks for testing this out. You have proved my theory correct, so I'll see about making a patch which will correct CheckDeviceFormat(). Basically that whole function needs a re-write, so I'd rather do it that way than to put this hack in there. Especially since, I assume, this problem is not present on nVidia systems, only ATI. > I should add that on the first run, I disabled the title screens between > benchmarks, and changed the "Display and CPU Settings" so that I was > using 32-bit textures and triple buffering, and it ran thru several of > the tests, while on the 2nd and 3rd runs, I left all settings at > defaults; during run 2, it died just after the title screen for mark #2, > and during run 3, it died in the middle of mark #2... If I'm not mistaken, doesn't 3DMark change resolutions between benchmark and title screens? If so, it is possible, and quite likely that there is a resolution change bug in wine. If I recall, I had similar crashing problems with World of Warcraft if I tried to change resolutions from in-game. Regards, Aric

Dec. 22, 2005

Re: [lostwages] Remove winetools from download page

by James Hawkins

On 12/21/05, Tom Wickline <twickline(a)gmail.com> wrote: > > Shouldn't Wine be fixed before it's removed? Isn't it kind of backwards to say > we need to have Wine run everything out of the box and to accomplish this were > going to remove a link to a user friendly tool that currently helps our users. > If users continue to use winetools, wine won't get the needed testing coverage that will really help boost the development process. Many bugs will go unnoticed, new features won't be tested, and we won't get the feedback to make wine better. That's the beauty of open source; users are encouraged to tell us every bug or missing feature, and we will do our best to address the issues. The more eyes on wine, the better. > Then what? your going to have just as many, if not even more people on > IRC asking for > help who other wise wouldn't have had to do so. > I would love to see that day. I have no problem with people asking for help with wine on wine-users or IRC. The problem is when people report problems that are winetool specific, as Vitaliy initially stated. That's one of the reasons why I advocate a winetools specific mailing list, so people using winetools can reach the people that work on winetools. > > Wine is easy for me, and I'm sure for yourself to use and configure > but this is just not the case for a large number of people! > Usability is another rapidly progressing area of wine. You are exactly right in that it is easy for us to use, so we can't see through the eyes of a new wine user. We need more people to try wine out and tell us exactly what are is too difficult or not intuitive to use. That way we can fix it and make it easier for potentially many more users. If that user had used winetools, we would never get the report, and the issue would still remain. > > Removing WineTools is the worst thing this project could do at this time, as > its the *only* free GUI that makes a genuine attempt to help first > time users. On the contrary, winecfg is a great tool aimed to ease the use of wine and is being actively developed. Keep in mind that we don't want to remove winetools, just phase out winetools by advancing wine itself, and avoid promoting it from winehq. This should be taken in no way as an insult to winetools developers or users. The winetools developers are very competent, and their work is appreciated. winetools will eventually no longer be needed (which is a good thing!), and this is one of the first steps towards that process and wine 1.0. -- James Hawkins

Dec. 22, 2005

Re: [lostwages] Remove winetools from download page

by Tom Wickline

On 12/21/05, James Hawkins <truiken(a)gmail.com> wrote: > > As much as I appreciate the work you, Joachim, and others have put > into winetools, we're getting closer to the point in time when > winetools needs to be phased out by a better, more functional wine. > Part of this process is removing it from the official download page. Shouldn't Wine be fixed before it's removed? Isn't it kind of backwards to say we need to have Wine run everything out of the box and to accomplish this were going to remove a link to a user friendly tool that currently helps our users. Then what? your going to have just as many, if not even more people on IRC asking for help who other wise wouldn't have had to do so. Wine is easy for me, and I'm sure for yourself to use and configure but this is just not the case for a large number of people! Removing WineTools is the worst thing this project could do at this time, as its the *only* free GUI that makes a genuine attempt to help first time users. Tom > > -- > James Hawkins > > >

Dec. 22, 2005

Re: [lostwages] Remove winetools from download page

by James Hawkins

n 12/21/05, Sven Paschukat <Sven.Paschukat(a)t-online.de> wrote: > > Joachim says that he has 30.000 downloads per month. That's a big number > and if only one percent of the users has problems, then of course your > hear of them. > That's the problem; a clear distinction between wine and winetools is required. The wine-devel and wine-users lists are for the wine project, and any problems users have with winetools, or because of winetools, should be reported on a winetools mailing list. > And of course mostly users only report when they have problems. Can you > refer these users to the Wine users mailing list? We need detailed > feedback to fix remaining problems. > > James, please don't see the value of winetools only from a developers > view. Normal linux users don't want to test builtin dlls, they just want > to get their windows apps working on linux. IMHO it's better for Wine if > the users become an easy feeling of success instead of letting them fall > from one pitball into another. > Trust me, I don't. I think winetools is a great app, and I've used it on several occasions. I agree that most users want to easily use their windows apps using winetools, and I'm not of the opinion that they shouldn't use winetools. Vitaliy's point is that wine is progressing rapidly towards a 1.0 stable release. Wine's COM implementation is being worked on heavily, along with msi (and uncountless other areas.) Wine is at the point where a user shouldn't need winetools to use many windows apps. For example, it's possible to install IE6 by only registering one native dll and using another native dll for the installer. As much as I appreciate the work you, Joachim, and others have put into winetools, we're getting closer to the point in time when winetools needs to be phased out by a better, more functional wine. Part of this process is removing it from the official download page. -- James Hawkins

Dec. 22, 2005

Re: [lostwages] Remove winetools from download page

by Brian Vincent

On 12/21/05, Sven Paschukat <Sven.Paschukat(a)t-online.de> wrote: > James, please don't see the value of winetools only from a developers > view. Normal linux users don't want to test builtin dlls, they just want > to get their windows apps working on linux. IMHO it's better for Wine if > the users become an easy feeling of success instead of letting them fall > from one pitball into another. I agree that Winetools has an intended audience and I think there's a place for an app like that. Heck, look at CodeWeavers and their cxsetup program. Having said that, are there things that Winetools does that need to be moved into Wine? I'm not sure anyone has ever looked at that. Are there registry settings that belong in wine.inf? Any time a .EXE can't be run out of the box you have to question what Wine is doing wrong to prevent that. -Brian

Dec. 22, 2005

Need help fixing deadlock (GDI)

by Cihan Altinay

Hi, I have spent days finding the reason for PowerPoint 2000 causing a deadlock if a file is opened that contains a preview which itself contains a bitmap >90x90 pixels (ie. on the first slide). After inserting some more traces I feel I am pretty close but I'm stuck now. The problem is connected to GDI's StretchBlt (bitblt.c). It calls MFDRV_StretchBlt and then the trouble begins as can be seen from the output: <snip> trace:bitblt:StretchBlt --Start-- trace:gdi:GDI_GetObjPtr (0x3b0c): enter 1 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3b0c): leave 1 trace:gdi:GDI_GetObjPtr (0x3aec): enter 1 trace:dc:DC_GetDCPtr trace:gdi:GDI_GetObjPtr (0x3b0c): enter 2 trace:dc:DC_GetDCPtr trace:bitblt:StretchBlt 0x3aec 0,0 160x120 -> 0x3b0c 0,0 960x720 rop=cc0020 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GetObjectW 0x3af8 24 0x7fc2f760 trace:gdi:GDI_GetObjPtr (0x3af8): enter 3 trace:gdi:GDI_ReleaseObj (0x3af8): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:metafile:MFDRV_StretchBlt MF_StretchBltViaDIB->len = 20292 rop=cc0020 PixYPM=3780 Caps=96 trace:bitmap:GetDIBits trace:dc:CreateCompatibleDC --Checking lock-- hdc=0x3aec err:syslevel:_CheckNotSysLevel Holding lock 0x7fad49e0 level 3 </snip> Yes well... hdcDst and hdcSrc aren't freed yet from within StretchBlt. There is this comment "FIXME: there is a race condition here"... is that the cause? Btw. this might be the same problem as bug #3125. Can somebody give me a hint on how to tackle this? If you need more output please let me know. Thanks a lot, Cihan

Dec. 22, 2005

Re: [lostwages] Remove winetools from download page

by Sven Paschukat

Vitaliy Margolen schrieb: > I can't say how many people have come to #winehq with different problems > that were related to winetools. From what I could see, not a single > person who I talked to had winetools installed and had Wine programs > working properly. Well, it was just a few month ago when Joachim and me has reworked the winetools. It is no longer config file based, it is using the registry now. We have tested it on multiple Linux distributions and the newest release WineTools 0.9 III hasn't showed serious problems when walking through the menus as intended. Joachim says that he has 30.000 downloads per month. That's a big number and if only one percent of the users has problems, then of course your hear of them. And of course mostly users only report when they have problems. Can you refer these users to the Wine users mailing list? We need detailed feedback to fix remaining problems. James, please don't see the value of winetools only from a developers view. Normal linux users don't want to test builtin dlls, they just want to get their windows apps working on linux. IMHO it's better for Wine if the users become an easy feeling of success instead of letting them fall from one pitball into another. Thanks for the assistance of Tom and Michael. Sven

Dec. 22, 2005

Re: Bug 3885

by Tom Spear

Aric Cyr wrote: >>>I took a look at the D3D_OK hack, and I believe the problem to be >>>CheckDeviceFormat in wined3d/directx.c. This function should return an error if >>>D3DFMT_D32 is checked for on cards which don't support 32bit depth. Currently >>>it just returns OK for most formats though. This code is really just a stub as >>>it stands, and needs to be converted to check if there are any visuals that meet >>>the requested format's requirements, and if there is, return D3D_OK, otherwise >>>D3D_NOTAVAILBLE. >>> >>>To test my theory, try returning D3D_NOTAVAILABLE for the D3DFMT_D32 case >>>(you'll need to add it) in wined3d/directx.c in IWineD3DImpl_CheckDeviceFormat() >>>and see if that fixes that issue or not. This would be just another hack >>>though, so a real patch would still be necessary as I decribed above. Well I took a stab at adding the case for D3DFMT_D32, to the bottom of the other cases, and let it return the D3DERR_NOTAVAILABLE (as opposed to D3D_NOTAVAILABLE), and ran the benchmarks again.. Now it finishes the first one and then goes to do the second one, but crashes in a different spot, so it seems we also have some stack corrupion (as was mentioned in the bug).. So that hack works for now, I would suggest that since the rest of that code is stubbed out, we should probably go ahead and submit a patch so we can at least run the darn thing and then start debugging the stack corruption issue. I should add that on the first run, I disabled the title screens between benchmarks, and changed the "Display and CPU Settings" so that I was using 32-bit textures and triple buffering, and it ran thru several of the tests, while on the 2nd and 3rd runs, I left all settings at defaults; during run 2, it died just after the title screen for mark #2, and during run 3, it died in the middle of mark #2...

Dec. 21, 2005

_itow tests in ntdll/tests

by Paul Vriens

Hi, I was just diving into this as there is failure for months with this test on Winxp-SP2 and W2K3. We call _itow, like this: result = p_itow(ulong2str[0].value, NULL, 10); This however seems not be allowed anymore. Changing it to WCHAR buffer[LARGE_STRI_BUFFER_LENGTH + 1]; result = p_itow(ulong2str[0].value, buffer, 10); make the test succeed, but I don't know what the author wanted with these tests. Any ideas ? Cheers, Paul.

Dec. 21, 2005