Doesn't this (finally) put to bed the notion that there are virtually no worms or viruses for Mac OS X simply because hackers don't want to waste their time on a platform with so little market share? The platform targeted by the hackers in this case -- jailbroken iphones running a particular service -- is a fraction of the installed base of Mac OS X computers. It seems that hackers (naturally) select their targets primarily based on ease of exploit -- jailbroken iphones with SSH installed with a default password, for instance, or Microsoft Windows -- than on market share, since any of these platforms still provides tens of millions of potential targets.

I think it's also important to note that the security of Mac OS X extends to the iPhone as well; hackers are apparently unable to successfully compromise the much larger installed base of iPhones, having to content themselves with the much smaller population that has been jailbroken (read, "security compromised").

The TechCrunch rebuttal to the points of Apple's letter is spot on, but the idea that somehow Google has power over the iPhone, or that Google Voice gives it more power, is nonsense. It's hard to believe Apple really thinks this, or that TechCrunch would accept it as a valid explanation. How does having iPhone users receive calls via their Google Voice number affect the iPhone overall at all? iPhone users still have to use AT&T for their calls? It no longer ties the user strongly to their iPhone phone number, but with number portability that represents no advantage for Apple or AT&T. Having Google manage your calendar and contacts doesn't make any difference to the iPhone in general. Google Voice may give Google more power over individual iPhone users, but not over the iPhone itself.

And all Apple would have left is the browser? No, Apple would still have the industry's most advanced, user-friendly handheld OS and probably a hundred thousand apps, including--if they turn out to popular enough to be a thread--Google Voice. If Google has any power over the iPhone, it stems only from their willingness to pull a Microsoft and withdraw those apps and technologies from the iPhone at some point in the future, such as when it comes time for Apple and Google to renegotiate their license for YouTube, maps, and search. But the flip side is equally true; there's no question that its to Google's advantage to be a prominent part of the smart phone platform likely to cell hundreds of millions over the next five years.

In short, I don't think we've heard the real rationale; certainly TechCrunch didn't provide a believable one. I think it's more likely that Apple perceives Google's calendar and contacts apps as a threat to Mobile Me, which does compete directly with Google. Or that Google Voice potentially interferes with something else Apple considers a unique advantage, perhaps something that they aren't even using yet but is in development. And finally, it's possible that Apple really isn't worried about Google Voice per se, but is worried about opening the door to other challenges to their "no duplication of built-in functionality" rule.

This is kernel-level code -- part of the OEM Abstraction Layer -- that is used to read the current time from the RTC, hence it is hardware-specific. RTCs on other processors, or Freescale-based devices using external RTCs, may implement the OemGetRealTime () function differently than Freescale has done here (the buggy ConvertDays () function is just a helper function).

This code is actually from the Windows CE OAL (OEM Abstraction Layer), part of the code that reads the current time from the RTC. As such, the implementation is hardware-dependent, which is why there isn't a standard implementation of this function for Windows CE.

In addition, this code is in a portion of Windows CE source code provided by a device's BSP developer, not by Microsoft. In most cases, Windows CE BSP developers start with sample BSPs written by a processor's manufacturer -- in this case, Freescale -- and then improve it.

It turns out that this bug is specific to the Freescale's BSP -- sample Windows CE BSPs for other procesors don't have it -- and other Freescale devices using Windows CE will only have this issue if their developers used this code verbatim. Since sample BSPs provided by processor manufacturers are often of poor quality, many Windows CE developers typically rewrite such functions. In other words, the impact of this particular bug may be quite limited, which may be why there haven't been reports of this issue on other devices.

In this particular case, though, Microsoft (or a contractor) was the Zune's BSP developer, so they certainly should have caught this.