v0.29.0 - the trim gets a switch on the window, amber while it is on

The trim was buried in advanced settings, which is the wrong place for the one
setting in this app that can make the machine feel worse while every number on
screen says better.

A log from a machine running the repeat loop every fifteen minutes:

-- squeezing working sets
   = trimmed 231 processes, 4654 MB pushed out of RAM
   = standby list purge: done

Nothing was killed. explorer, StartMenuExperienceHost and SearchHost were
all still running — and all three had just had their working sets emptied and the
standby list purged underneath them, so the next click on Start faulted the lot
back off the disk. Twenty-one times that day. From the chair that does not look
like a setting, it looks like Windows randomly breaking.

So it now sits next to Keep hunting after boost, and wears the same amber the
overclocked sentry uses to say this one bites.

It writes TrimWorkingSets only. ClearStandbyList stays in advanced settings on
purpose: purging standby is the half that can never help — standby is already
available to the next allocation — so it should not ride along on a switch
somebody flips hoping to get a bit of RAM back.

Answering the one-time notice from v0.28.0 now moves the switch with it, instead
of leaving a ticked box behind.

v0.28.0 - a trim is not a free, and an install that is still doing it gets told

Trimming working sets is not freeing memory, and Idle Master has stopped doing it
behind your back.

The trim is off by default

At the end of every boost — and again every ten minutes for as long as the sentry
was armed — Idle Master used to squeeze every process still running and purge the
standby list. That number went in the log as memory freed. It was not.

A trim evicts pages from processes that are still running and still wanted. The
clean ones go to the standby list, the changed ones head for the pagefile, and
every one of them faults back the moment you touch the app again. Purging standby
on top turns those cheap returns into reads from disk — for memory that was
already available to whatever asked for it next, because standby is available
memory; the allocator reclaims it on demand without being asked.

So the megabytes it reported were never really freed, and the bill arrived later
as a stutter when you went back to whatever had been squeezed. Every sweep. On a
machine that exists to hand Sunshine a steady frame, that is a hitch you would
blame on the network.

TrimWorkingSets and ClearStandbyList are now 0.

Three ways to trim, all of them somebody's decision

• Trim RAM now — the button on the window. Always runs, whatever the settings
  say. Worth a click right before you launch something big: you are abandoning
  those apps anyway, so the fault cost is paid later, for nothing.
• TrimWhenFreeBelowMb — runs even with TrimWorkingSets=0. Being genuinely
  short of memory is the one moment evicting pages beats keeping them.
• TrimWorkingSets=1 — the old behaviour, boost and the sentry clock
  included, for anyone who wants it back.

The flag used to sit inside TrimAll, which meant turning it off silently broke
the button too. It now gates the automatic callers only.

The headline stops summing two different things

Memory a kill released is gone and stays gone until you open the app on purpose.
Memory a trim "freed" is on its way to disk. Adding them together made the bigger
number and the worse claim, so a boost now reports a line each - what was
released by closing things, and separately, if you asked for a trim, what was
squeezed out of processes that are still running and will want it back.

If you are updating, you get told once

An update keeps your idlemaster.ini exactly as it found it — which is the
right promise to keep, and also means a machine that has been running Idle Master
for a while carries TrimWorkingSets=1 forward and goes on trimming as if nothing
had changed.

So it gets told, once, on the same frosted pane the theme picker uses: what it has
been doing, why that stopped being the default, and two buttons — Stop trimming
automatically, which writes TrimWorkingSets=0 and ClearStandbyList=0 into
the ini line by line so every comment in that file survives, or Leave it as it
is, which changes nothing.

Either answer writes TrimNotice=1 and the pane never comes back. Being asked is
what gets remembered, not which way it went — a prompt that reappears every start
is a nag, and the whole point of the change was to stop doing things to your
machine that you did not ask for. A fresh install ships TrimNotice=1 and never
sees it; neither does a machine that had already turned trimming off by hand.

Also in this release

Trash once means the whole session (v0.26.0). "Trash once" closed the thing
and put its name on a 30-minute backoff — so half an hour later the same process
was back, asking the same question about the thing you had just trashed. The four
toast answers now mean four different lengths of time:

	lasts	written
Keep it	until Idle Master restarts	nothing
Always keep	forever	[protect]
Trash once	until Idle Master restarts	nothing
Always trash	forever	[ask.never] + [boost.kill]

