- GUI previously not display
- Style of some code updated to reflect body and readability
- Updated the `string` types within double-quote to be within curly braces for interpreter
DebloatAll whitelisted XBox apps since a lot of home users
want to play games. So, I added ALL of the XBox items to
the whitelist. Seems reasonable to me.
The blacklist removed several XBox components (since it
ignores the whitelist). Since some XBox components are
being removed, I added ALL of the XBox items to
the blacklist. Seems reasonable to me.
Or alternatively all XBox apps should be removed from
one of the lists, right?
I also confirmed that both GameOverlay and GamingOverlay
are both valid/installed in 1809.
This ESPECIALLY helps during a second run of the removal script,
where the result is almost instantaneous. Instead of
initializing the Remove-AppxPackage routine N times,
it only needs to do it once.
The downside is that we can't control feedback to the user on
the progress - and users frequently complain about hung
processes etc. There is SOME feedback coming from the
Remove-AppxPackage process - hopefully that will be enough.
I also ensured that -AllUsers packages were removed,
which was not done previously. If there was a reason for
NOT removing -AllUsers for the blacklist, then it can
be removed, but the DeBloat All function does remove
it, so to be consistent it seemed best to do the same here.
In terms of $NonRemovables - I had just added that but
on second thought, let the user be smarter than the computer.
The user now has the tools to detect if there are
conflicts with nonRemovables, so if they choose to
try to remove it anyway, don't prevent that.
The computer might be lying after all...
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.)
