April 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: user32: After handling an internal message give a chance to real message to arrive.
by Alexandre Julliard May 6, 2015

May 6, 2015

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -2931,7 +2931,10 @@ static BOOL peek_message( MSG *msg, HWND hwnd, UINT first, UINT last, UINT flags > else > peek_message( msg, info.msg.hwnd, info.msg.message, > info.msg.message, flags | PM_REMOVE, changed_mask ); > - continue; > + > + /* give a chance to real message to arrive */ > + HeapFree( GetProcessHeap(), 0, buffer ); > + return FALSE; Why do you need to leave the function instead of checking for further messages? What is the issue you are seeing? -- Alexandre Julliard julliard(a)winehq.org

2 17

Wine Joysticks, seeking a plan
by Aric Stewart May 6, 2015

May 6, 2015

Hi all, Ok I sat down with Ken (the benefits of being in the same office) and after a lengthy discussion I have come to terms with how it may not be the most ideal plan to put the joystick driver into the graphics driver. However I am still of the strong opinion that we need some sort of better joystick architecture and I know Alexandre is also of the like mindset. This was discussed back on 2005 and I know there was also recent discussion around BSD that also involves this. I also have an itch to start to poke at xinput, but I have no interest in poking at xinput with the current way joysticks are handled. When I was working on this driver thing Alexandre expressed he was pretty opposed to having a whole new set of platform specific wine drivers. (winejoystick_mac, winejoystick_linux, etc...) But if we at least did that we would reduce code duplication by not having the platform specific code duplicated in 2 (with xinput it would become 3) places and have it collected in one place. Now completely unresearched but it may be possible to make a single joystick driver, maybe replacing winejoystick.drv that would build only the platform code that is relevant. but before I do another big chunk of work I am seeking some community buy-in and not just discuss with with Alexandre. I understand if the USB driver path gets actually fleshed out and we try to support Joysticks via that then all this separate driver work would fall away and be replaced. We of course need to make sure we come up with a plan that Alexandre will approve of. Would a replacement winejoystick.drv that holds all the platform specific code be acceptable? Is there a case where we would want that driver to be able to build multiple platform code? Maybe Linux and Linux Input? I will admit I am pretty ignorant of the Linux side of this whole situation. Ideas? Comments? thanks! -aric

7 9

Re: [PATCH 2/4] wined3d: Keep track of renderbuffer capabilities.
by Henri Verbeet May 4, 2015

May 4, 2015

On 30 April 2015 at 00:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index 36be539..ad9b496 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -4095,7 +4095,7 @@ static BOOL wined3d_check_pixel_format_color(const struct wined3d_gl_info *gl_in > BYTE redSize, greenSize, blueSize, alphaSize, colorBits; > > /* Float formats need FBOs. If FBOs are used this function isn't called */ > - if (format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & WINED3DFMT_FLAG_FLOAT) > + if (format->flags[WINED3D_GL_RES_TYPE_RB] & WINED3DFMT_FLAG_FLOAT) That's not wrong as such, but it is pretty arbitrary. WINED3DFMT_FLAG_FLOAT is a basic property of the format, like e.g. the component masks and sizes, it shouldn't depend on the resource type. Once we'll get proper integer types for d3d10, it will probably make sense to keep track of the type (INT/UINT/FLOAT/UNORM/SNORM) as an enumeration instead, perhaps even per-component. > @@ -4178,8 +4178,8 @@ HRESULT CDECL wined3d_check_depth_stencil_match(const struct wined3d *wined3d, > ds_format = wined3d_get_format(&adapter->gl_info, depth_stencil_format_id); > if (wined3d_settings.offscreen_rendering_mode == ORM_FBO) > { > - if ((rt_format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & WINED3DFMT_FLAG_RENDERTARGET) > - && (ds_format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) > + if ((rt_format->flags[WINED3D_GL_RES_TYPE_RB] & WINED3DFMT_FLAG_RENDERTARGET) > + && (ds_format->flags[WINED3D_GL_RES_TYPE_RB] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) This is actually wrong. At least, as long as we don't allow (plain) renderbuffers to be used for FBO attachments. There's nothing in the spec that says formats that can be used for color rendering with renderbuffers have to be available for color rendering with textures as well, and in fact that's much of the reason for this patch set. > @@ -998,9 +998,9 @@ static BOOL fbo_blit_supported(const struct wined3d_gl_info *gl_info, enum wined > break; > > case WINED3D_BLIT_OP_DEPTH_BLIT: > - if (!(src_format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) > + if (!(src_format->flags[WINED3D_GL_RES_TYPE_RB] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) Similar to WINED3DFMT_FLAG_FLOAT, these are basic properties of the format.

2 4

Re: [2/3] user32: Add some tests for EndDialog called from other thread.
by Marvin April 30, 2015

April 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=13148 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0014013C msg.c:12252: Test failed: bad time 314e6/314f6

1 0

Re: [1/3] user32/tests: Add a test for calling SetWindowPos for other thread window. Resend.
by Marvin April 30, 2015

April 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=13147 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0014013C msg.c:12252: Test failed: bad time 30ece/30ede

1 0

Re: [PATCH 2/5] d3d9/tests: Add a test for UpdateTexture. (v2, resend)
by Alexandre Julliard April 30, 2015

April 30, 2015

Matteo Bruni <mbruni(a)codeweavers.com> writes: > v2: Make tests pass on the testbot, add a couple more test cases, some > small cleanups. It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so visual && touch visual.ok visual.c:12925: Tests skipped: No NVDB (depth bounds test) support, skipping tests. visual.c:16373: Tests skipped: DXT5 volume textures are not supported, skipping test. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 1. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 2. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 3. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 4. visual.c:18582: Test failed: Got unexpected color 0x0036c800, case 1, 1. visual.c:18582: Test failed: Got unexpected color 0x0036c800, case 1, 2. visual.c:18582: Test failed: Got unexpected color 0x0036c800, case 1, 3. visual.c:18582: Test failed: Got unexpected color 0x0036c800, case 1, 4. visual.c:18409: Tests skipped: Volume ATI2N textures are not supported, skipping some tests. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 2, 1. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 2, 2. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 2, 3. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 2, 4. make: *** [visual.ok] Error 12 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 4/4] wined3d: Don't use depth textures without ARB_depth_texture.
by Henri Verbeet April 30, 2015

April 30, 2015

On 30 April 2015 at 00:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (!gl_info->supported[ARB_DEPTH_TEXTURE]) > + { > + static const unsigned int depth_flags = WINED3DFMT_FLAG_SHADOW | WINED3DFMT_FLAG_DEPTH > + | WINED3DFMT_FLAG_STENCIL; > + format->flags[WINED3D_GL_RES_TYPE_TEX_1D] &= ~depth_flags; > + format->flags[WINED3D_GL_RES_TYPE_TEX_2D] &= ~depth_flags; > + format->flags[WINED3D_GL_RES_TYPE_TEX_3D] &= ~depth_flags; > + format->flags[WINED3D_GL_RES_TYPE_TEX_CUBE] &= ~depth_flags; > + format->flags[WINED3D_GL_RES_TYPE_TEX_RECT] &= ~depth_flags; > + } This is wrong for the reasons mentioned in patch 2/4, but it should also be unnecessary. WINED3DFMT_FLAG_TEXTURE is supposed to indicate if you can use a format for texturing or not.

1 0

Re: [PATCH 3/4] wined3d: Use renderbuffers if the resource type is RB.
by Henri Verbeet April 30, 2015

April 30, 2015

On 30 April 2015 at 00:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -341,6 +341,8 @@ void wined3d_resource_update_draw_binding(struct wined3d_resource *resource) > resource->draw_binding = WINED3D_LOCATION_DRAWABLE; > else if (resource->multisample_type) > resource->draw_binding = WINED3D_LOCATION_RB_MULTISAMPLE; > + else if (resource->gl_type == WINED3D_GL_RES_TYPE_RB) > + resource->draw_binding = WINED3D_LOCATION_RB_RESOLVED; I haven't looked much into what actually happens now, but the last time I looked at using renderbuffers for FBO attachments, one of the issues that came up was the initial surface contents. Right now we handle that by clearing WINED3D_LOCATION_SYSMEM and marking it current, but that won't work so well for renderbuffers. Somewhat related, does WINED3DFMT_D16_LOCKABLE need special handling?

1 0

Re: [PATCH 1/4] wined3d: Allow specifying a different depth stencil location.
by Henri Verbeet April 30, 2015

April 30, 2015

On 30 April 2015 at 00:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -2342,12 +2352,14 @@ BOOL context_apply_clear_state(struct wined3d_context *context, const struct win > ++i; > } > context_apply_fbo_state(context, GL_FRAMEBUFFER, context->blit_targets, > - wined3d_rendertarget_view_get_surface(fb->depth_stencil), > - rt_count ? rts[0]->resource->draw_binding : WINED3D_LOCATION_TEXTURE_RGB); > + wined3d_rendertarget_view_get_surface(dsv), > + rt_count ? rts[0]->resource->draw_binding : WINED3D_LOCATION_TEXTURE_RGB, > + dsv ? dsv->resource->draw_binding : WINED3D_LOCATION_TEXTURE_RGB); > } This works because we mostly just care that the color location isn't WINED3D_LOCATION_DRAWABLE if there's no attachment. (In particular for the case where the application is doing depth only rendering.) Strictly speaking though, it's probably more correct to use the color location if there's no depth/stencil attachment, to avoid silliness like the color attachment being in WINED3D_LOCATION_DRAWABLE and the depth/stencil attachment in WINED3D_LOCATION_TEXTURE_RGB. In fact, now that the color and depth/stencil locations are separate, you can probably just pass 0.

1 0

Re: [PATCH 5/5] wined3d: Don't use the same va_list multiple times in shader_vaddline().
by Henri Verbeet April 30, 2015

April 30, 2015

On 29 April 2015 at 23:34, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > -static void string_buffer_vsprintf(struct wined3d_string_buffer *buffer, const char *format, va_list args) > +static int string_buffer_vsprintf(struct wined3d_string_buffer *buffer, const char *format, va_list args) > { > if (!buffer) > - return; > + return 0; > string_buffer_clear(buffer); > - shader_vaddline(buffer, format, args); > + return shader_vaddline(buffer, format, args); > } > You could perhaps just merge this into string_buffer_sprintf(), but I don't care that much.

1 0

Re: d3drm: Fix refcounting for IDirect3DRM{1-3}
by Stefan Dösinger April 30, 2015

April 30, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-29 um 23:47 schrieb Aaryaman Vasishta: > - if (!refcount) > + if (!refcount && !InterlockedDecrement(&d3drm->numIfaces)) > HeapFree(GetProcessHeap(), 0, d3drm); This works, but this way you have the code that destroys the object 3 times. Not much of an issue as long as it is just a HeapFree, but I think it would be nicer to have a separate function. Either add a d3drm_destroy function or a pair of d3drm_add_iface and d3drm_release_iface functions that also take care of InterlockedIncrement / Decrement for iface_count) > - { &IID_IDirect3DRM3, &IID_IDirect3DRM3, S_OK, TRUE }, > - { &IID_IDirect3DRM2, &IID_IDirect3DRM2, S_OK, TRUE }, > + { &IID_IDirect3DRM3, &IID_IDirect3DRM3, S_OK, FALSE }, > + { &IID_IDirect3DRM2, &IID_IDirect3DRM2, S_OK, FALSE }, Afaics all the TODOs are gone, so you can remove this field from the table and the todo_wine code from test_qi(). Either in the same patch or a separate one. > - LONG ref; > + LONG ref1, ref2, ref3, numIfaces; > }; Please use iface_count. Yeah, it's just a plain style thing, but d3drm is nicely consistent so far in not using CamelCase (except in cases where Microsoft determined the name). (Yesterday on IRC I said num_ifaces. Henri says xxx_count is the way he prefers.) > + if (refcount == 1) InterlockedIncrement(&d3drm->numIfaces); Another minor style issue: Please put the statement on a separate line, in consistency with the existing code. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVQdzBAAoJEN0/YqbEcdMw5WAP/0H52sqgEXMdSmh6sXH/dZMQ nTZY9uRhElUbb3r6D6HG0ylit994pPaq887t9BSl8F4vbjsPXLjruDbVSwoScCfp rIDKy9xET+ek4p5TSFC9cX1BFAiC2VKN7YYWmr/wHKVPZc+aFudU9ykac02bi9p2 Oe+9wMBcFbwv33UhNL+2dugA4+0yj6egfPJWmju9C6ff6CPGqgXH70rHsrSf1AYs VkNPRhGpfI9BxojBChVtgc0zwPM1HnfOwfmKWCW75YNgNg9lL0o+bdoy2wCcxiLq FYwLLT2o9K+RnPQqRDhdJBKWwY8VrJI/fHZEURRau7RW1ia26j4UrrsAdXTQwhPs Iy8A63pYOxyZsphq5KJ8cwGABYIlBPUG0lXZQRgKh1Jw8f39HIR5cfnu1at/fPSc Cw6tfL/t+g4KeHaZDWZnROwyp704kIZGgvSaPuJjwkPtHh2MN14cp9KQj389kCUM 4KfV6FxsAByRuJ8ur1HSaV2OeIOKOJkaDTzaiiMqc581A0awOeCy5SuAUSrQu4IE 4gAIjryIJXd+kTDw46y6OW5UNXHdNJKGWAMiih25yLBi0BLBfUiW0U7qW5Lcerls e7zefeUYNT+Umj3WU4sDu6B8B6auSZgKrLu9JAwYH2RUhKX9R+z3uTY25VUbJkoP 9WJfJJuosIA5zqLbjxu+ =/BI/ -----END PGP SIGNATURE-----

