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

Re: kernel32/tests/debugger: remove win9x hacks
by Dmitry Timoshkov July 27, 2011

July 27, 2011

Austin English <austinenglish(a)gmail.com> wrote: > - if (disposition == REG_CREATED_NEW_KEY) > - win_skip("'dbg,event,order' test doesn't finish on Win9x/WinMe\n"); > - else > - crash_and_debug(hkey, test_exe, "dbg,event,order"); > + crash_and_debug(hkey, test_exe, "dbg,event,order"); You should check 'disposition' instead of removing it altogether. -- Dmitry.

1 0

Re: kernel32/tests/atom: remove win9x hacks
by Dmitry Timoshkov July 27, 2011

July 27, 2011

Austin English <austinenglish(a)gmail.com> wrote: > len = GlobalGetAtomNameA( (ATOM)i, buf, 2); > - if (!len) /* the NT way */ > - { > - ok(GetLastError() == (i ? ERROR_MORE_DATA : ERROR_INVALID_PARAMETER) || > - GetLastError() == 0xdeadbeef, /* the Win 9x way */ > - "wrong error conditions %u for %u\n", GetLastError(), i); > - } > - else /* the Win 9x way */ > - { > - ok(GetLastError() == 0xdeadbeef, > - "wrong error conditions %u for %u\n", GetLastError(), i); > - } > + ok(GetLastError() == ERROR_MORE_DATA || GetLastError() == ERROR_INVALID_PARAMETER, > + "wrong error conditions %u for %u\n", GetLastError(), i); > } You should add an ok(!len) check here. > len = GlobalGetAtomNameA(atom, out, 10); > - if (!len) /* the NT way */ > - { > - ok(GetLastError() == ERROR_MORE_DATA, "wrong error code (%u instead of %u)\n", GetLastError(), ERROR_MORE_DATA); > - } > - else /* the Win9x way */ > - { > - ok(GetLastError() == 0xdeadbeef, "wrong error code (%u instead of %u)\n", GetLastError(), 0xdeadbeef); > - } > + ok(GetLastError() == ERROR_MORE_DATA, "wrong error code (%u instead of %u)\n", GetLastError(), ERROR_MORE_DATA); And here. -- Dmitry.

1 0

Re: gdi32/tests/mapping: remove win9x hacks
by Dmitry Timoshkov July 27, 2011

July 27, 2011

Austin English <austinenglish(a)gmail.com> wrote: > - if (is_win9x) > - { > - expect_viewport_ext(hdc, dpi_x, dpi_y); > - expect_window_ext(hdc, 254, -254); > - } > - else > - { > - expect_viewport_ext(hdc, res_x, -res_y); > - ok( GetWindowExtEx( hdc, &size ), "GetWindowExtEx failed\n" ); > - ok( rough_match( size.cx, size_cx * 10 ) || > - rough_match( size.cx, MulDiv( res_x, 254, dpi_x )), /* Vista uses a more precise method */ > - "expected cx %d or %d, got %d\n", size_cx * 10, MulDiv( res_x, 254, dpi_x ), size.cx ); > - ok( rough_match( size.cy, size_cy * 10 ) || > - rough_match( size.cy, MulDiv( res_y, 254, dpi_y )), /* Vista uses a more precise method */ > - "expected cy %d or %d, got %d\n", size_cy * 10, MulDiv( res_y, 254, dpi_y ), size.cy ); > - } > + ok( GetWindowExtEx( hdc, &size ), "GetWindowExtEx failed\n" ); > + ok( rough_match( size.cx, size_cx * 10 ) || > + rough_match( size.cx, MulDiv( res_x, 254, dpi_x )), /* Vista uses a more precise method */ > + "expected cx %d or %d, got %d\n", size_cx * 10, MulDiv( res_x, 254, dpi_x ), size.cx ); > + ok( rough_match( size.cy, size_cy * 10 ) || > + rough_match( size.cy, MulDiv( res_y, 254, dpi_y )), /* Vista uses a more precise method */ > + "expected cy %d or %d, got %d\n", size_cy * 10, MulDiv( res_y, 254, dpi_y ), size.cy ); > expect_world_transform(hdc, 1.0, 1.0); > expect_LPtoDP(hdc, MulDiv(1000 / 10, res_x, size_cx), -MulDiv(1000 / 10, res_y, size_cy)); You've lost 'expect_viewport_ext(hdc, res_x, -res_y);' from the 'else' block. -- Dmitry.

1 0

Re: kernel32/tests/sync: remove win9x hacks
by Marvin July 27, 2011

July 27, 2011

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=12916 Your paranoid android. === W7PRO (32 bit sync) === sync.c:849: Test failed: ChangeTimerQueueTimer

1 0

Re: [3/3] ddraw/tests: Add a couple of fog tests.
by Marvin July 26, 2011

July 26, 2011

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=12866 Your paranoid android. === WINEBUILD (build) === Make failed

2 1

Re: [3/3] d3d9/tests: Add a couple of fog tests.
by Marvin July 26, 2011

July 26, 2011

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=12862 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: comctl32: Remove dead increments (clang)
by Marcus Meissner July 26, 2011

July 26, 2011

On Tue, Jul 26, 2011 at 09:15:57PM +0200, André Hentschel wrote: > --- > dlls/comctl32/propsheet.c | 1 - > dlls/comctl32/rebar.c | 2 -- > 2 files changed, 0 insertions(+), 3 deletions(-) > > diff --git a/dlls/comctl32/propsheet.c b/dlls/comctl32/propsheet.c > index f711399..3dd0713 100644 > --- a/dlls/comctl32/propsheet.c > +++ b/dlls/comctl32/propsheet.c > @@ -543,7 +543,6 @@ static BOOL PROPSHEET_CollectPageInfo(LPCPROPSHEETPAGEW lppsp, > /* Extract the caption */ > psInfo->proppage[index].pszText = p; > TRACE("Tab %d %s\n",index,debugstr_w( p )); > - p += lstrlenW( p ) + 1; > > if (dwFlags & PSP_USETITLE) > { > diff --git a/dlls/comctl32/rebar.c b/dlls/comctl32/rebar.c > index 99bde77..8d4e6f3 100644 > --- a/dlls/comctl32/rebar.c > +++ b/dlls/comctl32/rebar.c > @@ -1576,8 +1576,6 @@ REBAR_SizeToHeight(REBAR_INFO *infoPtr, int height) > iRow++; > } > } > - else > - extra -= REBAR_SizeChildrenToHeight(infoPtr, first_visible(infoPtr), infoPtr->uNumBands, extra / infoPtr->uNumRows, &fChanged); > > if (fChanged) > REBAR_Layout(infoPtr); REBAR_SizeChildrenToHeight might set fChanged here, or? Ciao, Marcus

