Tihiy

Well, it's recommended for problematic software. Let's make table with problematic soft in this post then! Opera 9.6 Uses a lot of GDI resources with web pages and itself. Opening a lot of tabs may drop resources below 40%. Alpha 1: +500% improvement. ImgBurn 2.4.x Uses a lot of resources by itself. (1/3 of all system). Alpha 1: +100% improvement. Flash 9+ May leak GDI resources with problematic web pages. Alpha 1: not tested. Foxit Reader 2-3 Leaks a lot of GDI resources. Extremely unstable. Alpha 1: not helping. SolSuite 2008 Uses a lot of GDI resources. May consume all available resources. Alpha 1: not helping.

here be dragons

GDI Heap Extender is a technology aimed to improve Windows 98/Me system capability to load more programs and run more stable by extending available GDI resources. Alpha 1-5 apply extender technologies now only to one type of GDI resource - DIB bitmap, which is most common heavy resource. Beta 1-2 covers all bitmaps and thus saves more resources. Eventually, this technology will be included into Revolutions Pack. Beta (meaning - untested) version is aimed to ensure: - This technology will work on all systems and all file versions. - This technology is applicable to real systems. - This technology does not introduce problems with performance and stability. So, you can help me much by testing it. What you shouldn't see: - Crashes, BSODs and lockups. - Graphical glitches. - Resource leaks. Be aware: - Any crash would be fatal, and any error during initialization will lock up your system. Download: http://tihiy.ahanix.org/rpXbeta2.zip Beta 2 installs on top of latest RP9 (RP9.1.0) and replaces existing RP9 "GDI Salvation" techologies. Extract zip somewhere, right-click on .inf file and select "Install". Also: Please don't duplicate error messages. Please don't redistribute. Please read this thread.

You should disable KernelEx for it.

So i shouldn't do that? http://www.mediafire.com/?mzyuinr9mzl

RP9 causes this message, it's not related.And i must confirm other sites, GDIMaxHeapSize is in win.ini while USERMaxHeapSize is in registry. That's how it is.

Just unregister (and delete) msvidctl.dll.

however i'm highly unsure if it will work on DBCS systems.

Nobody is interested? Then i'll tell you how to increase GDI 32-bit heap now. 32-bit GDI heap is 2MB by default, that's pretty much; but, GDI actively utilizes this heap for storing small images and discarding DCs there. While it's not that easy to fill this heap, it is possible. With default 2MB heap worst case filling scenario would be ~200 48x48 images or ~5000 DCs (only likely if you're using leaky programs). So it's good thing to increase GDI 32-bit heap size. It would be required for heap extender to go all-out, too. Remember, this value is maximum size, not commited-at-once size. Don't ever set it smaller than 2MB. You can change this value by adding line in win.ini section [windows] (value in KB)I would think of values like: <128MB of RAM: 4096 (4MB) 128-256MB of RAM: 8192 (8MB) 256-512MB of RAM: 16384 (16MB) >512MB of RAM: 32000 (~32MB, maximum value you can set). Not likely you often run into this limit, but this knowledge is nice to recall.

If you have RP9 less than 9.1.0 or UberSkin, install latest GDI and USER versions:http://tihiy.ahanix.org/RPUpdates.html

I'm back with news, and news are not bad: a functional alpha version of GDI extender was created. My theory of decoupling handles from objects seems applicable (although there were lot of problems to make friends with GDI). For now, only one type of object is extended: DIB bitmap. DIB bitmaps are actively used in a lot of programs (unfortunately, most leaky programs like Foxs*** pdf reader, your card game, that VB tool are likely to use DDB bitmaps) and are very heavy (2 global memory objects + selector array). Applying extender on them allowed to increase best case object count from 1'200 to 12'000! That means you can potentially open 10 times more tabs in Opera 9. My favorite 3xImgBurn test showed twice resource usage drop, allowing me to open 6xImgBurn copies (with user heap extender alpha enabled too). Performance hit is negligible - 5% max in tests on my VM. So, wanna wanna wanna? I'm planning to include both technologies in Revolutions Pack 10 (with completely rewritten core). Beta testing may be possible, but i'm not promising any time / deadline.

You can disable crash catcher in FF3 by editing application.ini: [Crash Reporter] Enabled=0 Then post the crash here, with Dr. Watson log.

Yes, but it can be KernelEx problem depending on certain ugpraded library (like comctl32, shfolder).

Sounds bizzare, but do you have IE6 installed & updated?

Unfortunately i can't test newer versions on the same XP machine. Usually they instantly crashed everything running including taskmgr and crash messages, making machine virtually hung. I've tested 0.9.6 on my home dual-core XP machine, and it seems better - only explorer crashes (with runtime error / FastMM message) as other people reported. 0.9.7 made explorer stay a few more seconds till crash, but i don't think it's relevant.

Pre-0.3, i think.

Use FlushInstructionCache instead/with affinity hacking. Although I'm almost sure CPU cache isn't an issue. First SmoothText versions (without object-oriented junk) worked well for me, with dual core CPU and even Windows XP.

Find direct WMP9 link, that GenuineCheck s*** is not supposed to work on 98.

In RP9, you can run "rundll32 ktm8,Shutdown", although i wouldn't recommend you to.

That's right, RPConfig is not photo gallery manager. It will seriously slow down after 10-20 wallpapers, especially high resolution ones; speed depends more on hard disk, not CPU. I'm considering fixing this, but not that much... That's nice suggestion. Also nice, but i don't imagine a good mockup.

That's a bug in main.cpl (all versions). You can't work it around, it has to be patched...Or wait, i just was struck with idea! I'll provide a cpl which will mirror main.cpl, and main.cpl would be hidden from Control Panel.

Not fair to spoil exectations, but i'm here again with some news. New USER salvation is delayed due to my work on KernelEx 4 (finally) as well as other busy things. The news, i've figured out how to theoretically implement GDI heap expander without breaking compatibility, performance and memory usage. This includes a lot of things to hax: global memory manager, local heap handle manager and GDI insides, but seems possible unless I bump into hard compatibility problems. But theoretically, it can be very-very promising; i won't spoil numbers. Or did rloew already implemented one?

%windir% is not set until windows boots, and i believe it's proper behavior. Use %winbootdir%.

What's wrong with providing cpl file icons?Can you remove this abomination from RP9 thread?

eidenk, unless you use window skin, there is no differences in resource usage - since i know how to not use resources. You may want to cut RP9.1 into bare-bone by using only RP8.dll (deleting shl8.dll, uberhack.exe), but note, i'm about to change component dependencies.