2 1

Re: kernel32/tests: Add tests for deleting readonly files with NtCreateFile.
by Marvin April 29, 2015

April 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=13137 Your paranoid android. === wvistau64 (32 bit file) === file.c:444: Test failed: attributes of file "testfile.xxx" are 0x0820 === w7u (32 bit file) === file.c:4052: Test failed: SetFileValidData failed 87 file.c:4055: Test failed: SetFileValidData failed 87 === wvistau64 (64 bit file) === file.c:444: Test failed: attributes of file "testfile.xxx" are 0x0820

1 0

Re: [3/3] ws2_32: Properly handle closing sockets during a select call.
by Marvin April 29, 2015

April 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=13135 Your paranoid android. === w2008s64 (64 bit sock) === No test summary line found

1 0

Re: shell32: Add caption to run dialog (resend)
by Alex Henrie April 29, 2015

April 29, 2015

Thanks for your interest in developing Wine! A few pointers: You are supposed to use your name when submitting patches. I don't think Alexandre will accept just your initials. Also, you should avoid putting all that HTML garbage into the patch by using `git format-patch` and `git send-email`. If you cannot use git send-email, send the patch as an attachment. Please read http://wiki.winehq.org/SubmittingPatches Finally, your patch is more likely to be accepted if you can give an example of a Windows program that demonstrates the problem you're trying to fix. -Alex

