Resources

[Bonj]

H

When creating an SDK program using VC++.NET 2002, it seems that the icon with the lowest ID seems to be the icon that the executable file gains when it is shown in Windows Explorer. Furthermore, you can edit the resource.h file, to change which icon has the lowest ID in order to determine this, but when you build the project, it always overwrites the resource.h file, even though it keeps the IDs that you've chosen if you've reassigned them
Is this standard behaviour for .NET, or does it happen in VC6 aswell?

[Igor Tandetnik]

"Bonj" <an*******@discussions.microsoft.com> wrote in message
news:B4**********************************@microsof t.com...

When creating an SDK program using VC++.NET 2002, it seems that the icon with the lowest ID seems to be the icon that the executable file
gains when it is shown in Windows Explorer. Furthermore, you can edit
the resource.h file, to change which icon has the lowest ID in order to
determine this, but when you build the project, it always overwrites the
resource.h file, even though it keeps the IDs that you've chosen if
you've reassigned them. Is this standard behaviour for .NET, or does it happen in VC6 aswell?

What do you refer to as "this" and "it" in the last sentense? Picking
the icon with the lowest ID to show for an executable is the standard
behavior of Windows Shell and has nothing to do with what compiler the
executable was built with.

As you say, the IDs you assign in resource.h are preserved, so I don't
see the problem here either.
--
With best wishes,
Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken

[Bonj]

> What do you refer to as "this" and "it" in the last sentense?

The method of how you tell the compiler what icon to make windows read as
the one to display as the icon in Windows explorer.

Picking

the icon with the lowest ID to show for an executable is the standard
behavior of Windows Shell and has nothing to do with what compiler the
executable was built with.
But how does windows know what compiler the program is built with, and how
does it know that it even uses IDs for its icons? I thought the chip that
gets fed the code when you run an .exe only understands machine language,
and hence the only thing that Windows explorer can use to glean the
information on what icon to display?

As you say, the IDs you assign in resource.h are preserved, so I don't
see the problem here either.
They are, but I didn't know that they were going to be! It was a stroke of
luck, I'm sure - so I thought it could be one of those features that they'd
built into .NET but wasn't compliant behaviour necessarily.

If you put it in release mode and compile it without using all the icons,
does it omit the unused icons from the .exe, in the same way that it does
for functions?
--
With best wishes,
Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken

[Igor Tandetnik]

"Bonj" <[e-mail]> wrote in message
news:uZ**************@tk2msftngp13.phx.gbl...

Picking

the icon with the lowest ID to show for an executable is the standard behavior of Windows Shell and has nothing to do with what compiler the executable was built with.
But how does windows know what compiler the program is built with

It does not know nor care.
and how
does it know that it even uses IDs for its icons?
Because it's part of the Portable Executable format that every Windows
executable must conform to. You are confusing cause and effect. Windows
operating system defines the format of a valid executable file, and
compiler builds a file that conforms to this format, not the other way
round. The way to store resources in an executable, and assign IDs to
them, is part of this format.
I thought the chip that
gets fed the code when you run an .exe only understands machine language,

Resources are not code and are never executed. They are data, and are
simply read from the file. You aren't surprised that a text file does
not contain valid machine codes, right?
and hence the only thing that Windows explorer can use to glean the
information on what icon to display?
You thought wrong. There's more to PE format than just raw machine code.
Ever wondered where string literals go?

As you say, the IDs you assign in resource.h are preserved, so I don't see the problem here either.

They are, but I didn't know that they were going to be! It was a

stroke of luck, I'm sure - so I thought it could be one of those features that they'd built into .NET but wasn't compliant behaviour necessarily.
Compliant with what?
If you put it in release mode and compile it without using all the icons, does it omit the unused icons from the .exe, in the same way that it does for functions?

No.
--
With best wishes,
Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken