Pull to refresh
252
0
Семен Козлов @sim0nsays

Пользователь

Send message
Я ни разу не готов говорить за Висту вообще, ее разрабатывают две с чем-то тысячи человек.
Могу разговаривать конкретно за графику, да и та куда сильно больше одного человека. В остальное ввязываться — упаси господь.

Если рассуждать абстрактно — на примере графических драйверов можно сказать, что допиливать драйверы до серьезного уровня может занимать натурально годы. Спустя год мне Виста нравится куда больше, чем в момент релиза.

Но, повторюсь, предметно за что-либо вне графики я не готов говорить.
Интересно. А у тебя есть репро на 10 строчек? Пришли пожалуйста в приват.
Там же целый SDK для работы с pdb есть?
Мне кажется, через него можно вытянуть всю информацию, какая в pdb есть.
Ничего такого нет. Но если найдут — моментально уволят, будут очень стараться искать.
Народ больше боится не за код, а за совсем важную информацию — 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, и для производителей железа.
12 ...
11

Information

Rating
Does not participate
Location
San Francisco, California, США
Works in
Date of birth
Registered
Activity