Читаю статью на Хабре про виртуальные рабочие столы в Windows. В конце статьи висит вопрос:
UPD: Если вы знаете принцип работы подобных программ или какой-либо отдельной в частности, поделитесь этими знаниями, нам всем будет очень интересно.
И «ответ» – цитата из комментария пользователя enktyptor:
Многие «менеджеры десктопов» Windows работают по схожему принципу — они скрывают все окна (чуть ли не через SW_HIDE), относящиеся не к текущему десктопу (при этом как таковых «десктопов» в системе нет, есть скорее наборы окон). В итоге новые окна и мессадж боксы любая программа открывает на первом десктопе, а не на текущем, плюс появляется ряд проблем, если программа сама использует сокрытие своих окон (например, когда прячется в трей).
Удивительно, но автор статьи разместил только этот кусочек полностью меняя смысл комментария. Часть про то, что поддержка виртуальных рабочих столов встроена в Windows со времен цара Гороха почему-то была аккуратно вырезана. WTF? В смысле, «доколе?» 
Вопрос из почты:
The question is really simple: could we use RtlCaptureContext on X86? The MSDN (http://msdn.microsoft.com/en-us/library/ms680659(v=VS.85).aspx) says it’s only for 64 but the bug is for X86 and I see some kernel code are using it on x86.
Вопрос на самом деле очень прост: можем ли мы использовать функцию RtlCaptureContext на x86? MSDN говорит, что эта функция только для 64-х бит но баг-репорт (имеется ввиду баг-репорт, ранее упомянутый в письме) воспроизводится для x86 и я вижу, что код в ядре использует эту функцию на x86.
Ответ: можно. Действительно, упомянутая страница MSDN утверждает, что:
The following functions are used only on 64-bit Windows.
Следующие функции используются только в 64-х разрядных версиях Windows.
Однако, страница, описывающая саму функцию RtlCaptureContext() указывает Windows XP и Windows Server 2003 в качестве минимальных версий клиента и сервера. Сравните с функцией RtlAddFunctionTable(), действительно не реализованной на x86. Минимальные версии клиента и сервера для неё – Windows XP Professional x64 Edition и 64-bit editions of Windows Server 2003 соответственно.
Другой способ удостовериться в этом – проверить таблицу экспорта NTDLL. Хотя такой способ, конечно, не дает никакой информации о том, документирована функция (иными словами – поддерживается ли обратная совместимость для неё) или нет.
C:\>link /dump /exports c:\Windows\SysWOW64\ntdll.dll | findstr RtlCaptureContext
667 28D 00046B2B RtlCaptureContext
C:\>link /dump /exports c:\Windows\SysWOW64\ntdll.dll | findstr RtlAddFunctionTable
C:\>
Windows Sockets общаются с сетевым стеком через драйвер afd.sys. Происхождение этого имени для меня было загадкой до тех пор, пока я не заглянул в список «Non-Plug and Play Drivers» в Device Manager. Для этого нужно выбрать в меню «Show hidden devices». Оказалось, что это «Ancillary Function Driver for Winsock».
Свойства драйвера afd.sys
За одно новое слово выучил.
Win32 API предоставляет «Ex» варианты функций ReadFile и WriteFile, в то время как «Ex» варианта функции DeviceIoControl не предлагается. Исправить этот недостаток очень просто, так как соответствующая функция Native API документирована в MSDN: NtDeviceIoControlFile (хотя и помечена как «Deprecated»). Прототип новой функции будет выглядеть вот так:
Read more…
Пришло письмо с вопросом:
Обнаружилась следующая проблема:
Наша программа сохраняет и считывает последнюю открытую ею директорию в разделе реестра, где сохраняют последние посещенные ими директории и другие программы, а именно в ветке «HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU». Это в 32-х разрядной версии. Но оказывается, что в 64-х разрядной версии данной ветки реестра в узле HKCU не существует, а она находится в «HKEY_USERS\<некий идентификатор пользователя>\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU».
Так вот вопрос: как мне программно доступиться к этой ветке, если идентификатор пользователя неизвестен? Или, может, есть способ узнать этот идентификатор каким-то образом? А может где-то есть в реестре зеркало этой ветки, к которой можно получить доступ более простым способом?
Read more…
Меня пригласили выступить на конференции РИТ++ 2011, которая пройдет в Москве в конце апреля. Предварительная тема доклада: «Сетевая подсистема Windows глазами разработчика. Краткий, неполный и, в основном, неверный обзор. » Я собираюсь рассказать о том, как работает ядерная часть сетевой подсистемы, как данные попадают в user mode и что с ними происходит по пути. Заходите на огонёк.
На работе понадобилось написать драйвер для сетевой карты. Я этого раньше никогда не делал и вообще с NDIS дела не имел. А тут такая возможность! Делюсь впечатлениями.
В общем и целом NDIS мне понравился. Интерфейсы довольно логичны, хотя и многочисленны. Взаимосвязь между разными компонентами в большинстве случаев после недолгой медитации становится довольно очевидной. Все структуры снабжены заголовком с сигнатурой, версией и размером, что, помимо заботы об обратной совместимости, означает меньше проблем с отладкой. При необходимости нужную структуру можно просто найти в памяти.
Read more…
Recent Comments