Icons and cursors know where they came from

If you create an icon by calling LoadIcon, the window manager loads the specified icon from the module you specified, but it also remembers where the icon came from. (This discussion also applies, mutatis mutandis to cursors, but I will just talk about icons to avoid awkardness.) When you pass the LR_COPYFROMRESOURCE flag to the CopyImage function, the window manager goes back to the original icon source to create the copy you requested rather than blindly stretching the pixels of the icon you passed in.

Remember that an ICO file represents not just one icon but rather a collection of icons (known as an "icon group"), each at a different size or color depth. The intent is that each icon in the icon group depicts the same underlying image, just tuned for particular settings. (Now, mind you, there is no enforcement of this intent. If you make your 16×16 image a smiling-face and your 32×32 image a barking dog, well, then that's your problem.) For example, a single ICO file might contain a 16×16 image, a 32×32 image, and a 48×48 image. If somebody asks for the icon at one of those sizes, then the corresponding image is used. On the other hand, if somebody asks for, say, the 24×24 image, the window manager will take the 32×32 image and stretch it to the necessary size.

You can recover this "hidden source information" with the GetIconInfoEx function (new for Windows Vista). If the icon was loaded by ordinal, then the szResName is an empty string and the ordinal is placed in the wResID member. If the icon was loaded by name, then wResID is zero and szResName contains the resource name.

This is just some background information about icons (and cursors). Next time, we'll put this information to use to solve a problem.

[Raymond is currently away; this message was pre-recorded.]

Comments (18)
  1. Ziktar says:

    The game Fallout 2 actually used differing images in an .ico as an easter egg. The application’s icon was the game symbol for 16×16 and 32×32 images, but the 48×48 image was some guy (presumably a developer)’s face.

    This became apparent to me when I, in a bout of reminiscence, installed Fallout 2 on my XP box, which uses 48×48 icons in the frequently used box. Now, instead of the Fallout icon, there is this guy’s face plastered all over my start menu. Awesome. :)

  2. Dave says:

    I hope the problem you’ll solve is the one that grotesquely distorts 16×16 tray and application icons when you use 120DPI.

  3. Dog says:

    Why is Windows icon technology still in the stone age?

    The newest addition to the technology was alpha channels in Windows 2000. But it still requires custom bitmaps for each size and the system still uses a very poor scaling algorithm if the requested size is not available.

    Mac OS X has used 128×128 icons (512×512 for Leopard) that are then scaled down since 10.1.

    OSS desktops (GNOME and KDE) both support fully vectorised SVG icons.

    Unfortunately, since Microsoft doesn’t really have a modern vector format (VML has almost no application support, WMF is archaic) and will probably never use SVG since its not "theirs", it will probably be a long time before Windows gets any modern icon support…

  4. A. Skrobov says:

    Microsoft doesn’t really have a modern vector format (VML has almost no application support, WMF is archaic)


  5. Ulric says:


    It’s easy to complain about the Windows 2000 not being up-to-date with the operating systems that came years after, right?

    Windows Vista icons are 256×256 RGBA, with PNG compressions.

    512×512 in Leopard, if true, is just plain stupid. (1 meg of RAM per icon???)  It’s a program icon, for god’s sake, not a wallpaper.  You probably can’t ever see them in Finder.

  6. Ulric says:

    OK, well I’ll just file all of that under Mac Fanboy rants.

    Vector Icons: It doesn’t matter what you think is best.  What matters is what the artists want.  We want to create bitmaps icons with all the tools in photoshop, not simplistic SVG icons so that it ‘scales pretty’ but is painfully made with basic vector primitives.  Also, having large images scaled down too far looks absolutely horrible, a blurry mess of pixels, and the line detail art is lost.

    There is nothing wrong with the scaling in Vista, and it definitely uses the 256×256 icons if you use large icons.  Of course, it’s windows 2000 you want to talk about.

    note that OS X has much better 64-bit >support than Windows

    Beurk. OS X is not a true 64-bit operating system.  The kernel, the drivers are all 32-bit.  All the 64-bit apps are thunking  down to access all 32-bit stuff for stuff like OpenGL, for example. That’s partly why it’s not shipping a separate version of the OS for 64-bit.  It’s a 32-bit OS patched to support 64-bit processes on top.  The Finder and all the apps with OS X are 32-bit, so your comment about memory not mattering is irrelevant.  

    Apple, of course, ships no 64-bit application. It’s a 64-bit OS in Marketting only. ;)

  7. Bryan says:


    I’m confused by what you mean when you say that you almost never see the new icon.

  8. Zr40 says:

    @Ulric: The Mac OS X kernel has to be 64 bit, since it’s impossible to run 64 bit applications on a 32 bit kernel.

  9. Dog says:

    @Ulric: I’m no Mac Fanboy, I don’t even own a Mac anymore!

    Firstly, I admit, I am not an icon designer. Nor am I a graphic designer of any kind. However, I have had to source icons for projects in the past and I can tell you that for modern, high-resolution icons, the source format is almost always Adobe Illustrator, i.e. vector.

    Here is an article form Icon Factory (the icon designers for Windows Vista and XP), mentioning their use of Illustrator: http://iconfactory.com/home/permalink/1699

    They do of course also use Photoshop.

    Secondly, SVG (and other vector format) icons are far from simplistic (although simpleness is IMHO a desired trait for icons), vector graphics have come a long way since the collections of WMF clip-art that were common about 10 years ago. A quick google image search for "vector icons" brings up some very impressive results.

  10. Yuhong Bao says:

    "OS X is not a true 64-bit operating system."

    If you are wondering why, the 64-bit support in Mac OS X (and Solaris) was designed for processors where a simple port to 64-bit would actually lead to a performance loss. In contrast, the 64-bit support in Windows was designed for the Itanium, where x86 emulation was expensive enough that a simple port to 64-bit would result in a performance gain.

    "All the 64-bit apps are thunking  down to access all 32-bit stuff for stuff like OpenGL, for example"

    No, the user mode apps cannot thunk, at least within a process, and that is true on Windows as well. But the xnu kernel can switch between compatiblity mode and 64-bit mode, and often do. In fact if you look at the xnu kernel source, you will see that there is a set of macros for doing this.

  11. Leo Davidson says:


    "Ok, so Vista introduced a new bigger icon size, but it still uses bad scaling algorithms (scales small icons up, not big icons down)"

    It may not be used in the places you are thinking of but Vista has new icon-loading and scaling APIs which will automatically pick the next-biggest (or equal) size and scale them down to the size you requested.

    Is your complaint about something you’ve seen on Vista or something you just assume is still a problem? I haven’t tried 120dpi for more than a few minutes so I don’t know what happens.

    (I do agree that the taskbar notification area’s icon scaling was abysmal in previous versions of Windows. Haven’t seen Vista in a situation where it needed to scale them yet.)


    "We want to create bitmaps icons with all the tools in photoshop, not simplistic SVG icons so that it ‘scales pretty’ but is painfully made with basic vector primitives.  Also, having large images scaled down too far looks absolutely horrible, a blurry mess of pixels, and the line detail art is lost."

    Perhaps he is atypical but the icon artist I know does everything using vectors in Photoshop and then renders those to bitmaps for use in the program. The icons are still very detailed and you wouldn’t know they were not hand-drawn from looking at the results. (You can have lots of vectors, plus gradients and other effects applied to them.)

    He still has to tweak the large vs small icons as blindly scaling a large icon of any format down to 16×16 isn’t gonna work. It’s a lot easier to tweak things or create new sizes when everything is made from vectors you can move and resize, though.

    @The main article:

    I’m surprised to hear that Windows tracks the icon sources. I figured that info was lost on load because I’ve always had to create separate large & small icon resources for the window border icon. Trying to use a single icon resource (with both sizes embedded) for both always ended up with one size being chosen and scaled, with ugly results.

    Is this tracking new, or is it just not done by LoadImage or something?

  12. Koro says:

    Leo Davidson: You still have to tell Windows you want the small icon for your window caption. So you have to load it twice, once for the big icon (using LoadIcon), once for the small icon (using LoadImage, specifying GetSystemMetrics(SM_C(X|Y)SMICON) as width/height).

    At least that’s what I do since 1998, and it always worked well.

    What Raymond is talking about, is of the LR_COPYFROMRESOURCE flag which "[t]ries to reload an icon or cursor resource from the original resource file rather than simply copying the current image" (MSDN). Which means it actually reloads the icon the size you tell it.

  13. Mark says:

    Koro: that’s what he said.  The question is why the window manager doesn’t use LR_COPYFROMRESOURCE.

  14. Dog says:


    Ok, so Vista introduced a new bigger icon size, but it still uses bad scaling algorithms (scales small icons up, not big icons down), so you almost never see the new icon. Not to mention that there are still icons that ship with Windows that don’t support all the "standard" sizes.

    I also don’t think that 512×512 icons are that excessive. As higher resolution screens become more common, they’ll be needed. Also note that OS X has much better 64-bit support than Windows (it doesn’t require a different "edition" of the OS for a start*), so memory use is less of a problem.

    IMHO, vector icons are a better solution.

    *I understand why Windows must work this way, but I do not understand why Windows licensing is this way.

  15. alex.r. says:


    The whole vector side talk is mostly off-topic but I’ll bite anyway:

    Those wanting ‘pure’ vector icon most likely have never tried it.

    Rendering a complex vector file can easily be orders of magnitude slower than an a bitmap. (This is especially true for SVG which is not particularly efficient to begin with.)

    When you have one icon per file, it can quickly become a problem. This explains why a lot vector icons do not have much details.

    Also, as it was already mentioned, the resulting icon does *not* look good at every resolution (at very big sizes the borders are disproportionate and the whole icon is not detailed enough, at smaller sizes the icon is blurry and undecipherable).

    Having multiple bitmaps of the same icon at different size is a very good solution. It is not only used by Windows but by OS X also as well as a lot of the Gnome/Kde themes.

  16. JamesW says:


    ‘Apple, of course, ships no 64-bit application’

    Xcode.app and Chess.app have 64 bit binaries.

  17. Michiel says:

    Am I the first to wonder why the window manager, having to create a 24×24 icon takes the 32×32 icon? When it also has a 48×48 icon? It should just take 4 pixels at a time and average. Computers are still best at binary.

    Of course, that still doesn’t fix the ugliness that Dave hinted at. How many icon sizes should one support for non-96DPI screens? I believe that because of this (Windows) problem, high-DPI screens won’t take off until 192 DPI becomes affordable.

  18. Leo Davidson says:


    The 48×48 icon may have more detail than the 32×32 icon, meaning it would be best to scale the 32×32 version if you want 24×24. Obviously it can depend on the icon, though.

    Another issue would be if you wanted consistent drop-shadow depths (or outline widths or whatever) at all icon sizes. Scaling the 48×48 to 24×24 would make those features half the size. Scaling the 32×32 wouldn’t be perfect but it would be a closer match.

    These are just guesses, though. There could be other reasons behind it or it could be an arbitrary choice.

Comments are closed.

Skip to main content