by Michael S. Kaplan, published on 2009/10/26 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2009/10/26/9912727.aspx
The question from Jim was:
I am troubleshooting an issue with Vista SP2 where the common dialogs seem to be failing – Notepad – File/Open gives:
“Not enough memory available to complete this operation. Quit one or more applications to increase available memory, and then try again.”
Wordpad and other apps just never bring up the browse dialog box and seem to fail silently. It makes it hard to troubleshoot since their email cant attach any files to send me data.Is this likely a 3rd party shell extension? Any other ideas?
Thanks,
Jim
My initial thoughts when I first saw the issue, days into it, were almost Darth Vader like, since I felt something that I had not felt since... etc., you get the picture.
The problem was tracked down to a bad file in the image: a bad comdlg32.dll.mui.
This trackdown was hella complicated and took a bunch if people trying a bunch of different tools.
And then all the pieces fell into place, as I remembered my Random irreverent thoughts about the Ultimate Fallback, which points to Mark Russinovich's The Case of the Notepad that Wouldn't Run.
This new bug was just a recycled version of that same old one, the one that Erik has told me point blank and period is by design, because English is just another language.
But in this world we live within, this world where Microsoft is a company in Redmond, WA, in the USA, trying to proclaim English as being just another language seems a little naive, doesn't it?
I mean, in this world where the fact that the region and the language of just about everything we produce will bear the indelible mark of its main source, this policy's real impact is just to add a few more English bugs to the mix -- bugs like the one Jim reported.
Bugs where the [almost] never used, [almost] never tested code paths of core resource failures are tested, so the veritable world of responses in code are unleashed upon an unsuspecting populace for the occasional random scare like this one, where even the bug reporting tools (tools which encourage attachments) can be stymied just like they were here.
Where not everyone hads all of knowledge and of the tools we have here, either.
It all makes me wonder once again whether the DEVDIV solution that would have some ultimate fallback there isn't just a smidge better.
Well, what do you think?
John Cowan on 26 Oct 2009 11:21 AM:
The IETF has a concept of "Default Language" (language tag "i-default"), which is documented by RFC 2277. The relevant paragraphs of Section 4.5 are:
When human-readable text must be presented in a context where the sender has no knowledge of the recipient's language preferences (such as login failures or E-mailed warnings, or prior to language negotiation), text SHOULD be presented in Default Language.
Default Language is assigned the tag "i-default" according to the procedures of RFC 1766. It is not a specific language, but rather identifies the condition where the language preferences of the user cannot be established.
Messages in Default Language MUST be understandable by an English- speaking person, since English is the language which, worldwide, the greatest number of people will be able to get adequate help in interpreting when working with computers.
Note that negotiating English is NOT the same as Default Language; Default Language is an emergency measure in otherwise unmanageable situations.
In many cases, using only English text is reasonable; in some cases, the English text may be augmented by text in other languages.
(end quote)
It seems to me that i-default text should be as much as possible in simplified English that will not confuse non-native speakers, though the RFC does not say so. In this case, the application could perhaps embed just enough of an i-default resource to report that it can't run without a proper MUI file.