Antonshka

Загрузил User.32 dll в Ghydra. DrawIconEx из User.32 dll вызывает NtUserDrawIconEx в win32u.dll, предварительно записав все нужные параметры в регистры и стек. NtUserDrawIconEx из win32u.dll вызывает syscall. А дальше все, тайна кода ядра.

Привет, кто-нибудь пробовал такое? Есть функция DrawIconEx в User.32 dll. Нужно узнать как она работает изнутри. Как она обрабатывает маску иконки и само изображение иконки. Зачем это нужно? Дело в том что DrawIconEx корректно рисует иконку. Но если пробовать сделать тоже самое вручную, через BitBlt, как например это описано у Фень, Щупака, на MSDN, то получаются артефакты.

Оказывается в Windows есть ограничение на количество User, GDI, и Kernel объектов, для сессии в общем, и в частности для процесса. Для User и для GDI, максимальное возможное количество объектов на процесс равно 10 000. Для Kernel цифра побольше. Я открыл 5 PopupMenu и у меня уже более 10 000 GDI объектов. Утечки нет, при закрытии PopupMenu становится около 300. Проверял через ProcessExplorer. Придется переписывать всю логику обращения с объектами. Переходить на постоянное создание/удаление. Не знаю как сильно это скажется на производительности, но такова реальность. Еще вместо создания отдельных иконок, придется использовать общий ImageList или собственный битмап, затем уже через StretchBlt рисовать из него. Кстати, ImGUI не использует задержку и плавность для PopupMenu и для ToolTip. Думал тоже убрать, но с ними все же интересней.

Интересно было поностальгировать по СЕ. Не Velocity ли это было? В ESP+50. На 12:48. Обычно объекты ускоряют через Velocity * свой множитель. Я бы посоветовал использовать всегда pushfd/popfd при наличии своего cmp.

Ладно, спасибо всем за советы. Буду думать как реализовать планировщик.

Почему не главный поток? Такой планировщик справиться с плавным появлением/скрытием окна? А также с отменой отложенного задания? Думается мне что создать такой планировщик будет непростой задачей. Но сама идея конечно отличная.

Я думал у тебя что-то иное. Что он из себя представляет? Опиши в нескольких словах. Это дополнительный поток, время жизни которого равно времени жизни главного GUI потока, и который обрабатывает очередь задач? Или это просто обработчик задач встроенный в главный GUI поток? Ты сказал, - "планировщик". Но не сказал что он из себя конкретно представляет. Или и сказал, но мне для понимания этого было не достаточно.

Ну лааадно, зааажаааааарится как-нибудь Я все ждал решения от @Xipho. А он молчит, как партизан. Все хотел посмотреть на его планировщика.

А я подумал что вы все еще ее решаете и никак решить не можете.

Помимо задержки создания/удаления окна, должно еще быть плавное его появление/скрытие. Альфабленд от 0 до 255. Я забыл про этот момент. Если реализовать плавность в главном потоке, то отзывчивость GUI будет зависеть от того как быстро изменяется прозрачность окна. Ведь при изменении прозрачности нужен Sleep(1), иначе прозрачность будет изменяться мгновенно. Получается что без создания дополнительного потока, который будет управлять прозрачностью и вдобавок задержкой, не обойтись.

Значит у тебя первое место, у меня второе, у @Xipho и @youneuoy третье или четвертое, соответственно. А мы молодцы.

Я до часу ночи читал комментарии и даже смотрел другие видеоролики на эту задачу. И только один, один единственный комментарий, навел меня на нужную мысль. Утром я ее развил и понял ответ. А кто-то ее понял, как пишут, и за 15 - 30 минут. А ты все понял в этой задаче? Почему именно такое решение, а не другое? Долго думал? Только не пиши ход мыслей, пусть и другие попробуют себя.

Привет всем, хотите ли проверить себя на смекалку? Тогда эта вирусная логическая задача будет вам интересна. Сам я смог ее решить/осознать только сегодня... Увидел вчера. Сразу скажу, что для меня объяснение её решения автором видео является недостаточным. Также считают и некоторые комментаторы. Первое непонимание с которым столкнулись люди, - почему удаляем весь май? А вы, сможете ее целиком осознать?

Я не говорил что он при Sleep тратит. Sleep меня пока вообще не интересует. В твоем сообщении ты написал Я тебе привел цитаты, с форума и из книги, что это не так, что процессорное время не тратится, в моем конкретном случае, при использовании WaitForSingleObject. Это не загон, это обучение. Поиск лучших вариантов. Дай же пообщаться с интересными людьми. Развеяться 🤗. Понял теперь о чем ты. Тут такая ситуация, - я читал Рихтера, читал Щупака, в этих книгах не было разговора об std. В них все про WinAPI. Потому у меня такое восприятие. Ну и плюс я сам, низкоуровневый любитель. Я хочу работать с "главарями", не с посредниками. Я не люблю за это с#. За то что он за меня решает. Но ты скажешь может быть тогда, пиши на ассемблере. Ассемблер тоже крут, его я тоже люблю. Но С++ интереснее. Что-то в этом есть. Но мне хочется самому все организовать. Я бы не сказал что это требует особых усилий. Это достаточно быстро все пишется. Плюс я знакомлюсь с внутренним устройством всех этих систем. С внутренним это относительно, насколько это позволяет Microsoft. Где-то в книге читал что это полезно знать. Придет время, и я возможно перейду на std. Хотя я и сейчас ее очень часто использую.

Sleep или замену Sleep я не планировал использовать. Это я просто привел цитату с сайта о том что поток не тратит CPU время при функции WaitForSingleObject. Также и про спин, - речь не о самом спине, а о том что система умеет распределить процессорное время при заблокированном потоке, как я понял из всего прочитанного. Вот пример более конкретный относительно объекта события и WaitForSinlgeObject. Из Рихтера. Этот момент я не понял. Почему эти вещи загоны? Есть же принцип такой, Принцип единственной ответственности, что сущность должна заниматься исключительно своим делом. Вот и пускай объекты-контролы занимаются своими делами, а не основной поток. WaitForSingleObject чем плох? Я пишу на плюсах, что значит не забывать? Твои сообщения я часто не понимаю, даже с нескольких раз, поэтому переспрашиваю. Дело во мне, потому что я замечаю это и при общении с другими. Да где же это простые вещи. На таких мелочах все и строится. Я пока возился с этим, да и вообще, с тем что раньше, многое чего узнал. А если бы не возился, то так бы и оставался с тем что было. Так что это к лучшему.

Отдельный поток будет потреблять самую малость времени сидя на WaitForSingleObject. Это время будет уходить лишь на проверку освободился ли объект событие. Далее поток не будет занимать процессорное время. То есть если поток ждет 3 секунды, он не тратит все эти 3 секунды зря. Он просто уступает время другим потокам в системе. Raymond Chen То есть я про то что отдельный поток по моему мнению лучше чем система с PeekMessage в MessageLoop. Пускай PopupMenu сам отвечает за себя, вообще любой элемент которому нужен таймер, пусть сам его и создает, в виде потока. Главный поток должен быть абстрагирован от всех этих замеров прошедшего времени, проверки есть ли отложенные задания для все контролов библиотеки для которых это предусмотрено. Зачем нужна эта холостая проверки всех этих отложенных заданий, в случае если ни один контрол пока его не требует. В рамках одного главного GUI потока? То есть использование PeekMesage вместо GetMessage для постоянной работы потока? До конца я не понял схему, все равно. Объясни на конкретном примере, на куске кода, если не трудно. На словах мне иногда трудно понять о чем идет речь. Вот еще на одного сайте нашел Это из Рихтера

В главный MessageLoop? Там лучше использовать GetMessage, чтобы не было потребления процессорного времени в отсутствии сообщений. _beginthreadex использую из-за совместимости с CRT функциями. Не знаю как в этом плане ведет себя std::thread, скорее всего, по логике, std::thread должна быть также совместима. Но, так как в я пока не чувствую себя ущемленным при использоании _beginthreadex , я не перехожу на std::thread. Кроссплатформенность мне пока не по карману, иначе нужно весь код писать в таком стиле. Мне известно только 3 вида таймера. - Стандартный таймер (WM_TIMER Post сообщение). Он не подходит. Неизвестно когда до него дойдет очередь, а мне нужен точный интервал. Плюс из-за него подвисает главный поток, в котором он обрабатывается, незначительно, но все же. Даже если для таймера использовать свою отдельную процедуру. - Мультимедийный таймер. Он тоже не подходит. Он устарел. Плюс для обработки своей процедуры он использует свой поток. - CreateTimerQueueTimer. Но там может возникнуть ситуация, что создастся новый поток. Но зачем мне это, я могу тогда сам создать поток. Нет, я хочу использовать другой поток. Один поток на все дерево PopupMenu. Он контролирует задержки, плавность появления/скрытия. Он создается и удаляется только для главного родительского PopupMenu окна. Но, @Xipho говорит что это не лучший вариант. Понятно, я думал что это какой-то предопределенный механизм WinAPI. А как он будет устроен, этот самописный планировщик. Что из себя он будет представлять? Это какой-то отдельный поток, который создается в начале работы приложения, и удаляется после его завершения? И например у него есть буферная очередь с заданиями. Опиши вкратце его схему. Мне уже не столько интересно это для проекта, сколько просто, для себя, что ты там такое придумал, чего я не нашел ни в интернете ни у себя в голове. Как понять по PeekMessage? Это то что предлагал выше @youneuoy? Даже если воткнуть вместо GetMessage, PeekMessage, то что это меняет? Кто подаст команду/сообщение в очередь сообщений Потока А? Ведь в этом вся суть проблему, - кто будет инициатором для главного потока. Главный поток только имеет право создавать окна, по задумке. Использовать PeekMessage чтобы поток не засыпал? Ну хорошо, используем, поток не спит, а дальше что? Кто отсчитывает интервал, кто подает нужное сообщение. Сам Поток А, используя что-то вроде GetTickCount? Что-то так себе такая схема.

Ну да, у него основа std::thread. Я кстати почему-то не склонен к std::thread. Предпочитаю beginthreadex. Хотя std::vector, std::wstring, очень приветствую. Скажи название функций, этого таинственного планировщика. По логике, - должен быть "кто-то", кто разбудить главный GUI поток А. Который засыпает в функции GetMessage. Кто-то кто пошлет в очередь сообщений новое Post сообщение. Или кто-то кто пошлет сообщение Send-типа, что также разбудит Поток А, обойдя очередь.. В любом случае, кто-то должен разбудить Поток А через и только через сообщение. Иначе поток не проснется. Таймер, - нет. Другой поток, - нет. DCP, - нет, там куча заморочек. Не представляю что еще способно разбудить Поток А. Таинственный планировщик? Но не лежит ли в его основе ThreadPool, вообще манипуляция своими собственными потоками?

Это понятно. Я про функции, которые управляют этими заданиями. Создают их, удаляют. Посмотрел, ничего не понятно. Что-то на уровне драйверов. Подумал. Есть еще вариант с ThreadPool. CreateTimerQueueTimer. Но там может возникнуть ситуация, что создастся новый поток. Еще есть мультимедийным таймер, более точный. Но все это оверинженеринг. Поток на родителя, и все.

Что за отложенные задания? Не могу ничего найти на них.

Хорошая новость, - оказывается все намного проще. Вначале это показали тесты, а теперь и более внимательное чтение MSDN. PeekMessage умеет извлекать сообщения выборочно. Не нужно извлекать все сообщения подряд, тестировать, и заталкивать обратно. PeekMessage Нужно лишь указать фильтр. У меня это while (PeekMessageW(&msg, currentPopupMenu->hWnd, WM_APP + 1, WM_APP + 5, PM_REMOVE)) { Я запихал сообщения в очередь , и только WM_APP + 5 удалилось, как показала консоль-отладчик. То есть сообщение WM_APP + 5 было не в начале очереди, однако нормально удалилось. Буду использовать один специальный поток на родителе PopupMenu. Все дочернии окна, их появление/скрытие, будут управляться им. Думаю это хорошая схема.

Что-то ничего не нашел в интернете. Поиск выдает планировщик Windows. Главный поток приложения тоже простаивает, когда нет сообщений. Да и другие потоки, тоже случается что засыпают. А вообще, что я сделаю. Такова жизнь. Таймеры не подходят, из-за задержек. Можно подумать над тем чтоб поток создавался в момент создания окна родителя PopupMenu, и удалялся после его закрытия.

Ну вообще, наверно бред. Я бы хотел способ попроще. Способ удалить одно сообщение. Но что я могу сделать, так устроили Microsoft. Даже вот сейчас, я нашел баг, - в какой то момент PeekMessage уходит в бесконечный цикл, из кода выше. Видимо система начинает постить какое-то сообщение беспрестанно. И вот теперь новый костыль, - искать как заблокировать очередь, или сделать ее SnapShot, и работать уже с ним. То WM_NCLBUTTONUP не ловится процедурой, потому что так устроено окно, то это, то то. Куча костылей. Это PopupMenu. Реализация задержки появления дочернего PopupMenu. Навел на пункт меню, но окно показывается только спустя несколько секунд. А если отвел курсор с пункта, то таймер должен отключится, и окно не должно появиться. Вот и вся задача. Таймеры это дно, у них наименьший приоритет. Потому я использую потоки, для задержки. Поток-таймер не должен сам создавть окно, поэтому он посылает сообщение главному потоку. Но посылка через SendMessage приводит к DeadLock'y. Я использую PostMessage.

Вчера читал всю эту статью. Также про функции. Также на других сайтах. Все равно не понял почему работа с очередью сообщений это бред. Поток А - это главный GUI поток, он создал кнопку, и он создал поток Б. Поток А вызывает функцию "отмена", в которой закрывает поток Б, ждет его окончания, и зачищает свою же очередь сообщений, перед тем как выйти из функции "отмена". То есть зачистка сообщений производится главным потоком А. Вот так примерно Сообщения засовываются обратно в очередь в правильном порядке. Будет как и было, в FIFO. Идея интересная, но по моему не реализуемая. Буфер создать не проблема. Пусть поток Б заполняет его для потока А. Вот ситуация без отмены потока Б. - Поток А создал поток Б. - Поток А вернулся в MessageLoop, вызвал GetMessage, GetMessage обнаружил что новых сообщений нет, и поэтому Поток А ушел в спячку. - Поток Б завершился сам, после 30 секунд, и заполнил буфер. Но поток А спит, он не может понять что нужно обработать буфер. Нужен кто-то кто его разбудит. Это не может быть поток Б, иначе зачем тогда нужен буфер. Значит это Поток С, который пусть будет создан вместе с потоком Б. Тогда, Поток С, увидев что поток Б завершился сам, вызывает (PostMessageW) поток А, чтобы тот обработал буфер. Но где-то в этот самый момент, я передумал, хочу отменить обработку. Для этого Поток А идет и отменяет Поток С, но он не успел, Поток С уже запостил сообщения из буфера. Ситуация повторилась, стала как и с потоком Б. Значит нужно обязательное удаление сообщений из потока А самим потоком А. Пока что-то иногда вылазят ошибки. Нужно разбираться.

В главном MessageLoop приложения? В этом? Я не понял этот момент. Что такое "средства очереди сообщений винды"? Это функции типа GetMessage/PeekMessage? Осуществлять удаление этими функциями бред? Тогда какими не бред?