Not a kernel guy

Exception Chain Validation (ECV, SEHOP).

2009-10-11T03:46:52Z

Structure Exception Handler (SEH) overwrite - один из популярных способов передачи управления на вредоносный код, внедренный через ту или иную уязвимость (обычно – переполнение буфера). Иными словами, это один из способов подхватить заразу на свой компьютер через непропатченый браузер просто зайдя куда-нибудь с http://www.thehun.net почитать Пушкина на сон грядущий.

Windows Vista SP1/Server 2008 и более поздние версии системы включают механизм защиты от него – Exception Chain Validation (ECV) или Structured Exception Handler Overwrite Protection (SEHOP). К сожалению ECV по умолчанию выключен на клиентских версиях OS из-за несовместимости с некоторыми версиями Cygwin, Skype и программ защищенных с помощью Armadillo. Впрочем, Skype, начиная с 4-ой версии совместим с ECV и, вполне возможно, Cygwin и Armadillo тоже уже исправлены (тут я не в курсе, просто предполагаю).

В общем, если вам нравиться Пушкин :-) (да и если не нравиться – то же), то стоит включить ECV. В Knowledge Base опубликована статья, поясняющая как это сделать – KB956607:

В меню Пуск выберите пункт Выполнить, введите команду regedit и нажмите клавишу ВВОД.
Найдите следующий раздел реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\DisableExceptionChainValidation
Примечание: Если не удалось найти параметр DisableExceptionChainValidation в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\ выполните действия, описанные ниже, чтобы создать его.
1. Щелкните правой кнопкой мыши раздел kernel, выберите команду Создать, а затем — Параметр DWORD.
2. Введите DisableExceptionChainValidation и нажмите клавишу ВВОД.
Дважды щелкните элемент DisableExceptionChainValidation.
Присвойте параметру DisableExceptionChainValidation значение 0, чтобы включить его, а затем нажмите кнопку ОК.
Примечание: Значение 1 отключает этот параметр реестра. Значение 0 включает его.
Закройте редактор реестра.

Дополнительно замечу, что ECV защищает только 32-х битные приложения, включая те, что выполняются под Wow64 на 64-х битных системах. 64-х битный код не подвержен этому типу атаки.

Cross-posted from blog.not-a-kernel-guy.com.

Приколы нашего городка.

2009-09-15T08:53:40Z

Ехал сегодня на работу – увидел на дереве аккуратно прикрепленный листок с крупно распечатанной надписью «Micro$oft hates you». :-) Прямо на 156-ой, почти в самом центре главного кампуса. Во как!

Cross-posted from blog.not-a-kernel-guy.com.

Wow64 поддерживает аппаратное ускорение в DirectX.

2009-08-17T19:21:06Z

Вопрос из почты:

Ты не подскажешь, есть ли hardware acceleration through DirectX for Wow64 processes? В Windows Internals написано, что его нет, но другие источники говорят, что есть (и большинство игр продолжают собирать as 32-bit, и они работают в 64-bit Windows).

Вот несколько ссылок, которые выдает поиск на msdn.microsoft.com:

«Overview of the compatibility considerations for 32-bit programs on 64-bit versions of Windows Server 2003 and Windows XP». В разделе «Intel Architecture 32-bit Execution Layer (IA-32 EL)» есть секция «Graphics support»:
Power Point презентация о внутренней архитектуре Wow64: «WoW64 Internal Architecture» содержит вот такой слайд:
Документ «Best Practices for WOW64» утверждает, что «Microsoft DirectX® hardware acceleration APIs are not supported on IPF.» IPF раcшифровывается как «Itanium Processor Family».

Итого: на x64 аппаратное ускорение есть; на Itanium – нет. На практике это означет, что ускорение есть. Поди еще найди тот Itanium...

Cross-posted from blog.not-a-kernel-guy.com.

Что нового в Windows 7: изменения в Wow64.

2009-06-10T08:49:42Z

Наконец-то обновилась документация в MSDN. Теперь можно спокойно рассказать, что изменилось в Wow64 с выходом Windows 7.

