RegSupreme Pro 1.7 RC2 released

jv16

RegSupreme Pro 1.7 RC2 is now released, you can download it from:

http://www.macecraft.com/downloads/betas/RegSupremePro_setup_RC2.exe

(if the link doesn't work, it means the beta testing for this version has already ended)

Warning

Do not install this program over any previous version of RegSupreme Pro, always install beta and RC versions to a new directory. This product version is not an official release, it will contain bugs and can cause harm to your computer. Do not download or install this program unless you are willing to take the risk and understand what beta testing means.

On Beta Testing

All beta testers who submit valuable feedback, such as bug reports, performance reports, improvement ideas etc, will receive a free personal license for the product after it has been officially released. Simply installing and testing the application doesn't mean that you would automatically receive a free license, free licenses are issued only to those who submit valuable feedback.

General Release Notes

* All the current translations are included in this version, although they need some minor adjustments to be compatible with the new RegSupreme Pro, RegSupreme and jv16 PowerTools products. Feel free to do these modifications and send the updated translation files back to us, there shouldn't be any more changes to the translation files.

* This version doesn't work with Windows 9x (most likely crashes)

Changes from the RC1 version

* All reported, non-trivial bugs should be now fixed.

* All features are now implemented, including the Help > Check for updates

Please send all your feedback and bug reports to this thread (use the Post Reply Button, NOT the new topic button).

Thank you very much.

redseujac

1) Useless subdirectories "Snapshots" and "Tasks" still present under Main Directory of RSP after installation of RegSupreme Pro

2) It takes quite some time for "Shell Extensions" in Registry Manager to start: when starting the first time it took 48 seconds for the first item to be listed, when starting the second time it took of course less time (21 seconds).

Notice that the reported under (2) was already present in previous versions (beta1 and RC1).

tullik

Registry Cleaner, Custom Fix

Refer to the test described here …

In v.1.7.0.408, CF still places the Value correction in the Name field instead of the Value field, and then adds the resulting invalid item to the registry. The original error item remains in the registry unchanged.

Registry Cleaner, Abort run-on bug

Refer to the post here …

When I click "Abort" 20 seconds into the scan, RC still use 50% cpu for another 35-40 seconds. Most (~80-90% ) of that usage is in the kernel.

When I click "Abort" 20 seconds into the scan, then click "Close" on the results window, the results window goes away, but RC still use 50% cpu for another ~30 seconds. Most (~80-90% ) of that usage is in the kernel.

I don't think this bug is fixed. Its impact is possible user confusion or anxiety.

Registry Compactor, incorrect arithmetic in messages

To confirm this fix, one needs a hive which gets megabytes of compaction. It would be many weeks before I might have a hive with this condition. I'm assuming it is fixed …

Registry Cleaner, Scan Report, Statistics, unnecessary checkboxes

Fixed

Registry Cleaner, no "File reference scan finished" message

Fixed

Registry Cleaner, Structured list, context menu backups incomplete

Fixed for "Select all"

Except for "Select all," it is impossible to tell reliably what is selected -- but that's a different problem. :

Even with "Select all," it is more an assumption and hope than a certainty …

Advisory

An advisory showing the current RC2 status is here: http://www.macecraft.com/phpBB2/viewtopic.php?p=10936#10936

tullik

PowerTools Registry Cleaner Comparison

Comparison procedure:

* The Vista registry was cleared of detected "errors."

* Method: ran the Registry Cleaner (RC) in v.1.7.0.408 (RSPro RC2) and the one in v.1.5.2.350 (PT2006) and deleted all items found.

* Rescans by each program showed zero lines.

* A large set of errors actually found by RC over the last eight months was then restored to the registry.

* The runs shown in Table 1 were made to get the lines found and run times for the versions shown.

* Lines found is from the results window status bars.

* Run time is from the Scan Reports.

* The "errors" found by v.1.7.0.408 were then deleted and all the runs were repeated.

* Afterward, a few items were Customed Restored to check for duplication ("twinning") by windows.

Table 1: data fields are Program version -- lines found -- run time in seconds

First run

v.1.5.2.350 (PT2006) -- 467 -- 30.5

v.1.7.0.399 (PT2007) -- 289 - 109.4

v.1.7.0.405 (PT2007) -- 434 -- 92.2

v.1.7.0.408 (RSPro) ---- 448 -- 88.8

Rescan after delete using v.1.7.0.408

v.1.5.2.350 (PT2006) -- 25 -- 41.8

v.1.7.0.399 (PT2007) --- 0 - 105.5

v.1.7.0.405 (PT2007) --- 0 -- 94.4

v.1.7.0.408 (RSPro) ----- 0 -- 93.9

Conclusions:

* V.1.7.0.408 found all the "errors" found by the earlier PT2007 versions

* PT2006 found file reference errors in a few keys missed by PT2007 (24 lines)

* One empty key apparently re-creates eventually as windows operates:

* Up to 33% of the "does not exist" errors listed by PT2006 RC are due to "twinning" by windows

