Статья:
Создание драйверов режима ядра в среде Borland Delphi

Автор(ы): Геннадий Порев
Дата: 20.02.2005
Как известно, Borland, создавая Delphi, ориентировал этот продукт на рынок производства ПО для бизнеса. Поэтому в состав этого продукта не включено средств для создания таких низкоуровневых вещей, как драйверы. Однако Delphi является универсальной средой программирования и позволяет создавать ПО, ориентированное на любые задачи. В данной статье рассматривается создание драйвера средствами Delphi.

Авторы:
Геннадий Порев

Аннотация:
Впервые показана принципиальная возможность создания исполняемых модулей подсистемы Windows native (в том числе и драйверов устройств) в среде Borland Delphi.

Статья очень интересная, спасибо. Еще одно доказательство, что возможности человека безграничны.
Только вот хотелось бы, чтобы результатом работы был бы не драйвер в 40 строк, а что-то типа фильтра файловой системы. Или kernel-mode Firewall. Пожалуйста, напишете такое на Делфи.
А потом сравним, кто столько затратил на это времени и сил: Вы с Делфи и я с DDK/C++. А до тех пор, пока все остается на уровне "Hello World" ни о каком серьезном анализе достоинств/недостатков говорить пока рано.

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Как насчет VxD?

Пример создания VxD-драйвера на Delphi

Приветствую дискутирующих!

MT>Что касается необходимости и уместности. Я считаю что средства разработки для native subsystem на основе паскального синтаксиса до этого момента не существовали, не смотря на то, что популярность деривативов паскаля в данный момент не меньше, а в некоторых отраслях рынка и больше чем деривативов C. Поэтому данной статьей я просто закрыл некоторую досадную прореху в ассортименте средств разработки.

Рискну вызвать волну флейма, но деривативы Паскаля — понятие более чем абстрактное. Нет смысла говорить об абстрактной популярности языка, а лишь о его популярности ДЛЯ. Для решения определенного круга задач. Как уже неоднократно отмечалось, человек, программирующий задачу на данном языке, несмотря на то, что он (язык) для нее не подходит, делает ошибку либо подчиняется обстоятельствам. Это не к тому, что Delphi не подходит для написания драйверов, это лишь довод в пользу классификации по сферам применения.
Так вот, конкретно Delphi совершенно справедливо позиционируется как RAD-среда, причем с выраженным акцентом на "прикладной" смысл слова Application. В основном это выражается в быстром проектировании пользовательского интерейса, хотя и не только.

Из-за обилия неконтролируемых или, что не лучше, принципиально контролируемых, но недокументированных действий, Делфи не очень хорошо подходит для задач, в которых нужно, чтобы программа делала ровно то-то и то-то. Применять Делфи для создания драйверов — это по продуктивности то же самое, что применять Делфи без VCL и визуального проектирования. То есть — я рискну и попытаюсь навязать свое мнение читающим — в этом случае вместо Делфи вполне можно юзать любой компилер, хоть тот же FPC. Причем этот другой компилер может даже расширять язык более выгодно для программиста, чем Delphi.
Ну и потом, о вкусах не спорят, так что тут я ни на чем не настаиваю, но лично мне гораздо больше нравится C++, и я бы писал исключительно на нем, если бы для него существовала нормальная RAD-среда хотя бы для проектирования GUI (Билдер — не нормальная). И возможности языка не в пример шире, это факт.

Короче говоря, незачем делать припарки мертвому — Делфи подходит для написания драйверов по крайней мере немного меньше, чем C++. Тогда зачем упираться и делать это на Делфи?

Но! Все выше сказанное вовсе не означает бессмысленность исследования. Важен сам поиск решения, методика, — ведь она может оказаться полезной при решении других проблематичных ситуаций. Ну и, безусловно, вопрос принципа тоже не последний: теперь Делфи применим еще в одной нише, что делает его более универсальным, чем обычно считается.

С уважением,
Slicer

Здравствуйте, 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>Но! Все выше сказанное вовсе не означает бессмысленность исследования. Важен сам поиск решения, методика, — ведь она может оказаться полезной при решении других проблематичных ситуаций. Ну и, безусловно, вопрос принципа тоже не последний: теперь Делфи применим еще в одной нише, что делает его более универсальным, чем обычно считается.

О чём и речь

Здравствуйте, Аноним, Вы писали:

MT>>В целом согласен. Но. Целью данного материала являлось лишь показать принципиальную возможность. Застолбить первенство на непаханом поле, обеспечить приоритет, как это принято в научном мире. В данный момент последующая жизнь этой отрасли под моим руководством весьма сомнительна — временных ресурсов катастрофически не хватает. Но если найдутся энтузиасты, всё же пусть на одном из первых кирпичиков там будет надпись — "Здесь был я"

MT>>Собственно, никаких более масштабных целей этой публикацией я не преследовал.

А>В который раз видим, что миром правит тщеславие
А>Простите, но прореха в средствах разработки драйверов, о которой Вы говорите, на самом деле куда больше, чем кажется. Не так сложно написать драйвер, как отладить его. И тут уж гораздо бОльшим подспорьем был бы каой-то фреймворк с хорошими возможностями протоколирования, поиска ошибок. И вообще замечательно, если бы ыэтот фреймворк перегружал драйвер без перезагрузки системы на любой разновидности Windows.

Необходимость ребута системы зависит только от класса драйвера, и никаким образом от фреймворка . И кроме того, Вы же понимаете особенности драйверостроения : какая-нибудь ошибочка и — BSOD. Отлаживают драйвера SoftICE'ом и это правильно. Дублировать его функциональность я не считаю нужным, да и возможным для себя в разумные сроки .

А>И, поверьте старому маразматику, никто не вспомнит того кирпича, на котором было написано "Здесь был я, MouseTail", ибо было это один раз и вначале. А если Вы напишете толковый фреймворк — его будут видеть ежедневно на экране тысячи программистов и говорить: "крутую фичу замутил этот MouseTail".
А>Соразмеряйте усилия

Насчёт "никто не вспомнит" это Вы преувеличиваете. Конечно, Уильям Генри Гейтс III — персонаж более известный, чем Марк Збиковский, однако же количеству автографов последнего по всему миру можно только позавидовать, не так ли?

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

MT>>Могу Вас заверить, что вдумчивое чтение MSDN помогает в программировании для сетей заметно больше И, честно говоря, разработка собственной невизуальной RTL очень сильно сократила мне время на решение многих типовых задач такого плана.

AG>Я не любитель Delphi/Pascal и не сторонник перевода заголовков DDK на паскаль, просто потому, что сам давно ушел от Deplhi к MS VS и не перестаю регулярно убеждаться в его (Delphi/Pascal) ущербности. Я считаю, что Delphi — для ваятелей форм, а ести ты хочешь написать что-то системное-используй для этого профессиональную среду и язык.

