When programs assume that the system will never change, episode 4: Stealing strings

Raymond Chen

A customer had a program that automated a workflow, and one of the steps was to run a console program that came with Windows, and that console program printed a confirmation prompt “Are you sure (Y/N)?“. They wanted to programmatically say Yes, but since the customer had employees around the world, they couldn’t hard code the letter Y into their program. (For example, in German, it would be J/N instead of Y/N.) They also realized that the characters for affirmative and negative replies were stored in resources in the executable, so instead of having a big table of affirmative and negative replies for each language, they could load those strings from the executable and use them to answer the questions. They wanted to know if this is acceptable and supported.

No, it’s neither supported nor acceptable.

Unless documented otherwise, resource strings are considered implementation details of the program. Absent any promises to the contrary, Windows reserves the right to change any resource string, or to move them to another location.

Indeed, one of my colleagues gave an example of how this actually happened in recent memory.

The translation team received a bug report that one of the programs had mistranslated “Y/N”. They fixed the translation, but since the fix was going out in a servicing release, they couldn’t change the existing incorrect string because that would invalidate Language Interface Packs. Instead, they had to abandon the old string and create a new one. All the languages would then translate the new string to Yes and No, which would just be copied from the existing translation, except for the language that had an incorrect translation, in which case it would be re-translated, but correctly this time. The program would switch to using the new better-translated string for determining whether the user responded in the affirmative or negative, and the old string would become orphaned, waiting to be cleaned up at the next major release.

If the customer had been extracting strings directly from the binary, they would continue extracting the yes/no string from its old location, even though the program was using the string in its new location.

The customer should provide appropriate affirmative and negative answers, or even better, avoid having to answer the question at all. I forget which program it was, but maybe it had a /F or /Q option to suppress the confirmation prompt. Even better would to avoid the console program at all and access the underlying functionality in a programmatic way. (For example, use Copy-Item or CopyFile instead of xcopy.exe; or use Set-ItemProperty or RegSetValueEx instead of reg.exe.

Author

Raymond Chen

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.