Eugene Agafonov on the .NET
Блог Евгения Агафонова
[ANN] WinRT - новое компонентное API для Windows 8
15.09.2011
|
Gollum |
Я тут попробовал описать свои впечатления от WinRT
Честно, даже не знаю куда отправить По логике вещей это надо в COM, или C++. Но что-то мне кажется, что это нужно в первую очередь в .NET, так как по идее, это то, что нас всех ждет в самом ближайшем будущем. Копирую сообщение сюда, чтобы в блог было необязательно ходить Сиплюсплюсник из меня аховый, конечно, если что — поправляйте.
После второго дня конференции сложилось впечатление, что ходить нужно только на сессии про С++. Все остальное лишь показывает, как использовать новые API WinRT, но при этом остается непонятно, как собственно этот WinRT устроен. Я напишу, как понял сам
Итак, WinRT — это COM следующей версии. В общем, это и неудивительно, учитывая что Steven Sinofsky делал и предыдущую версию. Плюс к этому, WinRT использует расширения C++, как стандарта 11, так и собственные. Некоторой частью эти расширения похожи на расширения managed C++, но не нужно их путать. WinRT не использует CLR, и несмотря на то, что синтаксис местами одинаковый (например, Search::QueryOptions^), в WinRT это означает совсем другое. Для начала, чтобы создать библиотеку WinRT, используется ключ компилятора /ZW (чтоб никто не догадался), в то время как для managed C++ нужно использовать ключ /clr.
Как же выглядит код на C++ для WinRT? Примерно так:
Первое, что тут бросается в глаза — это ref new. В документации написано, что таким образом мы получаем smart pointer, который автоматически уменьшает счетчик ссылок, когда объект выходит из области видимости. То есть, это тот же COM. Пока не ясно, предпринято ли что-нибудь для решения проблемы циклических ссылок, и что именно это за указатели (думаю, что std::shared_ptr). Сборщика мусора здесь, как такового, нет.
Ключевое слово auto как раз из нового стандарта С++ 11, это вывод типа, по смыслу аналогичный var в С#. Язык шагнул очень далеко вперед — появились такие вещи, как лямбды (с поддержкой замыканий, но их надо явно описывать) и туплы (видимо чтобы была хоть какая-то замена анонимным типам).
В WinRT есть хитрый маршаллинг, благодаря чему можно в C# итерироваться по вектору из C++ кода WinRT компоненты. Как я понимаю, это достигается тем, что на типы WinRT наложен ряд жестких ограничений. Подробно про это можно посмотреть здесь: http://msdn.microsoft.com/en-us/library/windows/apps/hh454062(v=VS.85).aspx. Если укладываться в рамки ограничений, то можно использовать любые нативные библиотеки для разработки своих компонентов WinRT, и это очень здорово.
Все типы WinRT наследуются от Platform::Object.Мне пока нигде не удалось найти, что этот тип содержит, но логика подсказывает, что он должен выполнять базовую поддержку <b>IInspectable</b> — нового фундаментального интерфейса, который отвечает за получение метаданных типа. На слайдах также было нарисовано, что все типы WinRT реализуют IUnknown (что, в общем-то, неудивительно). Метаданные WinRT типов лежат в некоторой системной директории Windows, и имеют расширение winmd. Эти метаданные можно открывать ildasm'ом, они имеют стандартный дотнетный формат.
На мой взгляд, это пока главное, что нужно понимать про WinRT. Конечно, там еще огромное количество всего — C++-ые свойства, делегаты, события. Специальная работа со строками — в WinRT для этого свой тип, и т.п., все это можно прочитать по ссылке выше (хотя информации пока немного, надеюсь будут обновлять оперативно). Но самое главное уже более-менее понятно. Перед нами новая версия COM.
Честно, даже не знаю куда отправить По логике вещей это надо в COM, или C++. Но что-то мне кажется, что это нужно в первую очередь в .NET, так как по идее, это то, что нас всех ждет в самом ближайшем будущем. Копирую сообщение сюда, чтобы в блог было необязательно ходить Сиплюсплюсник из меня аховый, конечно, если что — поправляйте.
После второго дня конференции сложилось впечатление, что ходить нужно только на сессии про С++. Все остальное лишь показывает, как использовать новые API WinRT, но при этом остается непонятно, как собственно этот WinRT устроен. Я напишу, как понял сам
Итак, WinRT — это COM следующей версии. В общем, это и неудивительно, учитывая что Steven Sinofsky делал и предыдущую версию. Плюс к этому, WinRT использует расширения C++, как стандарта 11, так и собственные. Некоторой частью эти расширения похожи на расширения managed C++, но не нужно их путать. WinRT не использует CLR, и несмотря на то, что синтаксис местами одинаковый (например, Search::QueryOptions^), в WinRT это означает совсем другое. Для начала, чтобы создать библиотеку WinRT, используется ключ компилятора /ZW (чтоб никто не догадался), в то время как для managed C++ нужно использовать ключ /clr.
Как же выглядит код на C++ для WinRT? Примерно так:
using namespace Windows::Storage;
Search::QueryOptions^ options = ref new Search::QueryOptions(Search::CommonFileQuery::DefaultQuery, nullptr);
options->FolderDepth = Search::FolderDepth::Deep;
auto query = KnownFolders::PicturesLibrary->CreateFileQueryWithOptions(options);
Первое, что тут бросается в глаза — это ref new. В документации написано, что таким образом мы получаем smart pointer, который автоматически уменьшает счетчик ссылок, когда объект выходит из области видимости. То есть, это тот же COM. Пока не ясно, предпринято ли что-нибудь для решения проблемы циклических ссылок, и что именно это за указатели (думаю, что std::shared_ptr). Сборщика мусора здесь, как такового, нет.
Ключевое слово auto как раз из нового стандарта С++ 11, это вывод типа, по смыслу аналогичный var в С#. Язык шагнул очень далеко вперед — появились такие вещи, как лямбды (с поддержкой замыканий, но их надо явно описывать) и туплы (видимо чтобы была хоть какая-то замена анонимным типам).
В WinRT есть хитрый маршаллинг, благодаря чему можно в C# итерироваться по вектору из C++ кода WinRT компоненты. Как я понимаю, это достигается тем, что на типы WinRT наложен ряд жестких ограничений. Подробно про это можно посмотреть здесь: http://msdn.microsoft.com/en-us/library/windows/apps/hh454062(v=VS.85).aspx. Если укладываться в рамки ограничений, то можно использовать любые нативные библиотеки для разработки своих компонентов WinRT, и это очень здорово.
Все типы WinRT наследуются от Platform::Object.Мне пока нигде не удалось найти, что этот тип содержит, но логика подсказывает, что он должен выполнять базовую поддержку <b>IInspectable</b> — нового фундаментального интерфейса, который отвечает за получение метаданных типа. На слайдах также было нарисовано, что все типы WinRT реализуют IUnknown (что, в общем-то, неудивительно). Метаданные WinRT типов лежат в некоторой системной директории Windows, и имеют расширение winmd. Эти метаданные можно открывать ildasm'ом, они имеют стандартный дотнетный формат.
На мой взгляд, это пока главное, что нужно понимать про WinRT. Конечно, там еще огромное количество всего — C++-ые свойства, делегаты, события. Специальная работа со строками — в WinRT для этого свой тип, и т.п., все это можно прочитать по ссылке выше (хотя информации пока немного, надеюсь будут обновлять оперативно). Но самое главное уже более-менее понятно. Перед нами новая версия COM.
15.09.2011 257 комментариев |
http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/17/under-the-covers-of-winrt-using-c.aspx
G>Я тут попробовал описать свои впечатления от WinRT
Я в шоке. Нет слов. Это какое-то чудовищное г..но. Какой же это C++? Зачем они изменили синтаксис? Это не C++ и не дотнет. Какая-то технология-выродок с языком-мутантом.
Главные вопросы, которые у меня возникают: "WTF?" и "нафига?", а также "нафига?!", "нафига?!!" и "нафига?!!!".
Что ж это такое будет-то? Получается какая-то еще одна какая-то непонятная платформа со своим собственным довольно поганым языком (никакой это, конечно же, не C++).
Reference counting? Вы меня шутите? И для reference counting'а делать синтаксические расширения?
COM? В 2011 году? Они там совсем долбанулись?
Я бы понял, если бы они все перевели на дотнет, понял бы если бы они все сделали на C++, но эту хрень я не понимаю совершенно.
У меня нет больше никаких слов, кроме матных. Товарища Синофского надо подвесить за определенную часть тела и больше никогда не подпускать к компьютеру.
А>Reference counting? Вы меня шутите? И для reference counting'а делать синтаксические расширения?
Я в общем-то такого же мнения обо всём, но чем не угодил то ref counting?
А>>Reference counting? Вы меня шутите? И для reference counting'а делать синтаксические расширения?
F> Я в общем-то такого же мнения обо всём, но чем не угодил то ref counting?
Ну, вообще, это сложная и обширная тема, но коротко можно сказать, что, на мой взгляд, tracing garbage collection это более совершенная и эффективная техника (хотя ее эффективность сильно зависит от реализации), чем reference counting, особенно это касается многопроцессорных систем. И в дотнете выбрали tracing collection неспроста.
Хотя, если Микрософт использует эту свою наработку, то все еще не так плохо.
Но, учитывая, что там COM, возникают некоторые сомнения в том, что эффективность этого решения будет достойной и, тем более, сравнимой с эффективностью сборки мусора в дотнете.
Ну и очень не хотелось бы сталкиваться с дурацкой проблемой циклических ссылок. Хорошо, если они там ее решили.
Но главная причина для возмущения, конечно же, то, что Микрософт столько лет пилил свой дотнет с полноценной сборкой мусора и развитой компонентной моделью, а теперь вдруг выродил этого уродца. Какое-то непонятное дублирование технологий и шаг назад.
С ужасом вспоминаю COM — это, наверное, одна из самых говенных технологий программирования, с которой мне доводилось работать. Это был настоящий ад. По сравнению с ним дотнет и C# — как переход из тени в свет. И тут — на тебе! опять к старым баранам.
Кстати, я сейчас колупаюсь именно с reference counting'ом в C++, изучаю научные работы на эту тему, пытаясь в неравной битве побороть циклические ссылки, улучшить его производительность и подружить с многопоточностью. Скорее всего, ничего достойного не выйдет.
А>Кстати, я сейчас колупаюсь именно с reference counting'ом в C++, изучаю научные работы на эту тему, пытаясь в неравной битве побороть циклические ссылки, улучшить его производительность и подружить с многопоточностью. Скорее всего, ничего достойного не выйдет.
Не можешь — ну не колупайся.
Все там нормально. И все друг с другом дружит. В том числе — reference counting и многопоточность (по моему скромному мнению — второе без первого, это перевод
денегвремени). Справа от моего имени есть ссылочка на нефиговый по размерам проект, где все это (COM/MT/ref count) согласованно работает вместе без каких либо проблем.Правда надо
дружить с головойпонимать с чем имеешь делоPS. "Научные работы" — это ты наверное речь для
детского саданеискушенного слушателя готовил?PSS. У меня был еще более крупный проект чем провайдер (он был его мааааленькой частью), тоже C++/COM/ref count — но там (в плане сложности самой природы задачи) был полный мрак. Но все работало без AV/утечек/зависаний и прочих нелепых ужосов
----
Да. Я развлекаюсь с .NET потому что скучно.
КД>Не можешь — ну не колупайся.
КД>Все там нормально. И все друг с другом дружит. В том числе — reference counting и многопоточность (по моему скромному мнению — второе без первого, это перевод
денегвремени). Справа от моего имени есть ссылочка на нефиговый по размерам проект, где все это (COM/MT/ref count) согласованно работает вместе без каких либо проблем.Вопрос в том, сколько потребовалось времени, чтобы оно начало согласовано и без проблем работать. Автор ведь имел ввиду сложность решения. Понятно, что и с reference counting можно жить. Но это очевидный шаг назад по-сравнению со сборщиком мусора в .Net. Не люблю кивать в сторону Apple, но у них наоборот появился сборщик мусора для Objective-C, который до этого жил только с reference counting на naming conventions.
КД>>Не можешь — ну не колупайся.
КД>>Все там нормально. И все друг с другом дружит. В том числе — reference counting и многопоточность (по моему скромному мнению — второе без первого, это перевод
денегвремени). Справа от моего имени есть ссылочка на нефиговый по размерам проект, где все это (COM/MT/ref count) согласованно работает вместе без каких либо проблем.MM>Вопрос в том, сколько потребовалось времени, чтобы оно начало согласовано и без проблем работать.
Скажу про то, что знаю — что бы заставить согласованно и без проблем работать (драйвер базы данных) требуется колоссальные усилия и затраты. Которые хрена лысого сократятся если задействовать супер-пупер технологии/ЯП.
Впрочем, если бы не компилятор C++ из VS2005 — проект бы помер
И оно везде так. Было и будет.
Чтобы они там не родили — этим можно будет пользоваться через 10 лет, когда у них все устаканится. К этому моменту, они (как обычно) объявят это устаревшим и начнут все сначала
КД>Скажу про то, что знаю — что бы заставить согласованно и без проблем работать (драйвер базы данных) требуется колоссальные усилия и затраты. Которые хрена лысого сократятся если задействовать супер-пупер технологии/ЯП.
Непонятно, почему мы все должны возиться с подсчетом ссылок лишь потому, что это устраивает драйвер Interbase
Смайлик, в основном, вот за это высказывание:
КД>Справа от моего имени есть ссылочка на нефиговый по размерам проект, где все это (COM/MT/ref count) согласованно работает вместе без каких либо проблем.
Не обижайся, но только использование КОМ и С++ позволило вам сделать из провайдера к СУБД "нефиговый по размерам проект". На самом же деле провайдер к БД это весьма примитивный и незначительный по размерам проект. Но для этого, правда, надо
дружить с головойпонимать с чем имеешь делоДля примера объем кода одного из самых сложный языков программирования занимает около двух мегабайт.
КД>>Справа от моего имени есть ссылочка на нефиговый по размерам проект, где все это (COM/MT/ref count) согласованно работает вместе без каких либо проблем.
VD>Не обижайся, но только использование КОМ и С++ позволило вам сделать из провайдера к СУБД "нефиговый по размерам проект". На самом же деле провайдер к БД это весьма примитивный и незначительный по размерам проект. Но для этого, правда, надо
дружить с головойпонимать с чем имеешь делоДа ну нафиг. Чего обижаться то Я же помню — лет шесть (или уже восемь?) мы с тобой уже общались на эту тему.
Ты просто не в теме.
VD>Для примера объем кода одного из самых сложный языков программирования занимает около двух мегабайт.
Это тот самый?
А>С ужасом вспоминаю COM — это, наверное, одна из самых говенных технологий программирования, с которой мне доводилось работать. Это был настоящий ад. По сравнению с ним дотнет и C# — как переход из тени в свет.
Согласен. технология была ужасная. Технология ради технологии, но пользоваться ею было невозможно.
Программирование "под Windows" уже много лет как не интересует широкие массы. Все давно переехали в веб. Я, к примеру, уже много лет игнорирую все их десктопные технологии. Пережиток прошлого.
DD>Программирование "под Windows" уже много лет как не интересует широкие массы. Все давно переехали в веб. Я, к примеру, уже много лет игнорирую все их десктопные технологии. Пережиток прошлого.
Это хорошая мантра, продолжай ее повторять ))
IB>Это хорошая мантра, продолжай ее повторять ))
Правильно — нам работы больше будет — мы и десктопом не побрезгуем
DD>Программирование "под Windows" уже много лет как не интересует широкие массы. Все давно переехали в веб. Я, к примеру, уже много лет игнорирую все их десктопные технологии. Пережиток прошлого.
В корпоративном секторе — да. А вот пользовательские приложения уже переезжают назад. Лениво людям открывать браузер и набирать ссылки.
А>У меня нет больше никаких слов, кроме матных. Товарища Синофского надо подвесить за определенную часть тела и больше никогда не подпускать к компьютеру.
Не надо так явно завидовать товарищу, которому дали возможность определять направление развития программного обеспечения.
Я думаю он сам хорошо понимает — "если что, то лучше самому себе сделать харакири"
В таком случае, ему пора начинать готовиться к ритуалу, я думаю.
А>Главные вопросы, которые у меня возникают: "WTF?" и "нафига?", а также "нафига?!", "нафига?!!" и "нафига?!!!".
Да прекрасно понятно. Планете давно нужен нормальный язык\платформа для натива. И если комитет забивает болт, то в игру приходится вступать Microsoft'у.
А>Что ж это такое будет-то? Получается какая-то еще одна какая-то непонятная платформа со своим собственным довольно поганым языком (никакой это, конечно же, не C++).
Конечно же это C++. В него просто добавлен нормальный синтаксис\система типов — вместо всяких макросно-шаблонных извращений предыдущей эпохи — для поддержки компонентных систем. Причём с практически полным сохранением совместимости с C++\CLI по "буковкам".
А>Я бы понял, если бы они все перевели на дотнет, понял бы если бы они все сделали на C++, но эту хрень я не понимаю совершенно.
Наоборот, нормально всё. "Чистый" C++ это очевидный капец и путь в никуда. Сделан же очередной шаг в правильном направлении, просто он сделан с другой\непривычной стороны — со стороны натива.
D>Конечно же это C++. В него просто добавлен нормальный синтаксис\система типов — вместо всяких макросно-шаблонных извращений предыдущей эпохи — для поддержки компонентных систем. Причём с практически полным сохранением совместимости с C++\CLI по "буковкам".
Это не C++, потому что он не соответствует стандартам ни 2003, ни 2011 года и не компилируется другими компиляторами, кроме микрософтовского.
Да, и "макросно-шаблонные извращения" в новом стандарте уже являются частью стандартной библиотеки.
Вообще, если я буду разрабатывать софт для винды у меня два юзкейса:
1) у меня есть большая кодовая база на C++ и винапи, WinRT не нужен (не переписывать же все?);
2) я собираюсь начать новое приложение, выберу, естественно, дотнет (WPF, WinForms), ну или, на худой конец, QT, так как он мощный и еще и кроссплатформенный, а нафига мне ни с чем не совместимый и убогий (по сравнению с C#) WinRT с его кривым недосиплюсплюсом в этом случае?
Не, не понимаю, хоть убейте. Глупость и все тут.
А>Это не C++, потому что он не соответствует стандартам ни 2003, ни 2011 года и не компилируется другими компиляторами, кроме микрософтовского.
Вы так говорите, как-будто в предыдущих версиях реализации C++ от Microsoft не было никаких их "личных" языковых расширений. Тогда как килотонны... нет, килотонны это мало... мегатонны существующего кода оные во всю используют, и ничем кроме MSVC никогда не скомпилируются.
А>Да, и "макросно-шаблонные извращения" в новом стандарте уже являются частью стандартной библиотеки.
Да ну ? С интересом послушаю, как Вы на этих "частях" будете делать поддержку системы типов WinRT.
А>1) у меня есть большая кодовая база на C++ и винапи, WinRT не нужен (не переписывать же все?);
Зачем переписывать ??? Там прямой interop аналогичный схеме C++\CLI. Новые внешние интерфейсы делаете на WinRT, а в потрохах всё тот же старый добрый legacy C++.
А>2) я собираюсь начать новое приложение, выберу, естественно, дотнет (WPF, WinForms),
А если платформа это Windows Phone ? И приложение это какой-нибудь навороченный ГИС-клиент ? Для которого опять-таки куча C++ кода уже есть ? Тоже .NET выберете ?
D>Вы так говорите, как-будто в предыдущих версиях реализации C++ от Microsoft не было никаких их "личных" языковых расширений. Тогда как килотонны... нет, килотонны это мало... мегатонны существующего кода оные во всю используют, и ничем кроме MSVC никогда не скомпилируются.
Ну это неправда. У MSVC есть некоторые расхождения со стандартом в том плане, что он компилирует невалидный с точки зрения стандарта код, но это все не такие большие проблемы и довольно легко допиливаются при портировании. В то время, как в WinRT с его "крышками" это вообще считай другой язык.
А>>Да, и "макросно-шаблонные извращения" в новом стандарте уже являются частью стандартной библиотеки.
D>Да ну ? С интересом послушаю, как Вы на этих "частях" будете делать поддержку системы типов WinRT.
Дык примерно так я и пишу все программы на C++, с reference counting'ом.
А>>1) у меня есть большая кодовая база на C++ и винапи, WinRT не нужен (не переписывать же все?);
D>Зачем переписывать ??? Там прямой interop аналогичный схеме C++\CLI. Новые внешние интерфейсы делаете на WinRT, а в потрохах всё тот же старый добрый legacy C++.
А в чем профит перед C++/CLI, учитывая идентичный поганый синтаксис? Ну и для дотнета я бы скорее использовал автоматическую генерацию оберток, чем писать это уродство на C++/CLI. Хотя, это, конечно, лучше, чем делать COM-обертки, спору нет.
А>>2) я собираюсь начать новое приложение, выберу, естественно, дотнет (WPF, WinForms),
D>А если платформа это Windows Phone ? И приложение это какой-нибудь навороченный ГИС-клиент ? Для которого опять-таки куча C++ кода уже есть ? Тоже .NET выберете ?
Не понял эту реплику. А WinRT что дает для Windows Phone? C#-то вроде как раз и дает общую кодовую базу с Windows Phone (кроме UI).
А>Ну это неправда. У MSVC есть некоторые расхождения
Какие ещё "некоторые расхождения" ??? Я об intrinsic'ах, всяких хренях типа __declspec, атрибутах и т.д. и т.п.
А>Дык примерно так я и пишу все программы на C++, с reference counting'ом.
Опять двадцать пять. Система типов это не подсчёт ссылок.
А>А в чем профит перед C++/CLI, учитывая идентичный поганый синтаксис?
В том, что на выходе нативный код. Это interop реализованный с другой стороны.
А>Не понял эту реплику. А WinRT что дает для Windows Phone?
Открывает платформе путь для запуска стороннего нативного кода. WinRT это новый binding для системных API, нормально типизированный и контролируемый.
D>А если платформа это Windows Phone ? И приложение это какой-нибудь навороченный ГИС-клиент ? Для которого опять-таки куча C++ кода уже есть ? Тоже .NET выберете ?
Гы. Ты для начала узнал на чем можно под Windows Phone писать. Тебя это повеселит.
А>>Главные вопросы, которые у меня возникают: "WTF?" и "нафига?", а также "нафига?!", "нафига?!!" и "нафига?!!!".
D>Да прекрасно понятно. Планете давно нужен нормальный язык\платформа для натива. И если комитет забивает болт, то в игру приходится вступать Microsoft'у.
Мне не очень понятно в чём тут плюсы по сравнению с классическим решением на умных указателях. Генерация метаинформации — ну ладно, ещё можно простить.
C>Мне не очень понятно в чём тут плюсы по сравнению с классическим решением на умных указателях.
Ну расскажите, как Вы собираетесь реализовывать полную поддержку системы типов WinRT исключительно на smart-pointer'ах. Лично я с большим интересом послушаю.
C>>Мне не очень понятно в чём тут плюсы по сравнению с классическим решением на умных указателях.
D>Ну расскажите, как Вы собираетесь реализовывать полную поддержку системы типов WinRT исключительно на smart-pointer'ах. Лично я с большим интересом послушаю.
А какие сложности? Проблемы только с синтаксисом свойств и событий/делегатов. Их можно с помощью препроцессора реализовать (см. QT MOC).
C>Мне не очень понятно в чём тут плюсы по сравнению с классическим решением на умных указателях. Генерация метаинформации — ну ладно, ещё можно простить.
Думаю, главный плюс — это бесшовная интеграция с дотнетом в купе с поддержкой нэйтивного программирования.
Вообще, писать виндовс-приложения на голых плюсах всегда было не удобно. Для упрощения всегда делали кучу оберток. И даже с ними постоянно появлялись проблемы.
C>>Мне не очень понятно в чём тут плюсы по сравнению с классическим решением на умных указателях. Генерация метаинформации — ну ладно, ещё можно простить.
VD>Думаю, главный плюс — это бесшовная интеграция с дотнетом в купе с поддержкой нэйтивного программирования.
Её можно было сделать и без изнасилования С++. Win RT в общем и целом выглядит как Yet Another Reference Counted Object Framework с автоматической генерация обёрток по метаинформации, чего-то идеологически нового в нём нет.
Из аналогов: в QT есть бесшовная интеграция с JavaScript, а в GTK издревле вообще интеграция со всем есть (с помощью GObject).
VD>Вообще, писать виндовс-приложения на голых плюсах всегда было не удобно. Для упрощения всегда делали кучу оберток. И даже с ними постоянно появлялись проблемы.
Это всё из-за того, что API было старинное, прямо из 80-х годов.
Win RT можно было бы выпустить в виде кроссплатформенной библиотеки и небольших расширений компилятора для генерации метаинформации. Но MS решили попробовать старый добрый Embrace&Extend, чтобы увеличить lock-in для клиентов. Впрочем, сейчас это выглядит как-то бледновато на фоне того, что всё утекает в web.
C>Её можно было сделать и без изнасилования С++. Win RT в общем и целом выглядит как Yet Another Reference Counted Object Framework с автоматической генерация обёрток по метаинформации,
Вроде как где-то тут проскакивала информация, что можно и без оберток жить (сам себе уши обморожу...).
C>чего-то идеологически нового в нём нет.
А надо?
По сравнению с WinAPI — это явный прогресс — типизация + модульность.
C>Из аналогов: в QT есть бесшовная интеграция с JavaScript, а в GTK издревле вообще интеграция со всем есть (с помощью GObject).
Причем тут QT и JavaScript? Как я понимю, тут речь идет об АПИ ОС. Остальное уже детали.
VD>>Вообще, писать виндовс-приложения на голых плюсах всегда было не удобно. Для упрощения всегда делали кучу оберток. И даже с ними постоянно появлялись проблемы.
C>Это всё из-за того, что API было старинное, прямо из 80-х годов.
Ну, да. Вот это и пофиксили.
Я тут могу только согласиться лишь с мнением, что можно было тупо взять дотнет за базу для АПИ. Только предварительно подкрутить производительность и сделав его ядренным. Точнее даже лучше было бы взять то что было разработано в рамках Сингулярити. Они ведь доказали, что быстрый ЖЦ возможне. А джит он на фиг не нужен. Достаточно компиляции при инсталляции или даже вообще без нее. Формат дотнетных сборок это позволяет.
C>Win RT можно было бы выпустить в виде кроссплатформенной библиотеки и небольших расширений компилятора для генерации метаинформации.
+1
Я бы даже сказал, не можно, а нужно. Иначе это АПИ мало кому нужно будет... еще лет 5.
C>Но MS решили попробовать старый добрый Embrace&Extend,
Мне кажется — это что-то из серии охоты на ведьм.
C>чтобы увеличить lock-in для клиентов.
Как новый АПИ может сделать это? И почему это не делал старые расшерения API основанные на WinAPI. Ведь WinAPI не был заморожен в 91-ом.
C>Впрочем, сейчас это выглядит как-то бледновато на фоне того, что всё утекает в web.
Ну, блока — это реальная стратегия МС исправить фатальный недостаток в локальных серверах .
C>>Её можно было сделать и без изнасилования С++. Win RT в общем и целом выглядит как Yet Another Reference Counted Object Framework с автоматической генерация обёрток по метаинформации,
VD>Вроде как где-то тут проскакивала информация, что можно и без оберток жить (сам себе уши обморожу...).
Почему же? То что я вижу не является чем-либо лучше классических умных указателей. Если бы я писал на Win RT интерфейс для существующего кода, то написал бы обёртку для boot::shared_ptr.
C>>чего-то идеологически нового в нём нет.
VD>А надо?
VD>По сравнению с WinAPI — это явный прогресс — типизация + модульность.
Кстати, я не уверен, что внутри WinRT нет старого доброго CreateWindowW — вполне возможно, что там большая часть — просто хорошие обёртки.
C>>Из аналогов: в QT есть бесшовная интеграция с JavaScript, а в GTK издревле вообще интеграция со всем есть (с помощью GObject).
VD>Причем тут QT и JavaScript? Как я понимю, тут речь идет об АПИ ОС. Остальное уже детали.
А разница? libglib тоже может использоваться для общения на уровне ОС, даже разговоры о GNOME OS идут. Так что тут Win RT и GTK/QT как раз примерно на одном уровне по абстракциям и реализации.
VD>Я тут могу только согласиться лишь с мнением, что можно было тупо взять дотнет за базу для АПИ. Только предварительно подкрутить производительность и сделав его ядренным. Точнее даже лучше было бы взять то что было разработано в рамках Сингулярити. Они ведь доказали, что быстрый ЖЦ возможне. А джит он на фиг не нужен. Достаточно компиляции при инсталляции или даже вообще без нее. Формат дотнетных сборок это позволяет.
Не получается, GC всё портит. Не столько даже из-за скорости, сколько из-за того, что для надёжности ВСЁ должно использовать один большой хип.
Ну и практика показала, что GC для кода оконных систем особо и не нужен, и даже вреден.
C>>чтобы увеличить lock-in для клиентов.
VD>Как новый АПИ может сделать это? И почему это не делал старые расшерения API основанные на WinAPI. Ведь WinAPI не был заморожен в 91-ом.
Я могу компилировать приложения для WinAPI под GCC. И сам WinAPI очень дружественен к С. А тут MS хочет, чтобы использовали только их компилятор, да и ещё активно насаживает расширения языка.
VD>Я тут могу только согласиться лишь с мнением, что можно было тупо взять дотнет за базу для АПИ. Только предварительно подкрутить производительность и сделав его ядренным. Точнее даже лучше было бы взять то что было разработано в рамках Сингулярити. Они ведь доказали, что быстрый ЖЦ возможне. А джит он на фиг не нужен. Достаточно компиляции при инсталляции или даже вообще без нее. Формат дотнетных сборок это позволяет.
А что, в singularity был GUI?
C>>Win RT можно было бы выпустить в виде кроссплатформенной библиотеки и небольших расширений компилятора для генерации метаинформации.
VD>+1
VD>Я бы даже сказал, не можно, а нужно. Иначе это АПИ мало кому нужно будет... еще лет 5.
По-моему этот WinRT еще минимум год докручивать будут.
А>Я в шоке. Нет слов. Это какое-то чудовищное г..но. Какой же это C++? Зачем они изменили синтаксис? Это не C++ и не дотнет. Какая-то технология-выродок с языком-мутантом.
+100.
А>Что ж это такое будет-то? Получается какая-то еще одна какая-то непонятная платформа со своим собственным довольно поганым языком (никакой это, конечно же, не C++).
Там вроде можно использовать чистый С++, пользуясь WRL, но при этом получаем старый добрый COM, а эти уродские расширения мол нужны для того, чтобы не думать о COM.
А>Я бы понял, если бы они все перевели на дотнет, понял бы если бы они все сделали на C++, но эту хрень я не понимаю совершенно.
Я тут недавно копался в MSDN, WinRT в паре с C# (или VB) выглядит довольно органично. А вот код на C++
А>У меня нет больше никаких слов, кроме матных. Товарища Синофского надо подвесить за определенную часть тела и больше никогда не подпускать к компьютеру.
Да зачем так себе нервы трепать, проще будет тупо не программировать под Windows платформой больше, выбора выше крыши: Java/Web/Mac OS X/iOS/Android/...
А>Я в шоке. Нет слов. Это какое-то чудовищное г..но. Какой же это C++? Зачем они изменили синтаксис? Это не C++ и не дотнет. Какая-то технология-выродок с языком-мутантом.
То есть проблема в синтаксисе примеров на C++? Что вызывает такую реакцию?
А>Что ж это такое будет-то? Получается какая-то еще одна какая-то непонятная платформа со своим собственным довольно поганым языком (никакой это, конечно же, не C++).
Платформа понятная, а для разработки можно и другой язык использовать
А>Reference counting? Вы меня шутите? И для reference counting'а делать синтаксические расширения?
А почему нет
А>COM? В 2011 году? Они там совсем долбанулись?
Предложите свой вариант?
А>У меня нет больше никаких слов, кроме матных. Товарища Синофского надо подвесить за определенную часть тела и больше никогда не подпускать к компьютеру.
G> Некоторой частью эти расширения похожи на расширения managed C++, но не нужно их путать. WinRT не использует CLR, и несмотря на то, что синтаксис местами одинаковый (например, Search::QueryOptions^), в WinRT это означает совсем другое.
Одна синтаксическая конструкция имеющая разный смысл при разных ключах компилятора (то есть по сути два разных языка) очевидно один из самых быстрых путей к полному .....
И вопрос тут не в том, что ребята решили создать новый COM. Может он и нужен для низкоуровневых работ, а именно в том, что они решили продлить агонию С++ превратив его из кошмарного франкенштейна (чего стоит синтаксис лямбд) с замусоренным синтаксисом в нечто совсем уж убожеское. Надо было создавать новый язык. Пусть низкоуровневый, но новый.
И лично я считаю, что это может очень плохо сказаться на отрасли в целом и на компании MS в частности.
Печально
AB>И вопрос тут не в том, что ребята решили создать новый COM. Может он и нужен для низкоуровневых работ, а именно в том, что они решили продлить агонию С++ превратив его из кошмарного франкенштейна (чего стоит синтаксис лямбд) с замусоренным синтаксисом в нечто совсем уж убожеское. Надо было создавать новый язык. Пусть низкоуровневый, но новый.
Ну а чего ты от Синовского хотел? Да, у него классно получается разведенный в разработке бардак устранить и начать выпускать продукты качественно и в срок. Но вот технически, в плане новых идей, даже просто их оценки — он импотент. Нет у него инженерной чуйки.
НС>Ну а чего ты от Синовского хотел? Да, у него классно получается разведенный в разработке бардак устранить и начать выпускать продукты качественно и в срок. Но вот технически, в плане новых идей, даже просто их оценки — он импотент. Нет у него инженерной чуйки.
Не соглашусь — COM для своего времени был очень ничего, да и WinRT в общем сделан нормально.
G>Не соглашусь — COM для своего времени был очень ничего, да и WinRT в общем сделан нормально.
одно маленькое замечание, COM как таковой изобретен вовсе не компанией MS. по-моему — это детище DEC. точно уже не помню.
и изначально там как раз были AddRef, Release, QueryInterface. только называлось это IInterface вроде как (хотя как раз тут могу путать).
H_D>одно маленькое замечание, COM как таковой изобретен вовсе не компанией MS. по-моему — это детище DEC. точно уже не помню.
H_D>и изначально там как раз были AddRef, Release, QueryInterface. только называлось это IInterface вроде как (хотя как раз тут могу путать).
QueryInterface был другой, а AddRef/Release (или аналогичное) использовали задолго до и не только в DEC. На самом деле COM, как самостоятельная технология — ничего интересного. Цель была в технологии для OLE, в маршаллинге, в динамических создаваемых по метаинформации из библиотеки типов бинарных проксях и стабах, в диспетчеризации м/у разными типами аппартаментов. Вот это уже целая навороченная платформа... А голый COM на фоне этого — ничто. Даже DCOM и COM+, по-сути, развитие именно OLE. Т.е. ввод буквально одной службы и пару интерфейсов в существующую OLE-инфраструктуру. Просто сама OLE очень обширна, примерно половину платформы занимают интерфейсы, обслуживающие визуальные компоненты, а они не нужны для DCOM/COM+.
G>Не соглашусь — COM для своего времени был очень ничего
СОМ был тем еще отстоем, и только массовое его использование самим МС не дало ему склеить оапки.
G>да и WinRT в общем сделан нормально.
Рано об этом пока говорить.
НС>СОМ был тем еще отстоем, и только массовое его использование самим МС не дало ему склеить оапки.
Я не согласен. Но даже если и так, какая компонентная система была лучше?
НС>Рано об этом пока говорить.
Почему рано, он уже есть, видно что там внутри и выводы делать вполне можно.
НС>>СОМ был тем еще отстоем, и только массовое его использование самим МС не дало ему склеить оапки.
G>Я не согласен.
А это не вопрос твоего согласия.
G> Но даже если и так, какая компонентная система была лучше?
Java.
НС>>Рано об этом пока говорить.
G>Почему рано
Потому что все может 100 раз поменяться, да и для нормальной оценки надо плотно повозиться с технологией хотя бы месяц-другой. Тот же WPF, про который ты поминаешь — очень красиво смотрелся на пререлизах. А к релизу море неприятностей вылезло. Или WCF — прекрасная, без преувеличения, технология. Однако порог вхождения, как показала практика, очень высок.
НС>Потому что все может 100 раз поменяться, да и для нормальной оценки надо плотно повозиться с технологией хотя бы месяц-другой. Тот же WPF, про который ты поминаешь — очень красиво смотрелся на пререлизах. А к релизу море неприятностей вылезло. Или WCF — прекрасная, без преувеличения, технология. Однако порог вхождения, как показала практика, очень высок.
Дак все оно смотрится сначала как этакое простое и пушистое, а потом оказывается что айсберг не так уж прост. Стоит немного уйти от стандартных юзкейсов, так огребаешь столько тонкостей... Но уж лучше WCF чем Remoting.
НС>А это не вопрос твоего согласия.
А это не тебе решать
НС>Java.
Ну-ну
НС>Потому что все может 100 раз поменяться,
Уже слишком много сделали, чтобы все "100 раз менять"
G>> Но даже если и так, какая компонентная система была лучше?
НС>Java.
Шутка детектед ничего хуже жабы в качестве компонентных систем я не видел. а в 95 году жаба только вышла и была ТАКИМ УГ, что аж страшно было. (хотя рекламировали, что через год максимум весь веб будет на жабе).
а COM — это совместная разработка DEC и Microsoft, причем насколько я знаю, инициатива исходила от DEC. И болеее того, CORBA потом базировалась тоже на первой реализации COM.
Появилась не просто среда WinRT, а переписывается на нем весь API винды, а реально напишут сколько успеют. И теперь можно использовать весь этот API из обычных проектов на C#, делая ссылки как на .NET сборки, и не возиться с обертками.
Думаю новый WinCPP они делали в первую очередь для себя, но чтоб добро не пропадало выложили как продукт.
Подразделение занимающееся виндой отвергло .NET как вариант на чем можно переписать WinAPI, из-за проблем с производительностью.
S_S>Подразделение занимающееся виндой отвергло .NET как вариант на чем можно переписать WinAPI, из-за проблем с производительностью.
Лучше бы они вместо отвержения, продавили оптимизацию .Net. Ну, ладно. Если фича с простым подключением натива, как сборок, будет работать, то круто.
MM>Лучше бы они вместо отвержения, продавили оптимизацию .Net.
Вместо не получится. Это не то что разные команды, это разные подразделения. А поскольку первые деньги напрямую зарабатывают, а вторые — нет, то и получаем что имеем.
S_S>>Подразделение занимающееся виндой отвергло .NET как вариант на чем можно переписать WinAPI, из-за проблем с производительностью.
MM>Лучше бы они вместо отвержения, продавили оптимизацию .Net.
Не уверен, что это возможно. Пытались ведь в longhorn'е, и ничего не вышло.
MM>Ну, ладно. Если фича с простым подключением натива, как сборок, будет работать, то круто.
А почему нет, COM-то уже сейчас работает.
x64>Всё же, я думаю, это в раздел Win32 надо было. Потому что вот меня, например, больше беспокоит вопрос: зачем это всё, в смысле, какую цель преследует этот WinRT и какие задачи/проблемы призван решить? ... Но внезапно я узнаю, что появился какой-то там ещё WinRT, а чем он лучше для моей задачи, — мне не понятно, что мне делать?
Наивный ты. Видимо ты никогда не читал краткую историю революций от Майкрософт.
ИМО будет проще потребовать чтоб юзера был .NET, чем WinRT.
A>Главная проблема в том, что сейчас WinRT нет у 100% юзеров. Когда выйдет Win8, WinRT будет у тех кто поставит Win8. Может сделают WinRT для Win7, Vista, и даже xpsp3, это будет сколько-то десятков Мб которые надо будет скачать. Но у основной массы юзеров WinRT появится лет через 5.
WinRT будет только готов через год-два, как часть Win8. Не думаю, что будут выпускать обновление для Win7, нет смысла.
G>WinRT ... все это можно прочитать по ссылке выше (хотя информации пока немного, надеюсь будут обновлять оперативно). Но самое главное уже более-менее понятно. Перед нами новая версия COM.
Тут будет очень кстати вспомнить краткую историю программных революций от Microsoft:
Ну, что же, группа операционных систем (или это была группа COM?) громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к WinRT! Они в очередной раз нашли фатальный недостаток, на этот раз, в .NET и COM сразу. Ну, вы знаете какой!
ЗЫ
Всем запастись попкорном и ждать новых серий из цикла "краткие истории программных революций от Microsoft". Ведь WinRT наверняка революционно изменит Windows-программирование... примерно на год
G>За свое выдать не удастся, ставь копирайты или ссылку на оригинал
Классику знать надо. Ни то, скоро, придется копирайт к сказкам Пушкина приделывать.
В гугле тебя не забанили пока?
ЗЫ
Что до авторства, то если что, я автор перевода.
VD>Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом.
А я вспоминаю ретивого докладчика из MS на одной конфе в 2002 году. И его "следующая операционная система будет позволять выполнять только .NET приложения.". Я на тот уже вроде как должен был бы сказать "данунах", но все равно — что-то внутри вздрогнуло... Пошел уже четвертый год как я сижу на этой "следующей операционной системе" — Vista x64. Все работает. Даже то, что было последний раз откомпилировано в 2001. Страшненьким плюсовым компилятором 98 года.
Жаль, что нельзя вернуться и сказать "не говори гоп, пока не перепрыгнешь"
VD>>Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом.
КД>А я вспоминаю ретивого докладчика из MS на одной конфе в 2002 году. И его "следующая операционная система будет позволять выполнять только .NET приложения.". Я на тот уже вроде как должен был бы сказать "данунах", но все равно — что-то внутри вздрогнуло... Пошел уже четвертый год как я сижу на этой "следующей операционной системе" — Vista x64. Все работает. Даже то, что было последний раз откомпилировано в 2001. Страшненьким плюсовым компилятором 98 года.
КД>Жаль, что нельзя вернуться и сказать "не говори гоп, пока не перепрыгнешь"
Ты похоже не понял основного посыла моего высказывания. Ну, да трактавать юмор и сарказм — это последнее дело.
Тебе же я советую не выносить поспешных суждений о дотнете. Ты явно с ним пока что знаком очень поверхностно. Поверь человеку изучавшему COM и .Net по мери их появления — все намного сложнее чем ты себе представляешь.
VD>Всем запастись попкорном и ждать новых серий из цикла "краткие истории программных революций от Microsoft". Ведь WinRT наверняка революционно изменит Windows-программирование... примерно на год
Ну про дотнет там то же самое было написано, сам процитировал
Надеюсь, что ты сам то понимаешь, что этот текст изначально писал идиот (или человек, им притовряющийся)?
A>Надеюсь, что ты сам то понимаешь, что этот текст изначально писал идиот (или человек, им притовряющийся)?
Ты про историю революций то? Его писал очень не глупый челове — Рон Барг (на то время главный редактор Windosw Develeoper Jornal, в последствии Windows Magazine).
То что ты не понимаешь иронии этого текста, и то что, возможно, он вызывает у тебя батхерт — это твои личные проблемы.
Для тех кто не умеет воспринимать аллегории и сарказм, поясню прямым текстом. Он тонко ухватил суть многих проблем МС. МС это не огромная единая корпорация с единым планом развития, единым руководством определяющим это развитие, и единым и сплоченным коллективом разработчиков и менеджеров. МС это множество разных команд (можно сказать кланов). И то одна, то другая, временно, перетягивает на себя одеяло. Отсюда и кажущиеся странности.
Я бы не назвал это проблемой. Наоборот, это достаточно правильный подход. Имхо в большой копорации монолита и не может быть, а жесткая иерархическая структура из за несогласованности частей обязательно превращается в полный идиотизм. Поэтому рабочие группы, соревнующиеся за финансирование. Тут все верно, проблема у них в другом месте.
А мы смеемся над результатом.
G>Я бы не назвал это проблемой. Наоборот, это достаточно правильный подход. Имхо в большой копорации монолита и не может быть, а жесткая иерархическая структура из за несогласованности частей обязательно превращается в полный идиотизм. Поэтому рабочие группы, соревнующиеся за финансирование. Тут все верно, проблема у них в другом месте.
G>А мы смеемся над результатом.
Проблема в том, что МС колбасит из года в год. То они идут в одно направление, то в другое. Нет, в обществе стабильности (с)
Довольно глупо подсаживать миллионную армию разработчиков на дотнет, а потом создавать еще один АПИ похожий на дотнет, но другой.
Ты чего-то не понимаешь или не хочешь признавать. .NET и ОS API это очевидно несовместимые вещи. Библиотеки разного уровня и назначения. Очевидно нужно и то и другое.
G>Ты чего-то не понимаешь или не хочешь признавать. .NET и ОS API это очевидно несовместимые вещи.
Есть еще один вариант. Чего-то не понимаешь ты. В Сингулярити почему-то API ОS оказался совместим с клоном дотнета.
G>Библиотеки разного уровня и назначения. Очевидно нужно и то и другое.
Ну, тебе очевидно одно. Мне очевидно другое. Уверен, что там было не хилое противостояние и девелопер-дивижон уступил ОС-ному. Вот и все. А возможно, не возможно — это для баб на базарах разговоры, а не для инженеров. Скажут — сделаем. Вот наш диви!
G>Я бы не назвал это проблемой. Наоборот, это достаточно правильный подход. Имхо в большой копорации монолита и не может быть
Может может. Погляди на Яблоко.
>
> Может может. Погляди на Яблоко.
Не может. Это классика управления. И что значит погляди на яблоко? Пока внутри не поработаешь именно в орг-структуре, невозможно узнать монолит оно или нет. Да стопроцентов не монолит, они же не дураки там.
G>Не может. Это классика управления. И что значит погляди на яблоко?
То и значит, что там как раз таки жесткая иерархическая структура, и Джобс, покуда жив был, жестко контролировал все разрабатываемые продукты лично.
G> Пока внутри не поработаешь именно в орг-структуре, невозможно узнать монолит оно или нет.
В МС, я так понимаю, ты внутри в оргструктуре поработал.
Может он и умный человек, но сказанное им это или "для красного словца" (т.е. журналистская сущность взяла верх и он притворился идиотом), или он не совсем понимает о чем пишет (чистый идиот).
Т.к. мы знаем, что OLE 1 был развитием DDE. А OLE2 это и есть COM. И при этом многие части Win API существуют в виде COM-интерфейсов (например, DirectX, URL Monikers, Windows Shell, тот-же хостинг .Net и множество жругих вещей..). Или нужно было остановиться на DDE, и больше ничего не дедать? При этом и DDE и COM и OLE работали и работают и ни куда из Windows не денуться.
Ну и других нестыковок по тексту — масса. Ты сам их найдешь.
Возможно это и разновидность сарказма. Просто мне не нравиться сарказм, основанный на передергивании фактов.
В догонку — ты ведь и сам знаешь один фатальный недостаток у С# — он у тебя в подписи.
Это — сарказм.
A>В догонку — ты ведь и сам знаешь один фатальный недостаток у С# — он у тебя в подписи.
Дык я не в МС работаю ведь.
A>Это — сарказм.
Спасибо за подсказку! Я бы ни в жизнь не догадался .
A>Может он и умный человек, но сказанное им это или "для красного словца" (т.е. журналистская сущность взяла верх и он притворился идиотом), или он не совсем понимает о чем пишет (чистый идиот).
A>Т.к. мы знаем, что OLE 1 был развитием DDE. А OLE2 это и есть COM. И при этом многие части Win API существуют в виде COM-интерфейсов (например, DirectX, URL Monikers, Windows Shell, тот-же хостинг .Net и множество жругих вещей..). Или нужно было остановиться на DDE, и больше ничего не дедать? При этом и DDE и COM и OLE работали и работают и ни куда из Windows не денуться.
Ну, вы батенька и зануда!
Чувак и стебется над тем, что уже и в самом МС никто не понимает что к чему является названием и причем тут Active, X и +.
A>Ну и других нестыковок по тексту — масса. Ты сам их найдешь.
Мне не надо. У меня батхерта нет. Я прекрасно понимаю, что читать надо суть. И прекрасно вижу, что суть эта проявляется и по сей день. И эта тема тому прекрасное доказательство.
A>Возможно это и разновидность сарказма. Просто мне не нравиться сарказм, основанный на передергивании фактов.
А ты еще раз перечитай это дело, но лет эдак через 10.
VD>Мне не надо. У меня батхерта нет.
Есть, есть Не обманывай себя. Быть Гуру .Net, даже написать крутой .Net-язык, в свое время утверждать, что MS в Viste сделает Managed Internet Explorer. И тут такой облом — WinRT
A>Есть, есть Не обманывай себя. Быть Гуру .Net, даже написать крутой .Net-язык,
Спасибо за лестную оценку.
A>в свое время утверждать, что MS в Viste сделает Managed Internet Explorer.
Это уже домыслы.
A>И тут такой облом — WinRT
И вот представь себе нет. Когда .Net только появился и некоторые начали пророчить закат эры COM-а у меня действительно было нечто что можно охарактеризовать батхертом — я ощущал себя кинутым.
А сейчас все эти игры уже ничего кроме смеха не вызывают. Я прекрасно понимаю, что дотнет никуда не денеется, да и альтернатив достаточно.
Что до языка, то мы тут как раз подумываем о сваливании с дотнета. Точнее о мультиплатформности. Так шта...
Мне вот не совсем понятно, за что минус Можно пояснить?
VD>.NET наверняка революционно изменит Windows-программирование... примерно на год.
А ведь прошло уже почти 10.
[skipped]
только одно маленькое исправление: COM был раньше, чем OLE — OLE на нем основан а так — вполне даже доходчиво
VD>
соглавен.
1. Сейчас колупаю Windows API. Естественно использую C++ (ну это скорее С, как я понимаю). Более менее разобрался как работать объектами ядра, синхронизацией. Сейчас смотрю, как с GUI работать через WIN API — ну это скорее, чтобы понимать как оно все устроено на нижнем уровне. Вот я смотрю на этот ИМХО говнокод, смесь бульдога с носорогом и крышечками и возникает закономерный вопрос. А БУДУТ ЛИ В WIN 8 ПОДДЕРЖИВАТЬСЯ "КЛАССИЧЕСКИЕ" API ФУНКЦИИ НА СТАНДАРТНОМ С++?
2. Очевидно, что MFC окончательно загинается, GUI на API — долго, нудно, скудно и коряво, скорее всего для GUI будет использоваться в основном .NET, который позволяет быстренько наклепать добротное гуевое приложение. Однако охота использовать API, многопоточность, объекты ядра, синхронизацию, memory mapped files и другие нужные мне низкоуровневые "полезности". Как это все интегрируется ?
_>1. Сейчас колупаю Windows API. Естественно использую C++ (ну это скорее С, как я понимаю). Более менее разобрался как работать объектами ядра, синхронизацией. Сейчас смотрю, как с GUI работать через WIN API — ну это скорее, чтобы понимать как оно все устроено на нижнем уровне. Вот я смотрю на этот ИМХО говнокод, смесь бульдога с носорогом и крышечками и возникает закономерный вопрос. А БУДУТ ЛИ В WIN 8 ПОДДЕРЖИВАТЬСЯ "КЛАССИЧЕСКИЕ" API ФУНКЦИИ НА СТАНДАРТНОМ С++?
Дались вам эти крышечки, ей богу, дело же вовсе не в них. Можно использовать winapi напрямую, но тогда metro приложение написать не получится, только обычное
_>2. Очевидно, что MFC окончательно загинается, GUI на API — долго, нудно, скудно и коряво, скорее всего для GUI будет использоваться в основном .NET, который позволяет быстренько наклепать добротное гуевое приложение.
Если речь идет о будущем, то для GUI будет использоваться WinRT и то, что туда перенесли из WPF.
_> Однако охота использовать API, многопоточность, объекты ядра, синхронизацию, memory mapped files и другие нужные мне низкоуровневые "полезности". Как это все интегрируется ?
Можно использовать .NET обертки, можно самому вызывать неуправляемый код как p/invoke так и через COM.
G>Можно использовать winapi напрямую, но тогда metro приложение написать не получится, только обычное
А что под этим понимается? Встраивание в прокручиваемую панельку? А оно надо для 99% приложений?
VD>А что под этим понимается? Встраивание в прокручиваемую панельку? А оно надо для 99% приложений?
В частности, как уже тут кто-то писал, только metro apps можно будет продавать в app store.
G>В частности, как уже тут кто-то писал, только metro apps можно будет продавать в app store.
А одтнетные приложения использующие обертки для нового АПИ к таковым относиться будут?
G>>В частности, как уже тут кто-то писал, только metro apps можно будет продавать в app store.
VD>А одтнетные приложения использующие обертки для нового АПИ к таковым относиться будут?
В visual studio есть некий профиль для metro apps. Надо собирать приложение под этим профилем. Видимо, какой-то набор фич использовать нельзя.
G>Здравствуйте, constant_arapov, Вы писали:
_>>1. Сейчас колупаю Windows API. Естественно использую C++ (ну это скорее С, как я понимаю). Более менее разобрался как работать объектами ядра, синхронизацией. Сейчас смотрю, как с GUI работать через WIN API — ну это скорее, чтобы понимать как оно все устроено на нижнем уровне. Вот я смотрю на этот ИМХО говнокод, смесь бульдога с носорогом и крышечками и возникает закономерный вопрос. А БУДУТ ЛИ В WIN 8 ПОДДЕРЖИВАТЬСЯ "КЛАССИЧЕСКИЕ" API ФУНКЦИИ НА СТАНДАРТНОМ С++?
И все-таки можно ли будет использовать CreateWindow, ShowMessage и т.д. для обычных "классических" десктопных приложений (как я понял метро — для мобильных приложений больше преднахначен) ?
_>И все-таки можно ли будет использовать CreateWindow, ShowMessage и т.д. для обычных "классических" десктопных приложений (как я понял метро — для мобильных приложений больше преднахначен) ?
В том то и дело, что нет. Можно исопльзовать старый код, будут получаться обычные приложения, которые поддерживаются win8 в привычной среде.
Metro apps декларируются как десктопные приложения следующего поколения. Их можно будет распространять через windows store, использовать его возможности по лицензированию, и т.п.
G>Здравствуйте, constant_arapov, Вы писали:
_>>И все-таки можно ли будет использовать CreateWindow, ShowMessage и т.д. для обычных "классических" десктопных приложений (как я понял метро — для мобильных приложений больше преднахначен) ?
G>В том то и дело, что нет. Можно исопльзовать старый код, будут получаться обычные приложения, которые поддерживаются win8 в привычной среде.
G>Metro apps декларируются как десктопные приложения следующего поколения. Их можно будет распространять через windows store, использовать его возможности по лицензированию, и т.п.
Не вполне понятно — вот эти новые API WinRT будут оберткой для Win32(64) API ? Или для совместимости будут объявлены Win32(64) API, но фактически вызывать они будут API WinRT ? Типа как с приложениями MS DOS в свое время они как бы поддерживаются — для совместимости старых прог, но дальнейшая разработка приложений в подобном стиле не приветствуется.
_>Не вполне понятно — вот эти новые API WinRT будут оберткой для Win32(64) API ? Или для совместимости будут объявлены Win32(64) API, но фактически вызывать они будут API WinRT ? Типа как с приложениями MS DOS в свое время они как бы поддерживаются — для совместимости старых прог, но дальнейшая разработка приложений в подобном стиле не приветствуется.
Пока что, это отдельные API с разной функциональностью.
DR>Пока что, это отдельные API с разной функциональностью.
Не совсем так. Частично они перекрываются, и некоторые вещи из win32 которые можно использовать в WinRT завернуты в прокси, которые пытаются обеспечивать безопасность.
G>Я тут попробовал описать свои впечатления от WinRT...
G>...skip
Да ну нафиг, это какой-то мутант-чебурашка. Я даже сегодня не знаю как писать современный софт, если есть заказчики, сотрудники которых сидят за Win2K по сей день. (в глубине души это моя любимая операционка за всю историю)
Нафиг, нафиг. Я вот снова вспомнил... может я лучше дождусь продакшна ветки Singularity ? Или не дождусь, черт его знает что там происходит, из Miscrosoft Research новостей как с альфа-центавры. Что там у них происходит?
(если кто не в курсе Singularity — это микроядерная.. "OS после Windows" (с)Microsoft. старая станица на WIKI и довольно ладно скроена, с нуля, микроядерно)
.
C>Да ну нафиг, это какой-то мутант-чебурашка.
Да ну нафиг, это не мутант-чебурашка
C>Я даже сегодня не знаю как писать современный софт, если есть заказчики, сотрудники которых сидят за Win2K по сей день. (в глубине души это моя любимая операционка за всю историю)
Это уже другая проблема. Если заказчик готов оплачивать разработку под win2K — пусть платит.
C>Нафиг, нафиг. Я вот снова вспомнил... может я лучше дождусь продакшна ветки Singularity ? Или не дождусь, черт его знает что там происходит, из Miscrosoft Research новостей как с альфа-центавры. Что там у них происходит?
Теперь там происходит Midori.
C>>из Miscrosoft Research новостей как с альфа-центавры. Что там у них происходит?
G>Теперь там происходит Midori.
Спасибо! Но информации практически никакой.. Даже не как с альфа-центавры, а как из Apple.
C>Нафиг, нафиг. Я вот снова вспомнил... может я лучше дождусь продакшна ветки Singularity ?
Не дождешься. Проект никогда для этого не предназначался и сейчас вообще закрыт.
C>(если кто не в курсе Singularity — это микроядерная.. "OS после Windows" (с)Microsoft.
Microsoft никогда не позиционировал Singularity как замену Windows. И NT, кстати, изначально тоже была микроядерной.
C>>(если кто не в курсе Singularity — это микроядерная.. "OS после Windows" (с)Microsoft.
AVK>Microsoft никогда не позиционировал Singularity как замену Windows.
Я привел цитату с chanel9. Помню как я тогда мечтал, что стану старым и толстым, по мне будут прыгать внуки и спрашивать "Деда, а расскажи какая она была, Windows?"
Сейчас я думаю можно продолжить ту мысль. Сейчас я бы им ответил "Она была как жена, которая сварливая и с заскоками, но борщ в принципе готовит. Там еще окошки были их можно было перетаскивать, менять размер.. Это правда не с первой Windows началось.. Еще можно было сворачивать и потом опять доставать, а не очень нужные перетаскивать на второй монитор... А потом Б#ЯТЬ в этом прекрасном мире кто-то увидел <b>фатальный недостаток</b> и на десктопах появился Метро. А ботнеты и winlock остался, поому-что это не фатальный недостаток."
.
C>Сейчас я думаю можно продолжить ту мысль. Сейчас я бы им ответил "Она была как жена, которая сварливая и с заскоками, но борщ в принципе готовит. Там еще окошки были их можно было перетаскивать, менять размер.. Это правда не с первой Windows началось.. Еще можно было сворачивать и потом опять доставать, а не очень нужные перетаскивать на второй монитор... А потом Б#ЯТЬ в этом прекрасном мире кто-то увидел <b>фатальный недостаток</b> и на десктопах появился Метро. А ботнеты и winlock остался, поому-что это не фатальный недостаток."
С ботнетами ситуация улучшится когда установка приложений будет только через магазин.
DR>С ботнетами ситуация улучшится когда установка приложений будет только через магазин.
Не улучшится. Майкрософт годами закрывая глаза на пиратсво ради покрытия территории пользователей своей ОС сейчас попытается превратить территорию в качество? Легальную и модерируемую чистую экосистему как у Apple? IMHO утопизм.
Кроме того иньекции браузер-джава никуда не денутся. Чуть более чем домохозяйки обоих полов отключают UAC, из-за долбаных окошек по любому поводу, и отчасти этот гнев обоснован!. Почему меня МакОсь так не задалбывает подобными окошками (а там еще и пароль ввести надо между прочим).
Что-то не так в самой консерватории. Какого черта сама архитектура настолько везде кривая, что все время UAC. А они в этом развлекаются UI начиная с Висты (тьфу-тьфу, не поминай всуе) и WinRT придумывают.
P.S. Я не яблофаг, но как юзеру обоих систем и девелоперу под винду — мне иногда отчаяно грустно
.
C>Не улучшится. Майкрософт годами закрывая глаза на пиратсво ради покрытия территории пользователей своей ОС сейчас попытается превратить территорию в качество? Легальную и модерируемую чистую экосистему как у Apple? IMHO утопизм.
C>Кроме того иньекции браузер-джава никуда не денутся. Чуть более чем домохозяйки обоих полов отключают UAC, из-за долбаных окошек по любому поводу, и отчасти этот гнев обоснован!. Почему меня МакОсь так не задалбывает подобными окошками (а там еще и пароль ввести надо между прочим).
C>Что-то не так в самой консерватории. Какого черта сама архитектура настолько везде кривая, что все время UAC. А они в этом развлекаются UI начиная с Висты (тьфу-тьфу, не поминай всуе) и WinRT придумывают.
IE10 под Метро не поддерживает плагины и, говорят, под ARM будет поддерживаться только Метро. Так что, поверхность для атак уменьшается.
DR>IE10 под Метро не поддерживает плагины и, говорят, под ARM будет поддерживаться только Метро. Так что, поверхность для атак уменьшается.
Джава поддерживается даже под метро. Но ваша ошибка тут в том, что они не поддерживаются IE10. Вранье. Поддерживаются. Есть ораничение на уровне песочницы Метро, не более, как только вы в нормальном десктопе — IE10 чудесным образом снова IE9, просто без свистелок и перделок нового фреймворка. А почитайте интернеты про отношение к новому UI, подумайте о уже существующем софте и поймёте весь фейл.
DR>"...ARM будет поддерживаться только Метро. Так что, поверхность для атак уменьшается".
Во-первых я не вижу у ARM какой-то поверхности для атак, на которую что-то бы уменьшилось. Для embedded это актуально, но очень узко, и вообще это совершенно отдельная и изолированая история. Для планшетов... Ну ей богу, не смешите, мы с вами оба прекрасно понимаем майкрософт не влезет на этот рынок, после Apple еще был шанс, а после китайцев с Андроидами там осталось только узкое очко! Где поверхность, простите? Я туда точно не хочу.
И зачем вы вообще ARM вспомнили всуе в разговоре про майкрософт.. Я итак расстроен тем что майкрософт набрал толпу тупорылых тормозящих индусов, которые опоздали уже вообще везде где можно. Только на нервы надавили.
C>Кроме того иньекции браузер-джава никуда не денутся. Чуть более чем домохозяйки обоих полов отключают UAC, из-за долбаных окошек по любому поводу, и отчасти этот гнев обоснован!. Почему меня МакОсь так не задалбывает подобными окошками (а там еще и пароль ввести надо между прочим).
Не первый раз читаю такое и всё никак не пойму. Вы чем таким противоестесственным с ОС занимаетесь, что она вас с UAC задалбывает? Меня раз в месяц спросит, или когда программу ставлю, да и ладно. Хех, ну а Мак ОС, например, спрашивает постоянно "страшно: этот файл был загружен из иНета, бла-бла-бла".
C>>Кроме того иньекции браузер-джава никуда не денутся. Чуть более чем домохозяйки обоих полов отключают UAC, из-за долбаных окошек по любому поводу, и отчасти этот гнев обоснован!. Почему меня МакОсь так не задалбывает подобными окошками (а там еще и пароль ввести надо между прочим).
MM>Не первый раз читаю такое и всё никак не пойму. Вы чем таким противоестесственным с ОС занимаетесь, что она вас с UAC задалбывает? Меня раз в месяц спросит, или когда программу ставлю, да и ладно. Хех, ну а Мак ОС, например, спрашивает постоянно "страшно: этот файл был загружен из иНета, бла-бла-бла".
Спрашивает, но без повышения привилегий, ито редко. Иногда повышение привилегий в МакОси есть необходимость и надо ввести пароль — вопрос очень скользкий. В двух словах все это вообще не повышение привилегий. Это вопрос о вменяемости юзера, и что именно кликнул. Не смотря на то что МакОсь тру Unix, в ней по умолчанию вообще нет учетной записи root. А зачем? Если нужно реальное повышение привилегий такую учетную запись придется завести ручками, под ней зайти и уже тогда ломать себе операционку. В общем и целом МакОсь неубиваема без намерения и воли продвинутого юзера, который точно знает как всё поломать. А 99% всех юзеров не знают что это вообще Юникс, и тем более что такое root, им это лишнее знание ни на что не влияющее.
А в винде если спрашивает, то это реальное повышение привилегий вплоть до возможности рут-кит в Ось внедрить. А задалбывает... На неслабом компе двухмониторная конфигурация, оба монитора FullHD (да, я богатый буржуй, второй монитор 42" LCD панель) когда окошко UAC хочет всплыть начинается коллапс всех систем секунд на 5-10. Все что было под DirectX запущено вываливается в эксцепшн, начинается коллапс всех систем у эксплорера, медиаплеер наинается заикаться как эпилептик. И начинается мучительная отрисовывка затенения десктопов на двух мониторах и потом наконец появляется диалог UAC. Бесит ли это? Поначалу не очень, даже приколько когда музыка начинается заикаться, звук похож на семплы транс-музыки. Когда эффект новизны прошел начинает БЕСИТЬ! Отключение второго монитора зело помогает.
Индусам надо как-то законодательно в ООН ограничить рождаемость и приход в профессию программистов.
G>Я тут попробовал описать свои впечатления от WinRT
G>Честно, даже не знаю куда отправить По логике вещей это надо в COM, или C++. Но самое главное уже более-менее понятно. Перед нами новая версия COM.
Нет. Кто вам сказал, что WinRT — новая версия COM? новое компонентное API для Windows 8 — Да
А>Нет. Кто вам сказал, что WinRT — новая версия COM? новое компонентное API для Windows 8 — Да
Андерс Хайлсберг и Герб Саттер Это новое компонентное API отличается от COM несколькими методами и одним интерфейсом.
G>Здравствуйте, <Аноним>, Вы писали:
А>>Нет. Кто вам сказал, что WinRT — новая версия COM? новое компонентное API для Windows 8 — Да
G>Андерс Хайлсберг и Герб Саттер Это новое компонентное API отличается от COM несколькими методами и одним интерфейсом.
А также совместимыми форматами метаданных (winmd файл можно в рефлекторе паачитать са всеми кааментами),
отсутствием маршалинга (то бишь скорость вызовов как в .NET->.NET), ну и производительностью (ядро не надо JIT-ить)