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

Re: Experimental 64 bit OS X packages ready for testing

by Ken Thomases

Hi, On Apr 9, 2016, at 3:17 PM, Michael Müller <michael(a)fds-team.de> wrote: > > After checking a couple of 64-bit applications (VLC, Teamspeak 3, ...), > they were mostly using a single TEB field, which is %%gs:0x30 > (Teb->Tib.Self). My theory is that they use the NtCurrentTeb() inline > function from the MS header files. As you are aware, just changing the > %gs segment is not possible, but in order to get these applications > working we just need to set %%gs:0x30 correctly. Thanks for confirming. We've been working with Apple to get them to bless this hack by officially permanently reserving that slot of the pthread TLS for Wine before we add this to CrossOver. No promises, yet, but they seem positively inclined. We're still trying to find a more comprehensive solution. -Ken

April 9, 2016

wine-1.8.2-rc4 Available

by Michael Stefaniuc

Hello, as Alexandre wanted two more ntdll Coverity patches pulled in I have done just that. wine-1.8.2-rc4 (commit ee9ca763bc671bb895d257044b71f2e4fc4e777a) is basically rc2 + the two patches + the release commit. So this will be a forced update for those that got rc3 already. bye michael

April 9, 2016

Re: Experimental 64 bit OS X packages ready for testing

by Michael Müller

Hi Ken, I've attached the hack as attachment, but let me explain the theory first. ;) After checking a couple of 64-bit applications (VLC, Teamspeak 3, ...), they were mostly using a single TEB field, which is %%gs:0x30 (Teb->Tib.Self). My theory is that they use the NtCurrentTeb() inline function from the MS header files. As you are aware, just changing the %gs segment is not possible, but in order to get these applications working we just need to set %%gs:0x30 correctly. I looked through the last public pthread implementation on OS X and saw that %%gs:0x30 collides with the 6th TLS field. In fact the first 256 fields are reserved for system use, but there is some documentation available how those fields are used (http://opensource.apple.com/source/Libc/Libc-825.40.1/pthreads/pthread_mach…) As you can see the fields 1-9 are reserved for dyld, but only the fields 1,2,3 and 8 are currently in use. The fields 4-7 are reserved for future usage. I therefore looked through the dyld source code to see if those fields might be in use now. To my surprise current versions of dyld don't seem to use hardcoded TLS indices any more. For example field 8 was reserved for Unwind_SjLj and when you take a look at the current source code (http://opensource.apple.com/source/dyld/dyld-360.18/src/dyldAPIs.cpp - function at line 1261) you see that the key is dynamically created using pthread_key_create which only returns fields > 256. Moreover, all the code uses pthread_setspecific which doesn't allow to set fields < 10. There is an exception, when a library requests TLS storage, the values are directly changed using the gs segment, but even in this case the keys are dynamically allocated using pthread_key_create. So far I have found no evidence (neither source code or tests) that those fields are actually used or that the pthread implementation changed in this regard. I therefore assume that overwriting this single field should cause no harm and I gave the hack a try. Anyway, I only spent like an hour yesterday to investigate this and I my have overlooked something. You are of course also welcome to do your own investigations. When my theory holds, we might also be able to optimize Wines NtCurrentTeb() again by using %%gs:0x30 instead of using the pthread_getspecific function. Regards, Michael

April 9, 2016

Re: [PATCH 2/2] d3drm/tests: Add tests for IDirect3DRMObject::Add/DeleteDestroyCallback (v2).

by Aaryaman Vasishta

On Mon, Apr 4, 2016 at 1:40 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > *) The test already does some testing of the call order. I think you could > extend it a bit if you store arrays of expected callback functions and > context pointers in the structure and compare them when the callbacks are > invoked. > > Something like this? http://pastebin.com/hwAA66Vj It's not final yet. I could leave the existing tests alone and use a seperate context pointer for the call order. I'm also aware that the id member might be useless. Cheers, Aaryaman

April 9, 2016

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

by Vladimir Panteleev

On Sat, Apr 9, 2016 at 2:29 PM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > You can set WINEDLLOVERRIDES to set overrides without editing stuff in winecfg or the registry. Thanks Stefan. WINEDLLOVERRIDES, combined with putting the DLLs in system32/syswow64 or the EXE directory, works, however only when WINEDLLOVERRIDES is in the environment when Wine is started. Setting it from within a Windows program running under Wine seems to have no effect, therefore I can't use this solution. > If the DLL overrides don't work it's possible that some other piece is missing. You can use WINEDEBUG=loaddll,module to find out what the loader is doing. With WINEDEBUG, I see the following: trace:module:load_dll looking for L"MSVCR120.dll" in L"Z:\\home\\vladimir\\work\\Digger\\work-wine\\dl\\vs2013-community\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\bin\\amd64;.;C:\\windows\\system32;C:\\windows\\system;C:\\windows;Z:\\home\\vladimir\\work\\Digger\\work-wine\\dl\\vs2013-community\\windows\\system64;Z:\\home\\vladimir\\work\\D"... (Great, it's looking in the right places. Not in PATH but I can place it in the first directory (the EXE directory, since it's not a system one.) trace:module:get_load_order looking for L"Z:\\home\\vladimir\\work\\Digger\\work-wine\\dl\\vs2013-community\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\bin\\amd64\\MSVCR120.dll" (Not sure what this implies if anything.) trace:module:get_load_order got hardcoded default for L"Z:\\home\\vladimir\\work\\Digger\\work-wine\\dl\\vs2013-community\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\bin\\amd64\\MSVCR120.dll" ("Hardcoded default"?) trace:module:load_builtin_dll Trying built-in L"Z:\\home\\vladimir\\work\\Digger\\work-wine\\dl\\vs2013-community\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\bin\\amd64\\MSVCR120.dll" warn:module:load_builtin_dll failed to load .so lib for builtin L"Z:\\home\\vladimir\\work\\Digger\\work-wine\\dl\\vs2013-community\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\bin\\amd64\\MSVCR120.dll": /home/vladimir/.wine/dosdevices/z:/home/vladimir/work/Digger/work-wine/dl/vs2013-community/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/msvcr120.dll: invalid ELF header (It seems to try to load the DLL in the EXE's directory as a built-in, even when it's native. Understandably, it fails.) trace:module:load_builtin_dll Trying built-in L"MSVCR120.dll" (It seems to fall back to its own internal built-in version, even after I have removed it from system32/system64.) I don't really see a way out... > The even better solution would be to implement the missing functions :-) Yep, I've discovered many things that could be fixed or improved. However, for this particular endeavor, I need to target existing Wine versions. > Am 09.04.2016 um 01:22 schrieb Vladimir Panteleev <vladimir(a)thecybershadow.net>: > >> 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 9, 2016

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

