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

Re: [PATCH 1/4] msvcrt: Don't raise exception in _invalid_parameter (try2)

by Marvin

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=6473 Your paranoid android. === wxppro (32 bit misc) === misc.c:335: Test failed: buf = C:\Documents and Settings\winetest\My Documents\msvcrt_test.exe misc popen misc.c:338: Test failed: _pclose returned 1, expected 0x37

April 21, 2014

Re: The (broken) state of the WineTestBot

by Jacek Caban

Hi Francois, First of all, thanks for the hard work to WineTestBot working. On 04/18/14 23:25, Francois Gouget wrote: > * w7pro64 - Windows 7 Professional (64-bit) > It has all the latest Windows updates so it has Internet Explorer 11 > too. FWIW, I think upgrading to IE11 was a bad decision. Existing tests results made it clear that this will cause new failures on those VMs. While ideally we should fix tests on IE11 (I already fixed most of them, quite a few are still remaining), the upgrade should be better coordinated. Recovering from bad breakage of WineTestBot seems like the worst possible moment for increasing number of failures. This also makes base VMs unreliable for quite a few tests again for no good reason. We already knew those failures so the upgrade could wait just a bit more. We've just a lot further from having at least one succeeding win7 box again. Jacek

April 21, 2014

Re: msvcrt: Remove wine-specific exports

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > --- > dlls/msvcr100/msvcr100.spec | 4 ++-- > dlls/msvcr110/msvcr110.spec | 4 ++-- > dlls/msvcr70/msvcr70.spec | 4 ++-- > dlls/msvcr71/msvcr71.spec | 4 ++-- > dlls/msvcr80/msvcr80.spec | 4 ++-- > dlls/msvcr90/msvcr90.spec | 4 ++-- > dlls/msvcrt/mbcs.c | 7 ++---- > dlls/msvcrt/msvcrt.spec | 53 > --------------------------------------------- > dlls/msvcrt/string.c | 6 +++-- > 9 files changed, 18 insertions(+), 72 deletions(-) It doesn't work: ../../../tools/runtest -q -P wine -T ../../.. -M msvcrt.dll -p msvcrt_test.exe.so string && touch string.ok wine: Unhandled exception 0xc0000417 in thread 62 at address 0x7b83aa0e (thread 0062), starting debugger... Unhandled exception: 0xc0000417 in 32-bit code (0x7b83aa0e). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7b83aa0e ESP:0032f9a4 EBP:0032fa18 EFLAGS:00000246( - -- I Z- -P- ) EAX:7b826b79 EBX:7b8b5dac ECX:00000000 EDX:00000000 ESI:c0000417 EDI:00000000 Stack dump: 0x0032f9a4: 0032f9c4 009d0152 7bcc4514 c0000417 0x0032f9b4: 00000001 00000000 7b83aa0e 00000000 0x0032f9c4: 0032fa40 687415e1 68718cdf 00b100b0 0x0032f9d4: 00b300b2 039c00b4 681c8cc0 00000001 0x0032f9e4: 687415e0 0032fa28 6802d1bc 00000001 0x0032f9f4: 687415e0 68718cdf 68718c75 0032fa40 Backtrace: =>0 0x7b83aa0e RaiseException+0x5e(code=<couldn't compute location>, flags=<couldn't compute location>, nbargs=<couldn't compute location>, args=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/except.c:84] in kernel32 (0x0032fa18) 1 0x686c9b5d MSVCRT__invalid_parameter+0x8c() in msvcrt (0x0032fa78) 2 0x686da0c8 MSVCRT_memcpy_s+0x87(dest=0x6869112c, numberOfElements=0x8, src=0x68688415, count=0xf) [/home/julliard/wine/wine/dlls/msvcrt/heap.c:645] in msvcrt (0x0032fac8) 3 0x6865d547 test_memcpy_s+0x1f6() [/home/julliard/wine/wine/dlls/msvcrt/tests/string.c:581] in msvcrt_test (0x0032fb48) 4 0x686686c6 func_string+0xe55() [/home/julliard/wine/wine/dlls/msvcrt/tests/string.c:2737] in msvcrt_test (0x0032fd48) 5 0x6862b021 main+0x2f0(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/msvcrt/tests/../../../include/wine/test.h:584] in msvcrt_test (0x0032fe18) -- Alexandre Julliard julliard(a)winehq.org

April 21, 2014

Re: mshtml: Added IHTMLTable::width property implementation.

by Jacek Caban

