прошу прощения за некоторый оффтоп, но понял где то процентов 50, и то интуитивно (ибо на таком уровне не работаю)
Напомнило монолог из south park про марклар моего марклара.
Хотя в общем то история одного джедая :)
Есть, условно, причины маркетинговые и технические. За маркетинговые (отсутствие которых отрицать нельзя) я не готов говорить, я слишком далеко от них далеко.
Но есть и технические, основная из которых — новая Driver Model (WDDM).
Переносить новую driver model на XP не представляется возможным — слишком много изменений в ядре OS, переносить все фичи DX10 на старую driver model невозможно (виртуализация и шедулинг, к примеру, принципиально не заживет).
Возможен компромисс — переносить только хардверные фичи DX10 на старую driver model, это прилично работы для нас и очень много работы для производителей железа — писать поддержку новых фич для новой и старой driver model, и поведение API будет разным на разных OS.
Но это все равно не полное решение проблемы и очень тяжелое и для MS, и для производителей железа.
Ммм, я никогда не слышал термина «Windows Driver Foundation».
Есть XDDM (XP Driver Display Model), это то, как писались графические драйверы на XP и раньше.
Есть WDDM (Windows Driver Display Model), новая модель драйвера в Висте. Они независимы, драйвер может быть написали либо под XDDM, либо под WDDM.
Виста поддерживает и то, и другое. Чтобы использовать новую графическую инсфраструктуру ядра и поддерживать новые для Висты API (DX9Ex и D3D10), драйвер должен быть WDDM.
Интересно, никогда не сталкивался. Мне кажется, это потому что WDDM ортогонален этому добру, он именно для display drivers. Т. е. реализация минипорта скажем у графики своя, только зовем нужные коллбэки в IHV driver.
Я спрошу вокруг еще на всякий случай.
Я не смотрел детально, но видимо своя реализация d3d10.dll и компании, которая пытается форвардить вызовы в OGL (а то и D3D9). Пока не случается использования новой инфрастуктуры — теоретически это можно заставить работать, ценой эффективности и эмуляции. Практически — не все производители видеоркарт выпустили для OGL экстеншены, соответствующие D3D10, и прочая, прочая.
Ладно десятый DirectX, с ним понятно. Работы по переносу драйверов ещё и в XP огромные, а тут нужно ещё Vist'у рекламировать. Тем более в новой ОС появилась возможность сделать API над всеми новыми Direct'ами — DXGI, что помоему очень хорошо. Так как все общие функции вынесены в него: SwapChain (наконец-то они быстро работают!), управление Gamm'ой, Surface'ы (их можно шарить между девайсами! ура!). ))
Только жаль что Microsoft все таки с такими профессионалами отладки пропускает серьезные баги в своих SP'ах. Вон в 1-ом SP для Vist'ы(как в 32 битной, так и в 64-ой) намертво отвалились Multihead D3D9 устройства, в Reset() все падает где-то в d3d9.dll. Главное и неотправишь баг никуда, на форуме XNA меня успешно проигнорировали (может конечно виной мой английский ))).
Ладно десятый DirectX, с ним понятно. Работы по переносу драйверов ещё и в XP огромные, а тут нужно ещё Vist'у рекламировать. Тем более в новой ОС появилась возможность сделать API над всеми новыми Direct'ами — DXGI, что помоему очень хорошо. Так как все общие функции вынесены в него: SwapChain (наконец-то они быстро работают!), управление Gamm'ой, Surface'ы (их можно шарить между девайсами! ура!). ))
Только жаль что Microsoft все таки с такими профессионалами отладки пропускает серьезные баги в своих SP'ах. Вон в 1-ом SP для Vist'ы(как в 32 битной, так и в 64-ой) намертво отвалились Multihead D3D9 устройства, в Reset() все падает где-то в d3d9.dll. Главное и неотправишь баг никуда, на форуме XNA меня успешно проигнорировали (может конечно виной мой английский ))).
Боюсь, они скорее специальные, чем рабочие. Я их специально и не стараюсь переводить, они и привычней звучат по-английски, и хорошо акцентируют, где повествование, а где специальный термин. Они все гуглятся и я могу любой из них пояснить, если интересно.
Я подозреваю, там на стеке уже много всего, Shell, Printing, Driver, еще поди Network… (они в любом случае далеко от меня сидят :)
Познавательно может быть посмотреть в каком-нибудь Process Explorer call stack падения, а то и тупо отладчиком к explorer.exe подцепиться с самого начала. Может выясниться, что вообще чья-то левая dll виновата.
Все оказалось гораздо проще — в Vista очень много чего пишется в логи… тьфу в журналы. Так вот посмотрев их внимательно стало ясно что виновата вовсе не она, а… драйвер HP 1010, ведь говорил давно уже что пора выкунить этот ретро-принтер.
Интересно, сколько еще существует энтузиастов пишущих свой движок?
:) :)
Эта тема была очень популярна лет 5 — 7 назад. С тех пор, я так понимаю, движкоделов и рендероделов которые заинтересованы в PC платформе значительно поубавилось.
Во первых совершенно непонятно с чего вы взяли, что автор расказывает о том, как он пишет свой движек. Статья о другом.
Во вторых писали и будут писать. Невозможно на движке Q3 9-и летней давности написать приличную игру сейчас, как бы он не был хорош в свое время.
Ну вот их и написали как раз те самые энтузиасты. А могли бы просто взять квейковский движок. :)
А если серьёзно, то писание движков практически с нуля — в гейм-девелопинге дело регулярное. Пишут часто, и это считается нормальным. Скажем, например, неповторимый стиль игре чужим движком не придать.
Отсутствием альтернатив и исторической необходимостью, по большому счету.
— Когда Windows начинали писать, никакой Visual Studio не было, в ходу были именно такие отладчики.
— Очень часто надо отлаживать kernel, никаких средств кроме kd в MS для этого нету.
— Это очень мощные дебаггеры, очень. Начиная от скриптов и богатых команд, до огромного количества написанных экстеншенов для специальных случаев (которые выводят статус отдельных подсистем, ищут дедлоки, находят нужные модули на стеке, очень много всякого). То есть, это действительно самый мощный тул отладки, какой есть в MS.
— Так как таким образом отлаживают уже десятилетиями, с этими дебаггерами уже связана большая инфраструктура. Можно очень просто и прозрачно отправить remote, они не требуют установки, их легко конфигурировать для автоматизации, все новые тулы типа AppVerifier заточены на работу с ними.
Чисто user mode еще можно пытаться отлаживать в студии, я первые месяцы так делал. Через год мне на примерах объяснили, что нужно bite the bullet и изучать джедайские тулы.
а SoftIce совсем не Ice?
когда ещё не было интернета (в моей деревне) и кейгенов достать было не всегда возможно, софтайсом мы взламывали защиту программ, обычно это был серийник. помню, что не осилили только WinRAR
Ну я не вижу приемуществ, честно. Основное, какое было у SoftIce, как я понимаю, возможность делать kernel debug на той же машине (в kd нужно коннектиться с другой через COM-port или FireWire). Но в MS уже как-то давно сложилась культура разработки, в которой тебе и так нужна тест-машина (накатывать свежие билды OS) и дев-машина (на которой ты собственно живешь и код пишешь), так что на одной отлаживаться не надо.
И я подозреваю по мощности инструментов отладки kd куда мощнее. Там вселенная внутре, натурально.
«Необразованность» это достаточно спорный пункт на который бы я, на вашем месте, не стал напирать. Невоспитанность — странно это слышать. Неужели говорить о том, что автор не может внятно выразить свои мысли, стали частью поведения попадающего под эти рамки? Заметьте, я ни сколько не пытаюсь унизить автора или заикнуться хотя бы словом о его профессионализме, я лишь говорю о том, что мне, человеку приземленному, было достаточно сложно читать этот текст. Учитывая то, что я обладаю неким опытом в АйТи среде, можно подумать, что не мне одному сложно читать материал поданный таким образом.
Не тактично с вашей стороны с вашей стороны бросаться такими словами, Доброзёл.
Эта статья ориентированна на то, что человек имеет опыт работы программирования низкого уровня. То есть, чтобы понять эту статью, нужно иметь представление об отладке и ассемблере.
Ммм, то есть он ориентирован на анализ асма, когда нет исходного кода и символов?
Я в такие игры сразу не играю, у нас, слава богу, есть и то, и другое.
Если он не поддерживает kernel debug и remote, то вобщем-то и разговаривать не о чем.
К тому же, обычно интересное начинается в момент, когда дебаггер перестает видеть переменные, и там визуальное представление кода уже не поможет…
Согласен, жаль. У меня за последние, наверное, 10 попыток его поставить на виртуалках все были безуспешны, увы :-( Думаю, поддерживали бы они его — все было бы не так печально.
Поможет визуальное представление кода.
Гораздо лучше видеть, что в EAX — удвоенный результат вызова функции strlen, который затем сравнивают с нулем, чем видеть одинокое JE 0x401345 :-)
Это все может иметь смысл, когда нет сорсов и символов к ним, и ты смотришь на голый асм-код.
У нас, повторюсь, слава богу не так. Ты и так видишь в коде, к чему присваивается результат strlen.
Т. е. если дебаггер в состоянии увидеть, в каком регистре какая переменная — то проще смотреть на переменные, а если не в состоянии — то уж придется самому.
Слава господу, я не только отладкой занимаюсь, нужно и фичи писать, и над дизайном хоть немного думать. То есть, я в общем-то обычный девелопер, нисколько не ориентированный на отладку.
При всем при этом, все равно основное время сидишь в дебаггере, когда не в раздумьях. На концентрированную отладку сразу закладывается больше половины времени разработки, народ понимает, что он пишет.
Пользуясь случаем можно поинтересуюсь, как работает политика конфиденциальности в таких мегакорпорациях как Microsoft.
Что мешает ее сотрудникам выложить анонимно кусок какого-то кода в сеть?
Или там системники заклеены, или работаете через терминалы, или просто на совесть? :)
Ничего такого нет. Но если найдут — моментально уволят, будут очень стараться искать.
Народ больше боится не за код, а за совсем важную информацию — security issues, сроки выхода, новые фичи и т. д.
За такое уже и судиться будут.
У лида шпаргалка с разблюдовкой стек-фрейма? Потрясающе… Подобное, еще 8 лет назад, рядовые программисты просто вынимали из подсознания. Равно как хексовую арифметику и старшинство байт в дампе.
Да ну. Можно полагаться на дебаггер и debug build, я так жил 6 лет жизни в геймдеве. В debug build дебаггер справляется с раскруткой стек-фрейма практически всегда, потому что его смущают только оптимизации передачи параметров по регистрам, и можно про все это тупо не знать.
Все это начинает быть действительно необходимым, если нельзя себе позволить загрузить debug-версию и повторить баг.
Соратники! Ведь, если вы знаете, что такое стек-фрейм, то вы однозначно они. Можно полагаться на что угодно. Даже на «житие святого Билла». Но про ESP-N супротив EBP+N, уважающий себя team-leader должен помнить даже в постели чужой жены без соответствующей шпаргалки.
Мне так казалось до сих пор, по крайней мере. Готов рассмотреть аргументированные поправки к устоявшемуся мировоззрению.
Ну, здесь нужно, не аргументы, здесь нужно статистику.
Я вот честно признаюсь, писал игрушки на C++ 5 лет не зная про детали ESP и EBP (впрочем, только из университета был).
Надо устраивать опрос чтоли, с градациями «что дебаггер показывает, то и смотрю», «примерно понимаю, из каких регистров дебаггер берет то, что показывает», «могу это сделать и без дебаггера» и «могу сделать то, что дебаггер не может».
У меня сдержанные сомнения, что все девелоперы на С, условно, с пятилетним опытом выберут последний пункт.
А теперь вопросы на несколько сотен долларов (которые с меня снял Майкрософт за Висту).
1) Почему ж Виндовсы так херово работают-то и так глючат? Vista с SP1 — качество, как в бета-версии до сих пор.
2) За каким х*** убрали поддержку в VPN MSCHAPv1, если тысячи контор имеют железо (тот же PIX), которое только с ним и работает. Например, в моей конторе Висту никто не покупает именно из-за этого. И таких много.
Я ни разу не готов говорить за Висту вообще, ее разрабатывают две с чем-то тысячи человек.
Могу разговаривать конкретно за графику, да и та куда сильно больше одного человека. В остальное ввязываться — упаси господь.
Если рассуждать абстрактно — на примере графических драйверов можно сказать, что допиливать драйверы до серьезного уровня может занимать натурально годы. Спустя год мне Виста нравится куда больше, чем в момент релиза.
Но, повторюсь, предметно за что-либо вне графики я не готов говорить.
Консоль в отладчиках, конечно, рулит… Но я уж лучше с обычными бряками без украшательств, но с возможностью видеть код и нормальной навигацией по нему, чем с кучей фич, но с необходимостью после каждого шага обновлять окно кода :-)
Основная фича Windbg (по сравнению с cdb) именно в этом — что он может в отдельном окошке показывать код, где в нем сейчас исполнение, где стоят брекпойнты и т. д., не теряя при этом консоль.
Я еще не дошел до того, чтобы чисто консольным отладчиком пользоваться, дзена не хватает.
Windbg, например, из забавного, умеет автоматически вынимать файл с кодом из source control по номеру билда, это очень круто. Подконнектился куда угодно, и тебе показывают ту версию файла, которая на той машине.
Насколько я понимаю, прецедент есть — advancedwindowsdebugging.com/
Мужик черти сколько концетрированно занимался отладкой Windows и написал об этом книжку.
Прочитал с удовольствием. Статья очень даже познавательная. Однако технической информации маловато. Сам пишу системные программы и драйвера под Windows, однако опыт у меня не большой. Предложение к автору, может как-нибудь напишешь небольшую (а лучше большую) серию статей на темы:
1. Организация работы программистов в Microsoft. Особенности, отличия…
2. Отладка с использованием windbg, cdb, kd.
С удовольствием прочитал бы.
А Вы не подскажете, Дальнобойщики 3 умерли или все-таки еще можно ждать релиза? :)
За статью отдельное спасибо, хоть я и веб-девелопер, но было очень интересно почитать!
Здорово, вспомнил как сам не так давно дебагал модуль один в нашем проекте. Мы часто наращивали функционал и тестеры пропускали некоторые баги, ну понятное дело, человеческий фактор, нехватка времени и тп. Тогда мы сделали запуск этой софтины из-под cdb и оно нам посмертную корку кидало куда надо со всеми регистрами и списком процессов и пр.
Потом по стеку вычисляли примерно ответственного за каждый конкретный крэш и он брал в руки windbg и грузил кору для изучения проблемы. Был у нас один парень который очень глубоко в это уходил — дизассемблил даже какие-то системные вещи. Сервер символьной информации у нас тоже был…
Эх, вот романтика была!
Для меня путеводителем в мир Windows была книга Марка Руссиновича и Дэвида Соломона «Внутренне устройство Microsfot Windows». А дорога, которой ведут авторы и был windbg (точнее — livekd). Это 900 страниц открытий, крышу сносящих. :)
Саймон, а можете рассказать про сам процесс тестирования? Как выполняется автоматическое тестирование? Как присылаются инвайты на ремоут дебаггинг :)? Как выбираются счастливые обладатели инвайтов? Вы, девелоперы, только код девелопите, или и тесты пописываете? Тестирование проходит на виртуальных машинах?
Ох, это надо рассказывать много и долго. Поди придется еще один пост писать :)
Давай попробую вкратце совсем. Повторюсь, это про часть Windows где я. Hardware acceleration нельзя тестировать на виртуальных машинах, поэтому стоит лаб с сотней машин разных конфигураций.
Практически все тестирование — автоматическое, все тестеры пишут автоматические тесты и называются Software Engineer in Test. Требования при их наборе немногим уступают требованиям на девелоперов (некоторые патриоты теста считают, что и превосходят).
Когда пофиксал баг — даешь на тестирование тестеру из той области, он гоняет всяческие тесты, если падает — присылает тебе remote.
Есть наборы тестов, которые гоняются каждый день на билде, которые гоняются при интеграции изменений из другого бранча, есть полные наборы тестов, которые гоняются перед milestone. Есть люди, которые ими заведуют, если падает — присылают примерно команде. Если ошибутся, нестрашно — просто мэйл форвардится пока не найдется владелец проблемы.
Девелоперы пишут unit tests, которые сами гоняют перед чекином. Простенькие такие, по сравнению с монстрами, которых пишет тест.
Статья интересная, спасибо. Правда, очень техническая. Теперь, для баланса бы, услышать художественное повествование о том, как вы попали в Microsoft (если это — не слишком личная история)… ;)
Я не думаю, что лично моя история сильно заинтересует хабратусовку :)
Разве что как интервью проходило можно написать…
Художественная часть очень короткая. Вот такая: sim0nsays.livejournal.com/12749.html
Я все понял, но вы не достучались до моего сердца.
Я думаю, что проще и лучше не создавать проблем, чем с честью, трудностями и героизмом их преодолевать.
Вау, я захвачен вашими статьями, спасибо :) Идея пост-отладки засела мне в мозг, я хочу это делать :) Я вот только, не могу понять, с чего же начать. Может Вы дадите вектор движения.
Поясню, сейчас я пишу на C++ из под NetBeans (ох, это ужасно, в плане дебага). Когда мне сообщают о какой-либо ошибке, я просто прикидываю где бы это могло быть, и расставляю брейкпоинты запускаю приложение из под IDE ну и так далее…
Вот и вопрос созрел: что мне нужно сделать с моим приложением (т.е. как мне его модифицировать), что бы в случае если приложение у пользователя упало, то я бы мог восстановить у себя на компьютере как бы сессию дебага (не знаю как выразиться), т.е. мне нужно сделать полный дамп памяти, как то восстановить потом, либо что-то еще, где бы мудрости набраться?
www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx
Выглядит неплохом руководством. Вкратце, надо добавить код, который по unhandled exception создает файл с минидампом. Этот дамп потом можно открыть на другой машине и посмотреть на состояние регистров и памяти в момент падения. В коде, который создает Minidump можно подкрутить опции, чтобы он делал полный дамп памяти процесса. Понятное дело, нужны символы того билда, в котором упало.
В Advanced Windows Debugging (http://advancedwindowsdebugging.com/) есть целая глава про postmortem debugging, это довольно полное описание всех возможностей. Ее довольно тяжело читать, но оно того стоит.
Как отлаживают графику Windows в Microsoft