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

_>Версионность тут не причём. Люди пишут программы с ошибками. Особенно много ошибок в то время когда программа только разрабатывается. Т.е. человек не знает ещё что он собирается вызывать, ещё не знает что будут вызывать у него, не знает что можно передавать а что нет. И COM только усложняет этот этап. Если бы сразу ввели в стандарт требования на документирование самим IUnknown поддерживаемых им интерфейсов и методов, всё было бы в тысячи раз проще. И Ole Automation изобретать не пришлось бы.

ИМХО, подход неверный, нужно работать с целевыми интерфейсами — наследниками — IUnknown, тогда и проблем таких не будет. Ну а с точки зрения проектирования, это очень хорошо, что тебе при создании компонента надо будет сесть и подумать какие интерфейсы тебе нужны, как будет взаимодействие происходить и т.д.

_>А то что чёрным ящиком должна быть только реализация. А в случае с COM чёрным ящиком является вообще всё. Что этот объект может, к чему ещё его можно скастить, какие методы у него будут если он успешно скастится к чему-то ещё.

Набор интерфейсов определяет доступную ф-сть, у тебя столько же информации как и при испоользовании скажем API какой-нибудь библиотеки.

_>Ну то есть идея такая плохая что больше никто у себя подобное реализовать не захотел, а технология построенная на этой идее хорошая? А может закономерно — хреновую идею уже никакая реализация не спасёт?

есть нечто похожее — CORBA, не забывай, что реализация требует больших вложений (тем более реализация такой слоджной системы).

M>>Чего пенять на всю технологию, если обжегся на IE? С другой стороны, посмотри на описание объектной модели офиса — все четко описано, пусть и не очень подробно.
_>Офис? А видел как оттестированный в ActiveX Control Test Container контрол, ведёт себя совсем по другому в Word, по третьему в Excel, и совсем не позволяет себя вставить в PowerPoint? Ведь тот же COM, что ж опять всё не так-то. А им оказывается какой-то очередной I***Site* понадобился, и на его нехватку они реагируют кто как.

И где же его тестировали? Согласен, что офис криво поддерживает ActiveX, но сам-то офис — сплошной COM и работает исправно.

M>>А как иначе? Откуда прога знает что ты хочешь? Или ты хочешь работать в стиле "дай мне то не знаю что"? так только в сказках
_>Да в этом стиле куча народу работает. Надо получить размер окна. Есть объект скажем Window, нажимают ., смотрят — какие методы есть. Вбивают наугад Size, есть — хорошо, попались сразу два ClientSize, OuterSize — выбираем который подходит, нет ни одного — поищем тем же способом что-нибудь с Rect, нашлось — отлично, нет — поищем какой-нить Manager, может он знает, и т.д. А в стиле COM — есть объект IWindow, методов всего пара штук, все остальные описаны у IWindow3 скажем, про IWindow3 ты узнаешь только в документации, если есть. А если метод Size описан у какого-нить ISizeableHostedControl, то простым поиском по Window ты его вообще не найдёшь. Отличная технология для программистов.

Ага, только аналогия кривая. Если твой объект Window — базовый класс, то хрен ты получишь свойства наследника. А вот если IWindow2 наследуется от IWindow, то нет проблем с получегтем свойств базового интерфейса.


M>>и что? как недоработка того или иного COM-объекта кидает тень на технологию? Таже ситуация может быть с любой библиотекой.
_>Это недоработка самой технологии. Типизация объектов подразумевается, но получить информацию о типах нельзя. Возможность ошибок подразумевается, но оставляется возможность для возврата пустого E_FAIL. Версионность подразумевается, но работа с нею отдана на откуп тем же несовершенным людям.

Голову никто не отменял и система не может знать чего ты хочешь.

_>Объект, создаёт вложенные объекты, много. Дальнейший алгоритм работает только с вложенными, посему ссылка на корень успешно грохается смарт-пойнтером при выходе, вложенные тут же умирают, потому что по логике реализации библиотеки они не имеют смысла без корня. А корень умирает — потому что COM требует удаления объекта. Все делают свою работу честно, и заметь, даже циклических ссылок нет. А ошибка есть. Посколько крайнего не найти, всё валим на COM

Разговор об абстрактном коне в вакууме.
Попробую выяснить. У тебя есть com-объект А, который создает множество других com-объектов N1..NN? Где эти com-объекты NN храняться? внутри объекта A?

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

КЛ>Здравствуйте, michae1, Вы писали:

