Обновить

Как не дать Windows уснуть, и почему это сложнее, чем кажется

Кто-нибудь ещё живёт в режиме ноут-кровать? Спать уже хочется, работа почти сделана: дождаться агента, прочитать отчёт, выключиться. Ноутбук на одеяле, яркость в пол, агент молотит рефакторинг. Закрываю глаза на минуточку, открываю через сорок минут: тихо, машина спит. Агент уснул вместе со мной. Только у меня сессия восстановилась, а у него нет: прогон оборван, контекст заново, и спать теперь ещё полчаса не пойдёшь.

«Сон: никогда» в настройках не решение: это глобально, это забывается, и это не различает «не спи, я работаю» и «не спи, но экран туши». Нужен временный отзываемый запрос. В Windows он есть, и вокруг него четыре грабли.

Так что я сел и написал утилиту вместе с тем же агентом, который в ней нуждается. На Free Pascal, да, в 2026-м: один нативный exe без рантайма, и это всё равно видно по строкам в бинарнике, так что проще сказать сразу.

Грабли

  1. Состояние живёт у потока, а не у процесса. SetThreadExecutionState(ES_CONTINUOUS or ES_SYSTEM_REQUIRED) — слово Thread не для красоты. Поток завершился, состояние снялось, машина уснула, а приложение считает, что всё под контролем. Держать запрос надо в потоке, который доживёт до выхода.

  2. Утилиту могут убить в любой момент, а она меняет глобальное состояние. Порядок операций: сначала записать на диск, что и на что меняешь, потом менять. На следующем старте прочитать, сверить и откатить.

  3. ES_SYSTEM_REQUIRED не спасает на Modern Standby. Он лишь сбрасывает таймер простоя; на ноутбуках с S0 Low Power Idle при потушенном экране система всё равно уезжает в connected standby. Документированный путь с Windows 8: PowerCreateRequest + PowerSetRequest(PowerRequestExecutionRequired). На этих граблях до сих пор стоит PowerToys Awake (issue #48965, открыт), а Buho 1.0 стоял — на моём старом S3-ноуте всё работало, и я не увидел. В 1.0.1 запрос держится рядом с ES-флагами; проверка за секунду: powercfg /requests, секция EXECUTION. Так можно проверить любую утилиту этого рода, не дожидаясь ночи.

  4. План питания и режим питания это разные сущности. PowerSetActiveScheme двигает классическую схему, а ползунок «Режим питания» в Windows 11 живёт поверх неё и управляется недокументированными PowerSetActiveOverlayScheme / PowerGetEffectiveOverlayScheme из powrprof.dll (только через GetProcAddress). GUID-ы неочевидные: максимальная производительность ded574b5-…, экономия 961cc777-…, сбалансированный — нулевой GUID; в сетевых таблицах их путают. В Buho этого пока нет: там, где планы скрыты, утилита честно говорит «недоступно». Следующий пункт в списке.

Получился Buho. Нативный Win32, зип 1,3 МБ, в памяти около 20 МБ. Пять режимов (не тушить экран, держать машину бодрой с потухшим экраном, экономия, максимальная производительность, выключено), таймер до восьми часов или до конца дня, глобальные хоткеи, 12 языков. Портативная версия: настройки в buho.ini рядом с exe, ничего в реестре и профиле, в сеть не ходит. Автоматики «увидел процесс агента — включился сам» нет, она в старшем брате BuhoSleep; здесь хоткей перед запуском, чего для «жму Enter и закрываю глаза» хватает.

Зип и SHA-256: ru.buhosleep.com. Defender может ругнуться ML-эвристикой на неподписанный бинарник — это ложное срабатывание, заявка в Microsoft подана; хэши на странице сверяйте.

Теги:
+2
Комментарии4

Япония пыталась создать операционную систему для всего мира, но затем вмешалось правительство США

В 1984 году исследователь Токийского университета Кен Сакамура запустил проект TRON (The Real‑time Operating system Nucleus) — инициативу по созданию семейства операционных систем реального времени с открытым исходным кодом ядра. Подпроект BTRON был упомянут в отчёте США о торговых барьерах и фактически закрыт, прежде чем смог попасть в школы по всей Японии. Одновременно с этим подпроект ITRON стал одной из самых распространённых ОС в истории. 

Япония пыталась создать операционную систему для всего мира, но затем вмешалось правительство США

Публикации