Flawed Registration Systems

In the latest MacUpdate Promo, there are a number of programs I’ve never heard of and some that are big name products. I purchased the bundle, downloaded the applications, and started registering them. Developers have chosen different methods for registering their products. There are a few types of schemes that are being used:

  • Registration code that is just entered.
  • Registration code that is entered and then validated against a server.
  • Registration code that is entered and then validated against a server and then tied to a certain computer.
  • Custom downloaded app that is pre-registered.
  • Picture with registration information embedded.
  • Registration code that requires you to visit a web site and then your code is sent to you.

When I started ReceiptWallet, I used eSellerate’s system and chose option number 2. After I received a very nasty comment on VersionTracker that my company could go under and he’d never be able to re-register the application, I immediately switched to option 1 as the user was absolutely correct. Registration schemes, for the most part, keep the honest people, honest. All of the systems above, except for the first one and fifth one, have one serious flaw. That is, the company must still be in business if I change computers or lose the registration number. In addition, their servers must be working and they can’t rearrange anything on the server or the validation may no longer work. I understand that people are trying to protect their software, but protecting the software at the expense of penalizing legitimate customers is, in my opinion, bad business. I’m sure people will disagree with me, but I’ve had a few successful programs that used method number 1. I sold something like 4000 copies of one of my programs to NASA and I wasn’t really worried about piracy.

Developers, please re-consider your registration systems and spend more time writing software and less time on registration schemes.

Paperless in MacUpdate Promo!

Another bundle deal, another set of great apps! This time, however, Paperless (formerly ReceiptWallet), is part of the bundle. MacUpdate is offering a bunch of great apps. You’ve probably heard of most of them. This is the first time that one of my applications has been offered as part of a bundle.

I have a strange hobby of collecting software, so I’ll probably bite on this deal despite owning a few in the collection. It’s hard to go wrong for the price. If you decide to buy the bundle, click on the link on the right side of the page advertising the bundle to support my blog (running this blog isn’t free :-)).

Paperless on sale until Sunday!

Paperless, the new name for ReceiptWallet, is on sale until Sunday (5/17) for $34.95. It has the new branding on it, but it’s still my beloved ReceiptWallet! Additional features will be coming and this is a great opportunity for those that haven’t already committed to becoming organized to start.

Dealing with screenshots

Over the years, I’ve had to take screenshots for documentation, to report bugs, and to help other people. Up until recently, the primary application I used was SnapzProX. However, it took awhile for them to come up with an Intel native version and pretty much has remained the same for years. This isn’t really a bad thing as the program worked, but I was longing for something more. There have been a number of programs brought to market since SnapzProX, but nothing has really come close to meeting my needs.

I came across a program called Layers and immediately bought it. The ability to capture a screen with each window as a separate layer looked really cool. However, after using it for a little while, it just didn’t reaplce SnapzProX or command-shift-4. It still has a use every now and again, but not for everyday use.

When I bought the MacHeist 3 bundle, I looked at each program it came with to see if anything would fit into my everyday toolbelt (a lot of the applications could be used here and there). I started playing with LittleSnapper and after some initial problems (saving a web page as a PDF crashes it and there is currently no fix for it; in addition, uploading to a web site via SFTP doesn’t work with public/private key encryption), it has become invaluable to me. The feature that is making it invaluable to me is the fact that it saves the screenshots to a library and I can drag directly out of it into an iChat window or in an email message without having to save it to the desktop, drag it in, then delete the file (I also used to always delete the file before I sent the file which caused a problem). I still want them to fix the SFTP issue, but I’m quite happy with the program. I need to figure out how else I can use it.

The end of desktop sync?

While this probably isn’t news to many, I have almost come to the conclusion that syncing a handheld with the desktop is dead. The only exception is media as OTA (over the air) sync is far too slow (currently) to handle large photos, music, and movie (for the most part). It has taken me awhile to come to this conclusion as I spent many years working on desktop sync software. In the last few weeks, we installed Zimbra at work and are moving people towards syncing their handhelds (Windows Mobile, BlackBerry, iPhone, and Palm OS devices) over the air (primarily cellular). In these cases, the desktop just becomes another sync client and not the master; the server handles the synchronization.

My life seems much simpler now that I don’t have to deal with desktop sync; no more desktop configuration, physical connection issues, and various conduits.

Another MacHeist Bundle and More Tempers

I’ve waffled on what I think about bundled software like that being offered at MacHeist at a steep discount. My latest ramblings have been supportive of it. As a consumer, it’s great to get lots of stuff for just a little amount of money. Will I use everything in the bundle? Unlikely. However, I’ve used some of the programs I’ve bought here and there. For the most part, I might use 1 or 2 programs, but just in case I have a use for something else, I know I have it. For instance, today I used GraphicConverter to convert some graphics; I would not have bought GraphicConverter at full price (the awful UI really puts me off).

