File Icon Association: How to distinguish between Executable and different File extensions?

[vaclav.pro]

Hello

I am having some issue persuading Total Commander (9.21a) to show proper icons for my specific file type.

I am developing application, with which there are 2 file extensions associated.
The application and both file extensions have each their own icon (so 3 different icons). Application has it's icon embedded in it, the file extensions have their icons associated in the registry.

The problem is, that Total Commander doesn't show the application icon just for application exe, but also for both associated file extensions, so I see only 1 type of icon instead of 3. Everywhere else in the Windows (10) it shows properly (desktop, Windows File Explorer, other applications and file browsers), but not in the Total Commander.

The following is a .reg file content for one of the file extensions

"""
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.cdf]

[HKEY_CLASSES_ROOT\.cdf\DefaultIcon]
@="\"C:\\Telight\\Q-PHASE\\bin\\gui\\cdfico.ico\""

[HKEY_CLASSES_ROOT\.cdf\shell]

[HKEY_CLASSES_ROOT\.cdf\shell\Open]

[HKEY_CLASSES_ROOT\.cdf\shell\Open\command]
@=hex(2):22,00,43,00,3a,00,5c,00,54,00,65,00,6c,00,69,00,67,00,68,00,74,00,5c,\
00,51,00,2d,00,50,00,48,00,41,00,53,00,45,00,5c,00,62,00,69,00,6e,00,5c,00,\
51,00,2d,00,50,00,48,00,41,00,53,00,45,00,2e,00,65,00,78,00,65,00,22,00,20,\
00,22,00,25,00,31,00,22,00,00,00

"""

Is there something missing or something wrong? As far as the Windows icon association, it seems to follow this manual: https://docs.microsoft.com/en-us/windows/win32/shell/how-to-assign-a-custom-icon-to-a-file-type

I'm guessing that Total Commander is using some sort of way to determine file icon, that doesn't understand my way of defining those icons.
Could you please explain, so that I can make the icon associations work in Total Commander as well?

Best regards,
Vaclav

[ghisler(Author)]

Normally you don't put the icon under the extension, but use something like this:

[HKEY_CLASSES_ROOT\.cdf]
@="cdf_file"

[HKEY_CLASSES_ROOT\cdf_file\DefaultIcon]
@="\"C:\\Telight\\Q-PHASE\\bin\\gui\\cdfico.ico\""

[vaclav.pro]

Hello and thank you for your fast response

Aha, OK, so you support only this way of doing it. Thank you, works nicely now

Maybe you can also think about supporting the other valid way of defining icons as well in the future?
Because both are described as valid in this Microsoft manual: https://docs.microsoft.com/en-us/windows/win32/shell/how-to-assign-a-custom-icon-to-a-file-type

The way you support now actually just creates a second registry key for the same file type, which for example in my case is rather redundant. I understand it makes sense when there are multiple file extensions to associate with a single type of icon (like sound file extensions). But in my case, when there's only one file extension associated to one icon, the way I had it before makes much more sense - perhaps that's why Windows supports both ways of definitions.

Either way my problem is solved now, so thank you very much for your help

[Usher]

[HKEY_CLASSES_ROOT\.cdf\DefaultIcon]
@="\"C:\\Telight\\Q-PHASE\\bin\\gui\\cdfico.ico\""

It's a legacy method, based on Windows 3.x entries, not recommended, kept only for compatibility reasons.

[vaclav.pro]

Can you quote some reliable source on the "not recommended"/"legacy" thing?

Because the article on Microsoft Devs I referenced in my previous post is from 2018 and doesn't mention anything about this approach not being recommended or being legacy. If you have a more recent or more reliable source that says otherwise, can you please share a link to that?

Thanks

[vaclav.pro]

And btw even if it was just legacy for backwards compatibility, as long as it is still accepted on Windows in the entire system, everywhere except Total Commander, I'd say Total Commander should probably accept this way of defining icons as well...

[NotNull]

There are a multiple of factors in play here.

• You defined the file association in the 64-bit part of the Windows registry.
  If you run 32-bit Total Commander, it is a gamble if it will read the icon info from the 64-bit registry
• You might be "bitten" by the Icon Cache. For reasons of speed, the configured icon settings are bypassed when that info is already in cache. Reboot your system to start fresh (Icon Cache is per-user, but still .. somehow requires a reboot)

FWIW: Just tested this with Total Commander 9.12 and 9.50 Beta7 (both x64):
9.50 *does* show the correct icon; 9.12 does not.
(Can't show you a screenshot; sorry ..)

Tested with this registry settings:

Code: Select all

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Classes\.dummy\DefaultIcon]
@="\"C:\\Windows\\System32\\cmd.exe\""

[HKEY_CURRENT_USER\Software\Classes\.dummy\shell\open\Command]
@="\"C:\\Windows\\notepad.exe\""

And after that, created a file "testing.dummy"

[Usher]

This method was designed to associate extension with a single program. It has the lowest priority level and can be overruled by newer methods. In practice it is used mostly by lame coders or programs which work only in Windows 95 compatibility mode.

However, if you insist on using this method, you should always restart TC after manual changing icons in registry.