Вы только что очень наглядно продемонстрировали именно то заблуждение, про которое и была написана данная статья . Знаете, я уже очень давно не ваял никаких форм на дельфях, а пишу всё время совершенно, как вы говорите, "системные" вещи. И я уверен, что у Вас на студии решение моих задач займёт не меньше времени и не меньше кода, чем у меня, а "профессиональность" языка тут вообще ни при чём.

AG>Sorry, если обидел любителей паскаля- я не нарочно, честно

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

>>> Ведь не станете же вы разрабатывать математическое ПО, скажем на
>>> Прологе?
>>> Или закручивать гвоздь отверкой?
>> Если добавлю к отвёртке соответствующую металлическую деталь для
>> забивания гвоздей, то вполне можно.

SA>Еще раз, речь идет не о гипотетической/реальной возможности сделать это. А
SA>о целесообразности сего действа.
SA>Вы начнете разрабатывать металлическую деталь, потом будете прикреплять ее
SA>к отвертке, потом займетесь ее отладкой, и только после этого забьете
SA>гвоздь "отверткой".
SA>А Вася Пупкин возьмет проверенное временем, отлаженное и надежное средство
SA>для забивания гвоздей — молоток. И потратит на это пару секунд. Чего не
SA>скажешь о вас.

Мне сложно спорить с фанатиками.
Я только замечу, что если бы все люди думали так как Вы, мы бы до сих пор сидели в проверенных временем пещерах, жгли отлаженные костры и пользовались надёжными дубинками. Ведь совершенно очевидно, что для того что бы убить медведя, нужно 3-4 крепких мужика с дубинками и камнями и пару минут. И абсолютно незачем тратить столетия на освоение металлургии и оружейного дела, так как это безусловно нецелесообразное действо.

Как насчет VxD? Я помню, что один мой знакомый, Евгений Безверхий, написал переходник форматов, который в итоге позволял строить VxD.

Slicer

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Как насчет VxD? Я помню, что один мой знакомый, Евгений Безверхий, написал переходник форматов, который в итоге позволял строить VxD.

Для построения VxD есть очень похожий способ, и переходник форматов там не нужен.

Здравствуйте, Геннадий Порев, Вы писали:

ГП>Впервые показана принципиальная возможность создания исполняемых модулей подсистемы Windows native

Прочитал. В общем-то никогда и не сомневался, хотя и никогда не делал. Жаль только, что верхняя планка D3. Больно вкусная D7 в работе.

Видимо, в Борланд посчитали, что служб NT будет достаточно.

Здравствуйте, Геннадий Порев, Вы писали:

ГП>Статья:


ГП>Авторы:
ГП> Геннадий Порев

ГП>Аннотация:
ГП>Впервые показана принципиальная возможность создания исполняемых модулей подсистемы Windows native (в том числе и драйверов устройств) в среде Borland Delphi.


Относительно впервые — см. хотя бы http://infocity.kiev.ua/prog/delphi/content/delphi004.phtml?id=571
Здесь перепечатка — но оригинальный материал я видел еще примерно года три назад — сделайте поиск в том же гугле по фразе "Пример создания VxD-драйвера на Delphi" — несколько сотен ссылок.

К сожалению, полная версия статьи мне пока недоступна, но все же рискну предположить, что делается
подменяем делфийского ртл, долго и нудно переводятся хидера, делаются какие-то шаманские действия с полученными obj, чтобы скормить майкрософтовскому линкеру.. Спрашивается, зачем же все это, и насколько уместен здесь сам Делфи?

Зы. Все-же попытаюсь отыскать полную версию статьи, может где в столицах и журнал приобрету..


... Эта

Здравствуйте, 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. Поэтому данной статьей я просто закрыл некоторую досадную прореху в ассортименте средств разработки.

Здравствуйте, 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, все время занимаюсь разработкой.

>> что делает эту статью всё же оригинальным материалом, носящим титул "впервые показано" вполне заслуженно.

IO>хм, может и так, если рассматривать все же в контексте NT..

Как вы знаете, понятие Windows Native Subsystem имеет смысл только в таком контексте.

MT>>Что касается необходимости и уместности. Я считаю что средства разработки для native subsystem на основе паскального синтаксиса до этого момента не существовали, не смотря на то, что популярность деривативов паскаля в данный момент не меньше, а в некоторых отраслях рынка и больше чем деривативов C. Поэтому данной статьей я просто закрыл некоторую досадную прореху в ассортименте средств разработки.

IO>здесь у меня несколько иное мнение. При написания драйвера используется в большинстве случаев ограниченное подмножество синтаксиса и возможностей си (рассматривем вариант работы только с ддк, а не со всякими навороченными библиотеками,например, от того же numega, которые начинающему не так помогают, как мозги запудривают). ТО минимальное подмножество си в случае необходимости человек, даже не знающий си довольно быстро осваивает. Я думаю, что если человек с нуля (и без знания си) начинает приобщаться к драйверописанию, то с тех времменых затрат, что ему нужно провести на усвоение идеологии драйверной модели, особенностей апи режима ядра и собственно на борьбу с си, доля последней состоавляющей ничтожно мала. И занимает намного меньше времени, чем пойдет хотя бы на преобразование минимального набора хидеров.. Я, кстати, проходил похожий путь — ибо я делфиец, а с си работал более восьми лет назад, и то очень мало, более в плане хобби (справедливости ради все же можно сказать, что при работе с делфи, си все же на уровне рид-онли примеров с мсдн поддерживался). Но все же можно сказать, что при написании своего первого драйвера мне пришлось си начинать почти с нуля. Так вот, проблем с си почти не было, если сравнивать с теми проблемами, которые возникали при изучении идеологии и частично апи режима ядра..
IO> То есть если говорить коротко — Ваше изыскание может и интересно чисто в теоритическом плане, но пользы в практической работе — я все же думаю — никакой.. Да, на всякий случай — при программировании для win32 (в т.ч. системном) я однозначно даю предпочтение делфи, отыт профессиональной работы с pascal/delphi — где-то года с 1989, все время занимаюсь разработкой.

Как я понял, основное препятствие, по-Вашему, отсутствие переведённых хидеров. Но ведь работа не стоит на месте... Они появятся очень скоро

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

MT>Как я понял, основное препятствие, по-Вашему, отсутствие переведённых хидеров. Но ведь работа не стоит на месте... Они появятся очень скоро

Нет, не только, и далеко не в первую очередь. Извините за прямоту — Вы не очень внимательно читаете.

К тому же я не упоминал совершенно очевидных вещей, например, вопросов поддержки и сопровождения.

Да, еще. На всякий случай — в wxp ddk суммарный объем хидеров примерно 9 мегабайт.. Это относительно "появятся очень скоро".

Еще. Я, конечно, понимаю, что я не вправе давать Вам советы, но все же рискну, скажем так, высказать одну мысль.. Вы, безусловно, талантливый исследователь. И могли бы найти более полезную сферу для исследований.. Хотя, здесь можно маленькую оговорку сделать.. Если Вы планируете написать какую-то книгу по соотв. тематике, либо преподаете соотв. курс в каком-то ВУЗе — то Ваши изыскания может и имеют смысл.. Но даже в таком случае желательно немного по иному раставить акценты в обнародованных материалах.

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

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

