MSS>>Если "интересненькое" сделано под винды, не в конкуренцию одному из продуктов Microsoft, и, таким образом, ворованный код использовался только для того, чтобы лучше понимать, как работает платформа у тебя под ногами — то расслабьтесь. Никто на вас в суд подавать не будет, как не подают в суд на тех, кто сделал reverse engineering каких-то кусков ядра виндов и опубликовал результаты.
Pzz>Вы собираетесь всю жизнь писать драйвера для виндов?
Личная жизнь человека и жизнь компании — вещи разные. Я вполне допускаю, что моему работодателю _никогда_ не будет интересно программирование не под винды. Как и многим другим работодателям.
В судебную разборку в данном случае влипнет именно компания.
"Maxim S. Shatskih" <29705@users.rsdn.ru> writes:
>> более сложные чем a+b. А через doxygen с LaTeX формулы и оформлять >> более-менее удобно можно, и читать это нормально после обработки.
> И что — кому-то не лень пропускать код через 2 лишних тула, после чего > его якобы читать удобнее?
Через одну, doxygen всё сам сделает. Просто читать таким образом сложные
формулы не "якобы", а действительно удобнее.
MSS>P.S. В список подсистем не вошел TCP/IP, и к тому есть причины. Его перетащили за уши из OS/2 LAN Manager 1.x, он даже в другом стиле кодирования написан, чем все остальное ядро, и не переделывался аж до Висты (в Висте как минимум поменяли интерфейсы верхнего края — был TDI transport, стал WSK provider).
Ух ты. А ведь Microsoft утверждает, что OS/2 там вовсе не при чем. Утверждает официально в лице Рихтера в его знаменитой зелёной книжке про внутренности Виндов.
Стек TCP/IP, однако, там из FreeBSD. Был. До висты...
Здравствуйте, Maxim S. Shatskih, Вы писали:
Pzz>>Мой point заключается в том, что писание документации — это такая же вдумчивая работа, как писание кода.
MSS>На деле она нужна практически только при раздаче кода _без исходников_, бинарями, внешним людям. Т.е. она нужна только авторам фреймворков, тулкитов и платформ. Причем фреймворков и тулкитов, раздаваемых наружу без исходников.
Нет, еще при вводе в команду новых людей. Да и самим авторам иногда проще в документацию заглянуть, чем по сорсам копаться.
Но Вы правы в том, что при написании документации надо учитывать, для какой аудитории она предназначена.
MSS>Второе, зачем нужна документация — краткое описание общей архитектуры продукта, базовых принципов, обязательных к соблюдению (скажем, инвариантов базового класса, которые обязаны остаться инвариантами в потомках), и так далее.
И много чего другого. Скажем, если в Вашей программе есть сетевой протокол, он должен быть где-то описан. Если программа взаимодействует с базой данных, где-то должен быть описан формат таблиц и правила игры с ними. Если программа потребляет или производит данные в нетривиальном формате, должен быть документирован формат. И т.д., и т.п.
Все это не выводится из исходников, и не раскладывается на описания функций и методов. И это гораздо более насущная документация, чем референс по функциям.
Здравствуйте, Maxim S. Shatskih, Вы писали:
Pzz>>Если параметров просто много, значит функция просто продумана плохо.
MSS>Придумайте CreateFile с меньшим числом параметров, учитывая весьма развитый функционал этой функции, намного богаче, чем в юниксных аналогах.
Что такого содержательного делает эта функция, что не делает ее посиксный аналог?
Pzz>>Примерчики из DDK просто ужасны. Не в смысле стиля расставления скобочек, а в смысле архитектуры программы. В них любое действие, которое логически состоит из нескольких последовательных шагов, размазано тонким слоем по всему примерчику.
MSS>Конкретику можно? какое именно действие, какие шаги, как размазано.
Да можно и конкретику.
Ну вот, например, bus driver от тостера. Он работает с 2-мя видами девайсов, PDO и FDO, и у каждого своя логика обработки запросов. Нормальный человек записал бы в Device Extensions табличку указателей на обработчики, а в MajorFunction[] засунул бы указатели на функции, которые достают указатель на нужный обработчит из Device Extensions конкретного DEVICE_OBJECT, и передают туда управление. Раз уж в венде таблица обработчиков одна на драйвер, а не на каждый девайс, порожденный этим драйвером.
Нет, в сампле каждый обработчик по-отдельности разбирается с тем, PDO или FDO ему дали, и по-разному с ними работает.
Я понимаю, что там 3 обработчика и 2 типа девайсов, кода мало, и поэтому неправильность такого подхода не очень видна. А представляете, если бы там было 15 обработчиков и 5 типов устройств, и Вам надо добавить 6-й? Это же весь драйвер перелопатить только чтобы воткнуться.
И так там все. Я привел первое, что вспомнил.
MSS>Есть такое подозрение, что после приведения вами примеров станет ясно, что причина этого не в стиле кодирования DDK, а в архитектуре ядра NT.
Плохому кодеру, как известно, и ядра мешают
Pzz>>Тех, кто учился программировать по DDK, надо долго и мучительно переучивать.
MSS>Смотря что разработчикам предстоит разрабатывать. Если что угодно в ядре виндов — то не нужно переучивать, DDK есть истина в последней инстанции.
Да ну, перестаньте. Я в DDKных самплах и настоящие ошибки находил, которые могут систему порушить, если не повезет. Лень просто сейчас вспоминать, где это было, но в каком-то из простых примеров — синхронизация вокруг IRP cancellation была с ошибкой. Пример этот я, кстати, читал именно что бы разобраться в этом самом cancellation'е
И эти ошибки, они потом переползают в реальные драйвера, т.к. народ просто выдергивает код из DDK, особо не вчитываясь.
MSS>Причина делать такое утверждение очень проста: программируют, в частности, под платформу. Я понимаю, что программируют еще и под требования, и под соображения о красоте программирования — но если платформа достаточно сложна, то соображения "правильно воткнуться в платформу" уж точно перевешивают ЛЮБЫЕ (еще раз all caps — ЛЮБЫЕ) соображения красоты кода из любой литературы.
Вы лукавите. На самом деле, Вы ставите задачу не "правильно воткнутся в платформу", а "правильно воткнуться в платформу, не понимая, что Вы делаете". Только этим непониманием может объясняться столь священно-трепетное отношение к DDK.
MSS>Ядро НТ — достаточно сложная платформа с кучей тонких нюансов, которые могут породить кучу неприятных сложных в поиске багов именно в месте стыка "ваш код-платформа". Потому именно это место стыка начинает становиться _главным_ в вашем коде, а вовсе не его внутренняя красота.
Памилте. В одном из моих драйверов было 60 тышш строк кода, и работал он кроме венды еще на 2-х платформах. Вы правда думаете, что стык с платформой был главным в этом коде? На самом деле, все платформенное было аккуратно загнано в специально отведенное для него место, а большая часть кода знать не знала, на какой платформе она крутится.
Просто Вы сложных драйверов не писали. В простых драйверах, конечно, почти весь драйвер и есть стык железа с платформой.
Здравствуйте, Maxim S. Shatskih, Вы писали:
Pzz>>Вы собираетесь всю жизнь писать драйвера для виндов?
MSS>Личная жизнь человека и жизнь компании — вещи разные. Я вполне допускаю, что моему работодателю _никогда_ не будет интересно программирование не под винды. Как и многим другим работодателям.
MSS>В судебную разборку в данном случае влипнет именно компания.
Для компании, интересы которой пересекаются с мелкософтом, держать в штате человека, который копался в исходниках ядра, может быть опасно. Одно дело, если человек про это молчит, компания не обязана его допрашивать с пристрастием при приеме на работу (расписочку, впрочем, могут и попросить). Совсем другое дело, если человек хвастается этим на каждом углу.
Здравствуйте, SkyDance, Вы писали:
SD>Ух ты. А ведь Microsoft утверждает, что OS/2 там вовсе не при чем. Утверждает официально в лице Рихтера в его знаменитой зелёной книжке про внутренности Виндов. SD>Стек TCP/IP, однако, там из FreeBSD. Был. До висты...
Не очень он похож на стек из BSD. Ни по поведению, не по видимым простому человеку интерфейсам (например, управление буферами в NDIS'е совсем не похоже на BSD'ное).
Здравствуйте, Pzz, Вы писали:
Pzz>Единственное оправдание держать документацию в исходниках, это пресловутая возможность пройтись по ним доксигеном. Потому что вообще-то в исходниках развесистые комментарии только мешают, затеняя логику самого кода. А так как от доксигеновской документации все равно, см. выше, проку мало, то и незачем ради нее исходники марать.
Почему же — лично я люблю (ну хорошо: подсмотрел в одной из комманд в которой когда-то работал) писать по исходникам замечания и ссылки на номера багов в системе учета оных — по крайней мере на этапе доводки текущего релиза это как минимум не вредно — а потом, после выпуска релиза, можно эти замечания и удалить все сразу автоматом. А то как еще сказать "бак такой-то был исправлен в таком-то месте"?
Pzz>Назначение комментариев в исходниках — быть именно пояснением к исходникам, а не заменой документации. Именно из этого и следует исходить, выбирая стиль, в котором пишутся комментарии.
Ну, примерно это оно и есть.
Pzz>Ковырянием же доксигена можно, наверное, повлиять на стиль, в котором он форматирует свой output. Но я говорю совсем не об этом.
Лично я доксиген не прочувствовал: там в исходниках такие развесистые комментарии писать (а може я его не понял?) что имхо проще самому документацию вести и поддерживать в актуальном состоянии — благо "буквы писать" можно и отдельного специального человечка без глубокий знаний программирования посадить.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Исторически ядро было написано группой единомышленников человек в 30-40 (это если считать авторов драйверов под главнейшее железо и авторов основных кернел-модулей типа NTFS, NDIS, SMB клиента и сервера и тому подобного).
MSS>Люди давно работали вместе еще в Digital, хорошо сработаны, и при возникновении тех или иных вопросов просто спрашивали друг друга лично.
История известная — и было это ядро NT чтобы не соврать 3.5 (специально смотреть NT 3.x не полез, а "наизусть" вроде как 3.5 было...) — и когда это было? И осталось ли что-нибудь из того ядра в современном хотя бы XP (нет, я не говорю что мол не осталось ничего — привда интересно осталось ли и что именно) и остались ли кто-нибудь из тех "30-40 единомышленников" до сих пор "кодить ядро"?
Здравствуйте, The Lex, Вы писали:
TL>Почему же — лично я люблю (ну хорошо: подсмотрел в одной из комманд в которой когда-то работал) писать по исходникам замечания и ссылки на номера багов в системе учета оных — по крайней мере на этапе доводки текущего релиза это как минимум не вредно — а потом, после выпуска релиза, можно эти замечания и удалить все сразу автоматом. А то как еще сказать "бак такой-то был исправлен в таком-то месте"?
А зачем это говорить в исходниках? У вас что, нет системы контроля версий? Вот в ее логах и скажите.
Кстати, бывает еще, что система контроля версий интегрирована с багтракером. Т.е., вы закрываете багу и чекините изменения одним движением. Мне, правда, не попадалось удобной реализации, но идея хорошая.
Здравствуйте, Pzz, Вы писали:
Pzz>Все это не выводится из исходников, и не раскладывается на описания функций и методов. И это гораздо более насущная документация, чем референс по функциям.
А вот ее-то по большому печальному и повсеместно распространенному опыту фиг добьешься — зато непреходяща масса менеджеров всех уровней, "вдруг открывших для себя доксиген и решивших что это хорошо" (к) — мол "теперь у нас будет документация по проекту! всем срочно писать в коде комменты для доксигена!" (к) — повбывав бы!
Здравствуйте, Pzz, Вы писали:
Pzz>Все это не выводится из исходников, и не раскладывается на описания функций и методов. И это гораздо более насущная документация, чем референс по функциям.
Тут как раз вспомнилась классика: "угадал все буквы, но не смог назвать слово." (к)
Здравствуйте, SP_, Вы писали:
SP_>Здравствуйте, Unmanaged, Вы писали:
U>>Разжёвывать мне сейчас лень, кому надо — правильно поймут, что я имел в виду.
SP_>Батенька, складывается впечатление, что круче вашей фирмы только яйца. Озвучте пожалуйста название вашей конторы.
+1
Здравствуйте, Pzz, Вы писали:
TL>>... А то как еще сказать "бак такой-то был исправлен в таком-то месте"?
Pzz>А зачем это говорить в исходниках? У вас что, нет системы контроля версий? Вот в ее логах и скажите.
Мысль! Т.е. я-то так и делаю — почему-то не подумал сопоставить... Хех! Надо теперь защищать "коментарии в исходниках"...
Pzz>Кстати, бывает еще, что система контроля версий интегрирована с багтракером. Т.е., вы закрываете багу и чекините изменения одним движением. Мне, правда, не попадалось удобной реализации, но идея хорошая.
Да не очень, имхо. Во-первых, функции сильно разные. Ну, и этого достаточно — остальное уже следствия первого.
Здравствуйте, Maxim S. Shatskih, Вы писали:
Pzz>>Если нет, то что за радость от того, что они механически чекинятся одновременно с функцией? MSS>Не запускать отдельные тулы для чтения документации. Это раз. Документация обязательно видна и мозолит глаза при работе с кодом, это два.
А зачем ей именно мозолить глаза?
В целом я, конечно, согласен, что документация желательно должна быть тут же в коде.
Но надо и делать так, чтобы она не мешала читать.
MSS>А что за радость в отдельной документации вне комментов?
MSS>>>Если параметров просто много — то есть смысл, чтобы четче понимать, где какой параметр. Pzz>>Если параметров просто много, значит функция просто продумана плохо. MSS>Придумайте CreateFile с меньшим числом параметров, учитывая весьма развитый функционал этой функции, намного богаче, чем в юниксных аналогах.
Ну если говорить именно об этом примере, то как минимум 4 параметра (dwDesiredAccess, dwShareMode, dwCreationDisposition, dwFlagsAndAttributes) частично или полностью входят во второй параметр open(), и проблем я от этого ни разу не видел. То есть вместо 7 параметров можно было бы спокойно сделать 4-5. А это уже значительно ближе к возможности легко помнить их состав, порядок и назначение (особенно если lpSecurityAttributes унести в конец, и расширить её тем, что относится к security, но напихано в dwFlagsAndAttributes).
Итого, пример я считаю достаточно неудачным.;)
И непонятно, какой смысл в сравнении именно с юниксом (у Вас, кажется, это слегка больное место). Есть специфические библиотеки (например, GTK) где бывает и 15 параметров в функции.:)
MSS>Ядро НТ — достаточно сложная платформа с кучей тонких нюансов, которые могут породить кучу неприятных сложных в поиске багов именно в месте стыка "ваш код-платформа". Потому именно это место стыка начинает становиться _главным_ в вашем коде, а вовсе не его внутренняя красота.
Угу — для очень большого количества применений можно было бы обойтись значительно более простым построением.
Здравствуйте, The Lex, Вы писали:
TL>Здравствуйте, Pzz, Вы писали:
Pzz>>Все это не выводится из исходников, и не раскладывается на описания функций и методов. И это гораздо более насущная документация, чем референс по функциям.
TL>А вот ее-то по большому печальному и повсеместно распространенному опыту фиг добьешься — зато непреходяща масса менеджеров всех уровней, "вдруг открывших для себя доксиген и решивших что это хорошо" (к) — мол "теперь у нас будет документация по проекту! всем срочно писать в коде комменты для доксигена!" (к) — повбывав бы! :maniac:
А ты с другой стороны посмотри.:) Хорошо, когда работает слаженная команда, годами обрабатывающая один код и знающая его наизусть. А теперь представь себе, что надо ускорить работу (в меру, конечно) и добавить людей на мелкие задачи. И вот одному из них задача — переделать десяток функций под новые условия. Времени мало. Сколько времени он затратит на поиск того, что надо переделывать, и поймёт, как переделывать, без документации по каждой функции и по каждому файлу и с такой документацией?
А ведь менеджеру в том числе нужно чтобы, если ты не дай бог попал под трамвай, или бросил всё и уехал в Шамбалу искать смысл жизни — чтобы заменить тебя было реально решаемой проблемой в течение максимум недель...
Здравствуйте, netch80, Вы писали:
N>А ведь менеджеру в том числе нужно чтобы, если ты не дай бог попал под трамвай, или бросил всё и уехал в Шамбалу искать смысл жизни — чтобы заменить тебя было реально решаемой проблемой в течение максимум недель...
А теперь представь себе что все, кто начинал и продолжал писать эту программу, попали под трамвай и уехали в Шамбалу — и остался ты с программой один на один и есть у тебя описания всех функций и классов и даже названия у них очень даже "говорящие" и каждый отдельный алгоритм вполне понятен, но вот нет никаких данных а) что система делает вообще; б) что она должна делать в принципе. А проблемой замены "попавших под трамвай" в течение недели (после взятия на работу, да: поиск и найм — отдельный вопрос) я давно "озабочен" и определенные наработки имеются — в том числе, например, по динамическому переключенению имеющихся ресурсов на "горящие" участки. Так вот: доксиген там не только не помогает, а очень даже наоборот. А почему? А потому что писать много, а смысла — мало. Описывать хороший код по параметрам функций — смысла нет — описывать надо конкретные цели, которых добивались, конкретные решения, которые правили, и конкретные результаты, которых достигли. А для описания технической сути решения часто не только достаточно 2-3-х диаграмм — часто как эти 2-3 диаграммы дают гораздо более полное и полезное описание системы, модуля, etc., чем целый вагон доксигена. Знаем — плавали.
Что говорил Рихтер, и какие байки ходят вокруг среди ненавистников Микрософта — мне не интересно, говорю то, что на самом деле:
— TCP/IP от NT3.5 и до Висты — из OS/2 LAN Manager 1.x
— в Win9x/Me он строился с тех же исходников с помощью макросов. Кое какие-то вещи обернуты в portability обертки — скажем, CTESignal у нас KeSetEvent на NT и какой-то VMMный вызов на Win9x/Me.
— что в Висте — не знаю.
— что было в NT 3.1. Был совсем другой TCP/IP, основанный на STREAMS, возможно, срисованный с Lachman TCP source из System V или чего-то вроде (нет, никоим образом не из FreeBSD). Выкинули на помойку в NT 3.5 из-за низкой производительности, да еще и весь STREAMS задепрекатили.
— утилиты типа PING и FTP — вот они действительно из BSD.
TL>История известная — и было это ядро NT чтобы не соврать 3.5 (специально смотреть NT 3.x не полез, а "наизусть" вроде как 3.5 было...) — и когда это было? И осталось ли что-нибудь из того ядра в современном хотя бы XP (нет, я не говорю что мол не осталось ничего — привда интересно осталось ли и что именно)
Процентов 80 осталось. А именно — все основные функции и структуры данных остались. Главное изменение ядра было между NT4 и w2k — появление PnP & Power.
Кое-какие внутренние кишки переписали поумнее, например, реестр между w2k и XP (он теперь на memory mapped файлах стал).
TL>и остались ли кто-нибудь из тех "30-40 единомышленников" до сих пор "кодить ядро"?
И осталось ли что-нибудь из того ядра в современном хотя бы XP (нет, я не говорю что мол не осталось ничего — привда интересно осталось ли и что именно) и остались ли кто-нибудь из тех "30-40 единомышленников" до сих пор "кодить ядро"? 
