September 2011 - Wine-Devel

Re: [PATCH] winex11: Make MapColor fall back to GetNearestIndex
by Alex Henrie Sept. 29, 2011

Sept. 29, 2011

2011/9/29 David Kiefer <hevanen(a)googlemail.com>: > A possible solution is to have MapColor call GetNearestIndex as a last > resort instead. This both fixes the problem and results in acceptable > performance. Thanks for the tip. I've submitted a new patch which uses this solution instead, and it works better. 2011/9/29 Roderick Colenbrander <thunderbird2k(a)gmail.com>: > I'm not really sure how useful it is to try to optimize parts of the > X11 code now that the DIB engine is progressing nicely. Once the DIB > engine is done this code will disappear anyway. No need for horrible > X11 hacks to offload any DIB rendering and converting the X11 result > back into a DIB. You're right: the DIB engine would be much better. What needs to be done to get the DIB engine to work with Age of Empires II? -Alex

1 0

Re: [PATCH] Enable X11DRV_DIB_GetImageBits_8 in all cases and optimize X11DRV_DIB_GetNearestIndex to fix bug 2666 and other strange behavior
by David Kiefer Sept. 29, 2011

Sept. 29, 2011

While this patch indeed fixes bug 2666, it also kills performance, at least with Age of Empires II. The frame rate in the menu for me is about one frame every three seconds and about 1 fps in-game. With the patch, the work previously done by X11DRV_DIB_MapColor is now done by X11DRV_DIB_GetNearestIndex. Unlike GetNearestIndex, MapColor avoids traversing the entire palette most of the time by reusing the previous index in the destination bitmap if the color has not changed. However, MapColor only checks for exact matches and returns the first palette entry if none was found, effectively causing bug 2666. A possible solution is to have MapColor call GetNearestIndex as a last resort instead. This both fixes the problem and results in acceptable performance. David

2 1

Odd audio regression (interaction between two commits)
by Erich Hoover Sept. 29, 2011

Sept. 29, 2011

A: 64b14c0ecdd13530a92ff636c451523a99253a0b (quartz: Start DirectSound renderer as soon as possible.) B: e786998daff4ad49521a4c9c39c172ddcdcad82a (dsound: Reimplement rendering devices on mmdevapi.) I've been working with the audio in Fallout 3 and Fallout New Vegas for some time and I noticed a regression recently where the audio stopped working properly after the main menu (commit B). This triggered a memory of a similar experience I had where commit A caused the same behavior, but it only did so for PulseAudio users. So, on a hunch, I reverted commit A on the latest git and found that the audio went back to normal again. I'm not entirely sure what commit A could do to cause this problem, and I know you guys are busy with the audio changes, so if someone could point me in the right direction then I will try and track this issue down. Thanks! Erich Hoover ehoover(a)mines.edu

1 0

winecfg: Remove driver selection from Audio tab.
by Joerg-Cyril.Hoehle＠t-systems.com Sept. 29, 2011

Sept. 29, 2011

Hi, I'm not satisfied with the removal of the audio tree from winecfg. Beside allowing to switch or disable drivers, one key feature was to allow inspecting the devices that winmm found on this system. For instance, I've not yet had time to report a bug that since wine-1.3.25, one such entry shows an empty name IIRC. It allowed users to easily check whether e.g. Timidity was recognized or whether "MIDI through" was the only output. It allowed users to easily tell whether their 5:1 sound card was recognized beside the default device. Bugzilla shows 350 entries about winecfg & audio. It had a use. What are users supposed to do now? Regards, Jörg Höhle

9 18

Favorite bug: deadlock preventing backtraces?
by Joerg-Cyril.Hoehle＠t-systems.com Sept. 29, 2011

Sept. 29, 2011

Dan Kegel wrote: >Sadly, no backtrace follows I've not had midi.ok crash on me, but now that you mention it, I've had occasional crashes of random reasons in various apps yet got no backtrace. I seem to remember that there have been times where backtraces would be produced more reliably. So perhaps 1/2 a suggestion would be to try how an older version behaves. It shouldn't matter with midi. But which older version to choose? Regards, Jörg Höhle

1 0

Re: d3dx9_26: Add custom ID3DXEffect interface.
by Erich Hoover Sept. 29, 2011

Sept. 29, 2011

SetRawValue is at the end of the table, so it being extra will not influence any older application. So, you should be able to get the same functionality with way less code by adding that alternative GUID to the QueryInterface in d3dx9_36. Erich Hoover ehoover(a)mines.edu

5 8