MT>>Как я понял, основное препятствие, по-Вашему, отсутствие переведённых хидеров. Но ведь работа не стоит на месте... Они появятся очень скоро

IO>Нет, не только, и далеко не в первую очередь. Извините за прямоту — Вы не очень внимательно читаете.

По поводу остального я не нашёл, что возразить

IO>К тому же я не упоминал совершенно очевидных вещей, например, вопросов поддержки и сопровождения.

Это зависит от того, реализуется ли эта идея в коммерческий продукт или в какой-нибудь опенсорс на энтузиастах... Варианты есть.

IO>Да, еще. На всякий случай — в wxp ddk суммарный объем хидеров примерно 9 мегабайт.. Это относительно "появятся очень скоро".

А Вы думаете, что я их вручную собрался переводить?

IO>Еще. Я, конечно, понимаю, что я не вправе давать Вам советы, но все же рискну, скажем так, высказать одну мысль.. Вы, безусловно, талантливый исследователь. И могли бы найти более полезную сферу для исследований.. Хотя, здесь можно маленькую оговорку сделать.. Если Вы планируете написать какую-то книгу по соотв. тематике, либо преподаете соотв. курс в каком-то ВУЗе — то Ваши изыскания может и имеют смысл.. Но даже в таком случае желательно немного по иному раставить акценты в обнародованных материалах.

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

Собственно, никаких более масштабных целей этой публикацией я не преследовал.

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



MT>Это зависит от того, реализуется ли эта идея в коммерческий продукт или в какой-нибудь опенсорс на энтузиастах... Варианты есть.

ну не верю я, не верю

IO>>Да, еще. На всякий случай — в wxp ddk суммарный объем хидеров примерно 9 мегабайт.. Это относительно "появятся очень скоро".

MT>А Вы думаете, что я их вручную собрался переводить?

как человек, немного переводивший хидера, я думаю, что задача полностью автоматизировать этот процесс далеко не тривиальная.

IO>>Еще. Я, конечно, понимаю, что я не вправе давать Вам советы, но все же рискну, скажем так, высказать одну мысль.. Вы, безусловно, талантливый исследователь. И могли бы найти более полезную сферу для исследований.. Хотя, здесь можно маленькую оговорку сделать.. Если Вы планируете написать какую-то книгу по соотв. тематике, либо преподаете соотв. курс в каком-то ВУЗе — то Ваши изыскания может и имеют смысл.. Но даже в таком случае желательно немного по иному раставить акценты в обнародованных материалах.

MT>В целом согласен. Но. Целью данного материала являлось лишь показать принципиальную возможность. Застолбить первенство на непаханом поле, обеспечить приоритет, как это принято в научном мире. В данный момент последующая жизнь этой отрасли под моим руководством весьма сомнительна — временных ресурсов катастрофически не хватает. Но если найдутся энтузиасты, всё же пусть на одном из первых кирпичиков там будет надпись — "Здесь был я"

MT>Собственно, никаких более масштабных целей этой публикацией я не преследовал.

есть очень много принципиальных возможностей, но не все они целесообразны.. Вспомнил один полупохабный анекдот околомедицинской тематики с соотв. идеей.. Но не буду .

На всякий случай — я ссылку на эту веточку дал одному человеку — человеку, кстати, очень высокой квалификации — он говорил, что с похожей идеей (присособить делфи для разработки модулей режима ядра) он носился уже давно — может он и посчитает нужным войти в контакт с Вами. А может и нет .

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

MT>>Это зависит от того, реализуется ли эта идея в коммерческий продукт или в какой-нибудь опенсорс на энтузиастах... Варианты есть.
IO>ну не верю я, не верю

Чему именно Вы не верите?

IO>>>Да, еще. На всякий случай — в wxp ddk суммарный объем хидеров примерно 9 мегабайт.. Это относительно "появятся очень скоро".
MT>>А Вы думаете, что я их вручную собрался переводить?
IO>как человек, немного переводивший хидера, я думаю, что задача полностью автоматизировать этот процесс далеко не тривиальная.

Но и полностью вручную это делать тоже не обязательно. А также не обязательно переводить все хидеры.

Хорош пример

>Компиляция данного примера возможна только с Delphi 3. Delphi 2 не был опробован в связи с его отсутствием, объектные фалы созданные Delphi 4 отвергаются Microsoft ® Linker 5.12.8181 как файлы неизвестного формата.

Мило, ничего не скажешь. Небось из-за COMDEF-записей и отвергаются "фалы". Я уж как-нибудь буду на D6 или D7 писать

А насчет того, что я написал — переходник был нужен вроде бы именно для вырезания несовместимых записей в OBJ, тогда и уродовать RTL не надо. Впрочем, подробный отзыв напишу, только когда увижу журнал. Пока не прислали, и даже не запрос не ответили.

Slicer

Здравствуйте, 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

Здравствуйте, 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++!

Это кому как. Я ж уже приводил свой тезис на эту тему.

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


MT> Если взять обычного программера, владеющего в достаточной мере, допустим, Delphi, BCB, MSVC и т.п. и поставить перед ним такое ТЗ, то он для реализации выберет Delphi в последнюю очередь. Всё потому, что Delphi окружена целой стеной мифов и предрассудков, порождённых гуёвыми мышевозильщиками и бросателями компонентов на формы.


Хм. А почему такая увереность за всех. Я, кстати, для аналогичной задачи выбрал бы делфи.
На си проект делал бы только в том случае, если бы заказчик очень настаивал. И то, после повышения расценок.

Да, но самолеятельностью с подменой RTL я бы не занимался. Хотя бы потому, что на полке стоят не до конца проработанные A.Jones,J. Ohlund, D. Iseminger. Чтение последних заметно больше пользы приносит для программирования сетей в Делфи, чем переработка RTL.

Здравствуйте, 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

Hello MouseTail, you wrote:

> Давайте всё же будем рассматривать языки, имеющие примерно равные
> возможности... На Прологе вы сможете написать win32-сервис?

Так вы языки сравниваете, или же компиляторы?

--
Всего хорошего, Слава

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Хорош пример

>>Компиляция данного примера возможна только с Delphi 3. Delphi 2 не был опробован в связи с его отсутствием, объектные фалы созданные Delphi 4 отвергаются Microsoft ® Linker 5.12.8181 как файлы неизвестного формата.

SM>Мило, ничего не скажешь. Небось из-за COMDEF-записей и отвергаются "фалы". Я уж как-нибудь буду на D6 или D7 писать

SM>А насчет того, что я написал — переходник был нужен вроде бы именно для вырезания несовместимых записей в OBJ, тогда и уродовать RTL не надо. Впрочем, подробный отзыв напишу, только когда увижу журнал. Пока не прислали, и даже не запрос не ответили.

SM>Slicer

ну во-первых сейчас линкер в поставке ХР ДДК 7.00.9210
во-вторых он имеет оч много разных опций
ну и в третьих надобы конкретно узнать, чего ему не хватает.

