CyberManiac дело не в этом, Паскаль, как язык программирования перестал поддерживаться на "профессиональном" уровне -- на протяжении ~10 лет программы под Windows пишут в основном на Visual'е... а для любителей языка Паскаль выпустили Delphi (не Паскаль), и всё. так и остаётся, что Паскаль, как язык программирования скорее полумёртв, да и то, силами свободного сообщества.
Clerk Позвольте поинтересоваться, сколько драйверов на Делфи вы скомпилили? Ни одного? Значит ваше мнение в вопросе дров на Делфи не актуально. Делать дрова не Делфи не большее извращение, чем на С.
Clerk Я плотно не занимался кернел кодингом. Вобще я к тому, что написание дров на С и Делфи большой разницы не имеет.
K10 а вы попробуйте теоретически - это возможно , практически - много гемороя о чём говорит попытка поиска исходников драйвера на паскале (дельфи) найти можно , но ровно один (я давно искал , может что -то изменилось , но вряд ли )
Дрова надо строго на Си писать. Можно на асме, если терпения хватит. А вообще дрова под Вин написанные на Си и на асме не сильно будут различаться.
staier Не думаю, что это вызовет проблемы. Зачем мне искать исходники драйвера на Делфи? Для анализа и понимания работы хватит исходников на асме, С. Единственно - ДДК, но и это можно решить... kiborg Вы безнадежны...
t00x Я, право, категорически не понимаю, чем Delphi - не объектно-ориентированная модификация Паскаля. Обратная совместимость - в районе 99%. Визуальная шняга - так она и в VB есть, и в VC - правда, и там, и там сделана даже не через задницу, а а руками, которые из этой задницы растут. Но никто же не обязывает использовать формы и компоненты там, где в них нет необходимости. А вот введение динамических массивов и нумерации элементов массива с произвольного индекса назрело ещё вечность назад, и мне непонятно, отчего с этим так долго тянули.
К10 Безнадежен?? Вы анализируете и даже понимаете как работают драйвера по их асм_исходникам, а пишите на делфи!!! (подвох в чем-то?) А, ну да-автоматизация!(легче так)) или нет... Может в Делфи особая оптимизация?? переменные в регистрах - это круто
CyberManiac Delphi - это скорее модификация объектно-ориентированного Паскаля. да, ещё перечисляемые типы и даже проверка на принадлежность множеству in[...]
Когда писал драйвера на С, часто сталкивался с тем что забывал например поставить & или * перед указателем и подобного рода ошибки, которые не приводят к еррору компилятора, но приводят к генерации warning'ов, которых на стадии написания каркаса столько (например unused параметры в колбеках, unused переменные и т.д.), что я их просто не читаю в листинге. В итоге приходилось втыкать в отладчике где программа вываливается в БСОД. Тогда стал делать .cpp дрова, не ожидал даже на сколько выгадаю в продуктивности. Это просто переход C->C++. Поэтому я даже не представляю как люди пишут большие программы/драйвера на ассемблере. По мне это просто извращение и мазохизм.
t00x Ну можно сказать и так, но до Delphi единственным объектно-развитым Паскалем был BP7. Ну, этому уже сто лет в обед. И множества, конечно, вещь хорошая, но мне не нравятся своей кастрированностью - 256 элементов в одном-единственном измерении - и усё. Иной раз хочется сделать битовую карту для unicode, вроде как раз работа для множеств, а "коротка кольчужка".
CyberManiac минимальный тип данных на x86 архитектуре - 8 битов. как раз хватает, чтобы определить первый пришедший байт разве в новых "свободных" реализациях языка Паскаль перечисляемые типы не расширены до 16 битов?
t00x, макс. длина множества не 8 бит, а 32. По одному биту на единицу множества. Причём это придумали задолго до 32-разрядных процессоров. Почему до сих пор Борланд-Эмбаркадеро не расширил - мне неведомо, а полагаться на расширения, существующие в одном лишь FPC как-то не рискую. Хотя в 2009 Делфе тем, кто забавлялся хаками c AnsiString, тоже немелкую такую свинью подложили.
CyberManiac Причем 32 байта, а не бита - уже не хило А почему не расширили, я уже пытался тебе объяснить Операции с множествами включают не только работу с элементами (in,include,exclude), но и операции над множествами в целом (*,+,-, =, <= и т.д.). Поэтому перелопачивать туда-сюда не менее 3 массивов по 8Кб и более ради того, что кому-то "иной раз хочется сделать битовую карту для unicode" - извините, просто глупо. А для битовых\поэлементных операций есть TBits. Хочется чего то большего - создай свой класс на основе того же TBits
leo Как-то не убедительно. "Жри, чё дают, и стакан за собой убери" - в такие рестораны я не хожу. Почему в программировании должно быть иначе? Особенно ввиду того, что использовать "of char" в последние 4 года - себе дороже, всё равно потом под unicode переделывать. Что-то мне подсказывает, что накладные расходы на вызов методов для include/exclude превысят затраты на саму операцию. А практика показывает, что операции, отличные от in, include и exclude используются во много раз реже. t00x Ну да. Когда внутренний стандарт не принуждает к билдеру - только им и пользуюсь.
CyberManiac ходит в рестораны .(( а ко мне раз в полгода заказчик приедет, поводит по бифстрогановым всяким пару дней и дальше типа лапу соси, кодер, я свой долг выполнил/читай: отмазался/! .(
Comer_, а с программированием вообще лучше завязывать, пока не поздно. В ближайшие 10 лет оно станет абсолютно не почтенным занятием. Ну или плавно перемещаться туда, где старые программисты уже вымерли, а новые ещё не расплодились.
да я тут наоборот чёто подумываю что скоро даже тостеры с сиподобными скриптами будут - сам задавай когда и при какой тенпературе переворачивать ,) //а китайцы как обычно сп здят идею и запатентуют даже .(
