How can I specify icons for my app to use on the Start menu in high contrast mode?
A customer noticed that when the system was in a high contrast mode, some icons on the Start menu turned monochrome, whereas others retained their full colors. They wanted to know how they could get the Start menu to switch to a monochrome icon for their app when the system was in a high contrast mode.
The customer said that their program is a classic Win32 program, so its icon is declared in their .rc file. They also noticed that the apps whose Start menu icons went monochrome in high contrast mode were all UWP apps. Maybe that was a factor?
Indeed, that was a factor.
Custom icons for high contrast mode require an application manifest. Use the “contrast” qualifier to name your high-contrast alternate form. Application manifests are required for UWP apps, which is why you see it in wide use there. You can add a manifest to your classic Win32 apps, too, by putting it in an MSIX package.
Update: It’s also possible to attach an icon manifest to your unpackaged Win32 app.
Light
Dark
9 comments
Not being familiar with MSIX (and, frankly speaking, not willing to switch to yet another brand-new-X Windows feature that is expected to be abandoned within a few years) but after having googled MSDN a little, I wonder if something is available for applications that don’t need fancy installation features (or don’t really need installation, I mean, portable) and have to be compatible with older Windows versions.
I mean, if a user decides to add a Start menu shortcut to my tiny portable app, they deserve being able to have their high-contrast icon, not being punished for avoiding flashy useless but ”properly” packaged junk.
The packaged apps (MSIX) look like they will stay for a long time, but I see your point. Microsoft has many different “modern” UI frameworks (WinUI, WPF, Windows Forms, UWP, etc.), some of which are abandoned. They duplicate each other and the developers of the most popular Windows applications decided to stay away from this madness, so they still use Win32. Joel Spolsky has a good article on this (google for “How Microsoft lost the API war”)
Yep, I’ve read the article long ago. And, in fact, for me the main point is not the ”abandoned” part but the fact this brand new stuff hardly introduces anything new except being brand new itself. Well, sometimes is does so artificially, like when something gains limited availability with no technical reason, just to make people switch to the new stuff (’cause they wouldn’t otherwise). Not-only-MSDN-camp and not-only-MS problem though.
But what worries me the most is when simple, lightweight applications seem to be banned from useful features. That’s why I really asked about plain old Win32 alternative: in the hope this is not the case.
I think the issue here is that the shell is using PRI features to figure this out. In particular, it uses the contrast qualifier for contrast, and altform for the shell light and dark mode.
The .lnk format would probably need to be expanded. Maybe with the added ability to provide an icon path or even resource identifiers for icons that can be used in the different contrast modes. Even better would be an ability for the shell to look for a resources.pri or [executable.name.pri] that it would then use for the icons. Even if the resource names in the .pri file are fixed without a package manifest file.
Yeah, manifest. Manifest that manifests itself over other manifests when manifested in a manifestful way. Perfect manifisting (pun intended) for developers’ minds.
”Please, sir, may I have one-and-forever extensible way to manifest my manifestations in a bloat-free PE EXE, please?” Resources suit well, I’ve already achieved an agreement with myself that stupid XML is good enough no matter how poorly documented and overengineered it is. As far as I know from MSDN, there’re really only a few elements that are really useful for an average application, with over 50% of XMLish junk. Why not just extend these manifests’ capabilities?
Probably the new stuff gets abandoned because developers rightly see that it brings nothing new or useful and never adopt it. I don’t love win32/mfc but the API stability and the fact that you can rely on it to be around forever is a pretty huge feature that makes all the alternatives a lot less appealing. And often UWP apps just look like websites – why would I adopt a proprietary API to make a glorified website that’s tied to Windows machines? Projects like VScode suggest I’m not the only one who feels this way.
Looks like Win32 API was the last thing developed at Microsoft by engineers. After that managers, marketers and pythonists started growing stronger.
I think the magic word is `EXENAME.VisualElementsManifest.xml` — that’s how Office apps do it. I also remember there was (or maybe still is) a bug in Office installer that failed to refresh the last modified time of shortcuts to Office apps so that Start responds to the changes in `.VisualElementsManifest.xml`.
Also a shameless plug: https://geelaw.blog/entries/desktop-app-tile-colour/