1 0

Re: [PATCH 2/5] ddraw: Release the surface clipper (if any) in ddraw_surface_wined3d_object_destroyed() (Valgrind).
by Marvin April 29, 2015

April 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=13125 Your paranoid android. === w8 (32 bit ddraw1) === ddraw1.c:1373: Test failed: Expected color 0x00ff0000 for test 0, got 0x0000ff00. ddraw1.c:1392: Test failed: Expected color 0x000000ff for test 0, got 0x0000ff00. ddraw1.c:6666: Test failed: Got unexpected color 0x000000ff. ddraw1.c:6670: Test failed: Got unexpected color 0x00000080.

2 1

Re: Strange wined3d crash
by Francois Gouget April 29, 2015

April 29, 2015

On Wed, 29 Apr 2015, Henri Verbeet wrote: > On 29 April 2015 at 12:40, Francois Gouget <fgouget(a)free.fr> wrote: > > I am getting a strange wined3d crash during the d3d8:device test. > > > Is that a regression? We did touch the shader generation code recently. It is actually. This is the patch that introduced the crash: commit 28343db2083de7b4afe4079da090520f44b5544d Author: Matteo Bruni <mbruni(a)codeweavers.com> Date: Mon Apr 27 17:39:12 2015 +0200 wined3d: Don't use the builtin FFP uniforms for the lights. While at it, use D3D-like uniforms for the light parameters and (consequently) implement range and proper D3D spotlights support. I can test patches but I'm not sure I'll have time to debug this much further for a while :-( Note that this is with an Intel HD Graphics 4600 GPU. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ $live{free} || die "";

