wine-devel May 2011

wine-devel@winehq.org

79 participants
229 discussions

Start a nNew thread

Re: [15/15]usp10/test: add Lao shaping test
by Marvin 23 May '11

23 May '11

1 0

Re: [14/15]usp10/test: add Phags-pa shaping test
by Marvin 23 May '11

23 May '11

1 0

Re: [13/15]usp10/test: add Thaana shaping test
by Marvin 23 May '11

23 May '11

1 0

Re: [12/15]usp10/tests: add Syriac shaping test
by Marvin 23 May '11

23 May '11

1 0

Re: [8/15]usp10/tests: Hebrew shaping test
by Marvin 23 May '11

23 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11100 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === usp10.c:1594: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 73 usp10.c:1560: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1572: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 87 usp10.c:1573: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 71 usp10.c:1581: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 87 usp10.c:1582: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 88 usp10.c:1592: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 87 usp10.c:1608: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 87 usp10.c:1610: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 86 === W2KPROSP4 (32 bit usp10) === usp10.c:1594: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1560: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1572: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1573: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1581: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1582: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1592: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1608: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1610: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === WXPPROSP3 (32 bit usp10) === usp10.c:1594: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1560: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1572: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1573: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1581: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1582: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1592: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1608: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1610: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === W2K3R2SESP2 (32 bit usp10) === usp10.c:1594: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1560: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1572: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1573: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1581: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1582: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1592: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1608: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1610: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80

1 0

mmsystem16.h incorrect? SEGPTR vs. LPSTR
by Joerg-Cyril.Hoehle＠t-systems.com 23 May '11

23 May '11

Alexandre, Damjan, Eric, I understand your answers mean that a patch is needed to MCI_*_PARMS16 in mmsystem16.h to turn all occurrences of LPSTR into SEGPTR. E.g. MCI_LOAD_PARMS16, MCI_DGV_INFO_PARMS16, MCI_DGV_OPEN_PARMS16 ... I suppose "DWORD dwCallback;" is ok to copy 1:1 (what the code currently does) because it contains a window handle, not pointer. It would be wrong if the 16bit SDK contained HWND16 wCallback; UINT16 wReserved0; because then Wine might see half garbage and be lucky when wReserved is 0. Regards, Jörg Höhle

1 0

[1/2] mmsystem.dll16: fix MCI_STATUS mapping for digitalvideo
by Joerg-Cyril.Hoehle＠t-systems.com 23 May '11

23 May '11

