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

Re: [PATCH 5/7] comdlg32: Implement support for custom control subitems.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=11214 Your paranoid android. === WVISTAADM (32 bit itemdlg) === itemdlg.c:1284: Test failed: Failed to find item. itemdlg.c:1287: Test failed: Got L"" itemdlg.c:1289: Test failed: Failed to find item. itemdlg.c:1292: Test failed: Got L"" itemdlg.c:1294: Test failed: Failed to find item. itemdlg.c:1297: Test failed: Got L"" itemdlg.c:1300: Test failed: Got L"" === W2K8SE (32 bit itemdlg) === itemdlg.c:1284: Test failed: Failed to find item. itemdlg.c:1287: Test failed: Got L"" itemdlg.c:1289: Test failed: Failed to find item. itemdlg.c:1292: Test failed: Got L"" itemdlg.c:1294: Test failed: Failed to find item. itemdlg.c:1297: Test failed: Got L"" itemdlg.c:1300: Test failed: Got L""

May 26, 2011

Re: [PATCH 4/7] comdlg32: Implement some functions for modifying custom controls.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=11212 Your paranoid android. === WVISTAADM (32 bit itemdlg) === itemdlg.c:1284: Test failed: Failed to find item. itemdlg.c:1287: Test failed: Got L"" itemdlg.c:1289: Test failed: Failed to find item. itemdlg.c:1292: Test failed: Got L"" === W2K8SE (32 bit itemdlg) === itemdlg.c:1284: Test failed: Failed to find item. itemdlg.c:1287: Test failed: Got L"" itemdlg.c:1289: Test failed: Failed to find item. itemdlg.c:1292: Test failed: Got L""

May 26, 2011

Re: [PATCH 1/7] comdlg32: Add a container for custom controls.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=11209 Your paranoid android. === W7PROX64 (32 bit itemdlg) === itemdlg: unhandled exception c0000005 at 75B94C19

May 26, 2011

Re: winscard: Implement some functions of winscard.dll

by Alexandre Julliard

Sergey Stepanov <serg_admin(a)rambler.ru> writes: > @@ -33,6 +35,24 @@ const SCARD_IO_REQUEST g_rgSCardT0Pci = { SCARD_PROTOCOL_T0, 8 }; > const SCARD_IO_REQUEST g_rgSCardT1Pci = { SCARD_PROTOCOL_T1, 8 }; > const SCARD_IO_REQUEST g_rgSCardRawPci = { SCARD_PROTOCOL_RAW, 8 }; > > +#define MAKE_FUNCPTR(f) static typeof(f) * p##f = NULL > +MAKE_FUNCPTR(SCardEstablishContext); > +MAKE_FUNCPTR(SCardReleaseContext); > +#undef MAKE_FUNCPTR This can't work. You need to use the Unix headers (with appropriate configure checks), declare pointers to the Unix functions, and convert any types that need it before calling them. -- Alexandre Julliard julliard(a)winehq.org

May 26, 2011

Re: USB Device Support

by Juan Lang

Hi Scott, > I've been working through my Dell Inspiron 1545 with Linux/Ubuntu > 10.04 LTS experiences with ongoing reviews. I'd like to provide some help > to others considering making the transition from Windows to Linux. I'm > trying to get my Garmin GPS to talk to its Mapsource (running under WINE) > application through a USB port. This allows tracks to be read from and > written to the GPS itself. So far no luck. Can someone there please > provide some advice? If this functionality isn't available yet then so be > it. The Mapsource application runs fine it's just the USB communication > that isn't working. Many thanks. Such questions are better addressed to the Wine forum. Thanks, --Juan

May 26, 2011

kernel32/heap: Fix GlobalMemoryStatus()/GlobalMemoryStatusEx()

by Adam Martinson

There are a bunch of old apps which are known to be buggy with this, the ones I tested were: Dragon NaturallySpeaking 7 Adobe Illustrator 8 Need for Speed 2 SE (demo) Adobe Photoshop 4 Photoshop 4 has a hack in GlobalMemoryStatus() that's causing problems for some of the others. The 2nd patch removes that hack, and breaks it the same way it's broken on Windows. Normally I wouldn't advocate breaking apps, but in this case I think it's appropriate. The 3rd patch gives a workaround for Photoshop 4 that seams like the appropriate solution to me, as it mirrors the workaround for Windows. Any feedback would be appreciated.

