PyKd: Boost.Python build cmd

В который раз потребовалось собрать библиотеку и как это обычно бывает весьма не кстати потерялся командный файл упрощающий этот процесс.
Пришлось всё делать сначала. В итоге получился командный файл для сборки библиотеки Boost.Python, который также можно использовать в качестве шаблона для сборки необходимых boost-библиотек:

::
:: Build x86/x64 Boost.Python library
::
call :ExecBjam 32
call :ExecBjam 64
pause
goto :EOF

::
:: Execute bjam.exe with required params
::
:ExecBjam
set arch=%1
set stagedir=stage

if "%arch%"=="64" set stagedir=stage64

bjam.exe ^
    -j 2 ^
    --toolset=msvc-9.0 ^
    release debug ^
    threading=multi link=static runtime-link=shared ^
    address-model=%arch% ^
    --with-python --with-date_time ^
    --stagedir=%stagedir% ^
    stage
goto :EOF

Краткое пояснение:

• call :ExecBjam XX - сборка для i386 и amd64
• -j N - задействовать N ядер
• --toolset=msvc-9.0 - Visual Studio 2008
• threading=multi - сборка с поддержкой многопоточности
• --with-python - При сборке я предпочитаю использовать --with-libname вместо --without-libname, т.к. в этом случае будут скомпилированы только указанные библиотеки (что бы не собирать неиспользуемые библиотеки)
• link=static - собрать статическую версию библиотек
• runtime-link=shared - динамическая линковка с Visual C++ Runtime
• --stagedir=stage%arch% - директория для выходных файлов (stage для x86 и stage64 для и x64)

Cmd: Detect 64-bit Windows

Windows 64-bit присутствует на рынке довольно давно, но несмотря на это, не перестаёт удивлять разнообразие методов (не всегда корректных) определения разрядности системы в cmd скриптах.

В качестве примера, рассмотрим популярные ответы на вопрос Detect Windows Server version 32/64-bit in CLI на сайте superuser.com:

1. systeminfo | find /I "System type"
   

   Недостатки: Во первых, работает медленно. Во вторых, не будет работать если используется локаль отличная от английской. В третьих, необходимо дополнительно проводить разбор вывода.
   
   

2. Arch=x86
   if exist "%ProgramFiles(x86)%" set Arch=x64
   

   Недостаток: Условие отработает некорректно если существует директория с таким именем. Редкий случай, но тем не менее возможный.
   
   

3. reg.exe query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" | find "BuildLabEx"
   

   Недостаток: Необходим дополнительный разбор вывода.
   
   

4. wmic OS get OSArchitecture
   

   Недостаток: Необходим дополнительный разбор вывода.
   
   

5. set Arch=x64
   if "%PROCESSOR_ARCHITECTURE%" == "x86" ( 
       if not defined PROCESSOR_ARCHITEW6432 set Arch=x86
   )
   

   Недостатки: пока не обнаружены.
   Продолжительное время успешно использую данный метод. К тому же, при желании можно уточнить актуальную архитектуру: x86, amd64, ia64.
   

А какой способ используете Вы?

Cmd: reg.exe undocumented /reg switch

Задача

Из командного файла прочитать значение в реестре. В 64-х разрядной системе, в зависимости от условия читать из 32-х или 64-х битной ветки. Если используется 64-х битная версия cmd.exe, всё относительно просто: в зависимости от условия читать из HKLM\Software или HKLM\Software\Wow6432Node.

В 32-х битной версии командного интерпретатора (Post-Build Event в Visual Studio) этот способ не работает, т.к. запросы reg.exe перенаправляются подсистемой WOW64 в HKLM\Software\Wow6432Node.

Решение

Как подсказывает заголовок, reg.exe имеет недокументированный ключ /reg:. После двоеточия, без пробела, следует указать требуемую разрядность ("32" или "64"). Этот ключ работает в 32-х битной и 64-х битной версии утилиты, поэтому грамотно созданный командный файл будет корректно работать в интерпретаторе любой разрядности.

Пример использования (на всякий случай):

reg.exe query HKLM\Software\Python\PythonCore\2.6\InstallPath /ve /reg:64

Рабочая среда: Windows 7 x64

Cmd: Backup/Clear/Restore environment variables

Публикация в первую очередь будет интересна тем, кто использует WDK/DDK для сборки чего-либо (например, драйверов). Но возможно пригодится ещё кому-то.

Проблема

При сборке из командной строки setenv.bat устанавливает переменные окружения таким образом что повторный вызов этого командного файла генерирует сообщение:

ERROR: This window already has the DDK build environment set.  Please open 
       a new window if you want to change or reset your build environment.

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

Решение

VeriSign "Signtool Error: The provided cross certificate would not be present in the certificate chain."

Проблема

Попытка подписать драйвер сертификатом от VeriSign и кросс-сертификатом от Microsoft:

%WDKPATH%\Bin\x86\signtool.exe sign /v /ac MSCV-VSClass3.cer /f cert.pfx /p password /t http://timestamp.verisign.com/scripts/timtamp.dll driver.sys

Не увенчалась успехом:

Signtool Error: The provided cross certificate would not be present in the certificate chain.

Алгоритм подписания рабочий и проверенный. Изучение базы знаний US Home > Support > Code Signing Support с ходу результата не дало.

Решение

PYTHONPATH в Windows x64

Проблема

Для удобства создания скриптов на Python-е, в т.ч. для pykd, решил воспользоваться расширением pytools для Visual Studio.

Чтобы интерпретатор Python-а находил модуль pykd без указания полного пути, добавил в переменную окружения PYTHONPATH путь к 64-х битной и 32-х битной версии расширения. В моём случае C:\WinDDK\WinDbgX64\winext и C:\WinDDK\WinDbgX86\winext соответственно. После этого интерпретатор начал падать при попытке использования модуля (похоже что происходит сбой во время загрузки pykd.pyd не соответствующей разрядности).

Вывод очевиден. Если в системе одновременно установлен Python для x86 и x64, то переменную окружения PYTHONPATH лучше не использовать.

Решение