Not a kernel guy

Навеяно постом про ExUuidCreate и в частности вот этой фразой:

Well, I suggest MSFT to documented this behavior, or at least explain this case in documentation.

Вкратце, суть статьи сводится к тому, что функция ExUuidCreate может изменять содержимое возвращаемого буфера даже в том случае, если она возвращает ошибку. Далее, в комментариях, завязался спор на тему имеет ли функция право трогать буфер в случае ошибки.

(more…)

Эта неделя началась замечательно, - а именно с безуспешных попыток выяснить, почему валиться билд. Надо сказать, что и в невоенное-то время разобраться, что именно поломалось бывает непросто. Но в этот раз все было еще веселее чем обычно. Некая утилита (не будем показывать пальцем, хотя утилита написана на .NET ), выдавала примерно следующий лог:

...
> FooBar: parsing Z:\temp\tmp1234.tmp
> FooBar: error XXXX, line 123, Z:\temp\tmp1234.tmp
...

(more…)

Вопрос:

32-х битный процесс запущен на 64-х битной системе. Почему для некоторых библиотек GetModuleFileName возвращает путь вида “%SystemRoot%\syswow64”, а для других - “%SystemRoot%\system32”, не смотря на то, что и первые, и вторые находятся в “%SystemRoot%\syswow64”?

Ответ:

Потому что загрузчик понятия не имеет о Wow64 и перенаправлении файловой системы в частности. Загрузчик просто сохраняет полное имя модуля во время загрузки и возвращает его копию в GetModuleFileName. Соответственно если библиотека была загружена как “%SystemRoot%\system32\foobar.dll”, то и GetModuleFileName вернёт эту строку.

Это же верно и для других Win32 функций.

Хорошая статья: Особенности реализации командного процессора cmd.exe операционных систем WinNT. Напрочь отбивает всякое желание связываться с написанием скриптов для cmd.exe.