This bug is specific to JDK 1.1.x on win32

It concerns the way that frame icons are handled.
We are destroying something that is treated as a shareable resource.

A programmer can use setIconImage(Image) and supply an image which is
used as the icon for a window, to appear in both the top left hand corner
of the window and in the win95/NT taskbar.

The JDK runtime has to export a Java image to the format required
by the win32 environment in order to pass an HICON object to the
windows call to
    ::PostMessage(GetHWnd(), WM_SETICON, TRUE, (long)hIcon);


However when the frame is disposed by a call to Frame.dispose() then
this also causes the frame's native peer to be destroyed and in
the destructor for AwtFrame we see:-

        ::DestroyIcon(m_hIcon);

The icon data is now longer valid.

[[ Note that setting a new icon via setIconImage also destroys
the previous icon. ]]

The problem is that this icon is not recreated from the image
data everytime a HICON is requested.

It is done ONCE only on the first request and the runtime stores
a handle to the HICON which it has created and passes out a reference
to that to every new request to setIconImage using that image.

But after being destroyed this HICON , although not of course NULL
in the AWTImage object no longer points to valid data.

There is even a comment in the code above ToIcon() :-
// <<Created icons are cleaned up by callers.>>

I can't see why with this realisation we are sharing the icon.

Windows seems to be sufficiently robust to recognise this and
quietly use the icon for the window class instead - ie the Java cup.

But it does mean that this image is now useless as an icon.

Reloading the image from a URL or disk is NOT a workaround.
This is because the image loading code seems to cache the image
and always give you back the same internal image which has the
corrupted image.

This analysis was verified both by
1) Observing that commenting out the call to DestroyIcon cured
the problem

2) Observing that independently to solution (1), always returning
a fresh HICON cured the problem.


phil.race@eng 1998-02-13

This bug is fixed in 1.1.6 build E, but I want to make sure that the
following information is recorded in the bug report.
This bug can cause a very nasty crash for which it is hard to identify
the cause.

It appears that Windows '95 can identify that an icon handle is no longer
valid in some, but not all cases. In the cases where it tries to use
the invalid pointer the application can crash with a crash like

JRE caused a general protection fault
in module GDI.EXE at 0001:00007955.
Registers:
EAX=00001001 CS=0467 EIP=00007955 EFLGS=00000202
EBX=01e747a6 SS=5417 ESP=00008cfc EBP=00008d06
ECX=8164087e DS=05c7 ESI=000047a6 FS=3d6f
EDX=0001eeb9 ES=05c7 EDI=00006f3a GS=0000
Bytes at CS:EIP:
8e 65 0e 8b 3e 28 01 64 8b 05 8b d8 87 44 26 64
Stack dump:
50767929 47a66f3a 8d2205c7 0467771f 087e5076 0000013f 013f3d6f 00000000
0000eeb9 8d6c5b31 016f0028 087e5076 bff72999 013f0000 8d805657 016f0028

A crash in DIBENG.DLL can also result.

Alt-Tabbing between applications could also crash, since Windows'95 uses the
icon there too.