[1/2] gdiplus: Don't keep a reference to HDC in the GpBitmap object.

[Vincent Povirk]

>> > an image passed to GdipGetImageGraphicsContext() is destroyed right after
>> > the graphics object was created, then later on all calls using that HDC fail
>> > and silently lead to using invalid or not initilazed values.
>>
>> You have to keep the image alive as long as you're using the Graphics
>> object. If you're not doing that, then you have a use-after-free and I
>> don't trust the results of your test.
>
> You are welcome to experiment with the test and try to prove that its
> results depend on the availability of an image. My tests show that image
> after the GdipGetImageGraphicsContext() call can be safely destroyed,
> and the test results don't depend on it.

You're adding a test that relies on a corner case that should be
regarded as a broken program, and that could easily result in a
use-after-free on native. I'm not convinced this is reliable, as the
native codepath could involve a use-after-free and still work by
coincidence. There is no evidence that any real program relies on this
case, and you could easily modify your test to not depend on it.

By "fixing" this corner case, you risk breaking others. I wonder if
native can have multiple Graphics objects that draw to a single
Bitmap. I don't think an HBITMAP can be selected into multiple HDCs,
but since native does everything through memory it could easily handle
this. I don't know if any real program relies on this, but to my
knowledge nothing relies on the thing you're testing either.

And as I said, the HBITMAP and HDC are both going away soon. We know
native doesn't have them. So you're making minor adjustments to a
stop-gap solution that we know is wrong, in order to fix code that is
arguably broken and that does something no program to our knowledge
does. I just don't see the point.