Hiding the desktop icon layer without breaking the desktop

DeskDrawer has to hide the icons Windows draws, without changing a setting, without surviving a crash, and without upsetting Explorer. Each of those constraints came from a specific failure.

DeskDrawer draws your desktop icons inside boards. Windows is also drawing them, in the icon view that Explorer owns. Something has to give, or every icon appears twice.

Hiding that view is the single most invasive thing this application does, and the rules around it were written one failure at a time.

Rule 1: never write a Windows setting#

Windows has a real setting for this — the Show desktop icons item in the desktop's View menu. The obvious implementation is to turn it off at startup and back on at exit.

It is the wrong implementation, and the reason is the crash case. If the application exits without running its cleanup — a hard kill, a power cut, an uninstall while it is running — the setting stays off. The user now has a permanently empty desktop, no running application to blame, and no idea which Windows setting was changed. From their side the desktop is simply broken.

So the hiding is session-scoped: it lasts only as long as the current sign-in and is never persisted. Quitting restores the icons. Crashing restores them at the next sign-in. Uninstalling while running restores them at the next sign-in. The worst case is "sign out and back in", which is recoverable by someone who does not know what happened, and that is the bar an invasive behaviour has to clear.

It also means the desktop's own View → Show desktop icons still works as an escape hatch, which is the instruction on the Troubleshooting page.

Rule 2: never show both layers at once#

Boards and native icons are never displayed together, because that shows every item twice and neither copy is authoritative. This is why View mode is a toggle rather than two independent switches, and why creating a new board switches back to board view automatically — otherwise the board you just asked for would be invisible.

Rule 3: the desktop's gestures still have to mean what they meant#

Once boards are the desktop, several Windows behaviours become wrong by default:

• Win+D minimizes everything to reveal the desktop — but boards are the desktop, so hiding them is the opposite of the request. Fixed in 1.1.2.
• "Minimize all" had the same problem. Fixed in 1.0.8.
• Alt+F4 on the desktop opens Shut Down Windows. On a board it was closing the board — a destructive-feeling action triggered by muscle memory. Fixed in 1.1.0.
• Applications launched while boards were on screen got stuck behind them. Also 1.1.0.

None of these were in the original plan. Each was found by using the thing.

Rule 4: do not upset Explorer#

This is the one that produced the most serious bug in the product's history, and it is worth describing because the shape of it is instructive.

Hiding the icon view involves cross-process work: the view belongs to Explorer, not to DeskDrawer. Part of the interaction cleared the desktop selection after a New item was created. Under the right timing — a busy PC, OneDrive or antivirus scanning the desktop, the view being rebuilt underneath — that cleanup could act on a view that had already gone away, and take explorer.exe down with it. The desktop would flicker and restart.

Three things about that bug are worth stating plainly.

It was rare, and rare is the problem. It needed a busy machine and a specific sequence. That is exactly the profile of a bug that survives ordinary testing and reaches users.

It was introduced by a fix. The code that caused it was written during an earlier hardening pass — a change made to improve reliability created the worst reliability bug in the product.

It survived three subsequent audits. It was written during the fourth review round and found in the seventh, having been read past three times, because each of those rounds was looking at something else. It was eventually caught by a review pass specifically about cross-process COM object lifetime, which is the only lens that would have shown it.

It shipped fixed in 1.2.4. The lesson is in Eight rounds of code audits on a small app, and what each one found: what you find depends entirely on what you were looking for.

What the constraint bought#

The rules read like caution, and they are, but they produce a concrete guarantee worth having: the worst thing DeskDrawer can do to your desktop is temporary. No setting is changed, no file is moved, nothing needs undoing. Sign out and back in and Windows is exactly as it was.

For a program that paints over the whole desktop, that is the property that matters most.