Mac OS X on VmWare - Upgrading from 10.6.4 to 10.6.8

In my previous articles (this and this) I have shown you how to setup a working Mac OS X 10.6.4 system running on your PC using VmWare Workstation. For some time, the setup has been working perfectly fine for me, mostly for iOS development, since I don't own a Mac.

However, recently I needed to upgrade my xCode to version 4.2 in order to support the latest iOS SDK, and to my surprise, Xcode 4.2 requires at least 10.6.7 for installation.

The easy way: modifying SystemVersion.plist

Well, if you don't want to read the rest of this post, there is an easier way. It should be noted that most of xCode and iOS SDK will work just fine without the extra features in 10.6.7 - the minimum version requirement is just Apple's lazy way to reduce development and support efforts by forcing users to upgrade to their latest release.  Following this trick, I opened my SystemVersion.plist located at System/Library/CoreServices, and changed the version number to 10.6.7 or higher:

After a reboot, the new version was shown in About This Mac and xCode installed and worked just fine! Notice that this would fail (xCode installs but behaves erratically) if your current system is too old, e.g. 10.5.x. You'll need at least 10.6.4 for the trick to work.

Updating to 10.6.8 the proper way

However, with some free time at hand, I still decided to go ahead and properly update my system to 10.6.8 using the built-in Software Update. The updated system rebooted just fine, showing 10.6.8 correctly in About This Mac. For complete functionality, I installed the following 2 patches and rebooted the system again:

1. IOUSBFamily-378.pkg: allow the virtual OS to recognize USB devices. You would first need to disconnect it from the host and connect to the Mac via VMWare's Removable Devices menu.
2. EnsoniqAudioPCI_v1.0.3_Common_Installer.pkg: allow audio to work. 

In my case, I also needed to disable the screensaver and various power management settings. For some reasons, it causes random kernel panic.

Expanding the virtual hard disk

Next, I realized that there was not enough disk space to install the latest iOS SDK. Expanding the hard disk is not an easy task, as common methods fail with a "MediaKit reports partition map too small" error message. In my previous tutorial, I have shown a workaround which took a long time and did not always work. The proper method is to manually modify the partition table to reflect the new hard disk size. Run gpt tool from terminal as described in this post (see also this), destroy the existing partition table and recreate a new one with the correct partition size.

Take note that for gpt to work, you need to have the disk unmounted which is not easy as it's a system disk. You would need to boot from the install DVD and use Terminal from there. If a boot disk is not available, make a copy of the working virtual machine, insert the original hard disk as another drive, boot from the copied virtual machine and use it to work with the original hard disk. If you choose the second method, take note that the copied hard disk and the original hard disk will have the same UUID, which will cause problems with Disk Utility and VmWare will also warn you upon startup. The correct way to fix this is to use a hex editor that can accept large file such as Hex Editor Neo to edit the VMDK file and change the UUID. Look for ddb.uuid:

With the expanded hard disk, I installed the latest xCode, iOS SDK and various other apps just fine. Since the default Preview app does not work properly for graphics file due to the lack of QE/CI support, I replaced it with JustLooking, a freeware mac preview app that does not require QE/CI. Taking screenshots is done via VmWare's Capture Screen menu, or via Ctrl-Alt-PrintScreen.

However, everything was working great and I was developing my iOS app on the simulator when I encountered a kernel panic on the virtual Mac, causing VmWare to shut it down:

It took a while for me to realize that it wasn't the Mac that crashed first - it was the iOS app crashing on the simulator and taking the entire system down with it. Yes, any kind of crash, even one as simple as calling an unrecognized selector on an object:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {    
    [self dummyMethod];
    return YES;
}

If you are unlucky enough and the system is writing to the disk when the crash happens, the disk image will be corrupted and the Mac won't reboot to the desktop successfully. It will also be a tough task to recover any data from the corrupted disk image. Sort of funny but true. I was unable to determine the root cause and can only assume that it's due to hardware virtualization. The iPhone simulator architecture is actually x86, which suggests it is sharing the same CPU as the Mac, and any exception caused by the simulator will be escalated to the Mac if not handled properly.

Adding exception breakpoint in xCode

To work around this, I put all my projects in a VmWare shared folder that is linked to a folder the host's hard drive so that the projects are still intact even if the Mac drive is corrupted. I also save working snapshots of the system that I can revert to in case something goes wrong. Most importantly, I add an exception breakpoint so that xCode will stop before an exception occurs, instead of letting it happen and crash the system:

My 10.6.8 upgrade is now completed and my next attempt is to upgrade to Mac OS X Lion (10.7.0), which will be another article. Meanwhile, I can now happily develop iOS apps on my laptop without purchasing a Mac.

Read More »

Raw access to SMS/MMS database on Android phones

My HTC HD2 running on Android from SD card has stopped working recently - the phone simply refused to power up while the battery was still fine. There was nothing I could do except to migrate to a new phone and re-sync everything from my Google account. Restoring the SMS, however, was not an easy task as my latest backup using Sms Backup and Restore is more than 3 months old.

Fortunately my Android was running from SD card, which was still working fine, so I could still access the entire Android folder on the card. Using various Windows tools (see my previous article) such as Ext2Explore, I was able to read the contents of data.img and found the location of the database storing all text messages, among other things, at /data/data/com.android.providers.telephony/databases/mmssms.db. The database is apparently in SQLite format.

Database schema

Next comes the challenge of reading the database. For this I used SQLite Database Browser, and all the tables are listed nicely:

UPDATE: As of end 2014, it seems that SQLite Database Browser has some issues handing the mmssms.db file taken from some devices and will just show a blank database. A better tool to use for this purpose is RazorSQL, which supports SQLite and should be able to open the SMS database without issues.

Reading SMS messages

Opening the SMS table and I can see all messages:

(phone numbers and message bodies have been removed by me when taking the screenshot)

The address column stores the sender/recipient of the message. Column body stores the message body (for MMS/SMS) while subject is for MMS only. The type column specifies the message type (sent, received) and can be 1 or 2. Interestingly, the service centre that sent the message, or SMSC, is also stored but not visible from the stock Messaging application. The time of the message is stored as a Unix timestamp format. To convert it to a readable date in Microsoft Excel, use the following formula, adapted from this blog, and format the cell as Date:

=(((TIMESTAMP/1000/60)/60)/24)+DATE(1970,1,1)

If you want to migrate the SMS to a new Android device, you may be able to do it by simply copying the mmssms.db database to the other device. If not, you can export the messages to a CSV file using File->Export Table as CSV File and import them to Android, Blackberry (see my CSV2IPD tool) or other platforms.

Read More »