Aquesta és una versió anterior. La versió actual és la 1.131.0. SysManager 1.131.0 · Data de publicació:
Fitxers d’instal·lació 1.130.19
| 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.130.19] - 2026-10-20
On Display Profiles, Apply mode waits for a revert to finish, Escape puts back a mode you have not kept, and closing
SysManager before you keep a new mode puts the previous one back.
Fixed
- Apply mode could be pressed while a revert was still running. Revert now and the end of the countdown closed the
"Keep these settings?" bar before the screen had re-trained, and picking another mode then turned Apply mode back
on. An apply started then replaced the mode the revert was putting back, and the tab still reported the revert as
done. Apply mode now stays off until the revert has finished. Since display changes ran in the background (1.42.2).
- Escape did nothing on Display Profiles, though the message after a failed revert said to press it. Escape now
puts back the previous mode while a new one waits for Keep, as Windows' own prompt does. After a failed revert the
message says to restart the PC, which puts the previous mode back, or to use Windows Settings. Since that message
was added (1.43.1).
- Closing SysManager during the 15-second countdown kept the mode you had not confirmed. Exiting from the
notification area, closing the window or restarting as administrator ended the countdown that would have put the
previous mode back. SysManager now asks first while a new mode waits to be kept, and puts the previous mode back as
it closes. Since Display Profiles was added (1.37.0).
- Picking another display while a mode was applied or waited to be kept mixed up the two. The readout under the
display picked could show the other display's new mode, and Keep's message named whichever mode the readout showed.
Each now belongs to its own display, and Keep names the mode that was applied. Since Display Profiles was added
(1.37.0).
Verify the download
Get-FileHash .\SysManager-v1.130.19.exe -Algorithm SHA256
Expected SHA256: E1F80A9B9E7E7EEC3C6D5C0B77B6922496FFEFCEBE4E18C71C12E63E181273FD
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.130.19.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.130.19.sbom.json, a CycloneDX inventory of
every dependency resolved for this build.https://github.com/laurentiu021/SystemManager/releases/tag/v1.130.19