Hi Zhenbo, It looks better now. On 04/19/14 03:38, Zhenbo Li wrote: > @@ -395,15 +422,60 @@ static HRESULT WINAPI HTMLTable_get_rows(IHTMLTable *iface, IHTMLElementCollecti > static HRESULT WINAPI HTMLTable_put_width(IHTMLTable *iface, VARIANT v) > { > HTMLTable *This = impl_from_IHTMLTable(iface); > - FIXME("(%p)->(%s)\n", This, debugstr_variant(&v)); > - return E_NOTIMPL; > + nsAString val; > + HRESULT hres; > + nsresult nsres; > + > + TRACE("(%p)->(%s)\n", This, debugstr_variant(&v)); > + hres = var2str(&val, &v); > + > + if (hres != S_OK){ > + ERR("Set Width(%s) failed when initializing a nsAString!\n", > + debugstr_variant(&v)); > + nsAString_Finish(&val); val is not initialized here, so you shouldn't call nsAString_Finish on it. > + return hres; > + } > + > + nsres = nsIDOMHTMLTableElement_SetWidth(This->nstable, &val); > + nsAString_Finish(&val); > + > + if (NS_FAILED(nsres)){ > + ERR("Set Width(%s) failed!\n", debugstr_variant(&v)); > + return E_FAIL; > + } > + > + return S_OK; > } > > static HRESULT WINAPI HTMLTable_get_width(IHTMLTable *iface, VARIANT *p) > { > HTMLTable *This = impl_from_IHTMLTable(iface); > - FIXME("(%p)->(%p)\n", This, p); > - return E_NOTIMPL; > + nsAString val; > + nsresult nsres; > + DOUBLE width; > + const PRUnichar *str; > + > + TRACE("(%p)->(%p)\n", This, p); > + nsAString_Init(&val, NULL); > + nsres = nsIDOMHTMLTableElement_GetWidth(This->nstable, &val); > + if (NS_FAILED(nsres)){ > + ERR("Get Width(%s) failed!\n", debugstr_variant(p)); > + nsAString_Finish(&val); > + return E_FAIL; > + } > + > + nsAString_GetData(&val, &str); > + nsres = VarR8FromStr(str, 0, 0, &width); > + if (nsres == S_OK){ > + V_VT(p) = VT_I4; > + V_I4(p) = (LONG)width; > + } else { /* Symbols are in this string */ > + V_VT(p) = VT_BSTR; > + V_BSTR(p) = SysAllocString(str); > + if (!V_BSTR(p)) > + return E_OUTOFMEMORY; > + } > + return S_OK; > } > > static HRESULT WINAPI HTMLTable_put_height(IHTMLTable *iface, VARIANT v) > diff --git a/dlls/mshtml/tests/dom.c b/dlls/mshtml/tests/dom.c > index 23677f4..10aca6c 100644 > --- a/dlls/mshtml/tests/dom.c > +++ b/dlls/mshtml/tests/dom.c > @@ -5721,6 +5721,25 @@ static void _test_table_cell_spacing(unsigned line, IHTMLTable *table, const cha > VariantClear(&v); > } > > +#define cmp_length(a,b) _cmp_length(__LINE__,a,b) > +static void _cmp_length(unsigned line, VARIANT got, const char * exstr) > +{ > + static char buf[64]; > + ok_(__FILE__,line) (V_VT(&got)==VT_BSTR || V_VT(&got)==VT_I4, > + "V_VT is %hu, expected VT_BSTR(%hu) or VT_I4(%hu)\n", > + V_VT(&got), VT_BSTR, VT_I4); Please make it stricter and allow only one, exactly expected in given case, type. According to my quick tests (as I mentioned earlier), it's always VT_BSTR. Did you ever see it being VT_I4 in real Windows? If my testing is tight, this test hides a problem with your getter implementation. Cheers, Jacek

April 21, 2014

Re: [PATCH 01/10] vbscript: Fixed CBool(try 3)

by Jacek Caban

Hi Shuai, On 04/21/14 03:45, Shuai Meng wrote: > - > - return return_bool(res, val); > + V_VT(res) = VT_EMPTY; > + return VariantChangeType(res, arg, VARIANT_LOCALBOOL, VT_BOOL); You can't assume that res is not NULL. If result of the function is not used, it will be NULL. A simple test case is like this: call CBool(0) Also, are you sure we want VARIANT_LOCALBOOL here? Did you test it (probably by running tests on localized Windows with translated string "False")? Looking at CBool tests: +Call ok(CBool(Empty) = False, "CBool(Empty) = " & CBool(Empty)) +Call ok(getVT(CBool(Empty)) = "VT_BOOL", "getVT(CBool(Empty)) = " & getVT(CBool(Empty))) +Call ok(CBool(1) = True, "CBool(1) = " & CBool(1)) +Call ok(getVT(CBool(1)) = "VT_BOOL", "getVT(CBool(1)) = " & getVT(CBool(1))) +Call ok(CBool(CLng(0)) = False, "CBool(CLng(0)) = " & CBool(CLng(0))) +Call ok(getVT(CBool(CLng(0))) = "VT_BOOL", "getVT(CBool(CLng(0))) = " & getVT(CBool(CLng(0)))) +Call ok(CBool(CSng(0.5)) = True, "CBool(CSng(0.5)) = " & CBool(CSng(0.5))) +Call ok(getVT(CBool(CSng(0.5))) = "VT_BOOL", "getVT(CBool(CSng(0.5))) = " & getVT(CBool(CSng(0.5)))) +Call ok(CBool(-0.56) = True, "CBool(-0.56) = " & CBool(-0.56)) +Call ok(getVT(CBool(-0.56)) = "VT_BOOL", "getVT(CBool(-0.56)) = " & getVT(CBool(-0.56))) +Call ok(CBool(CCur(8.55)) = True, "CBool(CCur(8.55)) = " & CBool(CCur(8.55))) +Call ok(getVT(CBool(CCur(8.55))) = "VT_BOOL", "getVT(CBool(CCur(8.55))) = " & getVT(CBool(CCur(8.55)))) +Call ok(CBool(CDate(0)) = False, "CBool(CDate(0)) = " & CBool(CDate(0))) +Call ok(getVT(CBool(CDate(0))) = "VT_BOOL", "getVT(CBool(CDate(0))) = " & getVT(CBool(CDate(0)))) +Call ok(CBool(CDate(3.33)) = True, "CBool(CDate(3.33)) = " & CBool(CDate(3.33))) +Call ok(getVT(CBool(CDate(3.33))) = "VT_BOOL", "getVT(CBool(CDate(3.33))) = " & getVT(CBool(CDate(3.33)))) +Call ok(CBool("6666.78") = True, "CBool(""6666.78"") = " & CBool("6666.78")) +Call ok(getVT(CBool("6666.78")) = "VT_BOOL", "getVT(CBool(""6666.78"")) = " & getVT(CBool("6666.78"))) +Call ok(CBool(CByte(-0.1)) = False, "CBool(CByte(-0.1)) = " & CBool(CByte(-0.1))) +Call ok(getVT(CBool(CByte(-0.1))) = "VT_BOOL", "getVT(CBool(CByte(-0.1))) = " & getVT(CBool(CByte(-0.1)))) Those look mostly good. However I'd like to see some more tests. Interesting case is for example empty string and a "false", "False" and "#FALSE#" string. Also I'd really like to see tests on object default values. See the attached patch for an example. Those comments apply also to other patches in the series. It may be easier to proceed if you resent just the first patch fixed and include tests that don't depending on other patches in the series in the patch itself. Cheers, Jacek

April 21, 2014

Re: typo fixes - rebased - fixed

by Marvin

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=6455 Your paranoid android. === w7u (32 bit msg) === msg.c:12058: Test failed: unexpected hwnd 0017014A msg.c:12080: Test failed: bad time 310a2/310b2

April 20, 2014

Re: typo fixes - rebased - fixed

by Marvin

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=6454 Your paranoid android. === w2008s64 (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w7u (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w864 (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w2008s64 (64 bit moniker) === moniker: unhandled exception c0000005 at 000000000042024A === w864 (64 bit moniker) === moniker: unhandled exception c0000005 at 000000000042024A

April 20, 2014

Re: [PATCH 2/6] wined3d: Pass the volume texture level to the client libraries.

by Stefan Dösinger

Am 18.04.2014 um 20:03 schrieb Henri Verbeet <hverbeet(a)gmail.com>: > There's struct wined3d_texture_ops if there are no better options, but > yes, this may imply doing work to unify wined3d_surface_map() and > wined3d_volume_map() first. That was just an example though, the basic > point is that moving wined3d_volume calls from the d3d9 volume to the > d3d9 volume texture doesn't get us much closer to getting rid of > wined3d_volume in the public wined3d API. I did warn that this was > non-trivial to get right. We could go back to http://www.winehq.org/pipermail/wine-patches/2014-February/130248.html and merge resource management and resource mapping in a sub resource structure while keeping the resource structure around as long as needed. The main difference I’d suggest is not deriving wined3d_sub_resource from wined3d_resource. I’d prefer, but that’s not a requirement, to remove the get_resource_desc calls on surfaces and volumes before doing that. I realize that not calling those functions doesn’t make the interface go away (the only way to do that is to remove resource_from_surface), but it avoids exposing the to-be-removed resource data outside of wined3d. In terms of where we want to go wrt surfaces/volumes, subresources and resources: Surfaces and volumes would be responsible for storing and loading data in the GL texture. Surfaces also handle DIB sections for GetDC. Subresources take care of location management (the main motivation: Offscreen ORM can only load one mipmap sublevel into WINED3D_LOCATION_DRAWABLE). They take care of mapping PBOs and returning the correct pointer offset (motivation: user memory and DIBs are set per subresource). There’s some wiggle room on this point though. Subresources store the container, which is a wined3d_resource *. Textures (or rather, resources) take care of allocating textures, sysmem and PBOs. subresources can request the allocation and freeing of sysmem from their container. Textures will be resources, surfaces/volumes will be subresources. Buffers will be both, and they will be their own container. Resources take care of handling WINED3D_MAP_DISCARD and allocating new sysmem / pbos if necessary. While textures will allocate PBOs, they will allocate individual PBOs for each subresource because subresources can be mapped individually. In situations where GL_ARB_buffer_storage is available, and creating a an always-mapped PBO is feasible we can create one PBO for the entire texture and pre-map it at creation time or the first map. The main thing where I see two options with advantages / disadvantages: Do we store DIB and User pointer in the subresource or the surface: Storing them in the surface seems like the right place at first sight because they’re surface specific. But subresources need code to copy data between buffer and sysmem, and this code can be reused for DIBs and user memory as well. In that case we’d only call volume / surface specific code for loading textures, which means that code can assume a GL context is available. In my CS code surfaces allocate DIBs, but the DIB pointer is stored in struct wined3d_sub_resource. Somewhat related, I wonder if the hSection parameter of CreateDIBSection can be used to wrap a DIB section around our HeapAlloc’ed sysmem.

April 20, 2014

Re: typo fixes - rebased - fixed

by Marvin

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=6447 Your paranoid android. === w7u (32 bit msg) === msg.c:12058: Test failed: unexpected hwnd 00070140 msg.c:12080: Test failed: bad time 3118c/3119c

April 20, 2014

Re: typo fixes - rebased - fixed

by Marvin

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=6446 Your paranoid android. === w2008s64 (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w7u (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w864 (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w2008s64 (64 bit moniker) === moniker: unhandled exception c0000005 at 000000000042024A === w864 (64 bit moniker) === moniker: unhandled exception c0000005 at 000000000042024A

April 20, 2014

Re: typo fixes - rebased - fixed

by Nikolay Sivov

> - * INT oDefautlValue[nrargs]; > + * INT oDefaultlValue[nrargs]; This is wrong.

April 20, 2014

Re: [PATCH 10/10] vbscript/tests: Added tests for convert functions

by Marvin

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=6431 Your paranoid android. === w7u (32 bit run) === run.c:973: Test failed: api.vbs: L"CStr(CDate(1.5)) = 1899/12/31 12:00:00" run.c:973: Test failed: api.vbs: L"CStr(CDate(-1.5)) = 1899/12/29 12:00:00"

April 18, 2014

Re: mshtml: Added IHTMLTable::bgColor property implementation.

by Zhenbo Li

2014-04-07 13:05 GMT+08:00 Nikolay Sivov <bunglehead(a)gmail.com>: > On 4/6/2014 18:48, Zhenbo Li wrote: >> >> try 2: >> Don't free a string too early. >> >> --- >> dlls/mshtml/htmltable.c | 41 +++++++++++++++++++++++++++++++++++++---- >> dlls/mshtml/tests/dom.c | 35 +++++++++++++++++++++++++++++++++++ >> 2 files changed, 72 insertions(+), 4 deletions(-) >> > Also please check for variant_to_nscolor() return value. Thanks, Nikolay. Sorry for my late reply. I've checked the previous code in htmlbody.c, and found such code 385 static HRESULT WINAPI HTMLBodyElement_put_bgColor(IHTMLBodyElement *iface, VARIANT v) 386 { 387 HTMLBodyElement *This = impl_from_IHTMLBodyElement(iface); 388 nsAString strColor; 389 nsresult nsres; 390 391 TRACE("(%p)->(%s)\n", This, debugstr_variant(&v)); 392 393 if(!variant_to_nscolor(&v, &strColor)) 394 return S_OK; 395 396 nsres = nsIDOMHTMLBodyElement_SetBgColor(This->nsbody, &strColor); 397 nsAString_Finish(&strColor); 398 if(NS_FAILED(nsres)) 399 ERR("SetBgColor failed: %08x\n", nsres); 400 401 return S_OK; 402 } So when variant_to_nscolor failed (because VARIANT is invalid), wine would ignore it, and return S_OK. Maybe return E_FAIL is better? Also, in variant_to_nscolor, the return value of nsAString_Init is ignored. Is it good? Or should I write a patch to fix it? Thank you. -- Have a nice day! Zhenbo Li

April 18, 2014

Re: The (broken) state of the WineTestBot

by Francois Gouget

The new VM box is operational. It has an Intel Xeon E3-1230 and thus relies on kvm_intel instead of kvm_amd. But with the 3.13.1 kernel the VMs are still getting corrupted after a few hours :-( I have no idea why and I've never seen that issue on my personal box so I also have no idea how to figure out what's really going on. So the VM host is back to the 3.2.0 kernel. Since then I did not have not had a VM go bad. Then I moved on to restoring and updating the VMs. That's now done except for the two Vista VMs which I'll get to next. Here's what's new: * w2000pro - Windows 2000 Professional IPX (bug 35239) and AppleTalk support has been activated for its network card. I also 'inserted' the MemTest86 CD for the kernel32:volume test (bug 31780). * wxppro - Windows XP Professional It has all the updates it will ever get since its support period has now expired. As before it has WinPcap installed. * w2008s64 - Windows 2008 Server (64-bits) This VM now has two network cards. * w7u - Windows 7 Ultimate As with the other VMs I applied all Windows updates up to 2014/04/15, which means it now has Internet Explorer 11. As it's an Ultimate version I installed all the languages. Currently it's set up for Japanese but I can set it up for another language if desired. I also 'inserted' the MemTest86 CD so one can compare it with the equivalent in the Windows 2000 VM. * w7pro64 - Windows 7 Professional (64-bit) It has all the latest Windows updates so it has Internet Explorer 11 too. However it's a plain English environment so you can use detect locale issue by comparing it with the results of the w7u VM. * w8 - Windows 8 This has all the latest updates which means it's now running Windows 8.1 plus the Windows 8.1 Update. As before it also has the optional Direct X components, msxml4, and the Visual C++ runtime environments. And of course it now has Internet Explorer 11. * w864 - Windows 8 (64-bit) Like the previous VM it has all the updates and thus is running the Windows 8.1 Update and Internet Explorer 11, but without all the extras. If there's interest it's possible to run a VM from another snapshot, to test Windows 8.1 pre-Windows 8.1 for instance. -- Francois Gouget <fgouget(a)codeweavers.com>

April 18, 2014

Re: Wine test week 2 - nice apparent progress

by Francois Gouget

On Tue, 25 Mar 2014, Jeremy White wrote: [...] > Francois, do we have (or could we easily create) a mechanism to test that by > constraining the number of VMs that run simultaneously? Currently the way to do so is to send a patch to modify $MaxActiveVMs, and/or $MaxRevertsWhileRunningVMs in testbot/lib/WineTestBot/Config.pm to Alexandre. However the old VM host had an 8 core CPU and the limits are to run at most 2 VMs at once, and each VM has only 2 cores (except the build VM which had 4). So really there should not have been much contention on the cores (which it seems like should be all that matters for these tests). The new VM host has only 4 cores (+hyperthreading). We're still only running two VMs at a time but now the build VM only has 2 cores. We can do a test with $MaxActiveVMs = 1 and $MaxRevertsWhileRunningVMs = 0 but that would really limit performance. -- Francois Gouget <fgouget(a)codeweavers.com>

April 18, 2014

Re: [PATCH 2/6] wined3d: Pass the volume texture level to the client libraries.

by Henri Verbeet

On 18 April 2014 19:28, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Merging surface / volume map in texture_map doesn’t work well without having a common (internal) sub resource interface that the texture can call. Unless of course I do a switch(texture_type) and forward this to the separate surface_map and volume_map internally. > There's struct wined3d_texture_ops if there are no better options, but yes, this may imply doing work to unify wined3d_surface_map() and wined3d_volume_map() first. That was just an example though, the basic point is that moving wined3d_volume calls from the d3d9 volume to the d3d9 volume texture doesn't get us much closer to getting rid of wined3d_volume in the public wined3d API. I did warn that this was non-trivial to get right.

April 18, 2014

Re: [PATCH 2/6] wined3d: Pass the volume texture level to the client libraries.

by Stefan Dösinger

Am 18.04.2014 um 18:58 schrieb Henri Verbeet <hverbeet(a)gmail.com>: > I don't care about that ordering as much by itself. I do think that it > makes more sense to approach this as removing surfaces and volumes > from the public wined3d API than the approach you're taking here. > I.e., instead of e.g. forwarding d3d9_volume_LockBox() to > d3d9_texture_3d_LockBox() that then still does a wined3d_volume_map(), > I think it makes more sense to introduce wined3d_texture_map(), get > rid of wined3d_volume_map() and wined3d_surface_map(), and then let > the rest just fall out as a logical consequence. Related to that, I > think surfaces are the more interesting case to start with, because of > things like e.g. wined3d_device_set_render_target(), and perhaps more > importantly wined3d_device_get_render_target(). Merging surface / volume map in texture_map doesn’t work well without having a common (internal) sub resource interface that the texture can call. Unless of course I do a switch(texture_type) and forward this to the separate surface_map and volume_map internally.

April 18, 2014

Re: [PATCH 2/6] wined3d: Pass the volume texture level to the client libraries.

by Henri Verbeet

On 18 April 2014 18:08, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: >> I'm not convinced this is really necessary though, or that >> starting in d3d9 as opposed to wined3d with this is necessarily the >> right approach. > I prefer to remove as many calls to surfaces and volumes as possible > before changing them not to be resources. I don't care about that ordering as much by itself. I do think that it makes more sense to approach this as removing surfaces and volumes from the public wined3d API than the approach you're taking here. I.e., instead of e.g. forwarding d3d9_volume_LockBox() to d3d9_texture_3d_LockBox() that then still does a wined3d_volume_map(), I think it makes more sense to introduce wined3d_texture_map(), get rid of wined3d_volume_map() and wined3d_surface_map(), and then let the rest just fall out as a logical consequence. Related to that, I think surfaces are the more interesting case to start with, because of things like e.g. wined3d_device_set_render_target(), and perhaps more importantly wined3d_device_get_render_target().

April 18, 2014

Re: [PATCH 1/6] d3d9: Retrieve the volume description from the container.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-04-18 13:08, schrieb Henri Verbeet: > On 17 April 2014 15:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >> --- >> dlls/d3d9/texture.c | 20 +++++++++++++------- >> 1 file changed, 13 insertions(+), 7 deletions(-) >> > I suppose this works, but I don't think it's really necessary. At some > point wined3d_texture_get_sub_resource() will go away of course, but I > don't think there's a reason we can't e.g. have a > wined3d_resource_get_sub_resource_desc(), or alternatively just store > the information on d3d9 volume creation. Both of those alternatives work, but I'd prefer not to expose sub resources more than necessary. Map and get_dc need access to sub resources, but the rest of the information can be retrieved from the container. I'm not convinced that storing the size at creation is better either. Consider that surfaces can have their size changed by reset calls. That's not a strong opinion though, if you have a reason to prefer one of your suggestions I'm happy to change my plans. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTUVBbAAoJEN0/YqbEcdMwB1gQAJAequifOmY6HVgFhoIU2Xlw 0rltpGBXCKr9c64SXW4LiKPdNbGkHtWvxto5IZ1tFSpvbWeqbqYIsPhbLQZS02FD MhgbfjLKADcaEqSBH7h6cc3rIEnrIfaX9uYZZN50CkU31kqxLQiD5qeoHGTkG0Rw wAduomcPZ11CsbQSS0BTDR4ZoK2IthbyB48v2t2nZCvvng99aPP8LoDYHSGchiqh SGIWJV9jx6ExKD7KvZxBsk1Y65x4VeVtIx2lq9WijUsKVh7pNGAbrxtBXScDnL59 NWqstI+Oy65/HC37MMKIYQJlrdqnvZcfWGo/WyaN7hKIb7LaCeNidxvD/czhDEkZ eUW0v+rKT450HgAp/mkJdGi1JC0moebvDFFKESIx4FX3wIqqT2J21Ilw0C0lZs5D Phc5sPI08mD/iFDCVqgOgyquVzWorfOg2soiwzwsdjn3X1KKLd/cIBp8I37ngsCn nuklQPMAn+0x3enN1R9cdKmUJincb1bDhaZhDYEmnC3UJDvr2NOepmq0bEdxwaJX dCsADA+vP4lOFrVtLE8M8J7iNXrjvBpF2jEqmWK0oj//Gxt+83/OPS4kUMCV6ong G5A4ZHTXl3K8ksUVOyeEpL9ETUITeOgIQh4V/QxQJKLVgeN7B4RaI2j3kXccNJle DuZt18UkVlg/zVuBVXq9 =u6/y -----END PGP SIGNATURE-----

April 18, 2014

Re: [PATCH 2/6] wined3d: Pass the volume texture level to the client libraries.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-04-18 13:08, schrieb Henri Verbeet: > We got rid of this not too long ago, adding it back doesn't sound > very attractive. If you really need a way to find out a volume's > level, I'd prefer wined3d_volume_get_level() instead, mostly > because it doesn't need changes in every D3D library. As mentioned passing the information from wined3d is a temporary change only. Patch 6 removes it from d3d9. Once the same changes have been made to d3d8 the creation callback is gone. I guess I could avoid the temporary change by reordering the patches. > I'm not convinced this is really necessary though, or that > starting in d3d9 as opposed to wined3d with this is necessarily the > right approach. I prefer to remove as many calls to surfaces and volumes as possible before changing them not to be resources. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTUU4QAAoJEN0/YqbEcdMwr3YP/3ORrlipM1igNGQv9TFSJhg2 Q4hNUzEKNbpB94fsbI+HAbtX8LyvH5rC5R17aHTURrk3qo7PknfOrKE74T+jeD50 lCHR3YvJakRabjuvUn99bD6CAMMGaUVSr1tWIyoeplzoOoZ8DidnrnifubVCMaWl TIjcVW8elMwbi25tZkya9qELsb1BL53HTWTWlc/9L6a2OkiEqtX9t+/e+gliQE6X uB4PVXgDKN5D1Bhr4G3442SnHLcldbdy/oP/RbSKlGZaL+0Y3wu2CWtLU9XxvfCq bggGqpIWvOjM51zxj0kb1dSS/xQ4lOlhPUbE+UQVS8lJfz6jnwgvPB94plKEvJQ4 vrRUtG2wCdLmYPQ7kgI+6xb2QJLB+fMdf2z6h8l30/cXvkTdUdO4ifzZTMC15wJs PBRx7ALtbyh3rvPi4B9TnTcdC6KkgyciAGH2lfRA3yVmz84qnz0/qKs+WE6dZbxp mPI84DfH2KYwXZ1YxHoZHwj7/P58WYFcNRXGOi5FivF6Q2rXAbTg3+fTwxyko9Lr cEexXHxD39E7qTtxWDtRIPHrbsXUJFZ3mR3GAu6/6ZhqbeHYM8Fc4Em9vVDXvKf9 1VY+vX+MC8mH6TETP78riSekJYLXbPEIqil4yAYPBOEr6vO7PZqrGUxFTd+NUNM3 FxPWn41kSD0FXfmQTdqw =Vi8n -----END PGP SIGNATURE-----

April 18, 2014

Re: [wined3d] Add DF16 and DF24 formats

by Vijay Kiran Kamuju

Well I have to ask other users there if it helps them. As It did not show any FIXME's for those two formats. I think I have to remove the stencil there for D16 and D24, Its a copy paste error. I am checking the doc right now. Thanks, VJ On Fri, Apr 18, 2014 at 3:13 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 18 April 2014 16:46, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: >> + {WINED3DFMT_DF16, 0, 0, 0, 0, 16, 24, 8, 0, 0, 0, 0}, >> + {WINED3DFMT_DF24, 0, 0, 0, 0, 24, 24, 8, 0, 0, 0, 0}, > This is pretty much just wrong. > >> + {WINED3DFMT_DF16, GL_DEPTH24_STENCIL8_EXT, GL_DEPTH24_STENCIL8_EXT, 0, >> + GL_DEPTH_STENCIL_EXT, GL_UNSIGNED_INT_24_8_EXT, 0, >> + WINED3DFMT_FLAG_TEXTURE | WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING | WINED3DFMT_FLAG_FILTERING >> + | WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL, > WINED3DFMT_FLAG_STENCIL is suspicious here, since afaik these are > depth only formats. > > Note that you can't expose these formats without also implementing > "Fetch-4", since that's implied by DF24. See also > http://developer.amd.com/wordpress/media/2012/10/Advanced-DX9-Capabilities-…. > Does this patch help any application? > >

April 18, 2014

Re: [wined3d] Add DF16 and DF24 formats

by Henri Verbeet

On 18 April 2014 16:46, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > + {WINED3DFMT_DF16, 0, 0, 0, 0, 16, 24, 8, 0, 0, 0, 0}, > + {WINED3DFMT_DF24, 0, 0, 0, 0, 24, 24, 8, 0, 0, 0, 0}, This is pretty much just wrong. > + {WINED3DFMT_DF16, GL_DEPTH24_STENCIL8_EXT, GL_DEPTH24_STENCIL8_EXT, 0, > + GL_DEPTH_STENCIL_EXT, GL_UNSIGNED_INT_24_8_EXT, 0, > + WINED3DFMT_FLAG_TEXTURE | WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING | WINED3DFMT_FLAG_FILTERING > + | WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL, WINED3DFMT_FLAG_STENCIL is suspicious here, since afaik these are depth only formats. Note that you can't expose these formats without also implementing "Fetch-4", since that's implied by DF24. See also http://developer.amd.com/wordpress/media/2012/10/Advanced-DX9-Capabilities-…. Does this patch help any application?

April 18, 2014

Re: [PATCH 2/2] user32: add tests for valid cbSize in GetMonitorInfoA

by Bruno Jesus

On Fri, Apr 18, 2014 at 8:52 AM, <siro(a)das-labor.org> wrote: > should I iterate over all possible values other than sizeof(MONITORINFO) and sizeof(MONITORINFOEXA)‎ ? > Kind Regards, > Patrick Rudolph This is what I would do: Try to test sizeof(mi)+1, sizeof(mi)-1, -1, 0, 0xdeadbeef (and the same for miex). Memset(0) the structure before each test and choose a field that should never be zero to test if the struct was correctly filled aside from the success return value. Best Regards, Bruno

April 18, 2014

AW: [PATCH 2/2] user32: add tests for valid cbSize in GetMonitorInfoA

by siro＠das-labor.org

should I iterate over all possible values other than sizeof(MONITORINFO) and sizeof(MONITORINFOEXA)‎ ? Kind Regards, Patrick Rudolph Originalnachricht Von: Alexandre Julliard Gesendet: Freitag, 18. April 2014 13:47 An: Patrick Rudolph Cc: wine-devel(a)winehq.org Betreff: Re: [PATCH 2/2] user32: add tests for valid cbSize in GetMonitorInfoA Patrick Rudolph <siro(a)das-labor.org> writes: > @@ -362,6 +363,21 @@ static void test_monitors(void) > monitor = pMonitorFromRect( &rc, MONITOR_DEFAULTTONULL ); > } > > + /* sanity check */ > + monitor = pMonitorFromRect( &rc, MONITOR_DEFAULTTONEAREST ); > + mi.cbSize = sizeof(mi); > + ret = pGetMonitorInfoA( monitor, &mi ); > + ok( ret, "GetMonitorInfo failed\n" ); > + > + miex.cbSize = sizeof(miex); > + ret = pGetMonitorInfoA( monitor, (LPMONITORINFO)&miex ); > + ok( ret, "GetMonitorInfo failed\n" ); > + > + /* specify invalid cbSize */ > + mi.cbSize = 0xdeadbeef; > + ret = pGetMonitorInfoA( monitor, &mi ); > + ok( !ret, "GetMonitorInfo succeded\n" ); That's not a very convincing test. -- Alexandre Julliard julliard(a)winehq.org

April 18, 2014

Re: [2/5] user32: Add test calling EndMenu from WM_ENTERMENULOOP.

by Alexandre Julliard

Vincent Povirk <madewokherd(a)gmail.com> writes: > @@ -14525,6 +14582,7 @@ START_TEST(msg) > test_layered_window(); > test_TrackPopupMenu(); > test_TrackPopupMenuEmpty(); > + test_TrackPopupMenuAbort(); There's no need to write a separate function for each test, you could do them all as part of the main popup menu test. -- Alexandre Julliard julliard(a)winehq.org

April 18, 2014