Windows – Launching a registered mime helper application


I used to be able to launch a locally installed helper application by registering a given mime-type in the Windows registry. This enabled me to allow users to be able to click once on a link to the current install of our internal browser application. This worked fine in Internet Explorer 5 (most of the time) and Firefox but now does not work in Internet Explorer 7.

The filename passed to my shell/open/command is not the full physical path to the downloaded install package. The path parameter I am handed by IE is

"C:\Document and Settings\chq-tomc\Local Settings\Temporary Internet Files\

This unfortunately does not resolve to the physical file when calling FileExists() or when attempting to create a TFileStream object.

The physical path is missing the Internet Explorer hidden caching sub-directory for Temporary Internet Files of "Content.IE5\ALBKHO3Q" whose absolute path would be expressed as

"C:\Document and Settings\chq-tomc\Local Settings\Temporary Internet Files\ 

Yes, the sub-directories are randomly generated by IE and that should not be a concern so long as IE passes the full path to my helper application, which it unfortunately is not doing.

Installation of the mime helper application is not a concern. It is installed/updated by a global login script for all 10,000+ users worldwide. The mime helper is only invoked when the user clicks on an internal web page with a link to an installation of our Desktop browser application. That install is served back with a mime-type of "application/x-expeditors". The registration of the ".expd" / "application/x-expeditors" mime-type looks like this.

"Content Type"="application/x-expeditors"




@="\"C:\\projects\\desktop2\\WebInstaller\\WebInstaller.exe\" \"%1\""

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MIME\Database\Content Type\application/x-expeditors]

I had considered enumerating all of a user's IE cache entries but I would be concerned with how long it may take to examine them all or that I may end up finding an older cache entry before the current entry I am looking for. However, the bracketed filename suffix "[n]" may be the unique key.

I have tried wininet method GetUrlCacheEntryInfo but that requires the URL, not the virtual path handed over by IE.

My hope is that there is a Shell function that given a virtual path will hand back the physical path.

Best Solution

I believe the sub-directories created by IE are randomly generated, so you won't be able guarantee that it will be named the same every time, and the problem I see with the registry method is that it only works when the file is still in the cache...emptying the cache would purge the file requiring yet another installation.

Would it not be better to install this helper into application data?