When programs assume that the system will never change, episode 1, redux
Back in episode 1, we learned about programs that grabbed undocumented resources from system files. Today’s case is similar, but the culprit is not a program that shipped to customers. Rather, it’s a customer who is using icons from the system in their own internal deployments.
The customer reported that at some point between Windows 7 and the current version of Windows, the icon they were using is no longer present, and the remaining icons were renumbered. As a result, the shortcuts they are deploying to their customers show up with the wrong icon.
That icon was removed in the normal course of product development. The scenarios that required the icon no longer existed, so the icon was removed.
I found it interesting that in the customer’s impact statement, they never acknowledged that they were doing something wrong in the first place. They cheerfully stated that they reached in and grabbed icons that were lying around in undocumented places, and explained that any change to those undocumented icons would result in a break in their workflow.
I advised that the customer should stop using undocumented icons from undocumented locations. If they want to deploy shortcuts with specific icons, they should deploy the icons as well. Figure out what icon they want for the shortcut, create a DLL with that icon, and deploy that DLL along with the shortcuts.
The customer liaison passed the suggestion along, with a gentle reminder that what they are doing was never supported.
The request to put all the undocumented icons back the way they were in Windows 7 was rejected. For one thing, putting them back would in turn break customers who had improperly relied on the icon positions as they were in earlier versions of Windows 10. In other words, given two sets of customers who both did the wrong improper thing, it’s impossible to make both sets of customers happy, since the two sets are relying on contradictory requirements.
Since it is known how many customers are unhappy by the way the icons are set up in Windows 10 (namely: one), but it is not known how many customers would be made unhappy if the icons were moved back to the way they were in Windows 7. We could be trading one happy customer for a dozen unhappy customers.
We elected to leave things as they were. The one unhappy customer was given instructions on how to achieve their goal in a supported way, and they’ll be happier about it anyway, because they can deploy their fix immediately, instead of having to wait for the update to be developed and deployed to all their systems.
Light
Dark
28 comments
I wonder if the customer would have had better results if they had used the icon resource numbers (encoded by -1,-2, etc.), but they probably built their shortcuts with the GUI, which can’t do that.
The thing that disappoints me most about the shortcut format is there’s no way to permanently embed an icon into it (with no backing store elsewhere).
Theoretically you could “embed” the icon as an NTFS alternate data stream, but I’m not sure if the shell would understand it (the UI won’t let you set an icon from an alternate data stream, but maybe you could hack it in).
Alternate streams? What sorcery is this?
People hunting for icons for their shortcuts evidently aren’t very tech-savvy (if they were, they could use an icon editor or library manager), so it’s not reasonable to expect them to understand and use alternate streams, which is, probably, the most hidden and less known feature of Windows.
Forked streams will not work in network shares or many other non-NTFS file systems.
That said, what libraries with icons included in Windows are the documented? I recall moricons.dll from Windows 3.1, which is still included with Windows 10, but I don’t know if it’s contractual or just a compatibility concession. Also, I remember when Windows Vista broke the icon ordering of shell32.dll. It was restored in Windows 7 (somewhat) and is kept unchanged up to Windows 10, but the fact that Vista broke it makes me guess that it never was contractual.
As Joshua says, it’s a pain being unable to permanently embed icons in shortcuts. It made sense back in 1995, when it was nice to fit a shortcut file in a single 512 byte sector, but things have changed a lot since then. True, you can build your own icon library, but few people know that it’s possible or even have the right tools to do it. Even extracting an icon from a library into an .ico file is black magic for most users.
It could be greatly mitigated if Windows included its own documented icon library with a set of useful icons. A good start would be a subset of shell32.dll and moricons.dll (removing the ones for vintage DOS applications). Just name it “icons.dll” and place it in the Windows directory, and users hunting around for icons will find it immediately.
I don’t think any of the icons are documented. App developers are expected to ship their own icons.
I don’t think the majority of use cases are going to be developers. It’s more of a system admin trick – pretty sure I’ve had to resort to it on occasion, though I don’t recall the details. (I suppose a simple example would be needing to provide users with a shortcut that points to a batch file, but not wanting it to have the scary-looking cmd.exe icon.)
I do note that Explorer’s shortcut editor defaults to offering you icons from shell32.dll if the target of the shortcut doesn’t have its own icons. I can see why people might expect these icons to be supported.
Right. I bet the customer of the case Raymond is talking about isn’t a programmer, but a sysadmin deploying shortcuts pointing to shared folders or scripts. I have been in those shoes: I write a quick batch file to make a backup of something important, place a shortcut to it into the desktop (with the default -and ugly- batch file icon), and then the customer tells me “give it a nice icon so I can see it easily”.
In fact, this was what I had in mind when I talked about not having icon management tools. Any desktop programmer has an icon editor in their toolset, but most sysadmins don’t. Even in my case: I’m a programmer, but when I’m at a customer’s site, sometimes I don’t have an icon editor at hand.
If you’re deploying an app to users’ desktops then you can also deploy a DLL or ICO file with your app. If you’re a sysadmin then you already have privileges to do this. A simple web search for the tools takes less time than filing a support ticket with Microsoft 😉 Spend 5 minutes downloading the software and re-writing the deployment script to include another file and you’re done. Bonus: the deployment works regardless of changes in the Windows internals.
Wouldn’t there be legal issues to copying a Windows icon into your own file for deployment in this way?
@Harry: See my comment below regarding EULA on Image Library that come with Visual Studio, contain static and some animated images used in resources of Windows and Office.
@cheong00: your comment below suggests that use of that icon library is restricted to programs developed in Visual Studio, so it is not likely to be useful in this scenario.
(But in any case just trying to figure that out is likely to take longer than we would want to spend, when pointing at a built-in icon in shell32.dll takes only seconds!)
@Harry Johnston: what need is there to use a Windows icon for a custom application? Yes, linking to a built-in icon takes seconds, but has been proven, the icon sets are not guaranteed to be the same in later Windows releases. Linking to an .ICO file or a .DLL with embedded icons is pretty certain to work.
@Mike, I don’t understand – where are we to get the icon to put in the .ico or .dll file if not from from Windows?
Are you imagining that we would design a brand new icon ourselves? That really doesn’t sound like an appealing choice. (As it happens, I did actually design an icon once – on my own time, of course, since it would hardly be an appropriate work activity for me – and it took ages. It was also really really ugly.)
Harry, a simple web search for “icons free” will turn up sources of unencumbered icons.
Another option is to convert an image to the .ico format using an image editor. Several popular tools support saving files to the ICO format.
A third option is yes to create a new one in a an icon editor tool.
If none of those options are satisfactory and you choose to rummage around in the undocumented icon libraries, then don’t be surprised if things break in a new version of Windows.
So many people grab from shell32.dll I’m not surprised it broke. Driving force: I want to match the system theme when it updates when grabbing an icon for system functionality.
Some of the ancient documents gave resource numbers of icons in a few of the older dlls, but I don’t think shell32.dll was one of them. Other dlls expected to be hazardous: progman.exe (I think it still exists only for its icons), pifmgr.dll, moricons.dll.
Removing minesweeper broke a few things, but we shouldn’t be surprised. It was an optional component anyway and nobody should have been depending on it.
EDIT: I found the actual offender. Windows 95 GUI is asserting that the icon order of shell32.dll and pifmgr.dll are frozen and can’t change. So if you copied shortcuts forward from version to version their icons would break if the order ever changed.
Comctl32 has a contractual set of toolbar images but no icons. For loading at run-time you can use the stock icon API on Vista+ but you can’t really use them in shortcuts because the icon could move on Windows upgrades.
> True, you can build your own icon library, but few people know that it’s possible or even have the right tools to do it. Even extracting an icon from a library into an .ico file is black magic for most users.
Is it? I’ve done that on Turbo Pascal for Windows and that’s Win3.1 days. I thought it’s really a basic skill for Windows developers.
Btw, I’ll also add the Visual Studio installations do come with zipped image library for most icons embedded in Windows and Office, so they’re free to mix and match to build their own resource DLL to hold that. It’s even available as a separate download!
https://www.microsoft.com/en-us/download/details.aspx?id=35825
>>is black magic for most users
>I thought it’s really a basic skill for Windows developers.
^— Confuses software developers with “most users”. The quantity of “most users” is a few orders of magnitude more than the quantity of “developers”.
Edit: grammar and removal of markdown [quote] tags, which I guess this blog doesn’t support.
For us copyright cowards, this is the real answer. Extracting an icon is easy enough, but hunting down the permission slip can be a headache.
A 3rd-party app using Windows icons? Isn’t that copyright violation?
Edit: I just noticed an update to this site that allows me to mark my own comments as spam!
Just provide linking to icon is not copyright violation, but redistributing it is.
However, the EULA of the image library I mentioned have granted you right for use and distribute/redistribute the image files as long as you use it in programs developed in corresponding versions of Visual Studio.
Well they say imitation is the sinceresest formof flattery.
So, as a user, could I have created a personal shortcut, associated it with this icon, then wondered why it broke when I upgraded to Windows 10?
In fact, this has happened to me, a developer of Windows desktop applications. I have a set of folder templates, each one with a Shell32 icon (documents, images, music, videos…), so when I need to create a nice folder I can just copy the template. I created these templates under Windows XP, and when I upgraded to Windows 7, I found some of the icons were wrong and had to correct them. That’s also how I know that Windows 10 hasn’t broken the order established in Windows 7, and that the problem is far worse in Vista than in 7.
Of course, when I found the icon order change in Windows 7, far from cursing Microsoft (which seems to be the fashion among most Windows users), I understood that I was relying on undocumented behavior, and worked to adapt to the new OS. Probably the original customer did open a support ticket not because it was easier than finding the new icons and updating the shortcuts, but because they needed to shift the blame on Microsoft inside their organization.
In fact, domestic users often have OEM licenses, in which support is provided by the computer maker and not by Microsoft, so the original customer is most probably a corporate one. This applies to any of the “customer support” histories told by Raymond.
Microsoft actually telling a customer who relied on undocumented behaviour to get f**ked, as opposed to bending over backwards to ship a compatibility fix for said customer?
The times, they really are a-changing – and for the better I might add. Microsoft devs have wasted so many millions of man-hours on compatibility fixes for lazy and incompetent customers, hours that could have better been making Microsoft’s own products better.
Every change breaks someone’s workflow
I like to use Visual Studio Image Library which contains all icons of VS, Office, Windows and other apps:
https://www.microsoft.com/en-us/download/details.aspx?id=35825
That way icons are consistent in app and MS apps.