Аннотация:
Впервые показана принципиальная возможность создания исполняемых модулей подсистемы Windows native (в том числе и драйверов устройств) в среде Borland Delphi.
Unlike reality, stupidity is inescapable
Re: Создание драйверов режима ядра в среде Borland Delphi
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Как насчет VxD? Я помню, что один мой знакомый, Евгений Безверхий, написал переходник форматов, который в итоге позволял строить VxD.
Для построения VxD есть очень похожий способ, и переходник форматов там не нужен.
Unlike reality, stupidity is inescapable
Re[2]: Создание драйверов режима ядра в среде Borland Delphi
Здравствуйте, Геннадий Порев, Вы писали:
ГП>Статья:
ГП>Авторы: ГП> Геннадий Порев
ГП>Аннотация: ГП>Впервые показана принципиальная возможность создания исполняемых модулей подсистемы Windows native (в том числе и драйверов устройств) в среде Borland Delphi.
Относительно впервые — см. хотя бы http://infocity.kiev.ua/prog/delphi/content/delphi004.phtml?id=571
Здесь перепечатка — но оригинальный материал я видел еще примерно года три назад — сделайте поиск в том же гугле по фразе "Пример создания VxD-драйвера на Delphi" — несколько сотен ссылок.
К сожалению, полная версия статьи мне пока недоступна, но все же рискну предположить, что делается
подменяем делфийского ртл, долго и нудно переводятся хидера, делаются какие-то шаманские действия с полученными obj, чтобы скормить майкрософтовскому линкеру.. Спрашивается, зачем же все это, и насколько уместен здесь сам Делфи?
Зы. Все-же попытаюсь отыскать полную версию статьи, может где в столицах и журнал приобрету..
... Эта
Re[2]: Создание драйверов режима ядра в среде Borland Delphi
Здравствуйте, Ihor Osovyak, Вы писали:
ГП>>Статья: ГП>>Авторы: ГП>> Геннадий Порев ГП>>Аннотация: ГП>>Впервые показана принципиальная возможность создания исполняемых модулей подсистемы Windows native (в том числе и драйверов устройств) в среде Borland Delphi.
IO> Относительно впервые — см. хотя бы http://infocity.kiev.ua/prog/delphi/content/delphi004.phtml?id=571 IO> Здесь перепечатка — но оригинальный материал я видел еще примерно года три назад — сделайте поиск в том же гугле по фразе "Пример создания VxD-драйвера на Delphi" — несколько сотен ссылок.
Во-первых, в этом нет необходимости. Я связывался с автором оригинального материала про VxD, консультировался у него по этому поводу, и сообщил ему о некоторых собственных улучшениях методики.
Во-вторых, я надеюсь, что Вы всё же вкурсе принципиальных отличий VxD от Windows Native Subsystem, что делает эту статью всё же оригинальным материалом, носящим титул "впервые показано" вполне заслуженно.
IO> К сожалению, полная версия статьи мне пока недоступна, но все же рискну предположить, что делается IO> подменяем делфийского ртл, долго и нудно переводятся хидера, делаются какие-то шаманские действия с полученными obj, чтобы скормить майкрософтовскому линкеру.. Спрашивается, зачем же все это, и насколько уместен здесь сам Делфи?
В целом похоже, но не совсем так. Делфийский ртл не подменяется, а удаляется. Хидера переводятся не долго и нудно, а минимальный "компилябельный" SYS занимает в исходнике аж 76 строк.
Что касается необходимости и уместности. Я считаю что средства разработки для native subsystem на основе паскального синтаксиса до этого момента не существовали, не смотря на то, что популярность деривативов паскаля в данный момент не меньше, а в некоторых отраслях рынка и больше чем деривативов C. Поэтому данной статьей я просто закрыл некоторую досадную прореху в ассортименте средств разработки.
Unlike reality, stupidity is inescapable
Re[3]: Создание драйверов режима ядра в среде Borland Delphi
Здравствуйте, MouseTail, Вы писали:
MT>Здравствуйте, Ihor Osovyak, Вы писали:
IO>> Относительно впервые — см. хотя бы http://infocity.kiev.ua/prog/delphi/content/delphi004.phtml?id=571
MT>Во-первых, в этом нет необходимости. Я связывался с автором оригинального материала про VxD, консультировался у него по этому поводу, и сообщил ему о некоторых собственных улучшениях методики.
это радует.
MT>Во-вторых, я надеюсь, что Вы всё же вкурсе принципиальных отличий VxD от Windows Native Subsystem,
как это ни странно, но знаком. На уровне бегин левел. Но, впрочем, несколько моих sys (и legacy, и wdm) и одна vxd используются в нескольких проектах.
> что делает эту статью всё же оригинальным материалом, носящим титул "впервые показано" вполне заслуженно.
хм, может и так, если рассматривать все же в контексте NT..
IO>> К сожалению, полная версия статьи мне пока недоступна, но все же рискну предположить, что делается IO>> подменяем делфийского ртл, долго и нудно переводятся хидера, делаются какие-то шаманские действия с полученными obj, чтобы скормить майкрософтовскому линкеру.. Спрашивается, зачем же все это, и насколько уместен здесь сам Делфи?
MT>В целом похоже, но не совсем так. Делфийский ртл не подменяется, а удаляется. Хидера переводятся не долго и нудно, а минимальный "компилябельный" SYS занимает в исходнике аж 76 строк.
MT>Что касается необходимости и уместности. Я считаю что средства разработки для native subsystem на основе паскального синтаксиса до этого момента не существовали, не смотря на то, что популярность деривативов паскаля в данный момент не меньше, а в некоторых отраслях рынка и больше чем деривативов C. Поэтому данной статьей я просто закрыл некоторую досадную прореху в ассортименте средств разработки.
здесь у меня несколько иное мнение. При написания драйвера используется в большинстве случаев ограниченное подмножество синтаксиса и возможностей си (рассматривем вариант работы только с ддк, а не со всякими навороченными библиотеками,например, от того же numega, которые начинающему не так помогают, как мозги запудривают). ТО минимальное подмножество си в случае необходимости человек, даже не знающий си довольно быстро осваивает. Я думаю, что если человек с нуля (и без знания си) начинает приобщаться к драйверописанию, то с тех времменых затрат, что ему нужно провести на усвоение идеологии драйверной модели, особенностей апи режима ядра и собственно на борьбу с си, доля последней состоавляющей ничтожно мала. И занимает намного меньше времени, чем пойдет хотя бы на преобразование минимального набора хидеров.. Я, кстати, проходил похожий путь — ибо я делфиец, а с си работал более восьми лет назад, и то очень мало, более в плане хобби (справедливости ради все же можно сказать, что при работе с делфи, си все же на уровне рид-онли примеров с мсдн поддерживался). Но все же можно сказать, что при написании своего первого драйвера мне пришлось си начинать почти с нуля. Так вот, проблем с си почти не было, если сравнивать с теми проблемами, которые возникали при изучении идеологии и частично апи режима ядра..
То есть если говорить коротко — Ваше изыскание может и интересно чисто в теоритическом плане, но пользы в практической работе — я все же думаю — никакой.. Да, на всякий случай — при программировании для win32 (в т.ч. системном) я однозначно даю предпочтение делфи, отыт профессиональной работы с pascal/delphi — где-то года с 1989, все время занимаюсь разработкой.
Re[4]: Создание драйверов режима ядра в среде Borland Delphi
>> что делает эту статью всё же оригинальным материалом, носящим титул "впервые показано" вполне заслуженно.
IO>хм, может и так, если рассматривать все же в контексте NT..
Как вы знаете, понятие Windows Native Subsystem имеет смысл только в таком контексте.
MT>>Что касается необходимости и уместности. Я считаю что средства разработки для native subsystem на основе паскального синтаксиса до этого момента не существовали, не смотря на то, что популярность деривативов паскаля в данный момент не меньше, а в некоторых отраслях рынка и больше чем деривативов C. Поэтому данной статьей я просто закрыл некоторую досадную прореху в ассортименте средств разработки.
IO>здесь у меня несколько иное мнение. При написания драйвера используется в большинстве случаев ограниченное подмножество синтаксиса и возможностей си (рассматривем вариант работы только с ддк, а не со всякими навороченными библиотеками,например, от того же numega, которые начинающему не так помогают, как мозги запудривают). ТО минимальное подмножество си в случае необходимости человек, даже не знающий си довольно быстро осваивает. Я думаю, что если человек с нуля (и без знания си) начинает приобщаться к драйверописанию, то с тех времменых затрат, что ему нужно провести на усвоение идеологии драйверной модели, особенностей апи режима ядра и собственно на борьбу с си, доля последней состоавляющей ничтожно мала. И занимает намного меньше времени, чем пойдет хотя бы на преобразование минимального набора хидеров.. Я, кстати, проходил похожий путь — ибо я делфиец, а с си работал более восьми лет назад, и то очень мало, более в плане хобби (справедливости ради все же можно сказать, что при работе с делфи, си все же на уровне рид-онли примеров с мсдн поддерживался). Но все же можно сказать, что при написании своего первого драйвера мне пришлось си начинать почти с нуля. Так вот, проблем с си почти не было, если сравнивать с теми проблемами, которые возникали при изучении идеологии и частично апи режима ядра.. IO> То есть если говорить коротко — Ваше изыскание может и интересно чисто в теоритическом плане, но пользы в практической работе — я все же думаю — никакой.. Да, на всякий случай — при программировании для win32 (в т.ч. системном) я однозначно даю предпочтение делфи, отыт профессиональной работы с pascal/delphi — где-то года с 1989, все время занимаюсь разработкой.
Как я понял, основное препятствие, по-Вашему, отсутствие переведённых хидеров. Но ведь работа не стоит на месте... Они появятся очень скоро
Unlike reality, stupidity is inescapable
Re[5]: Создание драйверов режима ядра в среде Borland Delphi
Здравствуйте, MouseTail, Вы писали:
MT>Как я понял, основное препятствие, по-Вашему, отсутствие переведённых хидеров. Но ведь работа не стоит на месте... Они появятся очень скоро
Нет, не только, и далеко не в первую очередь. Извините за прямоту — Вы не очень внимательно читаете.
К тому же я не упоминал совершенно очевидных вещей, например, вопросов поддержки и сопровождения.
Да, еще. На всякий случай — в wxp ddk суммарный объем хидеров примерно 9 мегабайт.. Это относительно "появятся очень скоро".
Еще. Я, конечно, понимаю, что я не вправе давать Вам советы, но все же рискну, скажем так, высказать одну мысль.. Вы, безусловно, талантливый исследователь. И могли бы найти более полезную сферу для исследований.. Хотя, здесь можно маленькую оговорку сделать.. Если Вы планируете написать какую-то книгу по соотв. тематике, либо преподаете соотв. курс в каком-то ВУЗе — то Ваши изыскания может и имеют смысл.. Но даже в таком случае желательно немного по иному раставить акценты в обнародованных материалах.
Re[6]: Создание драйверов режима ядра в среде Borland Delphi
Здравствуйте, Ihor Osovyak, Вы писали:
IO>Здравствуйте, MouseTail, Вы писали:
MT>>Как я понял, основное препятствие, по-Вашему, отсутствие переведённых хидеров. Но ведь работа не стоит на месте... Они появятся очень скоро
IO>Нет, не только, и далеко не в первую очередь. Извините за прямоту — Вы не очень внимательно читаете.
По поводу остального я не нашёл, что возразить
IO>К тому же я не упоминал совершенно очевидных вещей, например, вопросов поддержки и сопровождения.
Это зависит от того, реализуется ли эта идея в коммерческий продукт или в какой-нибудь опенсорс на энтузиастах... Варианты есть.
IO>Да, еще. На всякий случай — в wxp ddk суммарный объем хидеров примерно 9 мегабайт.. Это относительно "появятся очень скоро".
А Вы думаете, что я их вручную собрался переводить?
IO>Еще. Я, конечно, понимаю, что я не вправе давать Вам советы, но все же рискну, скажем так, высказать одну мысль.. Вы, безусловно, талантливый исследователь. И могли бы найти более полезную сферу для исследований.. Хотя, здесь можно маленькую оговорку сделать.. Если Вы планируете написать какую-то книгу по соотв. тематике, либо преподаете соотв. курс в каком-то ВУЗе — то Ваши изыскания может и имеют смысл.. Но даже в таком случае желательно немного по иному раставить акценты в обнародованных материалах.
В целом согласен. Но. Целью данного материала являлось лишь показать принципиальную возможность. Застолбить первенство на непаханом поле, обеспечить приоритет, как это принято в научном мире. В данный момент последующая жизнь этой отрасли под моим руководством весьма сомнительна — временных ресурсов катастрофически не хватает. Но если найдутся энтузиасты, всё же пусть на одном из первых кирпичиков там будет надпись — "Здесь был я"
Собственно, никаких более масштабных целей этой публикацией я не преследовал.
Unlike reality, stupidity is inescapable
Re[7]: Создание драйверов режима ядра в среде Borland Delphi
MT>Это зависит от того, реализуется ли эта идея в коммерческий продукт или в какой-нибудь опенсорс на энтузиастах... Варианты есть.
ну не верю я, не верю
IO>>Да, еще. На всякий случай — в wxp ddk суммарный объем хидеров примерно 9 мегабайт.. Это относительно "появятся очень скоро".
MT>А Вы думаете, что я их вручную собрался переводить?
как человек, немного переводивший хидера, я думаю, что задача полностью автоматизировать этот процесс далеко не тривиальная.
IO>>Еще. Я, конечно, понимаю, что я не вправе давать Вам советы, но все же рискну, скажем так, высказать одну мысль.. Вы, безусловно, талантливый исследователь. И могли бы найти более полезную сферу для исследований.. Хотя, здесь можно маленькую оговорку сделать.. Если Вы планируете написать какую-то книгу по соотв. тематике, либо преподаете соотв. курс в каком-то ВУЗе — то Ваши изыскания может и имеют смысл.. Но даже в таком случае желательно немного по иному раставить акценты в обнародованных материалах.
MT>В целом согласен. Но. Целью данного материала являлось лишь показать принципиальную возможность. Застолбить первенство на непаханом поле, обеспечить приоритет, как это принято в научном мире. В данный момент последующая жизнь этой отрасли под моим руководством весьма сомнительна — временных ресурсов катастрофически не хватает. Но если найдутся энтузиасты, всё же пусть на одном из первых кирпичиков там будет надпись — "Здесь был я"
MT>Собственно, никаких более масштабных целей этой публикацией я не преследовал.
есть очень много принципиальных возможностей, но не все они целесообразны.. Вспомнил один полупохабный анекдот околомедицинской тематики с соотв. идеей.. Но не буду .
На всякий случай — я ссылку на эту веточку дал одному человеку — человеку, кстати, очень высокой квалификации — он говорил, что с похожей идеей (присособить делфи для разработки модулей режима ядра) он носился уже давно — может он и посчитает нужным войти в контакт с Вами. А может и нет .
Re[3]: Создание драйверов режима ядра в среде Borland Delphi
Приветствую дискутирующих!
MT>Что касается необходимости и уместности. Я считаю что средства разработки для native subsystem на основе паскального синтаксиса до этого момента не существовали, не смотря на то, что популярность деривативов паскаля в данный момент не меньше, а в некоторых отраслях рынка и больше чем деривативов C. Поэтому данной статьей я просто закрыл некоторую досадную прореху в ассортименте средств разработки.
Рискну вызвать волну флейма, но деривативы Паскаля — понятие более чем абстрактное. Нет смысла говорить об абстрактной популярности языка, а лишь о его популярности ДЛЯ. Для решения определенного круга задач. Как уже неоднократно отмечалось, человек, программирующий задачу на данном языке, несмотря на то, что он (язык) для нее не подходит, делает ошибку либо подчиняется обстоятельствам. Это не к тому, что Delphi не подходит для написания драйверов, это лишь довод в пользу классификации по сферам применения.
Так вот, конкретно Delphi совершенно справедливо позиционируется как RAD-среда, причем с выраженным акцентом на "прикладной" смысл слова Application. В основном это выражается в быстром проектировании пользовательского интерейса, хотя и не только.
Из-за обилия неконтролируемых или, что не лучше, принципиально контролируемых, но недокументированных действий, Делфи не очень хорошо подходит для задач, в которых нужно, чтобы программа делала ровно то-то и то-то. Применять Делфи для создания драйверов — это по продуктивности то же самое, что применять Делфи без VCL и визуального проектирования. То есть — я рискну и попытаюсь навязать свое мнение читающим — в этом случае вместо Делфи вполне можно юзать любой компилер, хоть тот же FPC. Причем этот другой компилер может даже расширять язык более выгодно для программиста, чем Delphi.
Ну и потом, о вкусах не спорят, так что тут я ни на чем не настаиваю, но лично мне гораздо больше нравится C++, и я бы писал исключительно на нем, если бы для него существовала нормальная RAD-среда хотя бы для проектирования GUI (Билдер — не нормальная). И возможности языка не в пример шире, это факт.
Короче говоря, незачем делать припарки мертвому — Делфи подходит для написания драйверов по крайней мере немного меньше, чем C++. Тогда зачем упираться и делать это на Делфи?
Но! Все выше сказанное вовсе не означает бессмысленность исследования. Важен сам поиск решения, методика, — ведь она может оказаться полезной при решении других проблематичных ситуаций. Ну и, безусловно, вопрос принципа тоже не последний: теперь Делфи применим еще в одной нише, что делает его более универсальным, чем обычно считается.
С уважением,
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Re[8]: Создание драйверов режима ядра в среде Borland Delphi
Здравствуйте, Ihor Osovyak, Вы писали:
MT>>Это зависит от того, реализуется ли эта идея в коммерческий продукт или в какой-нибудь опенсорс на энтузиастах... Варианты есть. IO>ну не верю я, не верю
Чему именно Вы не верите?
IO>>>Да, еще. На всякий случай — в wxp ddk суммарный объем хидеров примерно 9 мегабайт.. Это относительно "появятся очень скоро". MT>>А Вы думаете, что я их вручную собрался переводить? IO>как человек, немного переводивший хидера, я думаю, что задача полностью автоматизировать этот процесс далеко не тривиальная.
Но и полностью вручную это делать тоже не обязательно. А также не обязательно переводить все хидеры.
Unlike reality, stupidity is inescapable
Re[3]: Создание драйверов режима ядра в среде Borland Delphi
Хорош пример
>Компиляция данного примера возможна только с Delphi 3. Delphi 2 не был опробован в связи с его отсутствием, объектные фалы созданные Delphi 4 отвергаются Microsoft ® Linker 5.12.8181 как файлы неизвестного формата.
Мило, ничего не скажешь. Небось из-за COMDEF-записей и отвергаются "фалы". Я уж как-нибудь буду на D6 или D7 писать
А насчет того, что я написал — переходник был нужен вроде бы именно для вырезания несовместимых записей в OBJ, тогда и уродовать RTL не надо. Впрочем, подробный отзыв напишу, только когда увижу журнал. Пока не прислали, и даже не запрос не ответили.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Re[4]: Создание драйверов режима ядра в среде Borland Delphi
Здравствуйте, Slicer [Mirkwood], Вы писали:
MT>>Что касается необходимости и уместности. Я считаю что средства разработки для native subsystem на основе паскального синтаксиса до этого момента не существовали, не смотря на то, что популярность деривативов паскаля в данный момент не меньше, а в некоторых отраслях рынка и больше чем деривативов C. Поэтому данной статьей я просто закрыл некоторую досадную прореху в ассортименте средств разработки.
SM>Рискну вызвать волну флейма, но деривативы Паскаля — понятие более чем абстрактное. Нет смысла говорить об абстрактной популярности языка, а лишь о его популярности ДЛЯ. Для решения определенного круга задач. Как уже неоднократно отмечалось, человек, программирующий задачу на данном языке, несмотря на то, что он (язык) для нее не подходит, делает ошибку либо подчиняется обстоятельствам. Это не к тому, что Delphi не подходит для написания драйверов, это лишь довод в пользу классификации по сферам применения. SM>Так вот, конкретно Delphi совершенно справедливо позиционируется как RAD-среда, причем с выраженным акцентом на "прикладной" смысл слова Application. В основном это выражается в быстром проектировании пользовательского интерейса, хотя и не только.
Ничего абстрактного Delphi, FPC, GNU Pascal и прочие. То есть те, чьё синтаксическое сходство с виртовским паскалем больше, чем у остальных языков.
По поводу подчинения обстоятельствам и прочей мифологии. Позволю себе не согласиться. Не далее как недавно , пришлось мне писать SMTP шлюз, работающий сервисом под нагрузкой около 150-200 одновременных коннектов. Шлюз должен был уметь провести сеанс в соответствии с RFC2821, сделать небольшую антиспамерскую проверку и положить бандл в очередь. Так вот, писал я его на Delphi. Исходник сего чуда занял всего около 7 тысяч строк, из которых всего около тысячи собственно шлюз, а остальное — моя собственная RTL и библиотека классов тоже собственной разработки. Скомпиленый екзешник занимает 72 кбайт, под пиковой нагрузкой ест около 6 мбайт working set, обходится 5 потоками и занимает не более 15% проца вобщем не самого крутого. Это, конечно, оценки очень приблизительные, по таск-менеджеру. Но я это к чему, собственно. Если взять обычного программера, владеющего в достаточной мере, допустим, Delphi, BCB, MSVC и т.п. и поставить перед ним такое ТЗ, то он для реализации выберет Delphi в последнюю очередь. Всё потому, что Delphi окружена целой стеной мифов и предрассудков, порождённых гуёвыми мышевозильщиками и бросателями компонентов на формы.
Я же считаю, что качество выполнения работы зависит от программиста, и абсолютно не зависит от средства разработки. Я допускаю, что кто-то может владеть, скажем, Visual Basic'ом в такой мере, что позволит ему решить подобную задачу на более впечатляющих показателях. И я буду уважать такого профессионала при всё моём презрении к Visual Basic.
SM>Из-за обилия неконтролируемых или, что не лучше, принципиально контролируемых, но недокументированных действий, Делфи не очень хорошо подходит для задач, в которых нужно, чтобы программа делала ровно то-то и то-то.
"Вы просто не умеете их готовить" (c). У меня программы неконтролируемой самодеятельностью не занимаются.
SM> Применять Делфи для создания драйверов — это по продуктивности то же самое, что применять Делфи без VCL и визуального проектирования.
Чем я успешно последние годы занимаюсь и получаю за это деньги.
SM> То есть — я рискну и попытаюсь навязать свое мнение читающим — в этом случае вместо Делфи вполне можно юзать любой компилер, хоть тот же FPC. Причем этот другой компилер может даже расширять язык более выгодно для программиста, чем Delphi.
Нет, тут Вы принципиально не правы. Заниматься программированием невизуальных (не гуишных) вещей на FPC тяжелее чем на Delphi, это я по собственному опыту говорю. Ну и если возникает вопрос о навешивании какого-нибудь гуишного фронтэнда, то использовать уже два компилятора просто неудобно.
SM>Ну и потом, о вкусах не спорят, так что тут я ни на чем не настаиваю, но лично мне гораздо больше нравится C++, и я бы писал исключительно на нем, если бы для него существовала нормальная RAD-среда хотя бы для проектирования GUI (Билдер — не нормальная). И возможности языка не в пример шире, это факт.
Это не факт, это личное и частное мнение. Я не буду спорить, потому что этот спор ни к чему не приводит вот уже десятиления. Я считаю, что недостатки и достоинства у паскальных и сишных деривативов распределены приблизительно одинаково и взаимно компенсируют друг-друга.
SM>Короче говоря, незачем делать припарки мертвому — Делфи подходит для написания драйверов по крайней мере немного меньше, чем C++. Тогда зачем упираться и делать это на Делфи?
Лишь потому, что одна маленькая и мягкая фирма сделала С\С++ своим корпоративным стандартом. А без этого все языки равны в этой отрасли.
SM>Но! Все выше сказанное вовсе не означает бессмысленность исследования. Важен сам поиск решения, методика, — ведь она может оказаться полезной при решении других проблематичных ситуаций. Ну и, безусловно, вопрос принципа тоже не последний: теперь Делфи применим еще в одной нише, что делает его более универсальным, чем обычно считается.
О чём и речь
Unlike reality, stupidity is inescapable
Re[5]: Создание драйверов режима ядра в среде Borland Delphi
Здравствуйте, MouseTail, Вы писали:
MT>По поводу подчинения обстоятельствам и прочей мифологии. Позволю себе не согласиться. Не далее как недавно , пришлось мне писать SMTP шлюз, работающий сервисом под нагрузкой около 150-200 одновременных коннектов. Шлюз должен был уметь провести сеанс в соответствии с RFC2821, сделать небольшую антиспамерскую проверку и положить бандл в очередь. Так вот, писал я его на Delphi. Исходник сего чуда занял всего около 7 тысяч строк, из которых всего около тысячи собственно шлюз, а остальное — моя собственная RTL и библиотека классов тоже собственной разработки. Скомпиленый екзешник занимает 72 кбайт, под пиковой нагрузкой ест около 6 мбайт working set, обходится 5 потоками и занимает не более 15% проца вобщем не самого крутого. Это, конечно, оценки очень приблизительные, по таск-менеджеру. Но я это к чему, собственно. Если взять обычного программера, владеющего в достаточной мере, допустим, Delphi, BCB, MSVC и т.п. и поставить перед ним такое ТЗ, то он для реализации выберет Delphi в последнюю очередь.
И будет неправ? А почему? Потому, что "качество выполнения работы зависит от программиста, и абсолютно не зависит от средства разработки"? Так это абсурд. Вы потратите месяц, пока напишете на Delphi каркас, поддерживающий логическое программирование, и лишь затем приступите к написанию собственно экспертной системы в виде набора фактов и правил вывода. На Прологе я вообще не потрачу времени на каркас.
Аналогично, на VC++ замучаешься писать сложный интерфейс со множеством вкладок, докирующимися элементами и т.п., хотя бы потому, что нельзя все это двигать мышкой и представлять себе, что в чем находится (ну, кое-что можно, местами). На Delphi то же самое делается намного быстрее.
MT>"Вы просто не умеете их готовить" (c). У меня программы неконтролируемой самодеятельностью не занимаются.
Спешу засвидетельствовать свое почтение профессионалу. Мне за 8 лет программирования на Delphi этого добиться так и не удалось. Впрочем, я не ставил эту цель первичной: кому-то ведь надо и сами приложения писать А так — если подменить RTL и сделать еще пару финтов ушами, можно, пожалуй, и избежать неоднозначностей. Вот только с Delphi результат будет иметь мало общего
MT>Чем я успешно последние годы занимаюсь и получаю за это деньги.
Что это доказывает? Только то, что это возможно. Но никак не то, что это оптимально.
SM>> То есть — я рискну и попытаюсь навязать свое мнение читающим — в этом случае вместо Делфи вполне можно юзать любой компилер, хоть тот же FPC. Причем этот другой компилер может даже расширять язык более выгодно для программиста, чем Delphi. MT>Нет, тут Вы принципиально не правы. Заниматься программированием невизуальных (не гуишных) вещей на FPC тяжелее чем на Delphi, это я по собственному опыту говорю. Ну и если возникает вопрос о навешивании какого-нибудь гуишного фронтэнда, то использовать уже два компилятора просто неудобно.
Не знаю, я по опыту использования FPC этого бы не сказал. Но спорить не буду, в основном я на нем писал под DOS extender. Да и не только FPC я имел в виду, а то, что какой-нибудь компилятор, кроме Delphi, может расширять язык лучше (вот в FPC, например, есть перегрузка операторов, если она кому-нибудь нужна). И если не юзать визуальность, он может лучше подойти для разработки. Я не говорил, что какой-то конкретный компилятор подходит лучше.
SM>>И возможности языка не в пример шире, это факт. MT>Это не факт, это личное и частное мнение.
Это таки факт. Многие паскалевские конструкции имеют в C++ прямые аналоги, для других можно придумать аналоги, используя шаблоны. Еще что-то можно сделать возможным, введя базовый класс и потребовав у всех от него наследоваться. Object Pascal же нечего противопоставить шаблонам, по кр. мере, с сохранением всей полноты возможностей наследования и прилично выглядящего синтаксиса. Разве что Delphi .Net... но на нем вы как раз WDM-драйвер и не напишете, тем более — VxD
SM>>Короче говоря, незачем делать припарки мертвому — Делфи подходит для написания драйверов по крайней мере немного меньше, чем C++. Тогда зачем упираться и делать это на Делфи? MT>Лишь потому, что одна маленькая и мягкая фирма сделала С\С++ своим корпоративным стандартом. А без этого все языки равны в этой отрасли.
Согласен. Но не ради же принципа писать драйвера на Delphi, если сейчас это удобнее делать на C++!
MT>О чём и речь
Тут без комментариев
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Re[6]: Создание драйверов режима ядра в среде Borland Delphi
Здравствуйте, Slicer [Mirkwood], Вы писали:
MT>>По поводу подчинения обстоятельствам и прочей мифологии. Позволю себе не согласиться. Не далее как недавно , пришлось мне писать SMTP шлюз, работающий сервисом под нагрузкой около 150-200 одновременных коннектов. Шлюз должен был уметь провести сеанс в соответствии с RFC2821, сделать небольшую антиспамерскую проверку и положить бандл в очередь. Так вот, писал я его на Delphi. Исходник сего чуда занял всего около 7 тысяч строк, из которых всего около тысячи собственно шлюз, а остальное — моя собственная RTL и библиотека классов тоже собственной разработки. Скомпиленый екзешник занимает 72 кбайт, под пиковой нагрузкой ест около 6 мбайт working set, обходится 5 потоками и занимает не более 15% проца вобщем не самого крутого. Это, конечно, оценки очень приблизительные, по таск-менеджеру. Но я это к чему, собственно. Если взять обычного программера, владеющего в достаточной мере, допустим, Delphi, BCB, MSVC и т.п. и поставить перед ним такое ТЗ, то он для реализации выберет Delphi в последнюю очередь. SM>И будет неправ? А почему? Потому, что "качество выполнения работы зависит от программиста, и абсолютно не зависит от средства разработки"?
Нет, потому что подавляющего большинства программистов существует такой предрассудок, ассоциативная связь — Delphi -> Visual-RAD среда и ничего более. Поэтому представить себе Delphi как инструмент решения подобных задач может только тот, кто свободен от таких предрассудков.
SM> Так это абсурд. Вы потратите месяц, пока напишете на Delphi каркас, поддерживающий логическое программирование, и лишь затем приступите к написанию собственно экспертной системы в виде набора фактов и правил вывода. На Прологе я вообще не потрачу времени на каркас.
Давайте всё же будем рассматривать языки, имеющие примерно равные возможности... На Прологе вы сможете написать win32-сервис? Или, скажем, user-mode sniffer/firewall? Наверное, нет. А среди равных по возможностям языков выдвинутый мною тезис вполне справедлив.
MT>>Чем я успешно последние годы занимаюсь и получаю за это деньги. SM>Что это доказывает? Только то, что это возможно. Но никак не то, что это оптимально.
Уж поверьте мне на слово, если бы я решал те же самые задачи, допустим, на MSVC, это занимало бы как минимум ровно столько же ресурсов. Прецеденты есть Так что выбор Delphi у меня скорее сродни религии
SM>>>И возможности языка не в пример шире, это факт. MT>>Это не факт, это личное и частное мнение. SM>Это таки факт. Многие паскалевские конструкции имеют в C++ прямые аналоги, для других можно придумать аналоги, используя шаблоны.
Вы таки хотите поднять волну флейма? Придумайте, пожалуйста, аналоги для WITH, SET, AS, IN, PROPERTY, модификаторам CONST/VAR/OUT, или скажем для INTERFACE (который тип), ARRAY OF. Продолжать? Я ж прошу Вас — бесполезное это занятие. Сишники не видят недостатков С\С++, паскалисты не видят недостатков Паскаля.
SM> Еще что-то можно сделать возможным, введя базовый класс и потребовав у всех от него наследоваться.
Это костыль, вы же понимаете. Введением класса можно добиться любой функциональности, которой нет в языке, но это доказывает лишь то, что такой функциональности нет в языке.
SM>>>Короче говоря, незачем делать припарки мертвому — Делфи подходит для написания драйверов по крайней мере немного меньше, чем C++. Тогда зачем упираться и делать это на Делфи? MT>>Лишь потому, что одна маленькая и мягкая фирма сделала С\С++ своим корпоративным стандартом. А без этого все языки равны в этой отрасли. SM>Согласен. Но не ради же принципа писать драйвера на Delphi, если сейчас это удобнее делать на C++!
Это кому как. Я ж уже приводил свой тезис на эту тему.
Unlike reality, stupidity is inescapable
Re[5]: Создание драйверов режима ядра в среде Borland Delphi
MT> Если взять обычного программера, владеющего в достаточной мере, допустим, Delphi, BCB, MSVC и т.п. и поставить перед ним такое ТЗ, то он для реализации выберет Delphi в последнюю очередь. Всё потому, что Delphi окружена целой стеной мифов и предрассудков, порождённых гуёвыми мышевозильщиками и бросателями компонентов на формы.
Хм. А почему такая увереность за всех. Я, кстати, для аналогичной задачи выбрал бы делфи.
На си проект делал бы только в том случае, если бы заказчик очень настаивал. И то, после повышения расценок.
Да, но самолеятельностью с подменой RTL я бы не занимался. Хотя бы потому, что на полке стоят не до конца проработанные A.Jones,J. Ohlund, D. Iseminger. Чтение последних заметно больше пользы приносит для программирования сетей в Делфи, чем переработка RTL.
Re[7]: Создание драйверов режима ядра в среде Borland Delphi
Здравствуйте, MouseTail, Вы писали:
MT>Нет, потому что подавляющего большинства программистов существует такой предрассудок, ассоциативная связь — Delphi -> Visual-RAD среда и ничего более. Поэтому представить себе Delphi как инструмент решения подобных задач может только тот, кто свободен от таких предрассудков.
Согласен.
MT>Давайте всё же будем рассматривать языки, имеющие примерно равные возможности... На Прологе вы сможете написать win32-сервис? Или, скажем, user-mode sniffer/firewall? Наверное, нет. А среди равных по возможностям языков выдвинутый мною тезис вполне справедлив.
Спору нет, какие-то задачи из подобных (т.е. написания драйверов, сервисов etc.) я решу на C++ не быстрее, чем на Delphi. А какие-то — быстрее. И красивее. Или вот взять ту же разработку игр. К сожалению, какие-то — медленнее, потому что, несмотря на весь потенциал C++, дурная поддержка COM — самое слабое, на мой взгляд, место в этом языке. Так что я бы свел результаты сравнения языков к формуле выбора: либо красиво решенная работа с COM и интерфейсами, либо наличие шаблонов. Все остальное — мелочи.
MT>>>Чем я успешно последние годы занимаюсь и получаю за это деньги. SM>>Что это доказывает? Только то, что это возможно. Но никак не то, что это оптимально.
MT>Уж поверьте мне на слово, если бы я решал те же самые задачи, допустим, на MSVC, это занимало бы как минимум ровно столько же ресурсов. Прецеденты есть Так что выбор Delphi у меня скорее сродни религии
Да, что-то в этом есть
MT>Вы таки хотите поднять волну флейма? Придумайте, пожалуйста, аналоги для WITH, SET, AS, IN, PROPERTY, модификаторам CONST/VAR/OUT, или скажем для INTERFACE (который тип), ARRAY OF. Продолжать?
Для with аналога действительно нет, это минус, но — совсем малюсенький, из-за возможности объявлять локальные переменные где угодно в коде. Интерфейсы и, кстати, COM-объекты — это как раз из того немногого, что меня в C++ бесит. Вроде как шаблоны немножко решают проблему, но в целом это целый пласт вещей, для C++ до сих пор совершенно инородных.
Set вроде уже воспроизведен (-но?) хотя бы в Builder, да и потом — в подавляющем большинстве случаев он (оно) равноценен набору констант.
Property, из моего опыта в последнее время, приносит больше вреда, чем пользы, как раз из-за скрытых от программиста действий: то ли мы просто получаем значения поля, то ли вызывается какой-то метод...
CONST/VAR/OUT... Для const и var долго искать не надо, причем их смысл в C++ не в пример очевиднее, чем в Delphi (я о счетчиках ссылок и проч.), с Out сложнее, его и правда до сих пор нет.
Array of... А чем так плохи STL-контейнеры? Скажете, это не часть языка? Да, но это часть стандарта Если уж придираться к словам, то — да, этого в C++ нет. Хотя опять же можно красиво реализовать. Есть только одно, в чем array of лучше — это передача набора непосредственных значений, указываемого прямо при вызове функции. Это open arrays, а не dynamic arrays, но такая необходимость и встречается нечасто, и обходится безболезненно.
Итого, без интерфейсов и COM набирается не так уж и много недостатков. Зато насколько полнее инструментарий для того, чтобы писать свой код! Главным образом, я в восторге от шаблонов — и вовсе не скрываю этого. Были бы они в Delphi — вопрос о лучшем языке стал бы вопросом вкуса.
MT> Я ж прошу Вас — бесполезное это занятие. Сишники не видят недостатков С\С++, паскалисты не видят недостатков Паскаля.
Спору нет. А я кто? Почти всю сознательную жизнь пишу на Delphi, полгода на Java; у меня почти нет стажа на C++, но я на нем писал и продолжаю писать один проектик, да и книжек маленько читал, плюс опять же сертификация BrainBench. Так что имею некоторое начальное представление, и по нему выходит, что С++ во многом (не во всем) мне нравится больше. Так что я не сишник, но недостатки С++ вижу, но и на недостатки Delphi тоже глаза не закрываю.
Опсь, или Вы про себя?
SM>> Еще что-то можно сделать возможным, введя базовый класс и потребовав у всех от него наследоваться. MT>Это костыль, вы же понимаете. Введением класса можно добиться любой функциональности, которой нет в языке, но это доказывает лишь то, что такой функциональности нет в языке.
Но язык построен так, что она воспроизводима в его рамках, и использование этой воспроизведенной функциональности выглядит просто и естественно. Пример обратного — "шаблоны" в Delphi до .NET (модули + включаемые файлы).
SM>>Согласен. Но не ради же принципа писать драйвера на Delphi, если сейчас это удобнее делать на C++! MT>Это кому как. Я ж уже приводил свой тезис на эту тему.
Прошу прощения Мне как-то не захотелось читать ту гору флейма
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
.
Мне как-то не захотелось читать ту гору флейма 