Go get it if you haven't already. Don't forget to post some feedback on THIS thread, please.



If you open the Clock Settings panel, you will see a combo box with Green, Blue and Red color options for the Digital clock. However, look closely and right next to it you will also see a 'color well'. Clicking that color well will allow you to chose *any color you want* (including white) for the digital clock text - the options in the combo box are simply there for convenience.



Yeah, I will need to figure out some non-obtrusive way to notify the user that a new update is currently waiting to be installed. _OR_ I can wait for the system to be idle/unattended for, say, 10 minutes or so, and automatically install the update then.

When the user got back to his system, he would see a brand new version already installed/running and a notification that his software had been updated.

Ok, so I have been giving the silent update some thought, to try and figure out how it should work.

This is not as simple as it sounds, because an update's setup file requires admin privileges to succeed, and neither the Winstep application nor the Winstep Update Manager have them (which means the user will see a UAC prompt if setup is launched from either of those, when the idea is not to bother the user unless we absolutely have to).

The Winstep Service has admin rights, but it cannot launch an interactive application directly (i.e.; one that would possibly display a dialog to the user if there is a problem) because Windows Services (or anything launched by them) are not allowed to interact with the user.

So, here is how I see this happening:

1. The Update Manager detects a new version is available.

2. If the user is registered and his license key does not cover the new update, the Update Manager announces the availability of the new version as normal (i.e.; it prompts the user).

This obviously only applies to the paid versions, and what we are trying to avoid here is a registered user being fed a version that will run as a trial on his system because the 1 year of free upgrades offered by his license key does not cover the new version.

3. Assuming 2) does not happen, the Update Manager *silently* downloads and unzips the upgrade's Setup file, which is now sitting there on the user's hard drive ready to be launched.

4. The problem now is WHEN to launch setup and HOW to do it without the user seeing a UAC prompt.

This is where the possible methods start to diverge:

A) Application is ONLY updated after a reboot.

The Update Manager tells the Winstep Service that an update is available. Since the Service has admin rights, it can write to the HKEY_LOCAL_MACHINE RunOnce key and basically use the same trick used for Fast Boot to launch the Setup file from there after a reboot.

Since anything run from that key runs elevated (and without a UAC prompt), Setup is able to silently run at system startup, update the Winstep application, and start the new version.

When the new version starts, it would present a dialog to the user saying it has been updated and giving him a link he can click on to see what's new.

Now, the problem with this method is that the application is only updated when the user reboots his system. If you are like me, it could be weeks before this happens and in the mean time you wouldn't even know an update has been released.

A notice could appear in the About tab of Preferences (e.g.; new update available, click here to install) but this would only be seen by the user if he opened Preferences (and, again, if he doesn't open Preferences for a long time the update will go unnoticed). Furthermore, since this would mean launching Setup from the application itself, a UAC prompt would be required to run the Setup file.

B) The application can be updated at *ANY* time.

Given the above, this would obviously be the preferred method. Once the new version has been downloaded and unzipped, instead of quitting immediately the Update Manager would wait around for the system to be idle (i.e.; no user activity) for, say, 10 minutes.

Once that happens, the Update Manager would tell the Winstep applications to quit (as it happens now when a new update is about to be installed) and the Winstep Service to launch Setup.

And here lies the problem. Launching Setup through the Windows Service ensures that setup is run without having to first ask the user for permission (i.e.; the UAC prompt we are trying so hard to avoid) *BUT*, for this to succeed, we must make sure that Setup NEVER asks the user for input, instead failing silently if there is a problem.

Again, this is because Windows Services cannot be used to launch applications that interact with the user, any attempt from Setup to show a dialog would fail and the dialog would never be seen by the user.

Not sure yet if I can pull that off.

As somebody who only reboots when I absolutely have to, I much prefer option B. Is there a way to tell when the screensaver/power save monitor blank mode kicks in? That would be a good time to have it run setup. Of course, if somebody has that totally disabled, it would never kick in . . . is it even possible to completely disable? Probably, but why would most people want to?

Would it be possible to have the setup return an error code or something to the updater and instead have that show a setup failed dialog and maybe some options for how to proceed?