КЛ>то, что ты пару раз за карьеру подергал STA объекты, и уже мнишь себя экспертом.

не буду тебя переубеждать, я лишь высказал свое мнение исходя из своего опыта.

M>>было бы что сказать

КЛ>я уже все сказал. вот когда надо будет написать многопоточный COM-exe сервер с UI из IE/Shell, тогда вспомнишь мои слова.

не переживай, я решал сложные задачи на базе COM.

Здравствуйте, Ночной Смотрящий, Вы писали:

ГВ>> Мне это недоступно, звиняй.
НС>О чем тогда ты споришь? О том, что Синовский умеет выпускать очень сложный продукт строго в срок и с приемлемым качеством? Так с этим никто и не спорит.

Если ты успел заметить, то я не спорю, а только пытаюсь несколько уточнить своё представление о том, что и как происходит в MS.

Здравствуйте, Ночной Смотрящий, Вы писали:

ГВ>>При чём тут Unity?
НС>При том что это прекрасный пример того, как линух "не собирается кардинально меняться ради "выигрывания битв".

Хорошо, замнём для ясности, а то сейчас набегут.

ГВ>>Однако, никто же не собирается делать managed-ядро для Линукса
НС>А что, кто то собирается делать managed ядро Windows?

Ну, сейчас, как я понимаю, эту безумную затею уже забросили.

M>есть нечто похожее — CORBA, не забывай, что реализация требует больших вложений (тем более реализация такой слоджной системы).
Чисто по памяти, когда по COM'у первые книжки выходили, CORBA уже вовсю была. Но к счастью стала матёрой legacy, и под видом новой технологии, например Win RT, нам её не выкатывают

M>>>Чего пенять на всю технологию, если обжегся на IE? С другой стороны, посмотри на описание объектной модели офиса — все четко описано, пусть и не очень подробно.
_>>Офис? А видел как оттестированный в ActiveX Control Test Container контрол, ведёт себя совсем по другому в Word, по третьему в Excel, и совсем не позволяет себя вставить в PowerPoint? Ведь тот же COM, что ж опять всё не так-то. А им оказывается какой-то очередной I***Site* понадобился, и на его нехватку они реагируют кто как.

M>И где же его тестировали? Согласен, что офис криво поддерживает ActiveX, но сам-то офис — сплошной COM и работает исправно.
Где тестировали свои контейнеры и контролы MS я не знаю. А сам ActiveX Control Test Container был долгие годы референсной реализацей контейнера и открыт в сорцах. Именно его драли вчистую когда хотели сделать у себя внедрение на манер офисного. И предварительное тестирование тоже на нём делали из-за удобства. Ну и вообще полагались на интуитивное — что технология универсальная, и если заведётся в одном контейнере, то и в остальных тоже. Поэтому облом при внедрении в стандартный офис был особенно неожиданным первые разы

А так вообще на COM работает и Офис, и студия до последнего времени, и IE. Но это больше потому что сил в работоспособность вложено было немеряно.

M>Ага, только аналогия кривая. Если твой объект Window — базовый класс, то хрен ты получишь свойства наследника. А вот если IWindow2 наследуется от IWindow, то нет проблем с получегтем свойств базового интерфейса.
Одним махом, не глядя в сорцы, обычно можно получить всех наследников реализованных той же библиотекой, ну или просто зайти в отладчик и уточнить реальный тип имеющегося экземпляра и все интерфейсы которые он поддерживает.

M>Разговор об абстрактном коне в вакууме.
M>Попробую выяснить. У тебя есть com-объект А, который создает множество других com-объектов N1..NN? Где эти com-объекты NN храняться? внутри объекта A?

Именно. Один объект создаёт пачку других. По принципам COM где они хранятся меня не волнует, я должен лишь корректно вызывать AddRef/Release. По внутренней логики самой библиотеки, удаление обьекта A делает невалидными все N, поэтому он их резко чистит, или там приводит в нерабочее состояние. smart-пойнтер удаляет A, работоспособность N уходит вслед за ним. Более того, в зависимости от смекалки авторов, иногда экземпляры N тупо удаляются, и вызов их методов в зависимости от того как сошлись звёзды на небе, может как ничего не делать, так и Access Violation устроить. Это я проблему в общем описал, такой которой я её несколько раз в самых разных иерархиях видел. Ну а если хочется конкретики, то DirectX 9 когда я с ним последний раз пересекался, при работе с SwapChain точно также себя повёл, но поскольку глаз намётан и рука уже набита, причина и решение были найдены быстро.

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