3 2

Re: ws2_32: Include inttypes.h for UINT32_MAX.
by Henri Verbeet April 29, 2015

April 29, 2015

On 29 April 2015 at 11:34, Francois Gouget <fgouget(a)free.fr> wrote: > This fixes compilation on FreeBSD. > --- > > The only other files that use UINT32_MAX are: > * The .yy.c files. These are generated and always do an ifndef+define. > * dlls/mshtml/nsembed.c though it calls it PR_UINT32_MAX for some reason. > * dlls/jscript/string.c which simply defines it. > * dlls/winemac.drv/macdrv_cocoa.h which presumably gets it from the Mac > OS X headers. > > Maybe mshtml and jscript should use inttypes.h, or to the contrary, > maybe ws2_32 should use the ifndef+define approach. > Arguably it shouldn't be using UINT32_MAX at all, since it isn't actually used with uint32_t. I guess it should be using e.g. unsigned int with UINT_MAX instead.

4 6

USB Support
by Steve Kenton April 29, 2015

April 29, 2015

USB Support has been on the list of possible release criteria basically forever. I've read through all the old threads and other discussions I could find and it boils down to "really hard to do right". If possible could someone knowledgeable comment briefly on what might be an acceptable architecture for a Wine USB stack? In particular I'm wondering about how much support for client/function drivers would be desirable. Should we stick to only unprivileged operations or would an optional kernel mode driver to support WDM or WDF (KMDF/UMDF) privileged interfaces be acceptable? Steve Kenton

5 11

Strange wined3d crash
by Francois Gouget April 29, 2015

April 29, 2015

I am getting a strange wined3d crash during the d3d8:device test. It's annoying because it only happens with the 64 bit build, and disappears if I add traces (+d3d or +d3d_shader), and even if I add a FIXME() just before the crash. The crash happens in shader_glsl_ffp_vertex_lighting(): shader_addline(buffer, "gl_FrontSecondaryColor = %s * specular;\n", specular); According to the checks I've been able to do the specular pointer is still correct when this gets called. Here's the backtrace: http://pastebin.com/DKvXTVJn Any idea what's up? It almost feels like a compiler bug (gcc 4.9.2 (Debian 4.9.2-10) here). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

1 0

Re: [PATCH] wined3d: fix different level count while texture update
by Henri Verbeet April 29, 2015

April 29, 2015

On 28 April 2015 at 20:18, Sergey Isakov <isakov-sl(a)bk.ru> wrote: > Bug 38048 > According to MSDN > https://msdn.microsoft.com/en-us/library/windows/desktop/bb205858(v=vs.85) > source texture CAN have greater level count then destination > Current comparison "!=“ causes black textures as discussed in the bugzilla. > This may be correct, it may not be. This change needs tests, and I believe that was pointed out in the bug report already.

1 0

Re: [PATCH] wined3d: fix Unrecognized usage flags
by Henri Verbeet April 29, 2015

April 29, 2015

Please use git send-email for sending patches. On 28 April 2015 at 09:18, Sergey Isakov <isakov-sl(a)bk.ru> wrote: > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_TEXTURE); This is fine, but WINED3DUSAGE_OWNDC is missing here as well. Is "buf" still larger enough after you add these flags? > - if (usage) FIXME("Unrecognized usage flag(s) %#x\n", usage); > + if (usage & ~WINED3DUSAGE_QUERY_MASK) FIXME("Unrecognized usage flag(s) %#x\n", usage); I think it makes more sense to do this in the caller. It may make even more sense to just merge debug_d3dusage() and debug_d3dusagequery().

1 0

Re: [PATCH] comdlg32: Change "Borders" to "Margins".
by Alex Henrie April 28, 2015

April 28, 2015

