April 2012 - Wine-devel - list.winehq.org

Re: [2/2] advapi32: Do not terminate a regular program if it calls StartServiceCtrlDispatcher.
by Alexandre Julliard 04 Apr '12

04 Apr '12

Alexander Morozov <amorozov(a)etersoft.ru> writes: > This patch partially fixes #30290. > > Pipe is renamed to spipe (service pipe) to prevent compilation error: > service.c:88:15: error: ‘pipe’ redeclared as different kind of symbol > /usr/include/unistd.h:414:12: note: previous declaration of ‘pipe’ was > here You shouldn't need to add global variables, just pass the handle to the thread. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msi: fixed MsiGetFileHashW for empty files (try 2)
by Alexandre Julliard 04 Apr '12

04 Apr '12

Robert van Herk <mijnspamboxje(a)hotmail.com> writes: > @@ -493,6 +493,45 @@ static void test_MsiGetFileHash(void) > } > } > > +static void test_MsiGetFileHashForEmptyFile(void) { > + char path[MAX_PATH]; > + MSIFILEHASHINFO hi; > + char file[MAX_PATH]; > + UINT res; > + > + /* Create empty temp file */ > + GetTempPath( > + MAX_PATH, > + path > + ); You should add that to the existing MsiGetFileHash tests, there's no need for a separate function. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] ntdll: Fix section header heap deadlock.
by Alexandre Julliard 04 Apr '12

04 Apr '12

"Erich E. Hoover" <ehoover(a)mines.edu> writes: > Real Name: > Erich Hoover > > Description: > Using the process heap for the section headers can cause a > deadlock (Bug #30356), this patch uses the virtual heap instead. I don't think we want to use the virtual heap for that sort of thing, it should be used only for memory views. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/3] wininet: Don't delete locked entry in DeleteUrlCacheEntry
by Alexandre Julliard 04 Apr '12

04 Apr '12

Piotr Caban <piotr(a)codeweavers.com> writes: > --- > dlls/wininet/urlcache.c | 9 +++++++++ > 1 files changed, 9 insertions(+), 0 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so urlcache.c && touch urlcache.ok urlcache.c:557: Test succeeded inside todo block: Expected failure urlcache.c:559: Test succeeded inside todo block: Expected ERROR_SHARING_VIOLATION, got 32 urlcache.c:568: Test succeeded inside todo block: UnlockUrlCacheEntryFileA failed: 0 urlcache.c:581: Test failed: Expected failure urlcache.c:582: Test failed: expected ERROR_FILE_NOT_FOUND, got 0 make: *** [urlcache.ok] Error 5 -- Alexandre Julliard julliard(a)winehq.org

1 0

Tools under the <>tools/winapi directory
by Roger Cruz 03 Apr '12

03 Apr '12

How are the tools under the winapi directory used? I've tried running them but they all complain about the same error. ~/sandbox/wine/sources/wine-1.3.36/dlls/kernel32$ ~/sandbox/wine/sources/wine-1.3.36/tools/winapi/winapi_extract winapi_extract: You must run this tool in the main Wine directory or a sub directory

2 1

OT: Looking for (paid) help with Wine development.
by Roger Cruz 03 Apr '12

03 Apr '12

Hello fellow Wine developers, I am looking for paid programming help to help me finish a proof of concept application that utilizes Wine. This is a short-term contract project with terms negotiated based on your experience and ability to finish tasks in a timely manner. The right person should have the following skills 1) Has worked extensively with Wine in the past. Being a contributor to Wine is a plus but not a requirement. However, you must know the internals of Wine and be able to cross-compile for other platforms. Knowledge of shared libraries and linking is a huge plus. 2) Have extensive programming experience in Windows and know its compilers and intricacies. 3) Must have a great understanding of calling conventions in Windows and Linux environments. In particular, you need to know where compilers place arguments to a function and how to extract them from the stack and registers. 4) Must know how to use debuggers effectively, as well as the internals of how a compiler keeps its debug information. DWARF knowledge is a huge plus. 5) Must be an expert in C and have good knowledge in C++. Other languages are desireable. 6) Having internal knowledge of QEMU, specially in the TCG area, is a huge plus as well. 7) SDL, OpenGL and graphics knowledge is a plus. You must not be precluded by any current employment from working on this side project. There should not be any conflict of interest that would taint your work. You will be required to sign a non-disclosure and non-compete agreement before proceeding. If this is something that interests you, please email me privately at roger_r_cruz AT yahoo dot com Warm Regards Roger R. Cruz

1 0

Re: gdiplus: GdipDrawString is not supposed to use the layout rectangle for clipping. Take 2.
by Vincent Povirk 03 Apr '12

03 Apr '12

I tried making a testcase for this, and I'm consistently seeing that native only draws text that lies inside the rectangle if a positive width or height are given. If I specify StringFormatFlagsNoClip then I see a slight difference. Without the flag, the last line of text is clipped at the given height; with the flag, it is fully shown as long as the top of that line lies inside the rectangle. The test cases you linked appear to leave the width and height uninitialized, and they do not specify StringFormatFlagsNoClip. My guess is that they either default to 0 or undefined depending on how the language works. Since we already handle the case where width and height are 0, and an undefined width/height could work or not by coincidence, I don't think your test cases show anything new. Due to the way we (like native) calculate the text layout independent of clipping, so that characters that lie entirely outside the rectangle are not drawn, it's not even clear to me why this patch might have helped. I think this needs more investigation.

2 1

Re: [website] Add Portuguese translation for release 1.5.1
by Bruno Jesus 03 Apr '12

03 Apr '12

2012/4/2 Lucas Fialho Zawacki <lfzawacki(a)gmail.com>: >> + <li>Suporte a fontes redimensionáveis em recursos.</li> A more correct translation for: - Support for scalable font resources. Would be: - Suporte para recursos de fontes escaláveis. Instead of: - Suporte a fontes redimensionáveis em recursos. Maybe "redimensionáveis" instead of "escaláveis" as you first used. Best wishes, Bruno

2 1

Re: [PATCH 3/4] winspool/tests: Add some tests for OpenPrinter with non-NULL defaults.
by Marvin 03 Apr '12

03 Apr '12

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=17661 Your paranoid android. === WINEBUILD (build) === Can't determine base name

2 1

Re: [1/2] kernel32/tests: Add tests for LCMapStringEx
by Alexandre Julliard 03 Apr '12

03 Apr '12

André Hentschel <nerv(a)dawncrow.de> writes: > /* test srclen = 0 */ > SetLastError(0xdeadbeef); > - ret = LCMapStringW(LOCALE_USER_DEFAULT, 0, upper_case, 0, buf, sizeof(buf)/sizeof(WCHAR)); > - ok(!ret, "LCMapStringW should fail with srclen = 0\n"); > + ret = LCMapStringU(0, upper_case, 0, buf, sizeof(buf)/sizeof(WCHAR)); > + ok(!ret, "LCMapStringU should fail with srclen = 0\n"); This is very confusing, there's no such API as LCMapStringU. You should display the correct function being tested in all the error messages, and pick a better name for the function pointer. -- Alexandre Julliard julliard(a)winehq.org

1 0