КЛ>я уже все сказал. вот когда надо будет написать многопоточный COM-exe сервер с UI из IE/Shell, тогда вспомнишь мои слова.
Если не секрет, какова задача такого сервера? Не лучше ли сделать много однопоточных, ну например как делает сама MS в IE.

Здравствуйте, Евгений Акиньшин, Вы писали:

ГВ>>Что-то у меня складывается обратное впечатление, что он чуть ли не единственный адекватный руководитель в MS:
ЕА>Да, ладно — может он там классный технарь, но руководитель компании из него хуже некуда.

По-видимому, у нас с тобой очень отличается трактовка выражения: "адекватный руководитель". С моей точки зрения, "технарство" — необходимый, но не ключевой скилл.

ЕА>Он за последние пару лет сделал все чтобы уничтожить сообщество лояльных разработчиков МС. История с Сильверлайтом не единственная, но самая показательная — никогда раньше не видел, чтобы компания сама топила новую, феноменально успешную технологию, несмотря на протесты клиентов в угоду личным предпочтениям. Причем делалось это очень демонстративно — типа "а хрен вы куда денетесь". Причем жесткая компания по утоплению сильверлайта началась практически сразу после интервью с Гатри, где он буквально клялся, что все будет развиваться.

Я тут подумал, а какой смысл держаться за технологию, которую надо рихтовать под каждый новый браузер? Это ж ахиллесова пята, а не технология, разве нет? В противовес SL тот же JS поддерживают более или менее все, вне зависимости от их лояльности курсу MS.

ЕА>По мне так то, что избавились от Синофского, лучшая новость о Микрософте для разработчиков

Я этого оптимизма не разделяю, но поглядим.

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

ЕА>>Он за последние пару лет сделал все чтобы уничтожить сообщество лояльных разработчиков МС. История с Сильверлайтом не единственная, но самая показательная — никогда раньше не видел, чтобы компания сама топила новую, феноменально успешную технологию, несмотря на протесты клиентов в угоду личным предпочтениям. Причем делалось это очень демонстративно — типа "а хрен вы куда денетесь". Причем жесткая компания по утоплению сильверлайта началась практически сразу после интервью с Гатри, где он буквально клялся, что все будет развиваться.

ГВ>Я тут подумал, а какой смысл держаться за технологию, которую надо рихтовать под каждый новый браузер? Это ж ахиллесова пята, а не технология, разве нет? В противовес SL тот же JS поддерживают более или менее все, вне зависимости от их лояльности курсу MS.

Одно дело когда отказываешься от технологии по каким-то техническим или маркетинговым причинам и заранее объясняешь своим партнерам почему это сделано. Такой процесс практически всегда идет постепенно, люди успевают хотя бы отбить свои вложения и относятся с пониманием.

Другое дело когда ты активно топишь технологию, потому что у тебя война с отделом, который ее разрабатывает, при этом половина представителей Микрософта говорит, что ничего круче Сильверлайта нет и мы будем это развивать, а другая половина, что Сильверлайт это говно, и его использовать не надо. Офигенно эффективный стиль руководства.


ЕА>>По мне так то, что избавились от Синофского, лучшая новость о Микрософте для разработчиков

ГВ>Я этого оптимизма не разделяю, но поглядим.

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

Здравствуйте, koandrew, Вы писали:
K>"Не напрямую" — это как?

здесь

Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>Другое дело когда ты активно топишь технологию, потому что у тебя война с отделом, который ее разрабатывает, при этом половина представителей Микрософта говорит, что ничего круче Сильверлайта нет и мы будем это развивать, а другая половина, что Сильверлайт это говно, и его использовать не надо. Офигенно эффективный стиль руководства.

Я никогда не следил за новостями SL и потому как-то не в курсе. А что, кто-то из MS говорил, что SL именно не надо использовать?

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

ГВ>Я тут подумал, а какой смысл держаться за технологию, которую надо рихтовать под каждый новый браузер? Это ж ахиллесова пята, а не технология, разве нет? В противовес SL тот же JS поддерживают более или менее все, вне зависимости от их лояльности курсу MS.

Кто тебе сказал, что JS не надо допиливать под каждый новый браузер? Ты в курсе сколько кода для совместимости написано в том же jQuery. А SL работает везде ожидаемо одинаково.

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

ГВ>>Я тут подумал, а какой смысл держаться за технологию, которую надо рихтовать под каждый новый браузер? Это ж ахиллесова пята, а не технология, разве нет? В противовес SL тот же JS поддерживают более или менее все, вне зависимости от их лояльности курсу MS.