Possibly, I would have to read more about it. The problem is that I use InnoSetup, which is a 3rd party Setup tool (excellent, by the way).

Hmmm... I think I'll just drop the idea... for now.

I feel v16.6 already has enough goodies to justify a new official release. Especially because it also fixes that nasty memory leak bug that's been there (undetected until now) since v16.2.

There is another problem with this solution, and it's a big one: it can be a HUGE security risk and potential malware attack vector.

Anything the Winstep service launches will run with the highest system privileges, so it can basically do anything it wants.

If 3rd party malware could trick the Winstep service into running the wrong executable instead of a legit Winstep setup application, then your system would be totally p0wned.

The only other thing I can think of is something I totally hate...
Some applications install to appdata to avoid having to elevate for updates. I guess it could be an option.

I read Chrome did that at one point - doesn't seem to be doing it anymore though.

Anyway, not something I would do.

I'll just try to think of a way to validate what the Winstep Service is running instead. Not a biggie at this stage.

Anyway, I've been reading some stuff regarding Firefox's 'fall from grace' that resulted in many of its users migrating to Chrome, and a major reason why that happened was because Mozilla switched to a Rapid Release Cycle without properly implementing Silent Updates first. And if that wasn't bad enough, many of the updates broke compatibility with FF plug-ins.

Another consequence of Rapid Updates is that new versions are no longer 'a big thing', something you're actually looking up for. You could hardly tell the difference between one release and the other, as most updates were for security reasons or had to do with things that the user himself saw no benefits from.

So, users were being constantly bombarded with FF restarts and prompts to upgrade itself, plug-ins that stopped working, major UI changes just as you were getting used to the old UI, etc... Even the 'What's new in Firefox' tab was a source of annoyance.

In contrast, Chrome has been doing it right from the beginning. You basically don't even know the browser has just updated itself.

Now, as Edmund Burke wrote, "Those who don't know history are doomed to repeat it", so the idea is not to repeat the mistakes others have made.

My goal is not to update the software every time I add a tiny little thing or fix a tiny little bug. This would make updates fall into the trap of not having any perceived value anymore.

Where Silent Updates would be really, really, useful are in those cases were serious or at least relatively important bug(s) are discovered right after a new release (something that happens more frequently than I like, but unfortunately normal since a handful of beta users cannot replace thousands of users running the software in all sorts of different conditions and configurations).

I could just quickly issue a silent update to fix the problem(s) without any inconvenience to users who had already downloaded the new version.

For this to work, the best idea is to automatically - and silently, obviously - update the application when the system is idle (or right after a reboot, whichever comes first). The user goes to the kitchen to make a sandwich and, when he's back, the software will have updated itself with absolutely no disruption to his working schedule.

For silent bug fix releases, like in the case I mentioned above, I don't even think a notification is necessary (in fact I think it would be counterproductive).

For major updates, I already think notifications are important, so the user knows what new features are now available to him. Just have to figure out a way for this notification to be noticeable but not intrusive.

Either way, and except for the case mentioned above, I would still be releasing new updates only once a critical mass of new features had already been amassed. This way new versions would not loose their perceived value.


Another subject open to discussion is whether Silent Updates should be enabled by default or not.

Sincerely, my opinion is that they should, at least for new users. For existing users, a dialog could pop up asking them if they want to opt in.

There was a time, many years ago, when users became concerned if an application tried to use the Internet. These days nobody seems to give a rats ass about privacy (or nobody would be running Windows 10 otherwise), but it wasn't like that before.

So, when the Winstep application started, it prompted the user if he wanted to regularly check for updates. It doesn't do this anymore, but because it did back then, I now have thousands of users still installing v12.2 (which was released back in 2012 and is unfortunately still lying around on the web) and then complaining on Uninstall Surveys that the software does not run correctly on Windows 10 (which was released 3 years AFTER v12.2).

Why they chose to turn off the automatic check for updates when prompted is anybody's guess, but the fact is that this rarely happens with versions higher than v12.2, where the automatic check for updates is already enabled by default.

So the same reasoning applies. Opt-in automatically and let users opt-out later if they want to.