Здравствуйте, Малич Юрий, Вы писали:
A>> Мне больше нравится другое — что fw одинаково работает на различных ОС от MS. win32 этим похвастать не мог.
МЮ>Really? Одинаково ограниченно вы хотели сказать . Внимание вопрос: Как вызвать из dotNet новые функции , появившиеся в новой операционной системе, новые интерфейсы, новые контролы? Или может прикладным программистам они не нужны?
Боюсь в случае с ОС от МС проблемы будут в том, как использовать "новые функции , появившиеся в новой операционной системе, новые интерфейсы, новые контролы" из не-дотнет приложений.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Я много за что заплатил. В этом списке кстати ни одной dotNet программы.
Мне многое за что платили и в последнее время это только .NET программы.
МЮ>Я вообще не рекомендую замыкать свои знания только на том, что нужно заказчику. Заказчики приходят и уходят, а знания остаются.
Есть у меня стойкое ощущение, что у нас разные заказчики. И это многое объясняет, не правда ли?
МЮ>У приложений dotNet круг тоже ограничен. Весьма. Ваш тому пример.
Не уверен, что имею право представлять написанными мной программами круг приложений .NET.
МЮ>Звук, видео, САПР, игры — там dotNet не нужен, а разработчики, владеющие API — нужны.
Да, не нужен. А кто говорит, что .NET заменит собой все и везде? Системное программирование, драйвера, программы критичные к скорости — туда путь .NETу заказан. Он ориентирован на программы уровня предприятия, а не на ширпотреб. Собственно, ничего другого от MS ждать и не приходится. Они жуть как людят масштаб предприятия" во всем. Собственно они (и NET) ориентированы на крупных заказчиков, а не на массовку.
МЮ>Знания ради умений и опыта. Чтобы написать хорошую программу, которая не ограничевается Button, DBGrid и StoredProg знаний dotNet не дотсточно. МЮ>Вообще зачем нужно учится в университете? Выучил дома dotNet по книге и вперёд устраиватся на работу
Абсолютно согласен. Методологию программирования и опыт ничто не заменит. Конкретные знания по winapi, .NET, ассемблеру или чему угодно этого не заменят и не помогут. Освоение книжки по NET или api опыта не даст.
МЮ>Вы очень поверхностно смотрите в корень проблемы, видимо специфика работы такая. Какой смысл мне вам рассказывать, если вам это не пригодится? Знанияния ради знаний?
Вы на попятную? Пожалуйста, уж снизойдите, расскажите. Я попробую отойти от своей поверхностной специфики и посмотреть на вопрос по-другому. Может я пойму всю свою убогость и брошусь в winapi? Мне все же непонятно насчет этих 90%. Как используется winapi в тестировании процессоров, обработке данных и вызове старого кода?
МЮ>А почему я например не могу попытатся что-то портировать или написать новое? Если я с этим сталкивался, значит мне это было нужно, а в FW этого не было.
Да ради бога, пишите сколько влезет и портируйте что требуется! Кто сказал нельзя? Просто вы работаете не в той сфере, для которой этот NET предназначен.
МЮ>Ага , уже напопятную.
Почему? В настоящий момент fw под lin уже чем под win. Это означает, что программу, написанную под lin, можно запускать по win, а обратное неверно. Это я и называю "проблемы lin сообщества". И почему в реальном мире прога не сможет работать и под win, и под lin при наличии fw — непонятно. Или для работы обязательно нужно абсолютно полное соответствие fw?
МЮ>Really? Одинаково ограниченно вы хотели сказать .
Нет, дорогой, ваша версия ошибочна, я сказал то, что хотел сказать — работает одинаково. А насчет ограниченности вопрос: лучше, если под одной ОС функция работала одним образом, а под другой — другим (или вообще не работала)?
МЮ>Внимание вопрос: Как вызвать из dotNet новые функции , появившиеся в новой операционной системе, новые интерфейсы, новые контролы? Или может прикладным программистам они не нужны?
Если вопрос абстрактен, то собственно если прикладнику приспичило что-то из win32, то pinvoke — и вперед.
Если вопрос конкретный, то его надо уточнить. О каких функциях, интерфейсах и контролах идет речь?
МЮ>API надо знать ради расширения возможностей. МЮ>А стоит ли замыкатся на ограниченные возможности dotNet?
Знания — это здорово, расширение возможностей — замечательно, но кроме них есть еще опыт, умения и навыки. Можно знать до черта всего, но не обладать опытом по его использованию. А можно знать мало, но довести это до совершенства, а скорость и качество написанных программ — до максимума. Что лучше? Истина как обычно, где-то посередине...
Здравствуйте, Kisloid, Вы писали:
K>А почему поздно ? Ведь все только начинает развиваться, С шарп то вышел всего года два назад =)
Вообще-то я думал ты поймешь, что я прикалываюсь. Просто уж больно смешно твои вопрсы выглядят.
K>И почему поздно покупать "Windows для профессионалов" ? Вин АПИ скоро изменится ? А с чего вообще тогда начать ? До сих пор я использовал MFC =)
Вообще-то MFC-программиста без знаний того что написано в "Windows для профессионалов" программистом то назвать тяжело. Так любитель.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вообще-то я думал ты поймешь, что я прикалываюсь. Просто уж больно смешно твои вопрсы выглядят.
Я понял =)
VD>Вообще-то MFC-программиста без знаний того что написано в "Windows для профессионалов" программистом то назвать тяжело. Так любитель.
Это я тоже понимаю, ну все же, посоветуй VladD2, "Windows для профессионалов" + Страуструп или "Программирование платформы .NET" + книга по C#-у ?
А мое мнение такое, что те, кто грит что Win API мертва и что в будущем .NET ,будет напрямую с ядром взаимодействовать неправда =) Поэтому я больше склоняюсь к первому варианту. Хотя конечно надо знать .NET, но в первую очередь думаю стоит изучить win api.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
>Мне многое за что платили и в последнее время это только .NET программы.
Это вовсе не значит, что WinAPI мёртв и другим его знать не надо.
>Есть у меня стойкое ощущение, что у нас разные заказчики. И это многое объясняет, не правда ли?
May be
>Да, не нужен. А кто говорит, что .NET заменит собой все и везде? .. Системное программирование, драйвера, программы критичные к скорости -...
И ещё много-много чего.
> Как используется winapi в тестировании процессоров, обработке данных и вызове старого кода?
А как вы сами думаете?
1. Не ужели я пишу ассемблерные вставки в программы на С++, чтобы затем интерфейс писать на фреймворке. Естественно, что с виндами я взаимодействую через API.
>Если вопрос абстрактен, то собственно если прикладнику приспичило что-то из win32, то pinvoke — и вперед.
Вот. Чистый пример необходимости использования WinAPI.
>Нет, дорогой, ваша версия ошибочна, я сказал то, что хотел сказать — работает одинаково. А насчет ограниченности вопрос: лучше, если под одной ОС функция работала одним образом, а под другой — другим (или вообще не работала)?
Да не фига они не одинаково работают, потому что FW обёртка над тем же вин API.
Хотите пример? Попробуйте в программе под Win98 задать координаты больше 2^16. (это мне нужно для отображения рулонных листов в специализированном САПР).
Ещё пример сходу, о котором точно знаю.
Form.TransparencyKey Property ,
...
Remarks
Windows 2000 Platform Note: Transparent windows and regions are only supported under the Windows 2000 operating system.
Ещё примеры искать будем, или вы признаете, что с одинаковостью погорячились .
> Знания — это здорово, расширение возможностей — замечательно, но кроме них есть еще опыт, умения и навыки.
Ну разумеется. Знания и опыт — две стороны одной медали. Но имея знания, по крайней мере , если понадобится, не растеряешься и будешь знать где что искать.
>А можно знать мало, но довести это до совершенства, а скорость и качество написанных программ — до максимума.
Ну это вопрос очень-очень спорный, так как возникают вопросы , а " мало можно знать", чтобы и скорость и качество программ до максимума. Но мне если честно лень спорить по этому вопросу.
> Истина как обычно, где-то посередине...
K>А мое мнение такое, что те, кто грит что Win API мертва и что в будущем .NET ,будет напрямую с ядром взаимодействовать неправда =) Поэтому я больше склоняюсь к первому варианту. Хотя конечно надо знать .NET, но в первую очередь думаю стоит изучить win api.
Здравствуйте, Kisloid, Вы писали:
K>Здравствуйте, VladD2, Вы писали:
VD>>Вообще-то я думал ты поймешь, что я прикалываюсь. Просто уж больно смешно твои вопрсы выглядят.
K>Я понял =)
VD>>Вообще-то MFC-программиста без знаний того что написано в "Windows для профессионалов" программистом то назвать тяжело. Так любитель.
K>Это я тоже понимаю, ну все же, посоветуй VladD2, "Windows для профессионалов" + Страуструп или "Программирование платформы .NET" + книга по C#-у ?
не бывает "или". Не те времена, когда можно позволить себе "или". И то, и другое, однозначно.
K>А мое мнение такое, что те, кто грит что Win API мертва и что в будущем .NET ,будет напрямую с ядром взаимодействовать неправда =) Поэтому я больше склоняюсь к первому варианту. Хотя конечно надо знать .NET, но в первую очередь думаю стоит изучить win api.
Изучать winapi надо, если уровень задачи того требует. Ведь ты же не собираешься изучать или знать PDP11 (хоть знаешь вообще, что это? ) из-за того, что он положил основу чему-то?)
А если вам не нужна легкость программирования на C#, удобная работа с Web, ASP.NET и ADO.NET, опять же, зачем вам C#?
А еще лучше следовать следующему правилу:
знать надо все, а для задачи применять наиболее удобный/подходящий/адекватный вариант.
Здравствуйте, Kisloid, Вы писали:
K>Здравствуйте, VladD2, Вы писали:
VD>>Вообще-то MFC-программиста без знаний того что написано в "Windows для профессионалов" программистом то назвать тяжело. Так любитель.
K>Это я тоже понимаю, ну все же, посоветуй VladD2, "Windows для профессионалов" + Страуструп или "Программирование платформы .NET" + книга по C#-у ?
K>А мое мнение такое, что те, кто грит что Win API мертва и что в будущем .NET ,будет напрямую с ядром взаимодействовать неправда =) Поэтому я больше склоняюсь к первому варианту. Хотя конечно надо знать .NET, но в первую очередь думаю стоит изучить win api.
Чистое IMHO:
"Windows для профессионалов" + Страуструп надо прочитать обязательно, потому что это основы;
"Программирование платформы .NET" + книга по C#-у имеет смысл пролистать, хотя бы для того чтобы значть что это такое и с чем его едят, всё равно все достоинства и недостатки вы сможете оценить только на реальном проекте.
И вообще читайте всё, что вам хоть чуть-чуть интересно и что попадается под руку, всё равно не угадаете, что от вас потребует заказчик
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Это вовсе не значит, что WinAPI мёртв и другим его знать не надо.
Я уж устал говорить, что NET не охватывает все на свете. Но в той части, что он охватывает, api мертв. Вы сами как считаете, с файлами и базами удобнее работать через классы или через хэндлы?
МЮ>И ещё много-много чего.
Можно список? Что не заменит в прикладном программировании NET, кроме задач требовательных к скорости/памяти (паковщики, 3d buhs), плотно интегрированных с системой (антивирусы, расширители shell) и специализированных задач (САПРы)?
МЮ>1. Не ужели я пишу ассемблерные вставки в программы на С++, чтобы затем интерфейс писать на фреймворке. Естественно, что с виндами я взаимодействую через API.
А я-то думал... Понятно. Это следствие.
МЮ>Ещё примеры искать будем, или вы признаете, что с одинаковостью погорячились .
Погорячился. Но все равно хотелось бы увидеть еще примеров.
A>Я уж устал говорить, что NET не охватывает все на свете. Но в той части, что он охватывает, api мертв. Вы сами как считаете, с файлами и базами удобнее работать через классы или через хэндлы?
Через классы работать само собой удобней, но, тем не менее, полезно иногда знать, что такое хенда, как передать хендл из одного процесса в другой и т.д. и т.п. Это, вообще говоря, фундамент, на котором построен dotNet.
A>Можно список? Что не заменит в прикладном программировании NET, кроме задач требовательных к скорости/памяти (паковщики, 3d buhs), плотно интегрированных с системой (антивирусы, расширители shell) и специализированных задач (САПРы)?
Ну а чего со списком баловаться? Обработка видео, звука. Дотнету туба пока далеко. А что всё, что вы перечислили, это мало и хорошие программисты там не нужны?
МЮ>>1. Не ужели я пишу ассемблерные вставки в программы на С++, чтобы затем интерфейс писать на фреймворке. Естественно, что с виндами я взаимодействую через API. A>А я-то думал... Понятно. Это следствие.
Хм. Тем не менее нельзя сказать, что dotNet может здесь мне заменить API.
A>Погорячился. Но все равно хотелось бы увидеть еще примеров.
А чего за ними далёко бегать? Все ограничения Win98 против NT действуют на dotNet. Кстати программы, написанные на Делфи тоже во всех версиях Win работают "одинаково". Однако практически все, кого я знал, пользовались не только VCL но и API.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Через классы работать само собой удобней, но, тем не менее, полезно иногда знать, что такое хенда, как передать хендл из одного процесса в другой и т.д. и т.п. Это, вообще говоря, фундамент, на котором построен dotNet.
Это вообще говоря вопрос. ДА — в той части, где NET — обертка над api. НЕТ — где в NET наколбасили своего. Больше всего изменений в распределенных приложениях. То RPC, потом DCOM, сейчас Remoting, в будущем Web-Service. Для чего например знать эту возню с хендлами в Remoting? Там свои приколы, специфичные и знания api в этой части не момогут. Так что не все там фундамент.
МЮ>Ну а чего со списком баловаться? Обработка видео, звука. Дотнету туба пока далеко. А что всё, что вы перечислили, это мало и хорошие программисты там не нужны?
Хорошие программисты везде нужны.
МЮ>Хм. Тем не менее нельзя сказать, что dotNet может здесь мне заменить API.
NET заменяет там, где начинает играть вопрос удобства. Под NET удобней, там все в классах и namespace-ах.
Здравствуйте, Kisloid, Вы писали:
K>Это я тоже понимаю, ну все же, посоветуй VladD2, "Windows для профессионалов" + Страуструп или "Программирование платформы .NET" + книга по C#-у ?
Собсвтенно тот же рихтер для человека уже знакомого с программированием для виндовс — это оптимальный выбор. Только не "Windows для профессионалов", а ... честно говоря точно не понмню название. Но по дотнету у него только одна книжка, так что не промажешь. Еще очень полезно поглядеть стандарт языка. Там все довольно толково написано. Если пропустить скучьные разделы, то читается почти как книга.
Так же на нашем сатйте есть статьи по основным вопросам (коллекции, вэлью-типы и т.п.). Просто заходи в раздел по дотнету и читай то что больше интересно. Но это уже после того как освоишь рихтера и напушишь три десятка тестовых приложений.
K>А мое мнение такое, что те, кто грит что Win API мертва и что в будущем .NET ,будет напрямую с ядром взаимодействовать неправда =)
Мнение твое с одной стороны верное. Но тем не менее знание дотнета это совсем не то же что знание ВыньАпи. Для программирования на С++ с использованием МФЦ оно нужно намного больше. А для дотнета больше нужно понимание того как работает рантайм. Умение эффективно использовать библиотеки. Библиотеки в дотнете на порядок более большие чем Апи-шные.
K> Поэтому я больше склоняюсь к первому варианту. Хотя конечно надо знать .NET, но в первую очередь думаю стоит изучить win api.
Я бы склонялся ко второму. А еще лучше просто купить и прочесть обе книжки. То же ВыньАпи можно с успехом осваивать и на шарпе. Даже больше знать будешь, так как каждую функцию вручную нужно будет описать для импорта.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Звук, видео,
Ну, тут МС и без нас справится. А АПИ для звука и видео пофигу будет откуда вызвать.
МЮ>САПР,
А что сапр? Такая же прикладнуха как и все остальное. На дотнете так же будет надежнее и проще чем на С++.
МЮ> игры — там dotNet не нужен,
От как раз там то они и нужен. Как минимум какой-нибудь Шарп или ВБ.Нет намного лучше доморощенных скриптов используемых в игрушках. ИЛ2 уже забросил пробный шар — использовал для этого Яву. Рано или поздно кто-то воспользуется дотнето для тех же целей. А потом подумает, а почему бы не писать на дотнете почти всю игру? Ну, вынести там самые низкоуровневые участки в анменеджед-код и все. И скажу по сикрету МС очень даже хочет пропихнуть дотнет в игры.
МЮ> а разработчики, владеющие API — нужны.
Да конечно нужны. Но уже меньше чем 5 лет назад. И с каждым годом будут нужны все меньше и меньше. А когда нибудь глядишь фрэймворк будет восприниматься как основное АПИ и тогда времена Вынь32 пройдут как страшный сон.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Хотите пример? Попробуйте в программе под Win98 задать координаты больше 2^16. (это мне нужно для отображения рулонных листов в специализированном САПР).
Дык в Лонгхорне как раз ГДИ то и станет не нужным. Там будет Авалон который перекроет возможности GDI/User32 и ВинФормс с большим запасам. А все координаты будут с плавающей точкой. Так что прачные прогнозы твоих аппонентов уже сбываются.
Правда можно будет использовать и GDI с User32. Но выгоды ты уже от этого не получишь. Только если с точки зрения совместимости со старыми ОС.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mab, Вы писали:
Mab>1) Нестандартные контролы. То, что предлагает WinForms, мягко говоря недостаточно. Тот же самый virtual list view пришлось руками делать.
Во втором фрэймворке обернут и виртуальный режим. К тому же нет проблем написать свой виртуальный грид. Тут АПИ только проиграет.
Mab>1') Доступ к GDI, которое практически в FW не представлено (разве что ControlPaint-ом). GDI+ не подходил из-за соображений скорости.
Опять же во втором фрэймворке обернуты основные функции и не можно легко обойтись без использования ГДИ напрмямую.
А если вспомнить о Лонгхорне, то становится понятным, что рано или поздно ГДИ и Юзер32 вымрут как динозавры.
Mab>2) Управление процессами (запуск с флагом DEBUG_PROCESS, отслеживание расходуемых ресурсов итп). Класс Process здесь малополезен.
Есть менеджед-дебаг-апи. Его более чем достаточно для этих целей. Просто это настолько экзотично, что моло кто о нем знает.
Mab>3) Memory mapped files. Часть проекта частично делали на MC++ , часть вообще на unmanaged C++ и подцепляли через pinvoke.
Это зачем же нужны MMF если есть МС++?
Ну, и где ты видел обертки над MMF? Можно ссылочку?
Mab>Каждый может дополнить этот список в соответствии с собственным опытом
Да может конечно. Только тенденция то однозначаная. Все меньше и меньше мест где Вынь32АПИ нужно. Так что рано или поздно 99% приложений будут писаться на дотнете без ВыньАПИ.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
И это многое объясняет, не правда ли?
Какой смысл мне вам рассказывать, если вам это не пригодится? 
.
