From: William Ahern on
Everything I read says that the TEB ThreadLocalStoragePointer (FS:[2Ch])
should point to the TLS array. But, on my XP installation, compiling w/
MinGw32, 0x2c is always NULL. TlsSlots (0xE10) and TlsExpansionSlots (0xF94)
work as advertised, however. (Thus, I'm forcing TlsAlloc() to allocate the
expansion array; I figured perhaps it also set 0x2c, but it's not.)

Is TlsSlots the same in Win95?
From: William Ahern on
William Ahern <william(a)wilbur.25thandclement.com> wrote:
> Everything I read says that the TEB ThreadLocalStoragePointer (FS:[2Ch])
> should point to the TLS array. But, on my XP installation, compiling w/
> MinGw32, 0x2c is always NULL. TlsSlots (0xE10) and TlsExpansionSlots (0xF94)
> work as advertised, however. (Thus, I'm forcing TlsAlloc() to allocate the
> expansion array; I figured perhaps it also set 0x2c, but it's not.)
<snip>

I _think_ the issue is that ThreadLocalStoragePointer is an array of module
loader linked variable tables (i.e. __declspec(thread)). I must assume,
then, that TlsSlots also works in Win95.

There's a lot of misinformation out there....

From: nick.smith2.uk on
Hi, William

Just basically to confirm your findings...

A while ago when I needed to use ThreadLocalStorage this confused me
too. From what i read I assumed that FS:[2Ch] pointed to the TLS slots
but spotted that FS:[2Ch] was NULL except when compiling code using
__declspec(thread) variables.

My findings were that FS:[2Ch] is only used to point to the Thread
Local Storage generated by the linker to hold __declspec(thread) data.
Windows API functions TlsAlloc, TlsSetValue, TlsGetValue etc operate
directly on (offsets from) FS:[0xE10] - this can be seen by stepping
into these functions under a debugger.

This could certainly do with being better documented in my opinion.

Nick.


On Jun 21, 8:54 pm, William Ahern <will...(a)wilbur.25thandClement.com>
wrote:
> William Ahern <will...(a)wilbur.25thandclement.com> wrote:
> > Everything I read says that the TEB ThreadLocalStoragePointer (FS:[2Ch])
> > should point to the TLS array. But, on my XP installation, compiling w/
> > MinGw32, 0x2c is always NULL. TlsSlots (0xE10) and TlsExpansionSlots (0xF94)
> > work as advertised, however. (Thus, I'm forcing TlsAlloc() to allocate the
> > expansion array; I figured perhaps it also set 0x2c, but it's not.)
>
> <snip>
>
> I _think_ the issue is that ThreadLocalStoragePointer is an array of module
> loader linked variable tables (i.e. __declspec(thread)). I must assume,
> then, that TlsSlots also works in Win95.
>
> There's a lot of misinformation out there....

From: William Ahern on
nick.smith2.uk(a)gmail.com wrote:
> Hi, William

> Just basically to confirm your findings...

> A while ago when I needed to use ThreadLocalStorage this confused me
> too. From what i read I assumed that FS:[2Ch] pointed to the TLS slots
> but spotted that FS:[2Ch] was NULL except when compiling code using
> __declspec(thread) variables.

> My findings were that FS:[2Ch] is only used to point to the Thread
> Local Storage generated by the linker to hold __declspec(thread) data.
> Windows API functions TlsAlloc, TlsSetValue, TlsGetValue etc operate
> directly on (offsets from) FS:[0xE10] - this can be seen by stepping
> into these functions under a debugger.

Thanks for taking the time to post. I feel infinitely more confident.

> This could certainly do with being better documented in my opinion.

Agreed! I've only just begun doing heavy Win32 programming, and I'm
astounded at the lack of clear documentation. Despite the steep learning
curve, I'm positively pampered in Unix-land as far as API and semantics
documentation (even excluding the ability to view source code).