2015-04-28 8:03 GMT-06:00 Alexandre Julliard <julliard(a)winehq.org>: > Alex Henrie <alexhenrie24(a)gmail.com> writes: > >> Alexandre, >> >> What was wrong with this patch that you did not accept it? > > I'm concerned that you have been looking at Windows a bit too much. At first, I thought that Wine actually used this string. On closer look, it seems that Wine always replaces the dialog's string "Borders" with the string resource "Margins [inches]" or "Margins [mm]": https://source.winehq.org/git/wine.git/blob/abd673bde93b76a361ddf7342c538c2… https://source.winehq.org/git/wine.git/blob/abd673bde93b76a361ddf7342c538c2… The following test (run with `./wine dlls/comdlg32/tests/comdlg32_test.exe.so printdlg`) also supports the hypothesis that Wine always overrides the dialog's string: diff --git a/dlls/comdlg32/comdlg32.rc b/dlls/comdlg32/comdlg32.rc index d3deeab..9d37d69 100644 --- a/dlls/comdlg32/comdlg32.rc +++ b/dlls/comdlg32/comdlg32.rc @@ -438,7 +438,7 @@ BEGIN GROUPBOX "Orientation", grp1, 8, 156, 64, 56, BS_GROUPBOX AUTORADIOBUTTON "&Portrait", rad1, 16, 170, 52, 12, BS_AUTORADIOBUTTON AUTORADIOBUTTON "&Landscape", rad2, 16, 190, 52, 12, BS_AUTORADIOBUTTON - GROUPBOX "Borders", grp4, 80, 156, 152, 56, BS_GROUPBOX + GROUPBOX "foobar", grp4, 80, 156, 152, 56, BS_GROUPBOX LTEXT "L&eft:", stc15, 88, 172, 30, 8 EDITTEXT edt4, 119, 170, 36, 12, WS_TABSTOP|WS_GROUP|WS_BORDER LTEXT "&Right:", stc16, 159, 172, 30, 8 diff --git a/dlls/comdlg32/tests/printdlg.c b/dlls/comdlg32/tests/printdlg.c index 7e06c97..d6c7dff 100644 --- a/dlls/comdlg32/tests/printdlg.c +++ b/dlls/comdlg32/tests/printdlg.c @@ -88,7 +88,7 @@ static void test_PageSetupDlgA(void) ZeroMemory(pDlg, sizeof(PAGESETUPDLGA)); pDlg->lStructSize = sizeof(PAGESETUPDLGA); - pDlg->Flags = PSD_RETURNDEFAULT | PSD_NOWARNING; + pDlg->Flags = PSD_NOWARNING; SetLastError(0xdeadbeef); res = PageSetupDlgA(pDlg); ok( res || (CommDlgExtendedError() == PDERR_NODEFAULTPRN), If I am correct, it would be better to replace "Borders" with "" so that translators have one less string to worry about. Is that acceptable to you? -Alex

2 1

Re: [PATCH] comdlg32: Change "Borders" to "Margins".
by Alexandre Julliard April 28, 2015

April 28, 2015

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Alexandre, > > What was wrong with this patch that you did not accept it? I'm concerned that you have been looking at Windows a bit too much. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: include: Added IShellFolderViewDual definition
by Marvin April 28, 2015

April 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=13085 Your paranoid android. === build (build) === Patch failed to apply

2 1

Re: [PATCH 5/5] d3d9/tests: Add spotlight and light range tests.
by Henri Verbeet April 28, 2015

April 28, 2015

On 27 April 2015 at 17:39, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + static const float pi = 3.141592654f; I guess you'll have to resubmit this for the testbot, but while you're at it, I think I prefer M_PI.

1 0

Re: [PATCH 3/6] dmloader: Add and use a generic IPersistStream_GetClassID.
by Marvin April 27, 2015

April 27, 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=13066 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH 2/6] dmloader/tests: Add more DirectMusicCollection tests.
by Marvin April 27, 2015

April 27, 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=13065 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH 1/6] dmloader: Use the generic DirectMusicObject implementation for DMContainer.
by Marvin April 27, 2015

April 27, 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=13064 Your paranoid android. === build (build) === Make failed

1 0

Re: jscript: Date.parse: long date with '/' or '-'
by Stefan Dösinger April 27, 2015

