Windows EXE icon resource

Hi guys,

I’m sure this has been touched on many times before, but I’d like to bring it up again if I may.

In SDL 2.0, setting the window icon with SDL_SetWindowIcon is a nice platform-independent way of doing it, but on Windows it is a pain. Short of editing the SDL source directly, there is no way to instruct SDL to use an icon that is already embedded in the EXE.

I’d like to suggest an API function that takes an icon resource identifier (an integer) specifically for Windows builds:

Code:
#if defined(_WIN32)
SDL_SetWindowIconResource(IDI_ICON1);
#endif

Alternatively, prior to initializing SDL, you could specify a hint that SDL should use a particular icon resource when it registers window classes:

Code:
SDL_SetHint(SDL_HINT_WIN32_WINDOW_ICON, IDI_ICON1);

A third alternative is that SDL should, by default, automatically use the first icon resource in the EXE if there is one is available (this mirrors how Windows Explorer puts icons on EXE files):

Code:
// During SDL initialization:

HICON hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(1), …);
if (hIcon)
{
WNDCLASS wc;

wc.hIcon = hIcon;

// etc…
}
else
{
// Do default SDL behavior
}

The second and third options are probably the easiest to integrate into the current source tree. I’d do this myself, but I’m not an SDL contributor and wouldn’t know where to start. I’m interested to hear what the SDL developers think of these suggestions.

Thanks.

Can you create a RWops from the resource? You can load an SDL_Surface from
a RWops (SDL_LoadBMP_RW() or IMG_Load_RW()) and then send it to
SDL_SetWindowIcon(). If it’s plain pixel data or you know how to decode
the format, you can use SDL_CreateRGBSurfaceFrom() directly.

Jonny D

**
Hi guys,

I’m sure this has been touched on many times before, but I’d like to bring
it up again if I may.

In SDL 2.0, setting the window icon with SDL_SetWindowIcon is a nice
platform-independent way of doing it, but on Windows it is a pain. Short of
editing the SDL source directly, there is no way to instruct SDL to use an
icon that is already embedded in the EXE.

I’d like to suggest an API function that takes an icon resource identifier
(an integer) specifically for Windows builds:

Code:

#if defined(_WIN32)
SDL_SetWindowIconResource(IDI_ICON1);
#endif

Alternatively, prior to initializing SDL, you could specify a hint that
SDL should use a particular icon resource when it registers window classes:

Code:

SDL_SetHint(SDL_HINT_WIN32_WINDOW_ICON, IDI_ICON1);

A third alternative is that SDL should, by default, automatically use the
first icon resource in the EXE if there is one is available (this mirrors
how Windows Explorer puts icons on EXE files):

I don’t like the other two since they involve #ifdef areas and
platform-specific stuff, but I think the above idea is a good solution. So
few Win32 applications change their icon from the one they have stored in
the EXE that I think it’d be safe to do as you suggest below.On Wed, Jul 25, 2012 at 3:53 AM, msturner wrote:

Code:

// During SDL initialization:

HICON hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(1), …);
if (hIcon)
{
WNDCLASS wc;

wc.hIcon = hIcon;

// etc…
}
else
{
// Do default SDL behavior
}

The second and third options are probably the easiest to integrate into
the current source tree. I’d do this myself, but I’m not an SDL contributor
and wouldn’t know where to start. I’m interested to hear what the SDL
developers think of these suggestions.

At this point, the developers are the community, so open season IMO.

Thanks.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I think the third solution is good, too. It would be seamless as far as
portability.

However, getting a pointer to the data and using SDL_RWFromMem(), etc.
would be more useful. An interface like that would handle more than just
image resources. With this or the first two suggestions, there would still
be a no-op on most (by enumeration) platforms.

Jonny D

While I agree that RWOps would be neat, I suspect that a program that makes
extensive use of EXE-embedded resources would likely be inherently less
portable than a program that stored its resources in external files and
might just choose some #ifdef logic instead. Though if a case can be made
for the icon, then why not the mouse cursor etc. It’s tough to pick one and
exclude the other.

PatrickOn Wed, Jul 25, 2012 at 10:04 AM, Jonathan Dearborn wrote:

I think the third solution is good, too. It would be seamless as far as
portability.

However, getting a pointer to the data and using SDL_RWFromMem(), etc.
would be more useful. An interface like that would handle more than just
image resources. With this or the first two suggestions, there would still
be a no-op on most (by enumeration) platforms.

Jonny D


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yeah, there may be no clear way to support more platforms through such an
interface. An add-on library that loads resources into RWops would be
appropriate, though.

So, I think taking the transparent route (#3) with icons would probably be
best, since it is clear enough and there is and has been demand for such a
thing. Automatic and expected is good. Mouse cursors and more would be
useful, but is the demand there or is there a standard for these resources?
They should wait, at the very least.

Jonny D

Not sure if similar facilities exist in whatever language you’re using, but in Delphi there’s a Resource Stream class for getting access to the data of a resource as a stream, and it’s trivial to wrap a SDL_RWops around any stream object.? If you have access to a similar resource stream class, that would probably be the best way to go about it.

Mason________________________________
From: Jonathan Dearborn
To: SDL Development List
Sent: Wednesday, July 25, 2012 8:04 AM
Subject: Re: [SDL] Windows EXE icon resource

I think the third solution is good, too. ?It would be seamless as far as portability.

However, getting a pointer to the data and using SDL_RWFromMem(), etc. would be more useful. ?An interface like that would handle more than just image resources. ?With this or the first two suggestions, there would still be a no-op on most (by enumeration) platforms.

Jonny D


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

This is SDL 1.2, but this is what we do in ioq3:

http://svn.icculus.org/quake3/trunk/code/sdl/sdl_icon.h?revision=1416&view=markup

#ifdef USE_ICON
{
SDL_Surface *icon = SDL_CreateRGBSurfaceFrom(
(void *)CLIENT_WINDOW_ICON.pixel_data,
CLIENT_WINDOW_ICON.width,
CLIENT_WINDOW_ICON.height,
CLIENT_WINDOW_ICON.bytes_per_pixel * 8,
CLIENT_WINDOW_ICON.bytes_per_pixel *
CLIENT_WINDOW_ICON.width,
#ifdef Q3_LITTLE_ENDIAN
0x000000FF, 0x0000FF00, 0x00FF0000, 0xFF000000
#else
0xFF000000, 0x00FF0000, 0x0000FF00, 0x000000FF
#endif
);

        SDL_WM_SetIcon( icon, NULL );
        SDL_FreeSurface( icon );
    }

#endifOn Wed, 25 Jul 2012 01:53:01 -0700 msturner wrote:

I’m sure this has been touched on many times before, but I’d like to
bring it up again if I may.

In SDL 2.0, setting the window icon with SDL_SetWindowIcon is a nice
platform-independent way of doing it, but on Windows it is a pain.
Short of editing the SDL source directly, there is no way to instruct
SDL to use an icon that is already embedded in the EXE.

Hi Guys,

Thanks to everyone for your comments.

After thinking about this overnight, and also reading your comments, I agree that option #3 is the overall best solution.
At the very least, it is the solution that would take the least amount of effort to integrate, does not require
refactoring of the API, and would not break existing code.

I do also like the idea of using SDL_SetHint() as a way of tweaking how this operates. For example, you could use it to specify the name of the icon resource to load.

Can I have it by Friday? [Laughing]

Cheers.

One note on resources:> Date: Wed, 25 Jul 2012 10:11:46 -0500

From: Patrick Baggett <baggett.patrick at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Windows EXE icon resource
Message-ID:
<CAEk2St=J_NVoDFk0_6T2uWL+PAb-a3Ee4fO6+ex4mxSbMFQvcA at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

While I agree that RWOps would be neat, I suspect that a program that makes
extensive use of EXE-embedded resources would likely be inherently less
portable than a program that stored its resources in external files and
might just choose some #ifdef logic instead.

Patrick

I’ve played around with embedded resources before, and all that you
really need is a program that transforms a file into a C array filled
with the resource’s byte values written in hex, + a variable that
specifies the array’s length. The only real restriction is whatever
length limit your compiler places on arrays.

Other platform-specific stuff is, of course, a different topic.