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

Error handling in RpcBindingVectorFree (dlls/rpcrt4/rpc_binding.c)
by Gerald Pfeifer Nov. 22, 2020

Nov. 22, 2020

Looking at RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector ) { RPC_STATUS status; ULONG c; TRACE("(%p)\n", BindingVector); for (c=0; c<(*BindingVector)->Count; c++) { status = RpcBindingFree(&(*BindingVector)->BindingH[c]); } HeapFree(GetProcessHeap(), 0, *BindingVector); *BindingVector = NULL; return RPC_S_OK; } we currently always ignore the outcome of RpcBindingFree and return RPC_S_OK. However, there is one case where RpcBindingFree returns something different (which is if *Binding is null when RPC_S_INVALID_BINDING is returned). What is the proper way of handling this? Just keeping the code as is and removing the unused status variable? Breaking the loop once RpcBindingFree returns something different from RPC_S_OK? Continuing and returning the first / the last status different from RPC_S_OK? Gerald

1 1

ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
by Qian Hong Sept. 28, 2018

Sept. 28, 2018

Dear all, While test another online bank with wine ActiveX, I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces, I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup, so I can't understand this log: wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 0022), starting debugger... Grateful for any explain! env: wine1.3.12 on Ubuntu 10.04 Here are the steps: 1. install an ActiveX from https://e.bank.ecitic.com/perbank5/plugs/CNCBSecPkg_EN.exe $ rm -rf ~/.wine $ winetricks -q mfc42 $ wine CNCBSecPkg_EN.exe fixme:ole:DllRegisterServer stub fixme:win:DisableProcessWindowsGhosting : stub fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:ole:CoCreateInstance no instance created for interface {ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf} of class {56fdf344-fd6d-11d0-958a-006097c9a090}, hres is 0x80004002 fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program Files\\\4e2d\4fe1\94f6\884c\7f51\94f6\5b89\5168\63a7\4ef6\\unins000.exe") stub fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 -1: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 002b), starting debugger... wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting 2. open the online bank entry with wine builtin IE, then IE will crash: $ wine iexplore https://e.bank.ecitic.com/perbank5/signIn.do Please checkout the full log here: http://pastebin.com/rbAg7gwj Should I file a singel bug in ntoskrnl component , or separate bugs, one for ntoskrnl and one for the IE crashing? Generalliy what component should I switch while file a bug about IE crashing? Many thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

5 6

ODBC Databases: Jet/Access success
by Barry Bird June 14, 2018

June 14, 2018

Good Afternoon. In section 3.3.6.2 of your User Guide you ask readers to report successes with databases other than MS SQL. Well here's one (I know Access 2000 can work with Wine, but this doesn't require Access): How to set up Wine to enable Windows programs that read and write to Jet (Access) databases using ODBC. I write such programs in C and use the API defined in ODBC API Reference http://msdn.microsoft.com/en-us/library/ms714562%28VS.85%29.aspx They work fine on Windows and only require Mingw to be installed to compile and link them, both for console programs and those using Windows SDK. You then can write interactive programs in C which use a full-featured SQL database which comes bundled with Windows. No need to purchase Access. With the set-up below they will also run on Linux (Kubuntu 9.04) and Wine 1.1.26. You need to update the registry to install the Access drivers. Under Windows, export from the Registry to *.reg files the registry entries - HKLM\Software\ODBC - HKLM\Software\Microsoft\Jet all subsidiary keys and values come with them. You can carefully edit these files to remove drivers and DSNs you don't need. Import these files using the registry editor in wine: wine regedit.exe. You need to bring across from Windows to Windows\System32 under wine: clbcatq.dll comres.dll expsrv.dll msjet40.dll mswstr10.dll msjter40.dll msjint40.dll msjtes40.dll msrd3x40.dll odbc32.dll odbccp32.dll odbcji32.dll odbcjt32.dll odbcad32.exe odbcint.dll odbctrac.dll vbajet32.dll Register this server in wine: wine regsvr32.exe msjtes40.dll No need to install MDAC. To use Windows ODBC drivers, you have to override Wine's odbccp32.dll and odbc32.dll with the native versions because the Wine versions are currently wired directly to Linux's unixodbc. This can be done by setting up the ODBC Data Source Administrator odbcad32.exe using winecfg: - Add the program to the Applications tab - then in the libraries tab, pick from 'New override for library' drop-down odbc32.dll and odbccp32.dll add them and edit them to be Native for Windows. Then if you do wine odbcad32.exe this brings up the ODBC Data Source Administrator window as in the Windows Control Panel If needed, set up (System) DSNs using this program. Bring across the programs and *.mdb database files from Windows. Using winecfg, you need to set up each program you want to run with overrides for odbc32.dll and odbccp32.dll (Applications and Libraries tabs) as above. The programs should then run as they did in Windows but perhaps a bit slower with: wine Odbc-prog.exe This has been tested twice on a clean .wine install. I cannot vouch for support of all API and SQL facilities however. I hope someone finds this useful. Barry Bird

5 4

IMM / IME work
by Aric Stewart June 16, 2016

June 16, 2016

Hello all, I know this will only interest a small portion of you but thought i would give a quick update on the state of IMM32 since I have brought it to a major milestone. All the main patches are in which now separate IMM32 and IMEs. There is still more work to do but the major framework is in place. X11 XIM processing should be unchanged. However wine can now begin to load native windows IMEs as well. I have tested with windows ATOK20 (a popular Japanese IME) and successfully had text processing in a fully IME aware application. There are still clear issues to resolve in many aspects of this processing but we have forward progress. ImmInstallIME does not work yet, nor does switching keyboards. So to get the native IME to work you need to add this registry key. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\<keyboard layout>] "Ime File"=<IME filename> so for example for ATOK20 in Japanese i used. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\e0010411] "Ime File"="ATOK20W.IME" I would love to hear how well things work. I am sure using native IMEs will quickly show us many places where IMM32 needs to be improved. One issues I am going to investigate next is that sometimes non x11drv ime initialization, if occurring too early, causes x11drv to fail to create windows. I have not investigated with the latest changes to xim.c (which may already correct this problem) but if you see this problem this patch may help and i believe the IME_UpdateAssociation(NULL) is already unneeded. diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c index d4df9f7..0c98136 100644 --- a/dlls/winex11.drv/xim.c +++ b/dlls/winex11.drv/xim.c @@ -475,7 +475,6 @@ static void X11DRV_OpenIM(Display *display, XPointer ptr, XP XUnregisterIMInstantiateCallback(display, NULL, NULL, NULL, X11DRV_OpenIM, wine_tsx11_unlock(); IME_XIMPresent(TRUE); - IME_UpdateAssociation(NULL); } thanks, -aric

5 7

Re: XInput [1/4]: Implement XInputGetState
by Stefan Dösinger July 5, 2015

July 5, 2015

Am 09.07.2009 um 02:58 schrieb Michael Gruber: > This patch series implements parts of the XInput library. You can use > this to play games that support Xbox 360 Controllers. To be able to > use this you will need to have your Controller working on Linux via > the xpad kernel driver and the event interface. It will not work on > any OS other than Linux. It supports gamepads, should work with > guitars and wheels, but will not work with dance-mats. > <1-XInputGetState.patch> Is it possible to implement XInput on top of DirectInput? DirectInput already has some internal abstraction layers for differnet joystick APIs, and has basic support for OSX joysticks. Does DInput have enough capabilities to access all the Xbox controller's features? My gut says no, otherwise MS wouldn't have created a new lib. I guess its worth checking though.

5 6

Wine 64 bit
by Kevin Davies June 5, 2015

June 5, 2015

Hello, Where would you find information on wine64 status for running 64 bit windows software under OSX. These days a lot of Windows programs are going 64bit to make use of the available memory. Its becoming necessary to have this capability. Many thanks Kevin

13 31

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.
by Alexandre Julliard April 23, 2015

April 23, 2015

Qian Hong <qhong(a)codeweavers.com> writes: > --- > dlls/user32/tests/winstation.c | 57 > ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 57 insertions(+) Can you please fix the test failures introduced by your previous changes first? cf. https://test.winehq.org/data/tests/user32:winstation.html -- Alexandre Julliard julliard(a)winehq.org

3 8

[RFC 0/11] Linux FF: Intro
by Elias Vanderstuyft Sept. 7, 2014

Sept. 7, 2014

Hi, This is the sequel of the mail with title: "Discussion and Improvement of Wine's Linux Force Feedback implementation". This mail is meant to give an introduction to the next 11 mails: All tests were performed using wine-1.7.11-206-g82b3813 (but none of the files of which I propose changes to be made in, are affected in the current (2014-03-04) wine-version 1.7.13) Because I haven't created any (formal) patch yet (and instead first request for comments), I tried to keep the line numbers to reference the affected files more or less based to the version I started from, where I could. However, the orig code of a (informal) patch that has to be applied after (and thus is dependent of) a previous patch, may be different from the initial code of the wine-version I started from. After having discussed everything, I will send a proper patchset. In these mails, sometimes 'FEdit' is mentioned: it's a MS application that allows to create all FF effect types (except CustomForce and rumble/vibration effects), and therefore the ideal test application. Physical behavior is compared between Windows7 (using Logitech MOMO wheel with latest drivers installed) running in Virtualbox, and my patched Wine-version. In the end, (using a dummy FF driver on the Linux side, thanks to Michal Malý), the behavior of Wine is almost (limitations caused by the dummy ff driver, such as updating an effect while playing is not implemented) identical, if not better (in some aspects) then the Windows equivalent. Sometimes I refer to linux-input mailing lists to prove a statement, because the links may vanish (unlikely though), I provide the titles corresponding with the links: (http://www.mail-archive.com/linux-input(a)vger.kernel.org/msg08513.html) "ff-core effect id handling in case of a failed effect upload" (http://www.mail-archive.com/linux-input(a)vger.kernel.org/msg08459.html) "Questions about the documentation/specification of Linux ForceFeedback input.h" Subjects [11] ------------- - Joystick control panel program [2] - Linux effect status management [3] - Linux effect parameter: start delay [1] - Linux effect parameter: periodic effect's phase [1] - Linux effect parameters: time parameters [3] - Linux effect: conditional effect's parameters [2] - Linux effect: axes [1] - Linux effect direction [7] - Linux effect parameters (global) [6] - Linux joystick initialization [1] - Debug message fixes/additions [6] Elias

2 3

Re: configure: Add -linotify when present, for non-Linux platforms.
by Alexandre Julliard Aug. 23, 2014

Aug. 23, 2014

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > A FreeBSD user ran into this when sys/inotify.h was present via an > extra package and Wine went ahead using that, only to fail at link- > time. We'd want to use kqueue instead on FreeBSD. -- Alexandre Julliard julliard(a)winehq.org

2 1

What happened to the Fedora packages?
by Neal Gompa Aug. 2, 2014

Aug. 2, 2014

What happened to the Fedora packages? They have not been updated since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro supported has the up to date packages!!! And why does the Red Hat packages site not go to the SourceForge site as it does for SUSE packages and the others?? I have not really had the guts to ask until now, because I thought that maybe there was a slump, but now, its getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! Please tell me new packages will be ready soon!!! Compiling WINE always crashes my computer, so I prefer to use the RPMs...

10 18

Fix for PlgBlt, the XFORM matrix was calculated incorrectly
by Alexander Almaleh June 16, 2014

June 16, 2014

I had tried to submit a patch for that 5 years ago<http://www.winehq.org/pipermail/wine-devel/2009-December/080391.html>, but couldn't figure out how to make a patch/test it, and eventually gave up and forgot about it. But recently I remembered about it, and now I want to try again. So, this time I've prepared a test that can prove that the previous implementation does not calculate the XFORM matrix correctly, and that my patch will fix it. The test is a VC6 project, you can find it at https://drive.google.com/file/d/0B9PGUhmmnsm1S2VvZzc3WmhBY3c/edit?usp=shari…. The test is a demo of PlgBlt that I found on CodeProject<http://www.codeproject.com/Articles/17712/The-GDI-magic-Rendering-reflectio…>. You can compare how it works on XP and on Wine. For testing, I directly inserted the original Wine implementation of PlgBlt, as well as my patched version, into the VC6 project, and tested on that. This is because there seems to be an additional problem with MaskBlt, which I'll try tackling next. I have screenshots of what the demo looks using Windows's PlgBlt<http://imgur.com/q8qKGd7>, and Wine's PlgBlt <http://imgur.com/smYEV6z>. To test it, simply look at this function in the VC6 project: BOOL MyPlgBlt( HDC hdcDest, const POINT *lpPoint, HDC hdcSrc, INT nXSrc, INT nYSrc, INT nWidth, INT nHeight, HBITMAP hbmMask, INT xMask, INT yMask) { // return MyPlgBltWinePatched(hdcDest, lpPoint, hdcSrc, nXSrc, nYSrc, nWidth, nHeight, hbmMask, xMask, yMask); return MyPlgBltWineUnpatched(hdcDest, lpPoint, hdcSrc, nXSrc, nYSrc, nWidth, nHeight, hbmMask, xMask, yMask); // return PlgBlt(hdcDest, lpPoint, hdcSrc, nXSrc, nYSrc, nWidth, nHeight, hbmMask, xMask, yMask); } Uncomment the function you want to test. If you need something else (like binaries), just write. And this is the patch itself. I've tried to keep the changes minimal, with respect to white-space, etc. I've removed a "return FALSE", because I don't calculate a determinant explicitly. commit c9ca2cab58fa0cba3d6b24cfb2af507fd1c07227 Author: Alexander Almaleh <sashoalm(a)gmail.com> Date: Tue May 20 18:33:55 2014 +0300 Fix for the calculation of the XFORM matrix in PlgBlt. diff --git a/dlls/gdi32/bitblt.c b/dlls/gdi32/bitblt.c index 4750d1b..1de25b9 100644 --- a/dlls/gdi32/bitblt.c +++ b/dlls/gdi32/bitblt.c @@ -992,22 +992,32 @@ BOOL WINAPI PlgBlt( HDC hdcDest, const POINT *lpPoint, HDC hdcSrc, INT nXSrc, INT nYSrc, INT nWidth, INT nHeight, HBITMAP hbmMask, INT xMask, INT yMask) { + /* we need to use floating-point precision when calculating the + * XFORM matrix to avoid loss of precision due to rounding */ + typedef struct tagPOINTLF + { + double x, y; + } POINTLF; + int oldgMode; /* parallelogram coords */ - POINT plg[3]; + POINTLF plg[3]; /* rect coords */ - POINT rect[3]; + POINTLF rect[3]; XFORM xf; XFORM SrcXf; XFORM oldDestXf; - double det; + int ii; /* save actual mode, set GM_ADVANCED */ oldgMode = SetGraphicsMode(hdcDest,GM_ADVANCED); if (oldgMode == 0) return FALSE; - memcpy(plg,lpPoint,sizeof(POINT)*3); + for (ii = 0; ii < 3; ii++) { + plg[ii].x = lpPoint[ii].x; + plg[ii].y = lpPoint[ii].y; + } rect[0].x = nXSrc; rect[0].y = nYSrc; rect[1].x = nXSrc + nWidth; @@ -1015,33 +1025,39 @@ BOOL WINAPI PlgBlt( HDC hdcDest, const POINT *lpPoint, rect[2].x = nXSrc; rect[2].y = nYSrc + nHeight; /* calc XFORM matrix to transform hdcDest -> hdcSrc (parallelogram to rectangle) */ - /* determinant */ - det = rect[1].x*(rect[2].y - rect[0].y) - rect[2].x*(rect[1].y - rect[0].y) - rect[0].x*(rect[2].y - rect[1].y); - - if (fabs(det) < 1e-5) - { - SetGraphicsMode(hdcDest,oldgMode); - return FALSE; - } TRACE("hdcSrc=%p %d,%d,%dx%d -> hdcDest=%p %d,%d,%d,%d,%d,%d\n", hdcSrc, nXSrc, nYSrc, nWidth, nHeight, hdcDest, plg[0].x, plg[0].y, plg[1].x, plg[1].y, plg[2].x, plg[2].y); /* X components */ - xf.eM11 = (plg[1].x*(rect[2].y - rect[0].y) - plg[2].x*(rect[1].y - rect[0].y) - plg[0].x*(rect[2].y - rect[1].y)) / det; - xf.eM21 = (rect[1].x*(plg[2].x - plg[0].x) - rect[2].x*(plg[1].x - plg[0].x) - rect[0].x*(plg[2].x - plg[1].x)) / det; - xf.eDx = (rect[0].x*(rect[1].y*plg[2].x - rect[2].y*plg[1].x) - - rect[1].x*(rect[0].y*plg[2].x - rect[2].y*plg[0].x) + - rect[2].x*(rect[0].y*plg[1].x - rect[1].y*plg[0].x) - ) / det; + xf.eM11 = -(rect[1].y*plg[2].x+rect[0].y*(plg[1].x-plg[2].x) + -rect[2].y*plg[1].x+plg[0].x*(rect[2].y-rect[1].y)) + /(rect[0].y*(rect[2].x-rect[1].x)-rect[1].y*rect[2].x+ + rect[2].y*rect[1].x+(rect[1].y-rect[2].y)*rect[0].x); + xf.eM21 = (plg[0].x*(rect[2].x-rect[1].x)-plg[1].x*rect[2].x + +plg[2].x*rect[1].x+(plg[1].x-plg[2].x)*rect[0].x) + /(rect[0].y*(rect[2].x-rect[1].x)-rect[1].y*rect[2].x + +rect[2].y*rect[1].x+(rect[1].y-rect[2].y)*rect[0].x); + xf.eDx = -(rect[0].y*(plg[2].x*rect[1].x-plg[1].x*rect[2].x) + +plg[0].x*(rect[1].y*rect[2].x-rect[2].y*rect[1].x) + +(rect[2].y*plg[1].x-rect[1].y*plg[2].x)*rect[0].x) + /(rect[0].y*(rect[2].x-rect[1].x)-rect[1].y*rect[2].x+rect[2].y + *rect[1].x+(rect[1].y-rect[2].y)*rect[0].x); /* Y components */ - xf.eM12 = (plg[1].y*(rect[2].y - rect[0].y) - plg[2].y*(rect[1].y - rect[0].y) - plg[0].y*(rect[2].y - rect[1].y)) / det; - xf.eM22 = (plg[1].x*(rect[2].y - rect[0].y) - plg[2].x*(rect[1].y - rect[0].y) - plg[0].x*(rect[2].y - rect[1].y)) / det; - xf.eDy = (rect[0].x*(rect[1].y*plg[2].y - rect[2].y*plg[1].y) - - rect[1].x*(rect[0].y*plg[2].y - rect[2].y*plg[0].y) + - rect[2].x*(rect[0].y*plg[1].y - rect[1].y*plg[0].y) - ) / det; + xf.eM12 = -(rect[1].y*(plg[2].y-plg[0].y)+rect[0].y*(plg[1].y + -plg[2].y)+rect[2].y*(plg[0].y-plg[1].y))/(rect[0].y*(rect[2].x + -rect[1].x)-rect[1].y*rect[2].x+rect[2].y*rect[1].x+(rect[1].y + -rect[2].y)*rect[0].x); + xf.eM22 = ((plg[0].y-plg[1].y)*rect[2].x+(plg[2].y-plg[0].y)*rect[1].x + +(plg[1].y-plg[2].y)*rect[0].x) /(rect[0].y*(rect[2].x-rect[1].x) + -rect[1].y*rect[2].x+rect[2].y*rect[1].x+(rect[1].y-rect[2].y) + *rect[0].x); + xf.eDy = (rect[0].y*(plg[1].y*rect[2].x-plg[2].y*rect[1].x) + -rect[1].y*plg[0].y*rect[2].x+rect[2].y*plg[0].y*rect[1].x + +(rect[1].y*plg[2].y-rect[2].y*plg[1].y)*rect[0].x)/(rect[0].y + *(rect[2].x-rect[1].x)-rect[1].y*rect[2].x+rect[2].y*rect[1].x + +(rect[1].y-rect[2].y)*rect[0].x); GetWorldTransform(hdcSrc,&SrcXf); CombineTransform(&xf,&xf,&SrcXf);

4 10

Re: wined3d: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4 (try 4)
by Stefan Dösinger June 11, 2014

June 11, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-30 00:45, schrieb Andrei Slăvoiu: > Add back glsl check to make sure the card is capable of DX10. > > --- dlls/wined3d/directx.c | 4 +++- 1 file changed, 3 > insertions(+), 1 deletion(-) Looks good to me. Note that Alexandre and Henri are on holidays right now, so it might take a while before it is committed or you receive further comments. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTiD0QAAoJEN0/YqbEcdMwcjcP/jAOsNo8MoM8sSlc2RVtU7Y5 tHVmUyMZ0xPSa7DaA13GFT7/hPnRXimRY39epjJ3subulmprkXV+HNtaHWBVkEvR lB+YSJJDFGJ9V81o7aVSUfXydeY81C3TB6TbztO9WtVPSVaE9/ZXJ1ZO3edufoXT XhXMJwce9HmL8nU+SRFo+mAc/FLimCuTwMMf6OF61KlAMTkzGSQoh8sUSwO0hndL /+yARXxgYhBAtepVb2vuL7411/VWlbzrD8S8h4sZhEnCgLNuyGjXFyggjTZn+MWd zYf5MgBWmY/YJu1VES3lkM8VM5FpgJgEcM3DG8BEQ3yI5eyBLReMiKQe3uuyhlnJ KdE9tSPP3Ts2gHYeZ90kGImebtjy5sxA0gsekY5J4oNsbDUfO01OoHde+54GG6WD 25aogs1+edJNZMGI6pxScDl6EoPgbTlBjL5dJ2xDYc1P/ACezNqPBe+tCDoqoVon WBlqNSNntcfCUBEoiXpOcRFK0PeJDIMHRKpZEBM63V3gFW6w0KuI+Sj0JcwFxy+u saLOwXDpaGerhar2njWiCEKwM1NfW2Wj7wcY0/eiy56bi9UvhDCAUqqZ98xlFZuP m8Js4Bwzlp7NHQjaqXo/h3uK36B0OngHZkjRm/hXMEFuQHfCSbKtUMZLn27JI+3a chXJiqk95eUes6GLKzGo =tusS -----END PGP SIGNATURE-----

3 2

Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4
by Stefan Dösinger June 3, 2014

June 3, 2014

Am 23.05.2014 um 00:23 schrieb Andrei Slăvoiu <andrei.slavoiu(a)gmail.com>: > Mesa drivers do not expose EXT_GPU_SHADER4 as all functionality it offers is > already part of OpenGL 3.0. This causes all cards that are not explicitly > recognized by wine (for example all GCN cards) to be treated as DX9 cards and > presented to Windows apps as Radeon 9500. The problem is that without GL_EXT_gpu_shader4 or GL_ARB_shader_texture_lod we cannot handle the texldd instruction. Right now we cannot use core contexts, so unless the driver exposes one of those extensions in compatibility contexts we are stuck on a shader model 2 feature level :-( . The level detection your patch changes isn't directly related to this, as the shader model version support is controlled differently. But a Radeon 9500 matches a card with shader model 2 support much better than a Radeon R9. Does this driver / gpu combination support GL_ARB_shader_texture_lod?

3 9

Re: ntdll: Use lockfree implementation for get_cached_fd.
by Ken Thomases June 2, 2014

June 2, 2014

On May 31, 2014, at 10:28 AM, Sebastian Lackner wrote: > Explanation: The basic idea of this patch is that we have a global > counter 'fd_cache_epoch' which is incremented, whenever the file > descriptor cache is updated. get_cached_fd() first reads the counter, > then the fd entry, and afterwards the counter again - if the counter has > changed we know that a second thread has maybe modified the content, and > have to read it again. The memory barrier is there to ensure that > compilers don't optimize away the two reads of 'fd_cache_epoch'. Please > note that: > > * the order of the write instructions when updating the content is > important - this way we ensure that threads only see either (0, *) = not > set, or a valid entry. > > * I assume that reading/writing up to the pointer size can be done as an > atomic operation (threads either see the old or new value, but no > partial updates). This assumption is also used in a lot other parts of > wine, for example here: > http://source.winehq.org/source/dlls/ntdll/sync.c#L1295 > [ It would probably be more safe to introduce special > interlocked_get/interlocked_set macros/functions for that, but not sure > what other people think about that... ] Thanks for working on this. Interesting stuff. I think there are still some issues. In order to ensure a consistent view of the ordering of memory operations, memory barriers have to be used in both the writer and the reader. The writer issues a write barrier after it has written and the reader issues a read barrier before it reads. The appropriate barriers are implicit in interlocked_xchg_add() for incrementing fd_cache_epoch, but the first read of it in get_cached_fd() has no read barrier before it. I think this is benign, though, because I think this can only result in the code thinking the epoch changed when it hasn't. It may retry unnecessarily. More problematic is the writing of the fd and its attributes. There are barriers implicit in the interlocked_xchg() which clears the fd, but there's no write barrier after the final write to it. There's no read barrier before the first read of them. You mention the order of writing, attributes first then fd, as being important. But there's no barrier in between the two operations, so either the compiler or the CPU could reorder either the writes or the reads, thwarting your design. The compiler can also reorder the reading of the fd_cache_epoch with respect to the reading of the fd or attributes. I think you can get this as the effective sequence: thread1 / get_cached_fd / read fd, get old fd thread2 / add_fd_to_cache / clear fd thread2 / add_fd_to_cache / increment epoch thread2 / add_fd_to_cache / set fd thread1 / get_cached_fd / read epoch thread1 / get_cached_fd / check if epoch has changed, conclude it hasn't thread1 / get_cached_fd / return old fd I think it's sufficient to have a write barrier after writing the fd and then a read barrier just before reading it. I _think_ that this obviates the need for the barrier at the bottom of the do-while loop. That is, you can just move that barrier up a line. I'm not 100% confident of my analysis of that. (Well, frankly, I'm never 100% certain of my analysis of this sort of code.) In the email thread regarding Daniel Horn's patch, I suggested an approach using interlocked_cmpxchg() to check if the fd had changed after reading the attributes. Was there a reason you rejected that approach? You mentioned an approach you experimented with using interlocked_cmpxchg64(). What was that about? Were you treating the fd and attributes combined as a single 64-bit value and then checking them both? Was that safer than my suggestion for some reason? If the only advantage is a slight performance improvement (especially in light of the huge difference that either approach has to the status quo, judging by your chart), then I'd argue for the simpler approach that's more easily analyzed for correctness. If the above issue is addressed, that leaves one remaining problem: get_cached_fd() can encounter a false negative: thread1 / add_fd_to_cache / set fd to -1 thread1 / add_fd_to_cache / increment epoch thread2 / get_cached_fd / read epoch thread2 / get_cached_fd / read attributes thread2 / get_cached_fd / read fd, gets -1 thread2 / get_cached_fd / check if epoch has changed, conclude it hasn't thread1 / add_fd_to_cache / set attributes thread1 / add_fd_to_cache / set fd thread2 / get_cached_fd / return -1 thread2 / server_get_unix_fd / see get_cached_fd as having failed since it returns -1 thread2 / server_get_unix_fd / do get_handle_fd server request thread2 / server_get_unix_fd / call add_fd_to_cache to cache the new fd I think you want to try get_cached_fd() again, inside the critical section, if the first call fails. -Ken

2 2

Video memory size detection in D3D
by Ruslan Kabatsayev June 2, 2014

June 2, 2014

Hello all, It seems Wine doesn't use any way to reliably detect video memory size, and for many video cards needs it to be specified as HKCU\Software\Wine\Direct3D\VideoMemorySize key in registry. But there exist at least three (vendor-specific) GL/GLX extensions which seem to address exactly this. Namely, for Mesa it's GLX_MESA_query_renderer [1], for nVidia it's GL_NVX_gpu_memory_info [2], and for ATI/AMD it's GL_ATI_meminfo [3]. Mesa extension is shipping starting from Mesa 10.0, nVidia ships their extension in 195.XX drivers (said in specification; I have it exposed with my 313.09 driver), don't know status of ATI extension though (marked as "???" in spec). It'd be good if Wine could utilize these. Is there any work towards this already? Regards, Ruslan [1]: http://www.opengl.org/registry/specs/MESA/glx_query_renderer.txt [2]: https://www.opengl.org/registry/specs/NVX/gpu_memory_info.txt [3]: http://www.opengl.org/registry/specs/ATI/meminfo.txt

5 6

Re: wined3d: Recognize cards that expose ARB_shader_texture_lod as DX10 capable even if they don't support EXT_gpu_shader4 (try 3)
by Stefan Dösinger June 2, 2014

June 2, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-29 01:33, schrieb Andrei Slăvoiu: > Drop the check for glsl_version. All wine shaders use #version 120 > so it doesn't matter. That's not quite right. Yes, it is true that we never use GLSL 130, so the version check isn't representative for what wined3d actually supports. For shader model 4 support we need much more than just GLSL 130, half of the d3d10 infrastructure is still missing. GL_ARB_shader_texture_lod doesn't imply shader model 4 support. My Radeon X1600 supports this extension on OSX, and this is a shader model 3 card. The X1600 doesn't support EXT_gpu_shader4 or GLSL 130. The point of this code is to check the capabilities of the card, not the capabilities of our d3d implementation. Thus to prevent SM 3 cards from being reported with PCI IDs that suggest SM 4 capabilities you need to check for all the other functionality that's supported by EXT_gpu_shader4 / GLSL 130. Even if we have a SM 4 capable card our d3d9 implementation does not expose SM 4 support. But neither does Microsoft's d3d9 implementation. There's also GLX_MESA_query_renderer. It gives us the PCI IDs and video memory size directly, without all the string parsing guesswork. We cannot use it wined3d directly. A possible approach would be to expose a similar WGL_WINE/MESA_query_renderer extension from winex11.drv and winemac.drv and use that in wined3d. The current wined3d guesswork code could be moved to winex11.drv and used in cases where GLX_MESA_query_renderer is not supported. (OSX has similar functionality that's always available) User32 also has a function (EnumDisplayDevices) to query the GPU identification string, and some applications (Company of Heroes demo) fail if the user32 GPU name differs from the d3d9 GPU name. So maybe a WGL extension isn't quite the right interface, and it should be something that does not require a GL context so user32.dll can use it as well. EnumDisplayDevices does not export all the information wined3d needs though - the PCI IDs and video memory size are missing I think. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJThvZZAAoJEN0/YqbEcdMwsY8QAJG1NQVMSqjwaguVR0cwwNXq IMYCRWL+5cJPxK4Eodt4bF+zZDObqCz9r3hAJVlkA6bJIcflNHJwedT0ddeOAfpe 0Xc8g+NvspN715yNt51PpzcnlSqh2vS18qp1JLb4l00pZuPt8PMNqC0gaePkv+tY 1wY3B/kgbl0TfcIRpxWbwZBcIAM2h4g+FGCHFPFeznhMYWqFaJ67OKW1KAdfpBTT lPZsaNDXtU8hSaVQYVk7ITulUl0C8tW/MExnh4zclz6b/wQuG+/M0WRg5v/YDlNq 0ZAsVqT60+MbepR87ehYDnLB7RMjZMjZhEZ4/drafFbOQBmqL7YJjgbFsbBBXLTt COf/1mjiz7TptUvSUyDRc27o1K+YP1UoswsVdXT37sWkP9gtHtQFeLLNx8ZuR4pa 2yQ7xNIBi7KPNBjz9Q0RKYvc11oGVUvFSuD0gLgNuHZxdOmBWwZyHeSce9adHHGU 5t4Oz0FsTZuEiiuJXPTDatp06KQQpUZ/c7FgcO7bxIpn/NNUCZGKZdKT/ZYM1waf BEtBL2Ov+DzRnvRM3/lVPdaiMD1IY54bqTeU7NOiKCEFhBl0elCAblj155tVaKdR 5WekiCEsvB8S4FE6stDa+GewpBWUZiVLGSL49S0MViPqAbkbgcjcNlRVg6IEH2Zo tyQIl6/9DwdY1TCllA9W =Z1W8 -----END PGP SIGNATURE-----

3 7

New Wine patches
by Chakke, Neha (GE Oil & Gas) June 2, 2014

June 2, 2014

Hello , I am trying to run a GE software and hardware on Debian (Linux platform) using WineHQ. In order to run the hardware we need to install device drivers for USB (Cypress) . http://wiki.winehq.org/USB I have been trying to look for some solutions online since a week. Could you kindly send me the new wine patches and please guide me with the procedure. Thanks and regards, Miss Neha Chakke Engineering/Technology GE Oil & Gas Measurement & Control T: +49 (0) 2233 601 123 neha.chakke(a)ge.com<mailto:neha.chakke(a)ge.com> www.ge-mcs.com<http://www.ge-mcs.com/> [NewMeatball] GE Sensing & Inspection Technologies GmbH Robert-Bosch-Str. 3 50354 Hürth Germany

3 2

Re: ntdll: Use lockfree implementation for get_cached_fd. (try 2)
by Ken Thomases June 1, 2014

June 1, 2014

On May 31, 2014, at 12:05 PM, Sebastian Lackner wrote: > Changes in try 2: > > * Always try to access the fd cache two times - this ensures that we > don't release a file descriptor when its still in use by a second thread. Heh. Well, you can ignore that part of my reply to your previous try. :) > * Replace interlocked_xchg() with an assert(). The original code looks > like its valid that the fd is nonzero at this point, but in fact this > would cause releasing a file descriptor which is still in use. I'll leave it to others to comment on that. > Replacing with an assert() also saves a couple of CPU cycles. I understand that this is an attempt to improve performance, but I don't think it's necessary to squeeze every last CPU cycle out of this code. -Ken

2 1

Re: ntdll/tests: Fix exception test failures on x86_64.
by Marvin May 31, 2014

May 31, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7354 Your paranoid android. === w2000pro (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 00950000/00950001 exception: unhandled exception 80000004 at 00950000 exception.c:406: Test failed: 42: Wrong exception address 7C5C20B0/00950001 === wxppro (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 00A30000/00A30001 exception: unhandled exception 80000004 at 00A30000 exception.c:406: Test failed: 42: Wrong exception address 7C80DF3C/00A30001 === wvistau64 (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 003D0000/003D0001 exception: unhandled exception 80000004 at 003D0000 exception.c:406: Test failed: 42: Wrong exception address 7751ED97/003D0001 === w2008s64 (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:406: Test failed: 42: Wrong exception address 77E5ED97/003C0001 === w7u (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:406: Test failed: 42: Wrong exception address 77CDE34F/003C0001 === w8 (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 00290000/00290001 exception: unhandled exception 80000004 at 00290000 exception.c:406: Test failed: 42: Wrong exception address 77174D17/00290001

1 0

Re: dmscript/tests: Test some IPersistStream methods of DMScriptTrack.
by Marvin May 30, 2014

May 30, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7339 Your paranoid android. === build (build) === Patch failed to apply

2 1

vs2013 support
by Daniel Lehman May 29, 2014

May 29, 2014

Is anyone already working on VS2013 support (msvcp120.dll)? or have plans to? Thanks daniel

1 0

Re: [2/2] ws2_32: Properly implement SO_CONNECT_TIME (try 2)
by Marvin May 28, 2014

May 28, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7316 Your paranoid android. === wvistau64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000 === w2008s64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000

1 0

Re: [2/2] ws2_32: Properly implement SO_CONNECT_TIME
by Marvin May 27, 2014

May 27, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7301 Your paranoid android. === w2000pro (32 bit sock) === sock: unhandled exception c0000005 at 00000000 === wvistau64 (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w2008s64 (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w7u (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w8 (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === wvistau64 (64 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w2008s64 (64 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0

1 0

About wineserver and winsock
by Bruno Jesus May 27, 2014

May 27, 2014

Hi all, after studying the ws2_32 dll code for some time while looking for ways to optimize it I started wondering why is the wineserver required (please don't stop reading yet). make test takes 45 seconds in my machine while it takes 25 seconds in a XP VM running on the same machine. The culprit is test_send() [1] which takes 24 seconds in wine and 1.8 seconds in windows. This long time is related to the 1 million recv() calls in test_send(). Each call to recv() has to call wineserver to do a enable_event(FD_READ) operation, if you comment that line out [2] wine magically takes 1.7 seconds, just like windows does (obviously commenting that line generaters other errors related to event sequences). So, in simple words: what if we move all wineserver socket code to a thread that is started in the ws2_32 DLL. I know this may sound very silly for the experienced wine developers, maybe some operations are impossible without the wineserver, maybe there is much more things affected, but I think it's better to ask and get crushed with (hopefully) constructive criticism than forget about the idea. My main objective with this is to speedup the whole implementation and properly implement the select call (different socket states result in different checks required) and WSACleanup call (which needs to close every open socket on last cleanup) and some other get/setsockopt stuff. [1] http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ws2_32/tests/sock.c#l… [2] http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ws2_32/socket.c#l6684 Best wishes, Bruno

5 4

Re: [PATCH 2/2] propsys: Forward exported calls to corresponding methods
by Jacek Caban May 27, 2014

May 27, 2014

Hi Nikolay, On 05/27/14 11:09, Nikolay Sivov wrote: > From 386a536f9ae75505cd95601e4a8ca936b826658c Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <nsivov(a)codeweavers.com> > Date: Mon, 26 May 2014 22:38:35 +0400 > Subject: [PATCH 2/2] propsys: Forward exported calls to corresponding methods It seems to me that forwarding the other way be more logical. Jacek

1 0

Re: [PATCH 2/2] shell32: Improve checking for folder index validity in NameSpace()
by Marvin May 27, 2014

May 27, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7279 Your paranoid android. === w2000pro (32 bit shelldispatch) === shelldispatch.c:94: Test failed: got 00000001 shelldispatch: unhandled exception c0000005 at 0040EB1D

1 0

Re: [PATCH] vbscript: Implemented CDbl(try 2)
by Marvin May 26, 2014

May 26, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7277 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: mshtml: Added IHTMLTableRow::insertCell method implementation. (try 3)
by Jacek Caban May 26, 2014

May 26, 2014

Hi Zhenbo, This version looks good except: On 05/24/14 11:56, Zhenbo Li wrote: > + *row = (IDispatch *)&elem->IHTMLElement_iface; > + IDispatch_AddRef(*row); > + IHTMLElement_Release(&elem->IHTMLElement_iface); You don't need to add such AddRef()/Release() calls. Reference count doesn't change anyway. Cheers, Jacek

1 0

Re: Japanese translation updates (try 4) for 1.7.19.
by Akihiro Sagawa May 25, 2014

May 25, 2014

On Wed, 21 May 2014 12:09:30 -0400 (EDT), Toshiaki Hirose wrote: > From 16832fa3d12785db591144f2005f953dd8937b9f Mon Sep 17 00:00:00 2001 > Message-Id: <16832fa3d12785db591144f2005f953dd8937b9f.1400688520.git.t_hirose(a)aol.com> > From: Toshiaki Hirose <t_hirose(a)aol.com> > Date: Thu, 22 May 2014 01:08:29 +0900 > Subject: [PATCH] Japanese translation updates(try4) for 1.7.19 > > --- > po/ja.po | 159 ++++++++++++++++++++++++++------------------------------------- > 1 file changed, 65 insertions(+), 94 deletions(-) Looks good to me. Akihiro Sagawa

2 1

Re: shell32: Fix SHFileOperation when deleting a nonexistent directory. (try 2)
by Zhenbo Li May 24, 2014

May 24, 2014

Excuse me, could someone have a look with this patch? Thank you. 2014-05-21 9:23 GMT+08:00 Zhenbo Li <litimetal(a)gmail.com>: > Thanks Alexandre > > try 2: > 1. Let SHELL_DeleteDirectoryW return DWORD > 2. Get the right return value by > ret = SHNotifyRemoveDirectoryW(pszDir) > origin: > Thanks Bruno Jesus > This patch would fix bug 34324, by returning correct > error value of SHFileOperation. > > --- > dlls/shell32/shlfileop.c | 55 > +++++++++++++++++++++--------------------- > dlls/shell32/tests/shlfileop.c | 4 --- > 2 files changed, 27 insertions(+), 32 deletions(-) > > -- Have a nice day! Zhenbo Li

1 0

Re: dpnet: Stub interface IDirectPlay8LobbyClient (try 4)
by Stefan Dösinger May 23, 2014

May 23, 2014

Am 21.05.2014 um 08:23 schrieb Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > Moved to be client.c. > Flags are printed as 0x%08x. You may want to move the test to tests/client.c as well. Otherwise this looks good to me.

1 0

Re: mshtml: Added IHTMLTableRow::insertCell method implementation. (try 2)
by Jacek Caban May 23, 2014

May 23, 2014

Hi Zhenbo, On 05/23/14 14:20, Zhenbo Li wrote: > iff --git a/dlls/mshtml/htmltablerow.c b/dlls/mshtml/htmltablerow.c > index 731b403..f1b672b 100644 > --- a/dlls/mshtml/htmltablerow.c > +++ b/dlls/mshtml/htmltablerow.c > @@ -308,8 +308,27 @@ static HRESULT WINAPI HTMLTableRow_get_cells(IHTMLTableRow *iface, IHTMLElementC > static HRESULT WINAPI HTMLTableRow_insertCell(IHTMLTableRow *iface, LONG index, IDispatch **row) > { > HTMLTableRow *This = impl_from_IHTMLTableRow(iface); > - FIXME("(%p)->(%d %p)\n", This, index, row); > - return E_NOTIMPL; > + nsIDOMHTMLElement *nselem; > + HTMLElement *elem = NULL; You shouldn't need to initialize it here. > + nsresult nsres; > + HRESULT hres; > + > + TRACE("(%p)->(%d %p)\n", This, index, row); > + nsres = nsIDOMHTMLTableRowElement_InsertCell(This->nsrow, index, &nselem); > + if(NS_FAILED(nsres)) { > + ERR("Insert Cell at %d failed: %08x\n", index, nsres); > + return E_FAIL; > + } > + > + hres = HTMLTableCell_Create(This->element.node.doc, nselem, &elem); > + if (FAILED(hres)) { > + ERR("Create TableCell failed: %08x\n", hres); > + return hres; > + } > + nsIDOMHTMLElement_Release(nselem); There it a leak in error case. Move Release call before if statement. > + > + hres = IHTMLElement_QueryInterface(&elem->IHTMLElement_iface, &IID_IDispatch, (void **)row); > + return hres; You don't need QueryInterface here. Cast is fine as long as it's done on an interface inheriting from IDispatch (but not on object, as you did in previous version of the patch). Cheers, Jacek

1 0

Re: (try 2) gdi32/tests: tmLastChar is solely governed by the last entry before 0xffff in the cmap.
by Marvin May 23, 2014

May 23, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7224 Your paranoid android. === w2000pro (32 bit font) === font.c:5077: Test failed: got 00a8 === wxppro (32 bit font) === font.c:5077: Test failed: got 00a8 === wvistau64 (32 bit font) === The test timed out === w2008s64 (32 bit font) === font.c:5077: Test failed: got 00a8 === w7u (32 bit font) === font.c:5077: Test failed: got 00a8 === w8 (32 bit font) === font.c:5077: Test failed: got 00a8 === wvistau64 (64 bit font) === font.c:5077: Test failed: got 00a8 === w2008s64 (64 bit font) === font.c:5077: Test failed: got 00a8

1 0

Re: [PATCH 3/3] vbscript: Fixed CInt
by Nikolay Sivov May 23, 2014

May 23, 2014

> - hres = to_int(arg, &val); > + V_VT(&v) = VT_EMPTY; > + hres = VariantChangeType(&v, arg, 0, VT_I2); > if(FAILED(hres)) > return hres; > > - return return_int(res, val); > + if(!res) { > + VariantClear(&v); > + return DISP_E_BADVARTYPE; > + } > + > + *res = v; > + return S_OK; I can't comment on removing to_int() here, I don't know this code well. But is it really possible to get a NULL 'res'? It looks like you can just use 'res' without intermediate 'v'. In any case you don't need VariantClear() on VT_I2 variant.

2 1

Re: [PATCH 3/3] vbscript: Fixed CInt
by Marvin May 22, 2014

May 22, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7223 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 2/3] vbscript: Implemented CLng
by Marvin May 22, 2014

May 22, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7222 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/3] vbscript: Implemented CDbl
by Marvin May 22, 2014

May 22, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7221 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Debugging wine with winedbg
by Alexander Almaleh May 21, 2014

May 21, 2014

I'm trying to debug Wine, and I want to step into the BitBlt function using winedbg. I've set a breakpoint at BitBlt, and it is being hit, however, when I list the source code, it points somewhere completely differently in the source. I have no idea why that is. Does it mean that Wine is not setup correctly for debugging? I cloned Wine from Git a few days ago, and I've used "./tools/wineinstall" to compile and install it. This is an excerpt of the debugging session. sashoalm(a)aspire:~$ winedbg /tmp/xformtest.exe WineDbg starting on pid 0022 start_process () at /home/sashoalm/Workspace/wine/wine-git/dlls/kernel32/process.c:1097 0x7b86235f start_process+0x5f [/home/sashoalm/Workspace/wine/wine-git/dlls/kernel32/process.c:1097] in kernel32: movl %edi,0x4(%esp) 1097 return call_process_entry( peb, entry ); Wine-dbg>break BitBlt fixme:dbghelp_dwarf:dwarf2_parse_subprogram Unhandled Tag type 0x1 at ctx(0x32bfec,L"gdi32<elf>"), for debug_info(abbrev:0x15f2148,symt:0x175a660) Breakpoint 1 at 0x7ebcac00 BitBlt in gdi32 Wine-dbg>cont Stopped on breakpoint 1 at 0x7ebcac00 BitBlt in gdi32 Wine-dbg>list 1097 return call_process_entry( peb, entry ); 1098 } 1099 1100 1101 /*********************************************************************** 1102 * set_process_name 1103 * 1104 * Change the process name in the ps output. 1105 */ 1106 static void set_process_name( int argc, char *argv[] ) 1107 { Wine-dbg>n copy_bitmap () at /home/sashoalm/Workspace/wine/wine-git/dlls/user32/cursoricon.c:382 382 DeleteDC( dst );

1 1

Vacations
by Alexandre Julliard May 21, 2014

May 21, 2014

Folks, I'll be away for the next two weeks, though I may still push some commits if I can get decent Internet. I'm also going to skip next week's release, so 1.7.20 should happen on June 13. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] add function iphlpapi/CreateSortedAddressPairs, FreeMibTable
by Bruno Jesus May 21, 2014

May 21, 2014

This patch is just a hack, I'll send a correct stub later. On Wed, May 21, 2014 at 8:10 AM, Akira Nakagawa <matyapiro31(a)gmail.com> wrote: > -- universe* god::bigbang (void); //and then it all began...

2 1

Re: [patch]japanese translation updates for 1.7.19.
by Akihiro Sagawa May 21, 2014

May 21, 2014

On Tue, 20 May 2014 13:38:12 -0400 (EDT), Toshiaki Hirose wrote: > po/ja.po | 159 ++++++++++++++++++++++++++------------------------------------- > 1 file changed, 65 insertions(+), 94 deletions(-) Hi, Hirose-san, I just figure out two points. Following msgid line introduces unnecessary changes. > #: oleacc.rc:97 > -#, fuzzy > -#| msgid "Normal" > msgctxt "object state" > -msgid "normal" > -msgstr "標準" > +msgid "normal" > +msgstr "normal" This change might be unintentional because other oleacc resources aren't translated yet. If you adopt this translation, please remove redundant "(&R)". > #: oleacc.rc:104 > -#, fuzzy > -#| msgid "&Read Only" > msgctxt "object state" > msgid "read only" > msgstr "読み取り専用(&R)" Otherwise looks fairly good. Regards, Akihiro Sagawa

1 0

Re: [1/2] ws2_32: Avoid memory allocation for simple sends
by Austin English May 21, 2014

May 21, 2014

On Mon, May 19, 2014 at 2:16 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > send() will ever use a single wsabuffer structure and most common > applications use of WSASend() will also send a single buffer. Saves > over 6 thousand calls to HeapAlloc in make test. > In (very non-scientific) timing runs, these two patches reduced valgrind test time by ~20% (5 vs 4 minutes), thanks! -- -Austin

2 1

Re: [PATCH 1/2] riched20: Implement ITextSelection::GetText.
by Nikolay Sivov May 21, 2014

May 21, 2014

> +HRESULT ME_ITextGetText(ME_TextEditor *editor, ME_Cursor *start, ME_Cursor *end, BSTR *pb) DECLSPEC_HIDDEN; Is this really needed? > + buffer = heap_alloc((nChars + 1) * sizeof(WCHAR)); > + if (!buffer) > + return E_OUTOFMEMORY; > + ME_GetTextW(editor, buffer, nChars, start, nChars, 0); > + buffer[nChars] = 0; > + /* FIXME: a '\r' should be appended at the end of a story */ > + *pb = SysAllocString(buffer); > + heap_free(buffer); This could be simplified with SysAllocStringLen().

2 3

BitBlt doesn't honor the rotation specified by SetWorldTransform
by Alexander Almaleh May 21, 2014

May 21, 2014

I have a test program that shows how BitBlt does not support rotation, when the rotation is specified by SetWorldTransform. Interestinly, the Rectangle() function works correctly and the rectangle is rotated. Here's a screenshot of the program in VirtualBox and in Wine<http://imgur.com/TIYx7XU> . Here is the code of the program. I'm setting a rotation XFORM, and then calling BitBlt. I load a bitmap file from the current directory for the BitBlt. hdc = BeginPaint(hWnd, &ps); double angle = 0.385398163; XFORM xf; xf.eDx = 0; xf.eDy = 0; xf.eM11 = cos(angle); xf.eM12 = sin(angle); xf.eM21 = -sin(angle); xf.eM22 = cos(angle); SetGraphicsMode(hdc, GM_ADVANCED); SetWorldTransform(hdc, &xf); HBITMAP hbmp = (HBITMAP) LoadImage( NULL, L"a.bmp", IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE); HDC hmemdc = CreateCompatibleDC(hdc); SelectObject(hmemdc, hbmp); BitBlt(hdc, 100, 0, 150, 50, hmemdc, 0, 0, SRCCOPY); EndPaint(hWnd, &ps);

1 0

Re: [PATCH 2/2] riched20: Implement ITextSelection::GetChar.
by Marvin May 21, 2014

May 21, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7197 Your paranoid android. === wvistau64 (64 bit richole) === richole: unhandled exception c0000005 at 000007FEF57FACFA === w2008s64 (64 bit richole) === richole: unhandled exception c0000005 at 000007FEF745ACFA

1 0

Re: [PATCH 1/2] riched20: Implement ITextSelection::GetText.
by Marvin May 21, 2014

May 21, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7196 Your paranoid android. === wvistau64 (64 bit richole) === richole: unhandled exception c0000005 at 000007FEF57FACFA === w2008s64 (64 bit richole) === richole: unhandled exception c0000005 at 000007FEF745ACFA

1 0

Re: mshtml: Added IHTMLTableRow::insertCell method implementation.
by Zhenbo Li May 20, 2014

May 20, 2014

Sorry, I've found that this patch may have some problems. Please ignore that, and I'll send a fixed one later. 2014-05-21 9:45 GMT+08:00 Zhenbo Li <litimetal(a)gmail.com>: > --- > dlls/mshtml/htmltablerow.c | 26 ++++++++++++++++++++++++-- > dlls/mshtml/tests/dom.c | 7 +++++++ > 2 files changed, 31 insertions(+), 2 deletions(-) > > -- Have a nice day! Zhenbo Li

1 0

Re: shell32: Fix SHFileOperation when deleting a nonexistent directory. (try 2)
by Marvin May 20, 2014

May 20, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7194 Your paranoid android. === wvistau64 (32 bit shlfileop) === shlfileop.c:815: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR === wvistau64 (64 bit shlfileop) === shlfileop.c:815: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR

1 0

Re: [PATCH 1/2] wined3d: Set palettes on the swapchain (v2).
by Henri Verbeet May 20, 2014

May 20, 2014

On 20 May 2014 13:09, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -3372,7 +3301,7 @@ static BOOL color_in_range(const struct wined3d_color_key *color_key, DWORD colo > > void d3dfmt_p8_init_palette(const struct wined3d_surface *surface, BYTE table[256][4]) > { > - const struct wined3d_palette *pal = surface->palette; > + const struct wined3d_palette *pal = surface->swapchain ? surface->swapchain->palette : NULL; > unsigned int i; > > if (!pal) This function is a bit silly. I think all callers should be able to just use palette->colors[], and avoid the extra copy. I'd guess that if no palette is set on the swapchain it should use the system palette, but perhaps it's ok to leave that undefined for now. > @@ -619,6 +625,14 @@ void x11_copy_to_screen(const struct wined3d_swapchain *swapchain, const RECT *r > > TRACE("swapchain %p, rect %s.\n", swapchain, wine_dbgstr_rect(rect)); > > + if (swapchain->palette && (swapchain->palette != swapchain->last_gdi_blt_palette > + || swapchain->palette->changed)) > + { > + wined3d_palette_apply_to_dc(swapchain->palette, swapchain->front_buffer->hDC); > + swapchain->last_gdi_blt_palette = swapchain->palette; > + swapchain->palette->changed = FALSE; > + } > + > front = swapchain->front_buffer; > if (front->resource.map_count) > ERR("Trying to blit a mapped surface.\n"); This is problematic in wined3d, because you can have multiple swapchains using the same palette. In practice that never happens, but that depends on knowing about everything that calls wined3d. If you really need this kind of scheme you'd have to make "palette->changed" a counter, and then iterate over all swapchains on wrap, but couldn't you just create a GDI palette for the wined3d palette, and then select that into the DC for the blit? Or just always update the palette, which is pretty much what we do now in the GL case.

2 3

Can my WINE program write to files in /usr directory?
by John Found May 20, 2014

May 20, 2014

In my program I want to copy some files in the /usr and other system directories. Is it possible from WINE program and how? In the FAQ I read: >/!\ NEVER run Wine as root! Doing so gives Windows programs (and >viruses) full access to your computer and every piece of media >attached to it. Running with sudo also has these same risks but with >the added bonus of breaking the permissions on your ~/.wine folder >in the process. If you have run Wine with sudo you need to fix the >permission errors as described in the next question, and then run >winecfg to set Wine up again. You should always run Wine as the >normal user you use to login. Is it so important? -- asm32.info <johnfound(a)asm32.info>

4 7

Re: [PATCH] msxml3: removed unused allocation (Coverity)
by Marvin May 20, 2014

May 20, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7177 Your paranoid android. === w2008s64 (32 bit domdoc) === Unable to set the VM system time: the "nc -q0 '10.42.42.136' '4242'" command returned 1

1 0

Re: [2/2] server: Clear the queue's QS_SMRESULT bit when sending a new message.
by Alexandre Julliard May 19, 2014

May 19, 2014

Vincent Povirk <madewokherd(a)gmail.com> writes: > This keeps the QS_SMRESULT bit in sync with the reply status of the > most recent sent message, if it happens that the > previously-most-recent sent message already has a reply. > wait_message_reply depends on this to work correctly. I believe you'll also need to set it again when the result is removed. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 3/3] user32: Don't rely on HMENU for showing popups
by Alexandre Julliard May 19, 2014

May 19, 2014

Andrew Eikum <aeikum(a)codeweavers.com> writes: > The idea here is to push the conversions from HMENU to struct pointer > up the call stack until eventually we are only converting to/from > HMENUs near the client code border, so we don't depend on HMENU > internally at all. To do this right, you'd want to increase the refcount every time you get a pointer. Otherwise the pointer could become invalid as soon as control is transferred to the app through SendMessage (not that the current code always gets it right, but when using handles the problem is much reduced). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: vbscript: Support multibyte characters in Global_Chr
by Marvin May 19, 2014

May 19, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7147 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 2/2] mmdevapi: Clock rate should be in bytes for shared mode
by Marvin May 19, 2014

May 19, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7145 Your paranoid android. === w7u (32 bit render) === render.c:1976: Test failed: Got wrong volume: 0.501088 render.c:2005: Test failed: Got wrong volume: 0.501088 === w8 (32 bit render) === render.c:1976: Test failed: Got wrong volume: 0.671337 render.c:2005: Test failed: Got wrong volume: 0.671337

1 0

Re: [PATCH 1/2] mmdevapi: Make buffer size divisible by number of periods
by Marvin May 19, 2014

May 19, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7144 Your paranoid android. === w7u (32 bit render) === render.c:1976: Test failed: Got wrong volume: 0.501088 render.c:2005: Test failed: Got wrong volume: 0.501088 === w8 (32 bit render) === render.c:1976: Test failed: Got wrong volume: 0.671337 render.c:2005: Test failed: Got wrong volume: 0.671337

1 0

Re: [PATCH] vbscript: Implemented CCur
by Piotr Caban May 19, 2014

May 19, 2014

On 05/19/14 08:47, Shuai Meng wrote: > +Call ok(CCur(0.000149) = 0.0001, "CCur(0.000149) = " & CCur(0.000149)) > +Call ok(getVT(CCur(0.000149)) = "VT_CY", "getVT(CCur(0.000149)) = " & getVT(CCur(0.000149))) > +Call ok(CCur(2147483647.99) = 2147483647.99, "CCur(2147483647.99) = " & CCur(2147483647.99)) > +Call ok(getVT(CCur(2147483647.99)) = "VT_CY", "getVT(CCur(2147483647.99)) = " & getVT(CCur(2147483647.99))) This tests are failing on polish locale. > +Call ok(CCur(MyObject) = 0, "CCur(MyObject) = " & CCur(MyObject)) > +Call ok(getVT(CCur(MyObject)) = "VT_CY", "getVT(CCur(MyObject)) = " & getVT(CCur(MyObject))) > +MyObject.myval = 1 > +Call ok(CCur(MyObject) = 1, "CCur(MyObject) = " & CCur(MyObject)) > +Call ok(getVT(CCur(MyObject)) = "VT_CY", "getVT(CCur(MyObject)) = " & getVT(CCur(MyObject))) > +MyObject.myval = 0 > +Call ok(CCur(MyObject) = 0, "CCur(MyObject) = " & CCur(MyObject)) > +Call ok(getVT(CCur(MyObject)) = "VT_CY", "getVT(CCur(MyObject)) = " & getVT(CCur(MyObject))) There are two identical tests on MyObject. MyObject.myval is set to 0 in first test (it's set this way in earlier tests). Thanks, Piotr

2 2

Re: shell32: Fix SHFileOperation when deleting a nonexistent directory.
by Alexandre Julliard May 19, 2014

May 19, 2014

Zhenbo Li <litimetal(a)gmail.com> writes: > @@ -353,8 +353,13 @@ static BOOL SHELL_DeleteDirectoryW(HWND hwnd, LPCWSTR pszDir, BOOL bShowUI) > HANDLE hFind; > WIN32_FIND_DATAW wfd; > WCHAR szTemp[MAX_PATH]; > + DWORD attrib; > > /* Make sure the directory exists before eventually prompting the user */ > + attrib = GetFileAttributesW(pszDir); > + if (attrib == INVALID_FILE_ATTRIBUTES || !(attrib & FILE_ATTRIBUTE_DIRECTORY)) > + return FALSE; It would be better to avoid a redundant file lookup, particularly since it's only to set last error (which BTW you are not setting at all in the non-directory case). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [website] German translation for release 1.7.19
by Frédéric Delanoy May 19, 2014

May 19, 2014

On Sun, May 18, 2014 at 5:40 PM, Julian Rüger <jr98(a)gmx.net> wrote: > Hi Frédéric, > >> "writer" should probably be translated as well... > > I don't think there is a useful translation that is not clunky or sounds > awkward. Plus, "writer" is probably a familiar term to most users > because of i.e. LibreOffice Writer. LibreOffice Writer is an English product name, and maybe not known to non-techies (it's just a word processing application to them) IMHO. In German, it should probably be something like Redaktor, but you know German better than me ;-) Frédéric Delanoy

2 1

Re: msi: Prevent call to memset with a nullptr in get_tablecolumns function
by Hans Leidekker May 19, 2014

May 19, 2014

On Sun, 2014-05-18 at 13:27 -0400, Daniel Beitler wrote: > This is a fix for bug #36139. > > It looks like calling memset with a nullptr is undefined behavior. Gcc > 4.9 will actually optimize out the "if(colinfo)" condition if memset was > called on colinfo before. > > > --- > dlls/msi/table.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) Looks good, thanks.

1 0

Re: [patch]Japanese Translation update
by Akihiro Sagawa May 18, 2014

May 18, 2014

On Fri, 16 May 2014 10:08:47 -0400 (EDT), Toshiaki Hirose wrote: > From 67e0fca928a2f2de03adaf96f7a1f8f55e2cf85d Mon Sep 17 00:00:00 2001 > Message-Id: <67e0fca928a2f2de03adaf96f7a1f8f55e2cf85d.1400248197.git.t_hirose(a)aol.com> > From: Toshiaki Hirose <t_hirose(a)aol.com> > Date: Fri, 16 May 2014 22:49:46 +0900 > Subject: [PATCH] Japanese Translation Update for 1.7.18 > > --- > po/ja.po | 172 ++++++++++++++++++++++++--------------------------------------- > 1 file changed, 65 insertions(+), 107 deletions(-) Hello Hirose-san, Your translation is getting better, but it needs some more work. Could you read my comments and submit again? I also welcome your feedback. > #: oleacc.rc:97 > -#, fuzzy > #| msgid "Normal" > -msgctxt "object state" > msgid "normal" > -msgstr "標準" > +msgstr "normal" Msgctxt line can't be removed. The line indicates message context, and is used with msgid to specify translation. > #: oleacc.rc:98 > #: oleacc.rc:99 : : > #: oleacc.rc:128 Same as above. > #: regsvr32.rc:41 > msgid "" > "regsvr32: Invalid or unrecognized switch [%1]\n" > "\n" > msgstr "" > +"regsvr32: 無効または認識できない切り替えです[%1]\n" > +"\n" I'm not sure about this translation. This `switch' means `command-line switch'. In that case, we usually translate into `スイッチ'. For instance, see http://support.microsoft.com/kb/227091/ja vs http://support.microsoft.com/kb/227091/en-us . > #: regsvr32.rc:46 > msgid "regsvr32: Failed to unregister DLL '%1'\n" > -msgstr "" > +msgstr "regsvr32: DLL '%1'の登録消去に失敗しました。\n" You removed some full-stops, but didn't about this line. > #: regsvr32.rc:49 > msgid "regsvr32: Successfully installed DLL '%1'\n" > -msgstr "" > +msgstr "regsvr32: DLL '%1'のインストールに成功しました。\n" Ditto. Otherwise looks fine. Regards, Akihiro Sagawa

1 0

Re: [website] German translation for release 1.7.19
by André Hentschel May 18, 2014

May 18, 2014

Am 17.05.2014 02:10, schrieb Julian Rüger: > +<date>16. Main 2014</date> -n, everything else is fine ;)

3 2

msvcp90/msvcp90.h: right-hand operand of comma expression has no effect
by Gerald Pfeifer May 17, 2014

May 17, 2014

Building git head with GCC development sources (soon to be GCC 4.9.0) gives me the following warnings ../msvcp90/msvcp90.h:529:75: warning: right-hand operand of comma expression has no effect [-Wunused-value] ../msvcp90/msvcp90.h:530:77: warning: right-hand operand of comma expression has no effect [-Wunused-value] several times. Digging into this in more detail I see ../msvcp90/ios.c: In function 'basic_streambuf_char__Xsgetn_s': ../msvcp90/msvcp90.h:529:75: warning: right-hand operand of comma expression has no effect [-Wunused-value] #define memcpy_s( dst, size, src, count ) (memcpy( (dst), (src), (count) ), 0) ^ ../msvcp90/ios.c:1218:13: note: in expansion of macro 'memcpy_s' memcpy_s(ptr+copied, size, *this->prpos, chunk); ^ Someone must have written that code intentionally, so I am wondering how to best address this. Gerald

2 2

Re: shell32: Fix SHFileOperation when deleting a nonexistent directory.
by Marvin May 16, 2014

May 16, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6958 Your paranoid android. === wvistau64 (32 bit shlfileop) === shlfileop.c:815: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR === wvistau64 (64 bit shlfileop) === shlfileop.c:815: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR

2 2

Re: vbscript: Parse doubles with bigger precision in parse_numeric_literal
by Marvin May 16, 2014

May 16, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7112 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: gdi32/tests: tmLastChar is solely governed by the last entry before 0xffff in the cmap.
by Marvin May 16, 2014

May 16, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7109 Your paranoid android. === w2000pro (32 bit font) === font.c:5076: Test failed: got 00a8 === wxppro (32 bit font) === font.c:5076: Test failed: got 00a8 === wvistau64 (32 bit font) === The test timed out === w2008s64 (32 bit font) === font.c:5076: Test failed: got 00a8 === w7u (32 bit font) === font.c:5076: Test failed: got 00a8 === w8 (32 bit font) === font.c:5076: Test failed: got 00a8 === wvistau64 (64 bit font) === font.c:5076: Test failed: got 00a8 === w2008s64 (64 bit font) === font.c:5076: Test failed: got 00a8

3 2

Wine Test analysis, report
by Jeremy White May 16, 2014

May 16, 2014

Just wanted to report that I do periodically do my analysis. It looks as though the test bot is beginning to be usable again, although the results are currently ugly: http://www.winehq.org/~jwhite/fba08e34c447.html I'm waiting for Francois to report that things are essentially operational again; until I get that word, I'm not planning to beat the drum. Francois, can we get an update? Cheers, Jeremy

7 8

Re: audio reset failed
by Pawel Por May 16, 2014

May 16, 2014

>>* I receive periodically the following error popup window: *>>* "Audio Reset Failed: Access violation at address 7BC503AA in module *>>* 'ntdll.dll'. Write of address F818611C" * >What is displaying this message? Wine itself does not contain the >message "Audio Reset Failed." This message is from the application that generates text voice messages using SAPI4 voices. This application works perfectly under wine launched in 32 bit linux. >>* When it occurs the audio hangs up and only the restart of the wine *>>* application helps. * >There is a list of sound-related debug log channels at ><http://wiki.winehq.org/Sound>. Getting a debug log with those >channels set could give us a clue as to what's going wrong. I've upgraded wine to version wine 1.7.18 (Arch Linux). I still receive the message: "Audio Reset Failed: Access violation at address 7BC4D272 in module 'ntdll.dll'. Write of address F82A011C" This time I've run wine with the following debug channels: +tid,+mmdevapi,+winmm,+driver,+msacm,+midi,+dsound,+dsound3d,+dmusic,+mci,+oss,+alsa,+coreaudio. I've attached the log. Please write me if I can provide anything else. Great thanks for your help.

2 1

Re: mshtml: Added IHTMLLocation::assign method implementation.
by Nikolay Sivov May 16, 2014

May 16, 2014

> HTMLLocation *This = impl_from_IHTMLLocation(iface); > - FIXME("(%p)->(%s)\n", This, debugstr_w(bstr)); > - return E_NOTIMPL; > + TRACE("(%p)->(%s)\n", This, debugstr_w(bstr)); > + return HTMLLocation_put_href(iface, bstr); I don't know if it correct or not, but please use method wrappers when calling from interface pointer instead of calling implementation directly.

1 0

Re: dpnet: Stub interface IDirectPlay8LobbyClient (try 3)
by Alexandre Julliard May 16, 2014

May 16, 2014

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > diff --git a/dlls/dpnet/Makefile.in b/dlls/dpnet/Makefile.in > index 541e104..70ccef0 100644 > --- a/dlls/dpnet/Makefile.in > +++ b/dlls/dpnet/Makefile.in > @@ -7,6 +7,7 @@ C_SRCS = \ > client.c \ > dpnet_main.c \ > lobbiedapp.c \ > + lobbyclient.c \ > peer.c \ > server.c \ > threadpool.c Please merge that code into some existing files, we don't need so many new files. -- Alexandre Julliard julliard(a)winehq.org

4 4

Re: [PATCH 2/5] wined3d: Set palettes on the swapchain.
by Henri Verbeet May 16, 2014

May 16, 2014

On 15 May 2014 14:33, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/palette.c b/dlls/wined3d/palette.c > index 3f7e2ad..780f068 100644 > --- a/dlls/wined3d/palette.c > +++ b/dlls/wined3d/palette.c > @@ -136,8 +136,8 @@ HRESULT CDECL wined3d_palette_set_entries(struct wined3d_palette *palette, > if (resource->type == WINED3D_RTYPE_SURFACE) > { > struct wined3d_surface *surface = surface_from_resource(resource); > - if (surface->palette == palette) > - surface->surface_ops->surface_realize_palette(surface); > + if (surface->swapchain && surface->swapchain->palette == palette) > + surface->swapchain->swapchain_ops->swapchain_realize_palette(surface->swapchain); > } > } > I don't think this kind of thing should be needed. You should be able to make the palette texture that currently lives in the ARB program shader backend a property of the wined3d palette, and then presents can just make sure the palette texture is current. Something similar, if perhaps slightly more involved, should be possible for the GDI swapchain with GDI palettes.

2 3

Re: [PATCH 4/5] d2d1: Add the ID2D1RenderTarget interface.
by Jacek Caban May 16, 2014

May 16, 2014

Hi Henri, On 05/16/14 09:59, Henri Verbeet wrote: > diff --git a/dlls/d2d1/d2d1_main.c b/dlls/d2d1/d2d1_main.c > index 9a389a2..d1e5e8f 100644 > --- a/dlls/d2d1/d2d1_main.c > +++ b/dlls/d2d1/d2d1_main.c > @@ -21,6 +21,9 @@ > #include "wine/port.h" > #include "wine/debug.h" > > +#include "winbase.h" > +#include "winuser.h" > +#undef DrawText It's probably better to place such #undef in .idl file itself (inside cpp_quote). That's what we already do in quite a few places and it avoids the need for hacking every .c file using the header. Jacek

1 0

Re: mshtml: Fixed a few more IE11 test failures.
by Marvin May 15, 2014

May 15, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7098 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2861: Test failed: unexpected command 74 === w8 (32 bit htmldoc) === htmldoc.c:2861: Test failed: unexpected command 74 htmldoc.c:2861: Test failed: unexpected command 74

1 0

Re: audio reset failed
by Pawel Por May 15, 2014

May 15, 2014

> An HTML attachment was scrubbed... > URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20140513/8f5f34ee/at…> I've uploaded the wine log at (37 KB): http://www.sendspace.pl/en/file/294794be77c2a1703e60d94 thanks for your help

2 1

Re: [PATCH 7/7] oleacc: Add WindowFromAccessibleObject implementation
by Marvin May 15, 2014

May 15, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7083 Your paranoid android. === wxppro (32 bit main) === main.c:104: Test failed: GetRoleTextA returned not zero-length buffer : (t)

1 0

Re: oleacc: Add WindowFromAccessibleObject implementation
by Marvin May 15, 2014

May 15, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7084 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 6/7] oleacc: Add IOleWindow::GetWindow implementation in default client accessible object
by Marvin May 15, 2014

May 15, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7082 Your paranoid android. === wxppro (32 bit main) === main.c:104: Test failed: GetRoleTextA returned not zero-length buffer : (t)

1 0

Re: [PATCH 4/7] oleacc: Add IOleWindow interface stub to default client accessible object
by Marvin May 15, 2014

May 15, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7081 Your paranoid android. === wxppro (32 bit main) === main.c:104: Test failed: GetRoleTextA returned not zero-length buffer : (t)

1 0

Re: [PATCH 5/5] includes: Fix an in/out annotation in shobjidl.idl.
by Nikolay Sivov May 15, 2014

May 15, 2014

On 5/15/2014 16:33, Stefan Dösinger wrote: > --- > include/shobjidl.idl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/shobjidl.idl b/include/shobjidl.idl > index c9297a8..ae42c2e 100644 > --- a/include/shobjidl.idl > +++ b/include/shobjidl.idl > @@ -3350,7 +3350,7 @@ interface ITransferAdviseSink : IUnknown > HRESULT FileFailure([in] IShellItem *item, > [in, unique, string] LPCWSTR itemname, > [in] HRESULT hr, > - [out, unique, size_is(crename)] LPWSTR rename, > + [in, out, unique, size_is(crename)] LPWSTR rename, > [in] ULONG crename); > HRESULT SubStreamFailure([in] IShellItem *item, > [in, string] LPCWSTR stream, According to PSDK existing attributes are correct. Where did you find additional [in] ?

3 3

Re: [PATCH 3/7] oleacc: Disable tests on old oleacc
by Marvin May 15, 2014

May 15, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7080 Your paranoid android. === wxppro (32 bit main) === main.c:104: Test failed: GetRoleTextA returned not zero-length buffer : (t)

1 0

Re: [PATCH 2/7] oleacc: Don't return partial data in GetRoleTextA if buffer is too small
by Marvin May 15, 2014

May 15, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7079 Your paranoid android. === wxppro (32 bit main) === main.c:96: Test failed: GetRoleTextA returned not zero-length buffer : (t)

1 0

Re: [PATCH 4/4] xmllite/writer: Implement Flush() method
by Marvin May 15, 2014

May 15, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7075 Your paranoid android. === wvistau64 (32 bit writer) === writer.c:229: Test failed: got <?xml version="1.0"?>?> === w2008s64 (64 bit writer) === writer.c:229: Test failed: got <?xml version="1.0"?>ncoding="UT

1 0

Re: [PATCH 3/4] xmllite/writer: Initial support for starting a document
by Marvin May 15, 2014

May 15, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7074 Your paranoid android. === wvistau64 (32 bit writer) === writer.c:229: Test failed: got <?xml version="1.0"?>?> === w2008s64 (64 bit writer) === writer.c:229: Test failed: got <?xml version="1.0"?>ncoding="UT

1 0

Re: [PATCH 2/4] xmllite/writer: Initial support of output buffer creation
by Marvin May 15, 2014

May 15, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7073 Your paranoid android. === wvistau64 (32 bit writer) === writer.c:219: Test failed: got <?xml version="1.0"?>?> === w2008s64 (64 bit writer) === writer.c:219: Test failed: got <?xml version="1.0"?>ncoding="UT

1 0

Re: [PATCH 1/5] wined3d: Move get_dc palette updates to ddraw (v2).
by Henri Verbeet May 15, 2014

May 15, 2014

On 15 May 2014 14:33, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +void __cdecl wined3d_palette_apply_to_dc(const struct wined3d_palette *palette, HDC hdc); Can we avoid "Hungarian" in wined3d, please?

1 0

Re: dpnet: Stub interface IDirectPlay8LobbyClient (try 2)
by Stefan Dösinger May 15, 2014

May 15, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-14 06:46, schrieb Alistair Leslie-Hughes: > +#define COBJMACROS > +#include "windef.h" > +#include "winbase.h" > +#include "wingdi.h" > +#include "winuser.h" > +#include "objbase.h" > +#include "wine/debug.h" Another thing I did not notice before: Do you need them all? At least wingdi.h seems suspicious, I guess winuser.h shouldn't be needed either - unless dpnet pops up dialogs. > +static HRESULT WINAPI lobbyclient_QueryInterface(IDirectPlay8LobbyClient *iface, REFIID riid, void **ppobj) > ... > + IUnknown_AddRef(iface); > + *ppobj = This; IMO this should be *ppobj = &This->IDirectPlay8LobbyClient_iface. That way it doesn't break if someone uses > +static HRESULT WINAPI lobbyclient_EnumLocalPrograms(IDirectPlay8LobbyClient *iface, GUID* pGuidApplication, BYTE* pEnumData, DWORD* pdwEnumData, DWORD* pdwItems, DWORD flags) You de-hungarified flags, but not the others (pSomePointer, pdwSomePointerToADWord). There are many more cases in the other functions. > +static HRESULT WINAPI lobbyclient_ConnectApplication(IDirectPlay8LobbyClient *iface, DPL_CONNECT_INFO* pdplConnectionInfo, PVOID pvConnectionContext, DPNHANDLE* hApplication, DWORD dwTimeOut, DWORD flags) > +{ > + IDirectPlay8LobbyClientImpl *This = impl_from_IDirectPlay8LobbyClient(iface); > + > + FIXME("(%p)->(%p %p %p %d %x)\n", This, pdplConnectionInfo, pvConnectionContext, hApplication, dwTimeOut, flags); a DWORD is an unsigned value, it should use %u. This applies to dwTimeOut here, but there are other cases in other functions. > +static HRESULT WINAPI lobbyclient_SetConnectionSettings(IDirectPlay8LobbyClient *iface, DPNHANDLE hConnection, const DPL_CONNECTION_SETTINGS* pdplSessionInfo, DWORD flags) > +{ > + IDirectPlay8LobbyClientImpl *This = impl_from_IDirectPlay8LobbyClient(iface); > + > + FIXME("(%p)->(%d %p %x)\n", This, hConnection, pdplSessionInfo, flags); > + > + return E_NOTIMPL; > +} You might want a helper function that prints DPL_CONNECTION_SETTINGS at some point. I'm ok with adding this in a later patch. Don't forget to check for NULL before you print though. > + > + > +static const IDirectPlay8LobbyClientVtbl DirectPlay8LobbiedClient_Vtbl = > +{ Really minor nitpick: There's an extra newline. > +HRESULT DPNET_CreateDirectPlay8LobbyClient(IClassFactory *iface, IUnknown *outer, REFIID riid, void **obj) > +{ > + IDirectPlay8LobbyClientImpl *app; Why is it called "app"? > + HRESULT ret; > + > + TRACE("(%p, %s, %p)\n", outer, debugstr_guid(riid), obj); You forgot to print iface here. Is that intentional? > diff --git a/dlls/dpnet/tests/Makefile.in b/dlls/dpnet/tests/Makefile.in > index f6e45ea..5b97aa1 100644 > +#define WIN32_LEAN_AND_MEAN > +#include <stdio.h> Is this needed? I don't see a function call, but maybe I'm missing something +static HRESULT WINAPI DirectPlayLobbyMessageHandler(PVOID context, DWORD message_id, PVOID buffer) PJUNK There are more PJUNKs in this file. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTdIsTAAoJEN0/YqbEcdMwxkkQAJVt/Y/QT5MIj7VKXsOHwZLJ 2prBQIrzBCPZHxS8EyzEEI008kZ+M2hquPD5Eeinj5L69D4wV5sv6VIFBk2Gz40P SpJaCdE/Srjto+2MQAgRjJ1JMhNCKCWMGg/w+OBRtBs8JM63gHwQNk+ZUQpdl58B OdNpGPbj7Ynlqt+fENUOOxMrbHwToMU1BvgfBogVdWD1P2AnvlFuoRZxSoZuF9Kn 3kloiFs/hv266ZCof1ngrxVuc2uojHWdlev4t2bWYSNoXewIVVRzvtJEvJpveQjq bWzGFe6ZmIhmSJ+2nCnAhXpZjNAv2+o2bdUK1q7EAkUHHv8cb/rTJ+8yX7HiG0UD NxmAtM4EMwLOBRl2yOATR52Q47r195JFv/YOJUHPRW+wL8rIkE/FC6kk4h6zB9/r 5rwLNpWoqagdD9bSJ6LZneRoQzsJ+SMy+8FInnEfDpFZaHRPue4UPFoUNWHQd3f/ ruuIWcWwQwQ7msI8Nr2JgNstGNCO7d6XQfjvJDwqZUZwLihrxEiOa8fVfCRA54Lu hS3esozn+0oQWmSKPm9fw5OA4RIZGY2zLGf3mkFX9BLuBWmKCfxQ5t+1c0nv6Q/f ZSHjUSjem6aLtwq6+48gilS5MsbqsqDQXRE+rEBzFNzcJbQByyd+0yMiYckBajAp H7j+HVl6L6VSGTY9LrMu =S78r -----END PGP SIGNATURE-----

1 0

Support for DirectX 11
by Dyweni - Wine-Devel May 14, 2014

May 14, 2014

Hi, I'd like to know if anyone has an idea on when DirectX 11 would be completed, at least to a point of being able to play DirectX 11 only games? Thanks, Dyweni

1 0

Re: [PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 4)
by Henri Verbeet May 14, 2014

May 14, 2014

On 14 May 2014 16:12, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > --- > dlls/d3d9/tests/device.c | 133 ++++++++++++++++++++++++++++++++++++++--------- > 1 file changed, 107 insertions(+), 26 deletions(-) > Unfortunately this still fails for me on Windows. The returned counts change between runs, which could perhaps be related to the backbuffer size being larger than the window size. It does seem to reliably pass when either running the test in fullscreen mode, or changing the backbuffer size to e.g. 640x480. The former is probably the easier fix. > + ok(data.word[0] == (WORD)expected || broken(!data.word[0]), > + "Occlusion query returned an unexpected result (0x%.8x).\n", data.dword[0]); > + if (!data.word[0]) > + { > + skip("Occlusion query result looks broken, ignoring returned count.\n"); > + broken_occlusion = TRUE; > + } At 1024x768 for example, "expected" is going to be 0xc0000. Is this for drivers that always return 0 for occlusion queries, or is this for the testbot, which IIRC runs at the resolution? If it's really broken, I think this should also check for "(WORD)expected" being 0, and then use win_skip() instead of skip().

2 1

Re: oleaut32: Added debugstr_variant helper for better debug traces.
by Michael Stefaniuc May 14, 2014

May 14, 2014

Hello Jacek, On 05/14/2014 04:55 PM, Jacek Caban wrote: > > 0001-oleaut32-Added-debugstr_variant-helper-for-better-deb.diff wouldn't it be better to make debugstr_variant aka add it to include/wine/debug.h? VARIANTs are used in a lot more places then just oleaut32. > > > diff --git a/dlls/oleaut32/varformat.c b/dlls/oleaut32/varformat.c > index e72a170..0e1c370 100644 > --- a/dlls/oleaut32/varformat.c > +++ b/dlls/oleaut32/varformat.c > @@ -1201,9 +1201,8 @@ static HRESULT VARIANT_FormatNumber(LPVARIANT pVarIn, LPOLESTR lpszFormat, > const BYTE* pToken = NULL; > HRESULT hRes = S_OK; > > - TRACE("(%p->(%s%s),%s,%p,0x%08x,%p,0x%08x)\n", pVarIn, debugstr_VT(pVarIn), > - debugstr_VF(pVarIn), debugstr_w(lpszFormat), rgbTok, dwFlags, pbstrOut, > - lcid); > + TRACE("(%s,%s,%p,0x%08x,%p,0x%08x)\n", debugstr_variant(pVarIn), debugstr_w(lpszFormat), > + rgbTok, dwFlags, pbstrOut, lcid); bye michael

2 1

Re: [PATCH 3/3] oleacc: Add GetStateText implementation
by Nikolay Sivov May 14, 2014

May 14, 2014

> + ret = GetStateTextW(0, (WCHAR*)&ptr, 0); Why not use id symbols, instead of magic numbers?

2 1

RFC: "once" FIXME capability
by Erich E. Hoover May 14, 2014

May 14, 2014

While at LinuxTag Sebastian Lackner, Michael Müller, and I were chatting with Michael Stefaniuc and Anastasius Focht about the way we currently implement "one-time FIXME". It was discussed that a more global approach to this was desired, but that it should have the following characteristics: 1) It should work with ANSI C compilers (the variadic macro problem) 2) It should be something that we can disable with a debug channel (something AF would really appreciate that our current ad-hoc approach does not support) 3) It should be expandable to handling a "once per flag" capability Toward that end the three of us have put together several proposed "once" implementations. All three patch-sets are based on variations of the following trick to allow defining in-place static variables without any special compiler requirements: if(1) { \ static int __wine_debug_once = 0; \ int __wine_debug_once_temp = __wine_debug_once; \ if(!__wine_debug_once) __wine_debug_once = 1; \ if(__wine_debug_once_temp == 0) \ goto __WINE_LIMIT_LABEL(__LINE__); \ } else __WINE_LIMIT_LABEL(__LINE__): Here are the various approaches: 1) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_1.tgz This implementation is a macro (LIMIT_ONCE, LIMIT_FLAG_ONCE) that you would use to prefix a FIXME/WARN/etc. The feature can be disabled by enabling the "+nolimit" WINEDEBUG option (patch 3). 2) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_2.tgz This implementation builds onto the existing FIXME to add a FIXME_ONCE (and FIXME_FLAG_ONCE). The feature can be disabled by enabling the "+nolimit" WINEDEBUG option (patch 4). 3) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_3.tgz This implementation builds onto the existing FIXME to add a FIXME_ONCE (and FIXME_FLAG_ONCE). The feature can be disabled by enabling the "nolimit+<channel>" WINEDEBUG option (patch 4). This version benefits from the ability to turn off limiting on a per-channel basis, which should make it easier to track down problems when an unrelated debug channel is also spamming the console. We'd love to hear which approach everyone likes the most or any feedback you might have. Best, Erich

2 1

Re: [PATCH 4/5] d2d1: Add the ID2D1Bitmap interface.
by Nikolay Sivov May 14, 2014

May 14, 2014

On 5/14/2014 09:56, Henri Verbeet wrote: > +[ > + local, > + object, > + uuid(a2296057-ea42-4099-983b-539fb6505426) > +] > +interface ID2D1Bitmap : ID2D1Image > +{ > + D2D1_SIZE_F GetSize(); > + D2D1_SIZE_U GetPixelSize(); > + D2D1_PIXEL_FORMAT GetPixelFormat(); > + void GetDpi( > + [out] float *dpi_x, > + [out] float *dpi_y > + ); > + HRESULT CopyFromBitmap( > + [in, optional] const D2D1_POINT_2U *dst_point, > + [in] ID2D1Bitmap *bitmap, > + [in, optional] const D2D1_RECT_U *src_rect > + ); > + HRESULT CopyFromRenderTarget( > + [in, optional] const D2D1_POINT_2U *dst_point, > + [in] ID2D1RenderTarget *render_target, > + [in, optional] const D2D1_RECT_U *src_rect > + ); > + HRESULT CopyFromMemory( > + [in, optional] const D2D1_RECT_U *dst_rect, > + [in] const void *src_data, > + [in] UINT32 pitch > + ); > +} > + > I don't think it makes sense to match msdn here regarding [optional] attribute, and that's why: - 'optional' without 'defaultvalue' has no effect on headers, as far as I can see; - you can't mix 'optional' with required arguments like that, midl will refuse to process such idl, optional arguments should be at the end of arguments list only; - msdn says that it only applies to VARIANT and VARIANT* types, not sure about that, probably it's meant to talk about typelib generation only. And we don't need a typelib for d2d1 anyway. It makes sense imo to eventually make widl more midl-compliant adding similar consistency checks, like 'optional' position, also duplicated guids in typelibs come to mind. It's up to you to keep it as it is, just pointing out potential problems.

3 6

Re: [user32] add a dde test for OEM CP
by Marvin May 13, 2014

May 13, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=7029 Your paranoid android. === w2000pro (32 bit dde) === dde.c:1797: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 6 dde.c:1820: Test failed: DdeQueryStringA returned wrong string String dde.c:1831: Test failed: DdeQueryStringA returned wrong length 6 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === wxppro (32 bit dde) === dde.c:1797: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1820: Test failed: DdeQueryStringA returned wrong string ?" dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === wvistau64 (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w2008s64 (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w7u (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w8 (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === wvistau64 (64 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w2008s64 (64 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom

1 0

Re: oleacc: Add GetStateText implementation (try3)
by Alexandre Julliard May 13, 2014

May 13, 2014

Piotr Caban <piotr(a)codeweavers.com> writes: > +UINT WINAPI GetStateTextW(DWORD state_bit, WCHAR *state_str, UINT state_str_len) > +{ > + DWORD state_id; > + > + TRACE("%x %p %u\n", state_bit, state_str, state_str_len); > + > + state_id = IDS_STATE_MIN; > + while(state_bit) { > + state_id++; > + state_bit /= 2; > + } > + > + if(state_id>=IDS_STATE_MIN && state_id<=IDS_STATE_MAX) { > + UINT ret; > + > + if(state_str) { > + ret = LoadStringW(oleacc_handle, state_id, state_str, state_str_len); > + }else { > + WCHAR tmp; > + ret = LoadStringW(oleacc_handle, state_id, &tmp, 0); > + } > + > + if(!ret && state_str && state_str_len) > + state_str[0] = 0; > + return ret; > + } The id range check doesn't seem very useful. Also it would be worth testing that a 0 length is supposed to return the string pointer the way LoadString does. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] ntdll: Pad the FILE_*_DIRECTORY_INFORMATION with zero bytes
by Alexandre Julliard May 13, 2014

May 13, 2014

Martin Storsjo <martin(a)martin.st> writes: > Instead of memcpying in whatever uninitialized data there was at > the end of long_nameW, memset the tail of the struct to zero > instead. > > This fixes running cl.exe from MSVC 2013 with native > msvcr120/msvcp120, fixing bug 35335. > > MSVC 2013 (or msvcr120?) seems to use NtQueryDirectoryFile to > iterate through the headers in directories in the include path, > and prior to this change, the file names found during iteration > could get a suffix consisting of an uninitialized WCHAR. That doesn't make much sense, given that there may not be space for a final null, and that your patch doesn't clear the right location anyway. It looks like more investigation is needed. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 3/5] wined3d: Always store the palette index in the alpha component.
by Henri Verbeet May 13, 2014

May 13, 2014

On 12 May 2014 15:12, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -1458,8 +1457,7 @@ static void surface_download_data(struct wined3d_surface *surface, const struct > int src_pitch = 0; > int dst_pitch = 0; > > - /* In case of P8 the index is stored in the alpha component if the primary render target uses P8. */ > - if (format->id == WINED3DFMT_P8_UINT && swapchain_is_p8(surface->resource.device->swapchains[0])) > + if (format->id == WINED3DFMT_P8_UINT) > { > gl_format = GL_ALPHA; > gl_type = GL_UNSIGNED_BYTE; This branch is pretty pointless, the format / type for WINED3DFMT_P8_UINT is always GL_ALPHA / GL_UNSIGNED_BYTE. (If ARB_fragment_program is supported, and the format is supported at all anyway.) > @@ -3256,53 +3252,19 @@ static void read_from_framebuffer(struct wined3d_surface *surface, DWORD dst_loc > switch (surface->resource.format->id) > { > case WINED3DFMT_P8_UINT: > - { > - if (swapchain_is_p8(context->swapchain)) > - { > - /* In case of P8 render targets the index is stored in the alpha component */ > - fmt = GL_ALPHA; > - type = GL_UNSIGNED_BYTE; > - mem = data.addr; > - bpp = surface->resource.format->byte_count; > - } > - else > - { > - /* GL can't return palettized data, so read ARGB pixels into a > - * separate block of memory and convert them into palettized format > - * in software. Slow, but if the app means to use palettized render > - * targets and locks it... > - * > - * Use GL_RGB, GL_UNSIGNED_BYTE to read the surface for performance reasons > - * Don't use GL_BGR as in the WINED3DFMT_R8G8B8 case, instead watch out > - * for the color channels when palettizing the colors. > - */ > - fmt = GL_RGB; > - type = GL_UNSIGNED_BYTE; > - pitch *= 3; > - mem = HeapAlloc(GetProcessHeap(), 0, surface->resource.size * 3); > - if (!mem) > - { > - ERR("Out of memory\n"); > - return; > - } > - bpp = surface->resource.format->byte_count * 3; > - } > - } > - break; > + fmt = GL_ALPHA; > + type = GL_UNSIGNED_BYTE; > + break; > > default: > - mem = data.addr; > fmt = surface->resource.format->glFormat; > type = surface->resource.format->glType; > - bpp = surface->resource.format->byte_count; > } Like above. > if (!srcIsUpsideDown) > { > - UINT len; > /* glReadPixels returns the image upside down, and there is no way to prevent this. > - Flip the lines in software */ > - len = surface->resource.width * bpp; > + * Flip the lines in software. > + * TODO: Consider flipping the image in an FBO. */ Possibly, but that would be a decision for surface_load_sysmem(), not read_from_framebuffer(). Note that reading the front buffer isn't particularly fast on Windows either though. > + row = HeapAlloc(GetProcessHeap(), 0, pitch); > + goto error; This looks unintentional. > @@ -3088,38 +3088,7 @@ DWORD wined3d_format_convert_from_float(const struct wined3d_surface *surface, c > } > > if (format->id == WINED3DFMT_P8_UINT) > - { > - const RGBQUAD *e; > - BYTE r, g, b, a; > - > - if (!surface->palette) > - { > - WARN("Surface doesn't have a palette, returning 0.\n"); > - return 0; > - } > - > - r = (BYTE)((color->r * 255.0f) + 0.5f); > - g = (BYTE)((color->g * 255.0f) + 0.5f); > - b = (BYTE)((color->b * 255.0f) + 0.5f); > - a = (BYTE)((color->a * 255.0f) + 0.5f); > - > - e = &surface->palette->colors[a]; > - if (e->rgbRed == r && e->rgbGreen == g && e->rgbBlue == b) > - return a; > - > - WARN("Alpha didn't match index, searching full palette.\n"); > - > - for (i = 0; i < 256; ++i) > - { > - e = &surface->palette->colors[i]; > - if (e->rgbRed == r && e->rgbGreen == g && e->rgbBlue == b) > - return i; > - } > - > - FIXME("Unable to convert color to palette index.\n"); > - > - return 0; > - } > + return (BYTE)((color->a * 255.0f) + 0.5f); So this could just use the table now, right?

2 3

Re: dpnet: Stub interface IDirectPlay8LobbyClient
by Stefan Dösinger May 13, 2014

May 13, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-13 02:04, schrieb Alistair Leslie-Hughes: > @@ -127,6 +127,7 @@ extern HRESULT DPNET_CreateDirectPlay8Peer(LPCLASSFACTORY iface, LPUNKNOWN punkO > extern HRESULT DPNET_CreateDirectPlay8Address(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; > extern HRESULT DPNET_CreateDirectPlay8LobbiedApp(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; > extern HRESULT DPNET_CreateDirectPlay8ThreadPool(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; > +extern HRESULT DPNET_CreateDirectPlay8LobbyClient(IClassFactory *iface, IUnknown *pUnkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; If you don't use LPJUNK for the iface and UnkOuter (yay :-) ), you might also do it for LPVOID. > +static HRESULT WINAPI lobbyclient_Initialize(IDirectPlay8LobbyClient *iface, PVOID pvUserContext, PFNDPNMESSAGEHANDLER pfn, DWORD dwFlags) No Hungarian notation please (dwFlags, pThisIsAPointer). Also, (L)PJUNK again. > + app = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IDirectPlay8LobbyClientImpl)); > + if (NULL == app) { > + *ppobj = NULL; > + return E_OUTOFMEMORY; > + } Style inconsistency with the rest of the patch. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTcddPAAoJEN0/YqbEcdMwu2oP/iKSBrRhn/4PoGRTAE6hHQsd 4qwWb7WNS+mczHW+ucVfBogFvPkecpUauHWMpEyND3mYp8kli/2BDqtQrovcvabK h5QRqrP3ToRyIm6VMgaijMx4WlrjsZKHKKzW7/k8TxBTAs25OOaBAUC8ihK1A65s lQVywsqPPHuq4u8LzFjr4xE8s5UyZy5tCPYyDFym0otbiRX9+MQJjztFtC3wd8si Fznv681ZTrpR5m3qvcrMn1Eo2mKFvM1Wbi7W58uO2QTEH6BRiMlfd3A/fqVbhCdZ jiYdcDgUSWugOxIoWtaJNzU/mh3oChyPe+WWFXNoPy5W0/wrJHXUbssAW/s5bX1p wRO6rqmbf27rGCFp57oimJMxb/QJT0o+sU2ZdYHv2hjAX7U1csGU6Z3bUQ/KYLlG AztBJBVkTbe9aoIKhsZx/ISHIQ5GYJyY8KntqBOadrziu/I0kzX0ONtDfTdFzkne RhBSXUFjlKxxm17hXyOEftMsD1tkMn74fChJzFOJUo6v3thkH1IcbMhqwNLvj6++ Om2bO4M5Lw77u/9jR84WpFWUh4wUUqgs+v1/VPpt07QTIhwAERU3CiMt1wlkZFvB cyiWm+a3q/GekR1gyyku31bbkqInDRZENDkRl3FXWS/t1Om38j2JgB45mCMEFKCq HoNMnRF44iY4XWaXwd5M =3BFT -----END PGP SIGNATURE-----

1 0

Re: [PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 3)
by Henri Verbeet May 12, 2014

May 12, 2014

On 12 May 2014 17:45, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > --- > dlls/d3d9/tests/device.c | 119 ++++++++++++++++++++++++++++++++++++++--------- > 1 file changed, 96 insertions(+), 23 deletions(-) > This fails here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so device && touch device.ok ... device.c:4609: Test failed: Occlusion query returned an unexpected result (0x00060300). device.c:4621: Test failed: Occlusion query returned an unexpected result (0x00060300). device.c:4628: Test failed: Occlusion query returned an unexpected result (0x00060300). And on Windows: device.c:4609: Test failed: Occlusion query returned an unexpected result (0xffff052a). device.c:4621: Test failed: Occlusion query returned an unexpected result (0x0008052a). device.c:4628: Test failed: Occlusion query returned an unexpected result (0x0008052a).

2 1

Re: testbot/log2revtimes: Add a script to extract the VM revert times from the WineTestBot log and prepare them for analysis.
by Francois Gouget May 12, 2014

May 12, 2014

On Mon, 12 May 2014, Francois Gouget wrote: > --- > > I'm using this script to parse the Engine log and generate a CSV files I > can import in a spreadsheet to generate a graph of the VM revert times. > But having it only on my machine feels wrong. So I propose to put it in > the scripts directory (which feels like a sort of contrib directory) so > it can be used by others. And here is the spreadsheet I import the 'CVS' file into: http://fgouget.free.fr/wtb/vm1-revtime.xls.bz2 And the corresponding graphs: * Since the beginning of times This graph shows all the revert times since the new TestBot was put online. The Y axis is logarithmic so the high revert times don't cause all the low ones to be crunched together. Note that the stratification is caused by the 1 second ganularity of the mesurements. I guess it needs an annotation with the different events. http://fgouget.free.fr/wtb/vm1-revtimes-all.png * Since last April This shows the revert times a bit before the VM1 host crashed and went through reconstruction. This confirms my suspicions: the revert times are not very good :-( http://fgouget.free.fr/wtb/vm1-revtimes-recent.png -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Re: [PATCH 5/5] wined3d: Move get_dc palette updates to ddraw.
by Henri Verbeet May 12, 2014

May 12, 2014

On 12 May 2014 15:12, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Note that d3d9 does not support get_dc on D3DFMT_P8. d3d8 and d3d10+ do > not support get_dc at all. That's not strictly true, with d3d10+ you can still get GetDC() / ReleaseDC() through IDXGISurface1. It doesn't give you P8 though. > + if (palette) > + { > + const RGBQUAD *color_table = wined3d_palette_get_rgbquads(palette->wineD3DPalette); > + SetDIBColorTable(*hdc, 0, 256, color_table); > + } ... > +const RGBQUAD * CDECL wined3d_palette_get_rgbquads(const struct wined3d_palette *palette) > +{ > + return palette->colors; > +} That's a pretty terrible interface, it shouldn't be very hard to come up with something better.

1 0

Re: msvcrt: Don't crash on NULL struct _tm in asctime
by Marvin May 12, 2014

May 12, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6983 Your paranoid android. === w2000pro (32 bit time) === time: unhandled exception c0000005 at 78028AD5 === wxppro (32 bit time) === time: unhandled exception c0000005 at 77C4A8B6

1 0

Re: [PATCH 2/2] oleacc: Add GetStateText implementation (try2)
by Nikolay Sivov May 12, 2014

May 12, 2014

> + state_id = IDS_STATE_MIN; > + while(dwStateBit) { > + state_id++; > + dwStateBit /= 2; > + } It looks like ffs() could be used to do that. Actually it would be better to find a way to connect those resource ids with actual STATE_SYSTEM_* symbols, not sure if it's possible to do cleanly. Also I don't like formatting, especially prefixed names, but that's probably considered to be submitter choice.

2 3

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.
by Alexandre Julliard May 12, 2014

May 12, 2014

Ken Thomases <ken(a)codeweavers.com> writes: > The specific pixel format was never used. It was effectively just a flag > indicating if the window had a GL surface. This generalizes it from a flag > to a count, to allow for multiple GL surfaces. I'm not convinced that the concept of multiple surfaces makes sense, except maybe as a driver implementation detail. -- Alexandre Julliard julliard(a)winehq.org

4 15

Re: [PATCH] gdi32: Add MS Shell Dlg tests
by Dmitry Timoshkov May 12, 2014

May 12, 2014

Alex Henrie <alexhenrie24(a)gmail.com> wrote: > + memset(&efnd, 0, sizeof(efnd)); > + strcpy(lf.lfFaceName, "MS Shell Dlg"); > + ret = EnumFontFamiliesExA(hdc, &lf, enum_fullname_data_proc, (LPARAM)&efnd, 0); > + ok(ret, "font MS Shell Dlg is not enumerated\n"); > + ret = strcmp((char*)efnd.elf[0].elfLogFont.lfFaceName, "MS Shell Dlg"); > + todo_wine ok(!ret, "expected MS Shell Dlg got %s\n", efnd.elf[0].elfLogFont.lfFaceName); > + ret = strcmp((char*)efnd.elf[0].elfFullName, "MS Shell Dlg"); > + ok(ret, "did not expect MS Shell Dlg\n"); Please add the tests for other font enumeration APIs (the may behave differently), and the tests with NULL face name (according to my tests in that case MS Shell Dlg won't be enumerated). Since that would clutter existing tests I'd suggest to move the new one into separate body and name it appropriately. -- Dmitry.

2 1

Re: comctl32/listview: Fix custom draw stage sequence
by Marvin May 11, 2014

May 11, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6975 Your paranoid android. === w2000pro (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wxppro (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wvistau64 (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7u (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w8 (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wvistau64 (64 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

2 1

Re: [PATCH] gdi32: Add MS Shell Dlg tests
by Marvin May 11, 2014

May 11, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6979 Your paranoid android. === wvistau64 (32 bit font) === The test timed out === wvistau64 (64 bit font) === The test timed out

1 0

Federal circuit reverses ruling on Java APIs
by Alex M May 11, 2014

May 11, 2014

https://www.eff.org/deeplinks/2014/05/dangerous-ruling-oracle-v-google-fede… This is very worrying news. What are the implications for WINE if this manages to go through entirely? -- Malo periculosam libertatem quam quietum servitium.

4 3

Testbot
by Mikael Ståldal May 11, 2014

May 11, 2014

I see in the patch list http://source.winehq.org/patches/ that the testbot run on some patches, but not all. What determine if it run or not?

2 4

Re: ced401: add initial support
by André Hentschel May 9, 2014

May 9, 2014

Am 09.05.2014 14:42, schrieb Alois Schlögl: > The attached patch includes the stubs for the ced1401 driver dll. > > This is a starting point to support ced1401/spike2/signal software. > > It's my first patch submission to wine - feedback welcome. > I also doubt that this wrapper get's included as it's too special. But when you finished your work, could you please share a link to github or somewhere with me. (I'm collecting wrappers for Wine on my website: http://dawncrow.de/wine/index.html )

1 0

Re: gdi32: Report unsubstituted font face names. (try 5)
by Alexandre Julliard May 9, 2014

May 9, 2014

Alex Henrie <alexhenrie24(a)gmail.com> writes: > I kept the full name tests, but now they make sure that the full name > is a SUBSTITUTED font name. It breaks the gdiplus tests: ../../../tools/runtest -q -P wine -T ../../.. -M gdiplus.dll -p gdiplus_test.exe.so font && touch font.ok font.c:759: Test failed: wrong face name MS Shell Dlg font.c:770: Test failed: wrong face name MS Shell Dlg make: *** [font.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wininet: Fix InternetGetConnectedStateEx[A|W] (try 2, resend)
by Alexandre Julliard May 9, 2014

May 9, 2014

Bruno Jesus <00cpxxx(a)gmail.com> writes: > @@ -1241,8 +1250,9 @@ BOOL WINAPI InternetGetConnectedStateExA(LPDWORD lpdwStatus, LPSTR lpszConnectio > dwReserved); > if (rc && lpwszConnectionName) > { > - WideCharToMultiByte(CP_ACP,0,lpwszConnectionName,-1,lpszConnectionName, > - dwNameLen, NULL, NULL); > + if (WideCharToMultiByte(CP_ACP,0,lpwszConnectionName,-1,lpszConnectionName, > + dwNameLen, NULL, NULL) == 0) > + *lpszConnectionName = '\0'; That doesn't seem to match what the W function does, and I don't see any tests for that case. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: comctl32: Tooltip AddTool needs to support TTTOOLINFOW_V3_SIZE
by Alexandre Julliard May 9, 2014

May 9, 2014

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -1037,8 +1037,9 @@ TOOLTIPS_AddToolT (TOOLTIPS_INFO *infoPtr, const TTTOOLINFOW *ti, BOOL isW) > infoPtr->hwndSelf, ti->hwnd, ti->uId, > (ti->uFlags & TTF_IDISHWND) ? " TTF_IDISHWND" : ""); > > - if (ti->cbSize >= TTTOOLINFOW_V2_SIZE && !ti->lpszText && isW) > - return FALSE; > + if ((ti->cbSize > TTTOOLINFOW_V2_SIZE && > + ti->cbSize != TTTOOLINFOW_V3_SIZE) && !ti->lpszText && isW) > + return FALSE; This doesn't make any sense. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ced401: add initial support
by Nikolay Sivov May 9, 2014

May 9, 2014

What does it have to do with Wine? Is it really some dll that Windows provides? > +/* > + * Use1432.dll > + * > + * Generated from/home/schloegl/.wine-1.7.17/drive_c/1401/utils/Use1432.dll by winedump. > + * > + * DO NOT SUBMIT GENERATED DLLS FOR INCLUSION INTO WINE! > + * > + */

3 3

Re: [PATCH 1/2] mshtml: Added IDispatchEx support to HTMLStyleSheetRulesCollection object.
by Marvin May 9, 2014

May 9, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6935 Your paranoid android. === w2000pro (32 bit dom) === dom.c:6245: Test failed: unexpected guid {3050f2e5-98b5-11cf-bb82-00aa00bdce0b}

1 0

Re: [PATCH 2/2] oleacc: Add Client_accHitTest implementation
by Piotr Caban May 9, 2014

May 9, 2014

On 05/09/14 10:54, Piotr Caban wrote: > --- > dlls/oleacc/client.c | 22 +++++++++++++++++++-- > dlls/oleacc/tests/main.c | 50 > +++++++++++++++++++++++++++++++++++++++++++++--- > 2 files changed, 67 insertions(+), 5 deletions(-) > This patch is wrong. I'll send a fixed version.

1 0

Can I play with the Notepad code?
by Susan Cragin May 9, 2014

May 9, 2014

Hi. I want to make Notepad remember which encoding scheme you last used. Right now it defaults to ANSI Latin when opening a new file, and saves it that way too, unless you are careful. And, if I can, I want to make the following changes: (1) use ALT-Windows-key to move lines up and down. (2) use CTL-Windows-key to move paragraphs up and down. Lines and paragraphs are defined as follows: So this is a line of text. And this is line 2 of text. And this is line three of text. But they are all part of Paragraph 1. Paragraph 2 starts after a blank line is inserted. Sort of like Emacs. I've found the source code. I'm looking at where to put things. I can do it in lisp, and I've got help for C. http://source.winehq.org/source/programs/notepad/ Can I can I can I? It's going to take me a while, so don't hold your collective breath. Susan

3 2

Re: ws2_32: Return the correct error if SO_REUSEADDR is set in bind error
by Marvin May 8, 2014

May 8, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6923 Your paranoid android. === w2008s64 (64 bit sock) === sock: unhandled exception c0000005 at 000007FEFFD49CD9

1 0

Re: [PATCH] gdi32: Report unsubstituted font face names. (try 4)
by Marvin May 8, 2014

May 8, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6914 Your paranoid android. === w2000pro (32 bit font) === font.c:4756: Test failed: expected MS Shell Dlg got Microsoft Sans Serif font.c:4765: Test failed: expected MS Shell Dlg 2 got Tahoma Bold === wxppro (32 bit font) === font.c:4756: Test failed: expected MS Shell Dlg got Microsoft Sans Serif font.c:4765: Test failed: expected MS Shell Dlg 2 got Tahoma Bold === w2008s64 (32 bit font) === font.c:4756: Test failed: expected MS Shell Dlg got Microsoft Sans Serif font.c:4765: Test failed: expected MS Shell Dlg 2 got Tahoma === w8 (32 bit font) === font.c:4756: Test failed: expected MS Shell Dlg got Microsoft Sans Serif font.c:4765: Test failed: expected MS Shell Dlg 2 got Tahoma === w2008s64 (64 bit font) === font.c:4756: Test failed: expected MS Shell Dlg got Microsoft Sans Serif font.c:4765: Test failed: expected MS Shell Dlg 2 got Tahoma

3 2

Re: [PATCH] gdi32: Report unsubstituted font face names. (try 3)
by Alex Henrie May 8, 2014

May 8, 2014

2014-05-08 2:28 GMT-06:00 Alexandre Julliard <julliard(a)winehq.org>: > Please add tests for the full name too. I thought I did: @@ -6031,6 +6042,8 @@ START_TEST(font) * I'd like to avoid them in this test. */ test_EnumFontFamilies("Arial Black", ANSI_CHARSET); + test_EnumFontFamilies("MS Shell Dlg", ANSI_CHARSET); + test_EnumFontFamilies("MS Shell Dlg 2", ANSI_CHARSET); test_EnumFontFamilies("Symbol", SYMBOL_CHARSET); if (is_truetype_font_installed("Arial Black") && (is_truetype_font_installed("Symbol") || is_truetype_font_installed("Wingdings"))) Is there a better way to test the full name? -Alex

2 1

Re: [PATCH] user32: Don't depend on HMENU being valid for popup menus
by Ken Thomases May 8, 2014

May 8, 2014

On May 6, 2014, at 9:28 AM, Andrew Eikum wrote: > +static HMENU MENU_GetHandle(POPUPMENU *menu) > +{ > + return menu ? menu->obj.handle : NULL; > +} Now that DestroyMenu() really destroys the handle, any use of the handle and thus this function has to be examined very carefully. The menu pointer may be valid and menu->obj.handle may have a value, but that value may no longer be a valid handle. > menuchar = SendMessageW( hwndOwner, WM_MENUCHAR, > - MAKEWPARAM( key, menu->wFlags ), (LPARAM)hmenu ); > + MAKEWPARAM( key, menu->wFlags ), (LPARAM)MENU_GetHandle(menu) ); So, here we're passing the menu handle in the WM_MENUCHAR message. If the menu has been destroyed, that's an invalid handle. We probably need tests to verify that that's what happens on Windows. That is, maybe it passes NULL. Or maybe the handle is still valid somehow. (The existing destroyed-submenu tests suggest that the handle isn't valid anymore, but maybe magic happens.) > - drawItem.hwndItem = (HWND)hmenu; > + drawItem.hwndItem = (HWND)MENU_GetHandle(menu); > - dis.hwndItem = (HWND)hmenu; > + dis.hwndItem = (HWND)MENU_GetHandle(menu); Same for the WM_DRAWITEM message. > @@ -1845,7 +1840,7 @@ static BOOL MENU_InitPopup( HWND hwndOwner, HMENU hmenu, UINT flags ) > menu->hWnd = CreateWindowExW( ex_style, (LPCWSTR)POPUPMENU_CLASS_ATOM, NULL, > WS_POPUP, 0, 0, 0, 0, > hwndOwner, 0, (HINSTANCE)GetWindowLongPtrW(hwndOwner, GWLP_HINSTANCE), > - (LPVOID)hmenu ); > + (LPVOID)MENU_GetHandle(menu) ); This one is interesting. This is a value that's just forwarded through to the WM_CREATE message via the lpCreateParams field of the CREATESTRUCTW pointed to by the lparam. It's then stored in the window extra space using SetWindowLongPtrW(). It's then looked up elsewhere in the window proc. Some cases in the window proc try to use the handle, which will fail if it's been destroyed. I think you can pass the menu pointer here instead of the menu handle. Likewise, I think you can store the menu pointer into the window extra space. You'd have to change the size of the extra space defined in the MENU_builtin_class struct. And you'd need to change all uses of Set/GetWindowLongPtrW() on the menu's window with 0 index. MENU_DrawPopupMenu() would need to be changed to take a menu pointer instead of a handle. A couple of those uses are for the MM_SETMENUHANDLE and MM_GETMENUHANDLE messages. I believe those are obsolete Wine-internal messages. They can probably be completely removed. For the MN_GETHMENU message, you can return MENU_GetHandle(GetWindowLongPtrW(hwnd, 0)), although, again, it would be good to test what Windows does for a destroyed-but-still-alive menu. The stored value is also used in GetMenuBarInfo(), so you'd want to rework that. > @@ -2023,18 +2018,17 @@ static void MENU_SelectItem( HWND hwndOwner, HMENU hmenu, UINT wIndex, > SendMessageW( hwndOwner, WM_MENUSELECT, MAKEWPARAM(pos, > ip->fType | ip->fState | > - (ptm->wFlags & MF_SYSMENU)), (LPARAM)topmenu); > + (topmenu->wFlags & MF_SYSMENU)), (LPARAM)topmenu); Here you missed a case. The lparam should be the menu handle, but topmenu is now a menu pointer. It might be good to also review all remaining uses of MENU_GetMenu(). Again, I think it should be possible to confine uses of menu handles just to the interfacing with client code. So, uses of MENU_GetMenu() at other places indicates that you're relying on the handle being valid. For example, the call to GetSubMenu() in MENU_FindItemByKey() or the calls to EnableMenuItem() in MENU_InitSysMenuPopup(). Unfortunately, that may involve creating a lot of helper functions. I didn't review further than this. Sorry that my suggestions are creating so much work. If you haven't already done so, you should probably get input from others (i.e. Alexandre) to see if my suggestions make sense. -Ken

2 3

Re: [PATCH] gdi32: Report unsubstituted font face names. (try 3)
by Alexandre Julliard May 8, 2014

May 8, 2014

Alex Henrie <alexhenrie24(a)gmail.com> writes: > @@ -4741,6 +4741,17 @@ static void test_EnumFonts(void) > ret = EnumFontFamiliesA(hdc, NULL, enum_all_fonts_proc, (LPARAM)&lf); > ok(ret, "font Arial Italic Bold should not be enumerated\n"); > > + /* MS Shell Dlg and MS Shell Dlg 2 must exist */ > + ret = EnumFontFamiliesA(hdc, "MS Shell Dlg", enum_fonts_proc, (LPARAM)&lf); > + ok(!ret, "font MS Shell Dlg is not enumerated\n"); > + ret = strcmp(lf.lfFaceName, "MS Shell Dlg"); > + ok(!ret, "expected MS Shell Dlg got %s\n", lf.lfFaceName); > + > + ret = EnumFontFamiliesA(hdc, "MS Shell Dlg 2", enum_fonts_proc, (LPARAM)&lf); > + ok(!ret, "font MS Shell Dlg 2 is not enumerated\n"); > + ret = strcmp(lf.lfFaceName, "MS Shell Dlg 2"); > + ok(!ret, "expected MS Shell Dlg 2 got %s\n", lf.lfFaceName); Please add tests for the full name too. -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH] comctl32/tests: Fix propsheet and listview tests which depend on being in foreground.
by Bernhard Übelacker May 7, 2014

May 7, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, the comctl32:propsheet and comctl32:listview are regularly failing on the Windows testbots. This is visible in these test runs with an "empty" patch to these tests: https://testbot.winehq.org/JobDetails.pl?Key=6828 https://testbot.winehq.org/JobDetails.pl?Key=6829 This is because windows forbids them to get into foreground. This patch is working around this by simulating an ALT key press and then calling SetForegroundWindow. These are the results with an earlier revision of this patch: https://testbot.winehq.org/JobDetails.pl?Key=6832 https://testbot.winehq.org/JobDetails.pl?Key=6833 Kind regards, Bernhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTaVcbAAoJEOlvol+DpkHmDb8IAKD/G0FWgDP8v44SpfqhHY2W 0g8fCzJY6/GhjweV6Mybwqx/YmeBwmc8qvRuHshDUm8WWZbI6yH14LEGz5GwbccI XH/kJgiqqaJH8AiCQM6chF+JBAz3URf9SsAsuDKBjNmpHSMkPAhC/JXecI43GMyX E2AoggKh6DXtEq3yOnGJIRSMAhGPJGYP1Vny5+rq6+rvg2DpNdGI11Xk4oCVgJvc cYCk3yVNKquv4JW8vg80ZJboglDff7omTBLJdF5Nkk5xSGY4iV7amp9CChEJN33N lsohSyvIXeDWegeCWaXGNGhTPXwuTb56tQG22uR7IxJscT8/cXsDQ4jYvuTHoXM= =hTJp -----END PGP SIGNATURE-----

2 2

Re: shell32: Use SW_HIDE with ShellExecuteA in tests.
by Marvin May 7, 2014

May 7, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6894 Your paranoid android. === w2000pro (32 bit shlexec) === shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 === wxppro (32 bit shlexec) === shlexec.c:1220: Test failed: expected 1 args, got 4 === w8 (32 bit shlexec) === shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1541: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1573: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1541: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1573: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\wtDFC3.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\wtDFC3.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:2111: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\wtDFC3.tmp" Exec") succeeded: rc=42

1 0

Re: [PATCH 1/2] include: Added atlcom.h
by Vincent Povirk May 7, 2014

May 7, 2014

I think you should add this new header to include/Makefile.in.

2 1

Re: [PATCH] user32: Don't depend on HMENU being valid for popup menus
by Vincent Povirk May 7, 2014

May 7, 2014

if (menu->FocusedItem != NO_SELECTED_ITEM) { + ERR("focused: %u, nitms: 0x%x\n", + menu->FocusedItem, + menu->nItems); menu->items[menu->FocusedItem].fState &= ~(MF_HILITE|MF_MOUSESELECT); menu->FocusedItem = NO_SELECTED_ITEM; } Is this stray debugging code or a real error condition? - * Return the handle of the submenu, or hmenu if no submenu to display. + * Return the handle of the submenu, or menu if no submenu to display. Still slightly inaccurate as the returned submenu is no longer a handle. @@ -4787,24 +4770,29 @@ static BOOL SetMenuItemInfo_common(MENUITEM * menu, menu->wID = lpmii->wID; if (lpmii->fMask & MIIM_SUBMENU) { - menu->hSubMenu = lpmii->hSubMenu; - if (menu->hSubMenu) { - POPUPMENU *subMenu = MENU_GetMenu(menu->hSubMenu); - if (subMenu) { - if( MENU_depth( subMenu, 0) > MAXMENUDEPTH) { + if(menu->fType & MF_POPUP){ + if(menu->submenu) + InterlockedDecrement(&menu->submenu->refcount); + } How do we know this isn't the last reference? I'm not sure this frees submenus correctly. If I create a popup menu and add a submenu to it, that submenu has two references (one because it has an HMENU and one because it is a submenu). DestroyMenu should recursively destroy submenus. So it seems to me, destroying a menu needs to destroy the handles to submenus (if they have one) and release its references to them.

2 1

Re: [2/2] dpnet: Implement IDirectPlay8Client Initialize (try 2)
by Stefan Dösinger May 7, 2014

May 7, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-07 03:39, schrieb Alistair Leslie-Hughes: > Hi, Just a rebase. This looks ok to me. It depends on the test added by patch 1 though, so it'll have to wait until the test is sorted out. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTajllAAoJEN0/YqbEcdMwiTYP/icYQO8oZyCNCRTwoJ3Vdsbl mBbpWrXI2pT0ASEj30+WdJ7a7iJvZXc8tVSvvV8UtbQPLBRGI5Y9asJi9rKpNCLb ksP5vXKmsSxUewGGbX+rtYqRS/hL67NSTai1mb/hxkqGmmJqLbchzM3NP+GX4fvv e9w9p/DpfcOXGCrAtvuKSCzFPDwn60IVIIZVXTCnEs6KR3Vvq+NGnxmV9kwtEjCj idZI0cgPXwR/R0ybJdhFJpU3GHiyNWPAhI6kZcXNCv+kP90A6aDJ8rgd3SvcNEyt oxROFT7PsHUJmC72xixpscGMM5DLDijffVmtooTIgGHsM2iC8Yi4B5s+U77P0sBJ 3LGfYH68AIZtAA187A21WM+WLOtWV5vjihHIHxEO9UFmdI1G88f/9bG0n5YRlzkf Rh4xevGBw7/oks3q08uEMY2EwQdCL/NSx1HWNBtbohBKClZv+373cXEY9+lXPbl2 vA6P0KCUHf/JRM9v2b19UG7vffklCoymroQ8i4TD8qksBHdGq640MUqqyQaMfuu4 ZBrJH3Q+VTe79fcPTG4AyQrEUb1Xy+ohNIY5gN4e8UuvydEpcIId5a0Isu04u9Xr 02tjdraySJaW7ELq5+NoegH30O2Q8aJzPkY7aS2lWe+Kt8lgAUG+KKQXF4fKoeSH x6wbbtc5ojYjXXS91b8S =59Gh -----END PGP SIGNATURE-----

1 0

Re: [1/2] dpnet: Add IDirectPlay8Client tests (try 2)
by Stefan Dösinger May 7, 2014

May 7, 2014

Am 2014-05-07 03:39, schrieb Alistair Leslie-Hughes: > Hi, > Changed test_init_dp to return a boolean. Sorry, I was a bit slow with replying to your previous mail. Is there anything that prevents you from having a helper function that creates a new client object for each test? If you share one client object and the tests modify the state, then the tests end up depending on each other. We had a similar situation in the d3d8/9 visual tests (and still have in ddraw:visual), and it leads to hard to debug test failures. If the client object takes too long to create (I'd say > 0.25 seconds) then that's a reason to keep the client around. Otherwise creating a fresh one for each test and destroying it afterwards will really help you in the long run. Somewhat related: > +static BOOL test_init_dp(void) > ... > + hr = CoInitialize(0); > ... > +static void test_cleanup_dp(void) > ... > + CoUninitialize(); > +} I'd move that to the test's main function. (And no, I don't think there's a need to call CoInitialize / CoUninitialize more than once.) Cheers, Stefan

1 0

Re: dplayx: Initial msgtid variable
by Stefan Dösinger May 7, 2014

May 7, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-07 04:08, schrieb Alistair Leslie-Hughes: > + obj->msgtid = 0; > obj->ref = 0; > obj->refA = 0; > obj->ref2 = 0; IMO it would be better to use HEAP_ZERO_MEMORY in the HeapAlloc call a few lines above. This problem will keep coming back when more members are added. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTajXtAAoJEN0/YqbEcdMwF6kP/iJveqvV58YLeyd2bpJKOjim H2dF+Cll8hAayzziokzOhgf6BoMikhnwqQHtXSgZKuGjQl7oF6sy2qCr5wvfl13V bC9Me4DbXE9PEwT2ArEDiGkejg0G7KQ8qFVo6vFNIaRBEt0mgH0bFUntGPtZZgbV 9qT3KgoNGqOw4iI8rzh4ATabu9NizkI+b2UxMY+9lEf/RSur9pnX/XQhjRIvzZKS YT4exS5bdjZXcSN9aEPax9f+VmYKRyVBvo6O5PfdkqQNarFMc5bw6Utkab/0VbQb j5IM5dRdevTsqx1ZdqzAxlDCHEtRlQWR07A0unsg6JuCX8Rwn+lAh78NTozHWwIV qG31CoHV37WJggleZc2Rk5oSatlAVARwX/f2qJ9GA3fv5muJkpThc8HcEvTN1e/V zSmWBLljyF0I6a6a4P8k2Ch9ZmDnmDvIaGaJshnETt+ypgK2T2QI35pb2bh/pGmC ltWvEwRpbATmftl62Bu4511Afo8AGcXEa83SvfukPmHaAtiJ2TNI9/c1vCP/Pvke TeARP1gtvSh3Q7pwcXPIaAry/RLEYmMPJDAoKRkc+FM2O/4gNiUDUBIDeEpKJaB1 BM2HE0/TCrrIEkfE1RI9JseX79uylagiStAIUgKkqMfJxrXA50VX0bLnQq/qtayD vRfIAuYYb3hvpNll1gIT =rA1r -----END PGP SIGNATURE-----

1 0

Re: [PATCH 2/2] gdi32: Report unsubstituted font face names.
by Alexandre Julliard May 7, 2014

May 7, 2014

Alex Henrie <alexhenrie24(a)gmail.com> writes: > @@ -5765,6 +5765,11 @@ static BOOL enum_face_charsets(const Family *family, Face *face, struct enum_cha > else > strcpyW(elf.elfFullName, family->FamilyName); > } > + /* Make sure that MS Shell Dlg says "MS Shell Dlg" and not "Tahoma" */ > + if (unsubstituted_face_name) > + { > + lstrcpynW(elf.elfLogFont.lfFaceName, unsubstituted_face_name, LF_FACESIZE); > + } So what happens to the full name in that case? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32: Make Treeview Notify the parent on a return key press
by Nikolay Sivov May 6, 2014

May 6, 2014

Quick testing doesn't show this notification, so I'm not convinced it's a right change. Please add a test.

1 0

Re: [1/2] dpnet: Add IDirectPlay8Client tests
by Stefan Dösinger May 6, 2014

May 6, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-05 08:46, schrieb Alistair Leslie-Hughes: > +static IDirectPlay8Client* client = NULL; > ... > + hr = CoCreateInstance(&CLSID_DirectPlay8Client, NULL, CLSCTX_INPROC_SERVER, &IID_IDirectPlay8Client, (void **)&client); > + ok(hr == S_OK, "CoCreateInstance failed with 0x%x\n", hr); > ... > + hr = IDirectPlay8Client_Close(client, 0); > + ok(hr == S_OK, "IDirectPlay8Client_Close failed with %x\n", hr); Please avoid such dependencies between different tests. If creating and releasing the client is something that every test has to do you can add helper functions for this task. > + for (i=0;i<items;i++) > + { > + trace("Found Service Provider: %s\n", wine_dbgstr_w(serv_prov_info->pwszName)); > + trace("Found guid: %s\n", wine_dbgstr_guid(&serv_prov_info->guid)); > + > + serv_prov_info++; > + } > + > + serv_prov_info -= items; /* set pointer back */ > + ok(HeapFree(GetProcessHeap(), 0, serv_prov_info), "Failed freeing server provider info\n"); You could use serv_prov_info as an array instead of doing the pointer arithmentic twice. E.g. trace("Found guid: %s\n", wine_dbgstr_guid(&serv_prov_info[i].guid)); > + hr = IDirectPlay8Client_EnumHosts(client, &appdesc, host, local, NULL, 0, INFINITE, 0, INFINITE, NULL, &async, 0); > + todo_wine ok(hr == DPNSUCCESS_PENDING, "IDirectPlay8Client_EnumServiceProviders failed with 0x%08x\n", hr); > + todo_wine ok(async, "No Handle returned\n"); > + > + hr = IDirectPlay8Client_CancelAsyncOperation(client, async, 0); > + ok(hr == S_OK, "IDirectPlay8Client_CancelAsyncOperation failed with 0x%08x\n", hr); Are you sure that this always returns DPNSUCCESS_PENDING? Couldn't it also return a result instantly? Overall I don't see the point in this test at the moment. As it is now it doesn't say much. This is just an opinion though, I'll leave the decision up to you. > + todo_wine ok(caps.dwMaxEnumPayloadSize == 983, "expected 983, got %d\n", caps.dwMaxEnumPayloadSize); Out of curiosity, do you have any idea where this value comes from? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTaTX9AAoJEN0/YqbEcdMwB6AP/jd1T0OLGPXO3pgF9boIHp6i yQTDCgf7Wq8zKJuxDZtOzfGzVbYqVeN8TDx9c3oD3RSru9bBIJ9Bjeu3hKqvL2Qo 4JRJZyQn665RymbKo/S9ivXBHmd9cuh4tfdTxHU7n0nVXICCNDniBxfAwr2HkkeB iyvMe8Ga3SPVCL+33XZAniPPFnfnEYkaqU42CTUUK2hlYyzb4bScihgdrUqoX36k RtvK2UKxOBT5E9nd0VIS/b8fF4uXFIzD7M6oEuzLObXL6XGsRNl2mtMpZ0ztlFpy PIF1AbFyK4tQA3obsTSWUVJVlQFLCurvqg2klLogewdyVy4wE4h0/oOCRCPhuVbR baJf0by5ZC4Os4YIZIzN0OOy0N3A+bMQI1VdvQTuMPwF+dYk268p0t77SN6F2gfa ts9MyQxYrhrao3+oI4Hw2ouYUxIYj+WxNSVCb01TjUrMVOMAeD1Ksttbk1g5ADdZ +DbV9CWuOhISjXh5OT8ToH0FxrImrby3FDyX/UFf2KPzwzKoX2kNyjtSHguPIOko 3jOnuVh8HsD7jX0sQqMMkdwsESdfTCwIHXLhbE4C08yxsu8ByNhFHme3oX4EcyPf oHRUA+w8Yr8rr+wSU1fpPEb79ZnMn5xfR7xZQKzX5af0ICta6k3UjtSeAuE6P1xX HFJrTsoKGibhnm6z2wZH =sF7u -----END PGP SIGNATURE-----

2 1

Re: [PATCH 2/2] gdi32: Report unsubstituted font face names.
by Marvin May 6, 2014

May 6, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6860 Your paranoid android. === wvistau64 (32 bit font) === The test timed out

1 0

Testbot returning 500 - Internal server error message
by Bruno Jesus May 6, 2014

May 6, 2014

Hi all. While trying to upload a test in the command line parameter input the server returned a 500 error. Then I went back to the index and it's working but clicking on any test key will result in the error message as well. This may be an intermittent failure and I'm reporting it just to check because I don't recall any scheduled maintenance emails. Example: https://newtestbot.winehq.org/JobDetails.pl?Key=6858 Best regards, Bruno

2 1

Re: setupapi: SetupDiGetClassDevsExW should ignore DIGCF_ALLCLASSES if class set
by Nikolay Sivov May 6, 2014

May 6, 2014

Is it possible to add a test for that?

2 1

Wine talk at Linuxwochen Österreich
by Stefan Dösinger May 6, 2014

May 6, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I will give a talk about Wine gaming at Linuxwochen Österreich later this week: When: Friday, May 9th, 15:00 Where: FH Technikum Wien, HS 2.01, Vienna See http://www.linuxwochen.at/ and https://cfp.linuxwochen.at/en/LWW14/public/events/154 for more details Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTaQLIAAoJEN0/YqbEcdMwscQP/2OuAs1Z2MSrYNlXH4CJngDQ 0rqb4aCf32Yy5iVJ6XRbIkfPxrA+CpeX1fwCPpx1rGjJM9djQ1RnbQDb1dafCbYg 4qHJeMooZ9zbqB/6rUV9q2xk8E3Bnhi5RptBnwtEljUWCOTbCbTtevr5BjLbM/Dk Si4S2gFSkGCHyNFupxaIFGOseew3zLNSkFvqV4Pr/eX+j0GIT78t6CyqtFB/Vpvs nMBptteZSlwmvJ5Z9bX7ruUus9+Az2Q17UV4c0tN+x5xsLD6QpoJWocFyO/7SYy9 HTa6QWwDF+AWOiCkP3TdPz1U/bNcEzSEGpDcFaQNLABGFhVm3rpgsqoBwJln2BDH Ig0+pG7jQSaYm1qK6Y5Sx58rVTDXizWmr2QfGkqh3ZmaOBBXTqudtPbZ5lrCmk50 xtbwqymo/vLXaU5FbgY83VvDip3oCBwny+E8R+O/rL20h5bkLNnn5doU3Kt2GTKU c3eohbg/qAlBzxG0UrtSQdiNYeItABaFYvhAkg11g8y0yjiZYdiGHMz4cgUMaVoe qDR0DLLEFGqTqYvhs5+fiK09EjABSpTVSnuGwsX0zRphgLZqsBWvg/O7G3pCwZ4Y MamqhvKBXhS6sQVjyDujuqNvSon3IEcomPz/BazbzZjuqfMU8IdP2lk7CizfvBvM dX/IsNZR6MKxhDVHtfEB =F/a5 -----END PGP SIGNATURE-----

1 0

Re: setupapi: SetupDiGetClassDevsExW should ignore DIGCF_ALLCLASSES if class set
by Henri Verbeet May 6, 2014

May 6, 2014

On 6 May 2014 16:05, Mark Harmstone <hellas(a)burntcomma.com> wrote: > + if (flags & DIGCF_ALLCLASSES && class) > + flags -= DIGCF_ALLCLASSES; This works, of course, but the usual way to do that kind of thing would be "if (class) flags &= ~DIGCF_ALLCLASSES;"

1 0

Re: [PATCH] gdi32: Report unsubstituted font face names.
by Alexandre Julliard May 6, 2014

May 6, 2014

Alex Henrie <alexhenrie24(a)gmail.com> writes: > @@ -5805,12 +5810,13 @@ static BOOL freetype_EnumFonts( PHYSDEV dev, LPLOGFONTW plf, FONTENUMPROCW proc, > GDI_CheckNotLock(); > EnterCriticalSection( &freetype_cs ); > if(plf->lfFaceName[0]) { > - FontSubst *psub; > - psub = get_font_subst(&font_subst_list, plf->lfFaceName, plf->lfCharSet); > + FontSubst *psub = get_font_subst(&font_subst_list, plf->lfFaceName, plf->lfCharSet); > + WCHAR *unsubstitutedFaceName = NULL; > > if(psub) { > TRACE("substituting %s -> %s\n", debugstr_w(plf->lfFaceName), > debugstr_w(psub->to.name)); > + unsubstitutedFaceName = plf->lfFaceName; > lf = *plf; > strcpyW(lf.lfFaceName, psub->to.name); > plf = &lf; This could be seriously simplified then. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/5] server: Add socket-side support for the interface change notification object (resend).
by Alexandre Julliard May 6, 2014

May 6, 2014

"Erich E. Hoover" <erich.e.hoover(a)gmail.com> writes: > This patch adds an async queue, list object, and interface change > object to the socket object in order to support interface change > notification objects (fully implemented in part 4). A significant > deviation from previous versions of this patch is that errors are > passed up from each routine so that it is easier to ensure that all > possible errors are properly reported. I believe that this is the > server style comment AJ had on IRC, but some clarification would be > appreciated. No, that's not how error handling works in the server. The functions that fail set last error and then you propagate that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/5] server: Add delayed processing for socket-specific ioctl() (resend).
by Alexandre Julliard May 6, 2014

May 6, 2014

"Erich E. Hoover" <erich.e.hoover(a)gmail.com> writes: > @@ -523,17 +523,32 @@ obj_handle_t sock_ioctl( struct fd *fd, ioctl_code_t code, const async_data_t *a > int blocking, const void *data, data_size_t size ) > { > struct sock *sock = get_fd_user( fd ); > + obj_handle_t wait_handle = 0; > + async_data_t new_data; > + int error; > > assert( sock->obj.ops == &sock_ops ); > > + if (blocking) > + { > + if (!(wait_handle = alloc_wait_event( current->process ))) return 0; > + new_data = *async_data; > + new_data.event = wait_handle; > + async_data = &new_data; > + } > switch(code) > { > case WS_SIO_ADDRESS_LIST_CHANGE: > /* intentional fallthrough, not yet supported */ > default: > - set_error( STATUS_NOT_SUPPORTED ); > - return 0; > + error = STATUS_NOT_SUPPORTED; > + break; > } > + set_error( error ); > + if (error == STATUS_PENDING) > + return wait_handle; > + close_handle( current->process, wait_handle ); > + return 0; You should be doing that only as needed. It doesn't make sense to allocate a handle for unknown ioctls. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/3] winex11.drv: copy and paste files to/from X11 apps (try 2)
by Alexandre Julliard May 6, 2014

May 6, 2014

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > /************************************************************************** > + * X11DRV_CLIPBOARD_ExportHDROP > + * > + * Export CF_HDROP format to text/uri-list. > + */ > +static HANDLE X11DRV_CLIPBOARD_ExportHDROP(Display *display, Window requestor, Atom aTarget, > + Atom rprop, LPWINE_CLIPDATA lpdata, LPDWORD lpBytes) > +{ > + HDROP hDrop; > + UINT i; > + UINT numFiles; > + UINT totalSize = 0; > + HGLOBAL hClipData = NULL; > + char *text_uri_list = NULL; > + char *next; > + BOOLEAN succeeded = FALSE; > + > + *lpBytes = 0; > + > + if (!X11DRV_CLIPBOARD_RenderFormat(display, lpdata)) > + { > + ERR("Failed to export %04x format\n", lpdata->wFormatID); > + return 0; > + } > + > + hDrop = (HDROP) lpdata->hData; > + numFiles = DragQueryFileW(hDrop, 0xFFFFFFFF, NULL, 0); > + > + for (i = 0; i < numFiles; i++) > + { > + UINT dosFilenameSize; > + WCHAR *dosFilename; > + succeeded = FALSE; > + dosFilenameSize = 1 + DragQueryFileW(hDrop, i, NULL, 0); > + dosFilename = HeapAlloc(GetProcessHeap(), 0, dosFilenameSize*sizeof(WCHAR)); > + if (dosFilename) > + { > + char *unixFilename; > + DragQueryFileW(hDrop, i, dosFilename, dosFilenameSize); > + unixFilename = wine_get_unix_file_name(dosFilename); > + if (unixFilename) > + { > + totalSize += 8 + /* file:/// */ > + 3*(lstrlenA(unixFilename) - 1); /* "%xy" per char except first '/' */ > + succeeded = TRUE; > + HeapFree(GetProcessHeap(), 0, unixFilename); > + } > + HeapFree(GetProcessHeap(), 0, dosFilename); > + } > + if (!succeeded) > + { > + ERR("out of memory\n"); > + goto end; > + } > + } > + totalSize += 2 * numFiles; /* "\r\n" */ > + hClipData = GlobalAlloc(GMEM_MOVEABLE | GMEM_DDESHARE, totalSize); > + if (hClipData == NULL) > + { > + ERR("out of memory\n"); > + succeeded = FALSE; > + goto end; > + } > + text_uri_list = (char*) GlobalLock(hClipData); > + next = text_uri_list; > + for (i = 0; i < numFiles; i++) > + { > + UINT dosFilenameSize; > + WCHAR *dosFilename; > + succeeded = FALSE; > + dosFilenameSize = 1 + DragQueryFileW(hDrop, i, NULL, 0); > + dosFilename = HeapAlloc(GetProcessHeap(), 0, dosFilenameSize*sizeof(WCHAR)); > + if (dosFilename) > + { > + char *unixFilename; > + DragQueryFileW(hDrop, i, dosFilename, dosFilenameSize); > + unixFilename = wine_get_unix_file_name(dosFilename); > + if (unixFilename) > + { > + static const char *hex_table = "0123456789abcdef"; > + UINT u; > + *next++ = 'f'; > + *next++ = 'i'; > + *next++ = 'l'; > + *next++ = 'e'; > + *next++ = ':'; > + *next++ = '/'; > + *next++ = '/'; > + *next++ = '/'; > + /* URL encode everything - unnecessary, but easier/lighter than linking in shlwapi, and can't hurt */ > + for (u = 1; unixFilename[u]; u++) { > + *next++ = '%'; > + *next++ = hex_table[unixFilename[u] >> 4]; > + *next++ = hex_table[unixFilename[u] & 0xf]; > + } > + *next++ = '\r'; > + *next++ = '\n'; > + succeeded = TRUE; > + HeapFree(GetProcessHeap(), 0, unixFilename); > + } > + HeapFree(GetProcessHeap(), 0, dosFilename); > + } > + if (!succeeded) > + { > + ERR("out of memory\n"); > + goto end; > + } > + } > + > +end: > + if (succeeded) > + { > + GlobalUnlock(hClipData); > + *lpBytes = GlobalSize(hClipData); > + return hClipData; > + } > + else > + { > + if (text_uri_list) > + GlobalUnlock(hClipData); > + GlobalFree(hClipData); > + *lpBytes = 0; > + return 0; > + } > +} That's unnecessarily complicated and inefficient. You don't need to retrieve the file name 4 times, or to convert every filename to Unix twice. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wined3d: Add a registry setting, DisabledExtensions, to disable the use of OpenGL and WGL extensions.
by Henri Verbeet May 6, 2014

May 6, 2014

On 6 May 2014 10:44, Ken Thomases <ken(a)codeweavers.com> wrote: > I'm inclined to say we don't really need this, but I'll leave that up to Alexandre. > + /* Second pass at disabling extensions. This (re)disables extensions that may > + be implied by the GL version or other extensions. */ Is this really a problem in practice? > + if (wined3d_settings.disabled_extensions) > + { > + parse_extension_string(gl_info, wined3d_settings.disabled_extensions, gl_extension_map, > + sizeof(gl_extension_map) / sizeof(*gl_extension_map), FALSE); > + if (WGL_Extensions) > + parse_extension_string(gl_info, wined3d_settings.disabled_extensions, wgl_extension_map, > + sizeof(wgl_extension_map) / sizeof(*wgl_extension_map), FALSE); > + } It may be nicer to just make parse_extension_string() handle a NULL "extensions" pointer, and skip all the conditionals here. > - gl_vendor = wined3d_guess_gl_vendor(gl_info, gl_vendor_str, gl_renderer_str); > - card_vendor = wined3d_guess_card_vendor(gl_vendor_str, gl_renderer_str); > - TRACE("Found GL_VENDOR (%s)->(0x%04x/0x%04x).\n", debugstr_a(gl_vendor_str), gl_vendor, card_vendor); > - > device = wined3d_guess_card(gl_info, gl_renderer_str, &gl_vendor, &card_vendor); > TRACE("Found (fake) card: 0x%x (vendor id), 0x%x (device id).\n", card_vendor, device); I guess this was broken up because of the extension checks in wined3d_guess_gl_vendor(). Is that really justified? Conceptually, if we really want the DisabledExtensions functionality in wined3d, I think it should behave like filtering the extension strings, as opposed to being some kind of generic way to disable specific wined3d code paths, but not others that depend on the same extensions.

1 0

Re: winex11: Silence a noisy winediag ERR in xrandr12_init_modes
by Henri Verbeet May 6, 2014

May 6, 2014

On 5 May 2014 22:53, André Hentschel <nerv(a)dawncrow.de> wrote: > - ERR_(winediag)("Broken NVIDIA RandR detected, falling back to RandR 1.0. " > - "Please consider using the Nouveau driver instead.\n"); > + static int once; > + if (!once++) ERR_(winediag)("Broken NVIDIA RandR detected, falling back to RandR 1.0. " > + "Please consider using the Nouveau driver instead.\n"); Does this actually help? We really shouldn't be calling X11DRV_XRandR_Init() much more often than once per process.

1 0

Re: [PATCH 5/5] ws2_32: Add an interactive test for interface change notifications (resend).
by Marvin May 5, 2014

May 5, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6836 Your paranoid android. === wvistau64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000

1 0

Working on ATL, more real world test case needed
by Qian Hong May 5, 2014

May 5, 2014

Hi all, I'm working on atl80/atl100 recently, particularly on AtlAxCreateControl{,Lic}{,Ex}, AtlAxAttachControl, AtlIPersistStreamInit_{Load,Save}, AtlIPersistPropertyBag_{Load,Save} The motivation to work on AtlAxCreateControl* and AtlAxAttachControl* is for AliWangwang [1]; the motivation to work on AtlIPersistPropertyBag_Load is for QQ[2]. I've already have solution for those apps, however, I have some trouble on them: 1. I have more and more test case for ATL, and found more and more difference behaviors between native AtlAxCreateControl/AtlAxAttachControl and buitin's, some of native behavior looks unreasonable to me so I doubt if we want to follow that. It would be nice to test more real world application before deciding what to do next. 2. I found the (seems) undocumented ATL_PROPMAP_ENTRY struct is different between atl80 and atl100 from my black box testing result. I know QQ use atl80.AtlIPersistPropertyBag_Load which receive a ATL_PROPMAP_ENTRY input parameter, but I don't have any real world app to test the atl100 version or any other version. I'm interesting to know more apps depends on any version (atl/atl80/atl90/atl100/atl110) of AtlIPersistStreamInit_*/AtlIPersistPropertyBag_* to see how they work. I really appreciate a lot if anyone can help report ATL related bugs and CC me, maybe someone remembers some Apps have bugs on atl* but haven't report to bugzilla yet - I don't know any good way to find real world test case, that's why I'm here :) I'd really be happy to get some surprise smart way to do it! In short, any ATL related bugs are welcome, particularly on AtlAxCreateControl*/AtlAxAttachControl/AtlIPersistPropertyBag*/AtlIPersistStreamInit* if you know that's the culprit, but never mind for other ATL related bugs. Note: if an app bugs can be workaround by winetricks -q vcrun2005 / winetricks -q vcrun2008 / winetricks -q 2010, even with msvc*.dll override set to builtin, only leave native atl*.dll, then it is possible a ATL bug. Here are a few known ATL bugs: http://bugs.winehq.org/buglist.cgi?cmdtype=runnamed&list_id=147507&namedcmd… Thank you a lot for any help! [1] http://bugs.winehq.org/show_bug.cgi?id=33724 [2] http://bugs.winehq.org/show_bug.cgi?id=33822 -- Regards, Qian Hong - http://www.winehq.org

2 4

Re: [PATCH 2/5] wined3d: Validate and handle query size parameter. (try 2)
by Henri Verbeet May 5, 2014

May 5, 2014

On 2 May 2014 16:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +static void fill_query_data(void *out, unsigned int out_size, const void *result, unsigned int result_size) > +{ > + unsigned int size = min(out_size, result_size); > + > + memcpy(out, result, size); > +} The extra "size" variable is perhaps a bit superfluous. Not sure if I care.

1 0

Re: [PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 2)
by Henri Verbeet May 5, 2014

May 5, 2014

On 2 May 2014 16:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + memset(&data, 0xff, sizeof(data)); This is a bit of an odd way to write "data = ~0u;". > + ok(*(WORD *)&data == 1 || broken(*(WORD *)&data != 1), > + "Occlusion query returned an unexpected result (0x%.8x).\n", data); > + todo_wine ok(*((WORD *)&data + 1) == 0xffff, > + "data was modified outside of the expected size (0x%.8x).\n", data); I think this is a bit awkward, perhaps it makes more sense the declare "data" as something like "WORD data[4];". Also, can this really ever return 0 for the query data? Would it help to draw a different primitive type, instead of a tiny point? (Because, well, point rasterization is complicated.)

1 0

Re: [PATCH] setupapi: Implement a binary compatible string table
by Marvin May 4, 2014

May 4, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6812 Your paranoid android. === wvistau64 (64 bit stringtable) === stringtable.c:351: Test failed: got 128 stringtable.c:352: Test failed: got 0, thread lcid 1401 === w2008s64 (64 bit stringtable) === stringtable.c:351: Test failed: got 124 stringtable.c:352: Test failed: got 0, thread lcid 409

1 0

Use WINE API from ELF application.
by John Found May 4, 2014

May 4, 2014

Is it possible to use the WINE functionality from inside regular ELF application. For example starting and debugging Windows application. Creating windows, etc. -- asm32.info <johnfound(a)asm32.info>

2 1

Re: Failing tests on testbots because of missing focus
by Francois Gouget May 4, 2014

May 4, 2014

On Sat, 3 May 2014, Bernhard Übelacker wrote: [...] > In my opinion the reason is that these tests get executed from an > application which does not have the current input focus. On the WineTestBot the tests are being run from a console window which is iconized. On the fg-* VMs the mechanism is similar, though it's possible the command window is no iconized. [...] > Also because the newtb* machines showed this error only sometimes (at > least before the testbot changes lately) probably some other tests are > doing something to change focus situation, or are running long enough > and windows is changing its focus policy there. Some tests cause Windows to be opened and stay around. In particular I remember that WineTest.exe typically leaves an Explorer window behind, most likely triggered by a shell32 or shlwapi test. The rpcrt4 tests and others also leave firewall windows behind, asking whether to unblock various ports (these tests don't actually need the ports to be unblocked and thus are not impacted by the questions being unanswered [1]). So based on your description it's quite likely that one of these windows is the one with the focus. [...] > Because of this affecting more tests (and probably this fix could also affect > tests running after this one), I am not sure if this is the right way to fix it: > > - should the test rely on being started from an application which > had focus? (e.g. change testbot to start the tests by an cmd window > which has guaranteed focus) Tests that need focus for one of their window should set up the focus themselves [2]. More generally tests should not rely on anyone else setting things up for them as that would make them too brittle and hard for developers to run 'correctly'. [1] I assume these tests bind their socket to any address and that's why they get these firewall questions. But in fact they only get connections from localhost which is unaffected by the firewall so it's possible they could avoid these questions by only binding to localhost. It's not clear that it's worth the trouble though. [2] I'll leave checking the proposed code to do so to other, more capable, hands (or eyes, braaaains, as the case may be). -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Re: [PATCH] vbscript: Fixed CBool(try 3)
by Piotr Caban May 3, 2014

May 3, 2014

On 05/02/14 06:22, Shuai Meng wrote: > testbot:https://newtestbot.winehq.org/JobDetails.pl?Key=6731 > > Changelog: > added more tests on object; > changed the implemention of some tests that caused "Err.number = 0" > rearranged the order of tests > --- > dlls/vbscript/global.c | 41 ++++++++++------------------------- > dlls/vbscript/tests/api.vbs | 53 > +++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 65 insertions(+), 29 deletions(-) > The tests are failing on wine on polish locale: LC_ALL=pl_PL make test ../../../tools/runtest -q -P wine -T ../../.. -M vbscript.dll -p vbscript_test.exe.so run && touch run.ok fixme:thread:GetThreadUILanguage : stub, returning default language. run.c:2102: Tests skipped: Skipping some tests in non-English locale fixme:vbscript:parse_script parser failed around L"<!--" fixme:vbscript:do_icall L"y" not found fixme:vbscript:DispatchEx_InvokeEx no letter/setter run.c:1917: Test failed: expected global_success_d run.c:1918: Test failed: expected global_success_i run.c:1920: Test failed: parse_script failed: 800a000d fixme:vbscript:ClassFactory_QueryInterface (0x7e2462ec)->({342d1ea0-ae25-11d1-89c5-006008c3fbfc} 0x33f7b0) fixme:vbscript:RegExp2_QueryInterface (0x130a88)->({fc4801a3-2ba9-11cf-a229-00aa003d7352} 0x33f74c) fixme:vbscript:interp_enumnext uninitialized fixme:vbscript:interp_newenum Unsupported for {VT_EMPTY} fixme:vbscript:interp_enumnext uninitialized fixme:vbscript:show_msgbox failed: 80004005 fixme:vbscript:show_msgbox blocked make: *** [run.ok] B³±d 3

2 6

Re: [PATCH] vbscript: Fixed CBool(try 4)
by Marvin May 2, 2014

May 2, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6774 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: dpnet/tests: Add a trailing '\n' to an ok() call.
by Marvin May 2, 2014

May 2, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6756 Your paranoid android. === build (build) === Patch failed to apply

1 0

Building Wine conformance tests on Windows
by Albert Szilvasy May 2, 2014

May 2, 2014

Hello there, It appears that it is not possible to build the Wine conformance tests on Windows as described here: http://www.winehq.org/site/docs/winedev-guide/testing-windows In particular, when I try to build against the latest Windows SDK I get all sorts of errors. Take for example, kernel32/tests/loader.c. It refers to IMAGE_FILE_MACHINE_ARM64. This symbol does not exist in winnt.h from Microsoft but does exist in the wine version. How do people build the conformance tests? Cross compile on Linux? Thanks, albert

6 7

Re: ole32/tests: Add a trailing '\n' to an ok() call.
by Marvin May 2, 2014

May 2, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6755 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH] ddraw/tests: Add a test for getdc palette handling (try 3).
by Marvin May 2, 2014

May 2, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6752 Your paranoid android. === wvistau64 (64 bit ddraw2) === ddraw2.c:5645: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw2.c:5645: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw2.c:5645: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw1) === ddraw1.c:4569: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw1.c:4569: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw1.c:4569: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw7) === ddraw7.c:6369: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6369: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6369: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw4) === ddraw4.c:6546: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw4.c:6546: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw4.c:6546: Test failed: Test 6: Got unexpected pitch 252, expected 256.

1 0

Re: [PATCH 3/3] wined3d: Remove broken gdi palette code.
by Marvin May 2, 2014

May 2, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6747 Your paranoid android. === wvistau64 (64 bit ddraw2) === ddraw2.c:5645: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw2.c:5645: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw2.c:5645: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw1) === ddraw1.c:4569: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw1.c:4569: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw1.c:4569: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw7) === ddraw7.c:6369: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6369: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6369: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw4) === ddraw4.c:6546: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw4.c:6546: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw4.c:6546: Test failed: Test 6: Got unexpected pitch 252, expected 256.

1 0

Re: [PATCH 1/3] ddraw/tests: Add a test for getdc palette handling (try 2).
by Henri Verbeet May 2, 2014

May 2, 2014

On 2 May 2014 13:43, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + * contains uninitialized garbage. See comments beflow for the P8 case. */ This is minor of course, but "below". > + /* See Win8 refcounting remarks in test_primary_palette. */ I think this is superfluous here as well. With those fixed, I think this set is ok.

1 0

Re: [PATCH 2/3] ddraw/tests: Test mipmap GetDC behavior.
by Marvin May 2, 2014

May 2, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6746 Your paranoid android. === wvistau64 (64 bit ddraw2) === ddraw2.c:5645: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw2.c:5645: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw2.c:5645: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw1) === ddraw1.c:4569: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw1.c:4569: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw1.c:4569: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw7) === ddraw7.c:6369: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6369: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6369: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw4) === ddraw4.c:6546: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw4.c:6546: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw4.c:6546: Test failed: Test 6: Got unexpected pitch 252, expected 256.

1 0

Re: [PATCH 1/3] ddraw/tests: Add a test for getdc palette handling (try 2).
by Marvin May 2, 2014

May 2, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6745 Your paranoid android. === wvistau64 (64 bit ddraw2) === ddraw2.c:5645: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw2.c:5645: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw2.c:5645: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw1) === ddraw1.c:4569: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw1.c:4569: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw1.c:4569: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw7) === ddraw7.c:6369: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6369: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6369: Test failed: Test 6: Got unexpected pitch 252, expected 256. === wvistau64 (64 bit ddraw4) === ddraw4.c:6546: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw4.c:6546: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw4.c:6546: Test failed: Test 6: Got unexpected pitch 252, expected 256.

1 0

Re: [PATCH] user32: Don't destroy in-use menus
by Ken Thomases May 2, 2014

May 2, 2014

On May 1, 2014, at 2:19 PM, Andrew Eikum wrote: > + /* two different kinds of "reference" counting. in_use is for internal > + * refcounting for e.g. submenus. user_destroyed indicates whether > + * DestroyMenu has been invoked on a handle returned by CreateMenu. */ > + BOOL in_use, user_destroyed; First, since in_use is a count, it probably shouldn't be a BOOL. Second, I haven't reviewed the menu code thoroughly, but I think that it would be better to conceptually separate the handle from the internal structure. Internal references to submenus and the like should be by pointers to the structure. The handle should only be used at the interface with external clients. Then, there should be only one reference count. It's the count of users of the structure. The handle represents one reference. Each place where a pointer to the structure is stored is another reference. DestroyMenu() should really destroy the handle (and thus decrement the reference count), not just mark it as "destroyed". -Ken

2 1

Re: dpnet: Implement IDirectPlay8LobbiedApplication Initialize (try 2)
by Stefan Dösinger May 2, 2014

May 2, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-02 07:26, schrieb Alistair Leslie-Hughes: > Hi, Remove the Initial value from Create function. The changes of > spaces was done on purpose, future patches will change the other > places. > > Changelog: dpnet: Implement IDirectPlay8LobbiedApplication > Initialize Looks good to me. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTY2cZAAoJEN0/YqbEcdMwKTgP/1rHmFZTq7GVcDfVyvjgrJvv BQmCMFJZs0/DYgy0+D+ZR5UccLaaoJD75+GyWjSuw2AITOHJ2q8kyREAms4nNQiR /DUa4ZDMeCFfVuC7aStSal2LOiMEqfZycrHa5ryu189mhoyObOT+xQtRa19rzxuJ OLN4IDe0eOSx1KyShiFzYueLY+oNnIf5IJ/omCTfvug5xPP45ZUby74VTXzmahD3 FU+oEBisuv2vXC7mHCjIsWUCadOh1G3UHtZ39/w/70Yj9HaxGipq6bxN4CD/5gho 99qy5JqqE+88gLTjgvsAFGoUpXCdc6k2hQXW9FviV/PbIYFy62tzmpmicmHVknKO XKrRP74l4bI4QutTxBOwN4d2SmGhFD/y8n0oi1c6SgwgfzdMO9nEv3Bx4F7d+pzi JZJnN7A++j5OInGow4xHd1b6oui55MLIMtbW3QJ7auBM+Ue0tB68UKYcrZkPYb29 JpmxFoNSJbqGAhw+0YH5KiemYKb7y/KD7uctrKodsbzQJFqA5gGEUTrTj7h2mo4+ kws3INzZlWJLMIoreaxtfNCco+SFtYIhD72io9KGSdIXc92GJOLTcG0JHXNC709s Rr3Ttl7hnYN6Y6YZsCpZQKE29ZsivUVUs4idL2AuYzHlUWbdJm3RUTRQVF7ncM2f OScvgQEx3PjLqCg861pY =pRHL -----END PGP SIGNATURE-----

1 0

Re: dpnet: Store DPN_SP_CAPS as part of the object
by Stefan Dösinger May 2, 2014

May 2, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-02 07:58, schrieb Alistair Leslie-Hughes: > +void init_dpn_sp_caps(DPN_SP_CAPS * pdpspCaps) DECLSPEC_HIDDEN; Why do you need the declaration in the header file? As far as I can see you're calling it from one file only. If you'll need it in a later patch just add it in the patch that needs it and keep the function static for now. Please avoid the Hungarian notation ("pdpspCaps") in new code. While you're at it: The placement of the * is inconsistent with the rest of the code. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTY2axAAoJEN0/YqbEcdMwOGYP/12lXZrx8HnEa1y1N3VHd/7W DMA9os0kqxyEuvBO0+4QCaTi8s8yjhlA0034xK4Tjl+ZYCy3sK8cx+1q1sM4PV2L XYxaRxddqWtNkuEVXbm9Kcq/P+xIzv+d8zcZ0j8WcPOX2fn0Y6YTyBGDHKQZGq/y QFLN1rLDoUksJ78L6Ik7s6zalGLmPw3SeZ7vsTvjiEaXBbbj/wBXy1LY/I4lVxXO uleeQpApV/h/3ul5mne9hnU5SkpskW6ECaNTW1ggmxA+GCSzy0UGK7Cd+LOb/gL+ wLaFXzdBop25LyGygNuzd6w+SwZ2VULPJY+IwVvZvprGMMQYYxrrdtc6B5kgJm51 tpitxyX/s2IqJUFDLPOp5yDUowmfrNWlrptS6iOjJ/j8g29PvTz4MAmoABm8UHm+ eDYUsn1jQhWp9zA7cuZL5G9JpxA7hY5xwlttBZLHqyYWzsNqC0c0XELwp6sCMAqx rH9RmFNH/Oo75puFav0YdfIQ1Zwmt8wgnaobFS1COIZ8u3gXAc36HsrPfQiaPIPQ TYiO7EwPAFx3+Tz1FHNln/PjUnbbND7s5KJtRs9CxVMiGnN3oyw7wNRyB7HbKP0u YcMXCTv6MlpMnFVSXM7zf0E1ahxTmMY3Z6qr+Y/N3EQVY+vHKxNBlXNZsaLfiJqj 8aXBZ1QdgGJ//Jn0dn3d =VadZ -----END PGP SIGNATURE-----

1 0

Re: dpnet: Implement IDirectPlay8Client Initialize
by Stefan Dösinger May 2, 2014

May 2, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-01 07:41, schrieb Alistair Leslie-Hughes: > +START_TEST(client) > +{ > + test_init_dp(); > + test_enum_service_providers(); > + test_enum_hosts(); > + test_get_sp_caps(); > + test_cleanup_dp(); > +} I think that needs splitting. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIbBAEBAgAGBQJTYn8SAAoJEN0/YqbEcdMwonoP9A8x5zWuCAlVxAVYi9Hsz7yL jkSay3KVxAmyU1mkboG3LBVEQP/ZSkD99oXlu2t/++GL2+FZuX9ms9vJNSxmETQn WBdu9LRqqh8QrGKuKjdyjr8aPzphqAkwNkfbHFpfvTZ9WDGqSXV2atv7pFB7ytfH 4Qrs//RYXE6n6feQB2LGSp6faupX+SGWA5hAKyWD3oKUthMNTo4C9lCjeBKg7az1 kvY45VbTthruv+YHuPnMBZk/hH5yZpxhyrM7yvBwMz/raia05Rf4Ok9xrp8FVX9k IyYX+vgYWi5OtK5XRtpwih3qpnk1v975owTcHmK/ngU2g/wkCmYszXhs+1t5hVti e4rMDByQXXgdFKV0w9uT1YnUwqgRIFMizKGLmBEougFzjtUVndXwK4U7tE0ar2Pd wwDnkQ5m0mcpZ2X690aGqnXhXg8hxsvMCFEDNQvwStH/2d1+2qpjrkaZ5WSW5W7E kEn1tTcqipoK2AVZ49ZXBa6xdtPn/ZafK3YWzwv5nvv52BhL7XE3HIByZvcuD5IM LdEr3O0xVojJLRoJ7f9dzUJWK+Fgi5TvVRMabzYEMemLWfQLEuNIZvse7JvXXu+5 bomwR2QR8+2+xv1L60CbMVepidN8bduQXNyzQdE974ZeK8ahLxWvUBS8mAlmb9aF /xU3BmBfPBwIVQIxw+s= =MrVx -----END PGP SIGNATURE-----

2 1

Re: [PATCH] vbscript: Fixed CBool(try 3)
by Marvin May 1, 2014

May 1, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6732 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvista (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found

1 0

Re: dpnet: Implement IDirectPlay8LobbiedApplication Initialize
by Stefan Dösinger May 1, 2014

May 1, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-01 07:42, schrieb Alistair Leslie-Hughes: > static HRESULT WINAPI IDirectPlay8LobbiedApplicationImpl_RegisterProgram(IDirectPlay8LobbiedApplication *iface, > @@ -191,6 +201,11 @@ HRESULT DPNET_CreateDirectPlay8LobbiedApp(LPCLASSFACTORY iface, LPUNKNOWN punkOu > } > app->IDirectPlay8LobbiedApplication_iface.lpVtbl = &DirectPlay8LobbiedApplication_Vtbl; > app->ref = 0; > + app->msghandler = NULL; > + app->flags = 0; > + app->usercontext = NULL; > + app->connection = NULL; This is redundant, HEAP_ZERO_MEMORY clears that for you. Also, in the other patches you changed the indentation to 4 spaces, but not here. If this was intentional I'm fine with that - just pointing it out. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTYn7KAAoJEN0/YqbEcdMwV2UP/jkWB0vY5CLO+A0z9JISmIJT V+dlgPTTWHYgxTVBpDVoBlfYl3vmVTqoHPMExWef8lts0Dx1+Gv0pDQZpwUFXJ9P 9jOBZsuyNwcwU1uSm8BvFXQFWs6XCUoQn9nHC5Y9GNezLQy4KRpPX3xkHf1QuHZw CI/Z8oLwcHT9zy4uWUcYe1ciATCRHx9noLFR7cHIIkOuI1kakptX1DYMp39uo7Hg qah9QP+yA88MDnXQlUSLOSui0dd7lmbqPTHwsHAm8VCgUWUdqFIT0Yt5kITxZjyW tKz1XM7aRZ+V4kbdg8R7PbmFdent/xa79ceOnOIg5MQEWc3LBY+ynh5vgAqEUgAA ynIFlJMyB09D9JRVKj6ETxoIrx+m+FN/z6xD66GvD9ehqQZXH8v+fUc+xyGg0d5o Yj+2R0HJLUEtN7h3n1o9+8EJ6YhmceyOnu7OtrSN7Mapw7qXT4aESSCiRy8j7c1T fy3qvPrmEPRjCN8e1Tu0IJn4EyQl6Eke9BB4CXtuxhOgNC+Z2GekgU1k4Dj78iiQ VXpD9jw/CblEYv+iu4Lvo+E76nHMvF4R0M/UooS+urSnIfKGiNSorMCJOQ+xM1hs b634KfA1gpfq/foDRY0pVcxQVEbN5nKS8vAiv7wul/bhIoWMAZr2DktBdYP08Ye2 pbmU+Nd4X5lclBbj2Rnq =jFdr -----END PGP SIGNATURE-----

1 0

Re: [PATCH 2/6] wined3d: Validate and handle query size parameter.
by Marvin May 1, 2014

May 1, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6720 Your paranoid android. === w864 (32 bit device) === device.c:3856: Test failed: Occlusion query returned an unexpected result (0xffff0000). device.c:3861: Test failed: Occlusion query returned an unexpected result (0x00000000). device.c:3866: Test failed: Occlusion query returned an unexpected result (0x00000000). === w864 (64 bit device) === device.c:3856: Test failed: Occlusion query returned an unexpected result (0xffff0000). device.c:3861: Test failed: Occlusion query returned an unexpected result (0x00000000). device.c:3866: Test failed: Occlusion query returned an unexpected result (0x00000000).

1 0

Re: [PATCH 1/6] d3d9/tests: Test GetData behavior with various size values.
by Marvin May 1, 2014

May 1, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6719 Your paranoid android. === w864 (32 bit device) === device.c:3856: Test failed: Occlusion query returned an unexpected result (0xffff0000). device.c:3861: Test failed: Occlusion query returned an unexpected result (0x00000000). device.c:3866: Test failed: Occlusion query returned an unexpected result (0x00000000). === w864 (64 bit device) === device.c:3856: Test failed: Occlusion query returned an unexpected result (0xffff0000). device.c:3861: Test failed: Occlusion query returned an unexpected result (0x00000000). device.c:3866: Test failed: Occlusion query returned an unexpected result (0x00000000).

1 0

Re: [PATCH] vbscript: Fixed CBool(try 2)
by Piotr Caban May 1, 2014

May 1, 2014

On 05/01/14 10:16, Shuai Meng wrote: > Changelog: > added tests on object subtype. > improved CBool. > > https://newtestbot.winehq.org/JobDetails.pl?Key=6689 > > --- > dlls/vbscript/global.c | 41 > ++++++++++++----------------------------- > dlls/vbscript/tests/api.vbs | 42 > ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 54 insertions(+), 29 deletions(-) The tests are not passing on wine: run.c:1013: Test failed: api.vbs: L"Err.number = 0" run.c:1013: Test failed: api.vbs: L"Err.number = 0" run.c:1013: Test failed: api.vbs: L"Err.number = 0" These are the failing tests: Call testCBoolError("#TRUE#", 458) Call testCBoolError("#FALSE#", 458) Call testCBoolError(MyObject, 458) Could you please also add following tests: MyObject.myval = 1 Call ok(CBool(MyObject) = True, "CBool(MyObject) = " & CBool(MyObject)) MyObject.myval = 0 Call ok(CBool(MyObject) = False, "CBool(MyObject) = " & CBool(MyObject))

3 3

Re: [PATCH 11/11] oleacc: Add tests for default client accessible object (try2)
by Marvin May 1, 2014

May 1, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6716 Your paranoid android. === w2000pro (32 bit main) === main.c:347: Test failed: V_I4(&v) = 8000 === w2008s64 (64 bit main) === main.c:223: Test failed: wparam = 0 main.c:229: Test failed: unexpected (-12) === w864 (64 bit main) === main.c:223: Test failed: wparam = 0 main.c:229: Test failed: unexpected (-12)

1 0

Re: [PATCH 11/11] oleacc: Add tests for default client accessible object
by Marvin May 1, 2014

May 1, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6714 Your paranoid android. === build (build) === Unable to regenerate dlls/oleacc/Makefile Unable to regenerate dlls/oleacc/Makefile

1 0

regsvr32 patches (argument handler, unicode)
by Hugh McMaster May 1, 2014

May 1, 2014

Is there a reason that patches 104221 to 104224 were not committed? Perhaps a test case is needed? [1/4] regsvr32: Implement new method of handling arguments/flags ( http://source.winehq.org/patches/data/104221 ) This patch replaces the existing argument/flag handler in regsvr32.c (mostly repeated calls to strcasecmp) with a new handler based on a switch statement. [2/4] regsvr32: Convert to Unicod ( http://source.winehq.org/patches/data/104222 ) This patch modifies the source in regsvr32.c so that regsvr32.exe runs entirely in Unicode. Note that the Windows version has Unicode support. Wine does not (yet). [3/4] regsvr32: Add WriteFile support ( http://source.winehq.org/patches/data/104223 ) This patch adds WriteFile() support to regsvr32's output_write() function. It is used in the event that WriteConsoleW() fails. [4/4] regsvr32: Fix a number of errors in the comments of regsvr32.c ( http://source.winehq.org/patches/data/104224 ) This patch fixes a number of spelling, grammar and logic errors in the comments of regsvr32.c. Thank you. -- Hugh McMaster

1 0

Re: user32: Reduce the minimum Set[System]Timer from 15 ms to 10 ms.
by Marvin May 1, 2014

May 1, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6713 Your paranoid android. === wxppro (32 bit msg) === msg.c:13332: Test failed: 9: WaitForSingleObject failed === w7u (32 bit msg) === msg.c:12098: Test failed: unexpected hwnd 00150136 msg.c:12120: Test failed: bad time 31ef4/31f14

1 0

AW: imagehlp: Implement (parts of) BindImageEx (try 5)
by Bernhard Reiter May 1, 2014

May 1, 2014

*ping* No comments or reviews? -------- Ursprüngliche Nachricht -------- Von: Bernhard Reiter <ockham(a)raz.or.at> Datum: An: wine-patches(a)winehq.org Betreff: imagehlp: Implement (parts of) BindImageEx (try 5) Some more fixes to make tests pass on Windows, and to adjust implementation accordingly.

1 0

Re: msi: Expand REG_EXPAND_SZ keys when resolving AppSearch entries
by Hans Leidekker May 1, 2014

May 1, 2014

On Wed, 2014-04-30 at 16:08 +0200, Jérôme Gardou wrote: > Resent for lack of comments on wine-devel. > > --- > dlls/msi/appsearch.c | 22 ++++++++++++++++++++++ > dlls/msi/tests/package.c | 22 ++++++++++++++++++++++ > 2 files changed, 44 insertions(+) Looks good, thanks.

1 0

Re: [PATCH] vbscript: Fixed CBool(try 2)
by Marvin May 1, 2014

May 1, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6706 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvista (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found

1 0

Re: msi: Expand REG_EXPAND_SZ keys when resolving AppSearch entries
by Marvin May 1, 2014

May 1, 2014

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 https://testbot.winehq.org/JobDetails.pl?Key=6702 Your paranoid android. === w2000pro (32 bit package) === package.c:3978: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:3984: Test failed: Expected "C:\\FileName2", got "C:\FileName2" package.c:3990: Test failed: Expected "C:\\FileName3", got "C:\FileName3" package.c:4002: Test failed: Expected "C:\\FileName5", got "C:\FileName5" package.c:4008: Test failed: Expected "C:\\", got "C:\" package.c:4014: Test failed: Expected "C:\\", got "C:\" package.c:4030: Test failed: Expected "C:\\FileName8.dll", got "C:\FileName8.dll" package.c:4041: Test failed: Expected "C:\\FileName10.dll", got "C:\FileName10.dll" package.c:4500: Test failed: Expected ERROR_SUCCESS, got 1627 package.c:4592: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:4603: Test failed: Expected "C:\\", got "C:\" package.c:4614: Test failed: Expected "C:\\", got "C:\" package.c:4664: Test failed: Expected "C:\\FileName3.dll", got "C:\FileName3.dll" package.c:4675: Test failed: Expected "C:\\FileName5.dll", got "C:\FileName5.dll" package.c:4690: Test failed: Expected "C:\\", got "C:\" package.c:4695: Test failed: Expected "", got "C:\" package.c:4711: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:4720: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:4970: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:4981: Test failed: Expected "C:\\", got "C:\" package.c:4987: Test failed: Expected "C:\\", got "C:\" package.c:5008: Test failed: Expected "C:\\FileName2.dll", got "C:\FileName2.dll" package.c:5019: Test failed: Expected "C:\\FileName4.dll", got "C:\FileName4.dll" package.c:5259: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:5265: Test failed: Expected "C:\\", got "C:\" package.c:5282: Test failed: Expected "C:\\one\two\three\FileName2", got "C:\one\two\three\FileName2" package.c:5293: Test failed: Expected "C:\\one\two\three\FileName2", got "C:\one\two\three\FileName2" package.c:5301: Test failed: Expected "C:\\FileName3.dll", got "C:\FileName3.dll" package.c:5645: Test failed: Expected C:\\winetest-package.msi, got C:\winetest-package.msi package.c:6277: Test failed: Expected C:\\abelisaurus or empty string, got C:\abelisaurus package.c:6301: Test failed: Expected C:\\ or empty string, got C:\ package.c:6345: Test failed: Expected C:\\ or empty string, got C:\ package.c:6354: Test failed: Expected C:\\neosodon\ or empty string, got C:\neosodon\ package.c:6584: Test failed: Expected "C:\\", got "C:\" package.c:6585: Test failed: Expected 4, got 3 package.c:6592: Test failed: Expected "C:\\", got "C:\" package.c:6593: Test failed: Expected 4, got 3 package.c:6609: Test failed: Expected "C:\\", got "C:\" package.c:6610: Test failed: Expected 4, got 3 package.c:6616: Test failed: Expected "C:\\", got "C:\" package.c:6617: Test failed: Expected 4, got 3 package.c:6624: Test failed: Expected "C:\\subsource\", got "C:\subsource\" package.c:6625: Test failed: Expected 14, got 13 package.c:6632: Test failed: Expected "C:\\subsource\sub2\", got "C:\subsource\sub2\" package.c:6633: Test failed: Expected 19, got 18 package.c:6643: Test failed: Expected "C:\\", got "C:\" package.c:6644: Test failed: Expected 4, got 3 package.c:6651: Test failed: Expected "C:\\", got "C:\" package.c:6652: Test failed: Expected 4, got 3 package.c:6668: Test failed: Expected "C:\\", got "C:\" package.c:6669: Test failed: Expected 4, got 3 package.c:6675: Test failed: Expected "C:\\", got "C:\" package.c:6676: Test failed: Expected 4, got 3 package.c:6683: Test failed: Expected "C:\\subsource\", got "C:\subsource\" package.c:6684: Test failed: Expected 14, got 13 package.c:6691: Test failed: Expected "C:\\subsource\sub2\", got "C:\subsource\sub2\" package.c:6692: Test failed: Expected 19, got 18 package.c:6702: Test failed: Expected "C:\\", got "C:\" package.c:6703: Test failed: Expected 4, got 3 package.c:6710: Test failed: Expected "C:\\", got "C:\" package.c:6711: Test failed: Expected 4, got 3 package.c:6727: Test failed: Expected "C:\\", got "C:\" package.c:6728: Test failed: Expected 4, got 3 package.c:6734: Test failed: Expected "C:\\", got "C:\" package.c:6735: Test failed: Expected 4, got 3 package.c:6742: Test failed: Expected "C:\\subsource\", got "C:\subsource\" package.c:6743: Test failed: Expected 14, got 13 package.c:6750: Test failed: Expected "C:\\subsource\sub2\", got "C:\subsource\sub2\" package.c:6751: Test failed: Expected 19, got 18 package.c:6761: Test failed: Expected "C:\\", got "C:\" package.c:6762: Test failed: Expected 4, got 3 package.c:6769: Test failed: Expected "C:\\", got "C:\" package.c:6770: Test failed: Expected 4, got 3 package.c:6786: Test failed: Expected "C:\\", got "C:\" package.c:6787: Test failed: Expected 4, got 3 package.c:6793: Test failed: Expected "C:\\", got "C:\" package.c:6794: Test failed: Expected 4, got 3 package.c:6801: Test failed: Expected "C:\\subsource\", got "C:\subsource\" package.c:6802: Test failed: Expected 14, got 13 package.c:6809: Test failed: Expected "C:\\subsource\sub2\", got "C:\subsource\sub2\" package.c:6810: Test failed: Expected 19, got 18 package.c:6825: Test failed: Expected 4, got 3 package.c:6842: Test failed: Expected 4, got 3 package.c:6848: Test failed: Expected ERROR_MORE_DATA, got 0 package.c:6851: Test failed: Expected 4, got 3 package.c:6858: Test failed: Expected "C:\\", got "C:\" package.c:6859: Test failed: Expected 4, got 3 package.c:6870: Test failed: Expected "C:\\", got "C:\" package.c:6871: Test failed: Expected 4, got 3 package.c:6966: Test failed: Expected "C:\\", got "C:\" package.c:6967: Test failed: Expected 4, got 3 package.c:6974: Test failed: Expected "C:\\", got "C:\" package.c:6975: Test failed: Expected 4, got 3 package.c:6984: Test failed: Expected "C:\\", got "C:\" package.c:6985: Test failed: Expected 4, got 3 package.c:6993: Test failed: Expected "C:\\", got "C:\" package.c:6994: Test failed: Expected 4, got 3 package.c:7000: Test failed: Expected "C:\\", got "C:\" package.c:7001: Test failed: Expected 4, got 3 package.c:7008: Test failed: Expected "C:\\", got "C:\" package.c:7009: Test failed: Expected 4, got 3 package.c:7016: Test failed: Expected "C:\\", got "C:\" package.c:7017: Test failed: Expected 4, got 3 package.c:7027: Test failed: Expected "C:\\", got "C:\" package.c:7028: Test failed: Expected 4, got 3 package.c:7035: Test failed: Expected "C:\\", got "C:\" package.c:7036: Test failed: Expected 4, got 3 package.c:7045: Test failed: Expected "C:\\", got "C:\" package.c:7046: Test failed: Expected 4, got 3 package.c:7054: Test failed: Expected "C:\\", got "C:\" package.c:7055: Test failed: Expected 4, got 3 package.c:7061: Test failed: Expected "C:\\", got "C:\" package.c:7062: Test failed: Expected 4, got 3 package.c:7069: Test failed: Expected "C:\\", got "C:\" package.c:7070: Test failed: Expected 4, got 3 package.c:7077: Test failed: Expected "C:\\", got "C:\" package.c:7078: Test failed: Expected 4, got 3 package.c:7088: Test failed: Expected "C:\\", got "C:\" package.c:7089: Test failed: Expected 4, got 3 package.c:7096: Test failed: Expected "C:\\", got "C:\" package.c:7097: Test failed: Expected 4, got 3 package.c:7106: Test failed: Expected "C:\\", got "C:\" package.c:7107: Test failed: Expected 4, got 3 package.c:7115: Test failed: Expected "C:\\", got "C:\" package.c:7116: Test failed: Expected 4, got 3 package.c:7122: Test failed: Expected "C:\\", got "C:\" package.c:7123: Test failed: Expected 4, got 3 package.c:7130: Test failed: Expected "C:\\", got "C:\" package.c:7131: Test failed: Expected 4, got 3 package.c:7138: Test failed: Expected "C:\\", got "C:\" package.c:7139: Test failed: Expected 4, got 3 package.c:7149: Test failed: Expected "C:\\", got "C:\" package.c:7150: Test failed: Expected 4, got 3 package.c:7157: Test failed: Expected "C:\\", got "C:\" package.c:7158: Test failed: Expected 4, got 3 package.c:7167: Test failed: Expected "C:\\", got "C:\" package.c:7168: Test failed: Expected 4, got 3 package.c:7176: Test failed: Expected "C:\\", got "C:\" package.c:7177: Test failed: Expected 4, got 3 package.c:7183: Test failed: Expected "C:\\", got "C:\" package.c:7184: Test failed: Expected 4, got 3 package.c:7191: Test failed: Expected "C:\\", got "C:\" package.c:7192: Test failed: Expected 4, got 3 package.c:7199: Test failed: Expected "C:\\", got "C:\" package.c:7200: Test failed: Expected 4, got 3 package.c:7297: Test failed: Expected "C:\\long\", got "C:\long\" package.c:7298: Test failed: Expected 9, got 8 package.c:7307: Test failed: Expected "C:\\long\", got "C:\long\" package.c:7308: Test failed: Expected 9, got 8 package.c:7317: Test failed: Expected "C:\\long\", got "C:\long\" package.c:7318: Test failed: Expected 9, got 8 package.c:7329: Test failed: Expected "C:\\two\", got "C:\two\" package.c:7330: Test failed: Expected 8, got 7 package.c:7341: Test failed: Expected "C:\\four\", got "C:\four\" package.c:7342: Test failed: Expected 9, got 8 package.c:7353: Test failed: Expected "C:\\six\", got "C:\six\" package.c:7354: Test failed: Expected 8, got 7 package.c:7365: Test failed: Expected "C:\\eight\", got "C:\eight\" package.c:7366: Test failed: Expected 10, got 9 package.c:7377: Test failed: Expected "C:\\ten\", got "C:\ten\" package.c:7378: Test failed: Expected 8, got 7 package.c:7389: Test failed: Expected "C:\\twelve\", got "C:\twelve\" package.c:7390: Test failed: Expected 11, got 10 package.c:7441: Test failed: Expected "C:\\short\", got "C:\short\" package.c:7442: Test failed: Expected 10, got 9 package.c:7451: Test failed: Expected "C:\\short\", got "C:\short\" package.c:7452: Test failed: Expected 10, got 9 package.c:7461: Test failed: Expected "C:\\short\", got "C:\short\" package.c:7462: Test failed: Expected 10, got 9 package.c:7473: Test failed: Expected "C:\\one\", got "C:\one\" package.c:7474: Test failed: Expected 8, got 7 package.c:7485: Test failed: Expected "C:\\three\", got "C:\three\" package.c:7486: Test failed: Expected 10, got 9 package.c:7497: Test failed: Expected "C:\\five\", got "C:\five\" package.c:7498: Test failed: Expected 9, got 8 package.c:7509: Test failed: Expected "C:\\seven\", got "C:\seven\" package.c:7510: Test failed: Expected 10, got 9 package.c:7521: Test failed: Expected "C:\\nine\", got "C:\nine\" package.c:7522: Test failed: Expected 9, got 8 package.c:7533: Test failed: Expected "C:\\eleven\", got "C:\eleven\" package.c:7534: Test failed: Expected 11, got 10 package.c:7670: Test failed: Expected "C:\\", got "C:\" package.c:7671: Test failed: Expected 4, got 3 package.c:7682: Test failed: Expected "C:\\", got "C:\" package.c:7683: Test failed: Expected 4, got 3 package.c:7690: Test failed: Expected "C:\\", got "C:\" package.c:7691: Test failed: Expected 4, got 3 package.c:7788: Test failed: Expected "C:\\", got "C:\" package.c:7789: Test failed: Expected 4, got 3 package.c:7796: Test failed: Expected "C:\\", got "C:\" package.c:7797: Test failed: Expected 4, got 3 package.c:7804: Test failed: Expected "C:\\", got "C:\" package.c:7805: Test failed: Expected 4, got 3 package.c:7824: Test failed: Expected "C:\\", got "C:\" package.c:7825: Test failed: Expected 4, got 3 package.c:7832: Test failed: Expected "C:\\", got "C:\" package.c:7833: Test failed: Expected 4, got 3 package.c:7852: Test failed: Expected "C:\\", got "C:\" package.c:7853: Test failed: Expected 4, got 3 package.c:7860: Test failed: Expected "C:\\", got "C:\" package.c:7861: Test failed: Expected 4, got 3 package.c:7880: Test failed: Expected "C:\\", got "C:\" package.c:7881: Test failed: Expected 4, got 3 package.c:7888: Test failed: Expected "C:\\", got "C:\" package.c:7889: Test failed: Expected 4, got 3 === w7u (32 bit package) === The test timed out

1 0