Not a kernel guy

Одна из не очень удобных особенностей Windows x64 - отсутствие программы для просмотра справочных файлов в формате .hlp. WinHlp32.exe поставляющийся с 32-х битными версиями системы был написан еще во времена Windows 3.1 и по сей день остаётся 16-ти битным приложением. Вместо того, чтобы переписать его под 32 бита было принято волевое решение - в поддержке формата .hlp на 64-х битных системах отказать! Видимо с целью дальнейшей популяризации .chm.

В принципе, меня это не особенно тревожило, до тех пор пока не пришлось поставить консольные утилиты от WinZip 9-ой версии. Единственная справка по параметрам командной строки там как раз в формате .hlp. В том числе сами утилиты при запуске вместо того, чтобы выдать краткую справку в консоли, пытаются показать .hlp файл. Добавлю, что ситуация была - дарёному коню в зубы не смотрят. Либо уже купленный WinZip либо нужно было искать бесплатную (не trial) альтернативу. Пришлось заняться переконвертированием .hlp в .chm.

Хотя в этом процессе нет ничего военного, тем не менее бесплатной утилиты для конвертирования не нашлось. Пришлось разделить процесс на декомпиляцию .hlp и собственно сборку .chm:

1. В качестве декомпилятора .hlp подошёл WinHelp Decompiler (ссылка на саму программу: helpdc21.zip).
2. Компилятор .chm - стандартный HTML Help Workshop.

Единственная проблема, возникшая в процессе, - непонятно как перенести “Содержимое” (AKA Table of Contents) в .chm.

Upd: статья в knowledge base: Windows Help program (WinHlp32.exe) is no longer included with Windows.

Судя по всему, существует довольно распространённое заблуждение касательно использования макросов BUILD_PRODUCES и BUILD_CONSUMES в скриптах для стандартной утилиты build.exe из WDK. Напомню, что эти макросы служат для синхронизации сборки разных частей проекта на многопроцессорной машине. Например, если проект состоит из двух библиотек A и B, и библиотека B использует файлы, сгенерированные в процессе сборки A, то для корректной сборки такого проекта на однопроцессорной машине достаточно указать A перед B в dirs файле. В случае же многопроцессорной машины для синхронизации сборки A и B нужно дополнительно:

• добавить BUILD_PRODUCES=A_lib в “A\sources”;
• добавить BUILD_CONSUMES=A_lib в “B\sources”.

Примечание: Строка “A_lib” в примере выше может быть заменена на любую другую. Следует лишь помнить, что каждое объявление BUILD_PRODUCES должно использовать уникальную строку.

Так вот, заблуждение состоит в том, что при использовании этих макросов порядок директорий в файле dirs может быть произвольным. На самом деле это не так и директория A должна по-прежнему указываться ранее директории B. Если порядок будет обратным, build.exe просто проигнорирует оба макроса. Проверить корректность использования BUILD_PRODUCES и BUILD_CONSUMES можно запустив build.exe с параметром -verifysynchronization.

Ссылка по теме: Building on a Multiprocessor Computer.

Продолжение истории. Кроме C#, теперь можно подучить ASP.NET, SQL Server 2005 и Visual Studio 2005. С нетерпением жду Windows Vista for Dummies.

PS: Наверное, я всё-таки что-то фундаментально не понимаю…

Сегодня, делая себе утренний кофе, наткнулся на объявление, рекламирующее “C# Programming Courses: Basic, Intermediate, Advanced”. Всё бы ничего, но это объявление висит на кухне в здании, где сидит большая часть разработчиков ядра Windows. Я бы не сказал, что это лучшее место, где можно найти желающих подтянуть свои знания по C#. Хуже этого могла бы быть только идея повесить аналогичное объявление в офисе команды, написавшей CLR и компилятор C#.

Ура! Ура! Вышли обновленные версии утилит от Sysinternals, совместимые с Vista x64. Кроме того, анонсирован Process Monitor - новая утилита для мониторинга процессов и потоков, которая, к тому же, включает в себя всю функциональноть RegMon и FileMon! Естественно, что Process Monitor также совместим с Vista x64 (чего не скажешь о RegMon и FileMon).

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

Не обошлось без казуса. При первом запуске Process Monitor на Vista x64 он свалился с Access Violation. Очевидно, что есть ещё простор для усовершенствования. Впрочем, при дальнейших запусках, повторить падение не удалось.

Ссылка на новость: New! Sysinternals TechCenter.

Я давно заметил одну странную вещь - разработчики не очень часто пользуются средствами быстрого поиска по исходникам. Это тем более странно, если учесть тот факт, что существует море доступных инструментов, в том числе множество Open Source проектов, посвященных индексированию и поиску. Я подозреваю, что это связано с отсутствием удобного пользовательского интерфейса. Просматривать исходники в браузере - что может быть хуже? Думаю, что если бы в Visual Studio была бы галочка “Индексировать исходные файлы”, которая автоматически включала индексацию, то 9 из 10 разработчиков использовали бы эту функциональность.

(more…)