Debugging palmsync

Also known as "An Exercise in Frustration and Self-Torture." As part of preliminary work for mailing list sanity, I need to make some changes to palmsync. It's not like I haven't changed this code before, but the work I need to do here is more than a simple s/a/b/g command. So, time to fire up the 'ole Windows partition and test.

Pain point number one: trying to get necessary stuff to work. First you need the Palm CDK. After getting that (complete with throw-away email account), you now need something to test the other end of palmsync—the PDA. Back at home, I have a monstrously old PDA whose functioning I would not guarantee. Fortunately, there's a nice palm emulator which I can install.

Now I just needed to Hotsync. Another non-trivial task, as my computer does not have two serial ports between which I could slap a cable (it doesn't even have one serial port…). After figuring that part out comes another problem. The palmsync failed to register. "No problem," I say, "I'll just reinstall it." And it still fails. Turns out that the necessary registry key used %ProgramFiles%. Don't you just love the registry?

That's all set up, so I click the sync button and… it fails. That wouldn't seem to be a problem, as I've already had to diagnose many errors to get to this point. Except I seem to have hit the critical unsupported limit:

• I'm using a custom-built version of a program (that's really not saying much, though)
• Said program is built with a technically unsupported compiler (VC 7.1)…
• …which is unsupported on my OS (Windows Vista)…
• …using and old SDK (Windows 2000)…
• …and it's a 32-bit on a 64-bit machine.
• The emulator officially supports neither Vista…
• …nor a 64-bit machine.
• Hotsync doesn't officially support the 64-bit machine either.

Debugging this proved to be a pain. The conduit logs didn't seem to function. Trying to get the VS debugger's nose in there proved a futile task until I did a world rebuild. Which takes 5.5 hours on my system (blame ext3). I finally got the debugger in, only to find a barrier thanks to COM. Some more work managed to shove the debugger in there and finally allowed me to pinpoint the error. Sorry, errors. Suffice to say that it's a mess in there.

So how did I get palmsync under the debugger? First off, let me describe my VS setup: I have mailnews as a project in VS (an NMake project, to be precise), set up such that clicking the build button actually builds in the mailnews directory (thanks to some custom hacking around msys). Based off of some external documentation for debugging Palm conduits, I created a new configuration (called "Palmsync," imaginative little me) whose command ran the hotsync program with -ic as its sole argument. Popping that under the debugger the normal way in VS allowed me to break on Palm's side of the conduit. On the Mozilla side, debugging is done by firing up an instance of TB under the debugger like normal, initiating the hotsync, and breaking and debugging as normal.

Modulo the fact that palmsync is in reality extremely fragile and apparently too buggy to support my nearly-empty testing profiling, it works now. Time to fix some more old bugs solely to be able to get to the point where I can work on the preliminary work for mailing list sanity.