Last time, we ended with the question, “What’s so special about the number 64?” when discovering that a program crashed if it ever got a TLS slot index greater than or equal to 64.

Versions of Windows prior to Windows 2000 supported up to 64 TLS slots. This was codified in the constant

#define TLS_MINIMUM_AVAILABLE 64

but even back then, it was noted in the documentation that 64 was merely the minimum. According to my really ancient copy of the Win32 SDK documentation

The constant TLS_MINIMUM_AVAILABLE defines the minimum number of TLS indices available in each process. This minimum is guaranteed to be at least 64 for all systems.

(I found a site that has something very close to the original documentation.)

Somehow, this got misinterpreted as “The constant TLS_MINIMUM_AVAILABLE defines the maximum number of TLS indices available in each process.”

One theory is that the code was originally written back in the days when the actual limit was indeed 64, and the code was written based on the implementation rather than the documentation. (Possibly because they either got a source code license or reverse-engineered the function and observed that Tls­Alloc always returned a value less than 64.)

I’m not entirely convinced of this theory because the maximum number of TLS slots increased in Windows 2000, but the program in question was released in 2007.

On the other hand, this theory could still be valid the program was using a library that was originally written pre-2000. Even though the program itself was written after 2000, parts of it were written before 2000, back when the TLS limit was 64.

Another theory is that somebody “heard from somewhere” that TLS slots will never go higher than 63, and they simply believed it.

Maybe you can come up with your own theory. Share it in the comments.