6 of 11Image
Microsoft's ActiveX technology seemed like a very bright idea in 1996, when the World Wide Web was still shiny and new. ActiveX controls were helper programs that could be called by a local app or a Web browser for a specific function. But the architects who dreamed up ActiveX didn't think of its consequences on PC security. The results over the next 10 years or so were disastrous. Today, if you ask a computer security professional or an IT pro about ActiveX, they'll probably just roll their eyes and groan.
The subject came up last year when I criticized Adobe's record on security. Several readers pointed out, quite reasonably, that the same Symantec report I referenced in that post said that "ActiveX technologies still constituted the majority of new browser plug-in vulnerabilities [in 2009], with 134." And indeed, for years after XP's introduction Microsoft was continuing to deal with the fallout of ActiveX insecurity.
Initially, ActiveX provided a convenient way for crooks to sneak malware onto Windows PCs. These were classic social engineering attacks, with malware disguised as a required update to play media files, for example.
Microsoft dealt with those But then, in June 2009, the mother of all ActiveX vulnerabilities was discovered. This is the infamous MSCOMM32.OCX ATL Loader Remote Code Execution Vulnerability (CVE-2008-0024). The problem was found in a template file that was included with Microsoft Visual Basic. In its security advisory, IBM Internet Security Systems rated its exploitability as "high" and described what made the problem so acute:
Although this ActiveX control is not installed by default, most PCs have it. Nearly all Visual Basic applications include this DLL during the installation process, and, since it's considered a shared component of these applications, it is typically left on the system even after an uninstall. So, if a Visual Basic program has ever been installed on a computer, it probably has this ActiveX control installed, too, which makes this component highly prevalent, and, therefore, a lucrative target for attackers.
There's no telling how many ActiveX programs were affected by this vulnerability, but the number is probably in the hundreds. The problem was worst for anyone using Windows XP with Internet Explorer 6.
Over time, Microsoft has tightened security around ActiveX controls dramatically. IE7 introduced a feature called ActiveX opt-in, which made it impossible for an attacker to use an installed ActiveX control without permission. In Windows Vista and Windows 7, Internet Explorer use Protected Mode, which sandboxes ActiveX controls so they're unable to do any serious damage. And cumulative updates to Internet Explorer routinely set ActiveX "killbits" for vulnerable controls to block them from running at all.
In modern Windows versions, you're unlikely to find more than a handful of ActiveX controls. (Adobe's Flash plugin for Internet Explorer is the most common one.) But it's taken years to shake off the security headaches that came with ActiveX, and Internet Explorer's image remains tarnished today.
Before there was the iPad, there was the Tablet PC.
Bill Gates proudly introduced Windows XP Tablet PC Edition (a variant of Windows XP Professional) in 2002, and he operating system got a major update in 2005. Its features were rolled into Windows Vista in 2006, and the entire pen-and-touch input system was refined impressively in Windows 7 in 2009.
And then the iPad came out and made Tablet PCs look like something from a prehistoric time.
What went wrong? If you look closely enough, three problems emerge.
First, the hardware available in the early 2000s simply wasn't good enough to make the tablet experience fun or interesting. Tablets were heavy and hard to hold, and they didn't have enough battery life to get through a working day without being recharged.
Second, these alternative modes of input were considered features rather than the primary mode of interacting with a Tablet PC. Although a few brave OEMs tried to introduce slate designs, the most common tablet configuration was a convertible PC, which functioned as a conventional notebook most of the time and switched into tablet mode as needed. The result was a system that didn't do either task particularly well.
Finally, the biggest problem was a lack of developer support. Even tablet enthusiast had a hard time finding apps that really took advantage of pen and touch input.
And so the entire Windows Tablet PC category was relegated to niche status, selling a microscopic number of units. Within a few months of its release, Apple had sold more iPads than Microsoft had sold Tablet PCs in the preceding eight years.
There's no question that Microsoft learned some painful lessons from the Tablet PC failure. There's also no question that its Tablet PC experience has given it a good head start—at least in technology terms—when it comes to Windows 8. For 2012, its challenge is to prove it can deliver a tablet that people will love. That's a tall order.
Photo: Michael Walsh, The Acer Guy
After XP shipped in 2001, Microsoft got right to work on the next release of Windows. It was an ambitious undertaking. Then-Windows boss Jim Allchin had a long list of groundbreaking features that would go into the upgrade, which was code-named Longhorn.
Paul Thurrott covered the Longhorn project extensively in those early days, putting together a detailed FAQ, multiple screenshot galleries, and extensive coverage of the many times Microsoft excitedly showed off new Longhorn features to developers and partners.
For Longhorn, the high point was the 2003 Professional Developers Conference (PDC), where Microsoft showed off everything it had done so far and whipped developers into a frenzy over what they could do with Avalon and Indigo and WinFS (Future Storage) and Next Generation Secure Computing Base, aka Palladium.
And then the wheels fell off.
In January 2004, Allchin sent an e-mail to Gates and Ballmer admitting failure:
I must tell you everything in my soul tells me that we should do what I called plan (b) yesterday. We need a simple fast storage system. LH (Longhorn) is a pig and I don't see any solution to this problem.
It took a few months, but by August the die had been cast, and the infamous "Longhorn reset" happened. A 2005 Wall Street Journal article has the ugly details:
Microsoft would have to throw out years of computer code in Longhorn and start out with a fresh base. It would set up computers to automatically reject bug-laden code. The new Longhorn would have to be simple. It would leave bells and whistles for later -- including Mr. Gates's WinFS ...
On Aug. 27, 2004, Microsoft said it would ship Longhorn in the second half of 2006 -- at least a year late -- and that Mr. Gates's WinFS advance wouldn't be part of the system. The day before in Microsoft's auditorium, Mr. Allchin had announced to hundreds of Windows engineers that they would "reset" Longhorn using a clean base of code that had been developed for a version of Windows on corporate server computers.
Nearly three years of work went down the drain, and a demoralized development team had to kick into high gear to turn out Windows Vista two years later. It's no wonder that Vista, despite its excellent foundational work, was a mess when it shipped.
Screenshot credit: Paul Thurrott