могет и возможно сделать спецтулзу для патча дельфовых обжей.
всежтаки иде от 7-го рулит!

и еще — когда на выложат полный вариант?
когда выйдет след номер, т.е. после нового года ?

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

>> Давайте всё же будем рассматривать языки, имеющие примерно равные
>> возможности... На Прологе вы сможете написать win32-сервис?

SA>Так вы языки сравниваете, или же компиляторы?

Я комментирую не совсем корректное сравнение Delphi и Пролога.

Здравствуйте, Slicer [Mirkwood], Вы писали:

MT>>Давайте всё же будем рассматривать языки, имеющие примерно равные возможности... На Прологе вы сможете написать win32-сервис? Или, скажем, user-mode sniffer/firewall? Наверное, нет. А среди равных по возможностям языков выдвинутый мною тезис вполне справедлив.
SM>Спору нет, какие-то задачи из подобных (т.е. написания драйверов, сервисов etc.) я решу на C++ не быстрее, чем на Delphi. А какие-то — быстрее. И красивее. Или вот взять ту же разработку игр.

Вы знаете, я очень часто в подобных дискуссиях слышу ссылки на разработку игр... До тех пор, пока очередной сторонник С\С++ не узнает, какие из достаточно известных игр были написаны на Delphi

SM>К сожалению, какие-то — медленнее, потому что, несмотря на весь потенциал C++, дурная поддержка COM — самое слабое, на мой взгляд, место в этом языке. Так что я бы свел результаты сравнения языков к формуле выбора: либо красиво решенная работа с COM и интерфейсами, либо наличие шаблонов. Все остальное — мелочи.

Собственно, об этом я уже говорил несколько сообщений назад, в ответ на заявление об "очевидном факте" — количество недостатков и достоинств у них примерно одинаково и взаимно скомпенсировано

MT>>Вы таки хотите поднять волну флейма? Придумайте, пожалуйста, аналоги для WITH, SET, AS, IN, PROPERTY, модификаторам CONST/VAR/OUT, или скажем для INTERFACE (который тип), ARRAY OF. Продолжать?
SM>Для with аналога действительно нет, это минус, но — совсем малюсенький, из-за возможности объявлять локальные переменные где угодно в коде.

Ну нифига себе однако. Знаете, как оно задалбывает — постоянно копи-пастить при заполнении полей какой-нибудь структуры вроде MIB_IFROW ?

SM>Set вроде уже воспроизведен (-но?) хотя бы в Builder, да и потом — в подавляющем большинстве случаев он (оно) равноценен набору констант.

Ну да По вашему запись вида

((ClassRoom&&Vasya)!=0)&&((ClassRoom&&Petya)!=0)

более очевидна, чем

((Vasya in ClassRoom) and (Petya in ClassRoom))

? Даже если в машинных кодах это совершенно одно и то же.

SM>Property, из моего опыта в последнее время, приносит больше вреда, чем пользы, как раз из-за скрытых от программиста действий: то ли мы просто получаем значения поля, то ли вызывается какой-то метод...

Хм. А вас не пугает скрытость от программиста действий некоторой функции, которую вы вызываете????

Ведь как раз в этих двух возможностях и состоит прелесть механизма свойства — разделения процессов чтения и записи свойства (соответственно, возможность создания как ReadOnly так и WriteOnly свойств) и прозрачность процесса обращения к свойству, как к полю, вне зависимости от того, что на самом деле происходит при этом. Называть это недостатком может только тот, кто не понимает преимущества такого подхода Я уж молчу про default, stored, published и прочих вкусностях свойств.

SM>CONST/VAR/OUT... Для const и var долго искать не надо, причем их смысл в C++ не в пример очевиднее,

Да, знаете в чём эта очевидность? Для констатнтых параметров передаётся само значение, а для переменных — указатель на область памяти, где находится переменная. Причём "указательность" параметра порой настолько неочевидна что приходится рыться в туевой хуче typedef'ов, выискивая что же это за тип на самом деле передаётся. В этом смысле непосредственный модификатор обьявления параметра куда как нагляднее.

SM> чем в Delphi (я о счетчиках ссылок и проч.),

Минуточку. О каких таких счётчиках ссылок идёт речь?

SM> с Out сложнее, его и правда до сих пор нет.

Жаль, а я думал что Вы напишете что-то вроде "Очищать переменную можно и прямо в коде и незачем для этого придумывать модификатор".

SM>Array of... А чем так плохи STL-контейнеры? Скажете, это не часть языка? Да, но это часть стандарта Если уж придираться к словам, то — да, этого в C++ нет. Хотя опять же можно красиво реализовать.

Да реализовать можно всё, что угодно. Даже, например, такую совершенно безобидную вещь как нумерацию массивов не с 0. Я был просто потрясён однажды .

Ладно, а вот вам ещё задачка.

Как вот это записать в синтаксисе С\С++ ?

var BasePtr : Pointer;
    OffSet : Cardinal;
...
Result:=Pointer(Cardinal(BasePtr)+OffSet);

SM>>> Еще что-то можно сделать возможным, введя базовый класс и потребовав у всех от него наследоваться.
MT>>Это костыль, вы же понимаете. Введением класса можно добиться любой функциональности, которой нет в языке, но это доказывает лишь то, что такой функциональности нет в языке.
SM>Но язык построен так, что она воспроизводима в его рамках,

Так построен любой нормальный язык высокого уровня! В том числе и Delphi, конечно. А то так можно договориться и до того, что ООП и прочие фишки вполне реализуемы средствами чистого ассемблера. Конечно реализуемы, но ведь удобнее иметь это уже в реализации самого языка.

MouseTail

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

MT>> Если взять обычного программера, владеющего в достаточной мере, допустим, Delphi, BCB, MSVC и т.п. и поставить перед ним такое ТЗ, то он для реализации выберет Delphi в последнюю очередь. Всё потому, что Delphi окружена целой стеной мифов и предрассудков, порождённых гуёвыми мышевозильщиками и бросателями компонентов на формы.
IO>Хм. А почему такая увереность за всех. Я, кстати, для аналогичной задачи выбрал бы делфи.
IO>На си проект делал бы только в том случае, если бы заказчик очень настаивал. И то, после повышения расценок.

Ну я очень рад за Вас

IO>Да, но самолеятельностью с подменой RTL я бы не занимался. Хотя бы потому, что на полке стоят не до конца проработанные A.Jones,J. Ohlund, D. Iseminger. Чтение последних заметно больше пользы приносит для программирования сетей в Делфи, чем переработка RTL.

Могу Вас заверить, что вдумчивое чтение MSDN помогает в программировании для сетей заметно больше И, честно говоря, разработка собственной невизуальной RTL очень сильно сократила мне время на решение многих типовых задач такого плана.

Hello MouseTail, you wrote:

> Вы знаете, я очень часто в подобных дискуссиях слышу ссылки на
> разработку игр... До тех пор, пока очередной сторонник С\С++ не узнает,
> какие из достаточно известных игр были написаны на Delphi

Поделитесь, плиз, информацией.