1 0

Re: comctl32: Remove dead increments (clang)
by Reece Dunn July 26, 2011

July 26, 2011

2011/7/26 André Hentschel <nerv(a)dawncrow.de>: > --- a/dlls/comctl32/rebar.c > +++ b/dlls/comctl32/rebar.c > @@ -1576,8 +1576,6 @@ REBAR_SizeToHeight(REBAR_INFO *infoPtr, int height) > iRow++; > } > } > - else > - extra -= REBAR_SizeChildrenToHeight(infoPtr, first_visible(infoPtr), infoPtr->uNumBands, extra / infoPtr->uNumRows, &fChanged); IIUC, this should not remove the |REBAR_SizeChildrenToHeight| call, only the |extra -=| bit as |REBAR_SizeChildrenToHeight| is updating the |infoPtr| output parameter. - Reece

1 0

d3d8/tests: make sure to use return values (LLVM/Clang)
by Austin English July 26, 2011

July 26, 2011

-- -Austin

4 8

Re: richedit: Implement WB_DELIMITER and remove todo_wine's in tests.
by Paul Vriens July 26, 2011

July 26, 2011

On 07/26/2011 03:36 AM, James McKenzie wrote: > if (wbuf[0] == 0x20 || wbuf[0] == 0xf020) > - todo_wine > - ok(result == delimiter_tests[i].isdelimiter, > - "wanted ISDELIMITER_W(0x%x) %d, got %d\n", > - delimiter_tests[i].c, delimiter_tests[i].isdelimiter,result); > + ok(result == delimiter_tests[i].isdelimiter, > + "wanted ISDELIMITER_W(0x%x) %d, got %d\n", > + delimiter_tests[i].c, delimiter_tests[i].isdelimiter,result); > else > ok(result == delimiter_tests[i].isdelimiter, > "wanted ISDELIMITER_W(0x%x) %d, got %d\n", > @@ -7122,10 +7121,9 @@ static void test_EM_FINDWORDBREAK_A(void) > SendMessageW(hwndRichEdit, WM_SETTEXT, 0, (LPARAM)buf); > result = SendMessage(hwndRichEdit, EM_FINDWORDBREAK, WB_ISDELIMITER, 0); > if (buf[0] == 0x20) > - todo_wine > - ok(result == delimiter_tests[i].isdelimiter, > - "wanted ISDELIMITER_A(0x%x) %d, got %d\n", > - delimiter_tests[i].c, delimiter_tests[i].isdelimiter,result); > + ok(result == delimiter_tests[i].isdelimiter, > + "wanted ISDELIMITER_A(0x%x) %d, got %d\n", > + delimiter_tests[i].c, delimiter_tests[i].isdelimiter,result); > else Hi James, I think that the if/else was introduced to accommodate the todo_wine(). I guess you can remove more lines as the 'if' now contains the same code as the 'else'. -- Cheers, Paul.

1 0

Re: [8/9] winhttp: Implement IWinHttpRequest::SetRequestHeader.
by Marvin July 26, 2011

July 26, 2011

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=12827 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [7/9] winhttp: Implement IWinHttpRequest::GetResponseHeader.
by Marvin July 26, 2011

July 26, 2011

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=12826 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [6/9] winhttp: Add some parameter checks.
by Marvin July 26, 2011

July 26, 2011

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=12824 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [1/9] winhttp: Implement IWinHttpRequest::SetProxy.
by Marvin July 26, 2011

July 26, 2011

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=12823 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: msvcrt/tests: remove unused assignments (LLVM/Clang)
by Frédéric Delanoy July 26, 2011

July 26, 2011

On Tue, Jul 26, 2011 at 03:48, Austin English <austinenglish(a)gmail.com> wrote: > -- > -Austin Already sent similar patches. Not sure AJ likes those.

2 1

Re: cmd: mkdir should complain if directory already exists (try 2)
by Frédéric Delanoy July 26, 2011

July 26, 2011

On Tue, Jul 26, 2011 at 07:39, Dan Kegel <dank(a)kegel.com> wrote: > Changes since last try: > - fix remaining todo_wine's > - add one more testcase for invalid paths (one that doesn't trigger > help message) > - simplified create_full_path > - avoid generating error message in race case where somebody else > creates an intermediate directory first Maybe a bit nitpickings, but echo mkdir foo slash star errorlevel %ErrorLevel% could be more readable with echo mkdir foo/* errorlevel %ErrorLevel% / and * are not to be escaped, so don't mind expanding them "litteraly" Frédéric

1 0

Re: [PATCH 3/4] ntdll: implement the NamedPipeConfiguration value for the FilePipeLocalInformation class of NtQueryInformati
by Marvin July 26, 2011

July 26, 2011

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=12805 Your paranoid android. === W7PROX64 (64 bit pipe) === No test summary line found

1 0

Re: [PATCH 2/4] kernel32, ntdll, server: implement permission checks for named pipes
by Marvin July 26, 2011

July 26, 2011

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=12804 Your paranoid android. === W7PROX64 (64 bit pipe) === No test summary line found

1 0

Re: [PATCH 1/4] server, ntdll: get rid of the blocking parameter for ioctls. blockingness depends on the overlapped flag for
by Marvin July 26, 2011

July 26, 2011

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=12803 Your paranoid android. === W7PROX64 (64 bit pipe) === No test summary line found

1 0

Questions on WINE releases and stability
by louis＠museresearch.com July 26, 2011

July 26, 2011

Hi, I am a developer for a product which makes heavy use of WINE. Right now, we're deciding which newer version of WINE to go to, and I thought the wine-devel community might have some insight. I did read the WineReleaseCriteria entry on the wiki, but still have some questions. If anyone could answer some things that I've been wondering about, it would go a long way towards helping us make an informed decision. So, here goes: - Does the development branch of WINE go through a battery of tests before it is posted? What kind of criteria has to be met before a development release is made available on the main page? - It's my understanding that the stable branch only has select features and patches ported over (from the wiki: "..with only minimal changes merged in"). Would this mean that if I compared a stable release with a development release from around the same time that the two releases would have significant differences? Specifically, I'm wondering about 1.2.3 vs. 1.3.15. - Is 64-bit support in version 1.2.3 generally usable and stable, or is the current development release a lot more mature in that respect? Your expertise would be appreciated! Louis

4 3

Re: comdlg32/tests: make sure to use a return value (LLVM/Clang)
by Marvin July 25, 2011

July 25, 2011

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=12798 Your paranoid android. === W7PROX64 (32 bit itemdlg) === itemdlg: unhandled exception c0000005 at 75B94C19

1 0

I need someone to present at the Desktop summit in my steed (Berlin)
by Scott Ritchie July 25, 2011

July 25, 2011

External events are preventing me from leaving the country these next few weeks, and I'll be missing the Desktop Summit in Berlin on Monday, Aug 8th. This is the venue to talk to our friends responsible for Freedesktop.org, Gnome, KDE, Unity, and others. https://www.desktopsummit.org/program https://www.desktopsummit.org/venue The stated topic is "Making Wine less broken", although this can be more constructively phrased as "What Wine needs from the Desktop". Many of the recent problems with the Wine user experience have come from desktop environments breaking some of their historical "windows-like way" of doing things while not considering the Wine case: this conference presents us with an opportunity to engage and have Wine handled properly. Any volunteers? I'd be more than willing to talk with you personally and adapt the presentation however you like. Also if you have any particular content that you'd like to make sure gets said, post it in this thread as well :) Thanks, Scott Ritchie

1 0

Re: [PATCH] mmdevapi: Try loading multiple audio drivers from the registry
by Octavian Voicu July 25, 2011

July 25, 2011

On Tue, Jul 26, 2011 at 12:46 AM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: + for(p = driver_name; p; p = next + 1){ + next = strchrW(p, ','); + if(next) + *next = '\0'; + + if(load_driver(p)) + return TRUE; + + TRACE("Failed to load driver: %s\n", wine_dbgstr_w(driver_name)); + } This crashes if no driver can be loaded (next will be NULL, then you'll have p = NULL + 1). Octavian

1 0

Re: cmd/tests: Add tests for stdout redirection and appending operators
by Marvin July 25, 2011

July 25, 2011

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=12796 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
by Alexandre Julliard July 25, 2011

July 25, 2011

Andrew Eikum <aeikum(a)codeweavers.com> writes: > +/* Attempt to determine if we are running on OSS or ALSA's OSS compatability > + * layer. There is no official way to do that, so just check for validity > + * as best as possible, without rejecting valid OSS implementations. */ > +static BOOL verify_actually_oss(void) > +{ > + int mixer_fd; > + oss_sysinfo sysinfo; > + HKEY key; > + > + static const WCHAR drv_key[] = {'S','o','f','t','w','a','r','e','\\', > + 'W','i','n','e','\\','D','r','i','v','e','r','s',0}; > + static const WCHAR drv_value[] = {'A','u','d','i','o',0}; > + static const WCHAR ossW[] = {'O','S','S'}; > + > + /* if the user has specified a driver explicitly, then succeed > + * if they want OSS and fail if they don't */ > + if(RegOpenKeyW(HKEY_CURRENT_USER, drv_key, &key) == ERROR_SUCCESS){ > + WCHAR driver_name[256]; > + DWORD size = sizeof(driver_name); > + > + if(RegQueryValueExW(key, drv_value, 0, NULL, (BYTE*)driver_name, > + &size) == ERROR_SUCCESS){ > + RegCloseKey(key); > + if(!lstrcmpiW(ossW, driver_name)) > + return TRUE; > + return FALSE; > + } > + > + RegCloseKey(key); > + } It's not the driver's business to check the configuration key. If there's really a need to know if some other driver was configured, this info should be passed from the driver loader. But it would be preferable to avoid that. -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: [PATCH 4/4] shell32/tests: Add verification of known folders relative paths.
by Alexandre Julliard July 25, 2011

July 25, 2011

Mariusz Pluciński <vshader(a)gmail.com> writes: > Checks relative path for each known folder. This one crashes here: ../../../../wine/tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so ../../../../wine/dlls/shell32/tests/shellpath.c && touch shellpath.ok fixme:shell:_SHGetUserProfilePath unsupported for user other than current or default fixme:shell:knownfolder_GetRedirectionCapabilities 0x23f440 fixme:shell:foldermanager_GetFolderByName L"Windows", 0x23f428 wine: Unhandled page fault at address 0x2ae22d17351a (thread 0021), starting debugger... Unhandled exception: page fault in 64-bit code (0x00002ae22d17351a). fixme:dbghelp_dwarf:compute_location Only supporting one breg (r8/336 -> rcx/330) Register dump: rip:00002ae22d17351a rsp:000000000023dd20 rbp:0000000000000000 eflags:00010246 ( R- -- I Z- -P- ) rax:0000ff000000ffff rbx:000000000023f410 rcx:0000000000000018 rdx:0000000000000000 rsi:00000000ffffffff rdi:ff000000ffffff00 r8:00000000000000ff r9:0000000000000007 r10:000000000023d370 r11:0000000000000000 r12:ff000000ffffff00 r13:00002ae22d17b380 r14:0000000000035e92 r15:0000000000010000 Stack dump: 0x000000000023dd20: 000000000023f410 0000000000000000 0x000000000023dd30: 000000000023f408 00002ae22d17b380 0x000000000023dd40: 0000000000035e92 00002ae22d14a5e2 0x000000000023dd50: 000000000003e1f0 00002ae22d17b3a0 0x000000000023dd60: 0000000000000025 00002ae200000001 0x000000000023dd70: 000000000023ec40 0000000000000000 0x000000000023dd80: 0000000000000000 000000000023f408 0x000000000023dd90: 006c006c00000000 0064007200000000 0x000000000023dda0: 0000000000000680 000000680023e400 0x000000000023ddb0: 000000000023ee50 000000000023ec40 0x000000000023ddc0: 000000000023ea30 000000000023e820 0x000000000023ddd0: 000000000023f270 000000000023f400 Backtrace: =>0 0x00002ae22d17351a wine_dbgstr_wn+0x1ca(str=*** invalid address 0xff000000ffffff00 ***, n=0xffffffff) [/home/julliard/wine/build/obj-elf64/dlls/shell32/tests/../../../../wine/include/wine/test.h:471] in shell32_test (0x0000000000000000) 1 0x00002ae22d14a5e2 test_knownFolders+0x1591() [/home/julliard/wine/build/obj-elf64/dlls/shell32/tests/../../../../wine/include/wine/test.h:66] in shell32_test (0x0000000000000000) 2 0x00002ae22d14c80a func_shellpath+0xb09() [/home/julliard/wine/build/obj-elf64/dlls/shell32/tests/../../../../wine/dlls/shell32/tests/shellpath.c:1555] in shell32_test (0x000000000000001a) 3 0x00002ae22d172b47 run_test+0x126(name="../../../../wine/dlls/shell32/tests/shellpath.c") [/home/julliard/wine/build/obj-elf64/dlls/shell32/tests/../../../../wine/include/wine/test.h:556] in shell32_test (0x00002ae22d185df4) 4 0x00002ae22d173676 main+0x115(argc=<is not available>, argv=0x10710) [/home/julliard/wine/build/obj-elf64/dlls/shell32/tests/../../../../wine/include/wine/test.h:624] in shell32_test (0x0000000000010710) 5 0x00002ae22d17387e __wine_spec_exe_entry+0xcd(peb=<is not available>) [/home/julliard/wine/build/obj-elf64/dlls/winecrt0/../../../wine/dlls/winecrt0/exe_entry.c:36] in shell32_test (0x00002ae225108908) 6 0x000000007b87221f start_process+0xbe(peb=0x7fffffbef000) [/home/julliard/wine/build/obj-elf64/dlls/kernel32/../../../wine/dlls/kernel32/process.c:1056] in kernel32 (0x00002ae22d1737b0) 7 0x00002ae225963bab call_thread_func+0x6a(entry=0x7b872160, arg=0x7fffffbef000, frame=0x0(nil)) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/signal_x86_64.c:3189] in ntdll (0x00007fff728e05c0) 8 0x00002ae22595d486 call_thread_entry_point+0x29() in ntdll (0x00007fff728e05c0) 9 0x00002ae22592e766 start_process+0x15(kernel_start=0x23fec8) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2612] in ntdll (0x00007fff728e05c0) 10 0x00002ae224de2223 wine_call_on_stack+0x12() in libwine.so.1 (0x00007fff728e05c0) 11 0x00002ae224de2279 wine_switch_to_stack+0x8(func=<is not available>, arg=<is not available>, stack=<is not available>) [/home/julliard/wine/build/obj-elf64/libs/wine/../../../wine/libs/wine/port.c:59] in libwine.so.1 (0x00007fffffbef000) 12 0x00002ae22593436e LdrInitializeThunk+0x3dd(kernel_start=0x7b872160, unknown2=<is not available>, unknown3=<is not available>, unknown4=<is not available>) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2668] in ntdll (0x00007fffffbef000) 13 0x000000007b878a32 __wine_kernel_init+0x921() [/home/julliard/wine/build/obj-elf64/dlls/kernel32/../../../wine/dlls/kernel32/process.c:1257] in kernel32 (0x00007fff728e1850) 14 0x00002ae225934da4 __wine_process_init+0x253() [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2877] in ntdll (0x00007fff728e1a9c) 15 0x00002ae224de01ff wine_init+0x29e(argc=<is not available>, argv=0x7fff728e2028, error="", error_size=0x400) [/home/julliard/wine/build/obj-elf64/libs/wine/../../../wine/libs/wine/loader.c:831] in libwine.so.1 (0x00007fff728e1b30) 16 0x000000007bf00de1 main+0x70(argc=0x3, argv=0x7fff728e2028) [/home/julliard/wine/build/obj-elf64/loader/../../wine/loader/main.c:228] in <wine-loader> (0x0000000000000003) 17 0x00002ae22536bead __libc_start_main+0xfc(main=<is not available>, argc=<is not available>, ubp_av=<is not available>, init=<is not available>, fini=<is not available>, rtld_fini=<is not available>, stack_end=0x7fff728e2018) [/home/aurel32/eglibc/eglibc-2.13/csu/libc-start.c:228] in libc.so.6 (0x0000000000000000) 18 0x000000007bf00ca9 _start+0x28() in <wine-loader> (0x0000000000000000) 0x00002ae22d17351a wine_dbgstr_wn+0x1ca [/home/julliard/wine/build/obj-elf64/dlls/shell32/tests/../../../../wine/include/wine/test.h:471] in shell32_test: cmpw $0,(%rdi) 471 while (*end) end++; -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [3/5] msi: Don't create a temporary copy of the package.
by Alexandre Julliard July 25, 2011

