Здравствуйте, ononim, Вы писали:
O>Я и имел ввиду соотношение количество багов/количество кода. Насчет затраченного времени — имхо вот здесь как раз не стоит экономить — потом выйдет гораздо больше времени на исправление проблем.
Так чего ж экономим, а не тратим его в таких количествах как NASA, заказчик виноват?
O>И по этой же причине в ядре не надо ниче делать кроме того что там приходится делать. А если чтото можно сделать в юзермоде — там это и надо делать, для того юзермод и был вобщемто придуман. Потому меня очень напрягают вопросы в стиле а как мне показать messagebox из кернелмода, у меня единственный вопрос возникает — а какие есть технические причины этому кроме того что "вот хочется чтоб из кернелмода".
Всё это интересно, микроядра, грамотные архитектуры, но к С++ отношения не имеет.
O>Вобщем я считаю так, что если уж человек полез в ядро, то он должен досконально знать куда лезет.
И это не имеет, хоть и верно.
O>Так что если вдруг вылетит бсод при доступе к Paged памяти из под высокого IRQL или вдруг окажется что человек забыл задереференсить какой то объект получиутечку, чтобы потом первая мысль в голове глядя на дамп от юзера в течении первой минуты была не "какого хрена???" а "а ну я лопух ступил".
А вот это имеет самое непосредственное отношение к С++.
Про дерефенренс — какие преимущества имеет С по сравнению с С++ и RAII где ресурсы освобождаются автоматически?
O>Снижение порога слоэности входа в кернелмод привлечет еще орду нубов и в результате наступит полный бардак
Окей, притянем к С++ этот оффтоп — порог вхождения в сам язык на порядок выше, чем в С, какие можно сделать выводы?
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
кгхм, извините, что вмешиваюсь в по-настоящему интересную дискуссию. Редкие забеги в янус не оставляют шансов полноценно тут поучаствовать.
Однако, ознакомившись с топиком и тут же, буквально следом за O>Кстати учитывая количество вопросов в этом топике в стиле а как мне выделить полгига nonpaged памяти — такого народу "не в теме" очень много и становится больше и больше. Снижение порога слоэности входа в кернелмод привлечет еще орду нубов и в результате наступит полный бардак, который давно царит в юзермоде. Я конечно против DRM, но введение обязательной подписи для х64 в этом плане хоть както сдерживает ситуацию.
встретив вот этот вопрос
пожалуй, главной для меня является тут следующая мысль: любые дополнительные вспомогательные инструменты, будь то verifier, SDV, prefast или DTM или вот язык С++ (вполне себе рабочий инструмент), позволяющие при правильном обращении повысить качество кода — это хорошо. Если обращение неправильно — априори вопроса ИМХО просто нет: ну прицелился хорошенько да пальнул человек себе в ногу из двустволки — кто ж виноват что не обучился использовать оружие? Таких деятелей жизнь быстро научит.
, действительно, в определенный момент могут не только заставить улыбнуться, а еще и настроить следом на весьма и весьма радикальный лад.
Поэтому на мой взгляд, истина (или даже точнее — согласие), как это часто бывает, где-то рядом. Если бы ononim чуть мягче использовал кванторы всеобщности и уникальности (собственно, за которые и зацепились коллеги), наверное бы даже подписался под его позицией.
Но все же лично мне пока со столь жесткими заявлениями вида >Вообще в целом подход большого и толстого драйвера ущербен сам по себе. В кернелмоде должно быть только то, что нельзя сделать в юзермоде. А единственное что нельзя сделать в юзермоде — это работать с железом (писать в IO/DMA etc)и модифицировать другой кернелмод код.
сложно согласиться.
Если оставить от цитаты фразу "В кернелмоде должно быть только то, что нельзя сделать в юзермоде", заменить "должно быть" на "следует стараться делать", не усилять условие "большим и толстым" (не хочется даже выяснять что есть большой а что толстый), а также попыткой перечислить в одну строку все то, "что нельзя делать в user mode" — то получилось бы гораздо лучше. Вряд ли кто из коллег возмущался бы потом.
Но думаю что и gear nuke и остальные скорее согласны чем нет — что безотносительно С++ и т.п. идея-то абсолютно верная в основе — "не суйся в воду, не зная броду"! Тем более, что времена когда брод практически невозможно было найти даже при запредельном уровне желания и старания — давно канули в Лету... Сейчас вполне можно не тупить и найти все что нужно для старта (и не только) самостоятельно — вопрос "где взять информацию?!" уже гораздо менее актуален. Главным становится вопрос "какому источнику верить?!"
Может, оно и к лучшему, конечно — но романтики в нашем деле становится меньше, факт.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
.
Основная проблемма использования С++ в кернеле это отсуствия поддержки от Microsoft.А если такой поддержки, нет то менэджмент не будет рисковать пускать энтузиастов С++ на рабочии проэкты.Энтузиасты могут уйти, а найти других энтузиастов бутет очень трудно.В целом найти хорошего разработчика для Windows кернел очень трудно, а энтузиаста С++ практически невозможно.
Я в Штатах давно работаю и только встретил один проэкт где испоьзовалься С++.Лично я вижу одно преимущество С++ в кернел .Это использования *.cpp файлов.Но в моей текущем проэкте мы даже отказались от этого.В проэкте используется код общий не только для Windows, но и для других OS кернел.Windows оказывается более дружественный к использованию С++ компилятора чем Linux и Unix.
Все что я написал относится в кернел.Для приложений я конечно использую С++.
eagersh, спасибо, интересно. понимаю, что если есть успешный опыт и рабочий — от него не отказываются.
VAB>>С++ в ядре при правильном обращении, несомненно, полезен и от того, о чем говорит gear nuke & co
. E>Основная проблемма использования С++ в кернеле это отсуствия поддержки от Microsoft.А если такой поддержки, нет то менэджмент не будет рисковать пускать энтузиастов С++ на рабочии проэкты.Энтузиасты могут уйти, а найти других энтузиастов бутет очень трудно.В целом найти хорошего разработчика для Windows кернел очень трудно, а энтузиаста С++ практически невозможно.
да, ситуация с кадрами очень непростая. с тем, что в работающих десятилетиями проектах у энтузиастов по любому будут чем-либо связаны руки — тоже понимаю и согласен с менеджментом
Молодежь всегда стремится к прогрессу и поэтому рано или поздно, но даже на самые закостеневшие проекты будет оказано влияние.
Конечно, нужно запускать энтузиастов с опытом, чтобы за энтузиазмом стояли знания и профессионализм. По одиночке тут ингридиенты не работают — только вместе.
E>Я в Штатах давно работаю и только встретил один проэкт где испоьзовалься С++.Лично я вижу одно преимущество С++ в кернел .Это использования *.cpp файлов.Но в моей текущем проэкте мы даже отказались от этого.В проэкте используется код общий не только для Windows, но и для других OS кернел.Windows оказывается более дружественный к использованию С++ компилятора чем Linux и Unix.
ну вот видите — плюсы они есть и если их просуммировать собрав обратную связь со всех (уже это в какой-то мере сделала эта и сопутствующие ветки), их окажется не так уж и мало. Вполне себе повод задуматься, на чем начинать новый проект.
E>Все что я написал относится в кернел.Для приложений я конечно использую С++.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, eagersh, Вы писали:
E>Основная проблемма использования С++ в кернеле это отсуствия поддержки от Microsoft.
Microsoft негласно похоронили язык С 10 лет назад. Поддерживается API OS, которое имеет С интерфейс.
Microsoft не поддерживает C++ в полной мере в ядре, поскольку на данный момент не накоплено достаточной базы знаний о возможных проблемах и методах их решений, они не хотят что бы шишки летели в них. Microsoft ждёт созревание рынка и потом "внезапно" окажется там всерьёз и надолго.
E>А если такой поддержки, нет то менэджмент не будет рисковать пускать энтузиастов С++ на рабочии проэкты.Энтузиасты могут уйти, а найти других энтузиастов бутет очень трудно.В целом найти хорошего разработчика для Windows кернел очень трудно, а энтузиаста С++ практически невозможно.
Разработчики на старом диалекте С не то что могут уйти, а когда-нибудь закончатся, можно даже сказать что их давно нет, свободных. В то же время есть сильные С++ разработчики, которых можно было бы научить премудростям кернел разработки, если бы такой переход не воспринимался ими как деградация.
E>Я в Штатах давно работаю и только встретил один проэкт где испоьзовалься С++.
Какой сложности проекты?
Тут стоит вспомнить, что качественный софт — не тот, который "работает" 24*7, а который выполняет работу, решая проблемы клиента. Так вот в Штатах пишут кучу совершенно бесполезных поделок-антивирусов, которые детектят разве что фейковые антималвары, и то через неделю.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
E>>Я в Штатах давно работаю и только встретил один проэкт где испоьзовалься С++.
GN>Какой сложности проекты?
GN>Тут стоит вспомнить, что качественный софт — не тот, который "работает" 24*7, а который выполняет работу, решая проблемы клиента. Так вот в Штатах пишут кучу совершенно бесполезных поделок-антивирусов, которые детектят разве что фейковые антималвары, и то через неделю.
Это был даже не драйвер, а библиотека поддержки.Драйвер — тюнер.Сам драйвер, та часть что работает с железом, была написана на С.Библиотека на С++ делала какую ту обработку сигнала.Детали не знаю.
Меня интервьюровали по знанию С++ на драйвер позицию только один раз.Это было в McAfee.
А похоронили они 10 лет назад С++ ибо сие мерворожденное чудо, которое откачали медики-чудесники. Перспектива вообщем понятная: все что можно (99%) будет на управляемом коде написано, остальное, где уж совсем никак без этого — С напополам с асмом.
Да самый главный лозунг:
Статические верификаторы кода обыгрывают С++ с его "строгой" типизацией. С код, проверенный хорошим верификатором становится надежней плюсового, который верифицировать гораздо сложнее. А раз С код надежней, то какие плюсы остаются у плюсов?
Здравствуйте, TarasCo, Вы писали:
TC>Статические верификаторы кода обыгрывают С++ с его "строгой" типизацией. С код, проверенный хорошим верификатором становится надежней плюсового, который верифицировать гораздо сложнее.
Верификация С кода так же невозможна, как и С++, верификаторы принимают другой язык — аннотированный С
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, TarasCo, Вы писали:
TC>Зачем тогда они новый код пишут на С?
Какой именно? В каждом случае могут быть свои причины.
TC> И занимаются такой херней: http://vcc.codeplex.com/?
Сам же ответил в следующем посте — С++ сложнее верифицировать, нало же с чего то начинать.
TC>А похоронили они 10 лет назад С++ ибо сие мерворожденное чудо, которое откачали медики-чудесники.
MS и в частности Герб Саттер активно развивают язык С++, VC поддерживает C++0x в отличае от C99.
TC> Перспектива вообщем понятная: все что можно (99%) будет на управляемом коде написано, остальное, где уж совсем никак без этого — С напополам с асмом.
Одно не понятно в этой перспективе, когда настанет её время и смерть Windows. Пока что Wintel пережила не один прогноз о своей смерти, Итаник, дотнет в ядре Висты...
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
TC>Да самый главный лозунг: TC>Статические верификаторы кода обыгрывают С++ с его "строгой" типизацией. С код, проверенный хорошим верификатором становится надежней плюсового, который верифицировать гораздо сложнее. А раз С код надежней, то какие плюсы остаются у плюсов?
Ерунда. Аккуратно написанный С++ код верифицируется самым лучшим инструментом — мозгами читающего его программиста. А в дебрях pureC за деревьяеми можно не разглядеть леса. К тому же RAII надёжно делает кучу работы, которую никакой source-based верификатор никогда не осилит.
GN>Какой именно? В каждом случае могут быть свои причины.
Ну, тот же HyperV. Проект новый, практически с 0 написанный. Довольно объемный. По всем показателям ему бы на плюсах писаться?
GN>Сам же ответил в следующем посте — С++ сложнее верифицировать, нало же с чего то начинать.
С++ сложнее на порядок верифицировать. И похоже, у MS нет желения тратить время на разработку бесполезного с их точки зрения продукта.
TC>>А похоронили они 10 лет назад С++ ибо сие мерворожденное чудо, которое откачали медики-чудесники. GN> MS и в частности Герб Саттер активно развивают язык С++, VC поддерживает C++0x в отличае от C99.
С++0х — это гимн и реквием одновременно . А С развивать не надо — это совершенный ( в своей парадигме естественно ) язык. Например, обсуждая С++, можно придумать кучу фич, которых не хватает в языке или стандартной библиотеке. Собственно, за пару десятилетий активного использования накопился целый том, который и назвали С++0x ( пора бы в C++1x переименовать? ) А за годы использования С все пожелания свелись к жалкому С99. Что там в нем? bool считать встронным типом и переменные объявлять не в начале блока? Мне лично С99 вообще на фиг не нужен.
TC>> Перспектива вообщем понятная: все что можно (99%) будет на управляемом коде написано, остальное, где уж совсем никак без этого — С напополам с асмом. GN>Одно не понятно в этой перспективе, когда настанет её время и смерть Windows. Пока что Wintel пережила не один прогноз о своей смерти, Итаник, дотнет в ядре Висты...
Windows и не умрет. А NT перестанет быть доминирующей платформой. С++ — доминирующим языком в разработке десктопных приложений.
IID>Ерунда. Аккуратно написанный С++ код верифицируется самым лучшим инструментом — мозгами читающего его программиста.
Да-да. Мозг — прекрасное средство поиска ошибок. Только он обычно включается после того, как ошибка уже случилась. А статический верификатор — это просто вспомогательное средство, позволяющее мозг подлючить до возникновения ошибки, а не после.
IID>К тому же RAII надёжно делает кучу работы, которую никакой source-based верификатор никогда не осилит.
Утечки ресурсов верификаторы ловят очень неплохо. А RAII — это не панацея. В реализации класса-владельца ресурса также могут быть ошибки. Кроме того RAII — это гарантированные дополнительные расходы: памяти и процессорного времени. То, что верификатор проверят единожды, твой код будет делать постоянно, на всех пользовательских машинах. И чем той код будет становится надежней, тем больше будет накладных расходов.
приведена реализация такого auto_ptr, по 2м выделенным фрагментам кода видно, что проблемы остальных реализаций были вызваны недооптимизатором.
TC> То, что верификатор проверят единожды, твой код будет делать постоянно, на всех пользовательских машинах.
Хм, уже научились верифицировать хранимое состояние?
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, TarasCo, Вы писали:
TC>Ну, тот же HyperV. Проект новый, практически с 0 написанный. Довольно объемный. По всем показателям ему бы на плюсах писаться?
Этот проект делали самые крутые спецы, с самой высокой когнитивной ригидностью. Степень важности проекта и доступное количество ресурсов позволили отказаться от рисков.
TC>С++ сложнее на порядок верифицировать.
Трансляция С++ в С тривиальна, проблемы лишь с языком аннотаций.
TC> И похоже, у MS нет желения тратить время на разработку бесполезного с их точки зрения продукта.
Уже давно тратят, делая управляемый С++. Верификатор С кода идёт к той же проблеме но с дургой стороны.
TC>С++0х — это гимн и реквием одновременно .
Ну... да Концепты, rvalue references — хороший показатель, что авторитеты тоже ошибаются, никто не может точно знать наперёд...
TC> А С развивать не надо — это совершенный ( в своей парадигме естественно ) язык. Например, обсуждая С++, можно придумать кучу фич, которых не хватает в языке или стандартной библиотеке. Собственно, за пару десятилетий активного использования накопился целый том, который и назвали С++0x ( пора бы в C++1x переименовать? ) А за годы использования С все пожелания свелись к жалкому С99.
За годы существования K&R C появилось достаточно усовершенствований как самого языка: C89, С90, C99 и сюрприз — C1X, так и изменений выхордящих за рамки языка: С--, C++, Go, Objective C, ...
С остайтся поскольку обычно выполняет роль стандартного бинарного интерфейса.
TC> Что там в нем? bool считать встронным типом и переменные объявлять не в начале блока?
здесь. inline, restrict, массивы переменной длины. C1X вносит гораздо больше, упомяну лишь стандартизацию _ReadWriteBarrier & Co. Показательно, что даже изменения в препроцессоре VC делались ради C++.
TC> Мне лично С99 вообще на фиг не нужен.
Дело не в ком-то лично. Нельзя взять С99 код и скомпилировать его под Виндовс без шаманства.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re: опять cpp в драйвере...
От:
Аноним
Дата:
04.03.10 15:55
Оценка:
Здравствуйте, MTimur, Вы писали:
MT>Знающие люди, объясните как это понимать, оно вообще скомпилится? Если да, то как? Вроде как microsoft говорил всегда, что CPP в драйверах не поддерживает. Или я что-то упустил?
если код правильный то скомпилиться (я код не читал)
а вообще что вы удивляетесь? вчера программирование начали изучать что ли?
в винде win2k.sys GUI написано в перемешку на С,C++
DirectX написан на C,C++, и в оптимизациях на asm
всем известный syser дебаггер, написан на C++ полностью
TC>А С развивать не надо — это совершенный ( в своей парадигме естественно ) язык. Например, обсуждая С++, можно придумать кучу фич, которых не хватает в языке или стандартной библиотеке. Собственно, за пару десятилетий активного использования накопился целый том, который и назвали С++0x ( пора бы в C++1x переименовать? ) А за годы использования С все пожелания свелись к жалкому С99. Что там в нем? bool считать встронным типом и переменные объявлять не в начале блока? Мне лично С99 вообще на фиг не нужен.
Двачую! Оставьте C и выкиньте уже этот недосишарп в лице C++.
Здравствуйте, x64, Вы писали:
x64>Двачую! Оставьте C и выкиньте уже этот недосишарп в лице C++.
Ниасиливший детектед!
не сподвигнувшиеся выучить ООП (а некоторые из них про него и не слышали, искренне считая все технологии после 1981 г. унылым говном), разжигают холивар, который, как правило, сводится к необходимости описывать каждый чих в ООП с одной стороны и необходимость изобретать уйму велосипедов для хоть какой-нибудь объектности с другой.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, IID, Вы писали:
IID>Ниасиливший детектед!
ИМХО больше похоже на сильное влияние Дельфи.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
MS и в частности Герб Саттер активно развивают язык С++, VC поддерживает C++0x в отличае от C99.
