July 2008 - Wine-Devel - list.winehq.org

re: gdi32: Implement automatic font substitution
by Dan Kegel July 3, 2008

July 3, 2008

Liu Qishuai wrote: > This patch appends all fonts on child_list so that if a character is > not available in the font, other fonts will be automatically used. > This is how Windows does to get a CJK character when a latin font is specified. > > A lot of CJK-related bugs will be fixed after applying this patch. Excellent! In case AJ hesitates to apply this patch: Can you write a conformance test that verifies this behavior? Also, can you identify a bug in bugzilla this will fix? - Dan

4 13

Re: msxml3/test: Added test file for ISAXXMLReader (6/6)
by Alistair Leslie-Hughes July 3, 2008

July 3, 2008

"Piotr Caban" <piotr.caban(a)gmail.com> wrote in message news:200807022156.01609.piotr.caban(a)gmail.com... > --- > dlls/msxml3/tests/Makefile.in | 3 +- > dlls/msxml3/tests/saxreader.c | 225 > +++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 227 insertions(+), 1 deletions(-) > create mode 100644 dlls/msxml3/tests/saxreader.c > What about checking for invalid arguments as well? Best Regards Alistair Leslie-Hughes

2 1

EnterCriticalSection throws exception?
by Huang, Zhangrong July 3, 2008

July 3, 2008

Hi, According to MSDN http://msdn.microsoft.com/en-us/library/ms682608(VS.85).aspx: EnterCriticalSection can raise EXCEPTION_POSSIBLE_DEADLOCK if a wait operation on the critical section times out. The timeout interval is specified by the following registry value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\CriticalSectionTimeout. Currently, WIne doesn't implement this timeout feature, instead wine throws exception only for Wine internal locks after waiting for about 65 seconds, it is useful to check deadlock, see RtlpWaitForCriticalSection in dlls/ntdll/critsection.c But this means a thread can't hold critical section longer than 65 seconds, otherwise app will crash. On some conditions, a thread does need hold critical section more than 65 seconds, for example: wine's implementation of GetAddress uses a critical section to protect non-reentrant gethostbyname() (well maybe need another gethostbyname_r() patch), see dlls/wininet/utility.c As you can see, gethostbyname() may take longtime when DNS setting is wrong or network is broken. If a multi-thread app calls GetAddress simultaneous in many threads, the app will crash. I meet this problem when my network was broken, my app kept crash: fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT err:ntdll:RtlpWaitForCriticalSection section 0x7e44fa80 "utility.c: cs_gethostbyname" wait timed out in thread 0037, blocked by 003b, retrying (60 sec) fixme:msxml:DllCanUnloadNow wine: Critical section 7e44fa80 wait failed at address 0x7bc3c5bc (thread 0039), starting debugger... WineDbg starting on pid 0008 Unhandled exception: wait failed on critical section 0x7e44fa80 cs_gethostbyname err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr 0x7bc3c5bc So I suggest a feature that EnterCriticalSection throws exception for Wine internal locks only when debug is present. Add the following code dlls/ntdll/critsection.c: NTSTATUS WINAPI RtlpWaitForCriticalSection( RTL_CRITICAL_SECTION *crit ) { ........................... /* Throw exception only for Wine internal locks and debug is present */ if ((!crit->DebugInfo) || (!crit->DebugInfo->Spare[0])) continue; else if (!NtCurrentTeb()->Peb->BeingDebugged) continue; ^^^^^^^^^^^^^^^^^^ add ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ rec.ExceptionCode = STATUS_POSSIBLE_DEADLOCK; ............................ } Any suggestion? Sorry If I'm not clean or missing something, thanks. -- $ apt-get moo (__) (oo) /------\/ / | || * /\---/\ ~~ ~~ ...."Have you mooed today?"...

8 14

Re: richedit: Store richedit version rather than boolean bEmulateVersion10 value
by Juan Lang July 3, 2008

July 3, 2008

