{"id":93274,"date":"2016-04-08T07:00:00","date_gmt":"2016-04-08T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=93274"},"modified":"2019-03-13T11:01:46","modified_gmt":"2019-03-13T18:01:46","slug":"20160408-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20160408-00\/?p=93274","title":{"rendered":"Why does FindExecutable behave erratically for files with extensions longer than three characters? (And what can you do about it?)"},"content":{"rendered":"

The Find­Executable<\/code> function looks up the executable responsible for launching a particular file. This is a dubious undertaking, because it assumes that the thing that launches a file is an executable. There are other things capable of launching a file, such as a DDE command<\/a>, a context menu shell extension<\/a>, or a custom drop target<\/a>. What should Find­Executable<\/code> return in those cases? <\/p>\n

Okay, so if Find­Executable<\/code> is based upon a flawed assumption, why does it even exist? <\/p>\n

Because at the time it was originally introduced, the assumption was valid. <\/p>\n

The Find­Executable<\/code> function comes from 16-bit Windows, and back in those days, there were no context menu shell extensions or custom drop targets. (There was DDE, but that’s okay, because programs still have to register an executable to be used in the fallback case when nobody responds to the DDE message.) <\/p>\n

In the port to 32-bit Windows, the Find­Executable<\/code> function remains, but it works only in the case where files were registered in the 16-bit way; that is, with a command line executable. It so happens that most file types are still registered that way, so the Find­Executable<\/code> function basically still works. <\/p>\n

Since the Find­Executable<\/code> function is basically a throwback to 16-bit Windows, there is another attempt to accommodate the 16-bit world that is not as obvious: The Find­Executable<\/code> function takes the thing you pass and converts it into a short file name before trying to look up the handler. <\/p>\n

The effect of the conversion to a short file name depends on a bunch of things. <\/p>\n

If the volume does not have short file name autogeneration enabled, then the conversion to a short file name has no effect. But if the volume does have short file name autogeneration enabled, then the net effect is that the extension gets truncated to three characters. foo.abcde<\/code> becomes foo~1.abc<\/code>. And then Find­Executable<\/code> looks up and returns the handler for the .abc<\/code> extension instead of the .abcde<\/code> extension. <\/p>\n

Back in the days before long file names, all file extensions were truncated to 3 characters. if you asked for foo.abcde<\/code>, you got foo.abc<\/code><\/a>. The Find­Executable<\/code> function tries to maintain this compatibility with older applications. Newer applications shouldn’t be using Find­Executable<\/code> anyway, seeing as the handler for a file type may not even be an executable. <\/p>\n

I accept that the concept of finding the executable associated with a file is flawed in the face of handlers that do not take the form of an executable, but I still want to get the executable associated with a file, if possible, with the understanding that the answer may be incorrect.<\/b> <\/p>\n

You can use the Assoc­Query­String<\/code> function to get the executable associated with the default verb of a file extension, if one exists. <\/p>\n

\nHRESULT FindExecutableAssociatedWithFileExtension(\n    _In_ PCWSTR extension,\n    _Out_ PWSTR resultBuffer,\n    _In_ DWORD bufferLength)\n{\n return AssocQueryString(ASSOCF_INIT_INGORENUNKNOWN,\n                         ASSOCSTR_EXECUTABLE,\n                         fullPath,\n                         nullptr,\n                         resultBuffer,\n                         &bufferLength);\n}\n<\/pre>\n
The ASSOCF_INIT_UNKNOWN<\/code> flag says that if the file extension has no handler, don’t return the “Open unknown file” handler. <\/p>\n
This is not exactly the same as Find­Executable<\/code> because that function has special-case code for when you pass in, for example, excel.exe<\/code>. In those cases, the Find­Executable<\/code> function just returns the file itself, since executables are their own handlers. <\/p>\n
The ASSOCF_INIT_UNKNOWN<\/code> flag was added in Windows 7. What do you do for older versions of Windows? Well, you’re in luck. Older versions of Windows didn’t have the “Open unknown file” handler, so if there is no registered handler, the call will simply fail. (Indeed, the introduction of the “Open unknown file” handler is what most likely prompted the creation of the ASSOCF_INIT_UNKNOWN<\/code> flag in the first place.) As a second mark of good fortune, the flag is ignored by older versions of Windows, so you can go ahead and pass the flag unconditionally: On versions of Windows that support it, it does what you want. And on versions of Windows that don’t support it, they already behave the way you want by default. <\/p>\n","protected":false},"excerpt":{"rendered":"
Short file names strike again.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-93274","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Short file names strike again.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/93274","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=93274"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/93274\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=93274"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=93274"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=93274"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}