April 27, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-25 um 17:45 schrieb Thomas Faller: > This format is not documented under > > https://msdn.microsoft.com/en-us/library/k4w173wk%28v=vs.84%29.aspx > > but its implemented in the internet explorer and in the windows > script host. In this case a test would be very useful. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVO8QzAAoJEN0/YqbEcdMwl4EP/1+xPW5sSLx86MPGq8e1eXCx 7ON4cSV1u0IIAnw1qMc/VuUxxHw3LN6VSrBN8Rbq6XxXx/1fLvaIz7+ckdBvOz3c QhregFjv7kBsRs3WCDuz8SujMMCeBL0FdeAg7xuWl61mHRKxkaeBNROHlfPxG7GE fYBdOTUPzdEj8eYTB48xozHPMV3EadpO7GL+742upv4qxJa3m7V2ZU3/+4O1atjE +yZyVKEwxKU6PLJNMMzva/TpQPxIEPsKg2L3hFAXnZXjn6lJeew6PWGQiR/OpNR0 HLQcdGk3xQlslefauJpJ6ffSyHl+wRrK7DUpUDsNAQuWQ4ALwHsjkFGG8ph8xRL4 aMnnA+afBU2VXnVpkmnjHlILIaWtCejMo4zveXjD1dk15CeOcs2ezasxhbbl9FUl HySkMNyX6gX07BfR6e9N5gwCzHdOj0GbvRtPMcRXWkPwgzj47xX4NbT0QT8ncg2a lsey/aE8aEscUwGROWm9xv7egKxdBM5kxccBxAMFY1Z5MBNbntlMVTwKERWAl1q9 sRjf77vuuD8LIyXpntqVOb96Hq+4mIo0VzAClFOqSIf6bv8fPz8oFD1elE6G3M4W cXH620URbzXsXg4ZBVRUP6t5sIy5jnSZG+I5h0BUxSizw5ekxbKWlfCicFSZStbu Ln6ptTTJVzUg3QpSR6jN =a7ty -----END PGP SIGNATURE-----

2 2

Re: [PATCH 2/2] winemac: Don't pump messages in ChangeDisplaySettings (v3).
by Ken Thomases April 27, 2015

April 27, 2015

On Apr 27, 2015, at 2:54 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Version 3: Use SendNotifyMessage for sending WM_MACDRV_DISPLAYCHANGE. > Ken, I need your review again to make sure that this change doesn't > have any negative impact regarding the sync_window_position call that > is part of the WM_MACDRV_DISPLAYCHANGE message handling. Looks OK to me. It is not necessary for the sync_window_position() call to be made synchronously with respect to the sending code. -Ken

1 0

Re: [PATCH 5/5] d3d9/tests: Add spotlight and light range tests.
by Marvin April 27, 2015

April 27, 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=13061 Your paranoid android. === build (build) === Patch failed to apply

2 1

Re: shell32: Add Association Registry entries (resend)
by Marvin April 27, 2015

April 27, 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=13043 Your paranoid android. === w2000pro (32 bit assoc) === The test timed out

1 0

Re: [PATCH 1/2] winex11: Don't pump messages in ChangeDisplaySettings (v3).
by Marvin April 27, 2015

April 27, 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=13041 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2497: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2510: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

1 0

Re: [3/3] user32: Don't perform SetWindowPos synchronously.
by Marvin April 27, 2015

April 27, 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=13038 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0017014A msg.c:12252: Test failed: bad time 31267/31276

1 0

Re: [1/3] user32/tests: Add a test for calling SetWindowPos for other thread window.
by Marvin April 27, 2015

April 27, 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=13037 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 00150136 msg.c:12252: Test failed: bad time 31100/3111f

1 0

Re: [PATCH 4/5] wined3d: Don't use the builtin FFP uniforms for texture transformation matrices. (v3)
by Henri Verbeet April 26, 2015

April 26, 2015

