Re: [ANN] WinRT - новое компонентное API для Windows 8 - .NET

Здравствуйте, VladD2, Вы писали:
КД>>Справа от моего имени есть ссылочка на нефиговый по размерам проект, где все это (COM/MT/ref count) согласованно работает вместе без каких либо проблем.

VD>Не обижайся, но только использование КОМ и С++ позволило вам сделать из провайдера к СУБД "нефиговый по размерам проект". На самом же деле провайдер к БД это весьма примитивный и незначительный по размерам проект. Но для этого, правда, надо ~~дружить с головой~~ понимать с чем имеешь дело

Да ну нафиг. Чего обижаться то

Я же помню — лет шесть (или уже восемь?) мы с тобой уже общались на эту тему.

Ты просто не в теме.

VD>Для примера объем кода одного из самых сложный языков программирования занимает около двух мегабайт.

Это тот самый?

За свое выдать не удастся, ставь копирайты или ссылку на оригинал

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, VladD2, Вы писали:

VD>Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом.

А я вспоминаю ретивого докладчика из MS на одной конфе в 2002 году. И его "следующая операционная система будет позволять выполнять только .NET приложения.". Я на тот уже вроде как должен был бы сказать "данунах", но все равно — что-то внутри вздрогнуло... Пошел уже четвертый год как я сижу на этой "следующей операционной системе" — Vista x64. Все работает. Даже то, что было последний раз откомпилировано в 2001. Страшненьким плюсовым компилятором 98 года.

Жаль, что нельзя вернуться и сказать "не говори гоп, пока не перепрыгнешь"

Здравствуйте, MxMsk, Вы писали:

MM>Я не понял причем здесь компилятор. Мы вроде ведем речь, что есть концепции более удобные, гибкие и надежные, чем reference counting.

Все так. Но у них есть только одна пробелма — за них приходится расплачиваться производительностью и потребляемой памятью.

Преимущество подсчета ссылок в том, что оно может применяться как совместно со сборкой мусора, так и совместно с ручным управлением памяти (или полуавтоматическом, на деструкторах. При этом оно не противоречит детерминированной финализации (ужасный термин

Здравствуйте, Cyberax, Вы писали:

C>Мне не очень понятно в чём тут плюсы по сравнению с классическим решением на умных указателях. Генерация метаинформации — ну ладно, ещё можно простить.

Думаю, главный плюс — это бесшовная интеграция с дотнетом в купе с поддержкой нэйтивного программирования.

Вообще, писать виндовс-приложения на голых плюсах всегда было не удобно. Для упрощения всегда делали кучу оберток. И даже с ними постоянно появлялись проблемы.

Здравствуйте, grosborn, Вы писали:

G>За свое выдать не удастся, ставь копирайты или ссылку на оригинал

Классику знать надо. Ни то, скоро, придется копирайт к сказкам Пушкина приделывать.

В гугле тебя не забанили пока?

ЗЫ

Что до авторства, то если что, я автор перевода.

Здравствуйте, Коваленко Дмитрий, Вы писали:

VD>>Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом.

КД>А я вспоминаю ретивого докладчика из MS на одной конфе в 2002 году. И его "следующая операционная система будет позволять выполнять только .NET приложения.". Я на тот уже вроде как должен был бы сказать "данунах", но все равно — что-то внутри вздрогнуло... Пошел уже четвертый год как я сижу на этой "следующей операционной системе" — Vista x64. Все работает. Даже то, что было последний раз откомпилировано в 2001. Страшненьким плюсовым компилятором 98 года.

КД>Жаль, что нельзя вернуться и сказать "не говори гоп, пока не перепрыгнешь"

Ты похоже не понял основного посыла моего высказывания. Ну, да трактавать юмор и сарказм — это последнее дело.

Тебе же я советую не выносить поспешных суждений о дотнете. Ты явно с ним пока что знаком очень поверхностно. Поверь человеку изучавшему COM и .Net по мери их появления — все намного сложнее чем ты себе представляешь.

Здравствуйте, VladD2, Вы писали:

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.

Здравствуйте, Cyberax, Вы писали:

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.

Ну, блока — это реальная стратегия МС исправить фатальный недостаток в локальных серверах

Здравствуйте, VladD2, Вы писали:

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 хочет, чтобы использовали только их компилятор, да и ещё активно насаживает расширения языка.

Я смотрю здесь собралась весьма почтенная и грамотная публика. Может кто нибудь сможет ответить на мои вопросы:

1. Сейчас колупаю Windows API. Естественно использую C++ (ну это скорее С, как я понимаю). Более менее разобрался как работать объектами ядра, синхронизацией. Сейчас смотрю, как с GUI работать через WIN API — ну это скорее, чтобы понимать как оно все устроено на нижнем уровне. Вот я смотрю на этот ИМХО говнокод, смесь бульдога с носорогом и крышечками и возникает закономерный вопрос. А БУДУТ ЛИ В WIN 8 ПОДДЕРЖИВАТЬСЯ "КЛАССИЧЕСКИЕ" API ФУНКЦИИ НА СТАНДАРТНОМ С++?

2. Очевидно, что MFC окончательно загинается, GUI на API — долго, нудно, скудно и коряво, скорее всего для GUI будет использоваться в основном .NET, который позволяет быстренько наклепать добротное гуевое приложение. Однако охота использовать API, многопоточность, объекты ядра, синхронизацию, memory mapped files и другие нужные мне низкоуровневые "полезности". Как это все интегрируется ?

Здравствуйте, VladD2, Вы писали:

VD>Всем запастись попкорном и ждать новых серий из цикла "краткие истории программных революций от Microsoft". Ведь WinRT наверняка революционно изменит Windows-программирование... примерно на год

Ну про дотнет там то же самое было написано, сам процитировал