Aquesta és una versió anterior. La versió actual és la 1.130.86. SysManager 1.130.86 · Data de publicació:
Fitxers d’instal·lació 1.76.24
| Arquitectura | Tipus | Àmbit | Mida del fitxer | Baixa | SHA256 |
|---|---|---|---|---|---|
| 64 bits | Portable | — | — | github.com | VirusTotal |
L’enllaç i l’SHA256 provenen del manifest comunitari del Gestor de paquets del Windows. Convé comparar el hash del fitxer baixat abans d’executar-lo.
Notes de la versió
[1.76.24] - 2026-09-07
The Landing tab used to ask Windows the same two questions 3.3 times a second, the expensive way, for three
numbers Windows hands over instantly. CPU load, memory and uptime now cost a few microseconds each instead of
two WMI round-trips, and the CPU figure is genuinely live rather than a one-second average being redrawn three
times.
Changed
- The Landing tab's live numbers cost syscalls instead of WMI queries. The vitals poll runs every 300 ms
for as long as the tab is open, and each pass made two WMI round-trips: one for CPU load, one for memory and
uptime. All three now come from the kernel directly — GetSystemTimes, GlobalMemoryStatusEx and the
monotonic tick count.
- The CPU percentage is now a real measurement of the interval just elapsed. The old source was a
WMI-throttled one-second average, so at a 300 ms poll the chart spent two passes out of three redrawing a
number that had not changed. It is now the busy share of the ticks that actually passed since the previous
reading.
- Uptime no longer jumps when the clock changes. It was computed as "now minus the boot timestamp", so
changing the system clock or a DST shift moved it. It now comes from a counter that only ever goes forward.
On a machine where the reading is unavailable the tab holds the last known figure rather than showing a zero
that reads as "idle".
Added
- A check that the 300 ms path cannot go back to WMI. Pinned by the WMI column names rather than by method
names, because the regression to guard against is someone adding the query back in a new method. It also
asserts the syscall path is still called — without that half, deleting the live values entirely would have
satisfied the rule.
Verify the download
Get-FileHash .\SysManager-v1.76.24.exe -Algorithm SHA256
Expected SHA256: FFC8CE9F62CB27799F4E1A6C341AA77C05CC7442FA5818FB4E154479515DDA97
This build is not code-signed, so Windows will warn on first launch. That is
expected for a small independent app: see what the warning says and what to
click.
Code signing is planned through the SignPath Foundation,
which provides free certificates to open-source projects, with signing performed by
SignPath.io. Until then, the SHA256 above and the build
attestation below are what establish that a download is the genuine build.
Code signing policy
This release is not code-signed. The team roles, release-approval process and
privacy policy required by the SignPath Foundation programme
are documented in advance under Code signing
policy. That
documentation is a prerequisite for applying, not evidence of a certificate. The
attribution line naming SignPath as the signing provider will appear here once a
certificate is actually issued.
This program will not transfer any information to other networked systems unless
specifically requested by the user or the person installing or operating it. Full
privacy policy.
Verify where this binary came from
This exe was built by GitHub Actions from this public source, and the build is
recorded in the Sigstore public transparency log. With the
GitHub CLI:
gh attestation verify .\SysManager-v1.76.24.exe --repo laurentiu021/SystemManager
That proves which commit and workflow produced this exact binary, something the
SHA256 file cannot show, since it is published alongside the exe it describes.
Each release also ships SysManager-v1.76.24.sbom.json, a CycloneDX inventory of
every dependency resolved for this build.https://github.com/laurentiu021/SystemManager/releases/tag/v1.76.24