DOS ain't dead

> - Why would a Win32 devel have/want to use TLS ?

TLS is nearly a requirement if you use threads. The concept is not unique to win32/64, *nix has it too.

All global error variables need TLS, like "errno".

Mostly to guard against cases like:

if (read(...)==-1)
printf("errno: %d",errno);

What if this code runs in a thread, and another thread changes errno between the read and the printf ? It would send you on a wild goose chase.

TLS variables provide a way to keep global variables (both runtime internal and "visible" ones like errno) like these per thread.

TLS callbacks are different. This is mainly a problem in heterogenous programs (programs in different lanugages/runtimes, but also when e.g. DLLs and .exe's in the same language are produced independantly)

Assume that I e.g. import a package in a different language/runtime A into my main program in language/runtime B, and that language has callbacks. If package B initializes a thread and calls a callback set by the mainprogram (A), and if the callback code in A accesses A's TLS errno, then everything might go BOOM, since the thread from B is not initialized by runtime A to setup A's TLS variables (like A's errno)

Here the TLS callback enter. Every runtime registers a callback to initialize/finalize threads (and their TLS variables), so that all threads are usuable in all languages. Appararently, Windows does this registering using a table in the PE format, so that even the mainthread can be initialized using TLScallbacks. From what I get from those links, malware abuses this to run code before main() to fool naieve antivirusses.

In short, any thread capable runtime will sooner or later gravitate to TLS, but non-native Windows compilers (like gcc) might not exploit all Windows features (e.g. register them via PE tables)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***