May 2010 - Wine-devel - list.winehq.org

Re: gdi32: Fix underline and strikeout for clipped to the rectangle text
by Alexandre Julliard 04 May '10

04 May '10

Ilya Shpigor <shpigor(a)etersoft.ru> writes: > There is bug with underline and strikeout font in ExtTextOutW. > > The text is clipped if the ETO_CLIPPED flag have been set and rectangle > smaller then needed for text. But underline and strikeout lines is drawed > same as when text fit in the rectangle. > > The problem screenshot (wine below): > http://bugs.etersoft.ru/attachment.cgi?id=1678 > > I suggest to check if the y coordinate of line is smaller then text rectangle > bottom. That's of course not sufficient for correct clipping. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Valgrind's wine_cp_wcstombs warnings
by Jordan Ayers 04 May '10

04 May '10

> Hi, > > running the MCI tests with Valgrind generates a lot of output like follows > > ==13170== Use of uninitialised value of size 4 > ==13170== at 0x4035369: wine_cp_wcstombs (wctomb.c:147) > ...[every line from 148 to 161] > ==13170== Use of uninitialised value of size 4 > ==13170== at 0x403550A: wine_cp_wcstombs (wctomb.c:162) > > I suspect the A<->W mapping is still not fully correct (I know at > least one more case, but I'm not sure it gets triggered by the tests) > but perhaps it's also the W->UNIX.UTF-8 conversions internal to Wine > which cause these hits. How do I tell? > > Is there any way to get more precise reporting for the above messages > (e.g. a backtrace)? The present output is not helpful at identifying > the origin of the uninitialised read. > > Perhaps Valgrind is broken? Why does it mention "size 4" when all > access in the offending function is either "char *" or "short *" > according to the source > http://source.winehq.org/source/libs/wine/wctomb.c#L145 ? > > Thanks for your help, > Jörg Höhle Joerg, If you're on a 32-bit system, your pointers would be where the 'size 4' is coming from. It looks like Valgrind thinks a pointer being dereferenced isn't initialized. (maybe src?) Jordan Ayers

1 0

Re: [3/3] rundll32: Recognize entry points passed as ordinal numbers. (try 2)
by Alexandre Julliard 04 May '10

04 May '10

Andrew Nguyen <anguyen(a)codeweavers.com> writes: > @@ -119,30 +119,43 @@ static FARPROC16 get_entry_point16( HINSTANCE16 inst, LPCWSTR entry ) > static void *get_entry_point32( HMODULE module, LPCWSTR entry, BOOL *unicode ) > { > void *ret; > - DWORD len = WideCharToMultiByte( CP_ACP, 0, entry, -1, NULL, 0, NULL, NULL ); > - char *entryA = HeapAlloc( GetProcessHeap(), 0, len + 1 ); > - > - if (!entryA) > - return NULL; > > - WideCharToMultiByte( CP_ACP, 0, entry, -1, entryA, len, NULL, NULL ); > + /* determine if the entry point is an ordinal */ > + if (entry[0] == '#') > + { > + int ordinal = atoiW( entry + 1 ); > + if (ordinal <= 0) > + return NULL; You don't set the unicode flag in this case. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wined3d: Fix some complaints in d3d9 texture test
by Henri Verbeet 04 May '10

04 May '10

2010/5/4 Ričardas Barkauskas <miegalius(a)gmail.com>: > Fixes some GL_INVALID_ENUM fixmes in d3d9 texture tests and bug 11167. > Why are you setting GL_GENERATE_MIPMAP_SGIS?

2 1

Re: [PATCH 4/5] d3d9/tests: Allow D3DFMT_A2R10G10B10 as supported adapter mode.
by testbot＠testbot.winehq.org 03 May '10

03 May '10

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=1890 Your paranoid android. === W7PRO (32 bit device) === device.c:2442: Test failed: Expected foreground window 00020142, got 00010040. device.c:2578: Test failed: Expected foreground window 00030142, got 00010040.

1 0

Re: [1/2] dlls/crypt32: implement PFXImportCertStore()
by Juan Lang 03 May '10

03 May '10

Hi Phillippe, this attempt looks pretty incomplete. First off: + ret = pPKCS12_verify_mac(pkcs12, password, len); + if (ret == 0) + ERR_(crypt)("failed to verify pkcs12 {%p} with password \"%s\" using func {%p}\n", pkcs12, password, pPKCS12_verify_mac); + else + TRACE_(crypt)("verified pkcs12 {%p} with password \"%s\" using func {%p}\n", pkcs12, password, pPKCS12_verify_mac); You accept the PKCS12 file even if the password is incorrect. This is clearly wrong. + /* extract private key and certificate */ + ret = pPKCS12_parse(pkcs12, password, &pkey, &cert, NULL); You don't support more than a single certificate in the PKCS12 file. This may be fine for the majority of uses, but at least a warning indicating more certificates are present would be helpful. Also, a PKCS12 file can contain more than just certificates, and the tests ought at least to check this. For example, what about a PKCS12 file with a CRL in it? OpenSSL also supports at least a couple of attributes associated with the certificates. From the man page for PKCS12_parse: The friendlyName and localKeyID attributes (if present) on each certificate will be stored in the alias and keyid attributes of the X509 structure. The Crypto API also supports setting such attributes, and if you aren't going to support these, at least the tests should cover them (and marked todo_wine) so we know they're still not done. More questions: + const WCHAR storeName[] = {'S', 't', 'o', 'r', 'e', ' ', 'N', 'a', 'm', 'e', 0}; + store = CertOpenStore(CERT_STORE_PROV_MEMORY, 0, (HCRYPTPROV)NULL, CERT_STORE_CREATE_NEW_FLAG, storeName); What's the purpose of the store name? Does the native implementation do this? If not, it can be omitted. If so, the tests should check it. Thanks, --Juan

2 5

[PATCH] RegisterWaitForSingleObject() fix special tmo == 0 case.
by Joakim Tjernlund 03 May '10

03 May '10

At http://msdn.microsoft.com/en-us/library/aa332406%28VS.71%29.aspx one can read: "If the timeOutInterval parameter is not zero (0) and the executeOnlyOnce parameter is false, the timer is reset every time the event is signaled or the time-out interval elapses." timeOutInterval == 0 makes the above false and the timer should NOT be reset, fix that. Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund(a)transmode.se> --- Forget the earlier patches, this feels like the right fix. dlls/ntdll/threadpool.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/dlls/ntdll/threadpool.c b/dlls/ntdll/threadpool.c index 44afb01..f6c9fb4 100644 --- a/dlls/ntdll/threadpool.c +++ b/dlls/ntdll/threadpool.c @@ -377,7 +377,8 @@ static DWORD CALLBACK wait_thread_proc(LPVOID Arg) wait_work_item->Callback( wait_work_item->Context, TimerOrWaitFired ); wait_work_item->CallbackInProgress = FALSE; - if (wait_work_item->Flags & WT_EXECUTEONLYONCE) + if (!wait_work_item->Milliseconds || + wait_work_item->Flags & WT_EXECUTEONLYONCE) break; } else -- 1.6.4.4

1 0

Why reserve space below 2G without preloader? wrt. patch 1aa749d & bug 22033
by Johann "Myrkraverk" Oskarsson 03 May '10

03 May '10

Hi all, Out of sheer curiousity, why is it important to reserve space below 2G when there is no preloader? Patch 1aa749d, is libwine: Reserve some low memory space even without a preloader. has the comment: /* if we don't have a preloader, try to reserve some space below 2Gb */ and is the regression for bug 22033. http://bugs.winehq.org/show_bug.cgi?id=22033 I will be trying to determine the excact cause of the bug later. Johann

3 2

Re: [2/5] rundll32: Fail if a rundll32 window cannot be created.
by Alexandre Julliard 03 May '10

03 May '10

Andrew Nguyen <anguyen(a)codeweavers.com> writes: > --- > programs/rundll32/rundll32.c | 16 +++++++++++++--- > 1 files changed, 13 insertions(+), 3 deletions(-) This will prevent initializing the prefix without an X display. Why do you need this? -- Alexandre Julliard julliard(a)winehq.org

2 1

Valgrind's wine_cp_wcstombs warnings
by Joerg-Cyril.Hoehle＠t-systems.com 03 May '10

03 May '10

Hi, running the MCI tests with Valgrind generates a lot of output like follows ==13170== Use of uninitialised value of size 4 ==13170== at 0x4035369: wine_cp_wcstombs (wctomb.c:147) ...[every line from 148 to 161] ==13170== Use of uninitialised value of size 4 ==13170== at 0x403550A: wine_cp_wcstombs (wctomb.c:162) I suspect the A<->W mapping is still not fully correct (I know at least one more case, but I'm not sure it gets triggered by the tests) but perhaps it's also the W->UNIX.UTF-8 conversions internal to Wine which cause these hits. How do I tell? Is there any way to get more precise reporting for the above messages (e.g. a backtrace)? The present output is not helpful at identifying the origin of the uninitialised read. Perhaps Valgrind is broken? Why does it mention "size 4" when all access in the offending function is either "char *" or "short *" according to the source http://source.winehq.org/source/libs/wine/wctomb.c#L145 ? Thanks for your help, Jörg Höhle

1 0