Jump to content

GDI Heap Extender


Recommended Posts

Beta2 + Simplified Chinese Win98SE + KernelEx 4 Final 2

- Drwatson runs on startup

- No more BSOD at normal shutdown :)

- However, when Kernel Task Manager said "System seems unstable" and I pressed the "Shut Down" button to close all programs, system crashed with BSOD

Otherwise Beta2 looks stable for me

Link to comment
Share on other sites


GDI Heap Extender Beta 2 Testing

...

The first test I left my batch file loading up all the IE sessions (with fifteen second pauses between) and came back about ten minutes later to find that Windows had rebooted and was sitting at the desktop.

The second test started to exhaust the GDI Heap and some graphics on web pages were missing.

...

I also had several hangs in Microsoft Word 2002 (XP), although I've had this in the past, so I cannot conclusively link it to GDI Heap Extender. It seems to come and go over time, and I've never identified what causes it. It only happens in Word.

...

Well, I've since had a hang in IE6 and a hang in WinDVD - these hangs all required the power button.

Also, after some minutes of using Thunderbird 2.0.0.23, the graphics and buttons started to scramble until it was not possible to make out what to click on.

I've rolled back to Beta 1 and so far no problems.

I've been using Thunderbird for hours selectively transferring, and filing in folders, e-mails from an old webmail account.

No problem whatsoever.

Beta 1 was very stable, so if it continues to be, then I'll know that the previous issues are Beta 2 and not something else.

I'll keep testing with Beta 1 and post results.

Link to comment
Share on other sites

Beta 3 dissection edition

http://tihiy.ahanix.org/rpXbeta3.zip

* Reverted RP9 to beta1 (thus shutdown probs again);

* Other changes nobody cares about.

This build has debug partial disabling functionality, intended to help Chozo4 identify the problem:

Please turn on all those switches in \windows\uberskin.ini:

[Beta]
Alpha=1
NoCleanup=1
NoSetDIBits=1
NoRestoreDC=1
NoGetDIBits=1
NoIsGDIObject=1
NoWackoHacko=1

If this solves your problem, please narrow the source of the problem to the only switch. If it's not, i'm gonna divide by zero. Don't forget rebooting.

The summer is almost over.

Link to comment
Share on other sites

Just tried out beta3 and tested using the bits specified.

This is OKAY:

[Beta]
Alpha=0
NoCleanup=1
NoSetDIBits=0
NoRestoreDC=0
NoGetDIBits=0
NoIsGDIObject=0
NoWackoHacko=0

However, the issue crops up once you unset the 'NoCleanup' bit.

Link to comment
Share on other sites

I felt it, since it was the second only Alpha 2->3 change. But it's just assembly code and the issue must be deeper.

Stay tuned.

Edited by Tihiy
Link to comment
Share on other sites

I'd also noticed a slight rendering issue with beta3. Although, I'm not sure if it is due to the cleanup being off for it to work or not. However, when an application crashes (in this case, IExplore.exe causes an IPF in mshtml.dll), the skinning becomes corrupt on the skinning elements (titlebar, taskbar, etc).

http://i29.tinypic.com/10cq550.jpg

Ignore the settings shown in the notepad document up, that was only during testing. The corruption occurs while Alpha=0 only (when alpha=1, the startmenu button only goes missing). The skinning elements are restored by reselecting the theme in rpconfig and applying again so it's purely an inconvinience really rather than something really major.

Edited by Chozo4
Link to comment
Share on other sites

Once again, this one should do the trick...

http://tihiy.ahanix.org/rpXbetaX.zip

[Beta]
Alpha=0
NoCleanup=0
NoSetDIBits=0
NoRestoreDC=0
NoGetDIBits=0
NoIsGDIObject=0
NoWackoHacko=0

SUCCESS! :thumbup

Well, I'm proud to say that one definately did the trick. So far no GDI crashes to report from winamp, psp7, etc.

It will most like be over my head but I hope you don't mind my asking: What WAS the cause anyway? :blink:

Edited by Chozo4
Link to comment
Share on other sites

What WAS the cause anyway?
I wish i knew exactly.

GDI Heap Extender works this way: [**** i suck at diagrams]

There are GDI handles pointing to 16-bit local heap memory blocks.

Handles are stored in handle tables and consist of 4 bytes: pointer to block (2 bytes) and flags (2 bytes).

When GDI Heap Extender kicks in, handles are decoupled from blocks. It preallocates several memory blocks [arenas] in 16-bit heap (~1% of resources) and provides those blocks for active GDI handles with special LRU algorithm:

* when new handle is allocated, it points to least used arena. if handle was using this arena, it is 'swapped out': contents are moved into special 'shadow' 32-bit heap. handle is marked by special 'mutated' flag 0x80. this value is not defined nor used in 16-bit heap.

* when GDI function receives handle marked as 'mutated', it must 'unmutate' it the same way: find least used arena, 'swap out' its contents, and 'swap in' object contents.

That's pretty much is it. This way each bitmap handle costs only 4 bytes to GDI heap, not 44 as before, thus potentially there is 10 times possible improvement. There are other limitations for bitmaps (global memory, LDT, 32-bit GDI heap) but best case it's really 10+ times.

GDI Heap Extender also can increase performance sometimes, and that's not obvious. I'll tell ya later.

So what was the problem? 0x80. It seems in Chozo4 case some program/driver is abusing handles the way i do, so I added simple check if it's really a bitmap.

Link to comment
Share on other sites

Tested RPX BetaX:

Good results with youtube...

[Beta]
Alpha=0
NoCleanup=1
NoSetDIBits=0
NoRestoreDC=0
NoGetDIBits=0
NoIsGDIObject=0
NoWackoHacko=0

Best results with youtube.

[Beta]
Alpha=0
NoCleanup=1
NoSetDIBits=1
NoRestoreDC=1
NoGetDIBits=1
NoIsGDIObject=1
NoWackoHacko=1

Bye.

Mcv'93

Link to comment
Share on other sites

What WAS the cause anyway?
I wish i knew exactly.

GDI Heap Extender works this way: [**** i suck at diagrams]

Ah, that explains things well for me, thanks! You say you suck at explaining but quite frankly, you did well as I'd understood it no problem. Just have to love how sometimes it's the smallest most obscure thing that can cause the biggest upheaval in a program,script, etc. Been there myself in other programming languages (though, web based involving user and session databases with efforts to minimize them as much as possible) so can somewhat relate.

.. thanks again for your efforts and unwavering patience in having solved this issue. :)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...