Does anybody know off-hand if launching Explorer programmatically (using either ShellExecute or ShellExecuteEx) should fail to open a directory containing surrogate pairs?
Then ShellExecute succeeds and Explorer opens, but it just punts and opens My Documents.
If I try the above with any other existing path that does not contain surrogates (like “c:\test” or even “C:\コ㐂”) then the Explorer opens in the requested directory.
This occurs on both Win7 and Win8. Is this an expected limitation with surrogate pairs?
He's right, it doesn't find supplementary paths.
I doubt it is actually ShellExecuteW, for what it's worth.
Something to do with the verb syntax, or how NTFS indexes the files, or more likely the way Explorer searches them, maybe?
Depressing that even in Windows 8 such problems exist.
A good bug with surrogate pairs and supplementary caracters, in any case!
This sort of thing will become more and more annoying, since all those emoji are encoded in the supplementary zone. I'm sure people are already trying to use emoji to create folder names, and no, I'm not being facetious or sarcastic (for once).
Char in .NET makes it soooo easy to use Unicode transparently, while still getting supplementary characters wrong.
In Windows 7, the Folder class's 'open' command is delegated to an IExecuteCommand implementation, CLSID_ExecuteFolder, which is implemented in %SystemRoot%\system32\explorerframe.dll. The folder name is presumably passed through IExecuteCommand::SetParameters, though DelegateExecute is not well documented.
So the likelihood is that the parsing of surrogates goes wrong either in CLSID_ExecuteFolder, or in whatever IPC it uses to communicate with the running instance of Explorer. If navigating to the folder in Explorer itself works, I'd suspect the IPC. Unless, of course, ShellExecuteW isn't detecting that the item *is* a folder.