Damjan, @@ -407,6 +441,20 @@ static MMSYSTEM_MapType MCI_UnMapMsg16To32W(WORD wMsg, DWORD dwFlags, DWORD_PTR + mdsp16->dwCallback = mdsp32w->dwCallback; + mdsp16->dwItem = mdsp32w->dwItem; + mdsp16->dwTrack = mdsp32w->dwTrack; This is superfluous. dwReturn is the only documented output. This was different with your former MCI_WHERE patch, where a RECT is output. I'd try hard not to turn one message call (Status) into 2 (GetDevCaps + Status). I've seen logs of apps that continuously poll MCI_STATUS_POSITION. Instead, I'd continue the path lead by winmm/mci.c:MCI_MapMsgAtoW: Allocate the largest structure and fill it depending on dwFlags, e.g.: case MCI_OPEN: { /* MCI_ANIM_OPEN_PARMS is the largest known MCI_OPEN_PARMS * structure, larger than MCI_WAVE_OPEN_PARMS */ BTW, I've a note that MCI_INFO needs similar treatment, but never wrote the patch... Select the right set of flags to fill the slots, otherwise fallback to defaults like: /* We don't know how many DWORD follow, as * the structure depends on the device. */ if (HIWORD(dwParam1)) memcpy(&mci_openW->dwStyle, &mci_openA->dwStyle, sizeof(MCI_ANIM_OPEN_PARMSW) - sizeof(MCI_OPEN_PARMSW)); Of course, one may argue that this is a heuristic and can fail. Well, GetDevCaps is a heuristic as well that only supports devtype_digital_video. An advantage IMHO of the existing approach is that it does not invent within the same source code base yet another mechanism to map 16 to 32 or A to W. I'd rather follow the existing model until the time it proves unbearable, or immediately switch the *whole* code base to another model, not the single MCI_STATUS function. For instance, you can argue that it makes sense for winmm to cache the device type (winmm:MCI_Open has it in several cases). It would arguably also make sense to cache the MCI auto_open'ed property, but I digress. Your MCI_get_device_type is bogus. MCI_GETDEVCAPS_DEVICE_TYPE belongs into dwItem, not dwFlags. Regards, Jörg Höhle

3 6

Request for comments: d3dX : wined3d implicit enum conversion warnings and resolution
by Frédéric Delanoy 23 May '11

23 May '11

Hi guys, while trying to compile wine with clang, I get a whole bunch of "implicit conversion from enumeration type FOO to different enumeration type WINED3DFOO" (and conversely) warnings when an enum value of type A is assigned to a var of enum type B. In order to tackle those, instead of using (probably ugly) casts everywhere, I put them in a "static inline" function in d3dX_private.h (conv functions put in the header so inlining is possible everywhere, so a potential performance impact is limited) Originally, I intended to issue a FIXME("Unhandled/unrecognized value...") in the default: clause of a switch statement to catch values not in in the original enum's domain, but I couldn't find a way to make FIXMEs work in a .h file 'cos of a macro expansion hell I'm not quite sure however what the best solution is wrt performance, so I'd like your comments on this Some explanations: *D3DPOOL and WINED3DPOOL have a full 1-1 mapping, so the conv functions simply do a cast. *D3DRESOURCETYPE and WINED3DRESOURCETYPE have *not* a 1-1 mapping, and I present here 3 possible solution types: D3DRESOURCETYPE => D3DRTYPE_SURFACE = 1, D3DRTYPE_VOLUME = 2, D3DRTYPE_TEXTURE = 3, D3DRTYPE_VOLUMETEXTURE = 4, D3DRTYPE_CUBETEXTURE = 5, D3DRTYPE_VERTEXBUFFER = 6, D3DRTYPE_INDEXBUFFER = 7, D3DRTYPE_FORCE_DWORD = 0x7fffffff WINED3DRESOURCETYPE => WINED3DRTYPE_SURFACE = 1, WINED3DRTYPE_VOLUME = 2, WINED3DRTYPE_TEXTURE = 3, WINED3DRTYPE_VOLUMETEXTURE = 4, WINED3DRTYPE_CUBETEXTURE = 5, WINED3DRTYPE_BUFFER = 6, WINED3DRTYPE_FORCE_DWORD = 0x7fffffff Type 1 --------- Identical semantics to direct assigment All cases specified, even "obvious" ones (D3D_FOO <-> WINED3D_FOO), using same enum value; non mapped values use the default: clause (e.g. D3DRTYPE_INDEXBUFFER=7; no 7 enum val in WINED3DRESOURCETYPE) Default clause: only used for values not in original enum Type 2 --------- Same as v1 except obvious values aren't specified in a case: Non directly obvious values (same enum val) can still be "highlighted" (e.g. WINED3DRTYPE_BUFFER=6 ==> D3DRTYPE_VERTEXBUFFER=6) Default clause: used for values not in original enum AND obvious values Maybe more optimal than "type 1", but isn't that a micro/premature optimisation? Type 3 --------- Potentially more risky/invasive: conversion does not simply return value "as-is" Semantics *changes* from direct assigment; some additional code changes are necessary; could help centralise, though e.g. D3DRTYPE_VERTEXBUFFER=6 => WINED3DRTYPE_BUFFER=6 D3DRTYPE_INDEXBUFFER=7 => WINED3DRTYPE_BUFFER=6 Adapted code (directx.c): - switch(RType) { - case D3DRTYPE_VERTEXBUFFER: - case D3DRTYPE_INDEXBUFFER: - WineD3DRType = WINED3DRTYPE_BUFFER; - break; - - default: - WineD3DRType = RType; - break; - } + WineD3DRType = wined3dresourcetype_from_d3dresourcetype(RType); What do you think would be best? Frédéric

1 0

Re: ddraw: Don't interpret end padding as dwCaps2 for x64.
by Alexandre Julliard 23 May '11

23 May '11

Dylan Smith <dylan.ah.smith(a)gmail.com> writes: > @@ -3123,6 +3123,8 @@ static HRESULT CreateSurface(IDirectDrawImpl *ddraw, DDSURFACEDESC2 *DDSD, > memset(&desc2, 0, sizeof(desc2)); > desc2.dwSize = sizeof(desc2); /* For the struct copy */ > DD_STRUCT_COPY_BYSIZE(&desc2, DDSD); > + if (DDSD->dwSize == sizeof(DDSURFACEDESC)) > + CLEAR_STRUCT_END_PADDING((DDSURFACEDESC*)&desc2, ddsCaps); I'd suggest to rethink the whole thing. We don't really need to set the same structure fields 4 times. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: urlmon: Fix incorrect pointer arithmetic (too conversative) in map_url_to_zone.
by Nikolay Sivov 23 May '11

23 May '11

On Sun, May 22, 2011 at 10:53 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > The difference between two pointers (of the same type) is the number > of elements, not the number of bytes. That's why it was divided by element size to get 'number of elements'. What's a problem? > Thus the code below was way > incorrect, luckily only too conversative. > > Gerald > > --- > dlls/urlmon/sec_mgr.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/urlmon/sec_mgr.c b/dlls/urlmon/sec_mgr.c > index 7b4bb35..75850ee 100644 > --- a/dlls/urlmon/sec_mgr.c > +++ b/dlls/urlmon/sec_mgr.c > @@ -529,7 +529,7 @@ static HRESULT map_url_to_zone(LPCWSTR url, DWORD *zone, LPWSTR *ret_url) > hres = CoInternetParseUrl(secur_url, PARSE_PATH_FROM_URL, 0, path, > sizeof(path)/sizeof(WCHAR), &size, 0); > > - if(SUCCEEDED(hres) && (ptr = strchrW(path, '\\')) && ptr-path < sizeof(root)/sizeof(WCHAR)) { > + if(SUCCEEDED(hres) && (ptr = strchrW(path, '\\')) && ptr-path < sizeof(root)) { > UINT type; > > memcpy(root, path, (ptr-path)*sizeof(WCHAR)); > -- > 1.7.4.1 > > >

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
23
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel May 2011