--
Всего хорошего, Слава

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

SM>>CONST/VAR/OUT... Для const и var долго искать не надо, причем их смысл в C++ не в пример очевиднее,
MT>Да, знаете в чём эта очевидность? Для констатнтых параметров передаётся само значение, а для переменных — указатель на область памяти, где находится переменная. Причём "указательность" параметра порой настолько неочевидна что приходится рыться в туевой хуче typedef'ов, выискивая что же это за тип на самом деле передаётся. В этом смысле непосредственный модификатор обьявления параметра куда как нагляднее.
Пардон, но при чем тут Typedef? Речь о

int func(const int& i);

MT>Как вот это записать в синтаксисе С\С++ ?

MT>

MT>var BasePtr : Pointer;
MT>    OffSet : Cardinal;
MT>...
MT>Result:=Pointer(Cardinal(BasePtr)+OffSet);
MT>

Гм. А в чем прикол?

return BasePtr+OffSet;

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

MT>Вы знаете, я очень часто в подобных дискуссиях слышу ссылки на разработку игр... До тех пор, пока очередной сторонник С\С++ не узнает, какие из достаточно известных игр были написаны на Delphi
Наверное, писали такие же фанатичные (скорее в положительном смысле) товарищи, как Вы. Это не выпад, это констатация возможности, основываясь на Вашем примере

SM>>К сожалению, какие-то — медленнее, потому что, несмотря на весь потенциал C++, дурная поддержка COM — самое слабое, на мой взгляд, место в этом языке. Так что я бы свел результаты сравнения языков к формуле выбора: либо красиво решенная работа с COM и интерфейсами, либо наличие шаблонов. Все остальное — мелочи.
MT>Собственно, об этом я уже говорил несколько сообщений назад, в ответ на заявление об "очевидном факте" — количество недостатков и достоинств у них примерно одинаково и взаимно скомпенсировано
Количество, но не качество. В Delphi удобнее синтаксис работы с интерфейсами, но если вам при всех этих красивостях ни разу не приходилось вызывать _AddRef и _Release, просто "для гарантии", что очередная версия Delphi не сделает код нерабочим, изменив механизм инкремента-декремента ссылок на интерфейс при входе в функцию, причем и так разный при передаче по var, сonst, out и просто так, я буду удивлен. На одном синтаксисе далеко не уедешь. Впрочем, согласен, можно попробовать включить в сферу применимости Delphi еще и жесткую работу с IDispath (помимо создания UI). Обычно, правда, все юзают раннее связывание, а с ним в C++ все не так глухо.

MT> Ну нифига себе однако. Знаете, как оно задалбывает — постоянно копи-пастить при заполнении полей какой-нибудь структуры вроде MIB_IFROW ?

CMyObject* pMyObj = MyRoot->MyFn()->MyContainer->ContainedObject;
pMyObj->DoSmth();
pMyObj->DoSmthElse()

И никаких глюков с указателями, которыми изобилует With Или пастить "pMyObj->" тоже напрягает? Генацвале, а макрокоманды на что? Если их можно успешно юзать в Delphi, почему не пользоваться ими в Visual C++? (Не путать с макросами, которые, кстати, в Delphi реализованы УЖАСНО). Написали без копипастов, потом нажали n раз и получили требуемое. Это скорее мелкий недостаток, нежели существенный.

SM>>Set вроде уже воспроизведен (-но?) хотя бы в Builder, да и потом — в подавляющем большинстве случаев он (оно) равноценен набору констант.
MT>Ну да По вашему запись вида... [skipped] Даже если в машинных кодах это совершенно одно и то же.
Нет, я имею в виду что-то из объявлений функций в D7 в хелпе, там есть билдерский вариант и интересное словечко Set в названии типов; сам я в билдере не работал, Вы, похоже, тоже — раз это написали. Так что тут вопрос остается открыт. Если что — можно написать свой Set; а есть, кстати, битовый контейнер из STL (остается прописать константы для индексов). Насчет своего set — будете говорить, что написать можно что угодно. Но — см. последний пункт — многие вещи, которые на Delphi написать, безусловно, можно, будут либо неуниверсальны, либо чужеродно смотреться среди остальных конструкций языка. Опять же возвращаюсь к наиболее яркому примеру "шаблонов" путем инклудов.

SM>>Property, из моего опыта в последнее время, приносит больше вреда, чем пользы, как раз из-за скрытых от программиста действий: то ли мы просто получаем значения поля, то ли вызывается какой-то метод...
MT>Хм. А вас не пугает скрытость от программиста действий некоторой функции, которую вы вызываете????
Обычно нет, т.к. я знаю, что это функция. Впрочем, на самом деле я так не думаю Просто со зла сорвалось: как раз недавно с этим мучился. А вообще, стоит раз и навсегда положить, что чтение свойства — это вызов функции, которая делает еще что-то (например, опрашивает API). Хотя для многих свойств было бы приятно быть уверенным, что их чтение — это простое чтение поля, и не извращаться с потокобезопасностью.

SM>>CONST/VAR/OUT... Для const и var долго искать не надо, причем их смысл в C++ не в пример очевиднее,
MT>Да, знаете в чём эта очевидность? Для констатнтых параметров передаётся само значение, а для переменных — указатель на область памяти, где находится переменная. Причём "указательность" параметра порой настолько неочевидна что приходится рыться в туевой хуче typedef'ов, выискивая что же это за тип на самом деле передаётся. В этом смысле непосредственный модификатор обьявления параметра куда как нагляднее.
Уже ответили А вот в Delphi, где передача объекта по const вовсе не означает константности объекта, зато передача по var почему-то автоматом правит счетчик ссылок, очевидностью и не пахнет.

Я, кстати, забыл злобно пнуть отстутствие статических объектов в Delphi — точнее, отсутствие их автодеструкции. Try-Finally вечно нарушает логику "абзацных" отступов (indentation).

SM>> чем в Delphi (я о счетчиках ссылок и проч.),
MT>Минуточку. О каких таких счётчиках ссылок идёт речь?
Как — о каких? Об ANSI- и WideChar- строках, о динамических массивах, об интерфейсах.

SM>> с Out сложнее, его и правда до сих пор нет.
MT>Жаль, а я думал что Вы напишете что-то вроде "Очищать переменную можно и прямо в коде и незачем для этого придумывать модификатор".
Как и в случае с Set, я не пытаюсь утверждать, что замена одной конструкции на другую с потерей семантики — равнозначна. Но без потери — вполне. Явная очистка вместо out — это потеря семантики. А обращение к Set через [] — не &, и уж тем более не && — вполне ее сохраняет.

