September 2010 - Wine-Devel

Re: [1/5] urlmon: Implemented validation of the host name component of a IUriBuilder

by Alexandre Julliard

Thomas Mullaly <thomas.mullaly(a)gmail.com> writes: > -#define ALLOW_NULL_TERM_SCHEME 0x1 > -#define ALLOW_NULL_TERM_USER_NAME 0x2 > -#define ALLOW_NULL_TERM_PASSWORD 0x4 > +#define ALLOW_NULL_TERM_SCHEME 0x1 > +#define ALLOW_NULL_TERM_USER_NAME 0x2 > +#define ALLOW_NULL_TERM_PASSWORD 0x4 > +#define ALLOW_BRACKETLESS_IP_LITERAL 0x8 > +#define SKIP_IP_FUTURE_CHECK 0x16 > +#define IGNORE_PORT_DELIMITER 0x32 These won't work as flags... -- Alexandre Julliard julliard(a)winehq.org

Sept. 27, 2010

RE: Sound on TestBot

by Francois Gouget

On Fri, 17 Sep 2010, Greg Geldorp wrote: [...] > Note that most people probably use VMware Workstation. Workstation > emulates an SoundBlaster (I think?) card, so there's actually virtual > hardware in there. This means you can install a normal SoundBlaster > driver, the driver will send commands to the virtual hardware device > which are then picked up by the Workstation virtual hardware layer. Yes, I use VMware Workstation which emulates a Sound Blaster PCI 128 sound card: depending on the place the driver is either called 'Creative AudioPCI (ES1371,ES1373)' or 'Creative Sound Blaster PCI'. Strangely enough, my Win9x VMs use the same driver (but only older and for win9x obviously) and although they all have a Midi device, none of them seems to get stuck in the midi test. Only the Windows XP and NT4 VMs seem to have trouble. I tried commenting out all the UART lines in wdma_ens.inf in Windows XP as described in http://www.winehq.org/pipermail/wine-devel/2010-March/082116.html but this had no effect. I also tried reinstalling the device afterwards (by deleting it in the device manager and letting XP redetect it), but to no avail. The driver's Properties tab in the hardware device manager gave me some hope because it has a 'Do not use MIDI features on this device' radio button. However checking it disables the driver entirely :-( So unless someone else finds a solution maybe the route to go is to apply this patch: http://www.winehq.org/pipermail/wine-devel/attachments/20100302/ac1a08e3/at… -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

Sept. 27, 2010

Re: [1/3] comctl32/tab: Add a test for TCM_SETITEMEXTRA

by Nikolay Sivov

On 9/27/2010 17:32, Vitaliy Margolen wrote: > On 09/27/2010 01:17 AM, Nikolay Sivov wrote: >> We always use the same parent window and I don't see a reason of >> having more >> parent windows for tests, so this kind of flexibility is useless >> here. Same >> for tab count - we don't run test with tables or even with different tab >> count so it makes no sense to pass it as parameter. > > It doesn't mean no one will use different parent o a different number > of tabs in the future. Regardless, it should be a separate patch. Of course future is always a mystery, anything could be possibly done someday, for now it's a cleanup of practically unused function parameters. About separate patch - I don't think this change is important enough to produce a separate patch for it. Yes, for code it's important, for tests it could go with other changes imho. > > Vitaliy.

Sept. 27, 2010

Re: [1/3] comctl32/tab: Add a test for TCM_SETITEMEXTRA

by Vitaliy Margolen

On 09/27/2010 01:17 AM, Nikolay Sivov wrote: > We always use the same parent window and I don't see a reason of having more > parent windows for tests, so this kind of flexibility is useless here. Same > for tab count - we don't run test with tables or even with different tab > count so it makes no sense to pass it as parameter. It doesn't mean no one will use different parent o a different number of tabs in the future. Regardless, it should be a separate patch. Vitaliy.

Sept. 27, 2010

Re: [PATCH 1/5] d3dcompiler_43/tests: Added HLSL test suite

by Stefan Dösinger

Am 27.09.2010 um 12:57 schrieb Henri Verbeet: > On 27 September 2010 02:22, Travis Athougies <iammisc(a)gmail.com> wrote: >>>> + /* The Direct3D 9 docs state that we cannot lock a render target surface, >>>> + instead we must copy the render target onto this surface to lock it */ >>> I think you can, if you create it with D3DUSAGE_DYNAMIC | D3DUSAGE_RENDERTARGET. If you want the backbuffer to be lockable you'll need some device creation flag whose name I forgot. >> >> There is the lockable boolean argument that I think might work. I will >> look into using this >> > Please don't. I think GetRenderTargetData() is the correct way to do > this. I remember running into problems with this on some windows drivers(*) with surfaces from swapchains, which is why getPixelColor in the d3d9 tests uses StretchRect to a lockable offscreen render target to read the backbuffer. This may however be outdated and apparently doesn't apply to offscreen RTs - the d3d9 tests use GetRenderTargetData on offscreen RTs and I haven't seen an issue. (*) I think it was my radeon 9000 mobility driver on the old acer travelmate 800.

Sept. 27, 2010

Re: [4/5] msxml3/httprequest: Store user defined request headers on transaction beginning

by Jacek Caban

Hi Nikolay, On 9/25/10 10:16 PM, Nikolay Sivov wrote: > Store user defined request headers on transaction beginning + buff = CoTaskMemAlloc((size+1)*sizeof(WCHAR)); + if (!buff) return E_OUTOFMEMORY; + + LIST_FOR_EACH_ENTRY(entry,&This->request->reqheaders, struct reqheader, entry) + { + LONG header_size = SysStringLen(entry->header) + SysStringLen(entry->value) + 4 /* colon, space, CRLF */; + + /* get large enough buffer */ + while (freech< header_size) + { + WCHAR *buff2; + + freech += size; + size *= 2; + buff2 = CoTaskMemRealloc(buff, (size+1)*sizeof(WCHAR)); This is very inefficient. You can compute header size before doing allocation, so that no reallocation is needed. And even when doing reallocation, the inner loop may be easily avoided. Jacek

Sept. 27, 2010

Re: [1/5] msxml3/httprequest: Store passed data for IXMLHttpRequest::open()

by Jacek Caban

Hi Nikolay, On 9/25/10 10:15 PM, Nikolay Sivov wrote: > Store passed data for IXMLHttpRequest::open() + hr = VariantChangeType(&async,&async, 0, VT_BOOL); + This->async = (hr == S_OK) ? V_BOOL(&async) : FALSE; You mix BOOL and VARIANT_BOOL here. |This->async = (hr == S_OK) && V_BOOL(&async)| will do what you want. + hr = VariantChangeType(&user,&user, 0, VT_BSTR); + if (hr == S_OK) + This->user = SysAllocString(V_BSTR(&user)); You potentially leak here. + hr = VariantChangeType(&password,&password, 0, VT_BSTR); + if (hr == S_OK) + This->password = SysAllocString(V_BSTR(&password)); And here. + { + return SysReAllocString(&entry->value, value) == TRUE ? S_OK : E_OUTOFMEMORY; + You shouldn't compare to TRUE value. This should be |return SysReAllocString(...) ? S_OK : E_OUTOFMEMORY|. + *bind_flags = BINDF_FROMURLMON; Are you sure you need BINDF_FROMURLMON here? This flag is set by urlmon before calling protocol handler. + hr = BindStatusCallback_create(This,&bsc); + if (FAILED(hr)) return hr; + + ERR("%x\n", hr); Debugging code left? Jacek

Sept. 27, 2010

Re: [PATCH 1/5] d3dcompiler_43/tests: Added HLSL test suite

by Henri Verbeet

On 27 September 2010 02:22, Travis Athougies <iammisc(a)gmail.com> wrote: >>> + /* The Direct3D 9 docs state that we cannot lock a render target surface, >>> + instead we must copy the render target onto this surface to lock it */ >> I think you can, if you create it with D3DUSAGE_DYNAMIC | D3DUSAGE_RENDERTARGET. If you want the backbuffer to be lockable you'll need some device creation flag whose name I forgot. > > There is the lockable boolean argument that I think might work. I will > look into using this > Please don't. I think GetRenderTargetData() is the correct way to do this. Generally you don't want lockable render targets at all, but the case where they're "useful" is for writing data to the render target, not reading. The problem with your current setup is that you do the readback after doing a Present(). Present() invalidates the contents of the backbuffer. > + ok(data[0] == D3DCOLOR_ARGB(0, 0, 255, 255), > + "swizzle_test: Got color %08x (should be 0x0000FFFF)\n", data[0]); While I doubt you're going to care a lot for this specific test, I think it makes sense to integrate something like color_match() from the d3d9 tests right from the start. In fact, I think the way you want to do this is to keep the actual testing inside compile_pixel_shader9(). E.g., you could pass it an array with things like probe locations, expected values, allowed deviations and failure messages. > + if (caps.PixelShaderVersion >= 0xffff0200) You can just use D3DPS_VERSION(2, 0) here.

Sept. 27, 2010

Re: d3d9: Add a sRGB format test

by Henri Verbeet

On 25 September 2010 23:45, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + struct > + { > + D3DFORMAT fmt; > + const char *name; > + } > + formats[] = > + { > + { D3DFMT_R5G6B5, "D3DFMT_R5G6B5" }, > + { D3DFMT_X8R8G8B8, "D3DFMT_X8R8G8B8" }, > + { D3DFMT_A8R8G8B8, "D3DFMT_A8R8G8B8" }, > + { D3DFMT_A16B16G16R16F, "D3DFMT_A16B16G16R16F" }, > + { D3DFMT_A32B32G32R32F, "D3DFMT_A32B32G32R32F" }, > + }; This should be static const. I recently fixed a number of these. > + const float quad[] = { > + -1.0, -1.0, 0.1, 0.0, 0.0, > + -1.0, 1.0, 0.1, 1.0, 0.0, > + 1.0, -1.0, 0.1, 0.0, 1.0, > + 1.0, 1.0, 0.1, 1.0, 1.0 > + }; Please use a proper structure?

Sept. 27, 2010

Re: [1/3] comctl32/tab: Add a test for TCM_SETITEMEXTRA

by Nikolay Sivov

On 9/27/2010 10:14, Vitaliy Margolen wrote: > On 09/26/2010 05:08 PM, Nikolay Sivov wrote: >> Add a test for TCM_SETITEMEXTRA >> >> >> >> > >> +static HWND parent_wnd; >> -static void test_curfocus(HWND parent_wnd, INT nTabs) >> +static void test_curfocus(void) >> { >> - hTab = createFilledTabControl(parent_wnd, TCS_FIXEDWIDTH, >> TCIF_TEXT|TCIF_IMAGE, nTabs); >> + hTab = createFilledTabControl(parent_wnd, TCS_FIXEDWIDTH, >> TCIF_TEXT|TCIF_IMAGE, 5); > > So how is the global better then function parameter? Or a magic number? We always use the same parent window and I don't see a reason of having more parent windows for tests, so this kind of flexibility is useless here. Same for tab count - we don't run test with tables or even with different tab count so it makes no sense to pass it as parameter. > > Vitaliy.

Sept. 27, 2010