Давно задаюсь вопросом, почему в отечественной литературе
так мало внимания уделяется низкоуровневому программированию
Windows. Создается такое впечатление, что это никому не надо
и вовсе неактуально. Но, на мой взгляд, низкая популярность
Kernel Mode Programming связана предже всего с недостаточным
количеством русскоязычной документации и литературы. Кроме того,
я думаю, что навыки программирования в режиме ядра должен иметь
каждый программист, ибо техники, применяемые там, требуют аккуратности
и тем самым прививают качественный стиль программирования. Судите сами,
если вы функцией ExAllocatePool выделите блок памяти и забудете освободить
его при помощи ExFreePool, система вполне может показать синий экран. В то же
время прожужжавшая уши парадигма managed code технологии .NET остается для меня,
магко говоря, непонятной, т.к. сама подталкивает программиста к набрежному расходу ресурсов, тем самым воспитывая неряшливый стиль. Кроме того, на данный момент она остается крайне ресурсоемкой и практически непригодной для разработки критичный по скорости приложений.
Господа посетители RDSN, хочу узнать ваше мнение на этот счет.
Здравствуйте, Orifiel, Вы писали:
O>его при помощи ExFreePool, система вполне может показать синий экран. В то же O>время прожужжавшая уши парадигма managed code технологии .NET остается для меня, O>магко говоря, непонятной, т.к. сама подталкивает программиста к набрежному расходу ресурсов, тем самым воспитывая неряшливый стиль. Кроме того, на
Спорно. Если посмотреть "поширше", то она также подталкивает к созданию скажем, хардварных GC, или поддержки понятия "указатель" на уровне железа, опять же с целью сделать какой-нибудь GC, хардварной поддержки RAII для всех типов ресурсов.
Здравствуйте, Orifiel, Вы писали:
O>Привет всем.
O> Давно задаюсь вопросом, почему в отечественной литературе O>так мало внимания уделяется низкоуровневому программированию O>Windows.
Спрос рождает предложение.
O>Создается такое впечатление, что это никому не надо O>и вовсе неактуально.
Да, ты прав
O>Но, на мой взгляд, низкая популярность O>Kernel Mode Programming связана предже всего с недостаточным O>количеством русскоязычной документации и литературы.
Ну... приведите примеры задач, которые можно решить только низвоуровневыми средствами? И сравните с теми задачами, на которые есть спрос Кроме того, обычно в режиме ядра программируют достаточно всококлассные специалисты дл якоторых английский не проблема.
O>Кроме того, я думаю, что навыки программирования в режиме ядра должен иметь O>каждый программист, ибо техники, применяемые там, требуют аккуратности O>и тем самым прививают качественный стиль программирования.
Это уже в образование Не будет же фирма ради тренинга сотрудников разрабатывать клиент БД таким образом, чтобы часть кода была в режиме ядра? Что касается образования, то тут отдельный разговор Да, было бы полезно, но...
O>В то же время прожужжавшая уши парадигма managed code технологии .NET остается для меня, O>магко говоря, непонятной, т.к. сама подталкивает программиста к набрежному расходу ресурсов, тем самым воспитывая неряшливый стиль.
Не поддалкивает, а освобождает дополнительные ресурсы программиста. Если пользоваться с умом, то удобная вещь. Обычно программы в режиме ядра не имеют большой сложности (не сталкиваются с большим количеством сущностей). В общем-то если послушать Вас, то следующий шаг будет в переписывание всего не ассемблере и т. д. Тоже нужна аккуратность
O> Кроме того, на данный момент она остается крайне ресурсоемкой и практически непригодной для разработки критичный по скорости приложений.
Ну... каждому овощу свое время. Оптимизировать надо то, что криточно по времени
Кодёнок wrote: > Спорно. Если посмотреть "поширше", то она также подталкивает к созданию > скажем, хардварных GC, или поддержки понятия "указатель" на уровне > железа, опять же с целью сделать какой-нибудь GC, хардварной поддержки > RAII для всех типов ресурсов.
Это нереально. Даже если ВСЕ аппаратные ресурсы сделать GCабельными, то
останутся внешние ресурсы (типа курсоров в DB).
Гораздо интереснее было бы совместить детерминированое управление
объектами и GC. Пионер тут (как обычно ) C++, где крайне тщательно
исследована семантика и проблемы детерминированого управления. Сейчас в
C++/CLI прорабатывается взаимодействие с GC. Но как-то это не совсем то,
что хочется.
Orifiel wrote: > > Давно задаюсь вопросом, почему в отечественной литературе > так мало внимания уделяется низкоуровневому программированию > Windows. Создается такое впечатление, что это никому не надо > и вовсе неактуально. Но, на мой взгляд, низкая популярность > Kernel Mode Programming связана предже всего с недостаточным > количеством русскоязычной документации и литературы. Кроме того, > я думаю, что навыки программирования в режиме ядра должен иметь > каждый программист, ибо техники, применяемые там, требуют аккуратности > и тем самым прививают качественный стиль программирования. Судите сами,
По-моему, community, существующие вокруг Виндовсного kernel-mode
программирования, занимаются примерно следующим:
1. Обсуждением виндовсного ядра на мифически-магическом уровне ("чтобы
XXX заработало, надо подергать за YYY, хотя это нигде и не написано").
2. Обсуждением того, как с помощью недокументированного API можно
написать в 100 строк то, что требует 120 строк, если делать все
абсолютно честно (но зато потребует прочтения половины MSDN).
3. Обсуждением того, как приручить какую-нибудь замороченную фичу, так
и не поняв ее настоящего смысла.
4. Обсуждением того, как заставить работать драйвер с ошибками, не
исправляя, а добавляя новые ошибки.
5. Иногда гуры дают конкретные ответы на наивные вопросы.
К сожалению, в Виндовсной community никто не пытается понять устройство
системы на концептуальном уровне. Вместо этого систему пытаются
представить в виде некоторой комбинации черных ящиков, с которыми надо
общаться через ихний API. И чем лучше Вы знаете тонкости этого API, тем
выше оценивается Ваш профессионализм. Знанием тонкостей API считается не
понимание его семантики, а умение поставить все ручки в правильное
положение с минимального количества попыток.
Поэтому в плане с кем-нибудь потусоваться на предмет kernel mode
програмизма UNIX'овская community гораздо более привлекательна.
> если вы функцией ExAllocatePool выделите блок памяти и забудете освободить > его при помощи ExFreePool, система вполне может показать синий экран. В > то же > время прожужжавшая уши парадигма managed code технологии .NET остается > для меня, > магко говоря, непонятной, т.к. сама подталкивает программиста к > набрежному расходу ресурсов, тем самым воспитывая неряшливый стиль.
Скорее, она позволяет посадить за клавиатуру тех мартышек, котором 5 лет
назад не светило более высокой должности, чем уборщик в оффисе.
> Кроме того, на данный момент она остается крайне ресурсоемкой и > практически непригодной для разработки критичный по скорости приложений.
Это-то как раз не очень важно. Важно то, что .Net'овский рантайм не
является стандартной частью операционной системы, и при этом достаточно
капризен и требователен в плане установки. Если Ваша программа
предназначена для массового пользователя и написана на C#, половину
пользователей Вы потеряли сразу, т.к. они не захотят выкачивать 20Mb
.Net'овского рантайма, и потом трахаться с его установкой.
Cyberax wrote: > > Гораздо интереснее было бы совместить детерминированое управление > объектами и GC. Пионер тут (как обычно ) C++, где крайне тщательно > исследована семантика и проблемы детерминированого управления. Сейчас в > C++/CLI прорабатывается взаимодействие с GC. Но как-то это не совсем то, > что хочется.
Готов поспорить, что в академической среде все это уже обнюхано 20 лет
назад, если не больше. C++ если в чем-то и пионер, то в популяризации
давно известных идей на массовом рынке.
Здравствуйте, Cyberax, Вы писали:
>> Спорно. Если посмотреть "поширше", то она также подталкивает к созданию >> скажем, хардварных GC, или поддержки понятия "указатель" на уровне >> железа, опять же с целью сделать какой-нибудь GC, хардварной поддержки >> RAII для всех типов ресурсов. C>Это нереально. Даже если ВСЕ аппаратные ресурсы сделать GCабельными, то C>останутся внешние ресурсы (типа курсоров в DB).
Наличие в системе автоматического управления памятью автоматически создаст традицию любой ресурс снабжать подсчетом ссылок или чем-нибудь подобным — если его можно получить и его можно освободить, то как минимум, автоматически можно считать ссылки.
К тому же курсоры — это не же аппаратный ресурс, причем тут они?
Здравствуйте, Pzz, Вы писали:
Pzz>Это-то как раз не очень важно. Важно то, что .Net'овский рантайм не Pzz>является стандартной частью операционной системы, и при этом достаточно Pzz>капризен и требователен в плане установки. Если Ваша программа Pzz>предназначена для массового пользователя и написана на C#, половину Pzz>пользователей Вы потеряли сразу, т.к. они не захотят выкачивать 20Mb Pzz>.Net'овского рантайма, и потом трахаться с его установкой.
Смею не согласиться. Насчет сложной установки: факты в студию.
Эта ситуация напоминает разработку игр под DirectX. Вы же не будите утверждать, что нефиг писать под DX, так как он, видетели, весит мегов 50 и его качать и ставить надо.
Тенденция такова, что всё больше и больше программ пишутся под fw, и он уже является "базовой" частью windows (тот же sp2). И не говорите, что лично у вас на машине нет fw
Максим Зелинский wrote:
> Pzz>Это-то как раз не очень важно. Важно то, что .Net'овский рантайм не > Pzz>является стандартной частью операционной системы, и при этом достаточно > Pzz>капризен и требователен в плане установки. Если Ваша программа > Pzz>предназначена для массового пользователя и написана на C#, половину > Pzz>пользователей Вы потеряли сразу, т.к. они не захотят выкачивать 20Mb > Pzz>.Net'овского рантайма, и потом трахаться с его установкой. > Смею не согласиться. Насчет сложной установки: факты в студию.
Мой личный печальный опыт заключается в том, что мне так и не удалось
поставить .Net на checked build of Windows XP.
> Эта ситуация напоминает разработку игр под DirectX. Вы же не будите > утверждать, что нефиг писать под DX, так как он, видетели, весит мегов > 50 и его качать и ставить надо.
С играми, наверное, выбора нет...
> Тенденция такова, что всё больше и больше программ пишутся под fw, и он > уже является "базовой" частью windows (тот же sp2). И не говорите, что > лично у вас на машине нет fw
Здравствуйте, Pzz, Вы писали:
Pzz>Максим Зелинский wrote:
> Тенденция такова, что всё больше и больше программ пишутся под fw, и он >> уже является "базовой" частью windows (тот же sp2). И не говорите, что >> лично у вас на машине нет fw
Pzz>А он вошел уже в XP2? Вы уверены?
В Windows2003 .NET Framework 1.1 всегда входил. в R2 вроде бы входит 2.0
В XP он действительно доолжен ставиться вместе с SP2.
Что то мне подсказывает, что все системы от МС, которые будут выходить в дальнейшем( за исключением может быть встраиваемых систем )
Pzz wrote: > Готов поспорить, что в академической среде все это уже обнюхано 20 лет > назад, если не больше.
Может быть. Однако, одно дело — академические исследование, другое дело
— практический опыт (см. подборку CUJ за десять лет).
Cyberax wrote: > >> Готов поспорить, что в академической среде все это уже обнюхано 20 лет >> назад, если не больше. > Может быть. Однако, одно дело — академические исследование, другое дело > — практический опыт (см. подборку CUJ за десять лет).
Ну я понимаю. Типа, чтобы знания из умной книжки попали в голову рядовых
программистов, они должны быть разжеваны, описаны в MSDN'е как "новая
технология" и реализованы в виде библиотеки C++'ных классов.
Знаний, которые не прошли этот путь, как-бы в природе не существует...
Pzz wrote: >> > Готов поспорить, что в академической среде все это уже обнюхано 20 лет >> > назад, если не больше. >> Может быть. Однако, одно дело — академические исследование, другое дело >> — практический опыт (см. подборку CUJ за десять лет). > Ну я понимаю. Типа, чтобы знания из умной книжки попали в голову рядовых > программистов, они должны быть разжеваны, описаны в MSDN'е как "новая > технология" и реализованы в виде библиотеки C++'ных классов.
Я же говорю — прочитайте CUJ. Там много интересного есть.
Например, казалось бы простая задача — вызвать деструкторы. Все вроде
просто и понятно — вызываем деструктор и освобождаем память.
Ан нет, оказывается что для иерархии классов нужно вызывать
деструкторы предков. А в каком порядке их вызывать? А что делать если в
деструкторе вылетело исключение? А как быть с множественным наследованием?
Исключения (такая древняя академическая поделка из 70-х годов) тоже
преподнесли кучу сюрпризов. Именно в среде практиков С++ появилось
понятие гарантий безопасности по исключениям (по которой уже достаточно
академических работ написано).
Или темплейты — все логично и понятно. Любой продвинутый программист
скажет, что темплейты образуют простой чистый функциональный язык с
ленивым выполнением. Все вроде просто и понятно — берем учебник по
Scheme и читаем, а потом пишем крутой метакод. Но опять появляются
интересные моменты типа "forwarding problem" или ADL.
> Знаний, которые не прошли этот путь, как-бы в природе не существует...
В практике практически нет. Все знания сначала появляются в
академических кругах, потом переходят в область практики (при этом
обнаруживаются незаметные подводные камни), а потом уже иногда переходят
в mainstream.
O> Давно задаюсь вопросом, почему в отечественной литературе O>так мало внимания уделяется низкоуровневому программированию O>Windows.
Не хватало нам на пару с "Нейрохирургией для чайников" еще и "Программирования в режиме ядра за три дня".
Ты тираж не продаж такой книжки, если ее напишет кто.
O>я думаю, что навыки программирования в режиме ядра должен иметь O>каждый программист, ибо техники, применяемые там, требуют аккуратности
А это можно на стенку вешать
O>магко говоря, непонятной, т.к. сама подталкивает программиста к набрежному расходу ресурсов, тем самым воспитывая неряшливый стиль. Кроме того, на данный момент она остается крайне ресурсоемкой и практически непригодной для разработки критичный по скорости приложений.
Рынок сейчас требует, чтобы приложения создавались БЫСТРО и хоть как-то, но РАБОТАЛИ, понимаешь?
Все отсюда и пляшет.
1. Как ни крути, задачи которые решают драйверы в основном тривиальны: прислать-переслать байты. Все сложное делает обычно user-mode апликуха. Поэтому писать особо нечего. Реализации разных FS конечно сложны, но кернел мод это или не кернео не иммет значение. Есть тенденция по выносу всего сложного в юзермод.
2. Ты радуйся что ты видишь BSOD как только допускаешь ошибку. Эти ошибки легче всего найти.
Здравствуйте, Orifiel, Вы писали:
O> Давно задаюсь вопросом, почему в отечественной литературе O>так мало внимания уделяется низкоуровневому программированию O>Windows. Создается такое впечатление, что это никому не надо O>и вовсе неактуально. Но, на мой взгляд, низкая популярность O>Kernel Mode Programming связана предже всего с недостаточным O>количеством русскоязычной документации и литературы. Кроме того, O>я думаю, что навыки программирования в режиме ядра должен иметь O>каждый программист, ибо техники, применяемые там, требуют аккуратности O>и тем самым прививают качественный стиль программирования. Судите сами, O>если вы функцией ExAllocatePool выделите блок памяти и забудете освободить O>его при помощи ExFreePool, система вполне может показать синий экран. В то же O>время прожужжавшая уши парадигма managed code технологии .NET остается для меня, O>магко говоря, непонятной, т.к. сама подталкивает программиста к набрежному расходу ресурсов, тем самым воспитывая неряшливый стиль. Кроме того, на данный момент она остается крайне ресурсоемкой и практически непригодной для разработки критичный по скорости приложений. O> Господа посетители RDSN, хочу узнать ваше мнение на этот счет.
Блин, еще один! Держите меня семеро, а то ведь покусаю.
Как достали эти неофиты каменного века? Мы тут о высоких материях. Об управляемых ОС, об типобезопасности, надежности... А они... ааааааааааааааааа...........
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pzz, Вы писали:
Pzz>Скорее, она позволяет посадить за клавиатуру тех мартышек, котором 5 лет Pzz>назад не светило более высокой должности, чем уборщик в оффисе.
Только что ты обозвал мартышками довольно большую часть аудитории этого сайта.
Вот я и подумал, может быть избавить тебя от общения с мартышками эдак на недельку другую?
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pzz, Вы писали:
Pzz>Мой личный печальный опыт заключается в том, что мне так и не удалось Pzz>поставить .Net на checked build of Windows XP.
Хм. А у мартышек получается.
Pzz>А он вошел уже в XP2? Вы уверены?
Попробуй разок купить Виндовс. Тогда узнашь, что на всех версиях виндовс начиная с XP SP1 фрэймворк лежит прямо на инсталляционном диске.
Кстати, SP весит куда больше фрэймворка. Ты его тоже по этим причинам не скачивашь?
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну я понимаю. Типа, чтобы знания из умной книжки попали в голову рядовых Pzz>программистов, они должны быть разжеваны, описаны в MSDN'е как "новая Pzz>технология" и реализованы в виде библиотеки C++'ных классов.
Pzz>Знаний, которые не прошли этот путь, как-бы в природе не существует...
Все проще. Наплодить кучу гениальных идей могут очень многие. А вот грамотно их структурировать, объеденить и качественно реализовать — нет. Вот и выходит, что идеи придуманные в 70-ых и 80-ых только сейчас находят реальное применение в массовом программировании, да и то появляются темы вроде этой в которых вопрошается "а на хрена все это?... все в керенел срубать ОС...".
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Во-первых, хочу подчеркнуть, что данное сообщение не является попыткой обсуждения модераторов.
Здравствуйте, VladD2, Вы писали:
Pzz>>Скорее, она позволяет посадить за клавиатуру тех мартышек, котором 5 лет Pzz>>назад не светило более высокой должности, чем уборщик в оффисе.
VD>Только что ты обозвал мартышками довольно большую часть аудитории этого сайта.
Во-вторых, если подумать головой, то никого никем обозвано не было. Если технология "позволяет посадить за клавиатуру тех мартышек..." (далее по тексту), то из этого утверждения не следет, что все, кто ей пользутся, являются мартышками. Это классическая путаница условий необходимости и достаточночти.
Если утрировать, то у тебя получается примерно следующий абсурд:
Утверждение 1. Все дети боятся зубных врачей.
Утверждение 2. Ни один король не является зубным врачем.
Вывод: Ни один ребенок не будет бояться ни одного короля.
Пояснение. Я ни к коем случае ничего не имею против, чтобы кого-то забанить просто потому, что тебе (лично тебе!) не понравилось его высказывание. Я всего лишь призываю думать головой прежде, чем делать логические выводы.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
