February 2006 - Wine-devel - list.winehq.org

Want fun? Try qemu.exe on wine
by Detlef Riekenberg 23 Feb '06

23 Feb '06

Hi. SDLVIDEODRIVER=windib wine qemu.exe -L . -hda reactos_0.2.8.img winefile starts inside reactos :-) -- By By ... ... Detlef

1 1

explorer.exe is a child of new process
by Paul Vriens 23 Feb '06

23 Feb '06

Hi, with current git/cvs I can see that there is now a new explorer.exe process running when I start process explorer. What is strange though, is that explorer.exe is a child of procexp.exe. Is this supposed to be like that? Cheers, Paul.

2 1

Re: D3D8 caps -> wined3d
by Stefan Dösinger 23 Feb '06

23 Feb '06

Hi, > + /* Optimization */ > + BOOL modelview_valid; > + BOOL proj_valid; > + BOOL view_ident; > + BOOL last_was_rhw; > + GLenum tracking_parm; > ... Are you sure that this is the latest version of IWineD3DDeviceImpl? I think my patch which added a viewport_changed member here was applied to CVS. I don't have CVS access right now, but I think that the structure you added is out of date.

2 1

Cross-Machine COM-Calls under Wine... (RePost from wine.user)
by Olaf Schmidt 23 Feb '06

23 Feb '06

are working here, using our own implementation of a COM-based RPC-Server. Its speciality is the hosting of COM-Binaries, that don't have to be registered, to instantiate Classes and invoke Methods on them. If you want to test a Server/Client-Pair - here's our free Download: www.datenhaus.de/Downloads/dh_RPC.zip For a successful test under Wine, you have to Install the Redistributables of an actual VB6-Runtime and some ADO-Distributable >=2.5 first. I've tested the whole thing under a Debian-Sid with a somewhat older Kernel (2.6.9), but with a new "apt-getted" Wine-Version (0.97). The Installation of the VB6-Runtime and the ADO-Redist was not possible, until I figured out, that a prior install of IE6 was helpful, to install the two above mentioned packages. After installing these prerequisites, I removed the IE6-ProgramFolder, unpacked our ZIP to c:\dh_RPC, started the Server and the Client - eh voilà - all was working fine (Linux->Linux and XP->Linux). The complete set of COM-DemoCalls was working "OutOfTheBox", even the "Disconnected ADO-Recordset"-Call was successful. (For the Linuxers, that are serialized DB-Resultsets, wich are often used in distributed COM-Scenarios). No Memory-Leaking, even under Stress (the server was able, to deliver max. 700 small COMRequsest per second, stressed from multiple Clients (XP-Box, comparable Hardware, reached ca. 2000). So Wine has ca. 3 times the Call-Overhead, regarding Object-Instantiation and Method-Invoking-By-Name. But the more realistic Recordset-Call was finished after 14ms, where the XP-Box needed 9ms - so for realistic Calls, we now see only factor 1.5 under Wine. And in the "Large-String- Reflection-Test" (2MB Up- and 4MB-Download) - Wine was a little bit faster than XP - good job, regarding your socket-bindings. Minimizing to the "KDE-SysTray", all was working; I was impressed. Now the bad news: ;-) Not working was: 1. Running as Service (Service-Registering was successful, but ...) (Ok, no big problem, running as UserProcess was working, but are there plans, to simulate the Win-ServiceControlmanager?) 2. Win-Authentication and -Impersonation (LogonUser- and ImpersonateLoggedOnUser-APIs - already mapped to...?) 3. "Global ServerSingletons" using ROT-Entries with FileMoniker-Binding 4. "RPCServer-internal Singletons" (CoMarshalInterThreadInterfaceInStream and CoGetInterfaceAndReleaseStream against the IUnknown-Interface). Any Ideas, especially for 3. and 4.?--> a good working X-Process-, respective X-Thread-Marshaling would be important, to take COM- Hosting under Linux/Wine seriously into account. My attempts, to get any useful information per WineDebug were not successful. It would be great, if anybody with more "Wine-Debugging-Experience" could look at the appropriate Calls using our free Server-Download. Thanks. Olaf Schmidt P.S. As Dan Kegel has recommended in 'wine.user', I will try to isolate the Problems 3. und 4. in separate Binaries and post a link later.

2 2

Re: gdi32: Fallback to StretchDIBits if the driver doesn't support BitBlt
by Alexandre Julliard 23 Feb '06

23 Feb '06

