At least as far as I can see. Microsoft.Paint is the appx name for
Paint3D. I often confuse it with Microsoft.Print3D, and perhaps
that is what has happened here as well.
https://github.com/Sycnex/Windows10Debloater/issues/107
1.) dynamic list of all installed apps, indicating current status.
This enables instant verification of the effectiveness of
running a debloat.
2.) white/blacklists regex/matching name retained. (Doesn't
change to match the actual full/installed name.)
3.) indentifies NEW apps not in any black or white list.
4.) notes conflicts between NonRemovable/White/Black lists.
Potential enhancements
A.) I placed the save button at the top of the form because
it was easiest to do. I don't know how to put it at the
bottom of a dynamic-length form.
B.) Currently the white/blacklist are only updated in the
running program when the saveList button is pressed.
That means that all of the NEWly found bloats which
are checked as bloatware will not be removed, and any
changes the user makes also don't take effect until
they are saved. I supposed an OK button could handle
that (but then a cancel button would also be needed).
Step 2 is to add a GUI.
This step 1 patch is the minimal requirement
for custom blacklist functionality.
https://github.com/Sycnex/Windows10Debloater/issues/68https://github.com/Sycnex/Windows10Debloater/issues/110
1.) Make the black/whitelists global - so they can easily be
modified from functions and forms (needed for step 2)
2.) Put the lists at the start of the script to make it
easy for people to find and browse through the lists.
3.) One item per line to allow for better documentation.
I added as many notes as I could. Documentating the
reasons for black/white-listing is very valuable.
4.) Both whitelist and blacklist entries can be used as REGEXs.
That can cause a bit of confusion perhaps, but probably
necessary for flexibility. I turned ON case sensitivity
to offset that a bit (using .NET as the prime example
which otherwise falsely whitelists .NetworkSpeedTest)
In theory, these should be merely cosmetic changes and any
change in behaviour should be considered a bug.
5.) Provide the user a persistent, customizable white/blacklist.
custom-lists.ps1 should NOT be added to GIT,
so that a "git pull" does not change their custom settings.
Step 2 will provide a GUI to easily create/edit this file.
6.) Tried to make NonRemovables dynamic - to auto-detect new
packages that cannot be removed in future verisons of Windows.
Non-dynamic fallback provided for older versions of Windows.
(I developed on 1709, which didn't have the .NonRemovable
property, but tested on 1809 which does.)
Justin Luth
Richard Newton