Tihiy

No. Sorry, i don't need testing anymore, nor do i have time to review testing results. GDI Heap Extender is unstable beta (stable for someone/thing, but not everyone/thing) and there are known problems which require major changes which i can't afford yet due to lack of time.

http://www.geocities.com/the_real_sz/misc/bear_.htm

You need to restore kernel32.dll with sfc.exe or manually.

Latest DVDFab seems to be poisoned with terrible GDI leak. GDI Heap Extender is able to make it run, but it still leaks more than half of system resources. You can try to persuade developers to fix that, but usually they don't really care. Note: GDI Heap Extender is still in deep beta.

Yep. I plan RP10 to bump it to 4MB (only if not already specified). Setting too big values is not recommended as it may deplete too much selectors.

you've bumped into 32-bit heap limitation <- link doesn't work for some reason, look previous page with GDIMaxHeapSize description. As for GDI Heap Extender: i had release ready but now i'm fighting with extremely nasty Miranda IM crash similar to previously reported, and it's hard to defeat.

Please don't touch RPXBetaX. It's intended only for those who had problems. Final beta will came, with optimizations.

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.

Once again, this one should do the trick... http://tihiy.ahanix.org/rpXbetaX.zip

You must have IE6 installed. I believe installer warns about that.

Surely it's cleanup. Now test this please (without NoCleanup on) and let's hope push fs / pop fs save the day. http://tihiy.ahanix.org/rpXbeta4.zip

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.

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=1If 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.

Can you re-try Alpha2 please? Just to be sure.

It may be difficult to obtain proper performance on 128MB of RAM. Final algorithms are gonna be much less aggressive. supem/Chozo4?

Yeah, and youtube works? Finally! Oi don't do that!Beta2 loads drwatson at startup, that may be problematic/unwanted behavior. I have to figure out how to make unloadable DLLs, so far there's no perfect approach.

RetroOS sites test seems to be very useful. I didn't find leak but on second test run apps start to hang. So avoid Beta 2 for now. Edit: or not, it's just adobe.com which hangs frequently for no reason.

That can be good news. If there is real leaks, anti-leaking code would be improved. There are other reports i'm waiting though...

Hmm seems i was too careless and released version which runs drwatson at startup? Anyway, that's nasty error. Are you sure rp10.dll was copied into \windows\system? To work this around you can downgrade to Beta 1 with rp10.dll from Beta 2. Sorry for trouble.

Beta 2 http://tihiy.ahanix.org/rpXbeta2.zip * Fixed all sorts of [theoretical] memory corruption issues; * Hardened / improved handle validation beyond RP9 level; * Covered more [all?] bitmap creations; * Fixed [should be] shutdown issues. Note: handle protection and anti-leaking system is active even when you turn off "GDI Salvation". This is intended. You may want to test that scenario (fixes Flash, Charmap font leaks; Notepad++, some older Miranda versions crashing). This beta version must be installed on top of RP9 (or previous betas) and updates it to 9.1.2 with: * Fix for shared memory swapping issues; * Some fixes for control skinning; * Disabled ClearType support.

Yeah?

Note, that functionality was achieved with RP9 GDI salvation. It was reimplemented since Alpha 2 afaik.Okay, i'm preparing [last?] beta with all unpossible fixes which should cure Chozo4/supem problems. Then USER Heap Extender alphas will roll, if everything goes as planned.

Uhh, that's not true. Shared memory is nicely swapped out, and with 64MB or less memory you can easily swap even system DLL pages.Moreover, mapped files reside in shared memory and basically are part of swap; and they are tracked by system, so apps using file mapping can use more than 2GB of virtual memory on 9x... Who cares?

Pretty much classic dialog.

It works with previous mozcrt19.dll.