One person has been ranting about it and basically saying people are cheap for buying it. Well, I bought it (still waiting for them to fix their system as they took my money, but didn’t deliver me anything; they underestimated demand which is surprising considering how well the last 2 have done) and I don’t feel cheap. I see some of the developers gaining a customer that they would never have had. The developers have a chance to sell me an upgrade later and that may just happen.

Documentation made easy

About a month ago, I wrote about a program called ScreenSteps for creating documentation for work. I bought the program because nothing else was out there that I could find (I’m not ready to do video documentation), but had major reservations in that the app was created using a cross platform tool. I’ve been using ScreenSteps to create lots of documentation, but have grown increasingly frustrated at it as it is quirky. For instance, it doesn’t do auto spell checking since it doesn’t use standard Mac based text editing, re-ordering steps don’t always work, and the dialogs look like crap.

A few days ago, a product called MacSnapper was released. It had many similarities to ScreenSteps, but one huge difference; it is a Mac app through and through. I converted some documentation to it and quickly purchased it. I made a few suggestions to the developer and quickly got a response. I just have to convert the rest of my documentation to MacSnapper and then I can get rid of ScreenSteps; I kind of feel dirty using a cross platform application as applications like this just don’t act like Mac apps (I’m sure there are a few exceptions, but I haven’t seen them, yet).

Who says hacks don’t cause problems?

The other day I had lunch with a friend and a friend of his wanting to get into Mac development. We were talking and this guy said that he admired a company that created “haxies”. I said that I really disliked them as their software can cause problems left and right with the system.

The very next day, I got a ReceiptWallet crash report where the user said he pulled down a menu and tried to create a new library. This action is pretty basic and just uses actions in the nib. In this user’s case, it caused ReceiptWallet to crash. Normally I would have ignored this and just said it was some fluke, but I decided to dig deeper. Here’s the top of the crash report:

Process:         ReceiptWallet [99875]
Path:            /Applications/ReceiptWallet.app/Contents/MacOS/
ReceiptWallet
Identifier:      com.ggtenterprises.receiptwallet
Version:         2.0.9 (2.0.9)
Code Type:       X86 (Native)
Parent Process:  launchd [98]

Date/Time:       2009-03-11 16:49:08.632 -0600
OS Version:      Mac OS X 10.5.6 (9G66)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000c0226ccb
Crashed Thread:  0