Hi Dylan, - if (!editor->bEmulateVersion10 || (editor->nEventMask & ENM_UPDATE)) + if (!editor->dwEmulatedVersion || (editor->nEventMask & ENM_UPDATE)) This change is incorrect, as dwEmulatedVersion is never set to 0. I believe you mean if (editor->dwEmulatedVersion > 0x100 || ... I have to ask, though: what bug does this fix? --Juan

2 1

Re: wined3d: Fix a deadlock that may occur during initialization
by H. Verbeet July 3, 2008

July 3, 2008

2008/7/3 Maarten Lankhorst <m.b.lankhorst(a)gmail.com>: > - * Copyright 2007-2008 Stefan Dösinger for CodeWeavers > + * Copyright 2007-2008 Stefan Dï¿½singer for CodeWeavers You shouldn't be changing Stefan's name though.

2 1

Thoughts on implementation of winhttp.dll
by Zac Brown July 3, 2008

July 3, 2008

Hi, I've been looking at implementing winhttp.dll. Does anyone have thoughts on implementing parts of winhttp in terms of wininet? The primary issue that prevents entirely implementing winhttp in terms of wininet is that there is no direct Win32 API for fetching an SSL certificate in winhttp. To access these, I'd need access to functions defined in wininet/netconnection.c but aren't exported. My current two ideas are to either: 1) Copy the networking sublayer from wininet into winhttp and build on top of that to implement winhttp. Effectively reimplementing mostly from scratch. 2) Implement most winhttp things in terms of wininet and then copying over parts that I need from wininet's network sublayer, like fetching SSL certificates and so on. Thoughts on this are greatly appreciated, as I'd prefer to only have to write the library once. -Zac

3 5

Unable to make crosstest for mlang/tests
by Vitaly Perov July 3, 2008

July 3, 2008

"make" command works, but when I try "make crosstest" the following message appears: mlang.cross.o: In function `func_mlang': /home/vitperov/Projects/wine/dlls/mlang/tests/mlang.c:831: undefined reference to `_IID_IMultiLanguage2' /home/vitperov/Projects/wine/dlls/mlang/tests/mlang.c:864: undefined reference to `_IID_IMLangFontLink' I've solved this problem by inserting: const GUID IID_IMLangFontLink_n DECLSPEC_HIDDEN; const GUID IID_IMLangFontLink_n = { 0x359f3441, 0xbd4a, 0x11d0, { 0xb1, 0x88, 0x00, 0xaa, 0x00, 0x38, 0xc9, 0x69 } }; const GUID IID_IMultiLanguage2_n DECLSPEC_HIDDEN; const GUID IID_IMultiLanguage2_n = { 0xdccfc164, 0x2b38, 0x11d2, { 0xb7, 0xec, 0x00, 0xc0, 0x4f,0x8f,0x5d,0x9a } }; and then use &IID_IMultiLanguage2_n instead of &IID_IMultiLanguage2. But it is not good decision! Does anybody know the correct way to fix these tests? -- Best wishes, Vitaly Perov Russia, Saint-Petersburg. www.etersoft.ru

3 3

Get Windows-PID for process with known Unix-PID
by Martin Szydlowski July 3, 2008

July 3, 2008

Hi all, I am starting and stopping some Windows (and also Unix) programs from a shell script. To start, I use fork/exec which gives me the Unix PID. To stop the program I use kill. I have experimented with different signals (TERM, HUP, INT, KILL) and all of them achieve the goal of stopping the program, but it does not shut down cleanly (as opposed to using File->Exit or the red X). I have written a small program (winelib) that enumerates all windows and can send as WM_CLOSE message to a program with a certain Windows PID. Since I have several instances of the same executable running, I cannot distinguish them by name or path, hence I save the PID when starting them, but it's the Unix PID I have. I believe there must be a way to get a mapping of Windows-PIDs <-> Unix-PIDs, but extensive googling only revealed (repeatedly) to me that those two must not be confused. I know I can get the Windows-PIDs using winedbg->info process but there is no trace of Unix PIDs there. Also, I need a scriptable way to do this, best being a small app that gets a Unix PID and prints the matching Windows PID to console. greetz Martin

2 1

Re: Sorry, resend, with patch now. [try 3] gdi32/tests: Add tests for GdiGetCodePage.
by Alexandre Julliard July 3, 2008

July 3, 2008

"Huang, Zhangrong" <hzhrong(a)gmail.com> writes: > This pacth add tests for GdiGetCodePage, which currently don't pass on WIne. > > ChangeLog > gdi32/tests: Add tests for GdiGetCodePage. It doesn't work here: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so font.c && touch font.ok font.c:833: Test succeeded inside todo block: data index 2: GdiGetCodePage should have returned 1252, got 1252 font.c:833: Test succeeded inside todo block: data index 3: GdiGetCodePage should have returned 1252, got 1252 font.c:830: Test failed: data index 14: expected font codepage 42, got 1252 font.c:833: Test succeeded inside todo block: data index 15: GdiGetCodePage should have returned 1253, got 1253 font.c:833: Test succeeded inside todo block: data index 16: GdiGetCodePage should have returned 1251, got 1251 font.c:830: Test failed: data index 17: expected font codepage 936, got 1252 font.c:1559: Tests skipped: Symbol or Wingdings is not installed font.c:1575: Tests skipped: Symbol or Wingdings is not installed font.c:1729: Tests skipped: Symbol is not installed font.c:2507: Tests skipped: Arial Black or Symbol/Wingdings is not installed font.c:1955: Tests skipped: Font DejaVu Sans doesn't contain 'x', skipping the test font.c:1955: Tests skipped: Font DejaVu Sans Condensed doesn't contain 'x', skipping the test font.c:1955: Tests skipped: Font OpenSymbol doesn't contain 'x', skipping the test make[2]: *** [font.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] wininet: moved cookie loading from HttpOpenRequest() to HttpSendRequest()
by Hans Leidekker July 3, 2008

July 3, 2008

On Wednesday 02 July 2008 19:27:43 Yann Droneaud wrote: > This patch does the following: > > - Move cookie retrieval code to HTTP_HttpSendRequest() > - Don't allocate memory for url if INTERNET_FLAG_NO_COOKIES is enabled > - Be sure to not overflow lpszCookies: > buffer size was nCookieSize + 1 + 8, > written size is 8 + (nCookieSize - 1) + 2 + 1 > - Optimized request header generation: > sprintfW() replaced by strcpyW() > strcatW() replaced by strcpyW() > removed call to strlenW() for HTTP_HttpAddRequestHeadersW() > - Use HTTP_ADDREQ_FLAG_ADD instead of HTTP_ADDHDR_FLAG_ADD > - Use HTTP_ADDREQ_FLAG_REPLACE to replace the cookie instead of adding Thanks Yann, good to see you move on to fix more bugs. To be accepted in git each of those items should be a separate patch though, and the impact of moving the cookie code is such that it needs a test case. -Hans

2 2