Re: [PATCH] Enable X11DRV_DIB_GetImageBits_8 in all cases and optimize X11DRV_DIB_GetNearestIndex to fix bug 2666 and other strange behavior
by Frédéric Delanoy Sept. 29, 2011

Sept. 29, 2011

Please do not include bug number in commit message summary line. Put something like 'fixes bug 123 in the commit header See http://wiki.winehq.org/SubmittingPatches for more info (e.g. "subject line" and "include a description" sections) Frédéric

2 3

Re: d3dx9_26: Add custom ID3DXEffect interface
by luis.busquets＠ilidium.com Sept. 29, 2011

Sept. 29, 2011

And what about introducing wined3dx to wrap up all d3dx9, d3dx10, ... functions?

1 0

CreateDC and DRIVER_GetDriverName
by Bruno Jesus Sept. 28, 2011

Sept. 28, 2011

Hi, I'm seeking advice as I really don't understand anything about wine display drawing (gdi, x11, ...). Every game created with an old win3.11 tool called Klik & Play do not work in wine because a driver called DIB is passed as parameter to CreateDC. Till today I've only seen a driver called DISPLAY being used by all sorts of applications. Looking at the DRIVER_GetDriverName [1] function I can see a list where 3 different drivers are supported. In an attempt to run an old game called Mortuum [2] I can see that it always fail due to this missing DIB driver: err:dc:CreateDCW no driver found for L"DIB" My lack of knowledge made me do a dirty hack in the CreateDCW function forcing the driver DISPLAY to be used instead of DIB and when I started the game it draw it's first screen and then crashed. What should be done to support the DIB driver name now that DIB is implemented in wine? [1] = http://source.winehq.org/source/dlls/gdi32/driver.c#L800 [2] = ftp://ftp.padua.org/pub/msdos/windows/games/local/mortuum.zip Best wishes, Bruno -- universe* god::bigbang (void); //and then it all began...

1 0

Re: [PATCH] d3dx9_36: avoid using fabsf/fmaxf
by Marvin Sept. 28, 2011

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

1 0

Re: [PATCH] d3dx9_36: avoid using fabsf/fmaxf
by Austin English Sept. 28, 2011

Sept. 28, 2011

