May 2009 - Wine-devel - list.winehq.org

Re: [1/2] winetest: malloc() & co are encapsulated, so encapsulate free() too.
by Alexandre Julliard 15 May '09

15 May '09

Francois Gouget <fgouget(a)free.fr> writes: > It's not very clean to encapsulate malloc() & co with xmalloc(), etc, > but to then call free() directly. It means if the implementation of > xmalloc() is changed to call HeapAlloc() all the free() have to be > changed. So encapsulate free() too. xmalloc() is clearly a wrapper around malloc(), so there's no need to rename free(). If you want to change the allocation you should rename both to heap_alloc/heap_free or something like that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Fiddling with EnumServicesStatusExW
by Paul Vriens 15 May '09

15 May '09

(I accidentally only sent this message to Rob only) Hi, To get away from the tests stuff I thought I'd resurrect my plans to implement EnumServiceStatusExW (the A-version is needed by SysInternal's Process Explorer amongst others). I have most of the stuff ready: - Added svcctl_EnumServicesStatusExW to /wine/wine-git/include/wine/svcctl.idl - Added svcctl_EnumServicesStatusExW to /wine/wine-git/programs/services/rpc.c - Added a enumeration routine to /wine/wine-git/programs/services/services.c (and .h of course) - Changed EnumServiceStatusExW in /wine/wine-git/dll/advapi32/service.c to call svcctl_EnumServicesStatusExW There is one important thing I can't get my head around. The call to EnumServicesStatusExW passes a pointer to a BYTE * lpServices with a length of cBufSize. lpServices is an array of some ENUM_SERVICE_STATUS_PROCESSW structs. The first two parameters of these structs are pointers to WCHAR strings. The strings for all these structs (on Windows) can be found after all the structs themselves. So imagine that we should have 2 services in our lpServices to be passed back to the initial caller: 0000 [0].lpServiceName -> 0088 0008 [0].lpDisplayName -> 0114 0016 [0].SERVICE_STATUS struct of 7 DWORDS 0044 [1].lpServiceName -> 0140 0052 [1].lpDisplayName -> 0166 0060 [1].SERVICE_STATUS struct of 7 DWORDS 0088 "ServiceName1" 0114 "DisplayName1" 0140 "ServiceName1' 0166 "DisplayName1" (The above is what EnumServicesStatusExW would pass back to the caller) The enumeration I have in services.c fills the lpServiceName pointer to the actual string. Likewise for lpDisplayName. This is all in the RPC world (where the lpServices address is different to the caller passed address). When lpServices is passed back to the caller I can see that the SERVICE_STATUS structs are correct but the pointers to the strings are pointing to the original ones. How can I make sure the pointers to the strings are correctly passed back as well? Should the RPC stuff take care of these pointers and 'translate' them? We could of course teach EnumServicesStatusExW to change the pointers to the appropriate ones. We know exactly where there strings are so it should be fairly trivial to change those pointers. This however seems like a hack. Any idea is welcome. -- Cheers, Paul.

2 2

Re: (try2)Fix ATI HD4800 being reported as ATI 9500
by Roderick Colenbrander 15 May '09

15 May '09

The patch itself is correct but the comment regarding the X2 4800 is incorrect. Those cards indeed have 2GB of video memory (and the PR people mention that to you) but the boards contain two GPUs and both need a have a copy of textures and other resources (though the GPUs can communicate using a high speed bus). Effectively the amount of video memory is still 1GB. Roderick On Fri, May 15, 2009 at 2:29 AM, Robert Key <hpestilence(a)gmail.com> wrote: > Changelog: > * Added support for the ATI HD 4800 series (should be all of them). > Used a HD4830 device id for HD4800 cards in wined3d_gl.h. > > > >

1 0

DIB Engine - first set of fixings agains wine test suite
by Massimo Del Fedele 14 May '09

14 May '09

I started fixing failures against test suite. Most of bitmap ones are fixed, remaining are due to still stubbed funcs. Now the problem is that it fixed also most todo_wines on bitmap suite.... As usual, on bug 421 page for who wants to test it. Ciao Max

3 4

Request for update of the AUTHORS-file
by André Hentschel 14 May '09

14 May '09

The Authors file wasnt updated since 2008-06-16. I maybe would send a patch but i bet Julliard has a Script :)

1 0

Unused functions in fusion.dll
by Francois Gouget 14 May '09

14 May '09

The following fusion.dll functions are unused: nobody calls them and they are not exported. CompareAssemblyIdentity() GetAssemblyIdentityFromFile() I checked a Windows fusion.dll I have here and I did not see them being exported there either. Yet, the MSDN documents them and presumably there's a way a application can call them... Does anyone know what's up? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner

4 5

Re: Unused functions in fusion.dll
by Paul Vriens 14 May '09

14 May '09

