Hi guys ... apologies for the headaches ... we've been waiting for the Vista SP1 "release" to step up with a bunch of fixes, and they claim "RTM" has been released now ... however, with a problem confirmed a few weeks ago with the EXCLUDER, and many problems with corrupted downloads as a result of plain "bad transfers" or windows just shutting down without warning in the middle of the download, this all has become a bit more pressing, and we might not want to wait given all the complaints lately and instead do *another* version after we've seen all that Vista SP1 might have broken.
It's up to "demand" as to the priorities ... are THAT many people suffering hosings?
BOClean 4.25 was a redesign from prior versions in which we expected that the PRIOR download would be OK and if anything went sideways, simply saving a GOOD copy and then restoring *that* should have made things happier in the event of a bad download to 4.25. Sadly, Windows managed to fool BOClean into saving a corrupted backup anyway, and that's MY fault as I'm the one who designed it that way. And THERE is the problem. In our *next* release, we're not going to bother doing this, as it was a miserable failure to many people with other things interfering with downloads, and thus we're planning to change the code as follows ...
IF you get a bad download, the "corrupted database" warning will occur as before. However, the ACTION on a bad download will be to put up a warning advising of a bad download, provide instructions to go to the start menu, COMODO group, BOClean and click on the external "updater" and then just shut down BOClean so YOU don't have to. You'll then be advised after going to the BOClean "group" and then restart BOClean from there. This will elimanate the need to shut things down to regain control and you'll be warned if the RE-download is somehow hosed as well. We tried to make things a bit saner in the previous design, but for those caught up in a bad download, only seemed to make things crazier which was NEVER our intent. This will be fixed in the next release.
I've ALSO come here though to explain one OTHER complaint that has been thoroughly disproven - that of "BOClean being CPU piggy" after much research and time wasted in it (I don't mean the "100% thing" which is OBVIOUSLY another proggie interfering with our kernel driver and nulling out its communications with our DLL [this effect was caused DELIBERATELY as a warning that your system ain't right] - that I still don't see any solution to other than deleting the offending "hoseware" which is causing it) ... here, I'm talking about BOClean eating about 16 Meg of memory (or even more) if you use the ctrl-alt-del and reading that. As it turns out, it's XP causing that memory assignment, not us! I redid the code QUADRUPLING the memory assignments within BOClean for experimentation, and it made no difference! Same for SHRINKING it by a factor of eight!
We once again need to expand the amount of space for BOClean in our next release owing to more and more nasties and the need to spot variants, and in redoing the code, I've discovered that whether we shrink or EXPAND memory allocations for what BOClean *really* needs in memory, it's makes NO difference until we expand it more than 16 times what we might ever need that the numbers actually rise. I've had philosphical battles among our own COMODO "elite" as to these memory issues, and internal arguments over "leaks" and they are CONFIRMED not to be BOClean, but rather Windows memory management itself! Seems as though there's a whacky design in XP and Vista where the system itself allocates memory which is NOT required based upon what it determines is "failures of hits" to "paging errors" and those come from our opening and closing of the file syste, and various internal Windows protections rather than anything in BOClean's code ... reason why I've been so tied up lately is trying to FIND the problems in the code I've written and there *ARE* no faults in my code after all ... talk about "chamionship pud-pulling" trying to find where I went wrong and it wasn't me ... MOST frustrating indeed!
I can always fix what I write, but ya can't fix WINDOWS.
So ... for now ... NEXT build (coming soon) ... excluder, fixed! Update corrupution, fixed! Driver/DLL communications errors, FIXED! But I dunno what we can do about those elusive issues, no matter what I've done to reproduce them, I cannot ... however, additional diagnostics writes HOPING to spot them have been added ... so all I can say to all, is HAVE faith! We probably have fixed it in what we're about to release, but if not - we finally have a bit more detail in the diagnostics to spot the few remaining "huh?" factors. =)
Please feel free to spread this info, as required ... moo! (grin)
Author