See my initial answer below.
This kind of wildcard is too simple.
Not true "file.exeandsomethingelse" does not match "*.exe". This pattern is correct, if you simply want to get "all file names ending with '.exe'". Did you try?
If the pattern was "*.exe*", then yes, "file.exeandsomethingelse" would match it. Don't mix up with sloppy liberal treatment of wildcards in Windows Search.
One note, just in case: in file system there is no such thing as "extension", not anymore. No it is exactly line in Unix. Dot inside name is treated as any other character (it is not put next to directory separator). (Don't mix it up with Shell "extension", which is still used in registered "file types".)
Unfortunately, Halabella and Nishant were right, and I was wrong — my apologies.
The vote of "1" for my answer was quite correct.
I just tested it and found it works like Microsoft documented:
When using the asterisk wildcard character in a searchPattern, such as "*.txt", the matching behavior when the extension is exactly three characters long is different than when the extension is more or less than three characters long. A searchPattern with a file extension of exactly three characters returns files having an extension of three or more characters, where the first three characters match the file extension specified in the searchPattern. A searchPattern with a file extension of one, two, or more than three characters returns only files having extensions of exactly that length that match the file extension specified in the searchPattern. When using the question mark wildcard character, this method returns only files that match the specified file extension. For example, given two files, "file1.txt" and "file1.txtother", in a directory, a search pattern of "file?.txt" returns just the first file, while a search pattern of "file*.txt" returns both files.
The following list shows the behavior of different lengths for the searchPattern parameter:
"*.abc" returns files having an extension of .abc, .abcd, .abcde, .abcdef, and so on.
"*.abcd" returns only files having an extension of .abcd.
"*.abcde" returns only files having an extension of .abcde.
"*.abcdef" returns only files having an extension of .abcdef.
Below, this strange behavior gets some explanation:
Because this method checks against file names with both the 8.3 file name format and the long file name format, a search pattern similar to "*1*.txt" may return unexpected file names. For example, using a search pattern of "*1*.txt" returns "longfilename.txt" because the equivalent 8.3 file name format is "LONGFI~1.TXT".
What we have here I would call an epic fail of Microsoft, it renders this API not really usable if we need reasonable masking behavior. It needs work around.
This looks like one of the "this is not a bug, this is a feature" cases.
I must say, in all shells I used masking works as I expected it.
Again, sorry for trouble caused by incorrect Answer.
See also: added
in my other answer.