Luke Benstead wrote: > 2009/5/14 Paul Vriens <paul.vriens.wine(a)gmail.com>: >> Paul Vriens wrote: >>> Francois Gouget wrote: >>>> The following fusion.dll functions are unused: nobody calls them and they >>>> are not exported. >>>> >>>> CompareAssemblyIdentity() >>>> GetAssemblyIdentityFromFile() >>>> >>>> I checked a Windows fusion.dll I have here and I did not see them being >>>> exported there either. Yet, the MSDN documents them and presumably there's a >>>> way a application can call them... >>>> >>>> Does anyone know what's up? >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>> What version of the .NET framework do you have? It looks like these came >>> with 2.0 >>> >> Forget that remark. Just checked both fusion and mscoree on .NET 1.1 and 3.5 >> and neither have these exports. >> >> So, no clue ;) >> >> -- >> Cheers, >> >> Paul. >> >> >> > > Just a pure guess, but Googling for CompareAssemblyIdentity returns > this: http://forums.iis.net/t/1149942.aspx which shows: > > mscorwks!CompareAssemblyIdentity+b04a > > Is it possible that the actual exported CompareAssemblyIdentity (and > the one documented on MSDN) should be in mscorwks.dll and NOT in > fusion.dll? > > Just thinking aloud. > > Luke. Spot on: (Vista with .NET3.5SP1): winedump -v -j export mscorwks.dll | grep -e CompareAssemblyIdentity -e GetAssemblyIdentityFromFile 002FF322 48 CompareAssemblyIdentity 00300A41 69 GetAssemblyIdentityFromFile (W2K3 with .NET1.1): not present (W2K3 with .NET2.0): 000F3C2F 47 CompareAssemblyIdentity 002DE14F 68 GetAssemblyIdentityFromFile (W2K3 / .NET 2.0SP1/3.0/3.0SP1/3.5): 0013A67D 47 CompareAssemblyIdentity 003277D3 68 GetAssemblyIdentityFromFile (W2K3 with .NET 3.5SP1): 002FF132 48 CompareAssemblyIdentity 00300851 69 GetAssemblyIdentityFromFile -- Cheers, Paul.

2 1

Re: Fix ATI HD4800 being reported as ATI 9500
by Roderick Colenbrander 14 May '09

14 May '09

I would recommend to add a new if-statement for hd48xx cards (detect the 4830, 4850, 4870, 4890) and set those cards to the pci id of the 4830 and set the video memory to let say 512MB for now. Roderick On Thu, May 14, 2009 at 7:08 AM, Robert Key <hpestilence(a)gmail.com> wrote: > Changelog: > * Add HD4800 series to be detected in graphics card table. > This makes it so that the ati dx9 quirks aren't applied. > > Also added the pci id of HD4850 to wined3d_gl.h > > > >

1 0

Re: wined3d: Updated NVIDIA mobile GT GPUs
by Roderick Colenbrander 14 May '09

14 May '09