"Always trash" also used to write [boost.kill] only when the name was on no list
at all, so a name answered from an idle watch that was only on the idle list
survived the next boost. It goes on the boost list whenever it is not there
already now.

The respawn brake is untouched: a name that comes back SentryRespawnLimit times
is still rested for SentryBackoffMinutes, and the log still says so.

v0.25.1 - the text comes down to the layout, not the layout up to the text

v0.25.0 fixed the scaling and got the direction wrong.

The layout is typed in 96dpi pixels and the fonts were rendering 25% bigger than
that on a 125% desktop. v0.25.0 pushed the layout up to meet the text - correct,
and it made the window 874x1020, nearly the whole height of a 1080p screen. The
window was the thing that was too big.

It goes the other way now. A 9pt font on a 120dpi screen is asked for as 7.2pt,
which is the same twelve pixels tall 9pt was at 96dpi, and the layout is left
exactly as drawn. The window is 700x882 on any screen at any DPI - the size
it was before all of this - and nothing clips, because the text is finally the
size the numbers around it were written for.

And a dial: UiScale in [settings]. 1.0 is the size every window was drawn
at; 0.85 is fifteen percent smaller, 1.2 is twenty percent bigger, anything from
0.5 to 2.0. It multiplies the layout and the fonts together, so what changes is
the size of the picture and not the proportions inside it - 0.85 gives a 596x755
main window with everything still on it.

One thing this does not make identical: the same string is a few pixels wider at
7.2pt/120dpi than at 9pt/96dpi. Glyph heights match to the pixel; advance widths
do not quite. A label cut to fit exactly at 96dpi can wrap on a scaled screen -
found one in advanced settings and gave it the room. If you spot another, the
bug report button is right there.

v0.25.0 - the window meets the screen it is drawn on

Four things, and three of them are the same thing.

The layout now scales with the display. The app declares per-monitor DPI
awareness, but .NET Framework 4.x acts on that only with opt-ins an app.config
would have to carry, and this is one exe with nothing beside it. So every
SetBounds kept its 96dpi number while GDI+ rendered every font at the screen's
real DPI: layout at 100%, text at 125%, and anything sized to just fit its text
clipped.

v0.24.1 and v0.24.2 chased that one control at a time. This does it properly -
the whole control tree is scaled by the screen's own factor when a window loads,
fixed tab headers and list columns included. It sits in Theme.Form(), so every
window in the app gets it, not just the main one.

The main window is fixed size and fits the screen. Every number in it is a
typed pixel with no layout engine underneath, so dragging an edge only moved the
console and pulled the button rows out of line with the rules above them. It no
longer resizes. What a drag was standing in for - make it fit MY screen - is now
automatic: any window bigger than the work area is clamped to it, and whatever
it anchors to its bottom edge takes the loss. On a 1080p desktop at 125% the
main window comes out 874x1020 instead of 1116 tall and off the bottom.

The title bar is dark, when the theme is - keyed off the perceived luminance
of the theme's own background, so a light theme keeps a light cap and nothing
had to be declared in the theme files. A live theme switch re-asks.

The scrollbars are dark. The task manager's list and the disk tree already
did this for themselves; the console, the bug report's two boxes and the remote
setup's report are plain controls with nothing to subclass, and now get the same
call.

v0.24.2 - the column under the header follows it down

Fixes a regression in v0.24.1.

v0.24.1 measured the title and fixed the title, then handed the problem to the
next control down. The gauge was allowed to move, but the boost slab under it
was still pinned at 108 - so on a 125% display the gauge came down to 76, ended
at 110, and sat on the blue.

Measuring one control in a pinned column does not work. The column is a column
now: the gauge follows the subtitle, the big buttons follow the gauge, and one
drop carries the four bands, the three centred lines, the two switches, the
sentry door and the console down with them. The window grows by exactly that
much, so the console keeps its height rather than paying for the header.

On a 125% display the drop is 11 and the window comes out 893. At 9pt on a 96dpi
screen it is 0, the window is 882, and every control lands on the pixel it was
pinned to.

Also: the boost slab reads "Kill the background junk."

v0.24.1 - the title stops being sheared off, and the band rules get air

Two layout fixes reported from a 125% display.

The IDLE MASTER title was cut off. The header was pinned to the pixel - a
20pt line in a 34px box - and a 20pt Segoe UI Bold line is 36px tall. At 9pt on
a 96dpi screen the all-caps ink happened to sit in rows 11..29 of that box, so
the shortfall never showed. It is not a margin, it is luck, and it runs out as
soon as the font renders bigger than designed.