July 25, 2011

Hans Leidekker <hans(a)codeweavers.com> writes: > There's no need for it now that we open the package in transacted mode. This breaks the Gecko install: fixme:msi:MSI_OpenDatabaseW open failed r = 80030005 for L"Z:\\home\\julliard\\wine\\wine\\..\\gecko\\wine_gecko-1.2.0-x86.msi" err:appwizcpl:install_file MsiInstallProduct failed: 1627 -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH 03/10] winmm: Implement waveOut* on top of MMDevAPI
by Joerg-Cyril.Hoehle＠t-systems.com July 25, 2011

July 25, 2011

Hi, I spent several evenings reviewing the code, here are my findings. The Good + You did it! + outer layer (wave*) uses hwave, inner layer uses device parameter (except WINMM_Pause/Reset which break this separation). + ValidateAndLock pattern + Invoking driver callbacks outside of critical sections, when all slots are in a sane state again. + Removed overhead of pass-through mapper in case of direct format match. However, this may make computations of position and DoneHeaders more complicated. Indeed, I have not yet understood the logic in MarkDoneHeaders and associated queues. Trivia - Some more comments are needed. - Why does WINMM_Pause call IAC_Stop yet set device->stopped = FALSE? - Document that g_device_handles MUST ONLY be modified within the player thread (otherwise MsgWait operates on undefined data), demonstrating that (part of) wave*Open must be handled there. - Express units of entities in WINMM_DEVICE, like you do with last_clock_pos - if(wait == 1 - WAIT_OBJECT_0) should be WAIT_OBJECT_0 + 1 (same by chance) Same with if(wait == g_devhandle_count - WAIT_OBJECT_0) - The caller of WINMM_BeginPlaying supplying the device argument will have locked it already, thus Enter/LeaveCS therein is superfluous. Generally, functions that take a WINMM_Device* parameter should receive it locked by the caller. - Memory leak in WINMM_PrepareHeader in case of acmStreamPrepareHeader error - WOD_Open/WID_Open:cb_info is unused, memcpy(&cb_info,...) useless. Same for WOD/WID_Close - WINMM_OpenDevice passed_fmt HeapAlloc is unchecked Prefer a stack-allocated WAVEFORMATEX and set passed_fmt = &stack_var - Prefer C structure copy over memcpy Logic - I don't see a protection against waveInClose(waveOUThandle); It would be trivial to add a flag to WINMM_GetDeviceFromHWAVE except in WINMM_Pause/Reset. - WINMM_Pause/Reset should take a device pointer, not hwave (which would additionally resolve the above point). - WAVERR_STILLPLAYING is unknown to waveoutClose. It's not a bug, it's a feature? (close would imply stop like the MCI?? but how to unprepare the headers in such a case? IMHO the WINMM API is not designed for a close while playing and only STILLPLAYING makes sense) - nBlockAlign is not sanitized and copied into device->bytes_per_frame. I mentioned long ago tests I wrote that supply incorrect avgbytes and blockalign to winmm yet don't disturb playback in native. IIRC I did not submit them because Wine would not work correctly with them. - device->bytes_per_frame is misdefined and/or misused. It's initialised from the original format (e.g. MP3) but compared in PushData via queue_frames with PCM frames from IAC::GetBuffer. Design - Too bad out_caps.dwSupport is now set within winmm, not the ALSA/OSS/CoreAudio drivers. I loose hope that one day WAVECAPS_VOLUME will be set according to the host OS caps. - How to avoid code duplication among WINMM_MapDevice and msacm32.drv/wavemap.c:wodOpen? - WAVE_FORMAT_DIRECT is missing. It is said to prevent use of ACM (de)compressors. My understanding (untested) is that ACM transforms (e.g. frequency, channels) would still be used. - WINMM_TryDeviceMapping opens the ACM twice, once with ACM_STREAMOPENF_QUERY, then for real. I recommend to open only once, because opening the ACM is an extremely expensive operation, known for delays. All drivers are loaded and queried in turn. I believe this is why people can't seem to Valgrind the winmm/wave and other tests: it just takes sooo much time repeatedly loading and unloading all the drivers! - It may not be a good idea to handle all of wave*Open within the data push thread. Open may take ages, during which no data will be supplied to concurrently playing or recording sounds. Xruns are likely. - Questionable use of BUFFERFLAGS_SILENT in WOD_PushData. When no data is available now, the buffer is flooded with silence, hence data submitted shortly afterwards will be delayed by as much (PulseAudio will accumulate 2 seconds of buffer data...), not by a minimal amount. - The old drivers used ALSA_NearMatch(rate,pcm_rate). There's nothing like this currently in winmm to prevent using a very different rate. My observation is that snd_pcm_set_rate_near() will happily yield 48000 when asked for 8000! Such a variation should be refused by winmm (accepted by dsound?), or a rate converter be silently plugged in. However the code currently ignores ALSA's actual rate and performs all computations using the original one. - Why do you use EVENTCALLBACK? Wine's mmdevapi (currently) signals events periodically from a timer. Winmm could do that itself. - I'm not sure what to think about the observation that waveOutWrite returns an error when BeginPlaying fails yet the header was inserted into the queue. The app may expect the header and data to be reusable for something else because of the error, while Wine may play it from a subsequent BeginPlaying and hit undefined memory. Well, BeginPlaying as of today always returns OK, but the flaw remains. BeginPlaying should be considered a performance optimization hint (start playing fast instead of after the next timer tick) and therefore not need a return value. After enqueuing, NOERROR should be the only return value. - What about mapping some AUDCLNT_E_* to MMSYSERR_*? Regards, Jörg Höhle

