On Windows, if a customer disabled a network adapter it would force them to re-activate. Now it just acts as a “fuzzy change”. In the upcoming TurboActivate 4.0, the fingerprinting algorithm has been vastly improved to reduce all known false-positives and false-negatives. This is not that improvement.
On Windows (and some unconfirmed Mac OS X reports) in some regions of the world TurboActivate failed to contact the activation servers even if there was nothing locally (on the computer or LAN) blocking the connection. This has been fixed by back-porting the vast amount of networking improvements back from TurboActivate 4.0.
This bug was a result of an ISP-level configuration error that effected a chunk of customers in Australia and New Zealand.
All communication with the activation servers now happens over HTTPS on port 443. This prevents system administrators or any middle-men from inserting junk into reponses to/from the servers. Previously sensitive information was encrypted, but the data was transmitted over HTTP under most circumstances.
Included XCode project for the C example (1 project for dynamic linkage, another for static linkage)
Subscribe to Wyatt Says...
Subscribe to the 'Wyatt Says...' RSS Feed and keep up to date on on my articles on updaters, usability, open source C# components, and software licensing.