On Wed, Sep 28, 2011 at 01:51, Natanael Copa <ncopa(a)alpinelinux.org> wrote: > This fixes compiling on Alpine Linux and other uClibc based distros. > > This is related bug 28247 and commit 4cddd5ffdf0c568445365c6c62e7788d7dbbca7d > --- > dlls/d3dx9_36/tests/mesh.c | 14 +++++++------- > 1 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/dlls/d3dx9_36/tests/mesh.c b/dlls/d3dx9_36/tests/mesh.c > index 6a78e64..c09607f 100644 > --- a/dlls/d3dx9_36/tests/mesh.c > +++ b/dlls/d3dx9_36/tests/mesh.c > @@ -6160,7 +6160,7 @@ static void check_vertex_components(int line, int mesh_number, int vertex_number > { > FLOAT *got = (FLOAT*)(got_ptr + decl_ptr->Offset); > FLOAT *exp = (FLOAT*)(exp_ptr + decl_ptr->Offset); > - FLOAT diff = fabsf(*got - *exp); > + FLOAT diff = abs(*got - *exp); > ok_(__FILE__,line)(diff <= FLT_EPSILON, "Mesh %d: Got %f for vertex %d %s, expected %f.\n", > mesh_number, *got, vertex_number, usage_strings[decl_ptr->Usage], *exp); > break; > @@ -6169,7 +6169,7 @@ static void check_vertex_components(int line, int mesh_number, int vertex_number > { > D3DXVECTOR2 *got = (D3DXVECTOR2*)(got_ptr + decl_ptr->Offset); > D3DXVECTOR2 *exp = (D3DXVECTOR2*)(exp_ptr + decl_ptr->Offset); > - FLOAT diff = fmaxf(fabsf(got->x - exp->x), fabsf(got->y - exp->y)); > + FLOAT diff = max(abs(got->x - exp->x), abs(got->y - exp->y)); > ok_(__FILE__,line)(diff <= FLT_EPSILON, "Mesh %d: Got (%f, %f) for vertex %d %s, expected (%f, %f).\n", > mesh_number, got->x, got->y, vertex_number, usage_strings[decl_ptr->Usage], exp->x, exp->y); > break; > @@ -6178,8 +6178,8 @@ static void check_vertex_components(int line, int mesh_number, int vertex_number > { > D3DXVECTOR3 *got = (D3DXVECTOR3*)(got_ptr + decl_ptr->Offset); > D3DXVECTOR3 *exp = (D3DXVECTOR3*)(exp_ptr + decl_ptr->Offset); > - FLOAT diff = fmaxf(fabsf(got->x - exp->x), fabsf(got->y - exp->y)); > - diff = fmaxf(diff, fabsf(got->z - exp->z)); > + FLOAT diff = max(abs(got->x - exp->x), abs(got->y - exp->y)); > + diff = max(diff, abs(got->z - exp->z)); > ok_(__FILE__,line)(diff <= FLT_EPSILON, "Mesh %d: Got (%f, %f, %f) for vertex %d %s, expected (%f, %f, %f).\n", > mesh_number, got->x, got->y, got->z, vertex_number, usage_strings[decl_ptr->Usage], exp->x, exp->y, exp->z); > break; > @@ -6188,9 +6188,9 @@ static void check_vertex_components(int line, int mesh_number, int vertex_number > { > D3DXVECTOR4 *got = (D3DXVECTOR4*)(got_ptr + decl_ptr->Offset); > D3DXVECTOR4 *exp = (D3DXVECTOR4*)(exp_ptr + decl_ptr->Offset); > - FLOAT diff = fmaxf(fabsf(got->x - exp->x), fabsf(got->y - exp->y)); > - diff = fmaxf(diff, fabsf(got->z - exp->z)); > - diff = fmaxf(diff, fabsf(got->w - exp->w)); > + FLOAT diff = max(abs(got->x - exp->x), abs(got->y - exp->y)); > + diff = max(diff, abs(got->z - exp->z)); > + diff = max(diff, abs(got->w - exp->w)); > ok_(__FILE__,line)(diff <= FLT_EPSILON, "Mesh %d: Got (%f, %f, %f, %f) for vertex %d %s, expected (%f, %f, %f, %f).\n", > mesh_number, got->x, got->y, got->z, got->w, vertex_number, usage_strings[decl_ptr->Usage], exp->x, exp->y, exp->z, got->w); > break; > -- > 1.7.6.1 fmaxf was already removed in http://source.winehq.org/git/wine.git/commitdiff/49064869595a8d0c97a79055eb… -- -Austin

1 0

Re: [2/3] cmd: Avoid checking whether we're in console mode for every read (try 2)
by Eric Pouech Sept. 28, 2011

Sept. 28, 2011

Le 28/09/2011 01:01, Frédéric Delanoy a écrit : > --- > programs/cmd/batch.c | 9 ++++----- > programs/cmd/builtins.c | 4 ++-- > programs/cmd/wcmd.h | 5 +++-- > programs/cmd/wcmdmain.c | 21 +++++++++++++-------- > 4 files changed, 22 insertions(+), 17 deletions(-) actually, console handles have their 2 lower bit set you could use it to even simplify further the code A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

1 0

Re: [PATCH 1/2] mmdevapi: Don't fail if dwChannelMask is not set correctly
by Marvin Sept. 28, 2011

Sept. 28, 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=14610 Your paranoid android. === WVISTAADM (32 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === W2K8SE (32 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === W7PRO (32 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === W7PROX64 (32 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === TEST64_W7SP1 (32 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === W7PROX64 (64 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === TEST64_W7SP1 (64 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000

1 0

Re: browseui/tests: Skip some tests if IEnumACString is not supported.
by Marvin Sept. 28, 2011

Sept. 28, 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=14608 Your paranoid android. === WNT4WSSP6 (32 bit autocomplete) === autocomplete.c:250: Test failed: CoCreateInstance(&CLSID_ACLMulti, NULL, CLSCTX_INPROC, &IID_IEnumString, (LPVOID *)&obj) failed: 80040154 === WXPPROSP3 (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === W2K3R2SESP2 (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === WVISTAADM (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === W2K8SE (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === W7PRO (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === W7PROX64 (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === TEST64_W7SP1 (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === W7PROX64 (64 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === TEST64_W7SP1 (64 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0

1 0

Re: [1/3] cmd: Avoid reading char by char from console (try 2)
by Alexandre Julliard Sept. 28, 2011

Sept. 28, 2011

Frédéric Delanoy <frederic.delanoy(a)gmail.com> writes: > @@ -181,13 +181,21 @@ WCHAR *WCMD_parameter (WCHAR *s, int n, WCHAR **where, WCHAR **end) { > * the LF (or CRLF) from the line. > */ > > -WCHAR *WCMD_fgets (WCHAR *s, int noChars, HANDLE h) { > - > - DWORD bytes; > - BOOL status; > +WCHAR *WCMD_fgets (WCHAR *s, int noChars, HANDLE h) > +{ > + DWORD bytes, charsRead, dummy; > + BOOL status, is_console_handle; > WCHAR *p; > > p = s; > + is_console_handle = !!GetConsoleMode(h, &dummy); > + if (is_console_handle) { > + status = ReadConsoleW(h, s, noChars, &charsRead, NULL); ReadConsole will fail if it's not a console, the check is redundant. -- Alexandre Julliard julliard(a)winehq.org

2 2

mmdevapi performance analysis
by Joerg-Cyril.Hoehle＠t-systems.com Sept. 28, 2011

Sept. 28, 2011

Hi, While the 3D guys work on performance improvements, we audio guys kill it. Luckily gfx data is shuffled around in MB/s, audio only in hundred kB/s, so hopefully it doesn't weight that much. Let's have a look at how data wanders around with dsound, winmm and mmdevapi. waveOutWrite with mmdevapi: copy to mmdevapi ALSA/OSS buffer copy some in case of mmdevapi buffer wrap around write buffer to ALSA/OSS waveOutWrite old driver model: write header to ALSA/OSS waveOutWrite involving MSACM with mmdevapi: convert PCM to MSACM, writing to new buffer copy to mmdevapi ALSA/OSS buffer copy some in case of buffer wrap around write to ALSA/OSS Here, if msacm/waveform.c had the courage to delay conversion until GetBuffer time, some copying could be avoided as msacm would write directly into mmdevapi's buffer. Being overly protective ("I should convert before GetBuffer because afterwards I might not have enough time") ends up wasting CPU cycles, hence paradoxically increasing the probability of being late thus causing underruns. The cause for the impedance mismatch between winmm and mmdevapi is what I call "owner inversion". The app supplies winmm with a pointer to its data buffers. As mmdevapi does the same, some transfer is needed between both. Arguably, mmdevapi is not the best target for winmm in Wine... DSOUND_WaveQueue newest "reimplement rendering on mmdevapi" in 1.3.30: write to dsound secondary buffer mix secondary to primary buffer copy to mmdevapi buffer copy some more in case of mmdevapi buffer wrap around write buffer to ALSA/OSS It looks like the new code misses the opportunity to equate device buffer with primary buffer. Instead we've got a cascade of buffers. Why is dsound's primary (mixing target) not mmdevapi's buffer? What's the goal? Ideally, 1. ALSA's mmdevdrv Get/ReleaseBuffer use snd_pcm_mmap_begin/commit, avoiding copying from mmdevapi to ALSA; 2. mmdevapi's buffer becomes DSound's primary, avoiding copying from dsound to mmdevapi. This applies even to CoreAudio where there's not really an mmdevapi buffer. The result: DSound's mixer talks straight with the HW. This should be no surprise. mmdevapi's shared mode mixer probably has roots in dsound's. BTW, what prevents equating dsound's secondary buffers with mmdevapi's shared mode streams and let the underlying device perform the mixing? Regards, Jörg Höhle

1 0

Update on testbot
by Maarten Lankhorst Sept. 28, 2011

Sept. 28, 2011

Hi all, I moved the windows 7 x64 vm with sp1 applied to the base pool now. This means that all submitted patches will be run on that vm as well. The original win7 vm is still available under its own name. Since all tests pass on that according to winehq tests I'm keeping it in the base pool. I hope to see all tests on the new vm fixed as well. They mostly appear to be related to the ie9 update, but msctf:inputprocessor and msi:install fail as well. ~Maarten

2 1

Re: mscoree: Add ICorDebug interface support (try 3)
by Vincent Povirk Sept. 28, 2011

Sept. 28, 2011

It's OK to call CLRMetaHost methods directly with a NULL ICLRMetaHost instance. It's a singleton, and none of the methods use the interface. You might want to check whether you get a new ICorDebug interface every time you request one. I suspect you do. On Wed, Sep 28, 2011 at 1:21 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > Changed to use ICLRRuntimeInfo::GetInterface, suggest by Vincent. > Moved the #undef to the header. > > > Changelog: > mscoree: Add ICorDebug interface support > > > Best Regards > Alistair Leslie-Hughes > > > > > >

1 0

Re: mscoree: Add ICorDebug interface support (try 3)
by Marvin Sept. 28, 2011

Sept. 28, 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=14599 Your paranoid android. === W2K3R2SESP2 (32 bit debugging) === debugging.c:82: Test failed: CreateDebuggingInterfaceFromVersion returned 80070057

1 0

re: dsound: Place storage class before type qualifier
by Dan Kegel Sept. 28, 2011

Sept. 28, 2011

Hi Andrew, doesn't seem to apply here: $ patch -p1 < 79377.patch patching file dlls/dsound/dsound_main.c Hunk #1 FAILED at 319. 1 out of 1 hunk FAILED -- saving rejects to file dlls/dsound/dsound_main.c.rej ---------- Forwarded message ---------- From: <buildbot(a)kegel.com> Date: Tue, Sep 27, 2011 at 2:50 PM Subject: Re: 79377: dsound: Place storage class before type qualifier To: dank(a)kegel.com, wine-tests-results(a)winehq.org This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. For more info about this message, see http://wiki.winehq.org/BuildBot The Buildbot has detected a failed build on builder runtests-default while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/128 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed git Errors: error: patch failed: dlls/dsound/dsound_main.c:319 error: dlls/dsound/dsound_main.c: patch does not apply

1 0

Re: [PATCH] kernel32: make it possible to create a backtrace from a RaiseException exception in gdb
by Alexandre Julliard Sept. 27, 2011

Sept. 27, 2011

Bernhard Loos <bernhardloos(a)googlemail.com> writes: > @@ -60,6 +60,17 @@ static PTOP_LEVEL_EXCEPTION_FILTER top_filter; > typedef INT (WINAPI *MessageBoxA_funcptr)(HWND,LPCSTR,LPCSTR,UINT); > typedef INT (WINAPI *MessageBoxW_funcptr)(HWND,LPCWSTR,LPCWSTR,UINT); > > +#ifdef __i386__ > +/* without this, it's impossible to get a backtrace from the raised > + * exception in winedbg in gdb mode */ > +void RaiseException_helper(EXCEPTION_RECORD *r, void *f) DECLSPEC_HIDDEN; > +__ASM_GLOBAL_FUNC(RaiseException_helper, > + "mov 0x4(%esp),%eax\n\t" > + "push %eax\n\t" > + "mov 0xc(%esp),%eax\n\t" > + "call *%eax\n\t" > + "ret") > +#endif You shouldn't need anything like that. -- Alexandre Julliard julliard(a)winehq.org

2 3

re: winmm: waveOutReset returns all buffers.
by Dan Kegel Sept. 27, 2011

Sept. 27, 2011

Fails to apply here. (Requires fuzz, which Alexandre says is verboten.) ---------- Forwarded message ---------- From: <buildbot(a)kegel.com> Date: Mon, Sep 26, 2011 at 2:35 AM Subject: Re: 79321: winmm: waveOutReset returns all buffers. To: dank(a)kegel.com, wine-tests-results(a)winehq.org This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. For more info about this message, see http://wiki.winehq.org/BuildBot The Buildbot has detected a failed build on builder runtests-default while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/63 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed git Errors: error: patch failed: dlls/winmm/waveform.c:1653 error: dlls/winmm/waveform.c: patch does not apply

2 2

Re: [PATCH] ntdll/signal_i386.c: RtlCaptureContext locals + args are 12 bytes instead of 8 (return address + CONTEXT * arg + %eax local
by Alexandre Julliard Sept. 27, 2011

Sept. 27, 2011

Bernhard Loos <bernhardloos(a)googlemail.com> writes: > @@ -1181,7 +1181,7 @@ __ASM_STDCALL_FUNC( RtlCaptureContext, 4, > __ASM_CFI(".cfi_adjust_cfa_offset 4\n\t") > "popl 0xc0(%eax)\n\t" /* context->EFlags */ > __ASM_CFI(".cfi_adjust_cfa_offset -4\n\t") > - "leal 8(%esp),%edx\n\t" > + "leal 0xc(%esp),%edx\n\t" > "movl %edx,0xc4(%eax)\n\t" /* context->Esp */ That's not really more correct, it's supposed to return the caller frame but there's no good way of doing that. What are you trying to fix? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: mscoree: Add ICorDebug interface support (try 2)
by Vincent Povirk Sept. 27, 2011

Sept. 27, 2011

You really should implement the .NET 4 version of this first (MSDN helpfully points to ICLRRuntimeInfo::GetInterface, which is CLRRuntimeInfo_GetInterface in our code), then implement the legacy version based on that, so everything is in one place. On Tue, Sep 27, 2011 at 6:34 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > Add missing test file. > > Changelog: > mscoree: Add ICorDebug interface support > > > Best Regards > Alistair Leslie-Hughes > > > > >

1 0

Re: mscoree: Add ICorDebug interface support
by Vincent Povirk Sept. 27, 2011

Sept. 27, 2011

Why aren't you using CLRRuntimeInfo_GetInterface for this?

1 0