In short, do not expect this function to work like the command interpreter Cmd.exe. This function does not handle many boundary conditions, nor does it properly handle empty extensions.
The simplest example is this command, which correctly finds the Windows directory on all versions of Windows and MS-DOS 6.x:
dir c:\windows.* However, this API call returns false on Vista:
BOOL b = ::PathMatchSpec("C:\\Windows", "C:\\Windows.*"); Other inconsistencies are shown in the table below. The "right" answer to these scenarios is unclear because MS-DOS did not support long filenames or spaces in filenames. Although various versions of Windows are themselves inconsistent, PathMatchSpec() does not agree with any of them. I would argue that the correct behavior is what Windows Vista does.
| Command | ::PathMatchSpec("C:\\Windows", xxx); | MS-DOS | Win 9x | Win NT |
|---|---|---|---|---|
| dir c:\windows.* | False | Displays directory name | Displays directory name | Displays directory name |
| dir c:\windows. | False | Displays directory contents | Displays directory contents | Displays directory contents |
| dir c:\windows... | False | Displays directory name | Displays directory contents | Fail |
| dir "c:\windows " (Note the trailing space) | False | n/a | Displays directory contents | Fail |
| dir "c:\windows ." (Note the trailing space followed by a period.) | False | n/a | Displays directory contents | Fail |
And yes, I did actually install MS-DOS to create this chart :-)
Hello
ReplyDeleteI don't understand what is your purpose to find with the strange syntax "c:\windows.*" ?
But surely you are doing something with the API that it is not made for.
As the description says and as the examples show this API checks if asterisk characters match letters in the other string.
I suppose for nothing else it can be used.
The point is that PathMatchSpec() doesn't work properly with an empty extension. The fact that it's the Windows directory in particular is uninteresting. The Windows directory is just a typical example of a path that has no extension. It exists on almost all users' computers, so it's a good sample.
ReplyDeleteI think you misunderstand how wildcard matching works. Matching an empty extension is a perfectly reasonable thing to do.
Definitely a matter of interpretation: the dot character is not a wildcard, and there is no dot in "C:\Windows", thus the function works perfectly :-) Trailing spaces are not allowed on Windows file systems, neither trailing dots so most of your input strings are just plain invalid. The only reasonable one is if the pattern "xxx.*" should match a file named 'xxx" without extension and here PathMatchSpec differs from MS-DOS, apparently.
ReplyDeleteAnonymous,
ReplyDeleteI'm really not sure what your point is. My article said that there were inconsistencies. There is no interpretation of "inconsistencies." They either yield identical results, or they don't. Nowhere did I express an opinion of what was right or wrong.
You are simply incorrect about "no dot in C:\Windows". Windows is not Unix/Linux. The period *always* exists, even if it's not stated. This is a convention that goes back to the very early days of DOS.