Был полностью переписан механизм перенаправления реестра (Registry Redirection).
Была изменена структура реестра. Многие ключи, перенаправляемые ранее в Wow6432Node, теперь совместно используются 32-х и 64-х разрядными приложениями.
Механизм синхронизации 32-х и 64-х ключей (Registry Reflection) был с корнем выкорчеван и с позором изгнан из кода Windows. :-)
В документацию было внесено множество дополнений и исправлений.

Начну, пожалуй, с перенаправления реестра. Как известно, 64-х битные версии Windows поддерживают два разных представления реестра. Обращения 32-х разрядных приложений к «HKEY_LOCAL_MACHINE\Software» и некоторым другим ключам перенаправляются в «HKEY_LOCAL_MACHINE\Software\Wow6432Node». 64-х разрядные приложения обращаются к «HKEY_LOCAL_MACHINE\Software» напрямую. Таким образом, 32-х битные приложения частично изолируются от 64-х разрядных компонент.

В какой-то момент, разработчики Wow64 столкнулись с проблемой. Некоторые из перенаправляемых ключей должны на самом деле использоваться 32-х и 64-х разрядными приложениями совместно. Для решения этой проблемы был придуман механизм синхронизации (в соответствии со сложными правилами) 32-х и 64-х копий ключей. Он был назван «Registry Reflection».

Почему при этом не было решено отключить перенаправление для этих ключей – загадка. Вероятно, это объясняется особенностями реализации. Никаких разумных «архитектурных» соображений на этот счет нам найти не удалось.

Время показало, что идея использовать Registry Reflection была не слишком хороша. Реестр фундаментально не может обеспечить 100% надежно копирование данных из одного ключа в другой (как и 100% надежность любой другой операции). Но если для «нормальных» операций приложение может получить код ошибки и корректно обработать его, то в случае Registry Reflection приложение решительно ничего не может сделать с кодом ошибки операции копирования.

Помимо этого механизм Registry Reflection:

Не определяет метод разрешения конфликтов в случае, когда модифицируются обе копии ключа.
Конфликтует с механизмом поддержки транзакций в некоторых сценариях.
Создаёт сложности при раздельной установке 32-х и 64-х битных компонент.
Плохо справляется с большим количеством одновременно открытых ключей.
Создает сложности во время завершения процесса.
И т.д. и т.п.

Вдоволь намучавшись с сопровождением этого монстра, мы пришли к заключению, что проблему нужно решать кардинально. Результат – механизм Registry Reflection был полностью убран из Windows 7.

Для обеспечения обратной совместимости с Vista было сделано следующее:

Большинство ключей, которые синхронизировались с помощью Registry Reflection, были исключены из списка перенаправляемых ключей. Иными словами вместо раздельных копий ключа, 32-х и 64-х разрядные приложения теперь совместно используют один и тот же ключ. Полный перечень всех ключей можно найти тут: http://msdn.microsoft.com/en-us/library/aa384253(VS.85).aspx
Некоторые приложения обращаются к 32-х битным ключам по их «физическому» имени, с использованием Wow6432Node в пути, не смотря на то, что это некорректно. Вместо этого следует использовать флаг KEY_WOW64_32KEY. Тем не менее, в механизм перенаправления был обучен распознавать Wow6432Node в пути и интерпретировать наличие Wow6432Node в пути как попытку открыть 32-х разрядный ключ.
COM runtime был основным компонентом завязанным на Registry Reflection. В него были внесены изменения, позволяющие ему обходится без Registry Reflection. Внешние интерфейсы COM runtime при этом затронуты не были.

Тестирование этих изменений показало, что существующие приложения очень хорошо чувствуют себя в новом окружении, не замечая подмены. При этом заметно уменьшилось время, затрачиваемое приложениями на операции с реестром. Так, при установке Microsoft Office 2003 суммарное время всех операций с реестром сократилось примерно на 30%.

По итогам этой работы была пересмотрена и обновлена вся публичная документация, относящаяся к Wow64:

Cross-posted from blog.not-a-kernel-guy.com.

Microsoft и РФ обсудили фиксированные цены на ПО для госзакупок.

2009-06-06T02:06:00Z

В комментариях к предыдущему посту шла речь о том, что ФАС, прижимая монополистов, заботится о потребителях. Ну что ж, одного такого потребителя можно назвать уже сейчас (выделение мое):

Министр связи и массовых коммуникаций РФ Игорь Щеголев обсудил с президентом Microsoft International Жан-Филиппом Куртуа вопрос об установлении фиксированных цен на программное обеспечение для госзакупок в России.

Обе новости разделяет пара дней. Прямо какое-то мистическое совпадение. :-)

Министр также отметил, что при внедрении в России этого механизма целесообразно устанавливать цены в рублях. По мнению И.Щеголева, Microsoft имеет достаточные возможности компенсации колебаний курса рубля к доллару с использованием хедж-фондов.

Я, кстати, думал, что в России цены и так в рублях. Или там такой специальный курс рубля планируется использовать? ;-)

Cross-posted from blog.not-a-kernel-guy.com.

ФАС возбудила дело против Microsoft

2009-06-04T21:00:00Z

С Хабра:

Признаки нарушения антимонопольного законодательства со стороны корпорации Microsoft усматриваются в экономически или технологически не обоснованном прекращении производства и поставок на территорию Российской Федерации операционных систем (ОС) для персональных компьютеров (ПК) семейства «Microsoft Windows» коробочных версий — дистрибутивов ОС «Windows XP» и сокращении поставок данной ОС в качестве предустановленной при продаже нового компьютера, а также в установлении различных цен на ОС «Windows XP».

Прелесть какая! :-)

Cross-posted from blog.not-a-kernel-guy.com.

Отладка на кофейной гуще.

2009-05-23T09:52:57Z

При определённой сноровке, можно отлаживать код прямо из любимого почтового клиента. На днях пришло письмо с вопросом. Некоторое приложение, будучи установленным в каталог отличный от “Program Files”, при запуске вызывало появление окна UAC с требованием повысить привилегии. Приложение работало нормально, в случае, если оно было установлено в “Program Files”. Как такое может быть?

Надо сказать, что разработчики подсистем Windows, которые обеспечивают обратную совместимость, вплотную приблизились к созданию искусственного интеллекта. :-) Windows умеет распознавать и, что самое главное, исправлять на ходу многие некорректные с точки зрения системы действия программ. Заметная часть этого «интеллекта» задействована для обеспечения совместимости с приложениями, которые не умеют работать без прав локального администратора, т.е. при включенном UAC.

Предположение, что программа делает что-то нехорошее, - пытается создать файл в «Program Files» например, вскоре частично подтвердилось. Автор приложения обнаружил, что оно пытается создать ключ реестра “HKEY_CLASSES_ROOT\.foobar”. Интересная особенность всех ключей в ветке “HKEY_CLASSES_ROOT” состоит в том, что эти ключи … не существуют. “HKEY_CLASSES_ROOT” – это виртуальный ключ, объединение двух других ключей: “HKEY_LOCAL_MACHINE\Software\Classes” и “HKEY_CURRENT_USER\Software\Classes”. Соответственно попытка создать ключ “HKEY_CLASSES_ROOT\.foobar” может, при определённых условиях, быть интерпретирована как попытка создания “HKEY_LOCAL_MACHINE\Software\Classes\.foobar”, что уже попахивает криминалом.

Далее, существует такая штука как LUA Virtualization. Если коротко, то это механизм как бы позволяющий приложению писать в ключи и каталоги, защищенные от записи. На самом деле, система на лету подменяет оригинальный ключ доступной на запись копией, локальной для этого конкретного приложения.

Соединив эти три кусочка информации, можно примерно догадаться что произошло. Хотя точно сказать, что именно произошло, я не берусь. Скорее всего, программа попыталась создать “HKEY_LOCAL_MACHINE\Software\Classes\.foobar”. Эта попытка была перехвачена механизмом LUA Virtualization. В случае, когда исполняемый файл находился в “Program Files”, механизм виртуализации делал свое черное дело, подсовывая приложению локальную копию ключа. В другом случае виртуализация не срабатывала, приводя к тому, что запрещенная операция перехватывалась уже логикой активации UAC.

Cross-posted from blog.not-a-kernel-guy.com.

Как отлаживать код незнакомых приложений?

2009-05-18T08:48:58Z

… легко постукивая кувалдой.

Вопрос из почты:

Я пытаюсь приспособить windbg не для отладки, а для реверсинга незнакомых приложений, и постоянно упираюсь в то, что для удобной работы нужны символы, иначе windbg (в юзермоде, конечно) ничем не сильнее того же OllyDbg. Но, я надеюсь, что не все так плохо с этим отладчиком, и это у меня руки кривые.

Если символьной информации нет, то частично заменить её можно только хорошенько проштудировав бинарный код. WinDbg таким, вроде бы, не занимается. В идеальном случае хотелось бы, чтобы отладчик умел все, что умеет IDA Pro и при этом имел расширяемость как у WinDbg. Хотя если судить по сайту, последние версии IDA имеют встроенный отладчик.

Я не в курсе насколько хорошо OllyDbg анализирует код и насколько это помогает при отладке. Если он заметно удобнее WinDbg, то логичнее всего было бы им и пользоваться.

Не могли бы Вы мне ответить на простенький вопрос, как корректно брякнуться на энтрипойнт приложения которому нет символов? Без танцев с бубном. Может, плугин какой есть?

Корректно - вот так: ;-)

bp <address> или ba <address>

Адрес в общем случае без танцев с бубном не находится, даже в случае IDA. Обычно поиски начинаются с крупиц информации из шагов для воспроизведения сценария. Программа обращается к определенному ключу в реестре? Ставим точку останова на RegCreateKeyEx/RegOpenKeyEx. Происходит определённое исключение? Ловим именно это исключение. После нескольких итераций находятся конкретные места в коде приложения, в которых выполняются интересующие нас действия.

В общем, ложки серебряной пули не существует.

Cross-posted from blog.not-a-kernel-guy.com.

Расширение для WinDbg: «Outline».

2009-05-17T08:49:39Z

Мне частенько приходится разбираться с отладкой исключений, произошедших из-за порчи стека или на фоне порчи стека. В таких случаях обычно приходится трассировать стек вручную. Дело это муторное, поэтому я решил написать расширение для WinDbg, несколько облегчающее эту задачу.

На данный момент реализована только одна команда «!fnframe». Она показывает структуру стекового фрейма для произвольной функции: локальные переменные и параметры, сохраненные регистры, указатель фрейма. На x64 помимо символов используется сгенерированная компилятором unwind information, что обеспечивает большую достоверность результатов. Поддержка Itanium пока в планах.

Скачать:

Outline 1.0.1 x86 (SHA1: 6dd2edb49940ac4d48016e49fb5c6ffe4d53d56d)
Outline 1.0.1 x64 (SHA1: 47b6c5e9b63c783126cc823e979a8d2882c6492f)

Примеры:

x86 сборка Far Manager 2.0 с включенным frame pointer omission:

0:000:x86> .load outline
0:000:x86> !fnframe far!wmain
 Start of frame               --> -0x78
   -0x78   Saved registers      : 0x10 bytes
   -0x64   strViewName          : class UnicodeString, 0x4 bytes
   -0x60   strEditName          : class UnicodeString, 0x4 bytes
   -0x5c   StartLine            : int, 0x4 bytes
   -0x58   CntDestName          : int, 0x4 bytes
   -0x54   DestNames            : class UnicodeString [2], 0x8 bytes
   -0x4c   RectoreConsole       : int, 0x4 bytes
   -0x48   StartChar            : int, 0x4 bytes
   -0x44   __ConsoleRestore     : class TConsoleRestore, 0x24 bytes
   -0x20   buf                  : char [15], 0xf bytes
   +0x0    Return address       : 0x4 bytes
   +0x4    Argc                 : int, 0x4 bytes
   +0x8    Argv                 : wchar_t **, 0x4 bytes
 End of frame                 --> +0xc
