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
Hi,
On Apr 8, 2016, at 11:03 PM, Michael Müller michael@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
On Sat, Apr 9, 2016 at 10:07 AM, Ken Thomases ken@codeweavers.com wrote:
Hi,
On Apr 8, 2016, at 11:03 PM, Michael Müller michael@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.
My bad, I mean TeamSpeak 3.
On Sat, Apr 9, 2016 at 11:47 AM, Aaryaman Vasishta < jem456.vasishta@gmail.com> wrote:
On Sat, Apr 9, 2016 at 10:07 AM, Ken Thomases ken@codeweavers.com wrote:
Hi,
On Apr 8, 2016, at 11:03 PM, Michael Müller michael@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.
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_machd...). 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
Hi,
On Apr 9, 2016, at 3:17 PM, Michael Müller michael@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
On Fri, Apr 8, 2016 at 11:03 PM, Michael Müller michael@fds-team.de wrote:
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.
That's where it stands as of now. The Wine committee approved the expense, but given that there's a legal agreement involved, we need to involve the SFC. I've pinged Bradley about it, hopefully that will get things rolling.
Please ping me if you don't hear anything in a few weeks, in case I forget :)
-
Aaryaman Vasishta -
Austin English -
Ken Thomases -
Michael Müller