Huw D M Davies <h.davies1(a)physics.ox.ac.uk> writes: > + if ((dcSrc = DC_GetDCUpdate( hdcSrc ))) > + { > + dcDst = DC_GetDCPtr( hdcDst ); > + TRACE("hdcSrc=%p %d,%d -> hdcDest=%p %d,%d %dx%d rop=%06lx\n", > + hdcSrc, xSrc, ySrc, hdcDst, xDst, yDst, width, height, rop); > + > ret = dcDst->funcs->pBitBlt( dcDst->physDev, xDst, yDst, width, height, > dcSrc ? dcSrc->physDev : NULL, xSrc, ySrc, rop ); This is wrong, dcSrc doesn't always need to be valid for BitBlt. -- Alexandre Julliard julliard(a)winehq.org

1 0

comm & Win98
by Eric Pouech 23 Feb '06

23 Feb '06

could someone with a Win98 box test the attached test (it's a diff to dlls/kernel/tests/comm.c) ? the test passes on XP, I want to be sure it does as well on Win9x before I remove the offending code TIA -- Eric Pouech

2 1

Re: [MSI 5/5] Fix Stack Buffer Overflow in MSI_ProcessMessage
by Alexandre Julliard 22 Feb '06

22 Feb '06

Robert Shearman <rob(a)codeweavers.com> writes: > ChangeLog: > Fix a theoretical stack buffer overflow if the number was greater than > one digit. Then the buffer should be larger, silently truncating the number is not that much better than a stack overflow. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: WineFile: [PATCH] Implement part of Save Settings to registry
by Detlef Riekenberg 22 Feb '06

22 Feb '06

Am Montag, den 20.02.2006, 12:57 -0500 schrieb Jason Green: > > This patch adds the ability to save your window position to the > > registry when using winefile. > +static const WCHAR registry_key[] = { 'S','o','f','t','w','a','r','e','\\', >+ 'W','i','n','e','\\','W','i','n','e','F','i','l','e','\0'}; Native winfile uses winfile.ini on win9x and this is mapped to the registry in WinNT. (IniFileMapping does not work in wine yet http://www.microsoft.com/resources/documentation/windowsnt/4/workstation/re… ). Can we make the settings compatible? +static windowOptions load_registry_settings() +{ + windowOptions opts; + + return opts; +} BANG. You used a struct on the stack. That Memory is not valid after the return. Use a pointer to the your struct as Parameter: ...(windowOptions * opts) -- By By ... ... Detlef

1 0

Re: OLEAUT32: Fix regression in OLEFontImpl_Clone
by Alex Villacís Lasso 22 Feb '06

22 Feb '06

Alex Villacís Lasso wrote: > Lately, all VB6 applications crash on exit. This weekend, I found the > cause. Apparently the VB6 runtime creates a standard OLEFont object, > and then calls IFont::clone() on it to get a second object. At exit, > the VB6 runtime disposes of both objects. However, the recent OLEFont > changes introduced a bug in which the cloning fails to clone the > connection points associated with the object. Therefore the dispose of > one of the objects frees the connection points, and the dispose of the > second object crashes on attempt to dispose an already-freed object. > > Changelog: > > * Create new empty connection points on clone of OLEFont > > Alex Villacís Lasso > ------------------------------------------------------------------------ > > --- wine-0.9.8-cvs/dlls/oleaut32/olefont.c 2006-02-14 10:38:35.000000000 -0500 > +++ wine-0.9.8-cvs-patch/dlls/oleaut32/olefont.c 2006-02-18 18:40:01.000000000 -0500 > @@ -1113,6 +1113,19 @@ > /* The cloned object starts with a reference count of 1 */ > newObject->ref = 1; > > + /* We need to clone the connection points too. */ > + /* FIXME: should we just add a reference to the (shared) connection points? */ > + newObject->pPropertyNotifyCP = NULL; > + newObject->pFontEventsCP = NULL; > + CreateConnectionPoint((IUnknown*)newObject, &IID_IPropertyNotifySink, &newObject->pPropertyNotifyCP); > + CreateConnectionPoint((IUnknown*)newObject, &IID_IFontEventsDisp, &newObject->pFontEventsCP); > + > + if (!newObject->pPropertyNotifyCP || !newObject->pFontEventsCP) > + { > + OLEFontImpl_Destroy(newObject); > + return E_OUTOFMEMORY; > + } > + > *ppfont = (IFont*)newObject; > > return S_OK; > > Is there anything wrong with this patch? Not applied, and nobody has commented on it either. Alex Villacís Lasso

1 0

WineD3D / D3D8 color format issues
by Roderick Colenbrander 22 Feb '06

22 Feb '06

Hi, Today I tested Max Payne which uses D3D8. Before I started the D3D8 -> WineD3D transistion the game worked fine. Right now it doesn't work correct anymore when you let the game use 16bit textures in its setup menu. Right now all textures are missing. The problem appears to be a glTexImage2D call in wined3d's LoadTexture (surface.c) which results in a 'invalid operation'. Similar code worked fine before the d3d8 transition. After analysing the functions it appears that in 16bit the game wants to use D3DFORMAT_R5G6B5. In case of d3d8 this is translated into GL_RGB while in case of wined3d GL_BGR is used. (Oliver changed it at some stage, he changed other formats too claiming those were incorrect but no more explanation than that) I'm using the latest nvidia drivers and the GL_EXT_BGRA extension is present so in theory GL_BGR should work but for some reason. (Perhaps it is a driver bug as I found similar issues on google regarding both the drivers from ati and nvidia. I wasn't able to find a solution) If I change GL_BGR into GL_RGB I don't get an invalid operation and the game works fine (the textures look well too). According to MSDN the format is just the internal format. Someone in #winehackers told me that Windows prefers BGR because it is more efficient. The format is for internal use and second the opengl driver does the conversion for us anyway. http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c… What shall I do, just change the behaviour back to GL_RGB which works? Second the issue likely appears for some other formats which Oliver changed. Regards, Roderick

2 1