On 24 April 2015 at 22:25, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +static void shader_glsl_ffp_vertex_texmatrix_uniform(const struct wined3d_context *context, > + const struct wined3d_state *state, unsigned int tex, struct glsl_shader_prog_link *prog) > +{ > + const struct wined3d_gl_info *gl_info = context->gl_info; > + struct wined3d_matrix mat; > + > + if (tex >= MAX_TEXTURES) > + return; I think the patch is fine as it is, but as a style comment, arguably you aren't so much validating "tex" against MAX_TEXTURES here as against ARRAY_SIZE(texture_matrix_location).

1 0

Re: [PATCH] wined3d: fix wrong struct initialization
by Henri Verbeet April 26, 2015

April 26, 2015

On 26 April 2015 at 12:22, Patrick Rudolph <siro(a)das-labor.org> wrote: > - static const struct wined3d_query_data_timestamp_disjoint > disjoint_data = {FALSE, 1000 * 1000 * 1000}; > + static const struct wined3d_query_data_timestamp_disjoint > disjoint_data = {1000 * 1000 * 1000, FALSE}; The change is fine like this, but unfortunately it looks like your MUA has wrapped the patch.

1 0

Re: advapi32/tests: Add tests for RegQueryInfoKey.
by Nikolay Sivov April 26, 2015

April 26, 2015

On 04/25/2015 08:41 PM, Thomas Faber wrote: > + /* class name with buffer one char too small */ > + memset(classbuffer, 0x55, sizeof(classbuffer)); > + classlen = sizeof(subkey_class) - 1; > + ret = RegQueryInfoKeyA(subkey, classbuffer, &classlen, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); > + ok(ret == ERROR_MORE_DATA, "ret = %d\n", ret); > + todo_wine ok(classlen == sizeof(subkey_class) - 2, "classlen = %u\n", classlen); > + todo_wine ok(classbuffer[0] == 's', "classbuffer[0] = 0x%x\n", classbuffer[0]); > + todo_wine ok(classbuffer[1] == 'u', "classbuffer[1] = 0x%x\n", classbuffer[1]); > + todo_wine ok(classbuffer[10] == 's', "classbuffer[10] = 0x%x\n", classbuffer[10]); > + todo_wine ok(classbuffer[11] == 0, "classbuffer[11] = 0x%x\n", classbuffer[11]); > + ok(classbuffer[12] == 0x55, "classbuffer[12] = 0x%x\n", classbuffer[12]); I think it would be more readable if you tested it against a string. Also hardcoded offsets could be avoided in this case. > + memset(classbufferW, 0x55, sizeof(classbufferW)); > + classlen = sizeof(subkey_class) - 1; > + ret = RegQueryInfoKeyW(subkey, classbufferW, &classlen, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); > + todo_wine ok(ret == ERROR_INSUFFICIENT_BUFFER, "ret = %d\n", ret); > + ok(classlen == sizeof(subkey_class) - 2 /* win8 */ || > + classlen == strlen(subkey_class), "classlen = %u\n", classlen); > + ok(classbufferW[0] == 0x5555, "classbufferW[0] = 0x%x\n", classbufferW[0]); > + ok(classbufferW[1] == 0x5555, "classbufferW[1] = 0x%x\n", classbufferW[1]); > + ok(classbufferW[10] == 0x5555, "classbufferW[10] = 0x%x\n", classbufferW[10]); > + ok(classbufferW[11] == 0x5555, "classbufferW[11] = 0x%x\n", classbufferW[11]); > + ok(classbufferW[12] == 0x5555, "classbufferW[12] = 0x%x\n", classbufferW[12]); If first element is not changed, it's really unlikely that anything else did. > + ok(classbuffer[12] == 0, "classbuffer[12] = 0x%x\n", classbuffer[12]); > + ok(classbuffer[13] == 0x55, "classbuffer[13] = 0x%x\n", classbuffer[13]); ... > + ok(!lstrcmpW(classbufferW, subkey_classW), "classbufferW = %s\n", wine_dbgstr_w(classbufferW)); > + ok(classbufferW[12] == 0, "classbufferW[12] = 0x%x\n", classbufferW[12]); > + ok(classbufferW[13] == 0x5555, "classbufferW[13] = 0x%x\n", classbufferW[13]); Could you replace offsets with calculated string length instead so it still works for different strings.

2 1

Re: [PATCH] wined3d: fix wrong data order for D3DQUERYTYPE_TIMESTAMPDISJOINT
by Henri Verbeet April 25, 2015

April 25, 2015

On 25 April 2015 at 14:26, Patrick Rudolph <siro(a)das-labor.org> wrote: > At the moment the querry D3DQUERYTYPE_TIMESTAMPDISJOINT returns TRUE instead > of FALSE due to wrong data order in struct > wined3d_query_data_timestamp_disjoint. > Please use "git send-email" for sending patches. (Or fix your MUA to inline them.) Unfortunately swapping the order of the fields will introduce a hole in the structure between "disjoint" and "frequency", and make it incompatible with the equivalent d3d10 structure (D3D10_QUERY_DATA_TIMESTAMP_DISJOINT). I think it would be much nicer to fix the initializer of "disjoint_data" in wined3d_timestamp_disjoint_query_ops_get_data() to match the structure layout instead.

1 0

Re: (resend)comctl32:TTM_SETTOOLINFO does not change subclassing
by Alexandre Julliard April 24, 2015

April 24, 2015

Aric Stewart <aric(a)codeweavers.com> writes: > + toolInfo2.cbSize = TTTOOLINFOA_V1_SIZE; > + toolInfo2.hwnd = parent2; > + toolInfo2.uId = 0x1234ABCE; > + lResult = SendMessageA(hwndTip, TTM_GETTOOLINFOA, 0, (LPARAM)&toolInfo2); > + ok(lResult, "GetToolInfo failed\n"); > + ok(!(toolInfo2.uFlags & TTF_SUBCLASS), "uFlags has subclass\n"); > + wndProc = GetWindowLongPtrA(parent2, GWLP_WNDPROC); > + ok (wndProc == (DWORD)(&info_wnd_proc), "Window Proc is wrong\n"); > + > + toolInfo2.uFlags |= TTF_SUBCLASS; > + SendMessageA(hwndTip, TTM_SETTOOLINFOA, 0, (LPARAM)&toolInfo2); > + lResult = SendMessageA(hwndTip, TTM_GETTOOLINFOA, 0, (LPARAM)&toolInfo2); > + ok(lResult, "GetToolInfo failed\n"); > + ok(toolInfo2.uFlags & TTF_SUBCLASS, "uFlags does not have subclass\n"); > + ok (wndProc == (DWORD)(&info_wnd_proc), "Window Proc is wrong\n"); Please use the correct types for window function pointers. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 5/5] wined3d: Move volume DXTn handling to apply_format_fixups.
by Henri Verbeet April 24, 2015

April 24, 2015

This fails the d3dx9_36 tests: ../../../tools/runtest -q -P wine -T ../../.. -M d3dx9_36.dll -p d3dx9_36_test.exe.so texture && touch texture.ok ... texture.c:1778: Test failed: D3DXCreateVolumeTextureFromFileInMemory returned 0x8876086c, expected 0

1 0

Re: [PATCH 6/6] wined3d: Introduce a scratch string buffers framework.
by Henri Verbeet April 23, 2015

April 23, 2015

