On 11.03.2010, at 14:30, Kevin Walzer wrote: > I have the technical solutions for these all worked out and documented > on my blog, in user forums, and in e-mails I send to users after seeing > crash reports from them: update the osax and other conflicting files, > move them out of the way if you run my app, etc. Still, I keep getting > crash reports. > > I'm worried that my apps may get a reputation for being buggy and > crash-prone even though they play by the rules (all my stuff is fully > 64-32 bit compatible), and the crashes aren't my fault. I'm pretty > certain I've lost some sales over this because people can't update > certain things, or feel they shouldn't have to. > > Apart from documenting all known issues and educating users about these > issues and advising them on how to update the stuff on their system that > is causing conflicts, is there anything else I can do? How have others > addressed these kinds of issues?
What we've done is throw code at the problem, e.g. some code at startup that looks for the requisite QuickTime component and puts up a warning message. Usually we try to collaborate with the developer of that third party software and work out the best way to detect the old version and/or a workaround. In your particular case of 64/32 bit incompatibility, another common approach is to split out the part that may crash into a separate executable, then run that in 32-bit (see the 'arch' command line tool). To not needlessly run 32 bit code, you can try running it once, and only when it crashes, switch to 32 bits and run it again. Of course, if you can detect the culprit, display an error message like "Frobnitz had to turn off 64-bit support due to the presence of incompatible extension Frobalizer OSAX". Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de
