Прочитал случайно про WinFX и что майкрософт собирается заменить им WinAPI в будущем. Скачал какой-то betta release WinFX SDK. Посмотрел что он там умеет и......ничего не нашёл, кроме какой-то XAML попсы для интерфейсов. А найти я там хотел какое-ньть подобие на WinAPI, ну хотя б ту же функцию FindWindow. Вот тут и вопрос возникает, что они себе там думают и как писать системное ПО в .NET? На managed C++?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, King of a Stellar War, Вы писали:
KOA>Прочитал случайно про WinFX и что майкрософт собирается заменить им WinAPI в будущем. Скачал какой-то betta release WinFX SDK. Посмотрел что он там умеет и......ничего не нашёл, кроме какой-то XAML попсы для интерфейсов. А найти я там хотел какое-ньть подобие на WinAPI, ну хотя б ту же функцию FindWindow. Вот тут и вопрос возникает, что они себе там думают и как писать системное ПО в .NET? На managed C++?
Нда. Много еще прйдется сломать стереотипов. Ну, да ладно. Так как времени на ломку нет, то по верхам:
1. ВыньАПИ не отменяется. Весь софт написанный ранее будет пазать как часы. Просто его больше не будут особо развивать. Открою один сикрет. Его практически не развивают с времен NT 3.51. Ну, там КОМ/ДКОМ/СОМ+ появился, но они в общем-то к ВыньАПИ отношение не имеют. Так что по мелочи АПИ конечно развиваться будет и дальше, но и только.
2. Новый АПИ просто позволит писать программы быстрее, проще и с большим количеством финтифлюшек. Например, Авалон позволит делать динамические ГУИ круче чем во Флэше от Макромедии.
3. Новых АПИ будт три: а) Аэро/Авалон — 3D-ГУИ плюс иерархия компонетов/контролв созданная чисто на дотнете, б) Индиго — комуникации (КОМ+/МСМКЮ и т.п. не отменяются, но по будет и новый менеджед-АПИ который позволит наладить комуникацию и без них, но и их задействовать мозволит), в) WinFS — объектно-ориентированная файловая система (она будет позже и будет являться чем-то вроде O/R Maping-а).
4. Новый АПИ уже есть. Основа WinFX — это банальный .Net Framwork следующих версий. Просто маркитологи из МС не могут не обойтись без супер-сенсаций. Сенсации эти в основном рассчитаны на юзыерей, а приличному программисту покупаться на них является не очень разумно . Для программистов сделан вот этот ресурс: http://WinFX.msdn.microsoft.com/
5. Надо отучаться от стериотипов, что:
* АПИ должно быть на С.
* ГУИ дожно состаять из окон.
Теперь АПИ — это просто ОО-библиотека. Окон в Авалоне нет, хотя они и могут использоваться для совместимости со старыми контролами, например, WinForms-овыми.
Испоьзовать новые АПИ можно будет из любого языка программирования способного породить управляемый код. Проще всего конечно это будет делать из C# или VB.Net, но можно и из МС++. В общем-то разница не вилека. Чуть больше шума.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
1. Насколько я помню когда читал документацию по WinFX единицей управления графическими объектами остаётся окно с его HWND. Просто предоставляются боле высокоуровневые механизмы управления, например logic tree.
2. Допустим Avalon с XAML и 3D таки выйдет в свет. Наверняка соответствующим образом озменится Explorer. Так вот, через какие вызовы/классы эксплорер сможет управлять всеми объектами на экране, если Avalon (вроде) такой функциональности не предоставляет? В WinAPI это было просто, например для перескакиваня по окнам — EnumWindows + ShowWindow, а в Avalone на .NET как можно реализовать подобный механизм?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, VladD2, Вы писали:
VD>5. Надо отучаться от стериотипов, что: VD>* АПИ должно быть на С.
Действительно, с чего бы это... то что сама операционка написана на C и у большинства программистов, пишущих под неё основным языком является C — это типа ещё не показатель...
VD>Теперь АПИ — это просто ОО-библиотека.
Ну и что? В соляре гуя тоже объектно-ориентированная, но это не мешает использовать её из множества языков...
VD>Испоьзовать новые АПИ можно будет из любого языка программирования способного породить управляемый код. Проще всего конечно это будет делать из C# или VB.Net, но можно и из МС++.
Вот-вот... Похоже в майкрософт нашли фатальный недостаток во всех языках программирования — их придумали не они! Вместо того чтобы наконец-то правильно реализовать компилятор того же C++, они просто решили убить этот язык (я за одно и все остальные) — браво! Вот интересно, как будет выглядеть реализация meneged Fortran-90...
Когда M$ насаждала мне под какую ОС писть — я терпел, когда она насаждала мне технологии которыми пользоваться — я терпел, когда она насаждала мне свои стандарты — я тоже терпел, но теперь она пытается заставить меня писать на том языке, который удобен ей — извинте, но терпение кончается!
Вообще всё это похоже на попытку отпилить сук на котором сидишь... Я вот не думаю, что вся армия Win-программистов выстроиться по струнке и как послушные собачки перейдут на C#, потому что так хочет Билли Ворота — читать здесь! Я скорее переориентируюсь под WEB или уйду в Unix — это будет проще, по крайней мере язык переучивать не надо будет. Технологии в Longhorn`е всё равно новые для всех будут, а под Unix я хоть чуть-чуть да писал когда-то...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Mr. None, Вы писали:
MN>Когда M$ насаждала мне под какую ОС писть — я терпел, когда она насаждала мне технологии которыми пользоваться — я терпел, когда она насаждала мне свои стандарты — я тоже терпел, но теперь она пытается заставить меня писать на том языке, который удобен ей — извинте, но терпение кончается!
Какой милый религиозный фанатизм!
А чем C# не устроил? C++ хорош, но компилятор для него хороший создать — задача более, чем нетривиальная Кроме того, под дотъ-нэтъ масса языков есть, помимо упомянутых Владом...
Mr. None,
> VD> Испоьзовать новые АПИ можно будет из любого языка программирования способного породить управляемый код. Проще всего конечно это будет делать из C# или VB.Net, но можно и из МС++.
> Вот-вот... <...>
Не заводись Влад (осознанно, или нет) преувеличивает: из C++/CLI использовать новые API .Net будет по меньшей мере в той же степени удобно, как и из C# или VB.Net.
> Похоже в майкрософт нашли фатальный недостаток во всех языках программирования — их придумали не они! Вместо того чтобы наконец-то правильно реализовать компилятор того же C++, они просто решили убить этот язык <...>
Не надо так эмоционально. Факт жизни состоит в том, что на деле MS делает для C++ достаточно много, чтобы сказать им за это спасибо. Да, еще достаточно недавно это было не так, но времена быстро меняются, и, имхо, это сложно не заметить.
> Когда M$ насаждала мне под какую ОС писть — я терпел, когда она насаждала мне технологии которыми пользоваться — я терпел, когда она насаждала мне свои стандарты — я тоже терпел, но теперь она пытается заставить меня писать на том языке, который удобен ей — извинте, но терпение кончается!
Cool it Нравится писать на C++ — пиши на C++, не нравится — подбери себе язык по вкусу из доступных под .Net — благо, недостатка не видно, и чем дальше, тем больше. В частности, чтобы сделать удобной разработку под .Net на C++, команда VC++ потратила как минимум целый цикл разработки своего продукта. Ребята вложились от души, enjoy.
> Вообще всё это похоже на попытку отпилить сук на котором сидишь...
Это хорошо согласуется с тем, что они сами говорят. Именно поэтому MS этого не сделает
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Не заводись ПК>Не надо так эмоционально.
Самое смешное, что тут действительно больше эмоций, чем прагматичекой логики . Просто меня немного раздражает, когда люди начинают заявлять: типа через пару лет будет один .NET и все будут писать на шарпе ! Не будет и не будут. Я прекрасно понимаю, что M$ никогда (по крайней мере в ближайшие лет 5 — 10 точно) не сможет перевести полностью весь АПИ на .NET и при этом оставить обратную совместимость со всем, что было. А раз не смогут, то им будут продолжать пользоваться по крайней мере те, которым в силу особенности языка не удобно использовать .NET и менеджед расширения. И трюк, который МС провернула для замены Win16 на Win32 не пройдёт — тогда она не предлагали сотням тысяч программеров сменить основной язык, на котором они пишут...
ПК>Cool it Нравится писать на C++ — пиши на C++, не нравится — подбери себе язык по вкусу из доступных под .Net — благо, недостатка не видно, и чем дальше, тем больше.
А если идеология языка не совпадает с идеологией .NET?
- И все будут жить счастливыми!
— А если кто-то не захочет жить счастилвым?
— Тогда он умрёт — все желания должны исполняться.
"Формула Любви".
Или будет как с OpenGL? Идеология OpenGL не совпадала с идеологией Windows в области графики и не совпадала с идеологией маркетингового отдела MS, которому больше нравился свой стандарт — Direct 3D. Но поддерживать OpenGL надо было, потому как иначе некузяво и решение было найдено — реализовать OpenGL как надстройку над Direct 3D и не важно, что "летающий" под Unix`ом OpenGL под Windows стал тормознее моей первой реализации алгоритма заливки методом Гуро. Итог, кто теперь использует OpenGL под Windows там, где нужна действительно быстрая графика?
ПК>В частности, чтобы сделать удобной разработку под .Net на C++, команда VC++ потратила как минимум целый цикл разработки своего продукта. Ребята вложились от души, enjoy.
А вот я слышал и этот слух ни как не опровергается отделом маркетинга MS (но надо отдать должное и не подтверждается — в духе совесткой дипломатии времён Карибского кризиса ), что MC++ в дальнейшем не будет ни развиваться, ни поддерживаться, и нужен он только для того, чтобы программисты пишушие на C++ легко перешли на .NET и в дальнейшем на C#... Типа demo-версия возможностей .NET для плюсов...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Mr. None пишет:
> Или будет как с OpenGL? Идеология OpenGL не совпадала с идеологией > Windows в области графики и не совпадала с идеологией маркетингового > отдела MS, которому больше нравился свой стандарт — Direct 3D. Но > поддерживать OpenGL надо было, потому как иначе некузяво и решение > было найдено — реализовать OpenGL как надстройку над Direct 3D и не > важно, что "летающий" под Unix`ом OpenGL под Windows стал тормознее > моей первой реализации алгоритма заливки методом Гуро. Итог, кто > теперь использует OpenGL под Windows там, где нужна действительно > быстрая графика?
Софтовый OpenGL в винде тормозил из-за того, что использовал GDI.
Аппаратные реализации OpenGL для Винды сейчас так же быстро работают,
как и DX.
Здравствуйте, Mr. None, Вы писали:
MN>Или будет как с OpenGL? Идеология OpenGL не совпадала с идеологией Windows в области графики и не совпадала с идеологией маркетингового отдела MS, которому больше нравился свой стандарт — Direct 3D. Но поддерживать OpenGL надо было, потому как иначе некузяво и решение было найдено — реализовать OpenGL как надстройку над Direct 3D и не важно, что "летающий" под Unix`ом OpenGL под Windows стал тормознее моей первой реализации алгоритма заливки методом Гуро. Итог, кто теперь использует OpenGL под Windows там, где нужна действительно быстрая графика?
Вот не надо OpenGL работает также быстро как Д3Д если драйверы на видюху поставить. Причина тут в другом... дело в том что с OpenGL таже фигня что и с С++... Как нет двух одинаковых С++ компиляторов так и нет двух одинаковых OpenGL под разные видюхи... Загляни в тотже boost как там его учат работать с разными компиляторами... а потом вспомни что различных видюх гораздо больше чем С++ компиляторов...
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Mr. None, Вы писали:
WH>Вот не надо OpenGL работает также быстро как Д3Д если драйверы на видюху поставить.
Тогда объясните мне, почему под тем же Linux`ом со скоростью у него всегда было всё впорядке, даже пошустрее Д3Д был. И реализации первые у него были софтовые, а не аппаратные. Даже игры полностью на нём пишут... А под виндой драйвера нужны, аппаратная поддержка, а если нет ни того ни другого — пожалуйста юзай как прослойку над Д3Д или вообще GDI...
Это сейчас он может быстро работает, если есть аппаратная поддержка, а когда я его впервые использовал (5 лет назад) — тормоза аткие были, что просто атас!
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Cyberax, Вы писали:
C>Софтовый OpenGL в винде тормозил из-за того, что использовал GDI. C>Аппаратные реализации OpenGL для Винды сейчас так же быстро работают, C>как и DX.
См. в ответе WolfHound`у
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Mr. None пишет:
> WH>Здравствуйте, Mr. None, Вы писали: > WH>Вот не надо OpenGL работает также быстро как Д3Д если драйверы на > видюху поставить. > Тогда объясните мне, почему под тем же Linux`ом со скоростью у него > всегда было всё впорядке, даже пошустрее Д3Д был. И реализации первые > у него были софтовые, а не аппаратные. Даже игры полностью на нём > пишут... А под виндой драйвера нужны, аппаратная поддержка, а если нет > ни того ни другого — пожалуйста юзай как прослойку над Д3Д или вообще > GDI...
Потому что первые версии OpenGL работали еще в Win3.11, в которой не
было нормального прямого доступа к видеопамяти (типа поверхностей DX).
Причем OpenGL без проблем интероперирует с GDI в Винде, так как
создавался не для игр, а для качественной 3D-графики.
> Это сейчас он может быстро работает, если есть аппаратная поддержка, а > когда я его впервые использовал (5 лет назад) — тормоза аткие были, > что просто атас!
Mr. None,
> ПК> Cool it Нравится писать на C++ — пиши на C++, не нравится — подбери себе язык по вкусу из доступных под .Net — благо, недостатка не видно, и чем дальше, тем больше.
> А если идеология языка не совпадает с идеологией .NET?
А если удачно совместить?
> ПК> В частности, чтобы сделать удобной разработку под .Net на C++, команда VC++ потратила как минимум целый цикл разработки своего продукта. Ребята вложились от души, enjoy.
> А вот я слышал и этот слух ни как не опровергается отделом маркетинга MS (но надо отдать должное и не подтверждается — в духе совесткой дипломатии времён Карибского кризиса ), что MC++ в дальнейшем не будет ни развиваться, ни поддерживаться, и нужен он только для того, чтобы программисты пишушие на C++ легко перешли на .NET и в дальнейшем на C#... Типа demo-версия возможностей .NET для плюсов...
Не надо путать MC++ и C++/CLI. По поводу отношения MS к своему детищу ссылки уже приводились
. C++/CLI позиционируется компанией Microsoft как системный язык для .Net. Напротив, от перехода на C#, если нравится С++, мягко, но регулярно отговаривают:
In the years since the .NET Framework, the CLR, and C# were announced, many developers have wondered about Microsoft's plans for C++. Some have speculated that C# is a replacement for C++, but it most certainly is not. C# is a language that is easier to learn than C++, and provides access to the functionality of the CLR. For those who already know C++, there's no need to learn anything to gain access to the functionality of the CLR, and C++ has features that are not in C#, so moving would actually involve giving up some power.
Intel тоже принимает посильное участие в продвижении C++/CLI:
Finally, perhaps the most important reason for a .NET programmer to learn C++/CLI is the observation with which this article began: no language is mentioned more in job ads than C++. Knowledge of C++ opens up the broadest range of programming positions on the broadest range of platforms. C++/CLI, which allows one to defer tackling the complexities of memory management while enjoying the powerful and familiar libraries of .NET, may be the ideal stepping-stone into this common language of professional software development.
В той же статье есть интересное наблюдение о том, что IBM также является членом технической группы ECMA, работающей над спецификацией C++/CLI, что дает серьезные основания подозревать их в наличии практического интереса к данному языку.
Ща в меня справедливо полетят помидоры за ссылки на откровенно маркетинговые статьи; оправданием мне служит то, что речь как раз и идет о маркетинге
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
P.S.
ПК>В той же статье есть интересное наблюдение о том, что IBM также является членом технической группы ECMA, работающей над спецификацией C++/CLI, что дает серьезные основания подозревать их в наличии практического интереса к данному языку.
Еще интереснее взглянуть на сам список компаний, пожелавших участвовать в работе TC39-TG5 (группа ECMA, занимающаяся C++/CLI):
Borland
Dinkumware
Edison Design Group
Hitachi
IBM
Indiana University
Intel
Microsoft
Plum Hall
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
MN>Самое смешное, что тут действительно больше эмоций, чем прагматичекой логики . Просто меня немного раздражает, когда люди начинают заявлять: типа через пару лет будет один .NET и все будут писать на шарпе !
Самое смешное, что совсем недавно тоже самое говорили программисты на асм про с/с++ и другие не асм языки
... <<silent RSDN@Home 1.1.4 beta 4 [303] Windows XP 5.1.2600.0 >>
DEMON HOOD,
> MN> Самое смешное, что тут действительно больше эмоций, чем прагматичекой логики . Просто меня немного раздражает, когда люди начинают заявлять: типа через пару лет будет один .NET и все будут писать на шарпе !
> Самое смешное, что совсем недавно тоже самое говорили программисты на асм про с/с++ и другие не асм языки
Здравствуйте, tarkil, Вы писали:
T>Здравствуйте, Mr. None, Вы писали:
MN>>Когда M$ насаждала мне под какую ОС писть — я терпел, когда она насаждала мне технологии которыми пользоваться — я терпел, когда она насаждала мне свои стандарты — я тоже терпел, но теперь она пытается заставить меня писать на том языке, который удобен ей — извинте, но терпение кончается!
T>Какой милый религиозный фанатизм!
T>А чем C# не устроил? C++ хорош, но компилятор для него хороший создать — задача более, чем нетривиальная
Помнится, Влад тут с пеной у рта доказывал, что, С# отпарсить куда сложнее, чем C++.
Ну а если серьёзно -- простота компилятора практически автоматически означает низкую выразительную силу языка, т.е. больше работы программисту потом.
T>Кроме того, под дотъ-нэтъ масса языков есть, помимо упомянутых Владом...
Ты не поверишь, но до появления дот-нета языков программирования было гораздо больше, чем тех, для которых есть дот-нет реализация сейчас.
Здравствуйте, Cyberax, Вы писали:
C>Потому что первые версии OpenGL работали еще в Win3.11, в которой не C>было нормального прямого доступа к видеопамяти (типа поверхностей DX). C>Причем OpenGL без проблем интероперирует с GDI в Винде, так как C>создавался не для игр, а для качественной 3D-графики.
А под Unix`ом их (поверхностей DX) вообще не было и работал он там прекрасно в теже самые времена. И использовался он там в том числе и для игр (все версии Quake под Unix`ом работают на OpenGL).
>> Это сейчас он может быстро работает, если есть аппаратная поддержка, а >> когда я его впервые использовал (5 лет назад) — тормоза аткие были, >> что просто атас!
C>Из-за GDI.
И никакой GDI под Unix`ом ему не мешал...
Из всего этого можно сделать один вывод — OpenGL по каким-то причинам не удобен M$ (он содержит фатальный недостаток — его придумали не они!), поэтому его реализации под Windows неудобны и неконкурентно способны с аналогичными технологиями от самой MS (DirectX, GDI и пр.). Вот как бы не случилось тоже под .NET с языками программирования, которые придумал не Майкрософт и идеология которых идёт в разрез с идеологией .NET...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Павел Кузнецов, Вы писали:
>> ПК> Cool it Нравится писать на C++ — пиши на C++, не нравится — подбери себе язык по вкусу из доступных под .Net — благо, недостатка не видно, и чем дальше, тем больше.
>> А если идеология языка не совпадает с идеологией .NET?
ПК>А если удачно совместить?
Это не всегда возможно...
Пример. Фортран: основная идеология и достоинство — очень быстрые вычисления. Все его внутренние библиотеки и компиляторы оптимизированы именно на это. Ради этого выкидывается всё, что может затормозить — проверки, универсальность; он даже динамическую память не поддерживает (по крайней мере до Фортран-80 было именно так... что там с Фортран-90 не знаю — с ним уже не работал), как следствие в нём нет понятий указателей, ссылок, объектов, классов и т.д. и т.п. Вот скажите как удачно совместить его с .NET не разрабатывая спецификацию нового языка, как в случае с VB .NET и сохранить основное достоинство — быстрые вычисления (скажем любая проверка на выход за границы массива уже противоречит этой идеологии).
>> А вот я слышал и этот слух ни как не опровергается отделом маркетинга MS (но надо отдать должное и не подтверждается — в духе совесткой дипломатии времён Карибского кризиса ), что MC++ в дальнейшем не будет ни развиваться, ни поддерживаться, и нужен он только для того, чтобы программисты пишушие на C++ легко перешли на .NET и в дальнейшем на C#... Типа demo-версия возможностей .NET для плюсов...
ПК>Не надо путать MC++ и C++/CLI. По поводу отношения MS к своему детищу ссылки уже ПК> ...
Вы меня успокоили, спасибо
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
. Для программистов сделан вот этот ресурс: http://WinFX.msdn.microsoft.com/
! Не будет и не будут. Я прекрасно понимаю, что M$ никогда (по крайней мере в ближайшие лет 5 — 10 точно) не сможет перевести полностью весь АПИ на .NET и при этом оставить обратную совместимость со всем, что было. А раз не смогут, то им будут продолжать пользоваться по крайней мере те, которым в силу особенности языка не удобно использовать .NET и менеджед расширения. И трюк, который МС провернула для замены Win16 на Win32 не пройдёт — тогда она не предлагали сотням тысяч программеров сменить основной язык, на котором они пишут...
), что MC++ в дальнейшем не будет ни развиваться, ни поддерживаться, и нужен он только для того, чтобы программисты пишушие на C++ легко перешли на .NET и в дальнейшем на C#... Типа demo-версия возможностей .NET для плюсов...
