Comments 16
Довольно интересно, спасибо. А почему вы не воспользовались dumpbin /disasm для получения ассемблерного кода? Если я правильно помню, то он еще и отладочные символы умеет потреблять, сами символы можно загрузить с помощью symchk
Закон об авторских правах, на статью 25 которого приведена ссылка в тексте, не действует с 1 января 2008 года
Спасибо за интересную статью! Скажите, а почему нельзя было использовать ida pro или ghidra? Удобнее же чем свои велосипеды.
А почему бы не ставить флаг DisableQuantum для текущего процесса, через смастерённый вызов int 0d, вместо того, чтобы дергать его периодически?
Насчет процесса изучения и исправления — на сам реверс было потрачено, наверное, раз в 20 больше времени, чем на сам фикс — так можно было бы и заполировать :)
Однако идти с этим в продакшен… Дизассемблинг и модификация чужих файлов, невозможность обновления системы, возможные побочные эффекты изменений на другие программы.
В принципе вы, похоже, пытались построить систему жёсткого реального времени на основе операционной системы, для этого совершенно не предназначенной, отсюда и проблемы. По большому счёту проблема решаема, скажем компания KUKA вполне себе использовала WinXP как основную ОС для контроллеров промышленных роботов, но там использовалась надстройка реального времени (VxWorks, если не ошибаюсь). Внутри там скорее всего происходил похожий на ваш тюнинг диспетчера и других компонентов. Эта надстройка, безусловно, решила бы все ваши проблемы, но увеличила бы стоимость системы на величину лицензии.
И, кстати, почему вы используете древнюю XP? Жёсткий реалтайм обычно в промышленных приложениях нужен, но я даже в цехах на производстве, где инерционность очень велика, ХР уже давно не видел. Семёрка ещё используется, но уж никак не ХР. Сейчас в промышленности все безопасностью озаботились и спешно переходят на Win 10 LTSC со всеми патчами и т.д.
И кстати, исходники XP ведь убежали — это могло сэкономить вам много времени.
Вот посмотрите доклады: https://youtube.com/playlist?list=PLBwwJL9lzKMY9Fpk1DAscywid1Xshp9NL
Там про .net но они также глубоко затрагивают работу ядра, которое не привязано к конкретному языку
А вот например в WinXP Embedded должен быть другой планировщик, вроде как реалтаймовость декларируется.
Но ход Ваших мыслей, имхо, верный.
Я бы на месте автора тоже для начала попробовал бы запустить его программу на какой-нибудь из промышленных Windows. Там есть возможность штатными средствами выкинуть из системы все лишнее, оставив минимально необходимый для работы именно вашей программы набор компонент, пожертвовав всем остальным.
Планировщик останется тот же самый, как и все остальное ядро системы. Но процессов, которые могут отвлекать вашу программу, будет сильно меньше.
Хотя исследовать потроха системы, конечно, интересно.
А у Windows нет аналога isolcpus из Linux (позволяет полностью освободить ядро, ОС не будет туда ничего сама скедулить, только то, что юзер явно указал)? Можно было бы ваш поток и "высокоприоритетные потоки" закинуть на выделенные ядра, а все остально, не слишком важное, крутилось бы на ядре 0. Возможно, я просто не очень внимательно читал статью.
Кстати, немного оффтоп.
Кто-нибудь знает, можно ли отключить прерывания планировщика Linux? Ситуация: высокоприотетный поток один-единственный висит на ядре. Время от времени приходят прерывания. Скорее всего, это планировщик (смотрит, убеждается, что никого больше нет, снова выделяет квант времени нашему потоку). Т.е. полностью передать ядро во владение высокоприоритетныму RT-потоку, но при этом это не bare-metal, ведь мы сохраняем возможность делать системные вызовы (и скедулинг может происходить только при системном вызове, получается).
Эмм? А что такое "прерывания планировщика"? Сам планировщик не генерит прерываний и, более того, способен работать только во время прерываний. Нет прерываний — планировщик никогда не получает управление.
А прерывания и исключения всегда будут. Это либо прерывания по таймеру, либо банальный Page Fault.
Ещё есть прерывания от оборудования. Можно настроить так, чтобы они не приходили на определённое ядро, но для этого вам необходимо будет пропатчить ядро самой ОС. Наконец, есть прерывания от гипервизора, всякие IME и прочая лабуда, о которых вы даже не узнаете, но задержку по времени они будут давать.
Постановка задачи
Конкретизируем задачу. Требуется проанализировать код ядра Windows в части переключения с одного потока на другой. Нужно убедиться, что никаких других случаев переключения, кроме трех перечисленных, в ядре нет. Используя результаты анализа и знание конкретного кода, переключающего потоки, требуется организовать работу планировщика так, чтобы заданный поток в течение 20-30 минут не прерывался потоками с более низким приоритетом (из-за работы диспетчера баланса), но при этом не обладал приоритетом «реального времени» и поэтому не мешал различным высокоприоритетным служебным потокам и сервисам.
Мне кажется эта задача решается намного проще и без создания дополнительного бекдор-апи к ядру. Просто динамическое повышение приоритета idle-процессов переставить с 15 на 14, сделав таким образом два уровня реалтаймовости.
Но изучить устройство ядра, конечно, интересно.
или статья 25 Закона РФ об авторском праве разрешают адаптацию программ для функционирования на технических средствах покупателя программы.
1 января 2008 года вступила с силу часть четвёртая Гражданского кодекса Российской Федерации, детально регламентирующая отношения в сфере авторских и смежных прав, в связи с чем утратил юридическую силу Закон РФ N 5351-1 «Об авторском праве и смежных правах»
И да, теперь реверс-инжиниринг незаконен.
Планировщик Windows? Это очень просто