March 2015 - 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

Speed of gdi vs opengl DirectDrawRenderer
by Jonas Maebe Oct. 11, 2015

Oct. 11, 2015

Hi, I had a problem with Majesty Gold HD running at glacial speed on my machine (quad Core i5 2.9GHz, NVidia GeForce GT 750M 1GB, OS X 10.9.5). I'm using wine 1.7.35, but I've had similar problems with older wine versions. It's a DirectDraw7 game that has been partially remastered to run on modern systems, but still uses DirectDraw7. This is a common problem on Windows too, but generally can be resolved by telling the game to use the DirectDraw blitter (instead of blitting itself). That didn't help on Wine though. I profiled wine (Instruments time profile) and noticed that most time was spent in wined3d's convert_r5g6b5_x8r8g8b8. Replacing that routine with an optimized sse2 version from pixman did not make much of a difference. Then I discovered that if I told the game to render to a 16 bit instead of to a 32 bit surface, wine would let OpenGL handle the colour conversion. Unfortunately, while this significantly reduced wine's cpu usage, it by no means made the game any faster. Looking at the OpenGL Driver Monitor stats, it seems the cpu was simply waiting all the time on the GPU, probably while it was blitting all of those 1920x1080 images to the screen. Reducing the resolution to the lowest supported by the game (800x600) made it slightly faster, but not much. Next, I added the DirectDrawRenderer registry key and set it to gdi. Now, while it's still slow at 1920x1080, the game runs much faster at 800x600 and even still at 1024x768. Profiling the gdi renderer shows that it has way higher cpu usage than the OpenGL renderer (virtually all in convert_to_8888), but it seems that for some reason it has causes much less traffic to the GPU. The wiki's wording suggests the gdi renderer is deprecated though. Does that mean this qualifies as a bug in the OpenGL renderer (maybe it tries to update the screen more often than necessary, saturating the bus that way?), and are there any things I can try to narrow down why the gdi renderer is so much faster? I didn't immediately see where it blits things actually to the screen. Thanks, Jonas

4 10

[PATCH] Use asserts for mmap failure modes
by Michael Gilbert July 26, 2015

July 26, 2015

Hi, Using exit in shared libraries is a discouraged practice, and wine's mmap implementation currently does that. I attach a proposed change using asserts instead. Let me know if you have any feedback. Best wishes, Mike (btw I'm the debian wine maintainer)

2 2

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

Application for GSoC 2015 - Implement findstr.exe for Wine.
by KaiPeng Zeng April 19, 2015

April 19, 2015

Hi folks, I’m Kaipeng Zeng who is a Linux user and Wine/CrossOver user from China. I am major in Biomedical Engineering in Guangdong Pharmaceutical University. I’d like to apply GSoC to work for Wine Project this year. My proposal is "Implementing findstr.exe for Wine". Though findstr is a quite independent program in Wine, I think it is valuable to implement. As far as I knew, there are some bugs about findstr in Bugzilla[1]. Any other programs in Chinese depend on it too. The implementation of findstr will help these programs and all the programs will also be good tests for our implementation. Besides, I think the code of grep will be helpful for implementing findstr. There are three parts in my plan: === Part 1: Add more tests for findstr.exe === I have submitted a patch for findstr’s test to wine-patches[2]. I will add more tests to prepare for the implementation. === Part 2: Implement an initial findstr.exe === With enough tests, I will try to implement the findstr gradually. My middle goal is having an initial implementation of findstr which can handle some simple work. Bug 35254[3] may be fixed after this part is finished. === Part 3: Add more parameters implementation === In this part, I will add more tests and try to implement more arguments for findstr, let it solve more things. [1] https://bugs.winehq.org/buglist.cgi?quicksearch=findstr&list_id=178519 [2] http://source.winehq.org/patches/data/110182 [3] https://bugs.winehq.org/show_bug.cgi

1 2

WineConf 2015
by Michael Stefaniuc April 17, 2015

April 17, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello guys, after we rethought WineConf and did it at/during FOSDEM for the last two years, it is time for a real WineConf again. We are missing too much our keynote, our governance discussions as well as our hackatons. Also the two full days should give more time for the most important topic aka the hallway discussions. After two years in Europe the old tradition would call for a session over in USA/Canada but this is not a strict requirement. Now the most important thing is to find volunteers that would want to host the WineConf. They have the bigger say in the date too, there are two options: - - either in late spring (preferred by me), - - or early fall (preferred by Jeremy) I have started also http://wiki.winehq.org/WineConf2015 please feel free to add agenda topics to it. bye michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTY5awACgkQ0ei8kcpE1VG2YQCguwUys0se+wV96lPfjZ+Qi6LJ 8ooAoJDxist2eZLgMXsRqUZVloGpBRgz =7Ta5 -----END PGP SIGNATURE-----

6 12

Re: [PATCH] vbscript: Implemented Oct(try 4)
by Marvin April 1, 2015