Thread 0 Crashed:
0   libobjc.A.dylib               	0x935cd688 objc_msgSend + 24
1   com.apple.AppKit              	0x947c453b -[NSApplication
sendAction:to:from:] + 112
2   com.apple.AppKit              	0x9487317c -[NSMenu
performActionForItemAtIndex:] + 493
3   com.apple.AppKit              	0x94872e81 -[NSCarbonMenuImpl
performActionWithHighlightingForItemAtIndex:] + 220
4   com.apple.AppKit              	0x9484fb5a AppKitMenuEventHandler +
6608
5   com.apple.HIToolbox           	0x964d4143
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,
HandlerCallRec*) + 1181
6   com.apple.HIToolbox           	0x964d357d
SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*,
HandlerCallRec*) + 405
7   com.apple.HIToolbox           	0x964efed2 SendEventToEventTarget +
52
8   com.apple.HIToolbox           	0x9652423d
SendHICommandEvent(unsigned long, HICommand const*, unsigned long,
unsigned long, unsigned char, OpaqueEventTargetRef*,

I then looked at what was loaded in memory and saw this:

  0xeb2000 -   0xeb4fff +com.unsanity.menuextraenabler 1.0.3 (1.0.3) /
Library/InputManagers/Menu Extra Enabler/Menu Extra Enabler.bundle/
Contents/MacOS/Menu Extra Enabler

Hmmm, looks like a “haxie” that deals with menus. While the company that makes these haxies has repeatedly said that their software doesn’t cause problems, but until users can prove to me that the problem is reproducible without the haxie installed, I have no insert in pursuing the matter. In a post about two years ago, a member of Apple’s DTS team wrote that they don’t investigate any crash that has haxies in it.

While I use one program (1Password) that patches the system, it is quite stable and only affects a few programs (Safari, FireFox, NetNewsWathcer). I’m just really tired of haxies that touch stuff that they shouldn’t.

Accepting responsibility for bugs

When I make a mistake, I take full responsibility for the issue. While some people think I never make mistakes, I am human. The same goes for bugs in my software; software will never be perfect and I make my share of mistakes. I acknowledge these mistakes in my release notes where I say “Fixed”. If it wasn’t broken, then how could I fix it?

Today I had a user get on my case about me blaming others for bugs in ReceiptWallet. There are basically only 2 cases where I do this. The first is a bug where if “write metadata to PDFs” is turned on, sometimes PDFs will become corrupt. This one is quite easy to blame Apple. I’ve had users send me the original documents in question, I opened them in Preview (an application that Apple wrote), showed the Inspector, added some keywords, saved the document and then re-opened it. The result was that the document was corrupt. Recently I had a user report a very odd behavior in which the document didn’t look corrupt, but when he tried to copy information out of it, the copied text was garbage. Sure enough, I did the above steps in Preview and demonstrated the problem. Sure sounds like an Apple bug to me; I’ve reported this to Apple a few times and have seen it fixed in the next OS release. Unfortunately it keeps coming back; what that means to me is that Apple’s CoreGraphics routines for handling PDFs are not tolerant enough. Some random program implements PDF writing and then Apple has to handle it; so while I blame Apple, maybe I should blame the original PDF writing application. That, of course, would be fruitless as there are far too many of them out there. If Apple could work on their PDF handling, this issue might go ago. In any case, turning off “write metadata to PDFs” works around this bug. (I love this feature as it lets my wife enter receipts, email me the archive, and then I can just import them into ReceiptWallet with all the information intact.) This issue is clearly not an issue with ReceiptWallet except for the fact that ReceiptWallet has this option.

The second issue has to do with me blaming scanner vendors for their poor quality drivers. Anyone that has had a scanner on the Mac for any length of time knows how crappy the drivers are. I finally had my father acknowledge this after he fought with the HP drivers for the longest time (I wrote about this last August when the scanner driver reported that it used 16815 bits per pixel which means it had a ton of color information!). These drivers are typically ports from Mac OS 9; some of the UIs still look like OS 9. I see com.epson in crash log all the time; anyone that reads crash logs knows that this is in the bundle that ReceiptWallet has to load in order to run the scanner. In addition, I’ve lately seen crashes when ReceiptWallet quits.

Thread 0 Crashed:
0   libobjc.A.dylib               	0x905eb688 objc_msgSend + 24
1   com.apple.CoreFoundation      	0x93f9f372 CFBundleGetIdentifier + 50
2   com.apple.CoreFoundation      	0x93fa2dc5 __CFBundleDeallocate + 53
3   com.apple.CoreFoundation      	0x93fff768 _CFRelease + 216
4   ???                           	0x00fc5340 0 + 16536384
5   dyld                          	0x8fe13083 ImageLoaderMachO::doTermination(ImageLoader::LinkContext const

After some investigation and looking at Console logs for the users having this problem, there is clearly a message in it saying that the EPSON plugin is releasing its bundle identifier when it should not be and that the user should report this to the plugin vendor. Who should I blame in this case?

The only scanners I recommend are the Fujitsu ScanSnap and the Pentax DSMobile 600. The ScanSnap series don’t use TWAIN drivers so they can’t blow up ReceiptWallet and the Pentax DSMobile has incredibily well put together drivers. My guess is that they didn’t start from legacy code. I’ve also had an engineer at a major scanner vendor acknowledge that their drivers are pretty poor, but unfortunately it will take time to fix. (Of course, I can’t tell you which vendor.) I’d love for scanner vendors to either fix their drivers or acknowledge that they are poorly written; however, most vendors bundle some of their own software and barely test the TWAIN interface (Pentax doesn’t bundle any Mac software, so they are totally dependent on TWAIN).

So while I’d love to be able to accept responsibility for these issues in ReceiptWallet and fix them, there is nothing I can do about it (I had one user suggest that I write scanner drivers for all the scanners…after I got up off the floor from rolling around laughing, I told the user that that was not going to happen).

ScreenSteps, cool idea, but not quite a Mac app

On Friday I stumbled across ScreenSteps, a program for doing documentation by quickly and easily capturing screen shots. While I no longer do documentation for my own software, I am starting to do some internal documentation for work on things like connecting to our VPN, setting up connecting to a file server, etc. I put together one “lesson” in maybe 15 minutes and was able to stick it on our internal web site. One thing that bothered me was that there were some dialogs that didn’t look like Mac dialogs like the following (The icon looks funny and it should have been a sheet):

  09-02-15 140924.png

Things like this usually indicate it was written in REALbasic. While I don’t have anything against REALbasic itself, I have problems with people slapping together programs in REALbasic and passing them off as Mac applications; in most cases they work like Mac applications, but they seem unpolished. I realize that this is a generalization, but I haven’t seem a REALBasic based program that I’d purchase (at least knowingly). ScreenSteps didn’t have the REALbasic libraries buried in its app bundle, so I knew it wasn’t built using REALbasic. So did the developers purposely create crappy looking buttons? I don’t think so. They appear to release the Mac and Windows versions at the same time, so they must be using some type of cross platform library. Ah, the about box gives me a clue. They’re using a system called Runtime Revolution. Uggh, another attempt at creating cross platform applications with the click of a button.

So the question boils down to, can I live with the sort of Mac like appearance to quickly build documentation or can I find another tool? I’m not sure, but I’m definitely not a fan of cross platform tools as they produce apps that just aren’t up to Mac UI guidelines.