Winapp2.ini

Thanks! This has been fixed, which winapp2ool will probably inform you of, but will require a manual redownload

A new version uploaded only just a few minutes ago is available. It now checks for updates against the GitHub version and notifies the user in the menu when an updated winapp2ool is available. Enjoy!

I've uploaded a new version of winapp2ool that fixes both this and the numbering issue (which was in the trim module as a result of some refactoring) All modules have had their behavior modified, and the menus have all been tweaked to be more consistent as well

I would guess that ICS here means Intelligent Cookie Scan and the value of this key is the CCleaner build during which you last ran the intelligent cookie scan.

I have uploaded a new version that should address these issues: https://github.com/MoscaDotTo/Winapp2/blob/master/Tools/beta/winapp2ool.exe

I have updated winapp2ool considerably and made available the source code. https://github.com/MoscaDotTo/Winapp2/commit/b69b08c54e70929c2ca8c33ec0a5fdec5f11b8cb Notably, I made a fix to trim such that it will actually respect the hive provided by Detect= entries, it previously ignored any markers such as HKCU, HKLM.. etc and checked all hives simultaneously, which can (strangely enough!) lead to "false" positives (eg. a key exists in HKLM but not HKCU, while the detect is for HKCU. Thus trim would count is as valid but CCleaner would never present this entry, presumably.)

I've uploaded a new version of winapp2ool that should address both the ExcludeKey error checking in WinappDebug and the detectless entries being ignored in the trim module.

I've just uploaded a new version of winapp2ool, give it a try. The trim module has been tweaked a bit to prevent it from outputting a bad ini file. FWIW I think there may be some bug in trim.bat because it also generated more entries for me, but some of them should not have been detected as being on my system.

You may want to try running the .NET Repair Tool are you including the .ini extension when entering the file name? (you should be!) ' Have you tried running just the trim module? It doesn't call any code from diff so it should not trigger a crash in that module as far as I'm aware. Does the error still occur if you move to tool to a less privileged folder?(ie. downloads) Thanks for trying it out!

The output is generated based on the file contents, so I must have used a version from before that PR was merged to produce it, or else it's absence in the later file would have triggered the "was removed" line. The next time I post a change log, this change will most likely make itself apparent.

Here is a demo of the new multitool (winapp2ool): https://github.com/MoscaDotTo/Winapp2/tree/master/Tools/beta Please give it a try, it includes a slightly improved WinappDebug, ccinidebug, a new module called "diff" that compares two winapp2.ini versions and outputs the changes, and a trimming module with an option to both overwrite the existing winapp2.ini file or to output to a new file called winapp2-trimmed.ini Recommended that you run it as an administrator, many of the functions don't work will without elevation. Trim especially, as it can't access certain registry keys without elevation and will as a result, erroneously trim entries from your file.

This one IS a changelog.

I've completed the basic work for this now actually. It's not ready for public release just yet, but it is functional. Here is an example of the output: NOTE TO READERS: THE BELOW IS NOT AN OFFICIAL CHANGELOG OF ANY SORT AND SHOULD NOT BE INTERPRETED AS ONE. IT IS SIMPLY THE OUTPUT OF A CLASS I AM TESTING THAT WILL EVENTUALLY REPLACE THE BACKBONE OF THE CURRENT SET OF TOOLS SUCH AS WINAPPDEBUG. I have provided it for feedback purposes only

https://github.com/sindresorhus/refined-github this browser extension removes diff markup from the copy/paste with the addon: FileKey1=%LocalAppData%\SuperBird\Application\*\Installer|*.7z FileKey2=%LocalAppData%\Torch\Application\*\Installer|*.7z FileKey3=%LocalAppData%\Vivaldi\Application\*\Installer|*.7z FileKey4=%LocalAppData%\Yandex\YandexBrowser\Application\*\Installer|*.7z FileKey5=%ProgramFiles%\Google\Chrome\Application\*\Installer|*.7z without: +FileKey1=%LocalAppData%\SuperBird\Application\*\Installer|*.7z +FileKey2=%LocalAppData%\Torch\Application\*\Installer|*.7z +FileKey3=%LocalAppData%\Vivaldi\Application\*\Installer|*.7z +FileKey4=%LocalAppData%\Yandex\YandexBrowser\Application\*\Installer|*.7z +FileKey5=%ProgramFiles%\Google\Chrome\Application\*\Installer|*.7z Longer term though, I have plans to redesign the current ini tools to use an object model that would be much more compatible with producing a tool that output diff of the sort that would include only the changed state of the modified entries. The way I've been approaching winappdebug (for example) is iterative based on an existing design provided by Shane that reads the files line-by-line, which doesn't lend itself well to this.

see I think the commit log does a much better job of tracking the changes than I ever did with changes.txt

https://github.com/MoscaDotTo/Winapp2/commit/b9014bbedd4c7ba801d548d86a89c5f3afd4db89

It would be helpful and more actionable for contributions to be submitted as PRs on GitHub Not a requirement, but it'd be easier to keep discussions about particular entries together instead of spread out over the course of several forums pages. Either way, thanks for all the hard work folks!

