I'm thinking about hot to better integrate 3rd party tools into WuMgr, we have an ini to configure all that, but how do we interact with it as a user. I think a viable solution providing a ok user experience would be a tool's menu accessible from the main window and the sys tray. the simplest incarnation is one where every 3rd party tool configured in the ini gets an own sub menu with actions to be done by calling various scripts. So for example Defender Update ----> Enable update task ----> Disable update task WuAuDisabler ----> Disable update facilitatory ----> Restore default config etc the ini for that could look like [Options] Scripts=Defender,Disabler, etc... [Defender] Name=Defender Update Entries=2 Name1=Enable update task Exec1=defEn.cmd Name2=Disable update task Exec2=defDis.cmd [Disabler] Name=WuAuDisabler Entries=2 InTray=1 Name1=Disable update facilitatory Exec1=wuauDis.cmd Name2=Restore default config Exec2=wuauRes.cmd What do you think
That makes good sense and looks like it would be satisfying to the user for setting the ini options. From my less-than-little programming experience, your ini grouping format looks easy to follow and understand. Obviously, the third party utilities would be able to use the data in the consolidated ini or you wouldn't be considering it. (Edit: I get it - WuMgr calls the third party programs and pushes the valid switches to them.) Could the ini file be edited directly and the tools menu would be updated to reflect those changes, as well?
it does not update the lists, you would need to press seach for updtes agian to get an up to date view. I wil change it in the next version such that it updates teh lists acordingly
I need your input: I have added a feature to cache the entire updates list file (helps with testing if one does not need to find all the updates each time the client is restarted), however the cached updates are missing a reference to a wua API object, meaning the loaded lists can not be used to install or download updates using wuauserv. The user needs to properly run search for updates. fyi the missing wua API object can be recovered but its very slow as the SearchUpdates API needs to be used each time, or at least I haven't found any other API call that would allow one to get an IUpdate object by knowing only its KB numbers or UUID string. should this functionality be on by default in the client or better to have it of and only enablable via the ini, to avoid confusion?
Yea i think so to, I also made it such that when the displayed updates are loaded from file they are displayed with gray text
Yeah, almost all Windows updates say a reboot may be needed, and then often no reboot is asked for -- so, useless info as you said. (Strangely, sometimes a reboot notice is inexplicably made a day or two later.) For MS Office updates when Microsoft Update is chosen, I find that some PCs ask for a reboot and others don't, even though I have the same versions of Office running. Does the experience below help any for possible programming alternatives to rebooting? (1) Lots of application program updates say the system needs to be restarted, but sometimes all that's needed is to restart the applicable service(s), (2) Sometimes, logging off and logging on again are all that's needed to satisfy a supposed reboot requirement, and (3) Sometimes, the only good reason for rebooting is to delete the replaced old files/folders/entries that are locked, but everything you were working on operates just as well as before the update without rebooting - often in those cases the pre-update version is in effect until reboot. I'm sure there are other circumstances where rebooting is insisted on but not needed.
minor thing noted that ObjectListView2012 was using .NET Framework 4.6.1 whereas wumgr is using .NET Framework 4.6 no biggie just gives me a warning on build so have changed to all be on 4.6 and building with NuGet using ObjectListView.Official -Version 2.9.1 would I be better dropping to ObjectListView, Version=2.8.0.41823 I am running on Win 7x64 and have VM's for: Win 7x86, Win 10x86-1709, Win 10x86-1803 Win 8.1x64, Win 10x64-1709, Win 10x64-1803 I may be able to test for you on these platforms if it helps
Here are my findings: OS STATUS 1) Win 7x86 working well no errors 2) Win 10x86-1709 working well no errors 3) Win 10x86-1803 working well no errors 4) Win 7x64 working well no errors 5) Win 8.1x64 working well no errors 6) Win 10x64-1709 working well no errors 7) Win 10x64-1803 working well no errors
Guys, do you think that I should publish the tool on the Microsoft store? idk. id they would even let such a tool in but it would allow to reach a wider audience.
What about contacting Steve Gibson at grc or via twit. they did release the never 10 and he reaches a wide audience via security now
I think Microsoft would ban it because it counters their strategy of Windows as a service. But it's in the best interests of Windows users. FWIW, I don't even use MS Windows Store since there are plenty of other application sources. I definitely think you should get it out there more widespread. But I'm not sure where. You should probably be aware of any exclusivity arrangements, such as whether you can move your program to another place. What do you think of SourceForge? (SourceForge had an adware controversy a few years ago, but they have a new owner since then and stopped the adware activity.) GitHub is being purchased by Microsoft - uncertainty about whether they will eventually screen out projects that lock horns with MS interests. Gibson Research Corporation does have popular Shields Up website tool and might be supportive. But much of it is pretty dated; for example, SpinRite doesn't work on modern high capacity HDDs. I think Steve rested on his laurels a long time ago. Still, they appear to have a supporting philosophy.