January 2015 - Wine-Devel - list.winehq.org

Re: ieframe:add app: protocol support to make mshtml trigger BeforeNavigate2 event when handle app: hyperlink
by Jacek Caban Feb. 5, 2015

Feb. 5, 2015

Hi Changhui, On 01/15/15 02:39, Changhui Liu wrote: > Hi, this verify test need the user click the app: hyperlink in browser, > so it is hard to write a test in dlls/ieframe/tests. > > I upload the test html file and a test exe here: > http://www.imakevideo.com/app.html > http://www.imakevideo.com/mfc_web.zip > > To run the test, extract mfc_web.zip, then run the mfc_web.exe, click > the Go button; > A message "BeforeNavigate2 app:xxx" will popup when click the > app: hyperlink > if the BeforeNavigate2 event was triggered as like IE in windows, or > nothing. It doesn't seem right. There is nothing special about app: protocol handling, BeforeNavigate2 should be called in this case the same way as for any other protocol. You need to find the real reason why it's not called instead of calling it in an error case. The bug is likely to be in mshtml. Jacek

2 4

D3d11 CreateDeviceAndSwapChain
by Martell Malone Feb. 1, 2015

Feb. 1, 2015

Hi, I hope this is the right place to send this Jacek asked me to send d3d11 patches to wine and not mingw-w64 first. More will come so if this is the wrong place please correct me :) Kind Regards Martell

2 2

Re: [2/3] mciqtz32: "status mode" returns resource strings.
by Marvin Jan. 30, 2015

Jan. 30, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=11379 Your paranoid android. === wxppro (32 bit mci) === mci.c:1287: Test failed: mci capability device type returned MCIERR_DEVICE_LOCKED

1 0

Re: League of Legends shop in game fix
by Austin English Jan. 30, 2015

Jan. 30, 2015

On Thu, Jan 29, 2015 at 9:19 AM, Monster <manuiglesias96(a)yahoo.es> wrote: > @@ -220,7 +220,10 @@ BOOL wined3d_resource_allocate_sysmem(struct > wined3d_resource *resource) > SIZE_T align = RESOURCE_ALIGNMENT - 1 + sizeof(*p); > void *mem; > - if (!(mem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > resource->size + align))) > + UINT size = resource->size; > + if (resource->width <= 128 && resource->height <= 128) > + size *= 2; > + if (!(mem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size + > align))) > return FALSE; > p = (void **)(((ULONG_PTR)mem + align) & ~(RESOURCE_ALIGNMENT - 1)) - 1; > > > > Please use your real name when sending patches. -- -Austin

3 2

Re: [PATCH] winemac.drv: Always initialize a closure-captured object pointer.
by Ken Thomases Jan. 30, 2015

Jan. 30, 2015

On Jan 29, 2015, at 5:23 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: > You might argue that we don't need to do this because we only use it on > the control paths where we initialize it. Ah, but it *is* used on one of > the other paths: it is captured by the Block closure whether or not we > actually use it inside the Block. This means that, when we copy the > Block onto the heap in OnMainThreadAsync(), the runtime will attempt to > retain it. For some reason, we got away with this in 32-bit > land--probably because the pointer happened to be NULL anyway--but it > broke and died horribly on 64-bit. > > With this change, 64-bit winemac.drv is actually usable. Nice. I was aware of the warning but assumed that it was benign. I'm not sure it's a coincidence that it worked in 32-bit. I don't think that dispatch objects are actually automatically retained by blocks which reference them in 32-bit. It's not entirely related, but it's relatively recent that ARC started doing that and, of course, that requires the modern Objective-C runtime and thus 64-bit. Anyway, I'm glad the Mac driver crashiness in the 64-bit build stemmed from a single cause. I'm sure it wasn't fun to find it. Thanks for doing so. -Ken

1 0

Re: msvcrt: Bump MSVCRT_MB_LEN_MAX to 6 and use it in MSVCRT__wctomb_l for default buffer length
by Piotr Caban Jan. 29, 2015

Jan. 29, 2015

