Tihiy

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.

No, i can't since those programs are not developed anymore. But when could it be useful?

IE - based ones, for sure. Unlikely for others. Is there browsing scenario which eats a lot of USER (except opening lots and lots of pages)?

Yes. Most GUI programs.

I'm unable to help. There is a guide to remove RP7, but it requires a lot of skills and time.

I'm pleased to announce that future Revolutions Pack 9 version will include technology which will greatly reduce USER resource usage in common scenarios. After your reports and my research i found a big hole in USER heap which i'm able to plug. Hole I found is in the design of list and combo box controls built in USER subsystem which consume a lot of space in 64K heap. The issue is so bad that any application that uses list/combo boxes makes easily noticeable impact. Less than 300 combobox windows can be created on pure system (while global windows limit should be 16000). To solve this issue, combo and list boxes had to be completely rewritten. That was hard task (on which i worked on for long time), but it's near finishing. 'Beta' version is kinda ready, but there are known compatibility problems and RP9 re-architecting tasks to be done. Test numbers: My unscientific 'Load 3 ImgBurn copies' test shows 65% USER free up from 39%. If you're interested in your scenario, i'm ready to test it.

This has nothing to do with sysmon version, really. It's a bug in performance measurement in 9x. Every application which uses registry CPU usage data can suffer from this.

You haven't provided any proof there is a problem. I can't trust sysmon which is often starts giving high CPU usage. If you say problem is apparent, then prove me how do you notice high CPU load - is there sluggishness or problems with multi-tasking or sound playing or what?Also: http://support.microsoft.com/kb/227131

My debug builds of course had this feature. Maybe I would publish them.Now i'm busy with long-secret feature, which I hope will find way to RP9. Stay tuned.