2 1

Re: [docs] winedev: Update code columns limit (resend)
by Francois Gouget July 25, 2011

July 25, 2011

On Mon, 4 Jul 2011, André Hentschel wrote: [...] > - Code is usually limited to 80 columns. This helps prevent > - mailers mangling patches by line wrap. Also it generally > + Code is usually limited to 100 columns. It generally I'd prefer to keep the 80 columns recommandation. With 80 columns one can nicely fit files side by side on a laptop with a typical 1024 horizontal resolution whereas with 100 colums one would end up with the hair comb effect thus making the code unreadable. Also 100 seems close enough to 80 that I'm not sure it actually provides any of the benefits that longer lines are supposed to provide (if they are supposed to provide any). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

7 6

Re: po: Use non-breaking spaces where required by the French typography rules.
by Frédéric Delanoy July 25, 2011

July 25, 2011

2011/7/23 Francois Gouget <fgouget(a)free.fr>: > > Except where they may be sent to a command line terminal. > --- > > I did some tests and non-breaking spaces don't seem to cause any issue > in the GUI. Did you use thin/normal non-breaking spaces? Keep in mind that the space "width" and breakability rules change slightly between e.g. France and French-speaking Canada, and that some (most?) translation tools don't allow you to easily view/enter those characters. TBH I'm not quite sure it's worth the trouble ATM Frédéric