April 1, 2015

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=12481 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (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

3 2

Re: [PATCH 4/4] d3drm/tests: Add QueryInterface tests for IDirect3DRMFrame3
by Aaryaman Vasishta March 31, 2015

March 31, 2015

The tests also pass when the frame is created via IDirect3DRM_CreateFrame and IDirect3DRM2_CreateFrame. On Tue, Mar 31, 2015 at 1:36 AM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > --- > dlls/d3drm/tests/d3drm.c | 99 > ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 99 insertions(+) > > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index 515aace..6029b1a 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -1841,6 +1841,104 @@ static void test_d3drm_qi(void) > IDirect3DRM_Release(d3drm); > } > > +static void test_frame_qi(void) > +{ > + static const struct qi_test tests[] = > + { > + { &IID_IDirect3DRMFrame3, &IID_IDirect3DRMFrame3, S_OK, > FALSE }, > + { &IID_IDirect3DRMFrame2, &IID_IDirect3DRMFrame3, S_OK, > FALSE }, > + { &IID_IDirect3DRMFrame, &IID_IDirect3DRMFrame3, S_OK, > FALSE }, > + { &IID_IDirect3DRM, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMDevice, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMObject, &IID_IDirect3DRMFrame3, S_OK, > FALSE }, > + { &IID_IDirect3DRMDevice2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMDevice3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMViewport, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMViewport2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRM3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRM2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMVisual, &IID_IDirect3DRMFrame3, S_OK, > FALSE }, > + { &IID_IDirect3DRMMesh, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMMeshBuilder, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMMeshBuilder2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMMeshBuilder3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMFace, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMFace2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMLight, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMTexture, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMTexture2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMTexture3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMWrap, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMMaterial, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMMaterial2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMAnimation, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMAnimation2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMAnimationSet, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMAnimationSet2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMObjectArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMDeviceArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMViewportArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMFrameArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMVisualArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMLightArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMPickedArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMFaceArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMAnimationArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMUserVisual, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMShadow, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMShadow2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMInterpolator, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMProgressiveMesh, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMPicked2Array, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMClippedVisual, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawClipper, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawSurface7, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawSurface4, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawSurface3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawSurface2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawSurface, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DDevice7, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DDevice3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DDevice2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DDevice, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3D7, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3D3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3D2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3D, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDraw7, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDraw4, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDraw3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDraw2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDraw, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DLight, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IUnknown, &IID_IDirect3DRMFrame3, S_OK, > FALSE }, > + }; > + HRESULT hr; > + IDirect3DRM *d3drm; > + IDirect3DRM3 *d3drm3; > + IDirect3DRMFrame3 *frame3; > + > + hr = Direct3DRMCreate(&d3drm); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", > hr); > + > + if (FAILED(hr = IDirect3DRM_QueryInterface(d3drm, &IID_IDirect3DRM3, > (void **)&d3drm3))) > + { > + win_skip("Cannot get IDirect3DRM3 interface (hr = %x), skipping > tests\n", hr); > + IDirect3DRM_Release(d3drm); > + return; > + } > + > + hr = IDirect3DRM3_CreateFrame(d3drm3, NULL, &frame3); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRMFrame3 interface (hr = > %x)\n", hr); > + CHECK_REFCOUNT(frame3, 1); > + > + test_qi("frame_qi", (IUnknown *)frame3, &IID_IDirect3DRMFrame3, > tests, sizeof(tests) / sizeof(*tests)); > + > + IDirect3DRMFrame3_Release(frame3); > + IDirect3DRM3_Release(d3drm3); > + IDirect3DRM_Release(d3drm); > +} > + > START_TEST(d3drm) > { > test_MeshBuilder(); > @@ -1857,4 +1955,5 @@ START_TEST(d3drm) > test_d3drm_load(); > test_frame_mesh_materials(); > test_d3drm_qi(); > + test_frame_qi(); > } > -- > 1.9.3 (Apple Git-50) > >

2 2

Re: [PATCH] comctl32: Handle BM_SETSTATE sent to themed buttons.
by Nikolay Sivov March 31, 2015

March 31, 2015

On 03/31/2015 10:45 PM, Mark Harmstone wrote: > This patch changes comctl32 to handle BM_SETSTATE itself when sent to > a themed button, rather than forwarding it to user32. This way, the > theming isn't temporarily lost when user32 repaints it. > > + case BM_SETSTATE: > + { > + int state = (int)SendMessageW(hwnd, BM_GETSTATE, 0, 0); > + if (wParam) > + SetWindowLongW(hwnd, 0, state | BST_PUSHED); > + else > + SetWindowLongW(hwnd, 0, state & ~BST_PUSHED); > + > + InvalidateRect(hwnd, NULL, FALSE); > + break; > + } > + I guess you can GetWindowLongW(...,0,...) instead of sending a message? But what's more important is that all these difference in behavior comparing to user32 controls should not be visible only when you have an active theme. It's actually another version of same Button control with additional messages and different behavior in some aspects, including theming-aware drawing. So my point is that theming support is secondary, what's important is class redirection support, and I'm worried if these theming-only changes will make it more difficult to fix properly later. P.S. 0 window data index is actually implementation details of user32 (I don't know if it's compatible with native one with that regard or not).

1 0

Re: gdiplus/tests: Use printf() for memory dumps instead of trace(). (try 2)
by Thomas Faber March 31, 2015

March 31, 2015

On 2015-03-29 12:29, Thomas Faber wrote: > trace is unsuitable since it adds a file:line prefix every time. Is there a preferred way to handle this instead of using printf? Or is this simply a case that seems pointless to fix because tests should never fail anyway (in which case a patch to remove these dumps completely might make sense)? Thanks! -Thomas PS: Here's what I see with trace(), which was my reasoning for the patch: image.c:4241: Test marked todo: 16: data should match image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 80image.c:4249: 80image.c:4249: 80image.c:4249: 80image.c:4249: 80image.c:4249: 80image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4250:

2 1

Re: [PATCH] gdiplus: Avoid unnecessary post-to-pre-multiplied alpha conversions in GdipDrawImagePointsRect
by Vincent Povirk March 31, 2015

March 31, 2015

On Tue, Mar 31, 2015 at 9:05 AM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > + if (bg_alpha == 0) return fg; This doesn't seem right. Foreground is premultiplied, but we expect the result to not be premultiplied.

1 0

Re: [PATCH 6/7] ddraw/tests: Add more d3d7 lighting tests.
by Henri Verbeet March 31, 2015

March 31, 2015

On 30 March 2015 at 20:18, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + static WORD Indices[] = {0, 1, 2, 2, 3, 0}; You have a typo here. :)

2 1

Re: [PATCH 1/7] ddraw: D3DLIGHT lights default to active.
by Henri Verbeet March 31, 2015

March 31, 2015

On 30 March 2015 at 20:18, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -184,7 +184,7 @@ static HRESULT WINAPI d3d_light_SetLight(IDirect3DLight *iface, D3DLIGHT *data) > - if (data->dwSize >= sizeof(D3DLIGHT2) && (((D3DLIGHT2 *)data)->dwFlags & D3DLIGHT_NO_SPECULAR)) > + if (!(flags & D3DLIGHT_NO_SPECULAR)) > light7->dcvSpecular = data->dcvColor; > else > light7->dcvSpecular = *(const D3DCOLORVALUE *)zero_value; I'm not holding this against the patch too much because it's ddraw, but I think "if (flags & D3DLIGHT_NO_SPECULAR)" and then flipping the branches reads a bit nicer. If the declaration of "zero_value" is fixed you can avoid the cast as well. > @@ -200,9 +200,10 @@ static HRESULT WINAPI d3d_light_SetLight(IDirect3DLight *iface, D3DLIGHT *data) > + memcpy(&light->light, data, sizeof(D3DLIGHT)); There's something to be said for "sizeof(D3DLIGHT)" here, although I don't think "sizeof(*data)" would have been worse.

