Здравствуйте, warren41, Вы писали:

W>В смысле, какие драйвера написать в домашних условиях, чтобы можно было опыта и знаний набраться и чтобы было, что предъявить потенциальному работодателю?
во-первых работодателю нужно предъявлять то, что он от Вас желает получить.

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


А знания можно получить гораздо быстрее и объемнее (на старте) без написания чего-то своего этакого. И мучительной отладки своего этакого, отнимающей дни и ночи напролет, без гарантий приемлемого в т.ч. потенциальными работодателями результата. При этом, очевидно, время тратится менее эффективно — проще прочитать\понять как надо и почему, чем доходить до этого понимания на своих шишках, часто пользуясь неверными посылками и опираясь на свои непроверенные догадки — так можно никогда не дойти. Кстати, руткиты я бы не стал рекомендовать трогать, зная качество исходников в открытом доступе (в основной массе) — большие шансы что это будет провокация начать неправильно мыслить, что впоследствии будет вызывать в лучшем случае непроизвольную тягу к обходу правильных но иногда тяжеловесных инженерных решений с помощью легких и не очень хаков + позднее понимание (на своих ошибках) почему это все не есть хорошо. Хотя конечно руткиты разные бывают.

Короче, я бы порекомендовал сначала не писать, а читать.

Читать доки и примеры из DDK\src, разделы по убыванию general, input, kernel/ser*, storage, filesys и факультативно что там покажется интересно еще — но для старта хватит на долго уже перечисленного выше. Говоря читать, не имею ввиду пассивное чтение в FAR или студии. Будет гораздо полезнее собрать, проставить, подкцепить отладчик и уже потом читать активно, проверяя поведение в динамике и отлаживая непонятные места для разрешения вопросов, которые появляются в процессе чтения опять же. Соотв. я бы порекомендовал сосредоточиться на формулировании вопросов — ибо правильно поставленный вопрос часто на половину содержит в себе ответ.

Алгоритм мог бы быть примерно такой:

— DDK help: выбираем тему типа архитектура WDM, смотрим картинки, читаем (можно подключить Walter Oney в параллель, если речь о WDM. Важно пользоваться правильными и по возможности оригинальными источниками и не тратить время на неавторитетные вроде книг на русском, разве что Руссинович годится). Заодно прививаем правильные привычки.

— определяем какой раздел в DDK\src содержит примеры по теме, напрямую рекомендуемые (это есть в DDK или описаниях к самим примерам — там пишут "кто они, что они"). К примеру, берем "пример на все времена" toaster и начинаем его собирать\ставить и затем активно читать.

— появился вопрос? сразу не бежим на форум или в гугль, думаем. А именно придумываем конкретные вопросы, которые бы помогли однозначно ответить на первый. Стараемся придумывать\ставить их такими, чтобы можно было тут же проверить. Например в отладчике или каком известном инструменте системного разработчика, которые также должны быть всегда под рукой — из раздела downloads на sysinternals да OSR, бинари к книгам Рихтера Брауна Они и т.п. Практика показывает, что бОльшая часть вопросов таким образом может быть снята самостоятельно (сколько ответов в форумах состоящих из ссылок на форум? просто авторы даже не искали ответов, а летели на форум) — кроме того это несет и реальный эффект, набор самого что ни на есть реального опыта ибо "в бою" ситуация мало чем отличается — часто спросить не у кого (возможно какие-то вещи вообще никто не делал или делал но тщательно скрывает сей факт) и полагаться остается на себя, да на отладчик. Так что привыкаем.

— что делать если все равно остались\появились новые неразрешенные старым добрым методом "разделяй и влавствуй" подвопросы? А нужно стараться "разделять", то бишь учиться выделять ключевые слова и формулировать вспомогательные вопросы так, чтобы можно было потом прогуглить. Это заодно и критерий — если ты сам не можешь внятно и кратко сформулировать, выделить ключевые моменты — что-то не так, нужно еще подумать\почитать. Итак, не получилось как предложено выше — гуглим. Найдя ответ, проверяем в отладчике\текстах\доках так ли это! ибо мало ли кто что сказал. Это важно и это выработка еще одной хорошей привычки в наш век гугления в непроверенных источниках, поможет не только в ядре. Далее пытаемся ответить на оригинальный вопрос с учетом нового полученного знания. Возможно имеет смысл перечитать какие-то места в книгах\доках\исходниках.

— все равно не прет? вот теперь идем на форум и выкладываем уже продуманные и понятно (хотя бы себе) сформулированные (под)вопросы, на которые не удалось ничего нагуглить (имется ввиду поиск не только в гугле но и по этому форуму ). При этом стоит, задавая вопрос, не писать своих предполагаемых ответов\домыслов, а лучше писать что именно, где и как уже смотрели\искали. Впрочем это уже описано в бессмертном тексте "Как правильно задавать вопросы".

— получаем ответ и едем дальше, читаем следующий раздел в DDK help, смотрим след sample и т.д.

Да, процесс итеративный (как и все у нас в софтостроении) и долгий, однако зарыться со своими поделухами можно не в пример дольше + остаться с пробелами "в образовании" по описанным выше причинам. Где-то так.

PS Поиском по форуму можно найти и другие посты по теме "с чего лучше начать" — с конкретными ссылками, поэтому это сообщение оставлю от них свободным.