A site devoted to discussing techniques that promote quality and ethical practices in software development.

Sunday, August 15, 2010

GPG3Win 2.0.4 Windows Explorer Context menu still fails to work

This is my pet project to see how long it takes Gpg4Win to produce a Windows Explorer context menu that is capable to encrypt and decrypt files.

My test environment is XP Pro SP3 (English Windows) with HK SAR as the language setting for non-Unicode Programs. Gpg4Win's explorer context menu fails to encrypt and decrypt a file producing the following familiar dreaded message box:

To get this feature working one has to change the "Language for non-Unicode program" is set to English. This is an unnecessary demand clearly indicating a lack of Internationalization Programming prowess. It presents great inconvenience to non-English speaking Windows users. Sad to see this bug still lingering on for so long.

It is another case of using 'It-works-here' development methodology.

2 comments:

Szechuan Sage said...

Leon, I don't know how much of this issue is because of the "it works here" mind-set as you mentioned, or a failure to step back a little and consider the bigger picture. I think it is a little of both.

L. Mar said...

Well, I normally do not comment on comments submitted but I would like to make an exception this time as it is of vital importance and central to the theme of this blog.

From the tone of the comment from Szechuan, it is a storm in the tea cup. But in reality, it is a reflection on an unpolished development.

You can't just say to your user, just leave that setting in English if it is not! It shows a legacy that is rooted in Win9x's days. If it has been developed correctly embracing the I18N programming technique, such a programming bug will not come up. Trust me, I have been programming Internationalized Windows programs for years - since Win3.x.

Normally, programs using Unicode API calls will not suffer from this bug. Legacy program using MBCS (Multibytes Character Set) API normally suffers from this problem.

If the user shifts the language setting to English to get just Gpg4Win to work, then their other favourite legacy programs will break. I believe Gpg4Win does not contain an clear warning to their users during installation of such a requirement.

I know Gpg4Win is largely a Unix style program that runs in Windows but it needs not fail like this. Look at Thunderbird, Opera, BOUML, & Firefox, they are cross platform programs without this kind of bugs.

If I have not stepped back to consider "the bigger picture", I would like to know what that's? When the developers put up a features it should be tested properly and not just 'it-works-here' on my Windows with the default setting of English in Language for non-Unicode programs.

This will not be the last I will comment on Gpg4Win in this regard and I will give credit where credit is due.

Please feel assure that I am not picking on Gpg4Win and I can tell you many commercial programs suffer from this issue. I had had the displeasure of involvement with companies that ill treated their customers with this kind of problems.

The difference is that poor users of ill-written commercial products often are told to use it regardless and suffer from the problem while paying for the buggy software. At least users of Gpg4Win does not pay for the problem.

Companies inflict this kind of problem on their users because 1) they are in a winning situation that can inflict this onto the users, 2) they have a lock in advantage that is extremely costly for their poor customers to leave, and 3) their management living in the past.

Blog Archive