Forum Replies Created
-
Posts
-
I’ve identified this bug and issued an immediate fix.
The downloads on the website have been updated with the corrected file. Those who have already downloaded 3.0.1 might receive a silent automatic update; but it’s very likely the Windows firewall will block it. If that’s the case, the easiest option is to just re-download it from the download page (free) or download hub (pro).
Sorry for the inconvenience.
I’m not quite sure what you’re trying to say here. Are the folders you’ve selected for exclusion still being detected?
[quote quote=9820]I can’t download latest version. please fix link.thanks[/quote]
Link is working fine for me.
‘DetectOS’ without a standard ‘Detect’ line following will cause it to be trimmed.
I’ll get this fixed in the next version. In the meantime, something like ‘Detect=C:\Windows’ will do the trick.
We could always take the Piriform approach and include JavaRa.exe and JavaRa64.exe in the downloaded archive.
Most people will automatically run JavaRa.exe, even if they’re on a x64 system; so the x32 binary would need to detect the OS and call the x64 binary when necessary. This call could be disabled if the user specifies a commandline argument, as it would be assumed such a user would be aware of the implications of calling the wrong binary.
Thoughts?
There’s still no ETA for a bug fix.
Just to give you a bit of background information; the issue is being caused by differences in Windows x86 and x64. Each stores the list of installed programs (and the MSI uninstall string) in a different location in the registry. The Windows registry is pretty cruel; automatically redirecting JavaRa’s registry access to the WOW6486Node (on x64) and throwing the “object reference not found” error when it realises the redirect was an idiot move.
The workaround is pretty simple. Setting the compiler flag to “x86” prevents the redirect from occurring, but makes the x64 registry hives invisible to JavaRa. Compiling against “Any CPU” has the inverse affect.
The logical answer would be to compile two different versions of JavaRa; but obviously this isn’t practical if being run across a network, as many different OS setups could be in use.
We’re currently investigating a workaround method that involves invoking native code, thus circumventing Windows’ annoying registry reparse “feature.”
The System Ninja registry cleaner uses the exact same rules as CCEnhancer adds to CCleaner.
If there’s a warning present in CCleaner, it should also be skipped automatically by System Ninja. That being said, I’ll double check the code shorty to make sure this is the case.
I like the exclusion list idea, too. Thanks for the great suggestion!