2 2

Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
by Vitaliy Margolen July 25, 2011

July 25, 2011

On 07/22/2011 08:35 AM, Andrew Eikum wrote: > > This is really crude, but does seem to work. I tested it correct with just > ALSA 1.0.24; ALSA 1.0.24's snd-pcm-oss and snd-pcm-mixer modules; and on > OSS4.2. It was also tested by Gerald Pfeifer on FreeBSD 8.2 and 9.0. > > This lets us attempt to load the OSS driver, and if that fails, then try the > ALSA driver. Automatic driver selection! You forgetting, that users can select multiple drivers in winecfg now. And that's what some people have in their registry. The actual approach is seems fishy to me as well. The reason ALSA driver is 1st is because most systems has it as the main sound subsystem. Putting something [oss] first in the list, and failing if it wasn't explicitly asked for defeats the whole idea about something being default, and having alternate fallback(s). With same logic one would add all other sound drivers and make them fail, unless explicitly asked for. Vitaliy.

2 1

Statur of DIB Engine
by Massimo Del Fedele July 25, 2011

July 25, 2011

Having seen many patches related to DIB engine lately, I built latest sources and tried it.... No speed enhancements on AutoCAD, my test app. So, I wonder if the engine is already working, at least partially, or not. If yes, there's some switch/environment variable to enable it ? Sorry for asking here but, besides of git commits I've seen no explanation about what's happening. Also some users of my old engine, which are blocked to an old wine version (it is no more applicable to git tree since some time, because of recent changes....) would like to know what's going on. Ciao Max