0:000:x86>

x64 сборка того же Far Manager 2.0:

0:000> !fnframe far!wmain
 Start of frame               --> +0x0
   +0x0    rcx home             : 0x8 bytes
   +0x8    rdx home             : 0x8 bytes
   +0x10   r8 home              : 0x8 bytes
   +0x18   r9 home              : 0x8 bytes
   +0x40   strEditName          : class UnicodeString, 0x8 bytes
   +0x48   strViewName          : class UnicodeString, 0x8 bytes
   +0x50   DestNames            : class UnicodeString [2], 0x10 bytes
   +0x60   __ConsoleRestore     : class TConsoleRestore, 0x30 bytes
   +0x98   buf                  : char [15], 0xf bytes
   +0xb0   r15                  : 0x8 bytes
   +0xb8   r14                  : 0x8 bytes
   +0xc0   r13                  : 0x8 bytes
   +0xc8   r12                  : 0x8 bytes
   +0xd0   rdi                  : 0x8 bytes
   +0xd8   rsi                  : 0x8 bytes
   +0xe0   rbp                  : 0x8 bytes
   +0xe8   Return address       : 0x8 bytes
 End of frame                 --> +0xf0
   +0xf0   Argc                 : int, 0x4 bytes
   +0xf8   Argv                 : wchar_t **, 0x8 bytes
   +0x100  rbx                  : 0x8 bytes
0:000>

Публичные символы не описывают ntdll!KiUserExceptionDispatcher (точка входа диспетчера исключений пользовательского режима), но включенная в бинарный файл unwind information дает кое-какое представление об этой функции:

0:000> !fnframe ntdll!KiUserExceptionDispatcher
 Start of frame               --> +0x0
   +0x0    rcx home             : 0x8 bytes
   +0x8    rdx home             : 0x8 bytes
   +0x10   r8 home              : 0x8 bytes
   +0x18   r9 home              : 0x8 bytes
   +0x90   rbx                  : 0x8 bytes
   +0xa0   rbp                  : 0x8 bytes
   +0xa8   rsi                  : 0x8 bytes
   +0xb0   rdi                  : 0x8 bytes
   +0xd8   r12                  : 0x8 bytes
   +0xe0   r13                  : 0x8 bytes
   +0xe8   r14                  : 0x8 bytes
   +0xf0   r15                  : 0x8 bytes
   +0x200  xmm6                 : 0x10 bytes
   +0x210  xmm7                 : 0x10 bytes
   +0x220  xmm8                 : 0x10 bytes
   +0x230  xmm9                 : 0x10 bytes
   +0x240  xmm10                : 0x10 bytes
   +0x250  xmm11                : 0x10 bytes
   +0x260  xmm12                : 0x10 bytes
   +0x270  xmm13                : 0x10 bytes
   +0x280  xmm14                : 0x10 bytes
   +0x290  xmm15                : 0x10 bytes
   +0x590  Machine frame        : 0x28 bytes
 End of frame                 --> +0x5b8
0:000>

Cross-posted from blog.not-a-kernel-guy.com.

Windows Internals, Fifth Edition

2009-05-13T20:57:14Z

5-ая редакция книги Windows Internals отправлена в печать. Ура, товарищи! :-) Я там скромно присутствую в списке рецензентов... вместе с доброй половиной kernel team. ;-)

Cross-posted from blog.not-a-kernel-guy.com.

Холивар на марше – ошибка в Windows 7 RC x86.

2009-05-13T08:56:30Z

В Windows 7 RC x86 нашли ошибку. Довольно неприятную, надо сказать. В связи с чем в комментариях к заметке на ZDnet разгорелся очередной холивар. Почитайте, зело интересно.