BTW. Whatever online MS documentation you use you should not trust it. It may be silently updated and you cannot check what changes have been made. There is no changelog or History (well known from Wikipedia) to see. For example, the same thing may have different names depending on system version (system tray, system area, notification area), but MS claims it was always only one name.

[vaclav.pro]

You defined the file association in the 64-bit part of the Windows registry.
If you run 32-bit Total Commander, it is a gamble if it will read the icon info from the 64-bit registry

Yes, I run 32-bit Total Commander. Although I am a bit of a rookie in the Windows registry, so I have absolutely no idea how to tell apart the 32-bit and 64-bit part of the Windows registry?
Anyway after following the guideline described by Mr. Ghisler earlier in this thread, the 9.2 version of 32-bit Total Commander works the icons normally.

You might be "bitten" by the Icon Cache

Yes, this I have taken into account, the problem really wasn't solved by any amount of rebooting, until I used the approach described by Mr. Ghisler.

9.50 *does* show the correct icon; 9.12 does not.

I just tested, and both of the current version 9.50 (both 64-bit and 32-bit versions), with my original registry setup (see the first post in this thread) works fine with those versions (without using the approach by Mr. Ghisler). So it seems that my original registry setup will be now supported, which is absolutely amazing

lowest priority level and can be overruled by newer methods

Can you present some documentation on this? And what would the newer methods be?? Because the best thing I could google was the documentation I referenced before, that uses this ( https://docs.microsoft.com/en-us/windows/win32/shell/how-to-assign-a-custom-icon-to-a-file-type )

In practice it is used mostly by lame coders or programs which work only in Windows 95 compatibility mode.

OK, and what would the non-lame and modern approach be? And, again, is this just your opinion, or do you base this statement on some documentation or any other official information? Because otherwise for me it's just your opinion, and I thank you for sharing that, but it has no further value for me to use with our product application

always restart TC after manual changing icons in registry

Yes, thank you, I am aware of that As a Windows user, a restart of software or reboot of system are the first things I try

Whatever online MS documentation you use you should not trust it

Yeah, but you see I have no problem with Windows. If I did, I'd ask someone on Microsoft Support. The confusing bit for me was that Windows and everything else was working fine with my registry approach, but Total Commander not - although, as I mentioned above, it seems that current beta 9.50 works fine with just my original approach, both in 64 and 32 bit versions.
But yes, I know that getting some information from Microsoft can be a painful and often unsuccessful process. But if you have some more reliable source of information about windows registry and the file icon association, please share that with us or with me. I'll be happy to learn something better

[NotNull]

Windows has evolved over the years.
In the early days of Windows, the method you are using was the most common: if file extenstion X, start program Y with the file with extension X, using static verbs (and sometimes some DDE (Dynamic Data Exchange/OLE)

On modern Windows, there are a lot more possibilities, mostly about shell integration (shell extensions, drag/drop/dynamic, dynamic verbs, OLE and DDE were replaced by COM Objects).
Not all of those technologies are supported with the old method, so virtually every program now uses this new method (File extension > ProgID > configuration or AppID > ClassID > configuration)
(a bit simplified)

But if you have a simple, straightforward application without further shell integration, you can still use the method you are using now.
(Although personally, I would use the ProgID method to be feature- and future-safe)


In the meantime, Microsoft "discovered" that a lot of programs are "stealing" file associations (ever installed a second image viewer?). And some programs use it to deploy their malware ("associate ,gif with malware.exe").
To counter that, Windows now asks for the default program to start for extension .xyz.
The results are stored under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.xyz\UserChoice and can not be tampered with programmatically, thanks to a control hash value (*) (although I have discovered a method to circumvent this, but will not make it public for obvious reasons)
This new method overrules all the previous ones: whatever you configured under HKCR ... it will be ignored if a UserChoice has been set.
That's a nightmare for corporate deployments and software developers alike, but that's how it is..

Anyway: no official reliable source of information; just my years of experience and reading.

32-bit registry can be found under the WOW6432Node key, for example HKLM\Software\WOW6432Node


(*) Earlier versions of Windows (I think Win7...) didn't have this hash checksum.

[Usher]

2NotNull
Thanks for help. Short resume, in priority order:
1. Default icon defined directly for extension. Not recommended, ported from Windows 3.x, association with a single program only.
2. Default icon defined for filetype associated with extension. Recommended by 2ghisler(Author). Most popular, allows to change default program with a single registry change.
3. ClassID, obtrusive, used by shell extensions (reported as PITA for example after installing ACDSee image viewer).
4. UserChoice, PITA for all.

2vaclav.pro
Instead of docs:
https://www.google.com/search?q=microsoft+undocumented+features
https://www.google.com/search?q=microsoft+undocumented+options
Read and learn before asking (about) Microsoft again, please.

[Hacker]

vaclav.pro,

2vaclav.pro
Instead of docs:
https://www.google.com/search?q=microsoft+undocumented+features
https://www.google.com/search?q=microsoft+undocumented+options
Read and learn before asking (about) Microsoft again, please.

You are welcome to ask even before reading the 932 k and 891 k search results.

Roman

[vaclav.pro]

2NotNull and 2Usher
Thank you for the information, it's really helpful. If it's not documented, someones personal experience is the best source ever

2Hacker
Thank you