SM>>Array of... А чем так плохи STL-контейнеры? Скажете, это не часть языка? Да, но это часть стандарта Если уж придираться к словам, то — да, этого в C++ нет. Хотя опять же можно красиво реализовать.
MT>Да реализовать можно всё, что угодно. Даже, например, такую совершенно безобидную вещь как нумерацию массивов не с 0. Я был просто потрясён однажды .
И будет она смотреться вполне естественно. А можно поинтересоваться, как Вы реализуете в Delphi массив с индексом типа double, ограниченным диапазоном от A до B, где A и B задаются? Чтобы доступ автоматом выполнял округление. Разумеется, вы это сделаете!!! Но! Одна запись создаст ссылку на массив, а другая — сам массив (и задаст индексы). В отличие от C, где такой "массив" можно будет объявить статически, хотя бы так: "MyDoubleIndexedArray<MyA,MyB> array;", прямо среди остальных переменных.

MT>Ладно, а вот вам ещё задачка.
MT>Как вот это записать в синтаксисе С\С++ ?

MT>

MT>var BasePtr : Pointer;
MT>    OffSet : Cardinal;
MT>...
MT>Result:=Pointer(Cardinal(BasePtr)+OffSet);
MT>

Итак, вы таки паскалист Как раз-таки гораздо короче это будет именно на C++, и с этим у меня было достаточно мороки, когда я писал здесь, на RSDN, статью о PE-загрузчике. Там через каждые три строки идет такое обращение. Более того, при желании можно наделить BasePtr семантикой указателя на массив, и писать BasePtr[Offset], что иногда выглядит более естественно.

SM>>>> Еще что-то можно сделать возможным, введя базовый класс и потребовав у всех от него наследоваться.
MT>>>Это костыль, вы же понимаете. Введением класса можно добиться любой функциональности, которой нет в языке, но это доказывает лишь то, что такой функциональности нет в языке.
SM>>Но язык построен так, что она воспроизводима в его рамках,
MT>Так построен любой нормальный язык высокого уровня! В том числе и Delphi, конечно. А то так можно договориться и до того, что ООП и прочие фишки вполне реализуемы средствами чистого ассемблера. Конечно реализуемы, но ведь удобнее иметь это уже в реализации самого языка.
В его рамках — это не совсем точно. Имелось в виду — использование рукотворного подобия чего-либо выглядит столь же естественно, как и само это что-то. И я привел выше достаточно типичный пример попытки введения в Delphi нового базового элемента, со вполне очевидными последствиями.

---

Поскольку профессиональная гордость ни одному из нас не позволит признать публично свою неправоту, предлагаю на этом закрыть дискуссию. Это относится ко всем участникам — а то у нас уже давно оффтоп идет

Slicer

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

>> Вы знаете, я очень часто в подобных дискуссиях слышу ссылки на
>> разработку игр... До тех пор, пока очередной сторонник С\С++ не узнает,
>> какие из достаточно известных игр были написаны на Delphi
SA>Поделитесь, плиз, информацией.

Точно знаю про Venom http://www.deep-shadows.com/hax/#Venom

Где-то в fido7.ru.delphi недавно была дискуссия по этому поводу, упоминали несколько известных стратегий. В любом случае, Гугл в помощь

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

MT>Точно знаю про Venom http://www.deep-shadows.com/hax/#Venom
Сходил по ссылке ради интереса.

Language: Microsoft Visual C++ 6.0, Borland Delphi 5.0, Assembler

Так что еще вопрос, какую часть игры писали на Delphi. Возможно, что только меню. Тем более, что с FPU студия работает не в пример лучше.

Slicer

Здравствуйте, Геннадий Порев, Вы писали:

Накопал линкер, который понимает одновременно и OMF от delphi 7 и COFF от MS DDK.
Брать здесь

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

T>Здравствуйте, Геннадий Порев, Вы писали:

T>Накопал линкер, который понимает одновременно и OMF от delphi 7 и COFF от MS DDK.
T>Брать здесь

http://здесь/ — server not found

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

/*Поскипано*/


MT>Могу Вас заверить, что вдумчивое чтение MSDN помогает в программировании для сетей заметно больше И, честно говоря, разработка собственной невизуальной RTL очень сильно сократила мне время на решение многих типовых задач такого плана.

Я не любитель Delphi/Pascal и не сторонник перевода заголовков DDK на паскаль, просто потому, что сам давно ушел от Deplhi к MS VS и не перестаю регулярно убеждаться в его (Delphi/Pascal) ущербности. Я считаю, что Delphi — для ваятелей форм, а ести ты хочешь написать что-то системное-используй для этого профессиональную среду и язык.

Sorry, если обидел любителей паскаля- я не нарочно, честно

MT>В целом согласен. Но. Целью данного материала являлось лишь показать принципиальную возможность. Застолбить первенство на непаханом поле, обеспечить приоритет, как это принято в научном мире. В данный момент последующая жизнь этой отрасли под моим руководством весьма сомнительна — временных ресурсов катастрофически не хватает. Но если найдутся энтузиасты, всё же пусть на одном из первых кирпичиков там будет надпись — "Здесь был я"

MT>Собственно, никаких более масштабных целей этой публикацией я не преследовал.

В который раз видим, что миром правит тщеславие
Простите, но прореха в средствах разработки драйверов, о которой Вы говорите, на самом деле куда больше, чем кажется. Не так сложно написать драйвер, как отладить его. И тут уж гораздо бОльшим подспорьем был бы каой-то фреймворк с хорошими возможностями протоколирования, поиска ошибок. И вообще замечательно, если бы ыэтот фреймворк перегружал драйвер без перезагрузки системы на любой разновидности Windows.
И, поверьте старому маразматику, никто не вспомнит того кирпича, на котором было написано "Здесь был я, MouseTail", ибо было это один раз и вначале. А если Вы напишете толковый фреймворк — его будут видеть ежедневно на экране тысячи программистов и говорить: "крутую фичу замутил этот MouseTail".
Соразмеряйте усилия

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

T>>Накопал линкер, который понимает одновременно и OMF от delphi 7 и COFF от MS DDK.
T>>Брать здесь

MT>http://здесь/ — server not found
Извиняюсь, таки здесь

Hello ArtemGorikov, you wrote:

> Sorry, если обидел любителей паскаля- я не нарочно, честно

Ага. Сначала скажут, что все козлы, а потом: "я не хотел никого обидеть"

ЗЫ: А что вы в этом форуме тогда потеряли, раз на MS VS пишете?

--
Всего хорошего, Слава

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

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

MT>>>Могу Вас заверить, что вдумчивое чтение MSDN помогает в программировании для сетей заметно больше И, честно говоря, разработка собственной невизуальной RTL очень сильно сократила мне время на решение многих типовых задач такого плана.

AG>>Я не любитель Delphi/Pascal и не сторонник перевода заголовков DDK на паскаль, просто потому, что сам давно ушел от Deplhi к MS VS и не перестаю регулярно убеждаться в его (Delphi/Pascal) ущербности. Я считаю, что Delphi — для ваятелей форм, а ести ты хочешь написать что-то системное-используй для этого профессиональную среду и язык.

MT>Вы только что очень наглядно продемонстрировали именно то заблуждение, про которое и была написана данная статья . Знаете, я уже очень давно не ваял никаких форм на дельфях, а пишу всё время совершенно, как вы говорите, "системные" вещи. И я уверен, что у Вас на студии решение моих задач займёт не меньше времени и не меньше кода, чем у меня, а "профессиональность" языка тут вообще ни при чём.