2 1

Re: [3/3] kernel32: force 4096 byte page alignment (resend)
by Alexandre Julliard March 31, 2015

March 31, 2015

David Naylor <dbn(a)freebsd.org> writes: > FreeBSD prefers to use a 0x200000 (super) page alignment however this causes > the image base to be displaced from the requested 0x7b800000. Forcing a > smaller page size ensures FreeBSD can place the image startin at 0x7b800000. This would have to be done in winegcc, with appropriate configure checks. It's probably easier to change the address to leave more room. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: comctl32/tests: Fix couple of metrics tests that fail on some systems
by Dmitry Timoshkov March 31, 2015

March 31, 2015

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + /* estimate using stock font metrics */ > + hdc = GetDC(0); > + hOldFont = SelectObject(hdc, GetStockObject (SYSTEM_FONT)); > + GetTextMetricsA(hdc, &tm); > + SelectObject(hdc, hOldFont); > + ReleaseDC(0, hdc); Probably DEFAULT_GUI_FONT should be used instead of SYSTEM, you really don't want to see SYSTEM_FONT on the screen, or just use its metrics. -- Dmitry.

2 1

Re: comctl32/tests: Fix couple of metrics tests that fail on some systems
by Marvin March 31, 2015

March 31, 2015

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=12538 Your paranoid android. === w2003std (32 bit listview) === listview.c:5151: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5156: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7u (32 bit listview) === listview.c:3914: Test failed: got right 112, bottom 19 listview.c:5151: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5156: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w8 (32 bit listview) === listview.c:5151: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5156: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5151: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5156: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

1 0

Re: msvcrt: Use Dragon4 algorithm to fix inconsistent rounding behaviour for sprintf and add tests. The Dragon4 algorithm implementation is based on http://www.ryanjuckett.com/programming/printing-floating-point-numbers/.
by YongHao Hu March 31, 2015

March 31, 2015

Excuse me, Is there anything to do to improve this patch? Thanks. On 2015年03月25日 15:46, YongHao Hu wrote: > Try 3: > - Superseded Patch 109456. > - Use appropriate win32 types instead of typedef. > (Thanks Dmitry Timoshkov) > > Try 2: > - Superseded Patch 109432 > - Use typedef instead of C99 types > - Delete useless #ifndef > - Add memset to test > > Try1: > - Fix bug https://bugs.winehq.org/show_bug.cgi?id=37913 . > - The Dragon4 algorithm implementation is based on > http://www.ryanjuckett.com/programming/printing-floating-point-numbers/. > > --- > dlls/msvcrt/dragon4.h | 668 > ++++++++++++++++++++++++++++++++++++++++++ > dlls/msvcrt/printf.h | 43 +-- > dlls/msvcrt/tests/printf.c | 96 ++++++ > dlls/msvcrt/wine_printfloat.h | 246 ++++++++++++++++ > 4 files changed, 1036 insertions(+), 17 deletions(-) > create mode 100644 dlls/msvcrt/dragon4.h > create mode 100644 dlls/msvcrt/wine_printfloat.h > >

2 2

Re: [7/8] server: Implement waiting for job objects.
by Marvin March 31, 2015

March 31, 2015

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=12521 Your paranoid android. === w7u (32 bit process) === process.c:2552: Test failed: WaitForSingleObject returned 258

1 0

Re: [1/8] server: Basic implementation of job objects. (rev 2)
by Marvin March 30, 2015

March 30, 2015

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=12516 Your paranoid android. === w7u (32 bit process) === process.c:2532: Test failed: WaitForSingleObject returned 258

1 0

Re: [PATCH 3/3] comctl32/listview: Always forward HDM_SETORDERARRAY to a header
by Marvin March 30, 2015