May 26, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Thu, May 26, 2011 at 1:14 PM, Joris Huizer <joris_huizer(a)yahoo.com> wrote: > On 05/26/2011 10:33 AM, Michael Mc Donnell wrote: >> I've added some more tests to see if I could make it fail. Microsoft's >> UpdateSemantics is not very picky. I can't get it to return anything >> but D3D_OK except for when I pass a null pointer. My implementation >> follows this behavior except for two cases: it returns E_FAIL when >> passing an undefined type and when the offset is not 4 byte aligned. >> This is because the values are checked inside vertexdeclaration_init. >> So Wine is stricter. I don't think that it is necessarily a problem >> because applications that pass bogus declarations like those will >> likely not work anyway. My own tests with a small interactive demo >> show that in those cases the application will crash with an access >> violation when it tries to re-draw the scene. > > I don't know whether it applies here, but if I understand correctly, > there have been cases before that Wine must not be stricter than Windows. > Tthe reason is that a program may 'depend' on a function crashing (it having > an exception caught in that case). > In such a situation, Wine's version of the function not crashing would cause > a code path being executed > that normally never is (causing incorrect behavior even) > > Again I don't know whether it is relevant in this cause. Yeah I'd prefer it too to be 100% compatible. However, I think it is highly unlikely that any programs depend on an exception being thrown by EndScene in a drawing method. But you never know, some people do crazy things :-) I think the current implementation is good enough as long as there is no evidence of programs depending on that behavior. The problem is that UpdateSemantics in the d3dx9 library depends on d3d9 and the error code is generated by vertexdeclaration_init in d3d9. That means d3d9 would have to be changed to make it less picky. That might on the other hand break other things that depend on it being picky (I haven't looked at the tests in d3d9). I thought of managing an array of D3DVERTEXELEMENT9 in ID3DXMeshImpl instead of a IDirect3DVertexDeclaration9, and then have ID3DXMeshImpl_DrawSubset call IDirect3DDevice9_CreateVertexDeclaration just before IDirect3DDevice9_SetVertexDeclaration. But that would not solve the problem as it would just shift the bad call to ID3DXMeshImpl_DrawSubset and not result in an exception in EndScene. It would also result in a lot of extra calls depending on the number of subsets. So I can't see any good way around modifying d3d9, but that might cause other problems as mentioned earlier. So to recapitulate, I think the best solution is to ignore that little difference until we see programs that depend on it. Michael Mc Donnell

May 26, 2011

Re: kernel32/toolhelp: PROCESSENTRY32::szExeFile is the full path in Win9x.

by Adam Martinson

On 05/26/2011 06:38 AM, Saulius Krasuckas wrote: > WRT doesn't test win9x any longer, so what's the point of putting such > check in the test? Ye, I noticed that when I was looking through Marvin's results, the reason I sent this one was to have the testbot check it xD

May 26, 2011

Re: ole32/ole2: Don't call IDropTarget::QueryInterface() in RegisterDragDrop(). [whitespace fixed]

by Adam Martinson

On 05/26/2011 06:56 AM, Huw Davies wrote: > On Thu, May 26, 2011 at 06:51:13AM -0500, Adam Martinson wrote: >> On 05/26/2011 06:47 AM, Huw Davies wrote: >>> On Wed, May 25, 2011 at 12:45:15PM -0500, Adam Martinson wrote: >>>> On 05/25/2011 12:36 PM, Adam Martinson wrote: >>>>> The AddRef is done in WrapDropTarget(), seems like the appropriate >>>>> place for it. Quite right on the rest though, thanks. >>>> Oops no, the window prop should be pDropTarget, not the wrapper. >>>> The wrapper is only used for the marshalling. >>> That window prop could probably go away, I only put it there because >>> that's what Windows does, I doubt there's an app that relies on it >>> though. However if it stays you do need the AddRef! >>> >>> Huw. >> Best to mirror Windows as close as possible. The AddRef() is done >> in WrapDropTarget(). On failure IDropTarget::Release() is done on >> the wrapper, which removes the ref on the original. > You're storing a 2nd instance of the ptr (the first being in the > wrapper), conventionally you take a 2nd ref. When you remove the > window prop you release and when you destroy the wrapper you release > again. > > Huw. Ah, right, looks like I'm leaking the wrapper this way.

May 26, 2011

Re: ole32/ole2: Don't call IDropTarget::QueryInterface() in RegisterDragDrop(). [whitespace fixed]

by Huw Davies

On Thu, May 26, 2011 at 06:51:13AM -0500, Adam Martinson wrote: > On 05/26/2011 06:47 AM, Huw Davies wrote: > >On Wed, May 25, 2011 at 12:45:15PM -0500, Adam Martinson wrote: > >>On 05/25/2011 12:36 PM, Adam Martinson wrote: > >>>The AddRef is done in WrapDropTarget(), seems like the appropriate > >>>place for it. Quite right on the rest though, thanks. > >>Oops no, the window prop should be pDropTarget, not the wrapper. > >>The wrapper is only used for the marshalling. > >That window prop could probably go away, I only put it there because > >that's what Windows does, I doubt there's an app that relies on it > >though. However if it stays you do need the AddRef! > > > >Huw. > Best to mirror Windows as close as possible. The AddRef() is done > in WrapDropTarget(). On failure IDropTarget::Release() is done on > the wrapper, which removes the ref on the original. You're storing a 2nd instance of the ptr (the first being in the wrapper), conventionally you take a 2nd ref. When you remove the window prop you release and when you destroy the wrapper you release again. Huw.

May 26, 2011