AG>>Sorry, если обидел любителей паскаля- я не нарочно, честно

MT>

Есть тонкий нюанс : мне не надо в студии писать свою RTL, — она уже есть... Кроме того, в C++ есть такие вкусные вещи, как стандартные алгоритмы и контейнеры из STL, куча всяких полезных вещей из ATL, атрибуты (Attributed ATL), перегрузка операторов, встраиваемые (inline) функции, оптимизирующий компилятор, эффективно отсекающий никогда не вызываемые ветви кода, плюс быстрый код с для FPU. Перегрузка операторов, кроме того, позволяет перегрузить стандартные операции типа сложение-вычитание и реализовать их, скажем, на inline asm с MMX и SSE инструкциями. А так — почти одно и то же

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

MT>>>>Могу Вас заверить, что вдумчивое чтение MSDN помогает в программировании для сетей заметно больше И, честно говоря, разработка собственной невизуальной RTL очень сильно сократила мне время на решение многих типовых задач такого плана.
AG>>>Я не любитель Delphi/Pascal и не сторонник перевода заголовков DDK на паскаль, просто потому, что сам давно ушел от Deplhi к MS VS и не перестаю регулярно убеждаться в его (Delphi/Pascal) ущербности. Я считаю, что Delphi — для ваятелей форм, а ести ты хочешь написать что-то системное-используй для этого профессиональную среду и язык.
MT>>Вы только что очень наглядно продемонстрировали именно то заблуждение, про которое и была написана данная статья . Знаете, я уже очень давно не ваял никаких форм на дельфях, а пишу всё время совершенно, как вы говорите, "системные" вещи. И я уверен, что у Вас на студии решение моих задач займёт не меньше времени и не меньше кода, чем у меня, а "профессиональность" языка тут вообще ни при чём.
AG>>>Sorry, если обидел любителей паскаля- я не нарочно, честно
MT>>
AG>Есть тонкий нюанс : мне не надо в студии писать свою RTL, — она уже есть...

Есть ещё более тонкий нюанс. В дельфи тоже не надо писать свою RTL , потому что она тоже уже есть.

То что лично мне понадобилось отказаться от её использования и создавать что-то своё — так это лично мои проблемы, связанные с лично моим стилем проектирования программ.

AG> Кроме того, в C++ есть такие вкусные вещи, как стандартные алгоритмы и контейнеры из STL, куча всяких полезных вещей из ATL,

А в дельфи есть VCL

AG> атрибуты (Attributed ATL), перегрузка операторов, встраиваемые (inline) функции, оптимизирующий компилятор, эффективно отсекающий никогда не вызываемые ветви кода, плюс быстрый код с для FPU. Перегрузка операторов, кроме того, позволяет перегрузить стандартные операции типа сложение-вычитание и реализовать их, скажем, на inline asm с MMX и SSE инструкциями. А так — почти одно и то же

Не хотите ли Вы сказать, что в Delphi нет оптимизирующего компилятора? Или что в последних дельфях нет перегрузки операторов и инлайна?

---

Уважаемый Артём!!!! У меня нет совершенно никакого желания начинать с Вами по стонадцатому кругу бесконечный спор (Delphi-MSVS)!!! Убедить Вас в Вашей слепоте и предвзятости мне не удастся. Убеждать Вас в том, что Delphi круче, я не собираюсь, потому что это неправда. Убедиться самому в том, что MSVS круче я не смогу, потому что это тоже неправда. Мне искренне и до боли жаль тех людей, которые уже много лет пытаются друг друга убедить в крутизне любимых средств разработки, потому что их бесполезный спор идёт в совершенно другой плоскости чем следовало бы. Вот именно сейчас мне просто впадлу перечислить Вам аналогичный список из вещей, которые есть в Delphi, и которые не снились студии. Впадлу потому, что я уже это неоднократно делал и в том числе в этой ветке. Но ещё и потому, что это бесполезно, так как я совершенно уверен, что на качество программирования влияет не средство разработки а только личные таланты программиста, а как называется его IDE — на самом деле до глубокой задницы.

Не провоцируйте меня, пожалуйста.

Hello MouseTail, you wrote:

> Есть ещё более тонкий нюанс. В дельфи тоже не надо писать свою RTL
> , потому что она тоже уже есть.

Есть еще один маленький такой нюанс. Для разработки в той или иной
прикладной области лучше пользоваться теми средствами, которые для этой
области больше подходят:
1) Экономим время
2) Не нужно писать всякие RTL
3) Не нужно переподить заголовки с одного языка на другой (неизбежно
допуская ошибки)
4) Плюс средства отладки предназначенные для этой прикладной области. А
отладка занимает значительно большую часть времени разработки.

Ведь не станете же вы разрабатывать математическое ПО, скажем на Прологе?
Или закручивать гвоздь отверкой?
Да, сделать это ничто не мешает, но какова цена всего этого?

Подводя итог, скажу еще раз: в каждом конкретном случае для разработки
следует выбирать те средства, которые для этого предназначены.

--
Всего хорошего, Слава

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

>> Есть ещё более тонкий нюанс. В дельфи тоже не надо писать свою RTL , потому что она тоже уже есть.

SA>Есть еще один маленький такой нюанс. Для разработки в той или иной
SA>прикладной области лучше пользоваться теми средствами, которые для этой
SA>области больше подходят:
SA>1) Экономим время
SA>2) Не нужно писать всякие RTL
SA>3) Не нужно переподить заголовки с одного языка на другой (неизбежно
SA>допуская ошибки)
SA>4) Плюс средства отладки предназначенные для этой прикладной области. А
SA>отладка занимает значительно большую часть времени разработки.

... или создавать новые средства разработки. Или расширять возможности существующих...

А вообще-то, не хочешь -- не пользуйся

SA>Ведь не станете же вы разрабатывать математическое ПО, скажем на Прологе?
SA>Или закручивать гвоздь отверкой?

Если добавлю к отвёртке соответствующую металлическую деталь для забивания гвоздей, то вполне можно.

SA>Да, сделать это ничто не мешает, но какова цена всего этого?

Это моё личное религиозное предубеждение. Я считаю цену вполне приемлемой.

SA>Подводя итог, скажу еще раз: в каждом конкретном случае для разработки
SA>следует выбирать те средства, которые для этого предназначены.

См. выше.

Hello MouseTail, you wrote:

>> Ведь не станете же вы разрабатывать математическое ПО, скажем на
>> Прологе?
>> Или закручивать гвоздь отверкой?
> Если добавлю к отвёртке соответствующую металлическую деталь для
> забивания гвоздей, то вполне можно.

Еще раз, речь идет не о гипотетической/реальной возможности сделать это. А
о целесообразности сего действа.

Вы начнете разрабатывать металлическую деталь, потом будете прикреплять ее
к отвертке, потом займетесь ее отладкой, и только после этого забьете
гвоздь "отверткой".
А Вася Пупкин возьмет проверенное временем, отлаженное и надежное средство
для забивания гвоздей — молоток. И потратит на это пару секунд. Чего не
скажешь о вас.

