- Wine-Devel - list.winehq.org

Latest winetest (20051212) issue on WinXP
by Paul Vriens Dec. 13, 2005

Dec. 13, 2005

Hi, I've just noticed that during the running of winetest.exe windows creates a nice desktop stating that 'Active Desktop' is stopped because an unexpected error occurred. Anyone? Paul.

2 1

Re: WINED3D / D3D9: SetVertexShader & SetPixelShader should not change the shader's refcount
by Oliver Stieber Dec. 13, 2005

Dec. 13, 2005

--- "H. Verbeet" <hverbeet(a)gmail.com> wrote: > SetVertexShader & SetPixelShader should not change the shader's > refcount. Verified on win2k, DirectX 9.0c. > > Changelog: > - Don't change the shader's refcount in SetVertexShader & SetPixelShader > > 26c6ae144caaaa6f7e40f7a7c6e3059851819ecf > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index c3a7f9c..a9c253f 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -3761,7 +3761,6 @@ HRESULT WINAPI IWineD3DDeviceImpl_GetVer > > HRESULT WINAPI IWineD3DDeviceImpl_SetVertexShader(IWineD3DDevice *iface, IWineD3DVertexShader* > pShader) { > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > - IWineD3DVertexShader *oldShader = This->updateStateBlock->vertexShader; > > This->updateStateBlock->vertexShader = pShader; > This->updateStateBlock->changed.vertexShader = TRUE; > @@ -3772,20 +3771,7 @@ HRESULT WINAPI IWineD3DDeviceImpl_SetVer > return D3D_OK; > } > > - if (pShader != NULL) { > - IUnknown *newVertexShaderParent; > - /* GetParent will add a ref, so leave it hanging until the vertex buffer is cleared */ > - TRACE("(%p) : setting pShader(%p)\n", This, pShader); > - IWineD3DVertexShader_GetParent(pShader, &newVertexShaderParent); > - } else { > - TRACE("Clear down the shader\n"); > - } > - if (oldShader != NULL) { > - IUnknown *oldVertexShaderParent; > - IWineD3DVertexShader_GetParent(oldShader, &oldVertexShaderParent); > - IUnknown_Release(oldVertexShaderParent); > - IUnknown_Release(oldVertexShaderParent); > - } > + TRACE("(%p) : setting pShader(%p)\n", This, pShader); The best thing to do is add an internal reference instead of referencing the parent. e.g. if (pShader != NULL) { IWineD3DVertexShader_AddRef(pShader); } if (oldShader != NULL) { IWineD3DVertexShader_Release(oldShader); } ___________________________________________________________ NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/

2 1

Re: WINED3D / D3D9: SetVertexShader & SetPixelShader should not change the shader's refcount
by Oliver Stieber Dec. 13, 2005

Dec. 13, 2005

--- "H. Verbeet" <hverbeet(a)gmail.com> wrote: > SetVertexShader & SetPixelShader should not change the shader's > refcount. Verified on win2k, DirectX 9.0c. > > Changelog: > - Don't change the shader's refcount in SetVertexShader & SetPixelShader > > 26c6ae144caaaa6f7e40f7a7c6e3059851819ecf > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index c3a7f9c..a9c253f 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -3761,7 +3761,6 @@ HRESULT WINAPI IWineD3DDeviceImpl_GetVer > > HRESULT WINAPI IWineD3DDeviceImpl_SetVertexShader(IWineD3DDevice *iface, IWineD3DVertexShader* > pShader) { > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > - IWineD3DVertexShader *oldShader = This->updateStateBlock->vertexShader; > > This->updateStateBlock->vertexShader = pShader; > This->updateStateBlock->changed.vertexShader = TRUE; > @@ -3772,20 +3771,7 @@ HRESULT WINAPI IWineD3DDeviceImpl_SetVer > return D3D_OK; > } > > - if (pShader != NULL) { > - IUnknown *newVertexShaderParent; > - /* GetParent will add a ref, so leave it hanging until the vertex buffer is cleared */ > - TRACE("(%p) : setting pShader(%p)\n", This, pShader); > - IWineD3DVertexShader_GetParent(pShader, &newVertexShaderParent); > - } else { > - TRACE("Clear down the shader\n"); > - } > - if (oldShader != NULL) { > - IUnknown *oldVertexShaderParent; > - IWineD3DVertexShader_GetParent(oldShader, &oldVertexShaderParent); > - IUnknown_Release(oldVertexShaderParent); > - IUnknown_Release(oldVertexShaderParent); > - } > + TRACE("(%p) : setting pShader(%p)\n", This, pShader); The best thing to do is add an internal reference e.g. if (pShader != NULL) { IWineD3DVertexShader_AddRef(pShader) IWineD3DVertexShader_Release(oldShader) ___________________________________________________________ NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/

