by Michael S. Kaplan, published on 2011/02/10 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/02/10/10126601.aspx
There are situations where a design decision made by Windows can cause a problem that some may reasonably consider to be a bug while the team owning the functionality might resolve the issue as by design.
Interestingly, neither is technically right in many of these cases. Not if an honest assessment is made of the intent of the product and the described behavior.
The problem may be caused by a design flaw.
The fact that the owning team decides it is by design in this case means that it is a desugn flaw that is not going to be addressed.
I'll give a couple of examples of this pattern to make it clearer....
You may remember my If you had gotten there first, you might have staked your claim too! blog, where I explained how the first language installed with a copy of Windows has special privileges in terms of the language of the directory names, the langauge of account names like the Administrator account, and so on.
Now if you have other languages installed via various Lanuage Packs, then you may install a Language Pack which, had it been installed first, might have called the Administrator account Administrateur. But now, since you installed English first, it will be named Administrator and it won't change.
However, documentation that discusses the Administrator account that you may look up in help will follow the default user interface language currently set.
And it will talk about Administrateur.
This is the design flaw that I described in Administrator vs. Administrateur, et. al..
Could it be fixed? Sure it could. By a complicated help authoring scheme that did the actual account name lookup based on wel known SIDs and RIDs and inserted that name into the help content, this problem where help content refers to things that are not actually true in a reasonable MUI scenario would be solved.
As a bonus, it would fix cases where the account is renamed, as well. Which might be interesting.
But the latter could have security consequences and really all that work is just generally rejected as too much effort for too little gain.
And although the documentation could in theory be edited to try to cover this case, it is a widespread issue that would almost certainly make everything ovwer-complicated and confusing.
So everything is left as is, and this design flaw is considered by design.
Even though any reasonable person looking at documentation that looks wrong will consider it a bug.
See? :-)
I'll give you another example....
say you are on another language version of Windows. Let's say the Italian version of Windows 7. On a machine you deceided to name italianmachine just for simplicity.
The "C:\Program Files" directory will actually be "C:\Programmi" on this Italian installation.
Now if you are like me, the machine next to this Italian one might actually be Brazilian Portguese copy of Windows 7.
And on that machinethe "C:\Program Files" directory will actually be "C:\Arquivos de Programas".
If you used the UNC path to look at this remote path, it will not be "\\brazilianmachine\C$\Arquivos de Programas".
It will be "\\brazilianmachine\C$\Programmi".
Yikes!
Just because you're on an Italian machine doesn't mean you expect the whole worled to be Italian, right?
But there is a good reason for this behavior.
The reason that happens is that if you look at the desktop.ini in that directory on that Brazilian machine, it will say:
[.ShellClassInfo]
LocalizedResourceName=@%SystemRoot%\system32\shell32.dll,-21781
and since the Italian copy of Windows you are running will have no problems resolving that path and finding that file, it will look up the directory name by loading that string on its own machine instead of the remote one. and of course it will get the Italian string....
Now perhaps if you are a developer you might be thinking about ways you could fix this problem. You could
for example. But is that a great plan for good performance? Is there hope that it would even be readable in all cases, as compared to just making it Italian?
In the end, this behavior which is easy to consider to be a bug and which the core team might consider to be by design is yet again a design flaw that is not worth the cost to address.
if you work for Microsoft, a more honest resolution for this kind of bug is Won't Fix, not By Design.
Or, if you are one of those users of Mac or Linux who hates Microsoft, you could (in both cases) just see it as pointing out that Microsoft software is buggy.... :-)
Mike on 10 Feb 2011 7:27 AM:
In my experience, what you just said seems to apply to almost every bug I've submitted to Microsoft.
Michael S. Kaplan on 10 Feb 2011 7:41 AM:
No, not really all bugs are like this -- many are actual bugs! Or perhaps you don't bother reporting *those* issues, since they seem simpler or something. :-)
htd on 10 Feb 2011 8:10 AM:
'as documented'
Michael S. Kaplan on 10 Feb 2011 8:30 AM:
In the first case the documentation is incorrect sometimes, and in the second case the issue in question is not documented at all (it is a side effect of the design). So I would definitely not consider it "as documented"....
John Cowan on 10 Feb 2011 8:48 AM:
I think the mistake was to localize the name of such a fundamental directory in the first place. I'm all for localization, but not all the way down to the bottom. Does the C: drive become the Г: or С: (i.e S) drive in Russian localization?
Michael S. Kaplan on 10 Feb 2011 8:53 AM:
Drive letters are not localized; the localizable dirs are a specific known and documented set.
And of course since we've been doing it for so long it is too late to rethink that without appearing broken to a lot more people.
Michael S. Kaplan on 10 Feb 2011 10:22 AM:
I suppose the entire architecture of localized drive names might be considered the original design flaw? :-)
Raymond Chen - MSFT on 12 Feb 2011 11:41 PM:
The magically morphing directory name is actually by design. The directory marked itself as "Program Files translated into the language the user prefers" and in this case, the visitor from a machine running the Italian UI prefers Italian. The Brazilian machine is a red herring. Consider the case where a visitor on an Italian machine sets his preferred language to German and visits the C:\Programmi directory. It's going to say "C:\Programme".
These desktop.ini files are sort of like that science fiction creature that looks like whatever the viewer wants it to look like.
Michael S. Kaplan on 13 Feb 2011 10:18 AM:
I suppose I cam buy that, though it is unexpected to many. Especially compared to other "remote machine" Shell scenarios, like the special icon on the main drive Windows is installed on. There usually seems to be something different about your installation of Windows (compared to some other that you browse to on another drive or another machine)....
Alex Cohn on 13 Feb 2011 11:40 AM:
It's worse than magically translating ditectory names. Somebody has right to create C:\Programmi on an English system, which will be hidden from the users who choose Italian UI.
Michael S. Kaplan on 13 Feb 2011 12:00 PM:
I'm not convinced it will be hidden -- in many such cases you will just see two directories with the same name!
Cheong on 13 Feb 2011 5:39 PM:
Possible. Consider the case when you have two folder with same name in your personal user desktop and the "All User" desktop. You'll see two folder with the same name there.
As long as the underlying filesystem knows they're different, it shouldn't really matter when they appear to have the same name in the eyes of user.