Adding a complete and detailed User Guide for all Winstep applications in v26.6 was actually something I wasn’t initially expecting to happen. But it did, and it’s another item crossed off the to‑do list.
So, what’s left? As before:
1. The Theme Builder
2. Revamp the Winstep Gallery and open it to the public
3. More multi‑session modules (desktop clock, weather, battery, network monitor)
The v26.6 release also almost went without a glitch.
Almost.Because of what happened to a single user, at the last minute I decided to make sure dock and shelf contents would not be lost in case of a power loss while the Winstep application was busy saving changed data.
Previously, the registry keys holding stale shelf and dock data were deleted first, and then fresh data was written. The problem is that saving hundreds or even thousands of registry entries takes time. If the power goes out in the middle of that process, the data ends up missing or corrupted. That’s exactly what happened to that one user.
To prevent this, data is now written to a temporary registry key first. Only after all data has been successfully written is the permanent key deleted and the temporary key renamed to take its place. It’s still technically possible to lose data if the power goes out in the milliseconds between deleting the old key and renaming the new one, but even in that almost impossible scenario, the temporary key still exists with all your data.
I tested this here and it worked. The two code paths that wrote to the permanent key used a flag to know when to write to the temporary key instead.
What I didn’t notice was that there was a third routine also writing to the permanent key, and it was only concerned with saving shelf theme data. Because I didn’t update that routine to respect the flag, it was always writing to the permanent key - which was then deleted when converting the temporary key to permanent. So that block of data was simply ignored.
I didn’t notice because I always use a global theme for everything (DarkTech), and the bug only becomes visible if a shelf uses an individual, non‑global theme. Even the tests I did in Windows 10 VMs didn’t reveal it, because applying a theme via the Themes tab applies it globally, so the bug stayed hidden.
Only when reports started coming in nearly 24 hours after the update did I realize something was wrong - and by then most users had already updated (update notifications are spread over a 24‑hour window).
I immediately knew what the problem was related to, found the missing routine, fixed it, and issued a new update notification (this only affected Nexus Ultimate and Winstep Xtreme users). Unfortunately, it’s the kind of annoying issue that even after installing the fixed version can only be corrected by re‑applying the shelf themes.
I truly hate when this happens, and it’s a lesson I should have learned long ago: do not change critical code right before a release. It also highlights that the vast majority of bugs don’t come from new code (because that’s usually tested thoroughly while you’re writing it), but from changes made to old code - you no longer have all the ramifications in your head, and since it was known good code, you assume the untouched parts will continue working flawlessly.
It is always more dangerous to modify old, existing code - and the older it is, the worse it gets - than it is to write new code.
Old code carries assumptions you no longer fully remember, hidden dependencies, and edge cases that were solved years ago and have faded from memory. Touching it often means waking up ghosts.
Another problem today is that very few users still browse forums, even ones that used to be extremely active, like Wincustomize. As a result, the number of people both willing and able to test beta builds before release has become very small. That reduces the chances of catching issues early and increases the risk that bugs only surface after a public release.
Because I’ve been making so many changes and additions lately - which is great, because it allowed me to introduce a ton of new functionality - it also means some parts of the code have become a little less stable. I fix issues as soon as they’re reported, and in the end, once everything settles, the trade‑off will have been more than worth it.
As Patrick Swayzee said in RoadHouse: "It will get worse before it gets better".
But some users simply have no patience (can't really blame them though).
I especially hate it when users uninstall the software and submit an uninstall survey with no return email address, which means I can’t contact them, and the description of the problem is so vague it’s completely useless. It’s as if they’re convinced I was already aware of the bug and simply didn’t care to fix it.
And then there are the issues caused by third‑party software - and increasingly even by Windows’ own security components.
One user thought Winstep Xtreme was crashing when, in reality, it was his GPU driver (I’d bet he was using an NVIDIA card!) that was failing while watching a video or ALT‑Tabbing from a game. The TDR reset hid the Xtreme UI for a few seconds, and he interpreted that as Xtreme crashing and restarting automatically.
He also assumed it was Xtreme because he had previously been using Nexus Ultimate, which ran perfectly for him - but shortly after upgrading to Xtreme he must have also updated his video card driver. So when the GPU driver started crashing, he connected the dots in the wrong direction: “Nexus Ultimate worked, Xtreme doesn’t, therefore Xtreme is the problem.”
And so it goes...
Posted: Sun Jun 28, 2026 10:04 pm 
