Я ни разу не готов говорить за Висту вообще, ее разрабатывают две с чем-то тысячи человек.
Могу разговаривать конкретно за графику, да и та куда сильно больше одного человека. В остальное ввязываться — упаси господь.
Если рассуждать абстрактно — на примере графических драйверов можно сказать, что допиливать драйверы до серьезного уровня может занимать натурально годы. Спустя год мне Виста нравится куда больше, чем в момент релиза.
Но, повторюсь, предметно за что-либо вне графики я не готов говорить.
Ничего такого нет. Но если найдут — моментально уволят, будут очень стараться искать.
Народ больше боится не за код, а за совсем важную информацию — security issues, сроки выхода, новые фичи и т. д.
За такое уже и судиться будут.
Я подозреваю, там на стеке уже много всего, Shell, Printing, Driver, еще поди Network… (они в любом случае далеко от меня сидят :)
Познавательно может быть посмотреть в каком-нибудь Process Explorer call stack падения, а то и тупо отладчиком к explorer.exe подцепиться с самого начала. Может выясниться, что вообще чья-то левая dll виновата.
Слава господу, я не только отладкой занимаюсь, нужно и фичи писать, и над дизайном хоть немного думать. То есть, я в общем-то обычный девелопер, нисколько не ориентированный на отладку.
При всем при этом, все равно основное время сидишь в дебаггере, когда не в раздумьях. На концентрированную отладку сразу закладывается больше половины времени разработки, народ понимает, что он пишет.
Ммм, то есть он ориентирован на анализ асма, когда нет исходного кода и символов?
Я в такие игры сразу не играю, у нас, слава богу, есть и то, и другое.
Если он не поддерживает kernel debug и remote, то вобщем-то и разговаривать не о чем.
К тому же, обычно интересное начинается в момент, когда дебаггер перестает видеть переменные, и там визуальное представление кода уже не поможет…
Интересно, никогда не сталкивался. Мне кажется, это потому что WDDM ортогонален этому добру, он именно для display drivers. Т. е. реализация минипорта скажем у графики своя, только зовем нужные коллбэки в IHV driver.
Я спрошу вокруг еще на всякий случай.
Ммм, я никогда не слышал термина «Windows Driver Foundation».
Есть XDDM (XP Driver Display Model), это то, как писались графические драйверы на XP и раньше.
Есть WDDM (Windows Driver Display Model), новая модель драйвера в Висте. Они независимы, драйвер может быть написали либо под XDDM, либо под WDDM.
Виста поддерживает и то, и другое. Чтобы использовать новую графическую инсфраструктуру ядра и поддерживать новые для Висты API (DX9Ex и D3D10), драйвер должен быть WDDM.
Отсутствием альтернатив и исторической необходимостью, по большому счету.
— Когда Windows начинали писать, никакой Visual Studio не было, в ходу были именно такие отладчики.
— Очень часто надо отлаживать kernel, никаких средств кроме kd в MS для этого нету.
— Это очень мощные дебаггеры, очень. Начиная от скриптов и богатых команд, до огромного количества написанных экстеншенов для специальных случаев (которые выводят статус отдельных подсистем, ищут дедлоки, находят нужные модули на стеке, очень много всякого). То есть, это действительно самый мощный тул отладки, какой есть в MS.
— Так как таким образом отлаживают уже десятилетиями, с этими дебаггерами уже связана большая инфраструктура. Можно очень просто и прозрачно отправить remote, они не требуют установки, их легко конфигурировать для автоматизации, все новые тулы типа AppVerifier заточены на работу с ними.
Чисто user mode еще можно пытаться отлаживать в студии, я первые месяцы так делал. Через год мне на примерах объяснили, что нужно bite the bullet и изучать джедайские тулы.
Боюсь, они скорее специальные, чем рабочие. Я их специально и не стараюсь переводить, они и привычней звучат по-английски, и хорошо акцентируют, где повествование, а где специальный термин. Они все гуглятся и я могу любой из них пояснить, если интересно.
Есть, условно, причины маркетинговые и технические. За маркетинговые (отсутствие которых отрицать нельзя) я не готов говорить, я слишком далеко от них далеко.
Но есть и технические, основная из которых — новая Driver Model (WDDM).
Переносить новую driver model на XP не представляется возможным — слишком много изменений в ядре OS, переносить все фичи DX10 на старую driver model невозможно (виртуализация и шедулинг, к примеру, принципиально не заживет).
Возможен компромисс — переносить только хардверные фичи DX10 на старую driver model, это прилично работы для нас и очень много работы для производителей железа — писать поддержку новых фич для новой и старой driver model, и поведение API будет разным на разных OS.
Но это все равно не полное решение проблемы и очень тяжелое и для MS, и для производителей железа.
Могу разговаривать конкретно за графику, да и та куда сильно больше одного человека. В остальное ввязываться — упаси господь.
Если рассуждать абстрактно — на примере графических драйверов можно сказать, что допиливать драйверы до серьезного уровня может занимать натурально годы. Спустя год мне Виста нравится куда больше, чем в момент релиза.
Но, повторюсь, предметно за что-либо вне графики я не готов говорить.
Мне кажется, через него можно вытянуть всю информацию, какая в pdb есть.
Народ больше боится не за код, а за совсем важную информацию — security issues, сроки выхода, новые фичи и т. д.
За такое уже и судиться будут.
Познавательно может быть посмотреть в каком-нибудь Process Explorer call stack падения, а то и тупо отладчиком к explorer.exe подцепиться с самого начала. Может выясниться, что вообще чья-то левая dll виновата.
При всем при этом, все равно основное время сидишь в дебаггере, когда не в раздумьях. На концентрированную отладку сразу закладывается больше половины времени разработки, народ понимает, что он пишет.
Я в такие игры сразу не играю, у нас, слава богу, есть и то, и другое.
К тому же, обычно интересное начинается в момент, когда дебаггер перестает видеть переменные, и там визуальное представление кода уже не поможет…
Я попробую локально ради интереса, впрочем.
Я спрошу вокруг еще на всякий случай.
Есть XDDM (XP Driver Display Model), это то, как писались графические драйверы на XP и раньше.
Есть WDDM (Windows Driver Display Model), новая модель драйвера в Висте. Они независимы, драйвер может быть написали либо под XDDM, либо под WDDM.
Виста поддерживает и то, и другое. Чтобы использовать новую графическую инсфраструктуру ядра и поддерживать новые для Висты API (DX9Ex и D3D10), драйвер должен быть WDDM.
Надеюсь, я ответил на вопрос.
— Когда Windows начинали писать, никакой Visual Studio не было, в ходу были именно такие отладчики.
— Очень часто надо отлаживать kernel, никаких средств кроме kd в MS для этого нету.
— Это очень мощные дебаггеры, очень. Начиная от скриптов и богатых команд, до огромного количества написанных экстеншенов для специальных случаев (которые выводят статус отдельных подсистем, ищут дедлоки, находят нужные модули на стеке, очень много всякого). То есть, это действительно самый мощный тул отладки, какой есть в MS.
— Так как таким образом отлаживают уже десятилетиями, с этими дебаггерами уже связана большая инфраструктура. Можно очень просто и прозрачно отправить remote, они не требуют установки, их легко конфигурировать для автоматизации, все новые тулы типа AppVerifier заточены на работу с ними.
Чисто user mode еще можно пытаться отлаживать в студии, я первые месяцы так делал. Через год мне на примерах объяснили, что нужно bite the bullet и изучать джедайские тулы.
Но есть и технические, основная из которых — новая Driver Model (WDDM).
Переносить новую driver model на XP не представляется возможным — слишком много изменений в ядре OS, переносить все фичи DX10 на старую driver model невозможно (виртуализация и шедулинг, к примеру, принципиально не заживет).
Возможен компромисс — переносить только хардверные фичи DX10 на старую driver model, это прилично работы для нас и очень много работы для производителей железа — писать поддержку новых фич для новой и старой driver model, и поведение API будет разным на разных OS.
Но это все равно не полное решение проблемы и очень тяжелое и для MS, и для производителей железа.