Attached is suggested reworded content that I think is more readable but could be condensed more, especially since it won't fit your current window size. Sure, you should convey a good understanding of what the script does upfront, but not everything needs to be summarized there. As to the other screens, they look good to me, and I like the uninstaller.cmd screen in 2.5.2 - my first time to use it - giving a network disconnect option while uninstalling. I'd been using a taskbar pinned WUB 1.0 immediately after uninstall.
If you put a "wumt wrapper script" folder in the "Téléchargements" folder, it creates a short name for the path. Try it. Then run the script and watch the tasks work. Let me know if you have any problems.
This is the path to the script : C:\Téléchargements\WUMTWrapperScript\Portable\WUMT Wrapper Script On w10, no short name. On my W7 VM, short name : TLCHAR~1!
@pf100, lowest priority suggestion if you agree for the need: Change name of "uninstaller.cmd". I came to the party a bit late and after you had the installer up and running, which I've used exclusively. The fact that your uninstaller.cmd uninstalls/reverses all changes by your script is explained in the readme file and is well known by everyone who used the portable version, which is all there was before the installer. But now, after utilization of the installer, you've got an Uninstaller selection in the WUMT Wrapper Script Menu entries which fits the traditional use to uninstall an installed program. For someone like me, who doesn't do a good job of RTFM and who hasn't normally just run the script from the portable folder, it's easy to forget that everything still needs to be reversed if you casually run the script command without using the installer first. Maybe "uninstaller-reset.cmd" or something else to indicate reverse/reset/revert?
I agree about the cluttered screen issue, and thanks. Like "uninstall_undo-all-script-changes.cmd" ? No problem
After running WUMTWrapperScript 2.5.2 Portable, Windows Update service is disabled however the WUB task and WDU task is not created.
I see what the issue was. After initially running the script, i hit Q to quit. This time i ran the script and hit C to run the WUMT and the tasks were created. Normally i didn't have to do that with previous versions of the script. I don't use the WUMT itself, i use the script to prevent Windows 10 from going into business for itself and installing updates. I normally update manually. At any rate, it's working now thanks for the help.
In order to be compatible with some foreign languages (I.e not Anglo-Saxon), short names (legacy 3dot8name to be compatible with MS-DOS) are used to define the action to be performed by the scheduled tasks). One has to make sure short names are enabled for the directory containing the wrapper script. At a command prompt type "dir /x". If no short names is available, just delete and recreate the directory(s) : now you should see short path names.
I'll make it so the tasks are created before the Configurator to help people like yourself that don't want to use WUMT in the next version 2.5.3. Edit: The reason why 2.5.2 only creates the tasks just before WUMT runs is because of the separate VB script in the file "module.vbs" that made the screen flash, so I moved the task creation to almost the end of the script to minimize the impact of the flashing. Now that v2.5.3 doesn't make the screen flash with that same VB code being inside the script itself now, I can move the task creation code to run before the first screen shows like it used to be. Thanks for the report.
@Whistler4 Here's a screenshot of the splash screen with your changes. Much better. Thanks. If you, or anyone else, sees a way to improve it further, I'll change it. (Screenshot removed by me since it was updated)
I'm toying with the idea of locking the "Update Assistant" files instead of uninstalling them, then deleting them, where they can possibly come back later like the script currently does. The downside of this is that you wouldn't be able to uninstall "Update Assistant". The upside is that the "Update Assistant" files can't be re-created, deleted, or run. Any feedback on this idea would be appreciated. People might freak out if they can't delete the: %SystemDrive%\Windows10Upgrade folder and files (assuming C: is your system drive (C:\Windows10Upgrade)) %systemroot%\UpdateAssistant folder and files (assuming C: is your system drive (C:\Windows\UpdateAssistant)) %systemroot%\UpdateAssistantV2 folder and files (assuming C: is your system drive (C:\Windows\UpdateAssistantV2)) But, like I said, "Update Assistant" couldn't run ever again or be re-created. Thoughts?
I think I'm in the bothered-by-not-being-able-to-uninstall-a-program camp. When that happens, I do a relentless search through the registry and AppData, Common Files, etc., folders to get rid of applicable entries. I might have to reinstall to uninstall. As a last resort, I'll restore a system backup. Anything else seems broken to me. If I know the Wrapper Script has done it, that's okay, but I think it has to be reversible with the uninstaller. I think you've generally had the "do no harm" policy for the uninstaller if the user makes the decision to stop using the script for however long. How about this? . . . Copy all the Update Assistant folder/files into something like Update Assistant.old (or similar), then lock and delete as proposed. The uninstaller then reverses that, restoring Update Assistant files from the copy. If your intention is to leave the system with Update Assistant uninstalled, at the least, the script can uninstall it during the uninstaller phase. Back to the mechanics of your proposal, in some cases, like if the script had previously been run and then uninstalled, there might not be an Update Assistant installed, right? Can the script check for that, then create the empty folder and lock it, and would that prevent future installations of Update Assistant?
That's my concern, is that people may not know that my proposed changes to the script won't allow you to uninstall Update Assistant, to seemingly ironically disable it. I haven't decided to do this, just trying to get a feel of what people are going to think about it. The way the uninstaller is now, it reverses all changes to exactly the way it was before you ever used the script, except for "Update Assistant." It's handled differently in that the script uninstalls Update Assistant, then deletes all files and folders related to it. But it can reinstall itself through an update, which is the only reason I suggest to run the script again after installing updates to the first screen, then just kill the script by clicking "X" on the window. If it wasn't for Update Assistant, that wouldn't be necessary. That's the biggest weakness of the script as of version 2.5.2. And I definitely have a "do no harm" policy with the script. I very carefully make sure the uninstaller reverses all changes, exept for Update Assistant. The uninstaller currently doesn't restore any part of Update Assistant by design. If I locked all the Update Assistant files so the system couldn't read or write to them, there would be no need to make an "Update Assistant.old" folder, because the system wouldn't be able to read, write, execute, or delete any of those files. And you, as a user, wouldn't be able to read, write, execute, or delete any of those files either unless you run the uninstaller. The uninstaller would then unlock them and reset everything back the way it was before using the script, resetting the folders and files permissions, making Update Assistant work normally again, essentially "restoring" Update Assistant. With the script, it would be exactly as if Update Assistant wasn't installed, even though it is installed, but Windows can't run any of the files. And if Windows tried to "repair" the permissions to those files and folders, it wouldn't be able to. That's the reason the script causes sfc errors, because Windows can't "repair" the unreadable and unwritable "Update Hijacker" files that are locked by the script. Also, if I moved and/or renamed all the Update Assistant files and folders to a differently named folder ("Update Assistant.old, etc."), and locked them, it wouldn't work because Update Assistant would re-create "C:\Windows10Upgrade", "C:\Windows\UpdateAssistant", and "C:\Windows\UpdateAssistantV2." So my proposed intention is to leave Update Assistant installed, not uninstalled, with all files intact, but not readable or writable by the system. So basically, making an "Update Assistant.old", "C:\Windows\UpdateAssistant.old", and "C:\Windows\UpdateAssistantV2.old" folder wouldn't help at all since the system could just re-create the files and folders since I can't lock folders and files that don't exist, which brings us to your next questions: 1) Right. If the wrapper script (beginning with version 2.2.8) has been run, in all cases, all traces of Update Assistant is completely uninstalled and removed the first time you run the script before you ever get to the first screen. 2a) Yes, 2b) yes, and 2c) yes. If Update Assistant is not installed, I can make the script check to see if Update Assistant is installed and exists, and if not create "C:\Windows10Upgrade", "C:\Windows\UpdateAssistant", and "C:\Windows\UpdateAssistantV2" and lock the folders so that Update Assistant can't be installed. That's my major concern, is people freaking out about running the script and wondering why "C:\Windows10Upgrade", "C:\Windows\UpdateAssistant", and "C:\Windows\UpdateAssistantV2" exists all of a sudden when the script is supposed to disable it permanently (until the script's uninstaller is run), not knowing that to disable it I had to create it!