4 6

Re: cmd: mkdir should complain if directory already exists
by Frédéric Delanoy July 25, 2011

July 25, 2011

On Sun, Jul 24, 2011 at 20:58, Dan Kegel <dank(a)kegel.com> wrote: > Fixes bug 27383. There's trailing whitespace on the line preceding "if (!create_full_path(param1)) {" Seems ok otherwise

1 0

Re: [PATCH 3/4] ntdll: implement the NamedPipeConfiguration value for the FilePipeLocalInformation class of NtQueryInformati
by Marvin July 25, 2011

July 25, 2011

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=12778 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === Timeout

1 0

Re: [PATCH 2/4] kernel32, ntdll, server: implement permission checks for named pipes
by Marvin July 25, 2011

July 25, 2011

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=12777 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === Timeout

1 0

Re: [PATCH 1/4] server, ntdll: get rid of the blocking parameter for ioctls. blockingness depends on the overlapped flag for
by Marvin July 25, 2011

July 25, 2011

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=12776 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === Timeout

1 0

Need help at collecting ActionMapping data
by Lucas Zawacki July 24, 2011

July 24, 2011

Hello everyone. As you may know I'm working on the dinput8 action mapping support and at the moment I've pretty much finished the mouse and keyboard and just need to get my patches in. For the next part, however, I'm going to need to analyze lot's of data generated by different joysticks to figure out how the mapping works. Some things are already clear for me, but I have only some simple USB joysticks here and thus would like your help to collect more useful data. If any of you has any sort of joystick (simple gamepads, driving wheels and whatnot) and would like to help, I've set up a little app that uses the DI8 action mapping API to construct a mapping for every connected joystick and outputs it to the terminal. You just need to run it, redirect the output to a file and email it back to me. Telling me which version of windows you're running would be nice. If you want to help but can't use windows, wine with native dinput8.dll is fine too. The program can be found here: https://github.com/downloads/lfzawacki/dinput-samples/devices_test.exe The code is here: https://github.com/lfzawacki/dinput-samples/blob/master/devices_test.cpp Thanks in advance Cheers

2 3

re: urlmon: Fix various typos/misspellings
by Dan Kegel July 24, 2011

July 24, 2011

