I dual-boot Windows XP and Windows 7 and have run into a peculiar issue with icons for shortcuts.

A different desktop is used for each OS, so I have a shortcut to the other one on each for easy access to both from either version of Windows; that is, in XP, the desktop contains a shortcut called 7Desk and in 7, the desktop contains a shortcut called XPDesk. Further, 7Desk.lnk is set to use the desktop icon resource of shell32.dll from Windows 7, and XPDesk.lnk is set to use the desktop icon resource of shell32.dll from Windows XP. That way, each shortcut shows the other OS’s icon for the desktop.

The problem is that even though in the Change Icon dialog I can see the correct icons (for the other OS), when I click OK, the icon shows the corresponding icon from the currently booted OS instead of the other one. I have confirmed this to occur for other icon resources as well like the Recycle Bin icons.

This is baffling because as far as Windows (and the Change Icon dialog) are concerned, shell32.dll from the other drive is just a file containing icons. There is no reason for it to treat the DLL specially, and even more mysterious is how it knows which of its own icons to use in place of it. That is, how does XP know to use the XP desktop icon in place of the 7 desktop icon, or how does 7 know to use the 7 recycle bin icon in place of the XP recycle bin icon? And just to make things even more confounding, I have checked the LNK files in a hex-editor and can clearly see that the icon resource is indeed pointing to the file on the other drive, not simply to \windows\system32\shell32.dll.

(Granted, the icon indexes are the same, so perhaps it is simply using its own copy of shell32.dll instead of the one specified on a different drive, but then, why is it doing that? Is it some sort of “AI” in the Change Dialog function, trying to do what it thinks we want instead of what we say?)

I can record a screen-cast if the problem is unclear.

2 Answers 2


It's possible that Windows uses LoadLibrary to load the DLL with the icons. When LoadLibrary sees that a DLL is loaded, it will use the one that is already loaded; the checking is based on DLL name, not location.

If so, a workaround is to create copies of both shell32.dll libraries with different names (e.g., shell32-xp.dll and shell32-7.dll) and then change the icons to reference those files.

  • Well, I just did that it seems to have worked (at least in 7; I’ll check XP the next time I reboot, but I suspect it will be the same). I’m not keen on having four copies of the 10MB+ files though, so maybe I’ll just extract the icons and link to those instead. It seems an extremely poor way to handle the icons. What about ICO, ICL, and EXE files? I imagine that it doesn’t/can’t do the same silliness for those, so why would it handle DLLs specially? I can understand doing it for functions, but not resources, at least not in this context. Anyway, thanks for the idea; it seems to be correct.
    – Synetech
    Sep 14, 2011 at 23:28
  • Extracting the icons sounds like a good idea. A possible explanation for this behavior: pulling icons from an already loaded DLL is much faster and since this is a common case, Microsoft has optimized it. EXEs probably use the same approach, ICOs etc. probably not.
    – jdigital
    Sep 14, 2011 at 23:37
  • Yes, using resources from loaded DLLs makes sense for certain aspects (specifically UI elements), but not shortcuts which could draw from anywhere. I guess this is another example of the typical narrow-minded, thinking of only my own software mindset that many programmers fall into. Either way, I extracted them and it’s working great now (even if it does feel a little hack-y and less “clever” and dynamic). :-)
    – Synetech
    Sep 15, 2011 at 0:27

To get around that copying part you could hardlink them, each on its own drive. That's at least what I've done. And there is no more fuss of having multiple copies of each file.

fsutil hardlink create \WINDOWS\system32\shell32_xp.dll \WINDOWS\system32\shell32.dll

This one is on the XP side. On the Windows 7 side you replace the _xp part with _7 :)

EDIT: I've seen that the one on Windows 7 side doesn't work. Unless you break permissions (with a chance of wrecking everything in the system) you should only do this on the XP side.

If you still want to do this, you must take ownership of the file and change the permissions, but be warned again!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .