Win10 bug? CopyImage() w/ LR_CREATEDIBSECTION

Talk about things C/C++, some related to AutoHotkey
User avatar
Drugwash
Posts: 853
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Win10 bug? CopyImage() w/ LR_CREATEDIBSECTION

Post by Drugwash » 10 May 2019, 09:26

Recently when testing some old scripts of mine under Win10 x64 I noticed a couple of them were displaying their "skins" in color chunks instead of gradient as it always was the case from Win98SE to at least Win7. After some debugging I found out that the CopyImage() API was the culprit.

In fact it's the LR_CREATEDIBSECTION flag (value of 0x2000) that seems to behave in reverse. The function I use to stretch an ImageList bitmap from 2x5px to 140x36px uses a value of 0x2008 for the flags (LR_CREATEDIBSECTION | LR_COPYDELETEORG) and it has worked fine as mentioned above, however in Win10 CopyImage() fails to create the gradient when stretching if the LR_CREATEDIBSECTION flag is present.

Unfortunately, omitting that flag would make the bitmap "chunky" in all other Windows versions (tested only on XP SP3 so far but I'm pretty sure it would be the same on all older OSes). So, to me it appears that the functionality of the said flag - at least in conjunction with CopyImage() - has been (erroneously or on purpose?) reversed in Win10, maybe even in Win8.x.

I'd appreciate if anyone else had the time and will to test this and confirm (or not) my finding, or maybe it has already been found by someone else. It could be of help for fixing old AHK scripts that use CopyImage(), for Win10 compatibility, unless someone asks/reports the issue directly to Microsoft (if it indeed is a bug). Thank you.
Part of my AHK work can be found here.

User avatar
Drugwash
Posts: 853
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Win10 bug? CopyImage() w/ LR_CREATEDIBSECTION

Post by Drugwash » 26 Aug 2019, 08:57

Really, nobody cared to test this in 3 1/2 months...? :(
Further, I noticed most recent versions of Wine have implemented the very same flag bahavior, breaking applications regardless of the OS version compatibility selected in winecfg. Am I going crazy or everything's slowly going down the drain?

swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: Win10 bug? CopyImage() w/ LR_CREATEDIBSECTION

Post by swagfag » 26 Aug 2019, 12:50

post code(minimal working example)
post the resource
post what it looks like
post what it should look like

User avatar
Drugwash
Posts: 853
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Win10 bug? CopyImage() w/ LR_CREATEDIBSECTION

Post by Drugwash » 12 Sep 2019, 13:22

Sorry for late reply, I haven't been notified of your message. :(

Not sure how minimal an example could be since this API is being used in conjunction with others. I'll atach one of my old scripts where I first noticed the issue. Funny thing is I can't find the most recent sources (could be on the XP machine, I'm on Linux Mint now) so I had to extract the script from the compiled exe; please excuse the lack of formatting. Found the sources, it's OK now.

Following screenshot was taken in VirtualBox, with same script first without LR_CREATEDIBSECTION (0x2000) and then with it. It's clear first image looks much better, as a smooth gradient. Using the same flag combination under Win9x/XP/7 (and maybe 8.x) would result in the exact reverse situation: first image ugly, second smooth.
CopyImage() flag bug.png
CopyImage() flag bug.png (21.96 KiB) Viewed 12465 times
Here's the code, look for the cif flag in the ILC_FitBmp2() function and switch it between 0x8 and 0x2008:
MemPanel_src.zip
(11.22 KiB) Downloaded 638 times
Please note that as it is now, the script would function correctly under all Windows versions, since I added that OSVersion detection and flag switch. But all old scripts making use of CopyImage() with the LR_CREATEDIBSECTION flag set will look bad. Which may even be intentional.
Part of my AHK work can be found here.

User avatar
SKAN
Posts: 1619
Joined: 29 Sep 2013, 16:58

Re: Win10 bug? CopyImage() w/ LR_CREATEDIBSECTION

Post by SKAN » 23 Apr 2021, 10:46

Drugwash wrote:
10 May 2019, 09:26
In fact it's the LR_CREATEDIBSECTION flag (value of 0x2000) that seems to behave in reverse. The function I use to stretch an ImageList bitmap from 2x5px to 140x36px uses a value of 0x2008 for the flags (LR_CREATEDIBSECTION | LR_COPYDELETEORG) and it has worked fine as mentioned above, however in Win10 CopyImage() fails to create the gradient when stretching if the LR_CREATEDIBSECTION flag is present.
Since source and target are small images, calling CopyImage() multiple times wouldn't hurt resources much.
I'm using brute force in my CreateDIB() to get it done.
I wish I had documented how I did it. I only remember that I was trying different permutations a whole night. :(
In case you are able to understand it, please let me know how I did it. :oops:

User avatar
Drugwash
Posts: 853
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Win10 bug? CopyImage() w/ LR_CREATEDIBSECTION

Post by Drugwash » 23 Apr 2021, 13:46

Thank you for confirming the issue. As far as I can see your CreateDIB() function uses the same approach: different flags for different OS versions.
Unfortunately in Wine this trick won't work, they never even tried to implement the "forced" gradient feature. Some time ago I've been referred to a bug in their bug tracker describing a very similar issue which probably stems from the same unimplemented feature, and it was years old. Looks like I'm SOL.

I wonder why this reverse behavior in Win10 - was it an accident, such as a moron botching the code because it didn't understand it, or was it deliberate to screw up all existing applications?
Part of my AHK work can be found here.

User avatar
SKAN
Posts: 1619
Joined: 29 Sep 2013, 16:58

Re: Win10 bug? CopyImage() w/ LR_CREATEDIBSECTION

Post by SKAN » 23 Apr 2021, 14:23

Drugwash wrote:
23 Apr 2021, 13:46
I wonder why this reverse behavior in Win10 - was it an accident, such as a moron botching the code because it didn't understand it, or was it deliberate to screw up all existing applications?
May be it shouldn't have existed in first place? May be nobody in Microsoft knew that this could be done?
Microsoft never documented this as a behavior!
I was the one who documented it: https://autohotkey.com/board/topic/80588-how-to-simulate-a-linear-gradient/

Back in 2000, the only programming skill I had was FoxPro for Dos.
I had a huge database of stock market prices and wanted to plot a bar graph.
HTML was the way to go. So I used a small 2x2 bmp for the bars and I noticed IE 3 was stretching the bitmap to a gradient.
I guess, it wouldn't work now.

Up till Windows 7, we could reduce the screen bit depth to 24-bit, 16-bit or even 256 colors, even when the machine had a graphics card.
This feature was removed in Windows 8. If you try reducing the screen color depth programmatically, the reduced color will be simulated in 32bpp mode.
I guess everything related to graphics was re-written for Windows 8 and hence the change in behavior.

:)

User avatar
Drugwash
Posts: 853
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Win10 bug? CopyImage() w/ LR_CREATEDIBSECTION

Post by Drugwash » 23 Apr 2021, 15:16

Ah, good ol' days! :)
Went to that topic and noticed you mentioned a 1x2px image failed to produce gradient. I noticed too that the minimum size would be 2px on either side, probably because a gradient can't be obtained from a single color in either direction.

And dunno why but I feel it in my gut that this was an intentional feature back then even if undocumented; maybe they wanted to keep an ace up their sleeve for whatever purpose. How many such undocumented features and APIs did they ultimately reveal at some point, after years? Not to mention the Easter Eggs in Win9x, very well crafted tricks that regular users never would've discovered other than by lucky accident, if ever.

I wonder how the Win9x gradient titlebars were being drawn. Most likely not from pre-made bitmap images but possibly by using that CopyImage() hidden feature with ad-hoc bitmaps created from the theme color data in the registry.

As it happens I do have a Win8.x machine around, if it should still work, but it'd be a hassle to connect all required peripherals to it and perform some tests. Long gone are the days when I would run 3-4 machines at the same time, all connected to a LAN and seamlessly manipulating files between two machines from a third one. :) But it sure would be interesting to find out if this issue started with Win8 or is solely the undoing of Win10.

In regard to skills, I was coming from a few years of Z80 machine code, where a Spectrum only had 16 colors and creating intermediary tones was a hack job, more so when only two colors were allowed in a 8x8px cell.Those times taught me not to waste storage space and memory, hence the usage of extra small bitmaps for creating skinned GUIs in AHK. That gradient feature allowed for the creation of interesting patterns, not only from two-color bitmaps. If you look in the res folder of MyDiary you'll see the small passSplash bitmaps, and if you run the script you'll see the nice skinned password dialog. It's a real shame to lose that feature, I have no idea if there is any direct replacement for it that would be officially documented and available in all Win versions from 95 to 10, not to mention Wine.

Don't you feel that the entire world has been constantly dumbed down for quite some years already, culminating with this... hell, I'd rather not go there.
Part of my AHK work can be found here.

User avatar
SKAN
Posts: 1619
Joined: 29 Sep 2013, 16:58

Re: Win10 bug? CopyImage() w/ LR_CREATEDIBSECTION

Post by SKAN » 24 Apr 2021, 04:26

Drugwash wrote:
23 Apr 2021, 15:16
I wonder how the Win9x gradient titlebars were being drawn. Most likely not from pre-made bitmap images but possibly by using that CopyImage() hidden feature with ad-hoc bitmaps created from the theme color data in the registry.
:shock: Yes, makes sense.
Also, during '98 times, the installers used to cover the background with a blue to black linear gradient.
I suppose they too had to be dynamically created.
As it happens I do have a Win8.x machine around, if it should still work, but it'd be a hassle to connect all required peripherals to it and perform some tests. Long gone are the days when I would run 3-4 machines at the same time, all connected to a LAN and seamlessly manipulating files between two machines from a third one. :) But it sure would be interesting to find out if this issue started with Win8 or is solely the undoing of Win10.
I have Window 8.1 in my older machine. The issue started with Win 8.0, I suppose.
My recent computer has driver support for Windows 7/Windows 10 but not for Windows 8.
They should have never attempted to remove the Start button :)
If you look in the res folder of MyDiary you'll see the small passSplash bitmaps, and if you run the script you'll see the nice skinned password dialog. It's a real shame to lose that feature,
I had already downloaded. Wil check that out too. :)
Don't you feel that the entire world has been constantly dumbed down for quite some years already, culminating with this... hell, I'd rather not go there.
In my town, there is a belief the illuminati control everything :D.

User avatar
jNizM
Posts: 3201
Joined: 30 Sep 2013, 01:33
Contact:

Re: Win10 bug? CopyImage() w/ LR_CREATEDIBSECTION

Post by jNizM » 26 Apr 2021, 01:23

I had the same problem back then.
https://www.autohotkey.com/boards/viewtopic.php?f=9&t=31773 (german sub)
[AHK] v2.0.18 | [WIN] 11 Pro (23H2) | [GitHub] Profile

User avatar
Drugwash
Posts: 853
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Win10 bug? CopyImage() w/ LR_CREATEDIBSECTION

Post by Drugwash » 29 Apr 2021, 15:49

@jNizM: Heh, if only I had searched the board before posting... :) But search works in mysterious ways anyway. :roll: It was good to brush up my German a little bit, been out of exercise for too long. I see the subject of more than two colors had come up, which makes usage of GDI+ as worthless as the regular GDI. As mentioned above (the passSplash bitmaps) there can be various combinations of colors and patterns in a small bitmap - or even an ad-hoc image built in memory - that may need stretching and color interpolation in a complex way. I don't think GDI+ or any other library for that matter could achieve the desired result, at least not in one go. And I still am unclear whether it was just a stupid mistake/bug or a deliberate act of sabotage towards all old software that may have relied on that feature.

@SKAN: Win98 had quite a few hidden gems that unfortunately came to public knowledge a tad too late to matter anymore. Ah, don't get me started, I'm still not over having to leave my 98SE behind due to lack of drivers for newer hardware.

So they began the destruction with Win8. It figures. Maybe they reversed the behavior of that flag in order to coerce people into getting used to the new ugly interface, together with retiring many useful options. Simplification, dumbing down, easier to control what people do with their machines and how. It's all about control: theirs over us. And it doesn't matter whether they're called illuminati or otherwise - to me they're all a bunch of impotent a$$holes that should climb up Musk's latest rocket and fly the fokk away from Earth, never to return. Ha! Great Reset! The fourth industrial revolution! Climate change, save the planet! A better world! All crap, excuses for the world genocide.

OK, I'm done ranting. I'll soon be done for anyway. Have a good one y'all! :wave:
Part of my AHK work can be found here.

Post Reply

Return to “C/C++”