--
Всего хорошего, Слава

Hello MouseTail, you wrote:

> Мне сложно спорить с фанатиками.

Симметрично
Вы упорно продолжаете утверждать что Дельфи круче всех, и подходит для
разработки драйверов.
Я же утверждаю, что на ней можно писать драйверы, но это менее эффективно
чем в специализированных средствах разработки.
И еще, Дельфи мне очень нравится, а C++ нет. Однако я не зацикливаюсь на
ней, и под каждую задачу стараюсь использовать то средство, которое более
эффективно.

> Я только замечу, что если бы все люди думали так как Вы, мы бы до сих
> пор сидели в проверенных временем пещерах, жгли отлаженные костры и
> пользовались надёжными дубинками.

Вы путаете совершенствование уже отлаженных и проверенных временем средств
с попытками из отвертки сделать молоток.

> И абсолютно незачем тратить столетия на освоение металлургии и
> оружейного дела, так как это безусловно нецелесообразное действо.

Перечитайте мои сообщения внимательней. Я не против эволюции средств
разработки, я против их применения не по назначению, когда это доставляет
больше минусов, чем плюсов.

--
Всего хорошего, Слава

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

SA>Симметрично
SA>Вы упорно продолжаете утверждать что Дельфи круче всех,

Это — неправда. Я такого нигде не утверждал .

SA> и подходит для разработки драйверов.

Конечно подходит, я же это наглядно показал

SA>Я же утверждаю, что на ней можно писать драйверы, но это менее эффективно чем в специализированных средствах разработки.

Появляющиеся средства очень часто бывают недостаточно эффективными.

SA>И еще, Дельфи мне очень нравится, а C++ нет. Однако я не зацикливаюсь на
SA>ней, и под каждую задачу стараюсь использовать то средство, которое более
SA>эффективно.

Я тоже не зацикливаюсь Может у меня задачи такие?

>> Я только замечу, что если бы все люди думали так как Вы, мы бы до сих
>> пор сидели в проверенных временем пещерах, жгли отлаженные костры и
>> пользовались надёжными дубинками.
SA>Вы путаете совершенствование уже отлаженных и проверенных временем средств
SA>с попытками из отвертки сделать молоток.

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

>> И абсолютно незачем тратить столетия на освоение металлургии и
>> оружейного дела, так как это безусловно нецелесообразное действо.
SA>Перечитайте мои сообщения внимательней. Я не против эволюции средств
SA>разработки, я против их применения не по назначению, когда это доставляет
SA>больше минусов, чем плюсов.

Плюсы и минусы — понятие относительное к конкретному программисту. А грань между эволюцией и применением не по назначению настолько тонка, что видна может быть только далёким потомкам

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

AT>Статья очень интересная, спасибо. Еще одно доказательство, что возможности человека безграничны.
AT>Только вот хотелось бы, чтобы результатом работы был бы не драйвер в 40 строк, а что-то типа фильтра файловой системы. Или kernel-mode Firewall. Пожалуйста, напишете такое на Делфи.
AT>А потом сравним, кто столько затратил на это времени и сил: Вы с Делфи и я с DDK/C++. А до тех пор, пока все остается на уровне "Hello World" ни о каком серьезном анализе достоинств/недостатков говорить пока рано.

Не бойтесь, никто ваш хлеб отбирать не собирается

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

AT>Статья очень интересная, спасибо. Еще одно доказательство, что возможности человека безграничны.
AT>Только вот хотелось бы, чтобы результатом работы был бы не драйвер в 40 строк, а что-то типа фильтра файловой системы. Или kernel-mode Firewall. Пожалуйста, напишете такое на Делфи.
AT>А потом сравним, кто столько затратил на это времени и сил: Вы с Делфи и я с DDK/C++. А до тех пор, пока все остается на уровне "Hello World" ни о каком серьезном анализе достоинств/недостатков говорить пока рано.


Вы удивительно догадливы. Да будет Вам известно, что как раз именно сегодня я сдаю клиенту проект, в состав которого входит, как вы выразились, kernel mode firewall, написанный именно таким способом. Ну, который IP Filter-Hook Driver. Вполне себе работает.

А вот меряться длиной пениса ни с Вами, ни с кем либо ещё я не собираюсь. Если Вам интересно, почему — можете пролистать весь тред обсуждения этой статьи, там немного. Вкратце вывод такой — эффективность работы программиста зависит только от его личных талантов, но никак не зависит от среды разработки. Если Вы не можете понять такой простой истины — Вам в holy war форумы.

Спасибо за внимание.

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

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

AT>>Статья очень интересная, спасибо. Еще одно доказательство, что возможности человека безграничны.
AT>>Только вот хотелось бы, чтобы результатом работы был бы не драйвер в 40 строк, а что-то типа фильтра файловой системы. Или kernel-mode Firewall. Пожалуйста, напишете такое на Делфи.
AT>>А потом сравним, кто столько затратил на это времени и сил: Вы с Делфи и я с DDK/C++. А до тех пор, пока все остается на уровне "Hello World" ни о каком серьезном анализе достоинств/недостатков говорить пока рано.

лично я разделяю восхищение, но не согласен с тем что на сях это дело будет быстрее и лучше.
я вот например пися на пвскале испытываю эстетическое удовольствие от стройности и логичности кода

но материала конечно маловато, былоб прекрасно если например экзампл мини-драйвер принтера (под 2000 и выше)
или например миррор видео.
автор упомянул, что доп. библы уже пишутся, кем? может я чем помог бы в портировании
так же интересует заточенный под это дело переписанный RTL ...

мона в приват.

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

AT>>>Статья очень интересная, спасибо. Еще одно доказательство, что возможности человека безграничны.
AT>>>Только вот хотелось бы, чтобы результатом работы был бы не драйвер в 40 строк, а что-то типа фильтра файловой системы. Или kernel-mode Firewall. Пожалуйста, напишете такое на Делфи.
AT>>>А потом сравним, кто столько затратил на это времени и сил: Вы с Делфи и я с DDK/C++. А до тех пор, пока все остается на уровне "Hello World" ни о каком серьезном анализе достоинств/недостатков говорить пока рано.
D>лично я разделяю восхищение, но не согласен с тем что на сях это дело будет быстрее и лучше.
D>я вот например пися на пвскале испытываю эстетическое удовольствие от стройности и логичности кода
D>но материала конечно маловато, былоб прекрасно если например экзампл мини-драйвер принтера (под 2000 и выше)
D>или например миррор видео.
D>автор упомянул, что доп. библы уже пишутся, кем? может я чем помог бы в портировании

Пока только самим автором . И портирование происходит под конкретную задачу, так что какой-либо систематизации работы не наблюдается.

D>так же интересует заточенный под это дело переписанный RTL ...

Если вы имеете в виду Delphi RTL, то он не заточен и не переписан. Он просто вырезан .

D>мона в приват.

Всегда пожалуйста.