| Date: | November 18, 2004 / year-entry #397 |
| Tags: | history |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20041118-00/?p=37263 |
| Comments: | 26 |
| Summary: | If you have both a folder named, say, C:\Folder and a program named C:\Folder.exe and you type C:\Folder into the Start.Run dialog, you get the program and not the folder. Why is that? Because it is common to have D:\Setup.exe D:\Setup\... where there is a setup program in the root, as well as a setup... |
If you have both a folder named, say, Why is that? Because it is common to have D:\Setup.exe D:\Setup\... where there is a setup program in the root, as well as a setup folder containing files needed by the setup program. Before Windows 95, you couldn't open a folder by typing its name. (If you wanted to view it in File Manager, you had to run File Manager explicitly.) As a result, programs written for earlier versions of Windows would have instructions like
Since there was no such thing as "opening a folder", the only option was to run the program Windows 95 was required to prefer the program over the folder in order that those instructions would remain valid (substituting the Start button for the File menu). And each version of Windows that prefers the program over the folder creates an environment wherein people who write setup programs rely on that preference, thereby securing this behavior for the next version of Windows. But what if you really want to open the folder? Append a backslash to force the path to be interpreted as a folder ( |
Comments (26)
Comments are closed. |
Indeed. I remember on Windows 95 I would often try to run c:windowscommand to get the directory full of DOS command programs but it would actually run c:windowscommand.com.
Thankfully, in NT-based Windows command.com lives in the system32 directory so this conflict doesn’t exist.
Pardon my stupid question, are the stuffs under "HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun" executed under the shell context? Reason I ask is it seems to have a different priority to what you outlined above. For example, you have a folder called "C:Program FilesFooAppFoo" and another folder called "C:Program FilesFooAppFoo Bar" and then on RUN key you put something like "C:Program FilesFooAppFoo BarBlah.exe" but without quoting it. I know that this becomes ambiguous because of the space, and quoting it will solve the ambiguity. But if I run that cmd-line from Start.Run without quoting it, it will execute Blah.exe. However, when Windows starts and executes the RUN key, "C:Program FilesFooAppFoo" folder will be opened instead. Please shed me some light in this matter, thanks.
Why should the two behave the same? One is an end-user control and the other is a programmatic interface.
Then what is the preference of "programmatic interface"?
I’ll take this up as a future topic. In the future, please put topic suggestions in the suggestion box instead of hijacking another comment thread.
You’ve got to wonder, if Microsoft were faced with this decision today would they still give preference to the file over the folder? I think, given all the security concerns nowadays, they would take go the safer route and give preference to the folder.
Why was the decision made to automagically append the .exe ?
The decision to run c:folder.exe instead of c:folder when the user types C:folder into start->run seems a bit weird to me, since there is no executable with the name c:folder (it’s called c:folder.exe), but there IS a directory with that name. If I was a user with no prior experience with Win32 I would not expect that behaviour.
It’s very common to not require users to type in full command names, to give them less typing to do. If you want to run it, it must be a program, therefore it’s probably called ‘.exe’ so it gets added. Hence the original instructions in the example being ‘a:setup’ to run the setup.exe program.
"If I was a user with no prior experience with Win32 I would not expect that behaviour."
Actually yes you would. If you were a user with no prior experience of windows you wouldn’t have found and turned off the feature of explorer that hides the extension of known file types, and hence you would never know the setup program was really named "setup.exe" rather than simply "setup"
The two (end user control and programmatic interface) should behave the same because the people who program to the programmatic interface are users too, probably before they were programmers.
Moi:
This way lies all the problems that lead to a number of confusions and compatibility shims.
The End User interface is for ease of use. Any ambiguity can be addressed by the user when they use it. This is not often just a thin interface over the API.
The programmatic interface is for clear and non-ambiguous invocation of operations (as the programmer is not there at run-time to correct any confusion). That is the reason there is (or at least should be) a clear published interface of what should be used and how it behaves.
The difference is that the target audience for the first is users and power users, and the second is programmers. As a Mort I fall somewhat between these but if I want some of the friendlier behaviour I have to program it myself (or find someone else who has already done it); just as the end user interface programmers did.
Another seeming discrepancy. If I leave off the path, and just type the exe (or folder) name into Start->Run, the FOLDER takes precedence over the exe.
For example, normally if you type "mmc" into Start->Run, up will come mmc.exe. But if you create a folder named MMC within HOMESHARE (or HOMEDRIVE?) and try again, up will come that folder…
Dhericean> The programmatic interface is for clear and non-ambiguous invocation of operations
So is the UI. You would prefer that it is ambiguous?
That aside, clearly there is already an ambiguity since the two are different.
>the target audience for the first is users and power users, and the second is programmers
Programmers are users. Should they read the documentation? Certainly, however the fact is that much documentation is not clear, and you can’t blame them for falling back on their knowledge of the UI when they see a function which appears to offer the same functionality.
Kevin: That has nothing to do with folder/exe priority. That’s search path priority. The folder/exe rule is a tiebreaker, not the primary rule.
"Indeed. I remember on Windows 95 I would often try to run c:windowscommand to get the directory full of DOS command programs but it would actually run c:windowscommand.com.
Thankfully, in NT-based Windows command.com lives in the system32 directory so this conflict doesn’t exist."
In a question to Raymond, that’s only relevent because of this comment – who on earth decided that the "Prevent access to the command prompt" policy in group policy would only prevent access to cmd.exe and not …system32command.com??
It makes that policy setting only a smidgeon of useless! Surely, despite command.com’s DOS heritage and legacy scripts, command.com could have respected that policy.
(I considered correcting grammar and spelling in the above post after I hit submit, but hope Raymond will answer despite it given it’s my birthday)
(… despite those …)
Please post off-topic questions to the suggestion box instead of hijacking a thread.
You didn’t have a topic for my birthday and the suggestion box seems buried approx 50 links in
buried? It’s there on the left hand side under "Links". Click on "Suggestion box".
It’s (the box is) exactly link number 48 (I hope).
It just seems it should be higher if you want people going there instead of your very attractive content and comments (surely people are likely to get attracted to that well before link 48!)
My question before was even more related to the most recent comments, given the facilitating comment I quoted.
I’ll shut up now for the sake of freeing innocent hostages from this thread hijack.
I can’t do anything about that – .Text puts the archive links in front of the custom links.
Sorry Raymond, if you consider this comment as hijacking thread.
Dhericean > The End User interface is for ease of use. Any ambiguity can be addressed by the user when they use it.
Since when the user knows how to resolve ambiguity? Aren’t you expecting too much from your user?
What’s interesting:
What Raymond tell us here applies only to the Run-Dialog.
I have my taskbar configured to constantly display the address line (I use that for quick access to deeply nested folders and stuff. It’s even faster than Windows-R)
In this address-bar, folders take precedence over same-named .EXE’s.
Philip