Пойти, что ли, в NASA работать? Писать софт, который управляет вспомогательным клапаном резервной задвижки дублирующей системы озонирования воздуха в кабине Ориона. Зато 100% доказанная корректность кода и никаких программных ошибок. Только сбои в железе и космические лучи. Ляпота! И никто не капает на мозги, не кричит «О боже, там баг!». Ммм… ;-)

Cross-posted from blog.not-a-kernel-guy.com.

Даже и не думайте пользоваться функцией Wow64DisableWow64FsRedirection!

2009-04-03T20:41:03Z

Просто удивительно, насколько опасной может быть функция Wow64DisableWow64FsRedirection. Эта функция позволяет временно отключить перенаправление файловой системы в Wow64. Еще более удивительно, что лишь малая доля разработчиков соглашается менять свой код, даже после подробного объяснения, в чем, собственно, проблема.

В чем состоит опасность? Во-первых, при отключенном перенаправлении файловой системы не работает загрузка 32-х битных системных библиотек. Они, как правило, загружаются из system32 и только перенаправление ввода/вывода спасает ситуацию. Во-вторых, и это самое главное, разработчик очень редко полностью контролирует весь ввод-вывод на участке между Wow64DisableWow64FsRedirection и Wow64RevertWow64FsRedirection.

«Как это возможно?» - спросите вы, «ведь все три строчки кода – вот они, как на ладони». Очень просто. Вот неполный список случаев, когда может происходить неявная загрузка кода:

Неявный вызов LoadLibrary. Многие функции Win32 вызывают LoadLibrary. Один из примеров – Multimedia API. То же самое делают и другие библиотеки, особенно те, что поддерживают плагины.
Отложенная загрузка библиотек (Delayed Loading) – это хороший способ ускорить загрузку приложения. Проблема только в том, что загрузка может случиться в любой, в том числе самый неподходящий момент. Все приложения, так или иначе, используют отложенную загрузку, так как ею пользуются ключевые системные библиотеки.

Так называемые «DLL import forwarders» позволяют сказать загрузчику, что функция «Foo», экспортируемая из «Foo.dll», на самом деле реализована в «Bar.dll». В результате при попытке получить адрес функции «Foo», загрузчик попытается загрузить «Bar.dll». Например:

link /dump /exports c:\Windows\System32\kernel32.dll | findstr forwarded
          1    0          AcquireSRWLockExclusive (forwarded to NTDLL.RtlAcquireSRWLockExclusive)
          2    1          AcquireSRWLockShared (forwarded to NTDLL.RtlAcquireSRWLockShared)
         14    D          AddVectoredContinueHandler (forwarded to NTDLL.RtlAddVectoredContinueHandler)
         15    E          AddVectoredExceptionHandler (forwarded to NTDLL.RtlAddVectoredExceptionHandler)
         70   45          CancelThreadpoolIo (forwarded to NTDLL.TpCancelAsyncIoOperation)
         86   55          CloseThreadpool (forwarded to NTDLL.TpReleasePool)
         87   56          CloseThreadpoolCleanupGroup (forwarded to NTDLL.TpReleaseCleanupGroup)
         88   57          CloseThreadpoolCleanupGroupMembers (forwarded to NTDLL.TpReleaseCleanupGroupMembers)
         89   58          CloseThreadpoolIo (forwarded to NTDLL.TpReleaseIoCompletion)
         90   59          CloseThreadpoolTimer (forwarded to NTDLL.TpReleaseTimer)
         91   5A          CloseThreadpoolWait (forwarded to NTDLL.TpReleaseWait)
         92   5B          CloseThreadpoolWork (forwarded to NTDLL.TpReleaseWork)

Взаимодействие с COM объектами очень часто приводит к загрузке дополнительных библиотек. К примеру, это быть вызов QueryInterface или любой другой вызов возвращающий указатель на COM интерфейс.
Внедрение кода в другой процесс – обычное дело в Windows. Внедренный код может вызвать LoadLibrary в самый неподходящий момент. В этом случае виноват не ваш код, но с точки зрения пользователя упадет именно ваше приложение.
и т.д. и т.п.

Проблема еще и в том, что код, использующий Wow64DisableWow64FsRedirection, в общем-то, работает в большинстве случаев. Так что разработчик не видит проблемы до тех пор, пока код не будет запущен в незнакомом окружении на машине заказчика. Или пока не выйдет новая версия ОС, используемой библиотеки или клавиатурного шпиона, которая вдруг начала загружать код в том месте, где раньше ничего такого не происходило.

PS. А когда можно использовать Wow64DisableWow64FsRedirection? Единственный поддерживаемый сценарий – вызов CreateFile, обернутый в Wow64DisableWow64FsRedirection и Wow64RevertWow64FsRedirection.

Cross-posted from blog.not-a-kernel-guy.com.

“This program requires Windows 2000 or newer operating system”.

2009-03-26T06:21:00Z

Когда видишь такое сообщение на Windows 7, это означает, что разработчики приложения допустили ошибку либо в коде проверки версии операционной системы, либо, что менее вероятно, - в самом сообщении. Второй вариант возможен, если программа действительно не должна работать в новых версиях операционной системы. В обоих случаях, с точки зрения пользователя это чистой воды баг. То ли в коде, то ли в дизайне, то ли в маркетинговом отделе…

В любом случае обходятся такие ограничения элементарно просто. Достаточно открыть окно свойств исполняемого файла или ярлыка, выбрать вкладку «совместимость» и в выпадающем списке выбрать нужную версию операционной системы. При следующем запуске, программа будет запущена вместе с набором заплаток, которые в том числе подменяют номер версии системы:

Cross-posted from blog.not-a-kernel-guy.com.

.NET toolset для Boost Build V2.

2009-03-09T23:24:00Z

Специально для любителей Boost.Build V2 – написал toolset, добавляющий поддержку C# и VB.NET компиляторов из .NET Framework. Toolset автоматически распознает все установленные версии .NET Framework:

using dotnet : all ;

Исполняемые файлы и библиотеки собирается как обычно с помощью правил “exe” и “lib”. Ссылки на системные библиотеки указываются через <find-shared-library>; путь к ним – с помощью <library-path>:

lib carrots
    :
        carrots.cs
    ;

windir = [ modules.peek : windir ] ;

exe rabbit
    :
        rabbit.cs
        carrots
    :
        <library-path>"$(windir)/Microsoft.NET/Framework/v2.0.50727"
        <find-shared-library>System.dll
        <find-shared-library>System.Data.dll
    ;

Можно указать целевую платформу с помощью <architecture> и <address-model>. По умолчанию – anycpu.

Cross-posted from blog.not-a-kernel-guy.com.

Вчера случился забавный момент...

2009-03-04T04:24:28Z

Копировал большой VHD файл с одной из тестовых машин на внешний диск, подключенный через FireWire. При этом предварительно запретил запуск тестов на этой машине, чтобы кто-то (или я сам) ничего не запустил там вдруг серию тестов, так как при этом отформатируется раздел с VHD файлом. Образ большой, копируется долго и я, естественно, отвлёкся на другие дела.

Через пару часов вспоминаю про файл, переключаю KVM на эту машину и вижу консоль запущенного кем-то теста. Лог в консоли при этом бодро обновляется. В голове проносится мысль: «Так. Опять накрылся почтовый архив». Потом понимаю, что что-то не так. Во-первых, я никому доступа к этой машине не давал. Во-вторых, на экране явно древняя версия Windows 7, едва ли не годичной давности. Тогда панель задач выглядела совсем по-другому. В-третьих, система собрана из ветки, для которой сборки хранятся максимум неделю. Ну и куча других несуразностей вроде неправильно выставленного системного времени.

Обман вскрылся, стоило только прикоснуться к клавиатуре. Как оказалось, каким-то образом запустился просмотрщик картинок и начал показывать slide show в полноэкранном режиме. Подозреваю, что окошко, всплывающее при обнаружении в системе нового диска, сыграло свою роль. А снимки экрана были сделаны самим тестом, когда он запускался на этой машине в апреле 2008. :-)

Cross-posted from blog.not-a-kernel-guy.com.