Редактировалось 1 раз(а), последний 2020-02-16 13:50:12

[offtop]Что-то не дают общественности покоя кулхацкерские техники, я погляжу, их есть у меня, вот только потяните ли Вы - большой вопрос [/offtop] Запуститься с повышенными привилегиями. Перечислить все потоки процесса-жертвы через CreateToolhelp32Snapshot, включая внешние библиотеки. Применить к каждому потоку функцию API SuspendThread. Регулярно следить, не запустит ли кто-нибудь в приложении поток без нашего ведома (например, по зарегистрированному Call-back) и считать свои секунды. По истечении требуемого интервала запустить все потоки через ResumeThread и молиться, что они не рассинхронизируются и всё не вылетит к чёртовой бабушке. Единственный случай, когда проблем наверняка не будет - однопоточное приложение, не использующее на момент заморозки асинхронных функций API (то есть без таймеров, ожидания соединения по портам, сокетам, прочих сообщений от системы). В общем, такого почти не бывает в реальной жизни.

Другими словами, Вы слишком многого хотите, 100% "правильно" (то есть без возможных негативных эффектов) приостановить чужое приложение невозможно. Единственный грамотный метод я Вам уже описал, но любая заморозка нарушает стабильность приложения-жертвы, и тут встаёт вопрос - насколько пряморукий человек писал то приложение, учитывал ли он возможную рассинхронизацию потоков в силу стороннего воздействия. Например, при виде чего-то страшного и многопоточного, без внутренней синхронизации и блокировок, что так любят клеить на коленке местные неофиты, закрадывается серьёзное сомнение в том, что ЭТО Вам удастся заморозить без фатальных (для приложения) последствий. А при попытках заморозить некоторые службы или системные процессы (естественно, нужны соответствующие привилегии) Вы имеете все шансы как минимум дестабилизировать, как максимум - "повесить" или выбить в BSoD всю систему.
------------ Дoбавленo в 09.37:
Net2Com, кстати, Ваш горячо "любимый" WMC - управляемый процесс виртуальной машины .NET, там добавляются свои ньюансы, сейчас впервые попробую приостановить простейшее самодельное .NET-приложение описанным выше методом, самому интересно, что получится.
------------ Дoбавленo в 10.01:
Практика показала, что экземпляры 32-хбитной виртуальной машины .NET под NT5.x замораживаются наравне с обычными процессами, но WMC наверняка использует мультимедийные функции системы с аппаратным ускорением и работой с потоковыми данными, сетью. Кроме того, там NT6.x x64 чаще всего, а Ваше приложение таки 32-хбитное, не исключаю, будет такая же история как с отловом окон и процессов.

[offtop]1nd1g0, блин, я только щас вспомнил, читая Ваш пост, если у меня и интерфейс и музыкальная часть лежит в одном FTCG мультике, то я получу однопоточное приложение. Интересно, можно ли для FTCG сделать элементы, аналогичные Thread стандартного пакета.[/offtop]

[offtop]
Можно, но головная боль по синхронизации потоков целиком ляжет на Вас. Можете начать с разбивки на несколько контейнеров и запуска каждого в отдельном потоке штатными компонентами.[/offtop]

[flood]1nd1g0, не получится в разные контейнеры, один контейнер не сможет залезть в другой чтобы прочитать там массив [/flood]

login, [flood]в отдельную тему, например, "Многопоточность внутри FTCG"[/flood]

1nd1g0,[flood]создам тему, как только закончу всю работу по прошлой нашей теме.[/flood]

Редактировалось 1 раз(а), последний 2017-03-04 03:33:23

Всё правильно. Так и должно быть.

г. ость, это лишь говорит о профессионализме авторов этих приложений и грамотной реализации описанного мною метода в AnVir. Я видел множество приложений, которые не "замораживаются" до конца, или не размораживаются корректно, если вообще "размораживаются". Например, если приложение само использует заморозкуразморозку собственных потоков, а тут ещё Вы лезете со своей. Либо оно Вам не даёт себя заморозить, либо дублирует Вашу заморозку своею не предполагая, что кто-то её уже наложил на один из потоков, наступает "вечная мерзлота", особенно весело, когда заморозка зацикливается и процесс становится неубиваемым никакими способами. Даже затиранием всей его памяти кодом из 0-го кольца защиты - в силу заморозки просто не отрабатывают деинициализирующие процедуры и он так и остаётся висеть в списке, хоть и не работает. Если бы всё было так просто, в системе и официальных утилитах давно была введена "пауза" для произвольных процессов, её не случайно нет.

Редактировалось 1 раз(а), последний 2020-02-16 13:50:21

Браузеры будут разные, на разных системах? Просто браузеры друг другу - рознь. Некоторые из десятков процессов состоять могут. И, опять же, 64-хбитные потоки, особенно - под другим пользователем, своим 32-хбитным приложением Вы в ряд ли заморозите.

Можно дать своему процессу приоритет реального времени, и загрузиться бесконечным циклом, притормозит сразу все

Есть очень старые приложения, где реализована эта функция! Например Process Killer! Программа стара, ещё 2003 года, а замораживать может любые процессы!

Редактировалось 1 раз(а), последний 2020-02-16 13:50:27