Therefore, when 64-bit Windows app code reads them, it gets what it needs. So, Wine simply pokes the appropriate values at those %gs-relative locations. As it happens, Wine never calls that function and there's little reason to expect any of the system libraries that it uses to do so, either. The other was used for the ttyname() function in the C library. We found that one of those slots was unused. They are in a part that's reserved to Apple (rather than, say, application uses). On macOS, %gs:0x30 and %gs:0x58 correspond to particular slots of the thread-local storage area. Often, if apps need to access other fields, they first read the self field and then reference off of that. The most commonly accessed fields of the TEB structure are the 'self' field ( %gs:0x30) and a field for the thread-local storage implementation ( %gs:0x58). The solution we figured out is only a partial solution. (It would also pose potential problems for the kernel on context switches and/or the kernel might fail to restore any value Wine might have set.) Not only does the OS not provide any mechanism to do it but, if Wine could, it would break the system libaries. So, there, Wine simply sets it using the OS-provided mechanism. On Linux, GS.base is available for 64-bit apps to use for their own purpose. It's less common for Mac apps to have hard-coded %gs-relative accesses baked into them, but some do and so do the system libraries. On macOS, GS.base is used to hold the base of the thread-local storage area of the thread's struct _pthread, an internal implementation detail of the Pthreads implementation. This is hard-coded into the app code rather than being behind an API function.

Windows apps expect to access the TEB using %gs-relative addresses. On 64-bit Windows, GS.base is used to hold the address of the Thread Environment Block (TEB) structure for each thread. The primary obstacle is a conflict over the GS segment base address (GS.base) maintained by the CPU under the control of the OS.

A mac emulator like wine