April 2016 - Wine-Devel - list.winehq.org

Re: How to change Wine DLL search path for "built-in" DLLs?

by Vladimir Panteleev

Thanks Theodore. As I have mentioned, I have already tried DLL overrides, which did not provide the desired effect. Also, as I have mentioned, I'm looking for a programmatic solution, without involving user intervention. On Fri, Apr 8, 2016 at 11:21 PM, Vladimir Panteleev <vladimir(a)thecybershadow.net> wrote: > Thanks Theodore. As I have mentioned, I have already tried DLL > overrides, which did not provide the desired effect. Also, as I have > mentioned, I'm looking for a programmatic solution, without involving > user intervention. > > On Fri, Apr 8, 2016 at 11:19 PM, Theodore Dubois <tblodt(a)icloud.com> wrote: >> Use DLL overrides. Open winecfg, go to the Libraries tab, type msvcr120, click add, click edit, click native, click ok. >> >> ~Theodore >> >>> On Apr 8, 2016, at 2:52 PM, Vladimir Panteleev <vladimir(a)thecybershadow.net> wrote: >>> >>> (reposting from wine-users, which seems to be dead) >>> >>> I'm trying to get the VS2012 C++ compiler (cl.exe) running under Wine >>> - stand-alone, as a component for a different larger project. The >>> project works fine on Windows without affecting any global system >>> settings or files (i.e. it unpacks DLLs etc. to private subdirs >>> instead of installing them system-wide). I'd like it to "just work" >>> under Wine as well, without user intervention or persistent >>> modifications to bottle settings or system files. >>> >>> Wine has a msvcr120.dll, however it is incomplete, at least as far as >>> cl.exe is concerned: >>> >>> wine: Call from 0x7b44ee37 to unimplemented function >>> msvcr120.dll.??0reader_writer_lock(a)Concurrency@@QEAA(a)XZ, aborting >>> Internal Compiler Error in >>> Z:\home\vladimir\work\Digger\work-wine\dl\vs2013-community\Program >>> Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\cl.exe. You >>> will be prompted to send an error report to Microsoft later. >>> >>> The problem is that it attempts to load its builtin DLL even if I >>> place the native Microsoft's DLL in PATH before system32/syswow64. >>> WINEDLLPATH seems to have no effect, and adding a DLL override has no >>> effect other than changing whether it loads Wine's DLL on fails to >>> load a DLL at all (even though it's in PATH!). Yes, the model >>> (bitness) is correct. >>> >>> I remember reading somewhere that Wine uses the value of PATH from the >>> registry. I guess I could also just delete or overwrite Wine's DLL in >>> system32/syswow64. But is it possible to change the DLL search path >>> for one Wine invocation, without any permanent modifications to the >>> bottle? >>> >>> Partially related, but I noticed that Wine does not skip over DLLs of >>> wrong bitness as Windows does. Instead, the program fails to >>> initialize. This means you can't add 32-bit and 64-bit DLL directories >>> to PATH and let the programs' bitness sort out which to use. That's >>> definitely a bug I guess. >>> >>> >>

April 8, 2016

Re: How to change Wine DLL search path for "built-in" DLLs?

by Theodore Dubois

Use DLL overrides. Open winecfg, go to the Libraries tab, type msvcr120, click add, click edit, click native, click ok. ~Theodore > On Apr 8, 2016, at 2:52 PM, Vladimir Panteleev <vladimir(a)thecybershadow.net> wrote: > > (reposting from wine-users, which seems to be dead) > > I'm trying to get the VS2012 C++ compiler (cl.exe) running under Wine > - stand-alone, as a component for a different larger project. The > project works fine on Windows without affecting any global system > settings or files (i.e. it unpacks DLLs etc. to private subdirs > instead of installing them system-wide). I'd like it to "just work" > under Wine as well, without user intervention or persistent > modifications to bottle settings or system files. > > Wine has a msvcr120.dll, however it is incomplete, at least as far as > cl.exe is concerned: > > wine: Call from 0x7b44ee37 to unimplemented function > msvcr120.dll.??0reader_writer_lock(a)Concurrency@@QEAA(a)XZ, aborting > Internal Compiler Error in > Z:\home\vladimir\work\Digger\work-wine\dl\vs2013-community\Program > Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\cl.exe. You > will be prompted to send an error report to Microsoft later. > > The problem is that it attempts to load its builtin DLL even if I > place the native Microsoft's DLL in PATH before system32/syswow64. > WINEDLLPATH seems to have no effect, and adding a DLL override has no > effect other than changing whether it loads Wine's DLL on fails to > load a DLL at all (even though it's in PATH!). Yes, the model > (bitness) is correct. > > I remember reading somewhere that Wine uses the value of PATH from the > registry. I guess I could also just delete or overwrite Wine's DLL in > system32/syswow64. But is it possible to change the DLL search path > for one Wine invocation, without any permanent modifications to the > bottle? > > Partially related, but I noticed that Wine does not skip over DLLs of > wrong bitness as Windows does. Instead, the program fails to > initialize. This means you can't add 32-bit and 64-bit DLL directories > to PATH and let the programs' bitness sort out which to use. That's > definitely a bug I guess. > >

April 8, 2016

Fwd: How to change Wine DLL search path for "built-in" DLLs?

by Vladimir Panteleev

(reposting from wine-users, which seems to be dead) I'm trying to get the VS2012 C++ compiler (cl.exe) running under Wine - stand-alone, as a component for a different larger project. The project works fine on Windows without affecting any global system settings or files (i.e. it unpacks DLLs etc. to private subdirs instead of installing them system-wide). I'd like it to "just work" under Wine as well, without user intervention or persistent modifications to bottle settings or system files. Wine has a msvcr120.dll, however it is incomplete, at least as far as cl.exe is concerned: wine: Call from 0x7b44ee37 to unimplemented function msvcr120.dll.??0reader_writer_lock(a)Concurrency@@QEAA(a)XZ, aborting Internal Compiler Error in Z:\home\vladimir\work\Digger\work-wine\dl\vs2013-community\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\cl.exe. You will be prompted to send an error report to Microsoft later. The problem is that it attempts to load its builtin DLL even if I place the native Microsoft's DLL in PATH before system32/syswow64. WINEDLLPATH seems to have no effect, and adding a DLL override has no effect other than changing whether it loads Wine's DLL on fails to load a DLL at all (even though it's in PATH!). Yes, the model (bitness) is correct. I remember reading somewhere that Wine uses the value of PATH from the registry. I guess I could also just delete or overwrite Wine's DLL in system32/syswow64. But is it possible to change the DLL search path for one Wine invocation, without any permanent modifications to the bottle? Partially related, but I noticed that Wine does not skip over DLLs of wrong bitness as Windows does. Instead, the program fails to initialize. This means you can't add 32-bit and 64-bit DLL directories to PATH and let the programs' bitness sort out which to use. That's definitely a bug I guess.

April 8, 2016

Re: [PATCH 1/4] dsound: Rework ugly mixer logic

by Andrew Eikum

On Fri, Apr 08, 2016 at 08:47:36PM +0200, Henri Verbeet wrote: > On 8 April 2016 at 20:37, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > From: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> > > > > Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> > > --- > > dlls/dsound/dsound.c | 1 - > > dlls/dsound/dsound_main.c | 6 -- > > dlls/dsound/dsound_private.h | 6 +- > > dlls/dsound/mixer.c | 252 +++++++++++-------------------------------- > > dlls/dsound/primary.c | 107 ++++++++---------- > > 5 files changed, 108 insertions(+), 264 deletions(-) > > > You're the one that has to maintain this, so I don't care all too > much, but this looks like it's doing a bunch of different things under > a pretty vague commit message. Looking at it again, you're right. The code is much cleaner on the other side, but there is a lot stuffed into one patch. I'll see how well I can split it up. Andrew

April 8, 2016

Re: [PATCH 1/4] dsound: Rework ugly mixer logic

by Henri Verbeet

On 8 April 2016 at 20:37, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > From: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> > > Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> > --- > dlls/dsound/dsound.c | 1 - > dlls/dsound/dsound_main.c | 6 -- > dlls/dsound/dsound_private.h | 6 +- > dlls/dsound/mixer.c | 252 +++++++++++-------------------------------- > dlls/dsound/primary.c | 107 ++++++++---------- > 5 files changed, 108 insertions(+), 264 deletions(-) > You're the one that has to maintain this, so I don't care all too much, but this looks like it's doing a bunch of different things under a pretty vague commit message.

April 8, 2016

Fwd: How to change Wine DLL search path for "built-in" DLLs?

by Vladimir Panteleev

(reposting from wine-users, which seems to be dead) I'm trying to get the VS2012 C++ compiler (cl.exe) running under Wine - stand-alone, as a component for a different larger project. The project works fine on Windows without affecting any global system settings or files (i.e. it unpacks DLLs etc. to private subdirs instead of installing them system-wide). I'd like it to "just work" under Wine as well, without user intervention or persistent modifications to bottle settings or system files. Wine has a msvcr120.dll, however it is incomplete, at least as far as cl.exe is concerned: wine: Call from 0x7b44ee37 to unimplemented function msvcr120.dll.??0reader_writer_lock(a)Concurrency@@QEAA(a)XZ, aborting Internal Compiler Error in Z:\home\vladimir\work\Digger\work-wine\dl\vs2013-community\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\cl.exe. You will be prompted to send an error report to Microsoft later. The problem is that it attempts to load its builtin DLL even if I place the native Microsoft's DLL in PATH before system32/syswow64. WINEDLLPATH seems to have no effect, and adding a DLL override has no effect other than changing whether it loads Wine's DLL on fails to load a DLL at all (even though it's in PATH!). Yes, the model (bitness) is correct. I remember reading somewhere that Wine uses the value of PATH from the registry. I guess I could also just delete or overwrite Wine's DLL in system32/syswow64. But is it possible to change the DLL search path for one Wine invocation, without any permanent modifications to the bottle? Partially related, but I noticed that Wine does not skip over DLLs of wrong bitness as Windows does. Instead, the program fails to initialize. This means you can't add 32-bit and 64-bit DLL directories to PATH and let the programs' bitness sort out which to use. That's definitely a bug I guess.

April 8, 2016

Re: [PATCH 3/5] user32: Don't enable owner in DIALOG_DoDialogBox.

by Jacek Caban

On 04/06/16 15:24, Jacek Caban wrote: > Could you share those tests (WIP is fine) or run my patches against them? Ping. Did you have a chance to run those tests? Jacek

April 8, 2016

Re: user32/tests: Add some tests for dialog owner disabled state. (v3)

by Jacek Caban

Hi Dmitry, On 04/06/16 13:15, Dmitry Timoshkov wrote: > Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> > --- > dlls/user32/tests/win.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 96 insertions(+), 2 deletions(-) > > diff --git a/dlls/user32/tests/win.c b/dlls/user32/tests/win.c > index 957e8a1d..528669e 100644 > --- a/dlls/user32/tests/win.c > +++ b/dlls/user32/tests/win.c > @@ -4258,6 +4258,78 @@ static INT_PTR WINAPI empty_dlg_proc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM > return 0; > } > > +static INT_PTR WINAPI empty_dlg_proc3(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) > +{ > + if (msg == WM_INITDIALOG) > + EndDialog(hwnd, 0); > + > + return 0; > +} > + > +struct dialog_param > +{ > + HWND parent, grand_parent; > + DLGTEMPLATE *dlg_data; > +}; > + > +static INT_PTR WINAPI empty_dlg_proc2(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) > +{ > + if (msg == WM_INITDIALOG) > + { > + DWORD style = GetWindowLongA(hwnd, GWL_STYLE); > + struct dialog_param *param = (struct dialog_param *)lparam; > + BOOL parent_is_child; > + HWND disabled_hwnd; > + > + parent_is_child = (GetWindowLongA(param->parent, GWL_STYLE) & (WS_POPUP | WS_CHILD)) == WS_CHILD; > + > + ok(IsWindowEnabled(hwnd), "wrong state for %p\n", hwnd); > + if (parent_is_child) > + { > + ok(IsWindowEnabled(param->parent), "wrong state for %08x\n", style); > + disabled_hwnd = param->grand_parent; > + } > + else > + { > + ok(!IsWindowEnabled(param->parent), "wrong state for %08x\n", style); > + disabled_hwnd = param->parent; > + } > + > + if (param->grand_parent) > + { > + if (parent_is_child) > + ok(!IsWindowEnabled(param->grand_parent), "wrong state for %08x\n", style); > + else > + ok(IsWindowEnabled(param->grand_parent), "wrong state for %08x\n", style); > + } > + > + DialogBoxIndirectParamA(GetModuleHandleA(NULL), param->dlg_data, disabled_hwnd, empty_dlg_proc3, 0); > + todo_wine_if ((style & (WS_CHILD|WS_POPUP)) == WS_CHILD) > + ok(IsWindowEnabled(disabled_hwnd), "wrong state for %08x\n", style); If you ensured that disabled_hwnd is enabled here, then testing it later, after dialog is done, has very little value. Maybe you'd disable it by EnableWindow() call here? > + > + ok(IsWindowEnabled(hwnd), "wrong state for %p\n", hwnd); > + ok(IsWindowEnabled(param->parent), "wrong state for %p\n", param->parent); > + if (param->grand_parent) > + todo_wine_if ((style & (WS_CHILD|WS_POPUP)) == WS_CHILD) > + ok(IsWindowEnabled(param->grand_parent), "wrong state for %p (%08x)\n", param->grand_parent, style); > + > + DialogBoxIndirectParamA(GetModuleHandleA(NULL), param->dlg_data, hwnd, empty_dlg_proc3, 0); > + ok(IsWindowEnabled(hwnd), "wrong state for %p\n", hwnd); > + ok(IsWindowEnabled(param->parent), "wrong state for %p\n", param->parent); > + if (param->grand_parent) > + todo_wine_if ((style & (WS_CHILD|WS_POPUP)) == WS_CHILD) > + ok(IsWindowEnabled(param->grand_parent), "wrong state for %p (%08x)\n", param->grand_parent, style); Why do you put those tests inside WM_INITDIALOG? Wouldn't separated tests be cleaner? > + param->dlg_data->style |= WS_CHILD; > + DialogBoxIndirectParamA(GetModuleHandleA(NULL), param->dlg_data, hwnd, empty_dlg_proc3, 0); > + todo_wine_if (!(style & (WS_CHILD|WS_POPUP))) > + ok(IsWindowEnabled(hwnd), "wrong state for %p (%08x)\n", hwnd, style); > + > + EndDialog(hwnd, 0); Testing that EndDialog enables window would be nice (given that it's disabled as I said above). > + } > + return 0; > +} > + > static void check_dialog_style(DWORD style_in, DWORD ex_style_in, DWORD style_out, DWORD ex_style_out) > { > struct > @@ -4269,11 +4341,19 @@ static void check_dialog_style(DWORD style_in, DWORD ex_style_in, DWORD style_ou > WCHAR caption[1]; > } dlg_data; > DWORD style, ex_style; > - HWND hwnd, parent = 0; > + HWND hwnd, grand_parent = 0, parent = 0; > + struct dialog_param param; > > if (style_in & WS_CHILD) > - parent = CreateWindowExA(0, "static", NULL, WS_OVERLAPPEDWINDOW, > + { > + grand_parent = CreateWindowExA(0, "static", NULL, WS_OVERLAPPEDWINDOW, > 0, 0, 0, 0, NULL, NULL, NULL, NULL); > + ok(grand_parent != 0, "grand_parent creation failed\n"); > + } > + > + parent = CreateWindowExA(0, "static", NULL, style_in, > + 0, 0, 0, 0, grand_parent, NULL, NULL, NULL); > + ok(parent != 0, "parent creation failed, style %#x\n", style_in); Always creating window here changes existing tests. It's not a big deal, I wouldn't expect it to change much, but still, the case that's currently tested will no longer be tested. Jacek

April 8, 2016

Re: Winegstreamer entry on Wine FAQ Wiki Page

by Rosanne DiMesio

On Thu, 7 Apr 2016 17:02:18 -0600 Kyle Auble <kyle.auble(a)zoho.com> wrote: > > All of the changes can still be recovered and moved > from the page history though. > It is completely unsuitable as written and I would oppose restoring it. What would be most helpful to users would be to include information on any gstreamer plugins needed by specific apps/games in their respective entries in the AppDB. > 2. That info could be nice to have on one or more of the dev-oriented > pages. The Wine Developer's Guide has a Multimedia section that looks like it hasn't been updated in quite a while. There's also the Packaging page. > And don't forget everybody, since we're on Mediawiki now, every page can > have a corresponding Talk page. Suggestions for changes to the FAQ should be made there. -- Rosanne DiMesio dimesio(a)earthlink.net

April 8, 2016

Re: Winegstreamer entry on Wine FAQ Wiki Page

by Kyle Auble

On 04/07/2016 03:18 PM, Rosanne DiMesio wrote: > On Thu, 7 Apr 2016 15:25:26 -0500 > Austin English <austinenglish(a)gmail.com> wrote: >> Getting winegstreamer to work certainly has been, at least in the past. >> > Yes, it has. The dominant problems are: > > 1. I'm trying to build Wine on a 64 bit system. ./configure keeps telling me it can't find the 32 bit gstreamer development files, but I have them installed. > > 2. My app doesn't work and winegstreamer is complaining about a missing plugin. Which package should I install? (Or the variation, "But I've already installed all the gstreamer plugins available in the repository and it still doesn't work. What should I do?") > > The info on building with gstreamer support on a 64 bit system does need to be added to the Building Wine page (it's on my wiki todo list). The second item is difficult to handle in the FAQ because the answers vary so much by distro. Specific information could be added to the individual distro pages (Debian in particular seems to need it). > I'll keep my thoughts short but I think we could come to a compromise pretty easily on this: 1. Since Gstreamer integration is ideally a problem a normal end-user shouldn't have to deal with, I can see the argument for not keeping it in the normal FAQ. All of the changes can still be recovered and moved from the page history though. 2. That info could be nice to have on one or more of the dev-oriented pages. I didn't port over the old wiki's Gentoo page because what little it had was already on the Gentoo wiki with more context. If there are any Gentoo specific problems though, definitely feel free to start a Gentoo page. 3. A stand-alone page just for Gstreamer support might not be a bad idea either, if anyone wants it bad enough. At least on the Debian side of things, I haven't checked to see if there are any bugs in the packages' Gstreamer support, but it is still one of the major libraries blocking a multiarch build. And don't forget everybody, since we're on Mediawiki now, every page can have a corresponding Talk page. Whether you bring up issues there or on the mailing list is really up to you, but discussions on the mailing list may slip away into the archives without being resolved. Kyle

April 7, 2016