AS>Тоже, открыли Америку. Вот как раз в непрактических науках ничего необычного нет. Попробовать бы заставить сию даму хоть что-ить закодировать настолько низкоуровневое
а почему вы думаете что низкоуровневое программирование это высший пилотаж?
все драйверщики так думают.
по моему спроектировать распределенную ОО-систему, скажем для управления тех.процессом на предпрятии, намного сложнее.
AS>>Тоже, открыли Америку. Вот как раз в непрактических науках ничего необычного нет. Попробовать бы заставить сию даму хоть что-ить закодировать настолько низкоуровневое
A>а почему вы думаете что низкоуровневое программирование это высший пилотаж? A>все драйверщики так думают. A>по моему спроектировать распределенную ОО-систему, скажем для управления тех.процессом на предпрятии, намного сложнее.
Спрошу прямо — проекты с драйверами были? Если нет — тогда вам меня не понять, поскольку у меня было и то, и то
Здравствуйте, Andrew S, Вы писали:
AS>>>Тоже, открыли Америку. Вот как раз в непрактических науках ничего необычного нет. Попробовать бы заставить сию даму хоть что-ить закодировать настолько низкоуровневое
A>>а почему вы думаете что низкоуровневое программирование это высший пилотаж? A>>все драйверщики так думают. A>>по моему спроектировать распределенную ОО-систему, скажем для управления тех.процессом на предпрятии, намного сложнее.
AS>Спрошу прямо — проекты с драйверами были? Если нет — тогда вам меня не понять, поскольку у меня было и то, и >то
нет. хотя очень давно и писал под ДОС.
я не хотел ничего плохого сказать про драйверщиков — но по моему охват предметной области у таких задач довольно узкий. например вряд ли ты занимаясь драйверами столкнешься в одном проекте с хранимыми процедурами в базах, C++/COM, C#, ASP.NET и программированием мобильных телефонов до кучи. при создании корпоративных систем с чем только не приходится работать, все намешано
A>я не хотел ничего плохого сказать про драйверщиков — но по моему охват предметной области у таких задач довольно узкий. например вряд ли ты занимаясь драйверами столкнешься в одном проекте с хранимыми процедурами в базах, C++/COM, C#, ASP.NET и программированием мобильных телефонов до кучи. при создании корпоративных систем с чем только не приходится работать, все намешано
все верно. так и есть. сталкивался и с тем и с тем. базы с хранимками это просто детский лепет по сравнению с теми ощущениями, что испытываеш в первый раз открыв файл из драйвера
выше верно сказали — не попробовав трудно сравнить.
AS>>>>Тоже, открыли Америку. Вот как раз в непрактических науках ничего необычного нет. Попробовать бы заставить сию даму хоть что-ить закодировать настолько низкоуровневое
A>>>а почему вы думаете что низкоуровневое программирование это высший пилотаж? A>>>все драйверщики так думают. A>>>по моему спроектировать распределенную ОО-систему, скажем для управления тех.процессом на предпрятии, намного сложнее.
AS>>Спрошу прямо — проекты с драйверами были? Если нет — тогда вам меня не понять, поскольку у меня было и то, и >то
A>нет. хотя очень давно и писал под ДОС.
Тогда — не понять. Это примерно как сравнивать сложение домика из детских кубиков и постройку останкинской башни.
A>я не хотел ничего плохого сказать про драйверщиков — но по моему охват предметной области у таких задач довольно узкий. например вряд ли ты занимаясь драйверами столкнешься в одном проекте с хранимыми процедурами в базах, C++/COM, C#, ASP.NET и программированием мобильных телефонов до кучи. при создании корпоративных систем с чем только не приходится работать, все намешано
В общем, вам уже довольно верно ответили, но я все же напишу. Охват предметной области низкоуровневого программирования что ни на есть самый широкий, поскольку влияние драйвера может проявляется где угодно, даже в ваших любимых базах данных (там же io\net используется весьма интенсивно, или что еще интереснее — в LPC\RPC И попробовать понять, что где и как — подчас очень сложно. Необходимо разбираться во всех деталях функционирования операционной системы, прикладого ПО и т.д. и т.п — в общем то, эти вещи обычно недокументированы либо документированы так, что лучше и не надо бы совсем. Затем, драйвер _обязан_ работать абсолюбтно стабильно, быть высокопроизводительным и вопросы синхронизации тут выходят на передний план. Посему квалификация специалистов, которые пишут драйвера, обычно на порядки выше, чем общесистемных, а уж тем более тех, которые занимаются разработкой корпоративного софта или просто технологов. Заметьте, я говорю _обычно_, а не всегда. Ровно так же, как и квалификация тех, кто пишет конфиги к 1с, обычно ниже квалификации общесистемщиков. Спроектировать сложную информационную систему, как ни странно, довольно просто — есть куча паттернов, есть просто у кого спросить\почитать — обычный итерационный процесс, который ограничивается временем\желанием\средствами. Есть готовые решения и компоненты, которые можно отсмотреть, потестировать, понять. В случае же с низкоуровневым программингом этого ничего обычно нет. В общем, объяснять долго, вам все равно придется верить (или не верить) на слово. Так вот, обычно низкоуровневое программирование — это удел злых бородатых\небритых мужиков с вечно красными глазами, которые во сне видят прохождение IRP по стеку и понимают, что, где и когда он там рушит. Когда девушка говорит, что она пишет на С++ — это почти нормально, ну, бывает. Но драйвера — это сильно, на самом деле
>на есть самый широкий, поскольку влияние драйвера может проявляется где угодно, даже в ваших любимых базах данных (там же io\net >используется весьма интенсивно, или что еще интереснее — в LPC\RPC И попробовать понять, что где и как — подчас очень сложно.
не угадали абсолютно нелюбимая моя область. но приходится заниматься потому что они — составная часть любой системы.
>>на есть самый широкий, поскольку влияние драйвера может проявляется где угодно, даже в ваших любимых базах данных (там же io\net >используется весьма интенсивно, или что еще интереснее — в LPC\RPC И попробовать понять, что где и как — подчас очень сложно.
A>не угадали абсолютно нелюбимая моя область. но приходится заниматься потому что они — составная часть любой системы.
И это все, что вам есть ответить? Мдя, слАбо.. Впрочем, это тут оффтопик
Вот что я точно заметил, так это то, что человек, который пытался писать драйвера с очень большой долей вероятности через некоторое время начинает считать, что круче него только горы.
AVK>Вот что я точно заметил, так это то, что человек, который пытался писать драйвера с очень большой долей вероятности через некоторое время начинает считать, что круче него только горы.
Пытался или ПИШЕТ? Это как бы разные понятия. Можно скомпилить пример из ДДК, и при этом говорить что пытался писать драйвер. Мы не про это речь ведем, а про разработчкиков драйверов реальных устройств. Я знаком с некоторыми, и вот что-то такого не замечал. Обычно с введением в кернел повышается общая квалификация программиста, поскольку там начинаются проблемы совсем другого порядка. В связи с этим и изменяется его собственное позиционирование. Но вот чтобы считать "круче только горы" — вам не кажется, что это как-то по-детски совсем, и напоминает замеры гениталиями в школьном туалете?
Здравствуйте, Andrew S, Вы писали:
AVK>>Вот что я точно заметил, так это то, что человек, который пытался писать драйвера с очень большой долей вероятности через некоторое время начинает считать, что круче него только горы.
AS>Пытался или ПИШЕТ? Это как бы разные понятия.
Т.е. пока только пытался, то шансы еще есть, а если уж пишет то все?
AS> Можно скомпилить пример из ДДК, и при этом говорить что пытался писать драйвер. Мы не про это речь ведем, а про разработчкиков драйверов реальных устройств. Я знаком с некоторыми, и вот что-то такого не замечал.
Я тоже знаком. И вот, что характерно, замечаю регулярно. Тут на рсдн топиков предостаточно на эту тему, в том числе и этот.
AS> Обычно с введением в кернел повышается общая квалификация программиста, поскольку там начинаются проблемы совсем другого порядка.
Да да да. Куда там бедным прикладным программистам... Вобщем не надо сказок — в свое время мне пришлось написать несколько драйверов (успешно), никаких проблем другого порядка там нет. Они просто другие. Точно так же как в случае написания серверов приложений есть свои сложные проблемы, в GUI свои, в SQL свои и т.д.
AS> В связи с этим и изменяется его собственное позиционирование. Но вот чтобы считать "круче только горы" — вам не кажется, что это как-то по-детски совсем, и напоминает замеры гениталиями в школьном туалете?
AVK>>>Вот что я точно заметил, так это то, что человек, который пытался писать драйвера с очень большой долей вероятности через некоторое время начинает считать, что круче него только горы.
AS>>Пытался или ПИШЕТ? Это как бы разные понятия.
AVK>Т.е. пока только пытался, то шансы еще есть, а если уж пишет то все?
Это вот к чему фраза? Непонятно..
AS>> Можно скомпилить пример из ДДК, и при этом говорить что пытался писать драйвер. Мы не про это речь ведем, а про разработчкиков драйверов реальных устройств. Я знаком с некоторыми, и вот что-то такого не замечал.
AVK>Я тоже знаком. И вот, что характерно, замечаю регулярно. Тут на рсдн топиков предостаточно на эту тему, в том числе и этот.
Не согласен. Прочитайте исходный пост, заметьте, что там постоянно вводится оборот "обычно", и далее аргументируется, почему. Никаких резких утверждений нет.
AS>> Обычно с введением в кернел повышается общая квалификация программиста, поскольку там начинаются проблемы совсем другого порядка.
AVK>Да да да. Куда там бедным прикладным программистам... Вобщем не надо сказок — в свое время мне пришлось написать несколько драйверов (успешно), никаких проблем другого порядка там нет. Они просто другие. Точно так же как в случае написания серверов приложений есть свои сложные проблемы, в GUI свои, в SQL свои и т.д.
Это так. Но там уровень документированности выше, есть у кого спросить, где посмотреть\почитать. При программировании драйвера обычно этого нет. И хочу заметить, что обычно в программирование драйверов приходят, имея уже довольно большой опыт прикладного программирования. Ошибки в драйвере стоят в сотни раз больше, чем в юзер-приложении, вы это должны понимать.
AS>> В связи с этим и изменяется его собственное позиционирование. Но вот чтобы считать "круче только горы" — вам не кажется, что это как-то по-детски совсем, и напоминает замеры гениталиями в школьном туалете?
AVK>Именно что напоминает.
Д>Подозреваю, что такое мнение существует исключительно среди kernel mode programmers
В том то и дело, что не только среди них. Я лично знаком с одним человеком, который десять лет писал на Turbo Pascal под MSDOS и пять лет — на VC/MFC под Windows. Однако во время знакомства с ядром NT у него, как он сам выразился, первые три месяца была мысль "да как такое вообще можно писать", а окончательно освоил ядро он только спустя года полтора. Да и на любом собеседовании рейтинг соискателя резко растет, когда он владеет kernel mode programming.
И такое, уж поверь, я встречаю на rsdn не первый раз.
AS> Прочитайте исходный пост, заметьте, что там постоянно вводится оборот "обычно", и далее аргументируется, почему. Никаких резких утверждений нет.
Это не важно. Сравни: "обычно все драйверописатели ничего не умеют".
AS>Это так. Но там уровень документированности выше, есть у кого спросить, где посмотреть\почитать.
Позволю себе повториться — не суди о том, что не знаешь. И там попадаются места, которые документированны плохо.
Например VSIP.
AS>Ошибки в драйвере стоят в сотни раз больше, чем в юзер-приложении, вы это должны понимать.
Не, непонимаю. Вот, к примеру, во что обойдется ошибка в коде сервера приложений, работающего в режиме 24х7 можно представить. А драйвера?
AS>>Спрошу прямо — проекты с драйверами были? Если нет — тогда вам меня не понять, поскольку у меня было и то, и то
Д>куда уж нам понять человека, который достиг Истинного Просветления
Офигенная шутка. Так и хочется сказать — "слив засчитан" Д>а какого рода были твои проекты, помимо написания драйверов?
Мы с Вами под ручку не ходили, давайте вежливо общаться, ок? Мои проекты были самые разные, обсуждать их здесь смысла не имеет. Скажу только, что опыт (приличный) имеется как в написании распределенных систем, сервисов, так и (небольшой, по сравнению с остальным) драйверов. В общем, области были самые разные и уже это позволяет примерно оценить необходимую квалификацию. Ну а основной вывод — по моим знакомым, кто чем занимается и что из себя представляет в качестве IT специалиста.
PS Я свою точку зрения высказал, засим для себя эту ветку закрываю. Всем успехов.
Д>>Подозреваю, что такое мнение существует исключительно среди kernel mode programmers
AVK>В том то и дело, что не только среди них. Я лично знаком с одним человеком, который десять лет писал на Turbo Pascal под MSDOS и пять лет — на VC/MFC под Windows. Однако во время знакомства с ядром NT у него, как он сам выразился, первые три месяца была мысль "да как такое вообще можно писать", а окончательно освоил ядро он только спустя года полтора. Да и на любом собеседовании рейтинг соискателя резко растет, когда он владеет kernel mode programming.
AVK>И такое, уж поверь, я встречаю на rsdn не первый раз.
И с чем вы в выделенном не согласны? Кстати, что за драйвера писали вы? Если что то уровня "доступ к порту", то понятно. Если нормальный fs\фильтр драйвер — дело другое.
AS>> Прочитайте исходный пост, заметьте, что там постоянно вводится оборот "обычно", и далее аргументируется, почему. Никаких резких утверждений нет.
AVK>Это не важно. Сравни: "обычно все драйверописатели ничего не умеют".
Важно. Сравните "Обычно программисты 1С круче прикладных". Нормально?
AS>>Это так. Но там уровень документированности выше, есть у кого спросить, где посмотреть\почитать.
AVK> Позволю себе повториться — не суди о том, что не знаешь. И там попадаются места, которые документированны плохо. AVK>Например VSIP.
Ключевое слово — попадаются
AS>>Ошибки в драйвере стоят в сотни раз больше, чем в юзер-приложении, вы это должны понимать.
AVK>Не, непонимаю. Вот, к примеру, во что обойдется ошибка в коде сервера приложений, работающего в режиме 24х7 можно представить. А драйвера?
Ошибка приложения:
Вывалится сервис, который перезапустится либо сам, либо вручную
Ошибка драйвера:
Зависнет система (и _все_ сервисы, которые она предоставляет, особенно круто, если это произойдет во время бэкапа), повредится fs, убьется железяка, которой он управляет и т.д и т.п.). В общем, ошибка в приложении обычно влияет только на это приложение, ошибка драйвера — обычно на систему целиком и обычно самым фатальным образом.
По-моему, это очевидно и обсуждению как бы не подлежит. В общем, далее эта ветка обсуждения для меня — RO. Удачи.
Здравствуйте, Andrew S, Вы писали:
AS>И с чем вы в выделенном не согласны? Кстати, что за драйвера писали вы? Если что то уровня "доступ к порту", то понятно. Если нормальный fs\фильтр драйвер — дело другое.
Ну да, сценарий повторяется с точностью до слов. Ты там чего то про пенисометрию писал?
AVK>>Это не важно. Сравни: "обычно все драйверописатели ничего не умеют".
AS>Важно. Сравните "Обычно программисты 1С круче прикладных". Нормально?
Нет. А по твоему что, нормально?
AVK>> Позволю себе повториться — не суди о том, что не знаешь. И там попадаются места, которые документированны плохо. AVK>>Например VSIP.
AS>Ключевое слово — попадаются
А, ну да, конечно, куда уж нам, сирым. Ты хоть раз с VSIP сталкивался, что с такой легкостью выводы делаешь? Или драйверописатели круче в принципе?
AVK>>Не, непонимаю. Вот, к примеру, во что обойдется ошибка в коде сервера приложений, работающего в режиме 24х7 можно представить. А драйвера?
AS>Ошибка приложения: AS>Вывалится сервис, который перезапустится либо сам, либо вручную
Ага, и накроется масса транзакций.
AS>Ошибка драйвера: AS>Зависнет система (и _все_ сервисы, которые она предоставляет, особенно круто, если это произойдет во время бэкапа), повредится fs, убьется железяка, которой он управляет и т.д и т.п.). В общем, ошибка в приложении обычно влияет только на это приложение, ошибка драйвера — обычно на систему целиком и обычно самым фатальным образом.По-моему, это очевидно и обсуждению как бы не подлежит.
AS> В общем, далее эта ветка обсуждения для меня — RO. Удачи.
Здравствуйте, Andrew S, Вы писали:
AS>Офигенная шутка. Так и хочется сказать — "слив засчитан"
не надо было высказываться про "вам этого не понять". В приличном обществе не хвастают своей крутизной, в особенности — не предъявляя никаких доказательств оной.
AS>Мы с Вами под ручку не ходили, давайте вежливо общаться, ок?
не стоит ходить в чужой монастырь со своим уставом
на данном форуме не принят официозно-формальный стиль общения, и уж тем более не принято требовать его соблюдения от остальных
AS>Мои проекты были самые разные, обсуждать их здесь смысла не имеет. AS>Скажу только, что опыт (приличный) имеется как в написании распределенных систем, сервисов, так и (небольшой, по сравнению с остальным) драйверов.
вероятно, на самом деле это должно означать "ни один из них не стоит серьезного упоминания"
если не хочешь выглядеть пустозвоном, приведи линк хотя бы на один серьезный продукт, который применяется в настоящее время. Ну и описание своей роли в нем, конечно.
AS>PS Я свою точку зрения высказал, засим для себя эту ветку закрываю. Всем успехов.
решил оставить за собой последнее слово? Молодец, вижу что основные приемы демагогии тебе знакомы. Если решишь прочитать мой ответ, чтобы проконтролировать результаты — желаю приятного прочтения
A>а почему вы думаете что низкоуровневое программирование это высший пилотаж?
тут ничего сложного нет. Хотя, несколько рутинных моментов напрягают:
— очень муторная отладка. Часто для отладки нужно перезапускать target каждый раз. Часто при crash-ах нужно грузиться в Safe Mode и убирать свой драйвер.
— сложная синхронизация потоков. Все real-time.
— сложная security model. Твой thread работает из под разных процессов и нужно учитывать security context.
— жесткие требования на performace и stack (==12 Kb).
— плохо документированные API методы. Много reseach. Есть вообще "голые" места, только через news group. I.e Dynamic disks.
— API в kernel имеет много ограничений и исключений.
— сильная зависимость на третии компоненты и драйвера. Если вы пишете file filter driver, то нужно учитывать, что может присутствовать еще несколько фильтров, которые еще и неправильно перехватывают операции.
— лучше писать на голом С, т.к. тогда можно сделать код "paged".
AS>Это так. Но там уровень документированности выше, есть у кого спросить, где посмотреть\почитать. При программировании драйвера >обычно этого нет. И хочу заметить, что обычно в программирование драйверов приходят, имея уже довольно большой опыт прикладного >программирования. Ошибки в драйвере стоят в сотни раз больше, чем в юзер-приложении, вы это должны понимать.
это все понятно что цена ошибки там очень высока
но вот скажите , алгоритмическая часть в драйверах шибко сложная?
случаи конечно разные бывают но мне кажется с точки зрения устойчивости дизайна, сложную алгоритмическую часть обычно
выносят в юзер моде длл. ибо отлаживать намного проще