Hi Frédéric, >-/* List of 3 character top level domain names Windows seems to recognize. >+/* List of 3 characters top level domain names Windows seems to recognize. That change is incorrect. In English, 'character' should be singular there. (This occurs twice in your patch.) The other changes seem ok. - Dan

5 6

Re: [2/3] winhttp: Implement IWinHttpRequest::get_ResponseBody. (try 2)
by Jacek Caban July 23, 2011

July 23, 2011

Hi Hans, On 07/23/11 09:52, Hans Leidekker wrote: > @@ -2107,7 +2107,7 @@ static void test_IWinHttpRequest(void) > HRESULT hr; > IWinHttpRequest *req; > BSTR method, url, response = NULL, status_text = NULL; > - VARIANT async, empty, timeout; > + VARIANT async, empty, timeout, body; > VARIANT_BOOL succeeded; > LONG status; > > @@ -2241,6 +2241,13 @@ static void test_IWinHttpRequest(void) > ok( hr == S_OK, "got %08x\n", hr ); > SysFreeString( response ); > > + VariantInit( &body ); > + V_VT( &body ) = VT_ERROR; > + hr = IWinHttpRequest_get_ResponseBody( req, &body ); > + ok( hr == S_OK, "got %08x\n", hr ); > + ok( V_VT( &body ) == (VT_ARRAY|VT_UI1), "got %08x\n", V_VT( &body ) ); > + > + ok( hr == S_OK, "got %08x\n", hr ); This duplicates the above test. Did you mean to test the result of VariantClear here (otherwise there is a leak)? Thanks, Jacek

2 1

Re: [2/3] winhttp: Implement IWinHttpRequest::get_ResponseBody. (try 2)
by Marvin July 23, 2011

July 23, 2011

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=12710 Your paranoid android. === W2K8SE (32 bit winhttp) === winhttp.c:926: Test failed: failed to receive response 12152 winhttp.c:933: Test failed: expected ERROR_INSUFFICIENT_BUFFER, got 12019 winhttp.c:937: Test failed: failed unexpectedly 12019 winhttp.c:938: Test failed: unexpected size 0 winhttp.c:943: Test failed: failed unexpectedly 12019

2 1

Re: [1/3] configure.ac: fix libpthread detection on Haiku
by Alexandre Julliard July 22, 2011

July 22, 2011

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > Changelog: > * configure.ac: fix libpthread detection on Haiku > > Haiku has a single library, libroot.so, for all POSIX functions. There > is no separate libc, libm, libpthread, etc. I'd suggest to file bugs with Haiku, they should provide compatibility libraries, that stuff is very much standard. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 1/3] programs: Add rule for cross-building modules.
by Alexandre Julliard July 22, 2011

July 22, 2011

Octavian Voicu <octavian.voicu(a)gmail.com> writes: > Allows cross-building modules similar to how tests are cross-built. > > For each module, a MODULE_cross.exe target is added to cross-build the module. > No other targets are affected. > > Cross-building doesn't work if the module uses libwine or the associated > includes. Currently only notepad_cross.exe can be built using this method, > but next patch makes it possible to also build winetest_cross.exe. > > [I always found it annoying that make crosstest only builds executables for > individual tests. This patch series makes it also build an executable for > winetest.] There's a reason for that. Tests are very limited in what they are allowed to use from Wine, but programs aren't. In particular you can't use any of the portability routines or configure check for cross builds. You really need a separate build tree to cross-compile programs. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [2/3] winhttp: Implement IWinHttpRequest::get_ResponseBody.
by Jacek Caban July 22, 2011

July 22, 2011

Hi Hans, On 07/22/11 16:00, Hans Leidekker wrote: > --- > dlls/winhttp/request.c | 13 +++++++++++-- > dlls/winhttp/tests/winhttp.c | 9 ++++++++- > 2 files changed, 19 insertions(+), 3 deletions(-) > > diff --git a/dlls/winhttp/request.c b/dlls/winhttp/request.c > index 0c4c726..a73be22 100644 > --- a/dlls/winhttp/request.c > +++ b/dlls/winhttp/request.c > @@ -2747,8 +2747,17 @@ static HRESULT WINAPI winhttp_request_get_ResponseBody( > IWinHttpRequest *iface, > VARIANT *body ) > { > - FIXME("\n"); > - return E_NOTIMPL; > + struct winhttp_request *request = impl_from_IWinHttpRequest( iface ); > + DWORD err; > + > + TRACE("%p, %p\n", request, body); > + > + if ((err = request_read_body( request, INFINITE ))) return HRESULT_FROM_WIN32( err ); > + > + VariantInit( body ); > + V_VT( body ) = VT_ARRAY|VT_UI1; > + V_ARRAY( body ) = request->buffer; The caller is responsible for freeing the result, so it will destroy your internal data. I think you should create an array here and not use it to store the data internally. Also VariantInit call is not needed if you set both type and value of variant. Jacek

2 2

Re: urlmon: Added support for javascript URIs
by Marvin July 22, 2011

July 22, 2011

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=12690 Your paranoid android. === WVISTAADM (32 bit uri) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

1 0

Re: [PATCH 2/2] ntdll: Use swapping method to return . and .. as first entries.
by Alexandre Julliard July 22, 2011

July 22, 2011

Grazvydas Ignotas <notasas(a)gmail.com> writes: > @@ -1522,76 +1538,76 @@ static int read_directory_getdents( int fd, IO_STATUS_BLOCK *io, void *buffer, U > } > > io->u.Status = STATUS_SUCCESS; > + de = (KERNEL_DIRENT64 *)data; > > + /* read first 2 entries so we can handle "." and ".." */ > + lseek( fd, 0, SEEK_SET ); > res = getdents64( fd, data, size ); You should find a way to do this only when you do encounter '.' and '..', not on every call. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: winecfg: Add missing checking of HeapAlloc return values.
by Alexandre Julliard July 22, 2011

July 22, 2011

Grazvydas Ignotas <notasas(a)gmail.com> writes: > --- > programs/winecfg/winecfg.c | 18 +++++++++++++----- > programs/winecfg/winecfg.h | 14 ++++++++++---- > 2 files changed, 23 insertions(+), 9 deletions(-) That sort of thing is not useful. It's going to crash a little later, and it's not something that's going to happen in winecfg anyway. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] comctl32: Send CBEM_DELETEITEM when CB_RESETCONTENT is received
by Nikolay Sivov July 22, 2011

July 22, 2011