1 0

BUG (3920) + sync between DIBs and X Server optimisation. (please help)
by Marinescu-Ghetau Iulian Dec. 13, 2005

Dec. 13, 2005

I came to the conclusion that the slowness in "Heroes IV" it has to do with sync'ing lage bitmaps between application DIBs and X Server(see the log: http://bugs.winehq.org/attachment.cgi?id=1470&action=view ). Also, a complete description of the bug is here: http://bugs.winehq.org/show_bug.cgi?id=3902 So i had this ideea that every GDI function could memorise the rectangle that is modifying, so each time a sync between DIB and X Server is needed, only a small part from the bitmap will get copied! I also made some changes to dib.c, bitblt.c and x11drv.h in "wine-0.9.2\dlls\x11drv" folder to implement my ideea, keeping backwards compatibility (if a DIB function doesn't set a valid rectangle for the bitmap that its modifying, the default values are taken - which is the entire bitmap) The changes i was talking about are listed below! My free time is very limited and i would strongly appreciate some help, moustly because something is not working ;( and i didn't manage to figure out what... -added member to X_PHYSBITMAP: XRectangle modified_rect; -added 2 functions: /*********************************************************************** * X11DRV_SetBoundRect */ void X11DRV_SetBoundRect(X_PHYSBITMAP *physBitmap, INT x, INT y, INT width, INT height) { XRectangle *t; INT xMin,yMin,xMax,yMax; if (!physBitmap) return; t = &(physBitmap->modified_rect); if ( t->width && t->height && /*already a valid rect inside*/ width && height ) /*not trying to invalidate rect*/ { //calculate the union of the two rectangles xMin = ((t->x < x)?t->x:x); yMin = ((t->y < y)?t->y:y); xMax = ((t->x + t->width > x + width)?(t->x + t->width):(x + width)); yMax = ((t->y + t->height > y + height)?(t->y + t->height):(y + height)); t->x = xMin; t->y = yMin; t->width = xMax - xMin; t->height = yMax - yMin; } else { t->x = x; t->y = y; t->width = width; t->height = height; } TRACE("(%p,%d,%d,%d,%d)\n", physBitmap->hbitmap, t->x, t->y, t->width, t->height); } /*********************************************************************** * X11DRV_GetBoundRect */ UINT X11DRV_GetBoundRect(X_PHYSBITMAP *physBitmap, INT *x, INT *y, INT *width, INT *height) { DIBSECTION dib; XRectangle *t; if (!physBitmap || GetObjectW( physBitmap->hbitmap, sizeof(dib), &dib ) != sizeof(dib)) { ERR("called for non-DIBSection!?\n"); return 1; } t = &(physBitmap->modified_rect); /* we should check for oversize values */ if ( (t->width > 0) && (t->height > 0) && (t->x < dib.dsBm.bmWidth) && (t->y < dib.dsBm.bmHeight) ) { *x = t->x; *y = t->y; if (t->x + t->width > dib.dsBm.bmWidth) *width = dib.dsBm.bmWidth - t->x; else *width = t->width; if (t->y + t->height > dib.dsBm.bmHeight) *height = dib.dsBm.bmHeight - t->y; else *height = t->height; } else { *x = 0; *y = 0; *width = dib.dsBm.bmWidth; *height = dib.dsBm.bmHeight; } TRACE("(%p,%d,%d,%d,%d)\n", physBitmap->hbitmap, *x, *y, *width, *height); return 0; } -changed X11DRV_DIB_DoUpdateDIBSection like this: static void X11DRV_DIB_DoUpdateDIBSection(X_PHYSBITMAP *physBitmap, BOOL toDIB) { INT x,y,width,height; if ( X11DRV_GetBoundRect(physBitmap,&x,&y,&width,&height) ) return; /*invalidate bound rect*/ X11DRV_SetBoundRect(physBitmap,0,0,0,0); X11DRV_DIB_DoCopyDIBSection(physBitmap, toDIB, physBitmap->colorMap, physBitmap->nColorMap, physBitmap->pixmap, x, y, x, y, // i think something is wrong here (help?) width, height); } - and finally, a GDI function calls it like this (for example bitblt): X11DRV_SetBoundRect(physDevDst->bitmap,xDst,yDst,width,height); X11DRV_CoerceDIBSection( physDevDst, DIB_Status_GdiMod, FALSE ); if (physDevDst != physDevSrc) { X11DRV_SetBoundRect(physDevSrc->bitmap,xSrc,ySrc,width,height); X11DRV_CoerceDIBSection( physDevSrc, DIB_Status_GdiMod, FALSE ); } result = BITBLT_InternalStretchBlt( physDevDst, xDst, yDst, width, height, physDevSrc, xSrc, ySrc, width, height, rop ); END: if (physDevDst != physDevSrc) X11DRV_UnlockDIBSection( physDevSrc, FALSE ); X11DRV_UnlockDIBSection( physDevDst, TRUE );

2 2

Re: http headers reworking
by Alexandre Julliard Dec. 13, 2005

Dec. 13, 2005

Aric Stewart <aric(a)codeweavers.com> writes: > Redo how headers are handled. > eliminating the concept of Standard Headers and allow all headers to be > added multiple times. > Allow querying of headers with an index to get the multiple headers. > Respect response vs request headers in HttpQueryInfo. > Add a number of tests to extensively test header adding and replacing. > All fixes for Picasa. The tests don't work here: http.c:1152: Test failed: Index was not incremented http.c:1156: Test failed: Second Index Should Not Exist http.c:1167: Test failed: Index was not incremented http.c:1168: Test failed: incorrect string was returned(test2) http.c:1173: Test failed: Index was not incremented http.c:1177: Test failed: Third Header Should Not Exist http.c:1187: Test failed: Index was not incremented http.c:1188: Test failed: incorrect string was returned(test3) http.c:1193: Test failed: Index was not incremented http.c:1197: Test failed: Third Header Should Not Exist http.c:1207: Test failed: Index was not incremented http.c:1208: Test failed: incorrect string was returned(test3) http.c:1213: Test failed: Index was not incremented http.c:1217: Test failed: Third Header Should Not Exist http.c:1227: Test failed: Index was not incremented http.c:1228: Test failed: incorrect string was returned(test4) http.c:1232: Test failed: Index was not incremented http.c:1233: Test failed: incorrect string was returned(test4) http.c:1236: Test failed: Third Header Should Not Exist http.c:1244: Test failed: Index was not incremented http.c:1245: Test failed: incorrect string was returned(test5) http.c:1249: Test failed: Index was not incremented http.c:1250: Test failed: incorrect string was returned(test5) http.c:1253: Test failed: Third Header Should Not Exist http.c:1261: Test failed: Index was not incremented http.c:1262: Test failed: incorrect string was returned(test6) http.c:1266: Test failed: Index was not incremented http.c:1267: Test failed: incorrect string was returned(test6) http.c:1270: Test failed: Third Header Should Not Exist http.c:1278: Test failed: Index was not incremented http.c:1279: Test failed: incorrect string was returned(test7) http.c:1283: Test failed: Index was not incremented http.c:1287: Test failed: Third Header Should Not Exist -- Alexandre Julliard julliard(a)winehq.org

2 1

Can't install mdac at all now
by Dan Kegel Dec. 13, 2005

Dec. 13, 2005

Bug 3636 is worse now. http://bugs.winehq.org/show_bug.cgi?id=3636 A few weeks ago, after mdac installer finished, I could go and unpack the installed cabs by hand. Now the installer aborts before it even copies the cabs. Bleah. -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 3

freetype and wine
by Curro Amores Dec. 13, 2005

Dec. 13, 2005

Hi: I get everytime i want to display a report on my access97 app this error: fixme:font:load_VDMX Failed to retreive vTable Then the fonts of the report are displayed separated and bigger than on windows. Somebody told me to install freetype new version. I have installed the last version of freetype2 (9.8.3) and it keeps on the same. Do i have to do something for telling wine to use the new version of freetype? Im using windows98 emulation in wine for this app. Has it something to do that i have moved all windows xp ttf files to fonts fake directory?? Thanks all!

1 0

Re: gethostbyname(my_name) and IL2-Sturmovik
by Juan Lang Dec. 13, 2005

Dec. 13, 2005

Hi David, > The string in str was "192.168.2.75" which is my Network IP-Adress. > With wine(under Linux), as far as I've tested it, exactly the same > code always generates "127.0.0.1". > Since Wine tries to simulate Windows as exactly as possible, > this is wrong. > So, in my opinion this Patch is necessary. :-) You're right that Wine doesn't behave correctly in this case. The trouble is your patch is rather ugly. First, the style isn't correct--no C++-style comments, please, and make the indenting consistent. Second, there's a leak in the code you wrote, the socket you open to do SIOCGIFCONF on is never closed. It would be cleaner, in my opinion, to use iphlpapi's GetAdaptersInfo, which already enumerates the public (non-loopback) interfaces available on the system. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

RFC: D3D7 and WineD3D
by Stefan Dösinger Dec. 12, 2005

Dec. 12, 2005

Hello, In the past weeks, I've worked on a re-write of the Direct3D7 implementation with WineD3D. Well, I've managed to get some games running, but I have also encountered a few problems. Before I continue with this, I'd like to ask for your opinions. I have uploaded a patch to http://doesi.gmxhome.de/d3d7.patch.bz2, it's a diff against Wine CVS from December, 11th 2005. It's not really meant to be used, but rather to have something to look at. I don't know how long I can keep the patch there, because I am limited in space. I've sent the patch to Oliver some days ago to upload it to his sourceforge website, it will be available there when he uploads it. So what's the point of this mail? While a D3D7->WineD3D wrapping can be done by wrapping D3D7 only and leave DirectDraw in ddraw.dll, it has a few ugly drawbacks: -> Device initalisation: In D3D7, the first step is to create a IDirectDraw Device, set up the device, create a surface and then create a Direct3D Device. When creating the WineD3DDevice in the last step, I have to do some ugly things to wrap the allready existing Surface to a newly created WineD3DSurface. The same applies in reverse order for the device removal. I also don't know what to do if a game changes the screen setup after D3DDevice creation. -> Surfaces: In D3D7 surfaces are children of IDirectDraw, while in WineD3D they are children of WineD3DDevice. Because the D3D7Device can be created and destroyed without modifying surfaces, I have to manage the surface's properties and memory areas for both DirectDraw and WineD3D. Overrides for the Lock() and Unlock() functions are used to access the WineD3D surface if it exists. I think that everything would be much cleaner if the DirectDraw functionality was also moved to WineD3D. My suggestion is the follwing. -> WineD3D would be initialised in the D3D7 way, using a new interface WineDDrawDevice. D3D8 and D3D9 could easily manage this in their create functions -> Surfaces are created with WineDDrawDevice, and they survive the release of WineD3DDevice. This makes surface creation easier for D3D7, and it's easy to adopt it for D3D9 and D3D8. -> The IWineD3DSurface interface gets additional functionality for DirectDraw operations. I'd suggest 3 versions of the 2D functions: One based on plain X11(for compatiblity) calls, one that uses DGA(speed without 3D acceleration), and one that uses OpenGL(For fast rendering without /dev/mem access). For DXVersion > 7 the OpenGL version is used, and for DX7 it can be decided when the primary surface is created. What's the drawback? First, it's much more work, and it's a really invasive change to WineD3D, which becomes more complex. Because of this I'd like to know your opinion before I spend a lot of time for this. Stefan

1 1

gethostbyname(my_name) and IL2-Sturmovik
by David Nolden Dec. 12, 2005

Dec. 12, 2005

Ok, I've just checked doing the same thing under windows. The test(ripdaveno is the name of the Computer I tested on): { ... hostent* h = gethostbyname("ripdaveno"); char* str = inet_ntoa(*((in_addr*)h->h_addr_list[0])); ... } The string in str was "192.168.2.75" which is my Network IP-Adress. With wine(under Linux), as far as I've tested it, exactly the same code always generates "127.0.0.1". Since Wine tries to simulate Windows as exactly as possible, this is wrong. So, in my opinion this Patch is necessary. :-) greetings, David Nolden

1 0