by Stefan Dösinger

You can set WINEDLLOVERRIDES to set overrides without editing stuff in winecfg or the registry. If the DLL overrides don't work it's possible that some other piece is missing. You can use WINEDEBUG=loaddll,module to find out what the loader is doing. The even better solution would be to implement the missing functions :-) Stefan Am 09.04.2016 um 01:22 schrieb Vladimir Panteleev <vladimir(a)thecybershadow.net>: > 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 9, 2016

Re: Experimental 64 bit OS X packages ready for testing

by Aaryaman Vasishta

My bad, I mean TeamSpeak 3. On Sat, Apr 9, 2016 at 11:47 AM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > > > On Sat, Apr 9, 2016 at 10:07 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > >> Hi, >> >> On Apr 8, 2016, at 11:03 PM, Michael Müller <michael(a)fds-team.de> wrote: >> > >> > […] I can now present you the first 64-bit Wine packages for testing. >> >> Cool! Thanks! >> >> > [T]he staging package contains a small hack to work >> > around at least some of the GS segment issues (it fixed 64 bit VLC and >> > TS3 for me). >> >> What hack is this? Also, what is TS3? >> >> -Ken >> >> >> I'm guessing it's TS3. > >

April 9, 2016

Re: Experimental 64 bit OS X packages ready for testing

by Aaryaman Vasishta

On Sat, Apr 9, 2016 at 10:07 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > Hi, > > On Apr 8, 2016, at 11:03 PM, Michael Müller <michael(a)fds-team.de> wrote: > > > > […] I can now present you the first 64-bit Wine packages for testing. > > Cool! Thanks! > > > [T]he staging package contains a small hack to work > > around at least some of the GS segment issues (it fixed 64 bit VLC and > > TS3 for me). > > What hack is this? Also, what is TS3? > > -Ken > > > I'm guessing it's TS3.

April 9, 2016

Re: Experimental 64 bit OS X packages ready for testing

by Ken Thomases

Hi, On Apr 8, 2016, at 11:03 PM, Michael Müller <michael(a)fds-team.de> wrote: > > […] I can now present you the first 64-bit Wine packages for testing. Cool! Thanks! > [T]he staging package contains a small hack to work > around at least some of the GS segment issues (it fixed 64 bit VLC and > TS3 for me). What hack is this? Also, what is TS3? -Ken

April 9, 2016

Experimental 64 bit OS X packages ready for testing

by Michael Müller

Hi all, recently there were multiple requests to provide experimental OS X 64 bit packages. I decided to give it a try and updated our build system and cross compiling toolchain during the last days. Luckily the whole idea turned out to be less difficult than I thought, and I can now present you the first 64-bit Wine packages for testing. It would be great to have some testers to find out if I made a mistake during the packaging and to evaluate how good the OS X 64 bit support already works, despite the GS segment / TEB problem. You can find the test packages at https://repos.wine-staging.com/macosx/beta/. I didn't use the WineHQ url because those packages are really in a very early stage, so I would like to have some more testers first before we push it to the users. The pkg installer will now provide you with an option to enable 64 bit support. The files of the 32-bit and 64-bit build are merged during the installation depending on your choice. Please test both options to ensure that a pure 32-bit build also still works as expected. The wine devel package is a pure 1.9.7 build without any additional patches applied, while the staging package contains a small hack to work around at least some of the GS segment issues (it fixed 64 bit VLC and TS3 for me). If you stumble upon any differences between both packages (besides the staged bugs), feel free to tell them to me. This way I can find out how much the hack breaks ;-). Anyway, I am looking forward to your feedback. The checksums are: 272d0fc6ccc390c99b8457c8a433953555f517e0ebbdfe68d7070de377c9fcb4 winehq-devel-1.9.7.pkg eb381ff8aec9e3c82576f941b9918f36185c17f921f0c6c93d6d97033cc0b303 winehq-staging-1.9.7.pkg BTW: Are there any news regarding the developer certificate, so we can sign the packages? I have not heard anything since about four months ago when there was the idea to ask the SFC. Regards, Michael

April 9, 2016