On 7/22/2011 06:59, Jay Yang wrote: > diff --git a/dlls/comctl32/comboex.c b/dlls/comctl32/comboex.c > index 3402a71..4888519 100644 > --- a/dlls/comctl32/comboex.c > +++ b/dlls/comctl32/comboex.c > @@ -1557,6 +1557,11 @@ static void COMBOEX_ResetContent (COMBOEX_INFO *infoPtr) > > item = infoPtr->items; > while (item) { > + NMCOMBOBOXEXW nmcit; > + memset (&nmcit.ceItem, 0, sizeof(nmcit.ceItem)); > + nmcit.ceItem.mask=~0; > + COMBOEX_CopyItem (item,&nmcit.ceItem); > + COMBOEX_NotifyItem (infoPtr, CBEN_DELETEITEM,&nmcit); > next = item->next; > COMBOEX_FreeText (item); > Free (item); First of all no need for memset probably, and it's common rule I think (well for me at least) to avoid unneeded initialization. As we have message to delete a single item, it's probably time to think about factoring out item deletion helper (that sends notification too). Actually it seems strange for me that this control uses list to store item data, cause messages are clearly index based. So first thing I'd like to see with that is to change item storage to use DPA array as others controls do. But if you don't have time for that now, I could try to do it myself.

2 2

Re: [PATCH 1/2] comctl32: Add tests for CB_RESETCONTENT
by Nikolay Sivov July 22, 2011

July 22, 2011

On 7/22/2011 06:59, Jay Yang wrote: > Tests that CBEM_DELETEITEM notifications are received when CB_RESETCONTENT is sent to a comboex control. > --- > dlls/comctl32/tests/comboex.c | 28 ++++++++++++++++++++++++++++ > 1 files changed, 28 insertions(+), 0 deletions(-) Better way to test that is to use message sequence test. Look at listview test to see how WM_NOTIFY/id pairs are logged.

1 0

Wininet set_cookie must handle not only <name>=<value> but also <name> = <value>
by Bruno Jesus July 22, 2011

July 22, 2011

Hello, while running uTorrent 3 I see the following fixme several times: fixme:wininet:set_cookie Unknown additional option L"expires = Sat,23-Jul-2011 02:20:13 GMT" After searching the source code I realized the expires parameter is already implemented but wine finds the entry names only if there's no space between the parameter name and the equal sign, here is a small piece of wininet.c around line 440 and 470. ... static const WCHAR szExpires[] = {'e','x','p','i','r','e','s','=',0} ... else if (strncmpiW(ptr, szExpires, 8) == 0) ... After searching msdn I found this article with an example that uses spaces: http://msdn.microsoft.com/en-us/library/aa385326%28v=vs.85%29.aspx bReturn = InternetSetCookie(TEXT("http://www.adventure_works.com"), NULL, TEXT("TestData = Test; expires = Sat,01-Jan-2000 00:00:00 GMT")); Looks like the cookie above is valid. I also found this other article telling about the data format: http://msdn.microsoft.com/en-us/library/aa384321%28v=vs.85%29.aspx After reading parts of the cookies RFC I found this note: http://www.ietf.org/rfc/rfc2109.txt ... NOTE: The syntax above allows whitespace between the attribute and the = sign. ... The newer version of the cookie rfc has the very same note: http://www.ietf.org/rfc/rfc2965.txt Please, don't bother to answer if this was already noted and is to be fixed. Also sorry for not pointing a solution. I'll study more on this later but I can say in advance that windows xp sets the cookie correctly when there is the space. I guess I'll start by adding tests for this on the file tests/internet.c Best wishes, Bruno -- universe* god::bigbang (void); //and then it all began...

1 0

Re:
by Lucas Zawacki July 21, 2011

July 21, 2011

Sorry, this is a duplicate for the [3/4] patch, you can disregard it. 2011/7/21 Lucas Fialho Zawacki <lfzawacki(a)gmail.com>: > --- > dlls/dinput/joystick.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 59 insertions(+), 1 deletions(-) > > diff --git a/dlls/dinput/joystick.c b/dlls/dinput/joystick.c > index b5c028c..2d8a818 100644 > --- a/dlls/dinput/joystick.c > +++ b/dlls/dinput/joystick.c > @@ -500,9 +500,67 @@ HRESULT WINAPI JoystickWGenericImpl_SetActionMap(LPDIRECTINPUTDEVICE8W iface, > LPCWSTR lpszUserName, > DWORD dwFlags) > { > + JoystickGenericImpl *This = impl_from_IDirectInputDevice8W(iface); > + DIDATAFORMAT data_format; > + DIOBJECTDATAFORMAT *obj_df = NULL; > + int i, action = 0, num_actions = 0; > + unsigned int offset = 0; > + > FIXME("(%p)->(%p,%s,%08x): semi-stub !\n", iface, lpdiaf, debugstr_w(lpszUserName), dwFlags); > > - return DI_NOEFFECT; > + if (This->base.acquired) return DIERR_ACQUIRED; > + > + data_format.dwSize = sizeof(data_format); > + data_format.dwObjSize = sizeof(DIOBJECTDATAFORMAT); > + data_format.dwFlags = DIDF_RELAXIS; > + data_format.dwDataSize = lpdiaf->dwDataSize; > + > + /* count the actions */ > + for (i=0; i < lpdiaf->dwNumActions; i++) > + if (IsEqualGUID(&This->base.guid, &lpdiaf->rgoAction[i].guidInstance)) > + num_actions++; > + > + if (num_actions == 0) return DI_NOEFFECT; > + > + This->base.num_actions = num_actions; > + > + /* Construct the dataformat and actionmap */ > + obj_df = HeapAlloc(GetProcessHeap(), 0, sizeof(DIOBJECTDATAFORMAT)*num_actions); > + data_format.rgodf = (LPDIOBJECTDATAFORMAT)obj_df; > + data_format.dwNumObjs = num_actions; > + > + This->base.action_map = HeapAlloc(GetProcessHeap(), 0, sizeof(ActionMap)*num_actions); > + > + for (i = 0; i < lpdiaf->dwNumActions; i++) > + { > + if (IsEqualGUID(&This->base.guid, &lpdiaf->rgoAction[i].guidInstance)) > + { > + LPDIDATAFORMAT df = This->base.data_format.wine_df; > + DWORD inst = DIDFT_GETINSTANCE(lpdiaf->rgoAction[i].dwObjID); > + DWORD type = DIDFT_GETTYPE(lpdiaf->rgoAction[i].dwObjID); > + LPDIOBJECTDATAFORMAT obj; > + > + if (type == DIDFT_PSHBUTTON) type = DIDFT_BUTTON; > + if (type == DIDFT_RELAXIS) type = DIDFT_AXIS; > + > + obj = dataformat_to_odf_by_type(df, inst, type); > + > + memcpy(&obj_df[action], obj, df->dwObjSize); > + > + This->base.action_map[action].uAppData = lpdiaf->rgoAction[i].uAppData; > + This->base.action_map[action].offset = offset; > + obj_df[action].dwOfs = offset; > + offset += (type & DIDFT_BUTTON) ? 1 : 4; > + > + action++; > + } > + } > + > + IDirectInputDevice8_SetDataFormat(iface, &data_format); > + > + HeapFree(GetProcessHeap(), 0, obj_df); > + > + return IDirectInputDevice8WImpl_SetActionMap(iface, lpdiaf, lpszUserName, dwFlags); > } > > HRESULT WINAPI JoystickAGenericImpl_SetActionMap(LPDIRECTINPUTDEVICE8A iface, > -- > 1.7.0.4 >

1 0