We've dabbled with this idea in the past ("dangerous entries" and "langfiles" inis both briefly existed at some point or another). ini files beyond winapp2.ini never got much traffic though, so I stopped maintaining them.

I didn't mean to suggest that the average user should need to go through this. Merely recounting the relatively quick sleuthing of users who are particularly attentive to Firefox. It is my understanding that the addon was pushed through the SHIELD system prematurely, and that while most of the information needed to understand it existed in some form or another, it was not a complete package in the way that it is currently shipped (notably, the information page is now populated with actual details of the addon, it was merely an empty article at the time of the addon push - which only lead to more confusion) At the end of the day though, they pushed something that effectively didn't do anything at all to people without explanation, and given the (mostly deserved) blowback for their lack of transparency, I tend to doubt it'll happen again. If it does, perhaps I'll feel more warmly towards a literal middle finger at the bottom of an article.

They certainly chose a poor approach for it, using the SHIELD studies feature; but I think the article is rather hyperbolic to the point of coming off as both immature and uninformed. I happened to have been actively following the Looking Glass fiasco as it unfolded via /r/firefox. Savvy users quite quickly made the link to Mr. Robot by looking through the code for the addon (found on GitHub), and soon discovered that the addon was totally inert unless you modified an about:config:preference to make it function. Upon doing so, it would flip some words up-side down and prompt you to follow a link to an incomplete information page (incomplete presumably because the study was sent out prematurely). It did not otherwise collect or transmit any data. As someone generally opposed to ads, I see and understand the resentment. However so far as I know, there was no profit motive here like the article suggests. Mozilla is a non-profit, and the bulk of their operating income comes from their search engine partnerships. I do think some blame falls upon users for not being more attentive to the SHIELD preferences. Being opted-in to studies explicitly allows Mozilla to push, without warning, addons to your browser the modify your user experience. Whether or not one thinks those settings should be enabled by default is surely a topic for discussion, but somewhat besides the point given the reality that they seem to be. (they certainly are on by default for Nightly, but I do not know the default setting on a clean profile using only the Stable release channel, I imagine that it is "on" though. Clearly the author did not carefully check Firefox's about:preferences#privacy page (perhaps they overlooked the complete redesign of the preferences in Firefox 56 during their review of Firefox 57), or he would have seen that not only were those boxes ticked, but the studies one even helpfully links to about:studies which itself links to SHIELD study information I think Mozilla had a poor response to user outrage initially, and they were essentially forced to make a second apology because of how lacking their initial response was. At the end of the day, while Mozilla acted here in bad faith of their users, I don't think they did so in an intentionally malicious manner and the real-world impact of what they did was to scare a bunch of people who thought they may have had malware (that they didn't). I don't think this makes Mozilla " Yet another shark in the pond, after its share of filthy dimes." I am not a reader of this website, and do not know if this manner of writing is typical of their articles, but it comes off (to me) as rather petulant. So at the risk of sounding like a Mozilla apologist, I don't think the author is informed enough about Mozilla as an entity (particularly what they do outside the scope of developing Firefox) to make some of the claims he does. Was Mozilla wrong to use the SHIELD study system to push out promotional content? Probably. That's not what the system is there for. Did they have the "right to" push content without asking? You could argue that "yes because that's what being opted into studies means." or "no because studies seem to be on by default and shouldn't be." I don't think they should be on-by-default on the Release channel (if that's the case), but I think it's absolutely reasonable for them to be on by default in both Beta and Nightly given that the purpose of those channels is to test prereleases and new features of the browser. It's not as if there aren't other browsers, but the author themselves after all that moaning even says they'll be sticking with Firefox because it's the least annoying. So while I am both a fan of Mr. Robot and Mozilla & what they do, and I recognize the user-trust implications of what happened (at a time where they're struggling to regain market traction), I don't particularly care for this article itself.

That's currently what we do, I think it's the appropriate approach given that games don't really feel like they "belong" to any of the default CCleaner LangSecRefs.

Author's loss on this one, IMO. I happen to quite enjoy Mr. Robot.

Steam definitely fits better under Games for our purposes (not a category that exists by Default in CCleaner) given that there are almost 400 entries in winapp2.ini (for reference, winapp.ini has only 402 entries total) that target games. Beyond the basic Steam entry, I don't think Piriform supports anything targeted at gaming.

I'm aware of this, it gets worse if you run ccinidebug in succession. I'll take a look at fixing it this weekend (and updating the tool to be aware of the new naming scheme) Pretty sure it's caused at least in part by the EOF newline getting bumped to the top during sorting

Cleaning has not been reduced here, rather, we merged many entries (eg. Sync Logs, Update Logs, TestPilot Error Logs -> Firefox Logs) together to produce the same cleaning results with less visual clutter in the interface. This applies to the whole file, you should see significantly fewer entries presented in the interface, however most/all of the same paths and files are still cleaned. Some firefox entries are no longer needed (net predictions was a feature that was axed a long time ago and no one running any supported version of Firefox would have this file) or are already included in CCleaner's cleaning (Session Backups)