The more I wrap my head around the whole thing, the more I begin to feel like I've seen this happen before.
It could be an effect of ZDNet's blog tech support adjusting the interphase transducer on the pattern flow buffers improperly on the site's WordPress CMS during the recent New York City cosmic hail storm, or it could just be simply an enduring hangover from all the Irish coffees I had at the Setai NYC hotel bar last night.
Note to readers:The bartender does an awesome Irish coffee with Bushmills at the Setai.
But I digress. Yes, we've seen this "We do it better than the original on our platform" thing before. In fact, it was twenty years ago. The vendor who last tried to do this was... IBM, with their OS/2 2.0 Operating System.
This is going to open up old wounds for me, but I'll do this anyway.
For the most part, in 1992, IBM succeeded in creating a "Better DOS than DOS and a Better Windows than Windows" with OS/2. It was a full 32-bit OS and could take advantage of much larger amounts of memory, which DOS and Windows could not. It could pre-emptively multi-task, where Microsoft's DOS and Windows 3.0 could not. It could protect native OS/2 applications in discrete sections of memory, which DOS and Windows 3.0 could not.
It could also run DOS and Windows 3.0 applications in their own protected, separate regions of memory, which DOS and Windows... could not. It was the first PC operating system to ship with Windows virtualization included in the OS. It was amazingly ahead of its time, in that respect.
OS/2 ran DOS and Windows 3.0 applicationsso well, in fact, that IBM had a very hard time getting 3rd-party developers to write native OS/2 Presentation Manager applications. Indeed, there were a few little gotchas with OS/2's Windows compatibility, it had problems for a time running Windows Enhanced Mode apps, and there were also issues with special types of device drivers, called VxD's.
Eventually, IBM was able to resolve most of these compatibility issues in future versions of OS/2. But it was always a constant battle to keep up with Microsoft's changes.
However, there is a a great deal of risk associated with attempting toleverage a competitor's ecosystem as opposed to being an active participant in it.
I do not know yet exactly how, from a systems architecture perspective, that QNX accomplishes Android compatibility. In some of my earlier articles which I've linked above, I've alluded to a number of possible paths the company could have gone down to achieve this.
This includes things such as doing a native port of the Dalvik VM for QNX, a binary emulation layer which would allow the native Linux-based Dalvik code to execute via API call translation at the QNX kernel and library level, or even something as radical as Android virtualization.
The Android compatibility mode or "Player" as RIM refers to it in their press release, apparently run in something they call a "secure sandbox". RIM isn't going to show this software to PlayBook developers until May, at the BlackBerry World trade show in Florida, a few weeks after the device ships in retail, so presumably this won't be released to end-users for at least several months post-launch.
I'm hoping that RIM went the Virtualization route as opposed to a native Dalvik port or a binary emulation layer. Ideally, I would like to see a full Android 2.3 stack running inside aType 2 Hypervisor, which is similar to the way VMWare's Mobile Virtualization Platform (MVP) technology works.
Essentially, this requires no "porting" work on RIM's behalf. Instead, an actual copy of Android, with a complete Linux kernel, would run as "Guest" OS within QNX.
Type 2 virtualization is obviously preferable because RIM would be running Google's actual OS, and not attempting to mimic the native Dalvik API itself, which could present any number of compatibility issues.
This is not to say that this would not have its own number of risks associated with it -- the hypervisor would have to be very performance optimized, and near-native Android performance would be expected by the PlayBook's end users, or the compatibility mode won't have much value.
To make Android NDK apps work, hypervisor-based virtualization is probably the only effective way to make Android C++ apps work correctly.
Regardless of the virtualization method used, however -- there is the issue of whether or not Android compatibility will have the same "cooling effect" on the PlayBook's native C++ development environment as well as on the Adobe AIR apps that IBM's Windows 3.0 compatibility had on OS/2.
Obviously, there are differences here. Virtualization technology has improved considerably in 20 years and it has proven to be viable even on embedded systems. As opposed to trying to compete with an OS to sell on PCs pre-loaded and in retail, RIM is selling a hardware platform and going to monetize their own App World.
So the company might not actually care what developers target their apps to, whether it's Android 2.3 Dalvik APIs, QNX C++ native, Java, or Adobe AIR/Flash. Oh, and then there's the WebWorks platform SDK as well. The PlayBook is a literal smorgaboard of API's, probably the richest of all the tablet OSes currently available.
The big question is will the PlayBook do all of them well, and will consumers "get it". Only time will tell.
Will PlayBook's Android "Sandbox" be a blessing, or a curse? Talk Back and Let Me Know.
Disclaimer: The postings and opinions on this blog are my own and don’t necessarily represent IBM’s positions, strategies or opinions.