Which is what a scaled display does here: the app declares PerMonitorV2, but
.NET Framework 4.x without the DPI opt-ins does not act on it, so every
SetBounds keeps its 96dpi number while GDI+ renders 9pt text at 25% more pixels.
Layout at 100%, text at 125%, and the control with the least slack goes first.

The header is measured now. The title autosizes to its own font, the subtitle
starts where the title ends, and the gauge sits under whatever those two came
to. At 9pt/96dpi all three land exactly where they used to; above that they give
ground downwards instead of cutting the text.

The band rules had no air under them. One pixel between a band's name and
the caps of the buttons it names, so "AFTER THE BOOST" sat on "Restore desktop"
and read as crowded rather than as a heading. Six pixels now, and the pitch
between bands carries the extra down so each keeps its 8px gap up to the next
rule. The four band positions are one base plus a pitch instead of four typed
numbers.

That costs 20px of window - 862 to 882, minimum height 620 to 640 - so the
console keeps its full height rather than paying for the spacing. 882 still fits
the 1020px work area of a 1080p desktop.

Still pinned, and worth its own pass: on a 125% display the checkbox labels, the
band buttons and the big buttons' second lines clip the same way the title did.
Same root cause, but a whole-window answer rather than a header one.

v0.24.0 - the guard notices a machine that can ping but cannot connect

v0.23.0 shipped a repair that could never have run. This makes it reachable.
If you installed v0.23.0, take this one.

The hole

v0.23.0 clears the dead split-default route a VPN leaves behind when it is
stopped after having been connected. Reaching that repair means the guard
deciding the connection is in trouble — and in exactly that state, it decided
the opposite.

The guard tried TCP to two anycast addresses, and if that failed, fell back to
pinging them. On a stranded machine TCP goes nowhere but ping still works,
because the router is a directly-connected route. So the guard set "internet is
up", recorded no problem, never entered the repair ladder, and never ran the
fix. DNS failing added nothing on its own — it only decorated a message that
already required the internet to be down.

The fix

Ping answering while TCP does not is now trouble in its own right, and the
guard says so in those words.

It is deliberately a narrow signature, not a broad one. DNS failing on its own
is still not treated as a problem — a transient resolver hiccup is not worth
restarting services over. But "no TCP to either of two anycast addresses that
are never down, while ICMP to those same addresses works" is not a state a
healthy machine is ever in.

Also

The stranded machine's real configuration is now a test fixture. It carried one
thing worth having: the adapter was "OpenVPN Data Channel Offload for
NordVPN", not NordLynx — the client had switched protocol. The matcher covers
all four Nord adapter spellings, and correctly ignores Tailscale, the physical
adapters, Hyper-V, and a different vendor's OpenVPN adapter. The real default
route via Wi-Fi survives; both dead halves are picked out.

One correction to the v0.23.0 notes, in the honest direction: the DNS-clearing
half has now been confirmed to work for real on a stranded machine. Only the
route delete remains unexecuted outside a fixture.

Found by another session working on the same machine, who said plainly that ICMP
succeeding must not be read as the network being fine. They were right, and I
had shipped exactly that.

---

Installer: IdleMasterSetup.exe. IdleMaster.exe is the app on its own and
IdleMasterRebuild.exe is what backup kits carry.

v0.23.0 - the guard clears what a stopped VPN leaves behind

If you have ever felt you could not turn your VPN off because the wifi then
had no internet — this is that bug, and this is the fix.

What was happening

Stop NordVPN after it has been connected and it leaves its adapter up, holding:

0.0.0.0/1    via the tunnel gateway   metric 25
128.0.0.0/1  via the tunnel gateway   metric 25
0.0.0.0/0    via the real router      metric 35

Those two halves cover the entire address space between them, and they are more
specific than the real default route - so they win no matter what the metric
says, and they point at a gateway that died with the tunnel. The DNS servers it
leaves on that adapter only ever resolved through the same tunnel.

The machine then looks online. Pinging the router still works, because that is a
directly-connected route. DNS and TCP go nowhere. Turning the VPN back on
"fixes" it, by restoring the gateway those dead routes point at - which is
exactly how you end up believing the VPN can never be switched off.

The fix

The network guard now removes that residue: the two dead half-routes, and the
DNS on that adapter.