* Up to 33% more of the "does not exist" errors listed by PT2006 RC are due to a bug in that program (outright duplicates)

* V.1.7.0.408 still lists both siblings in certain HKLM/HKCU and HKCU/HKUS twins (up to half the "does not exist" errors)

* A PT2007 RC scan run time is about two to three times that of a PT2006 RC scan

jv16

tullik wrote

Refer to the test described here …

In v.1.7.0.408, CF still places the Value correction in the Name field instead of the Value field, and then adds the resulting invalid item to the registry. The original error item remains in the registry unchanged.

Please give exact steps and the data on how to reproduce this problem. I have tried with the Wordpad registry data and haven't been able to reproduce the problem any longer with the RC2.

jv16

tullik wrote

Registry Cleaner, Abort run-on bug

Refer to the post here …

When I click "Abort" 20 seconds into the scan, RC still use 50% cpu for another 35-40 seconds. Most (~80-90% ) of that usage is in the kernel.

When I click "Abort" 20 seconds into the scan, then click "Close" on the results window, the results window goes away, but RC still use 50% cpu for another ~30 seconds. Most (~80-90% ) of that usage is in the kernel.

I don't think this bug is fixed. Its impact is possible user confusion or anxiety.

Did you use the structured list or the raw list mode? What scans did you run and on what stage did you hit abort? (i.e., about how many threads were still running?)

I have tested this and it takes less than 5 seconds in my computer from the Abort click to the cpu usage dropping to near 0% per TaskManager.

tullik

jv16 wrote
tullik wrote

Registry Cleaner, Abort run-on bug

Refer to the post here …

When I click "Abort" 20 seconds into the scan, RC still use 50% cpu for another 35-40 seconds. Most (~80-90% ) of that usage is in the kernel.

When I click "Abort" 20 seconds into the scan, then click "Close" on the results window, the results window goes away, but RC still use 50% cpu for another ~30 seconds. Most (~80-90% ) of that usage is in the kernel.

I don't think this bug is fixed. Its impact is possible user confusion or anxiety.

Did you use the structured list or the raw list mode? What scans did you run and on what stage did you hit abort? (i.e., about how many threads were still running?)

I have tested this and it takes less than 5 seconds in my computer from the Abort click to the cpu usage dropping to near 0% per TaskManager.

Maybe it's a Vista anomaly -- I'll check it on my XP Pro laptop and get back to you ... first, I'll have to install RC2 there ...

tullik

Regarding the Abort run-on issue: apparently what I reported only happens now in Vista. I'll mark the item as fixed. It's not a very important thing anyway, so, at this point, not worth spending more time on it just for Vista, IMO.

tullik

I'll get back to you on the Custom Fix issue ... I'll recheck in XP Pro in case there's a Vista difference (shouldn't be, I think ...).

What about the Startup Manager issue? Giving RSPro users a new feature (Disable/Enable) which doesn't work is not a good idea, IMO. :(

http://www.macecraft.com/phpBB2/viewtopic.php?p=10950#10950 - Startup Manager, disabled programs start during windows restart

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Workaround: none

tullik

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

jv16

tullik wrote
jv16 wrote

I have tested this and it takes less than 5 seconds in my computer from the Abort click to the cpu usage dropping to near 0% per TaskManager.

Maybe it's a Vista anomaly -- I'll check it on my XP Pro laptop and get back to you ... first, I'll have to install RC2 there ...

I can't reproduce this under Vista either. I'm running a virtualized Vista Home Basic and the delay after Abort is about 5-10 seconds.

Still, I have now made some improvements to the registry cleaner engine in order to speedup the abortion process. The version I ran under Vista is the same you have, the RC2.

jv16

tullik wrote

Procedure to reproduce the error (performed on an XP Pro system):
1. Create three files called haiku.rtf in different locations and open each one with wordpad; close them.

Could you try this with a different set of data? I'm a bit worried about the strange looking directory names on your test data (C:\+A\!C).

I have tried to reproduce the problem now with the identical test data under both XP and Vista and couldn't been able to reproduce it any longer. I was able to reproduce the problem with RC1, but not with RC2.

jv16

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

tullik

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

jv16

tullik wrote

Since that report (made during RC1), I have turned off UAC. I don't know if that had anything to do with it … anyway, I'll take the Startup Manager item off the advisory list.

I'm very glad to hear. However, I don't think UAC has anything to do with this since I ran the tests with UAC enabled.

tullik

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

tullik

jv16 wrote
tullik wrote

Since that report (made during RC1), I have turned off UAC. I don't know if that had anything to do with it … anyway, I'll take the Startup Manager item off the advisory list.

I'm very glad to hear. However, I don't think UAC has anything to do with this since I ran the tests with UAC enabled.

I also doubt UAC is involved here. However, turning it off changed the behavior of the first three items in this "Vista only" list: Probable Vista Issues

tullik

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

tullik

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

tullik

jv16 wrote
… Still, I have now made some improvements to the registry cleaner engine in order to speedup the abortion process. The version I ran under Vista is the same you have, the RC2. …

Those improvements worked very well -- see the added notes in the prior post here.