Hi, In order to not let the card database become too long I group a lot of boards together. That should be doable for the 96xx / 97xx / 98xx boards you added below and then I use the lowest number of video memory (512MB). This should be fine for apps as they only need a reasonable estimate of the card. Further we can't use all video memory anyway. In the near future I plan to add a better mechanism which will detect the actual card using nv-control. Roderick 2009/5/13 Łukasz Wojniłowicz <lukasz.wojnilowicz(a)gmail.com>: > --- > dlls/wined3d/directx.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > dlls/wined3d/wined3d_gl.h | 7 +++++++ > 2 files changed, 49 insertions(+), 0 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index f5d4d3e..989ab7f 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -1112,11 +1112,46 @@ static BOOL IWineD3DImpl_FillGLCaps(WineD3D_GL_Info *gl_info) { > gl_info->gl_card = CARD_NVIDIA_GEFORCE_9800GT; > vidmem = 512; > } > + /* Geforce9800M GTX - highend */ > + else if(strstr(gl_info->gl_renderer, "9800M GTX")) { > + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9800MGTX; > + vidmem = 1024; /* The 9800M GTX has 1024MB */ > + } > + /* Geforce9800M GTS - highend */ > + else if(strstr(gl_info->gl_renderer, "9800M GTS")) { > + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9800MGTS; > + vidmem = 1024; /* The 9800M GTS has 1024MB */ > + } > + /* Geforce9800M GT - highend */ > + else if(strstr(gl_info->gl_renderer, "9800M GT")) { > + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9800MGT; > + vidmem = 512; /* The 9800M GT has 512MB */ > + } > /* Geforce9 - midend */ > else if(strstr(gl_info->gl_renderer, "9600")) { > gl_info->gl_card = CARD_NVIDIA_GEFORCE_9600GT; > vidmem = 384; /* The 9600GSO has 384MB, the 9600GT has 512-1024MB */ > } > + /* Geforce9700M GTS - midend */ > + else if(strstr(gl_info->gl_renderer, "9700M GTS")) { > + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9700MGTS; > + vidmem = 512; /* The 9700M GTS has 512MB */ > + } > + /* Geforce9700M GT - midend */ > + else if(strstr(gl_info->gl_renderer, "9700M GT")) { > + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9700MGT; > + vidmem = 512; /* The 9700M GT has 512MB */ > + } > + /* Geforce9650M GT - midend */ > + else if(strstr(gl_info->gl_renderer, "9650M GT")) { > + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9650MGT; > + vidmem = 512; /* The 9650M GT has 512-1024MB */ > + } > + /* Geforce9600M GT - midend */ > + else if(strstr(gl_info->gl_renderer, "9600M GT")) { > + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9600MGT; > + vidmem = 512; /* The 9600M GT has 512-1024MB */ > + } > /* Geforce9 - midend low / Geforce 200 - low*/ > else if(strstr(gl_info->gl_renderer, "9500") || > strstr(gl_info->gl_renderer, "GT 120") || > @@ -3991,7 +4026,14 @@ static const struct driver_version_information driver_version_table[] = { > {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9400GT, "NVIDIA GeForce 9400 GT", 7, 15, 11, 8044 }, > {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9500GT, "NVIDIA GeForce 9500 GT", 7, 15, 11, 8044 }, > {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9600GT, "NVIDIA GeForce 9600 GT", 7, 15, 11, 8044 }, > + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9600MGT, "NVIDIA GeForce 9600M GT", 7, 15, 11, 8044 }, > + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9650MGT, "NVIDIA GeForce 9650M GT", 7, 15, 11, 8044 }, > + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9700MGT, "NVIDIA GeForce 9700M GT", 7, 15, 11, 8044 }, > + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9700MGTS, "NVIDIA GeForce 9700M GTS", 7, 15, 11, 8044 }, > {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9800GT, "NVIDIA GeForce 9800 GT", 7, 15, 11, 8044 }, > + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9800MGT, "NVIDIA GeForce 9800M GT", 7, 15, 11, 8044 }, > + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9800MGTS, "NVIDIA GeForce 9800M GTS", 7, 15, 11, 8044 }, > + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9800MGTX, "NVIDIA GeForce 9800M GTX", 7, 15, 11, 8044 }, > {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_GTX260, "NVIDIA GeForce GTX 260", 7, 15, 11, 8044 }, > {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_GTX275, "NVIDIA GeForce GTX 275", 7, 15, 11, 8044 }, > {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_GTX280, "NVIDIA GeForce GTX 280", 7, 15, 11, 8044 }, > diff --git a/dlls/wined3d/wined3d_gl.h b/dlls/wined3d/wined3d_gl.h > index 1a9c925..4f3542d 100644 > --- a/dlls/wined3d/wined3d_gl.h > +++ b/dlls/wined3d/wined3d_gl.h > @@ -3330,7 +3330,14 @@ typedef enum _GL_Cards { > CARD_NVIDIA_GEFORCE_9400GT = 0x042c, > CARD_NVIDIA_GEFORCE_9500GT = 0x0640, > CARD_NVIDIA_GEFORCE_9600GT = 0x0622, > + CARD_NVIDIA_GEFORCE_9600MGT = 0x0649, > + CARD_NVIDIA_GEFORCE_9650MGT = 0x064C, > + CARD_NVIDIA_GEFORCE_9700MGT = 0x064A, > + CARD_NVIDIA_GEFORCE_9700MGTS = 0x062A, > CARD_NVIDIA_GEFORCE_9800GT = 0x0614, > + CARD_NVIDIA_GEFORCE_9800MGT = 0x060B, > + CARD_NVIDIA_GEFORCE_9800MGTS = 0x0628, > + CARD_NVIDIA_GEFORCE_9800MGTX = 0x0608, > CARD_NVIDIA_GEFORCE_GTX260 = 0x05e2, > CARD_NVIDIA_GEFORCE_GTX275 = 0x05e6, > CARD_NVIDIA_GEFORCE_GTX280 = 0x05e1, > -- > 1.6.0.6 > > > >

1 0

Re: winhlp32: Avoid duplicate assignment in WINHELP_GetWindowInfo().
by John Klehm 14 May '09

14 May '09

On Wed, May 13, 2009 at 4:18 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > Most straightforward, I hope. :-) > > Gerald > > ChangeLog: > Avoid duplicate assignment in WINHELP_GetWindowInfo(). > > diff --git a/programs/winhlp32/winhelp.c b/programs/winhlp32/winhelp.c > index 7f74d8b..d1980e5 100644 > --- a/programs/winhlp32/winhelp.c > +++ b/programs/winhlp32/winhelp.c > @@ -278,7 +278,7 @@ HLPFILE_WINDOWINFO* WINHELP_GetWindowInfo(HLPFILE* hlpfile, LPCSTR name) > mwi.origin.x = mwi.origin.y = mwi.size.cx = mwi.size.cy = CW_USEDEFAULT; > mwi.style = SW_SHOW; > mwi.win_style = WS_OVERLAPPEDWINDOW; > - mwi.sr_color = mwi.sr_color = 0xFFFFFF; > + mwi.sr_color = 0xFFFFFF; > } > return &mwi; > } > Maybe one of was intended to be nsr_color?

1 0