Winapp2.ini
-
Posts
6,470 -
Joined
-
Last visited
Posts posted by Winapp2.ini
-
-
Hey Ishan! Hope you've been well!
-
7 hours ago, siliconman01 said:
I tested this on my system and CCleaner cannot remove the files because they are in use. I assume the system has to be running in Safe Mode for these to be deleted ??
If I try to delete the files manually, it shows what is using these files.
They're being used by the Connected Devices Platform (user) service. Stopping it should allow the files to be deleted. Not sure if you'd need to stop the parent service (Connected Devices Platform) too
-
1 hour ago, PICPro said:
Unfortunately, it does not: "not a valid Win32 application", same as trying to run regular Winapp2ool.exe. Comes up with "not a valid win32 applicaion" both in XP64 and regular XP.
I think this might just be a build configuration issue, I'll tinker with visual studio and see if I can get it built correctly
-
DeleteMe keys are definitely caused by winapp2ool, I'll look into it! the beta version supports keys without a value so it may be worth checking out whether that fixes the issue
Edit: This issue is not present in the beta, but it WILL break any intended functionality of the LCD keys which are not formatted the same way as other keys (though if I had to guess this is a ccleaner bug?)
-
28 minutes ago, PICPro said:
Just a report in case you want to add support for this:
In "winapp2oolXP.exe", I have a computer here that comes up with unable to identify operating system version when trying to trim and says to report the following:
out: 5.2
This is a Windows XP Professional 64 bit service pack 2 computer. Trim.bat works but winapp2ool.exe would be a lot nicer. Regular winapp2ool.exe doesn't run on this computer.wow! does this build work? https://github.com/MoscaDotTo/Winapp2/blob/Branch1/winapp2ool/winapp2oolXP.exe
I thought it might be a quick fix so I just targeted that one change, this version of winapp2ool xp may be otherwise unpolished. if things seem weird let me know, and definitely let me know if it crashes still
-
On 09/09/2019 at 19:47, Winapp2.ini said:
Thanks for pointing this out, I'll look into it when I get some time
@dvdbane this should be fixed in the latest beta build, sorry it took so long!
-
4 minutes ago, don_dolarson said:
Is there a way to get rid of applications that I no longer use? These marked with * coming from winapp2.ini and these wihout it. I've used couple of application once and they remain on the list after they've been uninstalled for a long time ago.
You can try running the Trim function of winapp2ool to rid yourself of these entries, however if CCleaner is detecting them and showing them to you, it means the removed software left whatever aspect of itself winapp2.ini is using to detect it.
You have two options for ridding yourself of these "leftover" entries: manually delete the entry from winapp2.ini (be aware that it may return if the detect criteria are still present on the computer - which it sounds like they may be!)
or
manually delete the detect criteria from the computer. This will prevent CCleaner from detecting the entry as valid and will cause winapp2ool to actually Trim these entries out of your file after you've done it.
-
Just now, APMichael said:
Yes, such a check would be helpful. But please note that wildcards are allowed before the pipe symbol (in the path). Wildcards should therefore only be checked after the pipe symbol.
Good point, thanks!
-
4 hours ago, APMichael said:
The use of the semicolon (;) is not always invalid. If wildcards are also used, it may be used. Please see example 5: https://www.ccleaner.com/docs/ccleaner/advanced-usage/ccleaner-ini-files/how-to-exclude-items-from-ccleaners-cleaning.
Perhaps a check for wildcards (and semicolons) in ExcludeKeys with the FILE switch will suffice
-
1 hour ago, don_dolarson said:
How can I test it? I'm definetly a noob
https://github.com/MoscaDotTo/Winapp2/#how-to-use-winapp2ini-for-the-following-cleaners
-
15 hours ago, siliconman01 said:
In recent days, when I run Winappool version 1.02, it states that the tool is offline. Is this fact or is there a problem somewhere? I am running Windows 10x64 Pro Build 18363.476 V1909 and my default browser is MS Edge Chromium.
This is an error, I'll look into it when I've some time this week
-
Just now, APMichael said:
Unfortunately, they mostly use SpecialKeys for browsers, so the changes are not visible in winapp.ini/winsys.ini.
(The latest update with the addition "recent searches in Microsoft Outlook" also uses a SpecialKey.)
Generally what I expected, the limitations of the (front end) scripting interface are pretty apparent when you consider some of the problems we try to tackle with winapp2.ini (and increasingly lean on code generation from winapp2ool to handle). barring some major rewrite of their ini interface, i would expect increasingly many future additions to the application to rely on these.
-
4 hours ago, APMichael said:
Thank you for pointing that out.
I really wish that Piriform would let us know if they were implementing anything from the Winapp2.ini. The change logs are often not very detailed.
The changelogs used to be more specific about winapp and winsys changes. the best option is to diff the built in ini files between versions
-
On 09/09/2019 at 19:47, Winapp2.ini said:
Thanks for pointing this out, I'll look into it when I get some time
@dvdbane Do the keys that are not in wow64node exist on your system too?
-
20 hours ago, dvdbane said:
Hi @Winapp2.ini
winapp2ool v1.2.7175.37819
weird thing happen when using trim for this location HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Foxit Software\Foxit Reader
Detect=HKLM\Software\Foxit Software\Foxit Reader = trimmed(wrong)
Detect=HKLM\Software\Foxit Software = not trim(correct)
tested this location HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SHAREit Technologies\SHAREit and winapp2ool trim correctly
just for testing purpose, tested this location \SHAREit Technologies\SHAREit Tech and winapp2ool trim correctly
[Foxit Reader **]
LangSecRef=3021
Detect=HKLM\Software\Foxit Software\Foxit Reader
Default=FalseThanks for pointing this out, I'll look into it when I get some time
-
4 hours ago, Stephen CCleaner said:
Winapp2 is great tool in the right hands, but we do not officially support it and it's definitely not considered 'default configuration'.
You can change your CCleaner home screen in the Options > Settings menu or, prior to running CCleaner, via the HomeScreen registry key Computer\HKEY_CURRENT_USER\Software\Piriform\CCleaner ("0" = Custom Clean, "1" = Easy Clean).
If that doesn't work for you, please let us know your specific use case and environment and we can see what we can do.
It may be worth looking into the fact that although Easy Clean doesn't support winapp2.ini, it does seem to be doing expensive work when a winapp2.ini file is present
-
43 minutes ago, mxz55 said:
Even though I added a note about this being unrelated to trimming, you seem to not have understood my point either.
The thing is that there are now 2 delays: the trimming thing (big amount of entries), and a long delay of CCleaner even appearing on newer versions due to the presence of Winapp2.ini, when the launch screen is Easy Clean. During this time, CCleaner won't be visible entirely, but only in Task manager as a process.
I must admit I did not attempt to reproduce the behavior before making my post and I do see the perceived difference between the issues
If I had to guess, when CCleaner loads the Easy Clean mode (either by default or when switched to as a tab if not loaded first), it force reloads its configuration including winapp2.ini (even though it is not used) and does so before it displays its pane (ie. before the ccleaner window is spawned if the easy clean tab is the default), probably blocking the main thread while it does so
If you set the default tab to custom clean, you'll observe the normal delayed availability of the buttons as expected, but when switching to the custom clean, my ccleaner window became non responsive before switching and then once again after it loaded
The best you can do to treat this as an end user is to trim winapp2.ini which is why I suggested it; Given that this seems to be a pretty glaring ccleaner bug, I'd suggest you post it to the bug report sub forum: https://forum.piriform.com/forum/8-ccleaner-bug-reporting/
I'm not a ccleaner developer so I don't have the agency to fix the bug you're describing here, but I think they'd be keen to hear it.
I think ultimately the slow loading of the large ini is the fault here and you'll see it whether it happens before or after the window displays itself; untrimmed ini clearly had the longest delay on my machine, the trimmed ini was still slow to load but noticeably faster, and an empty file just called winapp2.ini caused no delay at all
-
1 hour ago, mxz55 said:
I know CCleaner principally doesn't support add-ons like this, but perhap @APMichael or @Winapp2.ini can kindly request Piriform developers to find a solution, so that addons like this won't deteriorate the user experience by default. Especially as this is an issue brought on by CCleaner getting changed. If Custom Clean is incompatible with Winapp2.ini (and the core progra tries to load it there if its the start screen) then it should be only 1 line of program code to stop the ini from being loaded in that case, until Custom Clean is opened.
The general solution to this is to trim the winapp2.ini file, ccleaner will load much more quickly. I wouldn't imagine CCleaner's mechanism for loading entries was ever intended to handle the thousands of entries the untrimmed file contains
11 minutes ago, nukecad said:I think the point is that Easy Clean is meant for people who have no technical knowledge whatsoever.
So it does not support custom settings and winapp2 is a user based set of custom settings.
TBH I'm not sure why anyone using winapp2 would even think of using Easy Clean - the two things are so far apart.
I think this is right and the suggestion i'd have is for the developers to simply defer loading winapp2.ini until the custom clean screen is loaded if it's not supported in the easy clean
-
It follows the same structure as %appdata%\mozilla\profiles
-
Just now, CSGalloway said:
A lot of FireFox users have %userprofile%\Desktop\Old Firefox Data\ and I think it would be nice if there was an entry that would clean this and similar named folders.
Should definitely include a warning alongside this if one is created; this folder is typically created as part of the "refresh firefox" process and can contain important data. It's also optionally created when uninstalling firefox as a profile backup
-
-
Enabling BITS on nightly for me results in the update downloading only after pages have loaded
-
I think the Clover entry is correct as it is, IIRC.
-
The new firefox branding seems to be launching
Winapp2.ini additions
in CCleaner
Posted
Hopefully this version doesn't suffer from the same false positive problem the previous ones have but if it does we'll use the release version on the page above as the watershed release to have vendors whitelist