Software Piracy on the Mac

One of the recurring themes in the shareware industry is how to best protect our work from people that don't want to pay. I know I've written on this topic before, but the recent release of Leopard has brought this back to the forefront of my mind. Another blogger wrote about how many people had pre-ordered the Leopard family pack via his Amazon link and was amazed. The family pack is simply the same as the single user pack (same CD), but the license agreement differs slightly in that it says it can be installed on up to 5 machines in the same household. Why would people do this? It seems to me that Mac users are generally honest people willing to pay for good software. I've seen this with my own software where people purchase multiple licenses and I only send 1 serial number (I'll send more than one if I'm asked, but my automated system only sends 1) and people have asked about installing on more than one machine.

Software isn't cheap, but it's good to know that many Mac users do the right thing and purchase software even though it is quite easy to pirate many pieces of Mac software, including Leopard.

Frustration with Windows

Yesterday I had to install some maps onto my Garmin iQue 3600 for a trip back east. I had everything installed on my Windows machine, but wanted to put it in VMWare on my Mac so I could finally get rid of the Windows machine. I downloaded all the installers from the web and tried to install, but kept getting an error message that it couldn't connect to installengine.com to download some component. After searching and futzing for several hours, I finally gave up and installed from the original CD which worked fine. I then did all the upgrades and live was fine. For some stupid reason, InstallShield (one of the most popular installer technologies for Windows), has the install engine separate from the installer. While this sounds like a great idea so that the engine can be installed separately, it isn't if you're dealing with an installer that is several years old. Apple's Installer on Mac OS X does something similar, but the difference is backwards compatibility and the engine is built into the OS. Why is everything so much harder on Windows? Is it simply that I'm not familiar with it or does it really suck?

Compounding my frustration, I went to wipe down the Windows machine to give to my father and when I went to reinstall the OS, I couldn't figure out how to install the drivers. The OS (Windows XP) installed fine, just all the drivers didn't want to install. I ended up just making it my father's problem and gave him all the CDs and said good luck. All the drivers were on the CD, but I had to pick and choose which ones I needed. On the Mac, you insert the CD/DVD and install the OS. Granted you need drivers for scanners and other 3rd party stuff, but not for networking or the video like there is on my Dell machine.

Frozen in New Jersey

This past week's trip to New Jersey/New York reminded me why I live in San Diego. The lows in San Diego were higher than the highs in New Jersey. 40-50 degrees Fahrenheit is just too cold too live for me. While the trees changing colors was pretty, I'll take San Diego seasons any day.

XML vs Binary vs SQLite for CoreData

When I started ReceiptWallet almost a year ago, I chose to use the XML format for my CoreData stores. This was mainly because I was unsure of CoreData and if I messed something up, I could look at the file in a text editor and change it. Except for the first few weeks developing, I've only touched the data file once for a customer where CoreData improperly encoded an entity and made the XML invalid.

Last week I decided to try the Binary format (I put code in awhile ago to try Binary, XML, or SQLite). Wow, the startup time dropped as CoreData no longer had to parse the XML. Next I tried SQLite and again, it appeared to be a bit faster. So, I've decided to make SQLite the default database format for ReceiptWallet and DocumentWallet (it can be changed with a plist change). The only downside to SQLite vs XML and Binary is that an SQLite file can't be opened by two users at once, so I added a preference that allows the user to share the database (everyone except the primary user has to view it as read only) which changes the database format to Binary if it was SQLite.

So, I'm crossing my fingers that I don't run into any problems with SQLite; lots of programs use it, so I should be OK. I did have a bug where I used an NSPredicate with "MATCHES" in it where I should have used "LIKE" which failed with the SQLite store. I'm not sure why that worked in the other database formats, but it did.