On 01/23/15 18:38, Orion Poplawski wrote: > diff --git a/dlls/msvcrt/msvcrt.h b/dlls/msvcrt/msvcrt.h > index 41f31b9..401628a 100644 > --- a/dlls/msvcrt/msvcrt.h > +++ b/dlls/msvcrt/msvcrt.h > @@ -47,7 +47,7 @@ > #define MSVCRT_I64_MAX (((__int64)0x7fffffff << 32) | 0xffffffff) > #define MSVCRT_I64_MIN (-MSVCRT_I64_MAX-1) > #define MSVCRT_UI64_MAX (((unsigned __int64)0xffffffff << 32) | 0xffffffff) > -#define MSVCRT_MB_LEN_MAX 2 > +#define MSVCRT_MB_LEN_MAX 6 MB_LEN_MAX equals 5 on windows. It should probably be set to 5 here as well. Probably include/msvcrt/limits.h should also be changed. Thanks, Piotr

2 2

Re: [PATCH 1/2] kernel32/tests: Make loader tests independent from each other
by Dmitry Timoshkov Jan. 28, 2015

Jan. 28, 2015

> +const static IMAGE_NT_HEADERS nt_header_template = 'static const' is a commonly accepted order. There are various reasons of the current tests structure, if you are not planning to add new tests please leave the code as it is please. -- Dmitry.

2 4

Re: mshtml: Added support for _self target in IHTMLWindow2::open.
by Marvin Jan. 28, 2015

Jan. 28, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=11354 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: msvcrt: Fix inconsistent rounding behaviour for sprintf and add tests.
by Piotr Caban Jan. 28, 2015

Jan. 28, 2015

On 01/26/15 12:29, YongHao Hu wrote: > + if(flags.Precision >= 0 && toupper(flags.Format)!='G') { > + temp = pow(10, flags.Precision); > + val = round(val * temp) / temp; > + } This is not correct, val may loose to much precision. Also temp can become INF (in your patch temp is int but I guess it's a mistake). I'm afraid that in order to fix this bug you'll need to stop using glibcs sprintf in wine's printf implementation. Your patch to msvcp tests depends on this patch. Please send patches that depend on each other in series. Thanks, Piotr

2 1

Re: [PATCH 3/3] winecfg: add speaker config controls to audio tab
by Andrew Eikum Jan. 27, 2015

Jan. 27, 2015

I think you can squash the last two patches. No need to add symbols before they're used. Does it make sense to have a "system default" configuration as well? For example if the user changes which device ALSA's "default" points to from a 5.1 setup to a stereo setup, the "system default" setting should report the configurations correctly (or, as correctly as the backend allows, but you get the point). This might require storing the user-selected speaker configuration elsewhere in the registry, and updating the real registry entry on mmdevapi load. Couple notes below. On Mon, Jan 26, 2015 at 10:28:26PM +0000, Mark Harmstone wrote: > + info->speaker_config = 999; > + if(SUCCEEDED(hr) && pv.vt == VT_UI4){ > + i = 0; > + while (speaker_configs[i].text_id != 0 && info->speaker_config == 999) { > + if ((speaker_configs[i].speaker_mask & pv.u.ulVal) == speaker_configs[i].speaker_mask) > + info->speaker_config = i; > + i++; > + } > + } This is kind of awkward. Could be a for-loop and break early. > + > + /* fallback to stereo */ > + if(info->speaker_config == 999) > + info->speaker_config = 2; > + Yeah, I don't like 999 either. The "system default" would provide a reasonable fallback option here, too. > + IPropertyStore_Release(ps); > + > return TRUE; > + for (i = 0; i < num_render_devs; i++) { > + ERR("%s -> %u\n", wine_dbgstr_w(render_devs[i].id), speaker_configs[render_devs[i].speaker_config].speaker_mask); Looks like a debug line that should be removed or switched to TRACE. > + pv.u.ulVal = speaker_configs[render_devs[i].speaker_config].speaker_mask; > + WARN("speaker_config = %u\n", pv.u.ulVal); Another debug line? > + > + hr = IPropertyStore_SetValue(ps, &PKEY_AudioEndpoint_PhysicalSpeakers, &pv); > + > + if (FAILED(hr)) > + WARN("IPropertyStore_SetValue failed for %s: 0x%08x\n", wine_dbgstr_w(render_devs[i].id), hr); > + > + IPropertyStore_Commit(ps); This isn't actually implemented in mmdevapi, so we end up with noisy "stub" messages on the terminal. Best thing to do would be to fix the property store implementation, but in lieu of that, I'd just switch the FIXME in mmdevapi with a TRACE. Andrew

1 0