Every step is gated on no service of that VPN running. All of it is
legitimate while the VPN is connected, and the app rebuilds it on the next
connect, so the guard will not go near a live tunnel's configuration. It runs
before the guard tries restarting a stopped network service, because restarting
the VPN is the wrong repair for this.

Tailscale is deliberately not restarted automatically. It can log itself out
while DNS is dead, but tailscale up from a background sweep can ask for an
interactive login - so the guard tells you at the keyboard instead of guessing.

What was tested, and what was not

Tested on a real machine: the gate refuses to act while the VPN is running even
with the residue present; the netsh commands parse; and the route parser was
rewritten after the first version proved unsafe - it could match a route
metric of 25 against an interface index of 25 and delete a route on the
wrong adapter.

Not tested: the removal itself, on a genuinely stranded machine. Producing
that state means deliberately cutting the network on the machine doing the
testing. The detection and the gate are verified; the delete is not.

---

Installer: IdleMasterSetup.exe. IdleMaster.exe is the app on its own and
IdleMasterRebuild.exe is what backup kits carry.

v0.22.0 - disk cleanup stops trying to recycle 313,000 files

If a disk cleanup of yours has been sitting on one item for a long time, this
is the release that fixes it. Kill the app, install this, and run it again.

Windows update leftovers are deleted, not recycled

C:\Windows\SoftwareDistribution\Download is routinely several GB across
hundreds of thousands of files - 9.6 GB and 313,263 files on the machine
this was found on. Sending that to the Recycle Bin means moving every single
file individually, each with its own metadata record. It runs for hours, and
when it finally finishes the bin is holding all of it, so nothing is actually
freed until you empty the bin afterwards.

Those are deleted outright now. Windows' own Disk Cleanup does the same, and
they are payloads for updates that are already installed - there is nothing to
restore them for.

The confirmation now lists by name anything that is going for good, and what
it adds up to, instead of promising that everything can be restored from the
bin. Everything else still goes to the bin exactly as before.

The progress line no longer lies

A clean would set the status to "cleaning..." and then the scan's own progress
timer painted the last scan phase straight back over it - so a clean that was
hours into deleting sat there reading "scan finished", which is what made a slow
job look like a dead one.

Each item now names itself before it starts, with its size, and says whether it
is going to the bin or for good. The item that takes a long time is the one you
most need named.

Stop works during a clean

"Stop scan" was hidden while cleaning and "Clean checked" was disabled, so the
only way out was killing the app. There is a Stop cleaning button now.

It is honest about its limit: a single shell delete cannot be called off once
Windows has it, so Stop prevents the next item starting and tells you it is
finishing the current one first.

Still worth testing while you are awake

The NordVPN disconnect-then-stop sequence has never actually run - it cannot be
exercised from a session reaching the machine over Tailscale, because running it
drops that tunnel. Run one real Absolute Idle with a VPN up and watch the
hand-off before relying on it unattended.

---

Installer: IdleMasterSetup.exe. IdleMaster.exe is the app on its own and
IdleMasterRebuild.exe is what backup kits carry.

v0.21.0 - the IDLE MASTER band reads down the middle

A tidy-up of the band wall added in v0.20.0.

• "GONE FOR GOOD" is now "DISK AND SYSTEM" - named for what it covers rather
  than for the tone of it.

• Settings and Report a bug are centred in their band. Two buttons on a
  four-column grid sat left-aligned under "Disk cleanup" and "Debloat" with half
  a row of nothing beside them, which read as a bug rather than as a short band.

• The version line moved underneath them, centred, instead of sitting off to
  their right.

• The sentry's status line moved under the version. It was overlapping the
  "Sentry lists & timers" button - and because it is anchored to both edges, the
  wider you made the window the worse the overlap got.

There is a gap under those three centred lines now, so the program's own row is
visibly separate from the switches and the console below it.

One trade worth knowing: the window is 862 tall, up from 806, and no longer fits
an 816px desktop standing up. The console kept its full height instead of paying
for the change.

Still worth testing while you are awake

The NordVPN disconnect-then-stop sequence has never actually run - it cannot be
exercised from a session reaching the machine over Tailscale, because running it
drops that tunnel. Run one real Absolute Idle with a VPN up and watch the
hand-off before relying on it unattended.

---

Installer: IdleMasterSetup.exe. IdleMaster.exe is the app on its own and
IdleMasterRebuild.exe is what backup kits carry.