March 30, 2015

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=12515 Your paranoid android. === w2000pro (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2003std (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7u (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w8 (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

1 0

Re: [PATCH 7/7] ddraw/tests: Port the lighting test to the previous d3d versions.
by Marvin March 30, 2015

March 30, 2015

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=12513 Your paranoid android. === wvistau64 (32 bit ddraw1) === ddraw1.c:2498: Test failed: Expected message 0x46, but didn't receive it. ddraw1.c:2500: Test failed: Expected screen size 1024x768, got 0x0. ddraw1.c:2506: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2537: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2545: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2572: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2592: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2616: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2643: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2660: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2697: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2708: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2735: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2755: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2772: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2799: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2816: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2854: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. === w8 (32 bit ddraw1) === ddraw1.c:1376: Test failed: Expected color 0x00ff0000 for test 0, got 0x0000ff00. ddraw1.c:1400: Test failed: Expected color 0x000000ff for test 0, got 0x0000ff00.

1 0

Re: [PATCH 6/7] ddraw/tests: Add more d3d7 lighting tests.
by Marvin March 30, 2015

March 30, 2015

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=12512 Your paranoid android. === w8 (32 bit visual) === visual.c:1494: Test failed: unexpected colortable on offscreen surface

1 0

Re: [PATCH 3/7] ddraw: Make sure to activate / deactivate the light on D3DLIGHT_ACTIVE flag changes.
by Sergey Isakov March 30, 2015

March 30, 2015

Sorry, but seems current revision has no “flags” variable On 30 марта 2015 г., at 21:18, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > --- > dlls/ddraw/light.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/dlls/ddraw/light.c b/dlls/ddraw/light.c > index baaf6a3..c632c32 100644 > --- a/dlls/ddraw/light.c > +++ b/dlls/ddraw/light.c > @@ -201,7 +201,11 @@ static HRESULT WINAPI d3d_light_SetLight(IDirect3DLight *iface, D3DLIGHT *data) > > wined3d_mutex_lock(); > memcpy(&light->light, data, sizeof(D3DLIGHT)); > - if (flags & D3DLIGHT_ACTIVE) > + if (!(light->light.dwFlags & D3DLIGHT_ACTIVE) && flags & D3DLIGHT_ACTIVE) > + light_activate(light); > + else if (light->light.dwFlags & D3DLIGHT_ACTIVE && !(flags & D3DLIGHT_ACTIVE)) > + light_deactivate(light); > + else if (flags & D3DLIGHT_ACTIVE) > light_update(light); > light->light.dwFlags = flags; > wined3d_mutex_unlock(); > -- > 2.0.5 > > >

1 0

Re: [PATCH 1/5] wined3d: Give tex_type and its values a better name.
by Henri Verbeet March 30, 2015

March 30, 2015

On 28 March 2015 at 17:06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -179,7 +179,7 @@ static void surface_get_blt_info(GLenum target, const RECT *rect, GLsizei w, GLs > case GL_TEXTURE_2D: > info->binding = GL_TEXTURE_BINDING_2D; > info->bind_target = GL_TEXTURE_2D; > - info->tex_type = tex_2d; > + info->tex_type = WINED3D_FFP_TEXTURE_TYPE_2D; > coords[0][0] = (float)rect->left / w; > coords[0][1] = (float)rect->top / h; > coords[0][2] = 0.0f; Note that there isn't anything particularly fixed-function about blits. That currently doesn't matter a whole lot since this is effectively only used for onscreen/offscreen depth blits, but I get the impression your intention is to use this for the blitter interface in general. In that case, something like wined3d_shader_resource_type may be more appropriate, since eventually we'll have to deal with e.g. buffers and array textures as well (for ID3D10Device::CopySubresourceRegion() in particular.) > +enum wined3d_ffp_texture_type > { > - tex_1d = 0, > - tex_2d = 1, > - tex_3d = 2, > - tex_cube = 3, > - tex_rect = 4, > - tex_type_count = 5, > + WINED3D_FFP_TEXTURE_TYPE_1D = 0, > + WINED3D_FFP_TEXTURE_TYPE_2D = 1, > + WINED3D_FFP_TEXTURE_TYPE_3D = 2, > + WINED3D_FFP_TEXTURE_TYPE_CUBE = 3, > + WINED3D_FFP_TEXTURE_TYPE_RECT = 4, > + WINED3D_FFP_TEXTURE_TYPE_COUNT = 5, > }; Somewhat related to above, if this is supposed to be fixed-function we don't need WINED3D_FFP_TEXTURE_TYPE_1D. If it's supposed to be for blits we do, but the "FFP" in the name would be inappropriate. > -/* Similar to tex_types, except that it doesn't have 1d textures > - * (can't be bound), rect textures (handled via np2_fixup) and > - * none / unknown (treated as 2d and handled via dummy textures). */ > +/* Similar to wined3d_ffp_texture_type, except that it doesn't > + * have 1d textures (can't be bound), rect textures (handled via > + * np2_fixup) and none / unknown (treated as 2d and handled via > + * dummy textures). */ wined3d_ffp_texture_type doesn't have a none/unknown element either.

2 2

Re: [PATCH 3/5] wined3d: Use bitfields in struct arbfp_blit_type.
by Henri Verbeet March 30, 2015

March 30, 2015

On 28 March 2015 at 17:06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > struct arbfp_blit_type > { > - enum complex_fixup fixup; > - GLenum textype; > + enum complex_fixup fixup : 4; > + enum wined3d_ffp_texture_type textype : 3; > + unsigned padding : 1; > }; > I don't keep a very close eye on arb_program_shader.c, but I suspect this doesn't quite do what you think it does. The structure is going to get aligned to the alignment of the largest scalar field (which would be 32 bits in this case because of enum/unsigned), so you'll have another 24 bits of padding after the "padding" field.

1 0

Re: dwrite/tests: Test the correct return code.
by Marvin March 30, 2015

March 30, 2015

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=12500 Your paranoid android. === wvistau64 (32 bit font) === font.c:1818: Test failed: got 0x8faecafe === w2008s64 (32 bit font) === font.c:1818: Test failed: got 0x8faecafe === w7u (32 bit font) === font.c:1818: Test failed: got 0x8faecafe === w8 (32 bit font) === font.c:1818: Test failed: got 0x8faecafe === wvistau64 (64 bit font) === font.c:1818: Test failed: got 0x8faecafe === w2008s64 (64 bit font) === font.c:1818: Test failed: got 0x8faecafe

1 0

Re: [7/7] ws2_32: Better trace setsockopt/getsockopt (try 2)
by Alexandre Julliard March 30, 2015

March 30, 2015

Bruno Jesus <00cpxxx(a)gmail.com> writes: > Use wine_dbg_sprintf instead of plain sprintf, that simplified the patch =) What you really want is to implement a debugstr_sockopt and something like a debugstr_optval and use these in normal TRACE statements, instead of hiding the trace inside a helper function. Also you can't append to a wine_dbg_sprintf string, that's why it's const... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: add a stub for QueryThreadCycleTime
by Dmitry Timoshkov March 30, 2015

March 30, 2015

Austin English <austinenglish(a)gmail.com> wrote: > +@ stdcall QueryThreadCycleTime(ptr ptr) ... > +BOOL WINAPI QueryThreadCycleTime(HANDLE thread, PULONG64 cycle) 'ptr' is not suitable for HANDLE in the .spec file. -- Dmitry.

1 0

Re: d3drm/tests: Add QueryInterface tests for IDirect3DRMFrame
by Stefan Dösinger March 29, 2015

March 29, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-03-29 um 15:37 schrieb Aaryaman Vasishta: > + { &IID_IDirect3DRM, NULL, E_NOINTERFACE, FALSE }, It's funny that this interface returns the right error value on QI. > + hr = IDirect3DRM_CreateFrame(d3drm3, NULL, &frame3); Minor nitpick: IDirect3DRM3_CreateFrame . You can resend the patch with a fix if you want, but I'm OK with this patch as it is. Something to think about for future tests: It may make sense to split up d3drm.c into d3drm1.c, d3drm2.c and d3drm3.c for each interface version, similar to the ddraw tests. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVGBWOAAoJEN0/YqbEcdMwLkUP/3S8gOP5XSYOgOkELFOSznNp ir09O5ef1HUpECpZjCks7ez4IbUhswcb/idJ3UeEx3lSBy4vIk3vY0usXcXKkfMl TlioDlOuzKhpXxb/5lZ/SUoG/nguBvzisKeifAA1gi8ne+3REhWeJvY6iBNDNDEX dNUYiTP+qxsq8c+bzgydxDuu0OT7LVEXrVrDO1g3qOebJjFSdkXOnf1bCntejX4S WdnxPlioWBMvffP42r0oinXzjoqobi5BDw8r4YppflEUou1bH3oT7fczJEpK4rBm 2ZDz9EOhvMOa6M5PSiqwPpINfI1PpH+p9S0r3iMZz8ux2VbXDyfJ0i/5CdzQ3HX8 rnNq/NcObXVgweBYIN7uFvjlo0Si963ACYDperAVyBNgP/oJXsz3dA5ysvrf6Lf8 Xy1kdP2B79AxWR3DRumQS9sbruaofENF16/7d9MZE933uWY9xBS6JIKTP0AVdDsP tqF8ppHwVdPfpiazYnrG1ivpE0jNIPJJ67I6FWRC1S8k7QQVmbAdVnDgczDs6lLx hiZbjksd4Uf16oGO29bXeZ2YM3Zi75K9pCa7ruYoftcF2ihd0tU01+jbM6hY32qm K1RKe7/HCMANoal7pQEukARHVRvHDpVFRGJzeMbysc8yumnpbgl7/UI9z0wZvoYI aCAXfxi21aSdCzxC7mIU =9SMA -----END PGP SIGNATURE-----

2 2

Re: [PATCH 4/5] comctl32/listview: Always forward LVM_GETCOLUMNORDERARRAY to header
by Marvin March 29, 2015

March 29, 2015

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=12491 Your paranoid android. === w7u (32 bit listview) === listview.c:5141: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5146: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wvistau64 (64 bit listview) === listview.c:5141: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5146: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5141: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5146: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

2 1

Re: dsound: Fix angle to sound source calculation.
by Andrew Eikum March 29, 2015

March 29, 2015

Forwarding on to wine-devel, Stas, and Ruslan from Bug 38041. Any thoughts on the coning breakage, Stas? Andrew On Mon, Mar 23, 2015 at 09:52:32PM +0000, Mark Harmstone wrote: > Hi, > > I've had a play with it, and yes, I think he's right. It seems to be a > lot more robust than my code. One thing though that I think he's > overlooked is that he changes the behaviour of AngleBetweenVectorsRad, > which is called by AngleBetweenVectorsDeg and thus the coning code - > I think this patch will probably break that. > > I've not tested it yet, but there's a chance this patch might fix > bug 38041. > > Mark > > On 23/03/15 14:39, Andrew Eikum wrote: > > This seems sane to me, but I never had a good grasp on this to begin > > with. Does it look OK to you, Mark? > > > > Andrew > > > > On Sun, Mar 22, 2015 at 08:59:15PM +0300, Стас Цымбалов wrote: > >> This patch fixes incorrect sound positioning in dsound. > >> As of now, angle to sound source is calculated as angle between > >> vDistance and vOrientFront. > >> This leads to incorrect results for all sources that are not in the > >> same plane as speakers. > >> In extreme case: for sources directly above or below origin, angle is > >> calculated to -90 degrees, and they are played in the left speaker. > >> > >> This patch changes angle calculation: angle to sound source is > >> calculated as angle between vDistance and plane given by vectors > >> vOrientFront and vOrientTop. > >> --- > >> dlls/dsound/sound3d.c | 25 ++++++++++++++----------- > >> 1 file changed, 14 insertions(+), 11 deletions(-) > > > >> From 1ebe3761b0d6acfca58cec17472336a05b7f2679 Mon Sep 17 00:00:00 2001 > >> From: Stas Cymbalov <dummyunit(a)gmail.com> > >> Date: Sun, 22 Mar 2015 18:22:49 +0300 > >> Subject: dsound: Fix angle to sound source calculation. > >> > >> --- > >> dlls/dsound/sound3d.c | 25 ++++++++++++++----------- > >> 1 file changed, 14 insertions(+), 11 deletions(-) > >> > >> diff --git a/dlls/dsound/sound3d.c b/dlls/dsound/sound3d.c > >> index 9a0226a..ffd4d45 100644 > >> --- a/dlls/dsound/sound3d.c > >> +++ b/dlls/dsound/sound3d.c > >> @@ -112,7 +112,6 @@ static inline D3DVALUE AngleBetweenVectorsRad (const D3DVECTOR *a, const D3DVECT > >> > >> cos = product/(la*lb); > >> angle = acos(cos); > >> - if (cos < 0.0f) { angle -= M_PI; } > >> TRACE("angle between (%f,%f,%f) and (%f,%f,%f) = %f radians (%f degrees)\n", a->x, a->y, a->z, b->x, > >> b->y, b->z, angle, RadToDeg(angle)); > >> return angle; > >> @@ -264,16 +263,20 @@ void DSOUND_Calc3DBuffer(IDirectSoundBufferImpl *dsb) > >> else > >> { > >> vLeft = VectorProduct(&dsb->device->ds3dl.vOrientFront, &dsb->device->ds3dl.vOrientTop); > >> - flAngle = AngleBetweenVectorsRad(&dsb->device->ds3dl.vOrientFront, &vDistance); > >> - flAngle2 = AngleBetweenVectorsRad(&vLeft, &vDistance); > >> - > >> - /* AngleBetweenVectorsRad performs a dot product, which gives us the cosine of the angle > >> - * between two vectors. Unfortunately, because cos(theta) = cos(-theta), we've no idea from > >> - * this whether the sound is to our left or to our right. We have to perform another dot > >> - * product, with a vector at right angles to the initial one, to get the correct angle. > >> - * The angle should be between -180 degrees and 180 degrees. */ > >> - if (flAngle < 0.0f) { flAngle += M_PI; } > >> - if (flAngle2 > 0.0f) { flAngle = -flAngle; } > >> + /* To calculate angle to sound source we need to: > >> + * 1) Get angle between vDistance and a plane on which angle to sound source should be 0. > >> + * Such a plane is given by vectors vOrientFront and vOrientTop, and angle between vector > >> + * and a plane equals to M_PI_2 - angle between vector and normal to this plane (vLeft in this case). > >> + * 2) Determine if the source is behind or in front of us by calculating angle between vDistance > >> + * and vOrientFront. > >> + */ > >> + flAngle = AngleBetweenVectorsRad(&vLeft, &vDistance); > >> + flAngle2 = AngleBetweenVectorsRad(&dsb->device->ds3dl.vOrientFront, &vDistance); > >> + if (flAngle2 > M_PI_2) > >> + flAngle = -flAngle; > >> + flAngle -= M_PI_2; > >> + if (flAngle < -M_PI) > >> + flAngle += 2*M_PI; > >> } > >> TRACE("panning: Angle = %f rad, lPan = %d\n", flAngle, dsb->volpan.lPan); > >> > >> -- > >> 2.0.5 > >> > > > >> > > >

4 4

Re: d3drm/tests: Add QueryInterface tests for IDirect3DRMFrame
by Marvin March 29, 2015

March 29, 2015

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=12490 Your paranoid android. === w2000pro (32 bit d3drm) === d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 1, expected 0. d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 2, expected 0. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 3. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 4. d3drm.c:1728: Test failed: Got hr 0 for test "frame_qi" 0, 5. d3drm: unhandled exception c0000005 at 780273CD === wxppro (32 bit d3drm) === d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 1, expected 0. d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 2, expected 0. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 3. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 4. d3drm.c:1728: Test failed: Got hr 0 for test "frame_qi" 0, 5. d3drm: unhandled exception c0000005 at 77C46F07 === w2003std (32 bit d3drm) === d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 1, expected 0. d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 2, expected 0. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 3. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 4. d3drm.c:1728: Test failed: Got hr 0 for test "frame_qi" 0, 5. d3drm: unhandled exception c0000005 at 77BD7D8D

1 0

Re: [PATCH] user32: Support activation context class redirection in CreateWindow.
by Nikolay Sivov March 29, 2015

March 29, 2015

On 03/29/2015 01:54 AM, Mark Harmstone wrote: > This patch implements the class redirection feature of activation contexts, as > used by version 6 of comctl32. Among other things, this is a necessary step in > fixing the behaviour seen in bug 38124. > > --- > dlls/user32/win.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 62 insertions(+) > In principle it looks almost okay, except that I don't think we need it right now, as long as comctl32 doesn't register versioned classes at all. It will just wait time for every window creation requested looking for something that can't be created. Comments on code itself to follow. > + classatom = get_int_atom_value(className); > + if (classatom) > + GlobalGetAtomNameW(classatom, classNameStr, sizeof(classNameStr) / sizeof(*classNameStr)); > + else > + strcpyW(classNameStr, className); You don't need to copy in case of a string. > + if (wcrd->name_len == 0) > + return FALSE; I don't think it can be 0, ever. Name comes from class name from module manifest and assembly version string. > + memcpy(redirClassName, (unsigned char*)askd.lpData + wcrd->name_offset, wcrd->name_len); > + redirClassName[wcrd->name_len / sizeof(WCHAR)] = 0; All strings in context data are null-terminated, so you don't need this complexity. In fact you don't need to copy anything at all, you can just use a (WCHAR*)((BYTE*)askd.lpData + wcrd->name_offset) as a ready-to-use pointer, I think it's a preferred way, given that overhead of this redirection lookup should be minimal. So your helper only needs to return a pointer - original one or computed from redirection data. And atoms should be resolved outside of it. > + WCHAR redirClassName[256]; Is it defined somewhere to be limited to that? > + > + wndPtr = create_window_handle( parent, owner, redirClassName, module, unicode ); > + > + if (GetLastError() == ERROR_INVALID_HANDLE && GetClassInfoW( 0, redirClassName, &wc )) > + wndPtr = create_window_handle( parent, owner, redirClassName, module, unicode ); > + I don't quite get what you're trying to do here? How does same call help if called second time? Also last error check is strange.

1 0

Re: [PATCH] wined3d: Fix some videocards property detection
by Stefan Dösinger March 28, 2015

March 28, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This patch has a few unrelated changes. The core change is that it re-introduces a hack we once had in Wine and removed because it broke newer mac GPUs. The CrossOver version of the hack works a bit better than the unconditional Wine version, but it's still ugly. Am 2015-03-28 um 06:15 schrieb Sergey Isakov: > + /* Non-Apple GL vendors report uniforms correctly */ > + if (!match_apple(gl_info, gl_renderer, gl_vendor, card_vendor, device)) return FALSE; > + /* All dx9 cards are overreported on OSX */ > + if (!match_dx10_capable(gl_info, gl_renderer, gl_vendor, card_vendor, device)) return TRUE; > + /* Nvidia and Intel DX10 cards support > 256 uniforms */ > + if (card_vendor != HW_VENDOR_AMD) return FALSE; It is terrible that OSX lies about the GPU capability and then forces applications to have a crystal ball that tells them what the GPU can actually do. - From a pragmatic point of view I don't think OSX will ever change in this regard. It was a design decision by Apple to do this, and they stopped updating drivers for the old hardware a long time ago. I am open to re-introducing the hack if we can find a way to detect the bug more directly. E.g. try to declare a shader with 257 uniforms, read them with indirect addressing so the driver can't optimize the access and then check for software fallbacks. There's a CGL function for checking that, but I don't remember from the top of my head how it works. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVFoC/AAoJEN0/YqbEcdMwcUIP/Rw24kSROYMK2Xvfe9vyEZ9S NQd9RPHRQRNiXuXRfAmAUKm/PF17O7SUMKLAwjg90HGZySdDOH4MCb7rwaXryKYU qV1ba75KR/JOi7db0r/WrZjf+mQ2+z1hES0SEg9jSYHxIcSNRhWvjB3H3rId7Och TAEvsiT897rE7U/2GQmnw9popFPOPRm0Y2YY4f1XecF1XSdmBokpdmpcDzoRTxbX 8q11cWlPyqi3u6xiyX7SwEwoh7v/zpNd4c1yuL6kytSfV1w+sD4fMC4BitIvfd2X OltqvQz5MfexglNlLJaeE1yplhrEKE2NHHdoIXhOhg7TdOeHYJfvrzgpjLWlUVnC 6BWsSkgge3OO3Pk7Fhi7Lht0EPhds+iq+7NCLwDV051Qi89kBlyJOY33bMMjryez wHo+YEZEvk0IkkVQGkAjJfZzLFtxjMzIxcixijkJc3/aYwuF0ZyDVqFe3hj4gPTw Ei1IThyWC4hdVqIuduD4t+5VH3GwU6JiYE6a16uHVTfoTSboN9te1WzV+lnhRFMf P54xaJ+98sJrpq+670WU68jHzM/BmXXojyF+lxv8t0noXmHLJy7S4yskzDhowMMG myjbDbeb/fB2O/oSdeOEXkskl2+XkotROM9qwF7a/yyaGe1/f47Y16gmrPyeCFD5 0Z68wLM5//XliOz91+hs =1uP/ -----END PGP SIGNATURE-----

2 1

[BISECTED REGRESSION] file dialog does not shown
by Andrey Skvortsov March 28, 2015

March 28, 2015

Hi, original problem is described here: https://bugs.winehq.org/show_bug.cgi?id=34825 I have the same problem with running Nanocad 5.1. The file open/import dialog does not open with wine-1.7.39. I bisected the problem to commit: [bbf2cce16041e90d621a1f5889ea1bd760e21a0e] comdlg32: Do not modify dialog resource directly. I reverted this commit on latest wine and that fixed my issue with file open dialog. -- Best regards, Andrey Skvortsov Secure eMail with gnupg: See http://www.gnupg.org/ PGP Key ID: 0x57A3AEAD

2 1

Re: [PATCH] wined3d: Fix some videocards property detection
by Stefan Dösinger March 28, 2015

March 28, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Please keep wine-devel in CC. There are more developers than just myself :-) . Am 2015-03-28 um 12:38 schrieb Sergey Isakov: > I know this crash. It was appeared because this patch was > introduced in the wrong place as I describe in the bug 38277 Too > slow test Advanced Pixel Shaders in 3DMark2001SE > <https://bugs.winehq.org/show_bug.cgi?id=38277> My patch works > fine. It may work fine on the Macs you tested or even all the macs that ever shipped, but it is still ugly to hardcode GPU capabilities that the driver should provide. There are OpenGL flags winemac.drv can set to disable the software fallback: https://developer.apple.com/library/mac/qa/qa1502/_index.html . What happens when you set them? Do they influence the reported capabilities? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVFpW6AAoJEN0/YqbEcdMwaz4P/298Ha4rtgWPYEFF+w6HzAWP f7G9fenhHkgjaudNwjcFXTr1dweYTVwvVll5Ahpu9bRd4iC/hM4jyKf2TVcpcXbM +yIri1UnsgSt63YJ1+XRfvVsV28BYlhqnlZvqKkmNHf/5dxg0iOfz0noDYAcspFZ BjfVQOFgaRmuiS9AyVpgc5WO2+IptKvDa1ExSOSNhOO5ye7T9Nh071QoWCgakqza invrADPRjRm/Ri7JV6CtQeRZCLYdMjeONchhJOHif2KYjk8/J5PNVAUeSSt73ZXQ TPA/VmPAs9mge3QlKgD9NgIab8auPt0tHW3MLLluKbLmwOJSMsOuxx85VC4yxlvK K/h0Q7Ldx8BvmsraLjmNMPmB9FMUNuxmEhjrkdbN90v9FwfsfZs5PGm6V+Rmt4uq gBHQxY2wd6xUt6I4AFH+6s088Ubl7zQRdAsE12LTMnRHF0ctIvHZCVdtdgVG/0hu ZpxrnHgoWm4E9arzslkHOxaqAh1Tln8k9WtpF6PcGNv4xbLWKLNiRBHMF4fK9MQI PtbT7gzL71+38lArzqnCzKb4Ijw1X7PkgA//4ZlkENyCp9SKxWpLQaDq853mhGlQ Q8z6TqAgb1wIwqO/rfiX6Rqj+aWt9Zet4XDhLaLbsifRnGjr4gad9LSC28GzQfet d80ZXwigJshmdtl05+I6 =+1lX -----END PGP SIGNATURE-----

2 2

Re: [PATCH] krnl386.exe16: Fix NULL pointer dereferencing
by Stefan Dösinger March 28, 2015

March 28, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-03-27 um 19:16 schrieb Sergey Isakov: > This if statement body will perform only if driver_request is NULL > pointer. Next statements will cause crash. Bug 38159 NULL pointer > dereferencing <https://bugs.winehq.org/show_bug.cgi?id=38159> I think in this case the segfault is intentional. The caller passes a stupid parameter. Also I'm not sure if it actually segfaults. In vm86 mode memory is mapped to this page, so NULL may be a valid address. The best solution would be to write a test and see what happens on an ancient DOS, but we don't have a test infrastructure for DOS and Win16. The next best idea might be to just remove the entire block. It's funny though since (according to git) the patch that added this check already added the "/* FIXME - to be deleted ?? */" comment. At some point we may as well remove the entire DOS code since we just call dosbox these days and 64 bit CPUs don't allow vm86 mode anyway. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVFpBqAAoJEN0/YqbEcdMwVUQP/itrU95T4mlo2vo7f4J3k7fd Wx4goKV1/s5iPT+56T3q+MsqYp0gcNgmiwmVrf+HSNl94jXo1ysWfsuD1LeAAPGi O6FJBpszJdjw+fjm0whKidM3L+QYOEqGb/8AP5ZuXQ2zE0+iDA2cGo5oFrP2LpmM ZR7t3uYTIqk4VYWuZz4rlfSaHu552LpT/zEIYghteL/ANTqkad+oVleOFLB6Nbb/ j1PK7QKl6D+n6Kd2KSwlI9jj3XADf14i96J2knNh7yyLVZAsjNTe/3F9eoI98N5M cI22fGkW6jp70HoS1yMpJG66jqrhamAi6QBzMUI2cfAhHtjngKj36X3MRZMXIiK7 4E1g/Z7hcJ3ZtbrfzHnUdUXCQMXHszA93U69QRERTnjatDB+VNTZ67AaPGMXBiE9 2i5KlGg5TXjZPJwPqetHuGZ18uUXwCXfbC5+VPXP5AqbhxltE6IPfbKs95Bo90gh EvZsooU7pqNJxNAfscDIKliDsIcFV3TATqEyr/LCeczKNbE1DOKQ/afBrGyivabe f/YzcLLHfx5x8Lxx5bsmn2+3xR+LVfppH/rCSC5YA2ZwU6gB8NeuDAHh/BvsV7E1 i9IkN43sbQ4xZQFckBsyhdcpJd0kCCp3n1kmCfCWx3c2uIwLNvzzwT9HM8mY36my qcBfCcz1CCOpKpaayCSL =78sc -----END PGP SIGNATURE-----

1 0

Re: [PATCH] user32: Use function parameter if it set to be not stub
by Stefan Dösinger March 28, 2015

March 28, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-03-27 um 21:52 schrieb Sergey Isakov: > { + if (!lpDisplayDevice) { + return FALSE; + } This is probably correct, but it needs a test. Currently this function crashes if this parameter is NULL. I can imagine that EnumDisplayDevices(NULL, 1, NULL, 0) returns TRUE if display 1 exists and FALSE otherwise. > + + if (i) { FIXME("(%s,%d,%p,0x%08x), > stub!\n",debugstr_w(lpDevice),i,lpDisplayDevice,dwFlags); - - if > (i) return FALSE; + } This is an unrelated change and matters more for what the patch description says it does. Though if I understand this right we want this check to be "if (i || lpDevice)" because the application can also pass in a device name. > > + if (lpDevice) { + strcpyW(lpDisplayDevice->DeviceName, > lpDevice); + } else { memcpy(lpDisplayDevice->DeviceName, > primary_device_name, sizeof(primary_device_name)); + } This is yet another unrelated change. It looks OK, but I don't think it really matters. Copying the input display name will at best paper over the fact that our implementation of this function does not support multiple display devices. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVFo0tAAoJEN0/YqbEcdMw+eQP/1SnlfkRjPZ/8PW8+m3iOYHC OTLWOE7Io94FzLfFQO487pCbsqgd9199UWp3IolfUe/y2vS4LtosxQQh1tLG7j7A rsypwNjV8OwSHvXiL5BH/4QvZTAqoctW484E7z7IHzMXMqa2Oyrj5K3QXHVes6O5 9xEB1UuSkB19Z0jIQqHPR4Hc/o8gYuCAER05BiTqOZcBSsrVhfOOZ+FKR7krWqdP o3VkOmUSWhX+9ziTsKmWGsBEZk0r81RMG2cbT/eShAtBBZs/+YtUfYiNY2q+tCoF fMiEfiMU7e1TqroBJAw37gYju+qt3xon/RuyOQD13a3hwWSDzMeoE9PAf9TxCK4Q OinEV45U8RiDkczviuOQluojfmJSXmVCC2BjPPQ2ZtmGXyuRXLrlRZ4KsCE/xhyV p2+Za2U/cvfqy0ug5isnnFGu/lKi1RCeGXsbHX6ZF5amTEfuklQpWolacrGilxZ2 kYiBtV93A/IJzUPaj2d97JbEFG2nMP6pT+KTSFBJIY2bzzzhnX1Fltd8kt3Vp/rv MOUPs/peC9sv17wDc5LREPAbA7LOBuN4M3M+5O2glO/F96gt8FSsPYyZy9sMRXEv eEuQgGbFbm9KKCWBK53mm78aAFiulqEd3S4vFXnvNU5sFxUW/BO3TxDZJhPEAK2v BeJJ0ZjH01mfQ8lhDQph =RL+u -----END PGP SIGNATURE-----

1 0

Re: [PATCH] vbscript: Fixed Hex
by Marvin March 28, 2015

March 28, 2015

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=12482 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (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] vbscript: Implemented Oct(try 3)
by Marvin March 28, 2015

March 28, 2015

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=12480 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (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: [2/9] kernel32/tests: Add tests for IsProcessInJob.
by Marvin March 28, 2015

March 28, 2015

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=12470 Your paranoid android. === w7u (32 bit process) === process.c:2177: Test failed: WaitForSingleObject returned 258

2 1

Re: [PATCH] vbscript: Implemented Oct(try 2)
by Shuai Meng March 28, 2015

March 28, 2015

Hi, I find Oct("test") returns error number 13 on windows, while 445 on wine. So I shall resend this patch. 2015-03-27 23:28 GMT+08:00 Shuai Meng <mengshuaicalendr(a)gmail.com>: > testbot: > https://newtestbot.winehq.org/JobDetails.pl?Key=12461 > Changelog: > Added support for other subtypes; > Added more tests. > --- > dlls/vbscript/global.c | 53 ++++++++++++++++++++++++++++++ > +++++++++++++-- > dlls/vbscript/tests/api.vbs | 31 ++++++++++++++++++++++++++ > 2 files changed, 82 insertions(+), 2 deletions(-) > > >

1 0

winegcc & stdin
by Leon Bogaert March 27, 2015

March 27, 2015

I'm getting an error when using winegcc with stdin: > $ cat test.c | winegcc -xc -c - > gcc: warning: ‘-x c’ after last input file has no effect > gcc: error: -E or -x required when input is from standard input > winegcc: gcc failed Does anyone know what I could be doing wrong? I'm trying to use stdin because that's what the go (cgo) build tool is trying to use. Leon

2 2

Re: [PATCH] icnsformat.c: wrong pointer to formal parameters
by Bruno Jesus March 27, 2015

March 27, 2015

On Fri, Mar 27, 2015 at 3:01 PM, Sergey Isakov <isakov-sl(a)bk.ru> wrote: > Bug 38288 > Wrong pointer in icnsformat.c IcnsFrameEncode_WriteSource Hi Sergey. Usually the patch subject is the dll name followed by the change. I think a better subject in this case would be: windowscodecs: Fix wrong pointer to formal parameter

1 0

[GSOC 2015] Direct3DRM - Implement rendering for D3DRM
by Aaryaman Vasishta March 27, 2015

March 27, 2015

Hello! I have submitted my proposal on melange. Please take a look at it whenever possible. Any feedback would be very appreciated. Thank You! jam

1 0