On 22 April 2015 at 19:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > It's somewhat of an RFC at this point. In particular I'd like some > feedback about the API. In general, I think it goes in the right direction. > An obvious variant would be to store the pointer to the parent > wined3d_shader_buffer structure right before the string and just > return the string itself (thus avoiding having to add ->buffer to > all the uses of the string). Personally, I don't particularly mind the couple of extra characters, and it seems like a good thing to explicitly distinguish between string buffers and regular strings. > + tex_reg_name = shader_sprintf_unsafe(&priv->string_buffers, "tex%u", stage); > shader_glsl_color_correction_ext(buffer, tex_reg_name, WINED3DSP_WRITEMASK_ALL, > settings->op[stage].color_fixup); The problem with this construction is that it is likely to break as soon as shader_glsl_color_correction_ext() does anything that ends up calling shader_get_buffer(). To make it worse, shader_glsl_color_correction_ext() isn't aware of this because it just gets a const char *, and shader_glsl_generate_ffp_fragment_shader() isn't supposed to care about the internals of shader_glsl_color_correction_ext(). > @@ -276,13 +276,17 @@ int shader_vaddline(struct wined3d_shader_buffer *buffer, const char *format, va > char *base = buffer->buffer + buffer->content_size; > int rc; > char *new_buffer; > + unsigned int new_buffer_size; > > while(1) > { > rc = vsnprintf(base, buffer->buffer_size - buffer->content_size, format, args); > if (rc < 0 /* C89 */ || (unsigned int)rc >= buffer->buffer_size - buffer->content_size /* C99 */) > { > - new_buffer = HeapReAlloc(GetProcessHeap(), 0, buffer->buffer, buffer->buffer_size * 2); > + new_buffer_size = buffer->buffer_size * 2; > + while (rc > 0 && (unsigned int)rc >= new_buffer_size - buffer->content_size) > + new_buffer_size *= 2; > + new_buffer = HeapReAlloc(GetProcessHeap(), 0, buffer->buffer, new_buffer_size); > if (!new_buffer) > { > ERR("The buffer allocated for the shader program string is too small at %d bytes.\n", buffer->buffer_size); > @@ -290,7 +294,7 @@ int shader_vaddline(struct wined3d_shader_buffer *buffer, const char *format, va > return -1; > } > buffer->buffer = new_buffer; > - buffer->buffer_size = buffer->buffer_size * 2; > + buffer->buffer_size = new_buffer_size; > base = buffer->buffer + buffer->content_size; > } > else This is a bit of an unrelated change, but probably the right thing to do. Note that I have an unsent patch that separates tracing the shader source from shader_vaddline() though, so it's going to look a bit different fairly soon. > +static char shader_empty_string[] = ""; This should be const, right? > +static void shader_sprintf_va_list(struct wined3d_shader_buffer *buffer, const char *format, va_list args) I probably would have called that vprintf/vsprintf instead of sprintf_va_list. > +{ > + int ret; > + char *new_buffer; > + unsigned int new_buffer_size; > + > + if (!buffer) > + return; > + while (1) > + { > + ret = vsnprintf(buffer->buffer, buffer->buffer_size, format, args); > + if (ret < 0 || (unsigned int)ret >= buffer->buffer_size) > + { > + new_buffer_size = buffer->buffer_size * 2; > + while (ret > 0 && (unsigned int)ret >= new_buffer_size) > + new_buffer_size *= 2; > + new_buffer = HeapReAlloc(GetProcessHeap(), 0, buffer->buffer, new_buffer_size); > + if (!new_buffer) > + { > + ERR("Couldn't allocate buffer for temporary string.\n"); > + buffer->buffer[0] = 0; > + return; > + } > + buffer->buffer = new_buffer; > + buffer->buffer_size = new_buffer_size; > + } > + else > + { > + break; > + } > + } > +} Once tracing the shader source is removed from shader_vaddline(), this comes down to a shader_buffer_clear() followed by shader_vaddline(). And arguably shader_get_buffer() should always shader_buffer_clear() the buffers it returns. > +/* This function immediately puts the buffer back into the free list (it's > + * intended to be used when the string is to be used and discarded immediately, > + * mostly useful to avoid having to move the string pointer out of the block). */ > +const char *shader_sprintf_unsafe(struct list *buffer_list, const char *format, ...) Not a fan, for the reasons mentioned at shader_glsl_generate_ffp_fragment_shader() above. > +void shader_release_buffer(struct list *list, struct wined3d_shader_buffer *buffer) > +{ > + if (!buffer) > + return; Can buffer ever legitimately be NULL? > +void shader_buffer_list_free(struct list *list) > +{ > + struct wined3d_shader_buffer *buffer, *buffer_next; > + > + LIST_FOR_EACH_ENTRY_SAFE(buffer, buffer_next, list, struct wined3d_shader_buffer, entry) > + { > + shader_buffer_free(buffer); > + HeapFree(GetProcessHeap(), 0, buffer); > + } > +} > + This doesn't actually remove the buffers from the list. There may also be an argument for wrapping the list itself in a structure, similar to struct wined3d_private_store. > struct wined3d_shader_buffer > { At some point we'll probably want to rename this to something like "wined3d_string_buffer".

2 2