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

Re: [PATCH 2/4] msvcrt: Support expand_wildcards parameter in __getmainargs function
by Alexandre Julliard 13 Dec '12

13 Dec '12

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -359,6 +360,51 @@ void msvcrt_free_args(void) > HeapFree(GetProcessHeap(), 0, MSVCRT__wenviron); > HeapFree(GetProcessHeap(), 0, MSVCRT__pgmptr); > HeapFree(GetProcessHeap(), 0, MSVCRT__wpgmptr); > + HeapFree(GetProcessHeap(), 0, argv_expand); > +} > + > +static int build_expanded_argv(int *argc, char **argv) > +{ > + int i, size=0, args_no=0; > + HANDLE h; > + > + args_no = 0; > + for(i=0; i<__wine_main_argc; i++) { > + WIN32_FIND_DATAA data; > + int len = 0; > + > + h = FindFirstFileA(__wine_main_argv[i], &data); > + if(h != INVALID_HANDLE_VALUE) { > + do { > + if(data.cFileName[0]=='.' && (data.cFileName[1]=='\0' || > + (data.cFileName[1]=='.' && data.cFileName[2]=='\0'))) > + continue; > + > + len = strlen(data.cFileName)+1; > + if(argv) { > + argv[args_no] = (char*)(argv+*argc)+size; > + memcpy(argv[args_no], data.cFileName, len*sizeof(char)); > + } That won't work if the wildcard contains a path. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] comdlg32/tests: Accept win8 failure-code
by Dmitry Timoshkov 13 Dec '12

13 Dec '12

Detlef Riekenberg <wine.dev(a)web.de> wrote: > - ok(hr == E_FAIL, "got 0x%08x.\n", hr); > + /* win8: E_NOTIMPL */ > + ok(hr == E_FAIL || hr == E_NOTIMPL, "got 0x%08x.\n", hr); A usual form for such comparisons is ok(hr == E_FAIL || hr == E_NOTIMPL /* win8 */, "got 0x%08x.\n", hr); that helps to avoid redundant and duplicating information. -- Dmitry.

1 0

Re: [PATCH] comdlg32/tests: Accept win8 failure-code
by Nikolay Sivov 13 Dec '12

13 Dec '12

It probably makes sense to marking old one as broken, as E_NOTIMPL sounds better in this case. This could potentially break things of course if application checks for strict equality of the error code. On Thu, Dec 13, 2012 at 8:02 AM, Detlef Riekenberg <wine.dev(a)web.de> wrote: > winetestbot crash sometimes in comdlg32:itemdlg on win7 or win2008, > but that is independant from this win8 fix. > > http://test.winehq.org/data/tests/comdlg32:itemdlg.html > > > -- > By by ... Detlef > --- > dlls/comdlg32/tests/itemdlg.c | 9 ++++++--- > 1 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/dlls/comdlg32/tests/itemdlg.c b/dlls/comdlg32/tests/itemdlg.c > index ce05ed8..7bffcbd 100644 > --- a/dlls/comdlg32/tests/itemdlg.c > +++ b/dlls/comdlg32/tests/itemdlg.c > @@ -278,13 +278,16 @@ static BOOL test_instantiation(void) > IShellBrowser *psb; > > hr = IServiceProvider_QueryService(psp, &SID_STopLevelBrowser, > &IID_IExplorerBrowser, (void**)&peb); > - ok(hr == E_FAIL, "got 0x%08x.\n", hr); > + /* win8: E_NOTIMPL */ > + ok(hr == E_FAIL || hr == E_NOTIMPL, "got 0x%08x.\n", hr); > if(SUCCEEDED(hr)) IExplorerBrowser_Release(peb); > hr = IServiceProvider_QueryService(psp, &SID_STopLevelBrowser, > &IID_IShellBrowser, (void**)&psb); > - ok(hr == E_FAIL, "got 0x%08x.\n", hr); > + /* win8: E_NOTIMPL */ > + ok(hr == E_FAIL || hr == E_NOTIMPL, "got 0x%08x.\n", hr); > if(SUCCEEDED(hr)) IShellBrowser_Release(psb); > hr = IServiceProvider_QueryService(psp, &SID_STopLevelBrowser, > &IID_ICommDlgBrowser, (void**)&punk); > - ok(hr == E_FAIL, "got 0x%08x.\n", hr); > + /* win8: E_NOTIMPL */ > + ok(hr == E_FAIL || hr == E_NOTIMPL, "got 0x%08x.\n", hr); > if(SUCCEEDED(hr)) IUnknown_Release(punk); > hr = IServiceProvider_QueryService(psp, > &SID_SExplorerBrowserFrame, &IID_ICommDlgBrowser, (void**)&punk); > ok(hr == S_OK, "got 0x%08x.\n", hr); > -- > 1.7.5.4 > > > >

1 0

RFC: Remove auto-scan of ALSA devices from winealsa.drv
by Joerg-Cyril.Hoehle＠t-systems.com 13 Dec '12

13 Dec '12

Hi, Here's my proposal: winealsa shall stop enumerating ALSA devices. By default, it should solely provide access to ALSA's default device adequately named "default". The code that currently scans the registry Software\Wine\Drivers\winealsa.drv\devices=... shall remain in place, allowing a comma-separated list of alternate ALSA device names for those setups where "default" is not the preferred ALSA choice. Rationale: ALSA front-ends (pulse, dmix etc.) compete for the few back-ends (one or 2 sound cards or audio plugs). Some front-ends cling to the back ends even when unused. This has been known to cause random bugs. - Test suites failing randomly ("resource temporarily unavailable") e.g. bug #28109, #28048 or randomly performing more or less tests, depending on whether the app managed to open the device or not. - Sound stopping in apps (I believe when transitioning from intros to the main menu or game, at which time a rescan of all audio devices happens as mmdevapi is reopened). Nobody found an elegant way to robustly enumerate ALSA devices (some apps hard-wire common names...), so let's simply avoid the issue entirely. On many systems, the current code enumerates a quite uninteresting set of devices, e.g. "default", "plughw:0" and "plughw:4". These days, who wants hw:0 without mixing? I never heard any sound from "hw:4". The current code fails to enumerate some existing devices like "plug:dmix". OTOH, enumerating solely "default" or the user's hand-edited list of devices is expected to provide repeatable and best results. Cost to users: Users with a working ALSA device "default" should experience no drawback, only benefits. I believe this is the vast majority of users. Users that edit their ~/.asoundrc to define other devices without simultaneously overriding !default will have to additionally edit the Wine registry to name their working ALSA capture and render devices, e.g. "asnoop" and "amix". winecfg may or may not provide a GUI for editing this. This would be similar to most multimedia players allowing some way to change the ALSA device to use. It's a pity that the registry scheme AFAIK does not allow per-app audio settings, but that's a completely unrelated issue. Cost of non-adoption: Users and audio devs remain annoyed. Bug reports remain open. Unpredictable and erratic loss of sound possible each time mmdevapi rescans the ALSA devices. Please comment, Jörg Höhle

6 13

Announcing the Mac driver
by Ken Thomases 12 Dec '12

12 Dec '12

Greetings Wine community, As many of you may be aware, CodeWeavers just released CrossOver 12. We're pleased to announce that CrossOver 12 includes the long-awaited Mac driver. If you're not familiar with it, the Mac driver is an alternative to Wine's X11 driver for use on Mac OS X. It allows Wine to present windows, receive input from the keyboard and mouse, and interact with system facilities like the clipboard using Cocoa and other Mac-native APIs. That allows for superior integration into the Mac UI and eliminates the need for the foreign X11 middleware. The Mac driver is not yet complete but it's pretty far along. In CrossOver 12, it's described as an "experimental" feature and is disabled by default. We're aware of chunks of functionality, both big and small, that are simply not implemented yet and there are surely many bugs in need of squashing. You can take a look at the source in CodeWeavers' usual Wine source tarball at <http://www.codeweavers.com/products/faq/source/>. The Mac driver lives in dlls/winemac.drv. Because it was under (somewhat chaotic) development right up until the release of CrossOver 12, we do not yet have a series of clean patches for it to submit to Wine. In the coming days and weeks, I will be reconstructing the Mac driver as just such a patch series and submitting it. Mind you, those patches will face the same demanding scrutiny from Alexandre as everything else, so that process may be slow and painful. I'm SO looking forward to that! Thank you to everyone who contributes to Wine for making this possible. It will be fun to work with you on continuing development of the Mac driver. Cheers, Ken

5 6

Re: wininet: Don't perform revocation checks when verifying a certificate.
by Jacek Caban 12 Dec '12

12 Dec '12

Hi Hans, On 12/11/12 09:45, Hans Leidekker wrote: > https://testbot.winehq.org/JobDetails.pl?Key=23300 is a test which shows that > revocation checks fail for the certificate on outlook.com when passed straight > to CertVerifyRevocation. The reason is that a CRL link specified in the > certificate does not resolve. > > https://testbot.winehq.org/JobDetails.pl?Key=23301 is a test which makes > a secure connection to outlook.com from wininet and shows that this succeeds. > > My conclusion is that native wininet doesn't perform revocation checks. Your tests prove that we should relax our verification on CERT_TRUST_IS_OFFLINE_REVOCATION or something similar. To prove that revocation checks are not made, a test with truly revoked cert would be needed. Jacek

3 6

Re: [PATCH 1/3] jscript: Throw an error if return statement is in eval code
by Marvin 12 Dec '12

12 Dec '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=23356 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: d3d11: add a stub dll
by Henri Verbeet 11 Dec '12

11 Dec '12

On 11 December 2012 04:16, Austin English <austinenglish(a)gmail.com> wrote: > + * Copyright 2012 The Wine Project I don't think that kind of thing really makes sense unless you also define "The Wine Project" as some kind of legal entity somewhere. > + TRACE("(0x%p, %d, %p)\n", hinstDLL, fdwReason, lpvReserved); 0x%p is just wrong, and %d is at least questionable for a DWORD. I suspect this was just copied from somewhere else though.

2 1

Re: testbot: Fix the ConfigLocal.pl include path.
by Alexandre Julliard 11 Dec '12

11 Dec '12

Francois Gouget <fgouget(a)codeweavers.com> writes: > @@ -88,12 +88,11 @@ $JobArchiveDays = 0; > if (!$::BuildEnv) > { > $::BuildEnv = 0; > - eval 'require "$::RootDir/ConfigLocal.pl";'; > + eval 'require "$::RootDir/lib/WineTestBot/ConfigLocal.pl"'; > if ($@) > { > - print STDERR "Please create a valid $::RootDir/ConfigLocal.pl, " . > - "use $::RootDir/lib/WineTestBot/ConfigLocalTemplate.pl as template\n"; > - exit; > + print STDERR "Please create a valid $::RootDir/lib/WineTestBot/ConfigLocal.pl file, use ConfigLocalTemplate.pl as template\n"; > + exit(1); I had changed it because we don't want to have local config files inside the git checkout. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 1/3] include: Define FIELD_OFFSET to the standard offsetof macro
by Michael Stefaniuc 11 Dec '12

11 Dec '12

On 12/10/2012 07:37 PM, Amine Khaldi wrote: > This prevents the undefined behavior (null pointer dereference) > diagnostics (clang with ubsan checks for example). This is a bug in clang. There is no null pointer dereference. Afair gcc tried to pull this trick too but got educated about their error. > > --- > include/winnt.h | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/include/winnt.h b/include/winnt.h > index 207adaa..a3b996a 100644 > --- a/include/winnt.h > +++ b/include/winnt.h > @@ -746,8 +746,12 @@ typedef struct _MEMORY_BASIC_INFORMATION > > #define UNICODE_STRING_MAX_CHARS 32767 > > +#if defined(__GNUC__) || defined(__clang__) > +#define FIELD_OFFSET(type, field) offsetof(type, field) > +#else > #define FIELD_OFFSET(type, field) \ > ((LONG)(INT_PTR)&(((type *)0)->field)) > +#endif > > #define CONTAINING_RECORD(address, type, field) \ > ((type *)((PCHAR)(address) - (PCHAR)(&((type *)0)->field))) bye michael

2 2