IT>Кто тебе сказал, что JS не надо допиливать под каждый новый браузер? Ты в курсе сколько кода для совместимости написано в том же jQuery. А SL работает везде ожидаемо одинаково.

"Допиливать" и "отсуствует" — не одно и то же, не находишь?

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

S>здесь

Ну так мы далеко пойдём — давайте тогда говорить, что они не используют ядро винды — потому что сверху есть как минимум два слоя Однако, если взглянуть на это под другим углом, то оказывается, что COM не просто позволяет разрабатывать высокопроизводительные приложения, но и оказывается настолько быстрым, что даже добавление дополнительных прослоек поверх него обеспечивает приемлимое быстродействие

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

IT>>Кто тебе сказал, что JS не надо допиливать под каждый новый браузер? Ты в курсе сколько кода для совместимости написано в том же jQuery. А SL работает везде ожидаемо одинаково.
ГВ>"Допиливать" и "отсуствует" — не одно и то же, не находишь?

Ты вообще о чём? SL поддерживается всеми браузерами.

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

ГВ>>"Допиливать" и "отсуствует" — не одно и то же, не находишь?
IT>Ты вообще о чём? SL поддерживается всеми браузерами.

Точно?

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

ГВ>>>"Допиливать" и "отсуствует" — не одно и то же, не находишь?
IT>>Ты вообще о чём? SL поддерживается всеми браузерами.
ГВ>Точно?

Всеми известными мне поддерживаются. Тебе видимо известно больше.

Здравствуйте, Ночной Смотрящий, Вы писали:

LC>>Еще раз повторяю вопрос, какие инновации были задавлены Синофски?
НС>Тебя в какой области интересует? Из свежего, к примеру, WPF.
Кстати, вот в это охотно верю. Вспоминается, как Джош Смит написал, что сваливает в iOS, потому что разочаровался в отмене WPF/SL. А я все никак не мог понять причину такого сдвига. Ведь, даже если предположить, что WPF не лучшим образом уживается в API Винды, так ведь его туда никто и не звал. Жил бы себе в рамках .Net, как тонны других технологий, и жил. Теперь же все понятно. Просто прихоть. Это сразу все ставит на свои места.

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

IT>Всеми известными мне поддерживаются.

O'K

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

FR>И как без gcnew мне сделать экземпляр System.String например?

Зачем? Делаешь экземпляр char[]. Когда надо, он легко оборачивается в System.String. Так а в WinRT не сильно лучше. Местная строка тоже вполне конкретная фигня, и если что не так — маршаллинг в полный рост.

НС>>Ничего не понял. Тебе никто не мешает внутри CLR использовать твой любимый счетчик ссылок для объектов из нативной кучи.
FR>Мы с разных сторон смотрим. Меня больше интересует удобство использования компонентов
FR>из нативного кода

А меня больше всего интересуют причины, по которым, вместо докручивания СОМ и минимизации изменений в других местах, типа CLR, выкатывается нечто, не совместимое вообще ни с чем и весь девдив, вместо того чтобы заниматься своим делом, два года перепиливает весь тулчейн под поддержку этой херни. Ну и чего на выходе? Возможность писать под метру, перспективы которой под большим вопросом, на каком то нестандартном С++ чуть удобнее, чем под СОМ? Замах на несколько гигабаксов, удар на копеечку.

FR>Счетчик ссылок позволяет это делать прозрачно, с GC придется учитывать
FR>кучу особенностей

При чем тут вообще GC? Еще раз — CLR не требует никакого GC, хоть и предоставляет его. Совместить managed мир с миром нативного COM тоже проблем нет — там целая пачка отлаженных технологий есть для этого. Докрутите СОМ, подрихтуйте СОМовский маршаллинг в CLR, можно C++/CLI еще немножко подлатать и все. Получаем все тоже самое, только без ломающих изменений. Но нет, у старых технологий есть сами-знаете-какой фатальный недостаток.

НС>>Все зависит от того, что это за вызов.
FR>То есть польза все-таки есть?

Неа. Все, что делает WinRT, все это можно повторить существующими методами интеропа в CLR. Вплоть до прямого вызова без маршаллинга.

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

ГВ>Если ты успел заметить, то я не спорю, а только пытаюсь несколько уточнить своё представление о том, что и как происходит в MS.

Ну тут уже была карикатура МС, где облачка с кучей пистолей, направленных друг на друга. Так вот, пририсуй туда еще калаш — и ты примерно поймешь, какую роль во всем этом играл Синовский.