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

H>Да ты сам подумай, что умеет тот паинт... Палочки да кружочки рисовать (о его способности ко встраиваемости мы умолчим ибо не суть).

Значит можно говорить только про те фичи, которые тебе интересны ?

>А тот WordPad... Ну юзает он ричедит виндовый, большое понимаешь дело В общем, в подобном софте собственного функционала кот наплакал, посему гуй там самая сложная часть. Так что не гони ка ты сам.

Есть вроде как исходники для этих двух софтин, можешь посмотреть если хочешь

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

I> H>Да ты сам подумай, что умеет тот паинт... Палочки да кружочки рисовать (о его способности ко встраиваемости мы умолчим ибо не суть).

I> Значит можно говорить только про те фичи, которые тебе интересны ?

Реализация нескольких интерфейсов не ахти какая сложная задача, смысл на ней заострять внимание?

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

Кроме JIT есть еще один момент — в библитеках .Net имеется большое количество различных проверок, которые влияют на скорость работы. Например, довольо часто (особенно в WPF) происходит проверка, в каком потоке вызван метод. Можно сказать, что (в терминах Visual C++) программа всегда работает с DEBUG версиеий библиотеки (только вместо ASSERT получаем Exception). И эти проверки имеют место не только в библиотеках, но и в самом скомпилированном коде (проверки границ массивов и т.п.).

Но особенно сильных тормозов в .Net, я, увы, не наблюдаю.

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

H>Ну как же, профиты наипрямые (по мотивам КСВ): управляемый код не уступает в скорости нативному (тут об этом каждый нетер знает), управляемый код легче писать и проще поддерживать т.к. нет множественных граблей с мемори-ликами, указателями и прочим нативным непотребством (тут об этом знает каждый второй нетер),
Ну, в теории — да. Вопрос по производительности деликатно опустим.

H> а следовательно новая версия браузера выйдет раньше конкурентов и будет быстрее обрастать новыми фичами (это ли не профит, ё-мое).
А теперь грубо шмякаемся об реальность. МС всего-то что и придётся: переписать на другую платформу без малейшего код-реюза. Очевидно, это прям на порядки быстрее, чем выпуск новой версии по устоявшемуся процессу.

Итак, что МС получит по сравнению с текущей ситуацией?

H>Что касается совместимости, то ее легко обеспечить неким аналогом прокси-объектов, в общем ничего сверхестественного в этом нет

Спасибо, день сделан!

H> Кстати, читал интервью, правда о IE8, с господином Могилевским, так он говорил, что браузер переписывают практически с нуля, видимо не все так страшно, как ты рисуешь
Увы, к реальности это утверждение имеет очень малое отношение. Для совместимости там фактически полноценный render engine от ie7.

H>Скажи, какой был смысл превращать EventViewer в тормозное это-самое?
А это — как раз пример софта, на которое у них не было ни спецов по юзабилити, ни UI-дизайнеров, ни грамотных девелоперов. Одно то, что UI заморожен пока не прочтётся _весь_ лог говорит очень о многом.

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

S> H> а следовательно новая версия браузера выйдет раньше конкурентов и будет быстрее обрастать новыми фичами (это ли не профит, ё-мое).

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

А C++/CLI как же? Реюзь нехочу

S> Итак, что МС получит по сравнению с текущей ситуацией?

Рекламу .NET'у сделает такую, что самый последний ненавистник повесится в туалете (хотя я то точно знаю, что окромя тормозов фиг она там чего получит )

S> H>Что касается совместимости, то ее легко обеспечить неким аналогом прокси-объектов, в общем ничего сверхестественного в этом нет

S>
S> Спасибо, день сделан!

А чему ты удивляешься? Это стандартная практика, когда делается что-то новое, то для обеспечения совместимости (коли есть задача такая) со старым кодом делается специальная прослойка (как хочешь ее называй, я прокси назвал) обеспечивающая бесшовную работу старого кода с новым. Причем, даже архитектурные вопросы данным способом улаживаются вполне

S> H> Кстати, читал интервью, правда о IE8, с господином Могилевским, так он говорил, что браузер переписывают практически с нуля, видимо не все так страшно, как ты рисуешь

S> Увы, к реальности это утверждение имеет очень малое отношение. Для совместимости там фактически полноценный render engine от ie7.

Ну и пусть для совместимости так и будет, что нет механизмов взаимодействия управляемого кода с нативом что ли Пусть совместимое будет чуть более тормозным, зато новье будет летать ( )

S> H>Скажи, какой был смысл превращать EventViewer в тормозное это-самое?

S> А это — как раз пример софта, на которое у них не было ни спецов по юзабилити, ни UI-дизайнеров, ни грамотных девелоперов. Одно то, что UI заморожен пока не прочтётся _весь_ лог говорит очень о многом.

Ну а вот Task Scheduler, нафиг там .NET потребовался, какой от него профит (кроме меньших затрат на стадо индусов)? Гуй не замерзает в моменты чтения, но тормоза зверские.

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

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

H>А C++/CLI как же? Реюзь нехочу
Эдакий франкенштейн тут же убьёт все бонусы от managed-кода.

H>Рекламу .NET'у сделает такую, что самый последний ненавистник повесится в туалете (хотя я то точно знаю, что окромя тормозов фиг она там чего получит )
Гмм... ну и нафига МС, чтобы их обвиняли в геноциде ненавистников? Нащщёт тормозов — вся из себя managed vs2010 у меня на машине работала значительно шустрее 2008й (пока переползали). Увы, тормоза не зависят от используемой платформы.


H>А чему ты удивляешься? Это стандартная практика, когда делается что-то новое, то для обеспечения совместимости (коли есть задача такая) со старым кодом делается специальная прослойка (как хочешь ее называй, я прокси назвал) обеспечивающая бесшовную работу старого кода с новым. Причем, даже архитектурные вопросы данным способом улаживаются вполне

Тем, что это "лехко" для кода, который никем не используется, а если что и поломалося — клиенты ССЗБ, сами как нить поправят. IE — эт сволочь такая платформа, что аж завидно. Множество корпоративов даже на Висту никак не переползёт в том числе и из-за кривых веб-клиентов, а тут вы кавалерийским наскоком надеетесь перетащить все багофичи на новую платформу.

H>Ну и пусть для совместимости так и будет, что нет механизмов взаимодействия управляемого кода с нативом что ли Пусть совместимое будет чуть более тормозным, зато новье будет летать

Я ещё раз вам намекну, что масштабы потребной работы и выхлоп — удовлетворение вас, любимого — ну никак не соотносятся. И, пожалуй из этой темы уползу. Приятного вам холивара.

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

S> H>А C++/CLI как же? Реюзь нехочу

S> Эдакий франкенштейн тут же убьёт все бонусы от managed-кода.

Ой да ладно, он позволит быстренько выпустить продукт, а потом потихоньку переписывать на православный шарп

S>Нащщёт тормозов — вся из себя managed vs2010 у меня на машине работала значительно шустрее 2008й (пока переползали). Увы, тормоза не зависят от используемой платформы.

Гы. Когда говорят о тормозах 2010, говорят, что там тормозит нативный код. Когда рассказывают о том, что 2010 работает значительно шустрее, выясняется, что она вся из себя managed Доставляет

S> H>А чему ты удивляешься? Это стандартная практика, когда делается что-то новое, то для обеспечения совместимости (коли есть задача такая) со старым кодом делается специальная прослойка (как хочешь ее называй, я прокси назвал) обеспечивающая бесшовную работу старого кода с новым. Причем, даже архитектурные вопросы данным способом улаживаются вполне

S> Тем, что это "лехко" для кода, который никем не используется, а если что и поломалося — клиенты ССЗБ, сами как нить поправят. IE — эт сволочь такая платформа, что аж завидно. Множество корпоративов даже на Висту никак не переползёт в том числе и из-за кривых веб-клиентов, а тут вы кавалерийским наскоком надеетесь перетащить все багофичи на новую платформу.

Мозиловцам (есть/был у них контрол заменяющий IWebBrowser) это по плечу, а МС'у, владельцу кода, нет... Ниверю.

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

H>Ой да ладно, он позволит быстренько выпустить продукт, а потом потихоньку переписывать на православный шарп

Быстренько не получится. Слишком много работы вложено в имеющиеся версии.

H> Гы. Когда говорят о тормозах 2010, говорят, что там тормозит нативный код. Когда рассказывают о том, что 2010 работает значительно шустрее, выясняется, что она вся из себя managed Доставляет

Вобщето с ней чтото странное есть. Но ноуте этой весной она почему то работала быстрее, чем на более мощном полноценном компе. Щас комп другой замерить не могу.

S>> Тем, что это "лехко" для кода, который никем не используется, а если что и поломалося — клиенты ССЗБ, сами как нить поправят. IE — эт сволочь такая платформа, что аж завидно. Множество корпоративов даже на Висту никак не переползёт в том числе и из-за кривых веб-клиентов, а тут вы кавалерийским наскоком надеетесь перетащить все багофичи на новую платформу.

H>Мозиловцам (есть/был у них контрол заменяющий IWebBrowser) это по плечу, а МС'у, владельцу кода, нет... Ниверю.

У них был такой контрол, он он заменял только если прога не завязывалась ан всю DOM-модель и АПИ бровзера.

Т.е. если только навигацию осуществлять, то я сам тебе могу написать такой контрол

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

I> H>Ой да ладно, он позволит быстренько выпустить продукт, а потом потихоньку переписывать на православный шарп

I> Быстренько не получится. Слишком много работы вложено в имеющиеся версии.

Дык код-реюз же

I> H>Мозиловцам (есть/был у них контрол заменяющий IWebBrowser) это по плечу, а МС'у, владельцу кода, нет... Ниверю.

I> У них был такой контрол, он он заменял только если прога не завязывалась ан всю DOM-модель и АПИ бровзера.

Судя по этому документу, на тот момент совместимость была очень хорошая. И это, заметь, без доступа к исходникам вообще. А то тут сказочки начинаются о сложности воспроизведения поведения прошлых версий.

I> Т.е. если только навигацию осуществлять, то я сам тебе могу написать такой контрол

Там не только навигация.

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

I>> Быстренько не получится. Слишком много работы вложено в имеющиеся версии.

H>Дык код-реюз же

Проще по чуть чуть добавлять, как с MMC

I>> У них был такой контрол, он он заменял только если прога не завязывалась ан всю DOM-модель и АПИ бровзера.

H>Судя по этому документу, на тот момент совместимость была очень хорошая. И это, заметь, без доступа к исходникам вообще. А то тут сказочки начинаются о сложности воспроизведения поведения прошлых версий.

А ты свои ссылки читаешь ?

'It is important to note that the Mozilla control will not have a complete implementation of the DOM since it is extremely complex'

Это вобщем то основная проблема с совместимостями линейке IE и она же является препятствием для наращивания функционала и перформанса.

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

I> Проще по чуть чуть добавлять, как с MMC

Дык даже по чуть-чуть не решаются. А MMC уже превратили в говно

I> I>> У них был такой контрол, он он заменял только если прога не завязывалась ан всю DOM-модель и АПИ бровзера.

I> H>Судя по этому документу, на тот момент совместимость была очень хорошая. И это, заметь, без доступа к исходникам вообще. А то тут сказочки начинаются о сложности воспроизведения поведения прошлых версий.

I> А ты свои ссылки читаешь ?

I> 'It is important to note that the Mozilla control will not have a complete implementation of the DOM since it is extremely complex'

Ага. Ты аккуратно не процитировал дальше:

Here is what you can expect:
Implementation of most common element types
Retrieve element info such as class name, id etc.
Traversal functions. Parse the DOM using methods such as get_children, get_all, get_parent etc.
Attribute setting and getting, e.g. setAttribute, getAttribute etc.
Simple modifications, for instance to be able to set or get text from text elements
Integration with the ActiveX Plug-in support (if present) so that ActiveX objects in the HTML are available to clients.

What you shouldn't expect:
Exact DOM mapping between IE and Mozilla. The IE wrapper control uses the Mozilla (and therefore W3C DOM level 1 standard) for its element hierarchy and not the IE one.
Implementation of complicated methods. By complicated I mean ones where there is no direct mapping between the IE method and the Mozilla equivalent.

I> Это вобщем то основная проблема с совместимостями линейке IE и она же является препятствием для наращивания функционала и перформанса.

Это делали люди имея на руках готовый движок (Gecko), который по внутренней структуре мог сильно отличаться от трайдента. Разумеется, полного соответствия никто не мог гарантировать. Тут же мы говорим о МС, которая, и кодом владеет, и вообще всей информацией о собственном движке. Более того, что им мешало написав новый IE под .NET продолжать поставлять нативный трайдент? Пускай, те кому нужна совместимость, пользуются старой версией (т.е. для них все будет совершенно прозрачно), а кто хочет новую то вот она и уж тут сами проверяйте на совместимость Просто существовало бы два движка, один для легаси, другой весь из себя передовой. Развивать только новый движек, а старый просто заморозить, почему нет?

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

I>> Проще по чуть чуть добавлять, как с MMC

H>Дык даже по чуть-чуть не решаются. А MMC уже превратили в говно

По чуть-чуть таки решаются. Они кое какие плагины на дотнете пишут, например NodeXL

I>> I>> У них был такой контрол, он он заменял только если прога не завязывалась ан всю DOM-модель и АПИ бровзера.

I>> H>Судя по этому документу, на тот момент совместимость была очень хорошая. И это, заметь, без доступа к исходникам вообще. А то тут сказочки начинаются о сложности воспроизведения поведения прошлых версий.

I>> А ты свои ссылки читаешь ?

I>> 'It is important to note that the Mozilla control will not have a complete implementation of the DOM since it is extremely complex'

H>Ага. Ты аккуратно не процитировал дальше:

Читай сам:

H>

H>What you shouldn't expect:
H>Exact DOM mapping between IE and Mozilla. The IE wrapper control uses the Mozilla (and therefore W3C DOM level 1 standard) for its element hierarchy and not the IE one.
H>Implementation of complicated methods. By complicated I mean ones where there is no direct mapping between the IE method and the Mozilla equivalent.

I>> Это вобщем то основная проблема с совместимостями линейке IE и она же является препятствием для наращивания функционала и перформанса.

H>Это делали люди имея на руках готовый движок (Gecko), который по внутренней структуре мог сильно отличаться от трайдента. Разумеется, полного соответствия никто не мог гарантировать. Тут же мы говорим о МС, которая, и кодом владеет, и вообще всей информацией о собственном движке. Более того, что им мешало написав новый IE под .NET продолжать поставлять нативный трайдент? Пускай, те кому нужна совместимость, пользуются старой версией (т.е. для них все будет совершенно прозрачно), а кто хочет новую то вот она и уж тут сами проверяйте на совместимость Просто существовало бы два движка, один для легаси, другой весь из себя передовой. Развивать только новый движек, а старый просто заморозить, почему нет?

Потому что два продукта будут конкурировать между собой, внутривидовая борьба так сказать.

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

I> I>> Проще по чуть чуть добавлять, как с MMC

I> H>Дык даже по чуть-чуть не решаются. А MMC уже превратили в говно

I> По чуть-чуть таки решаются. Они кое какие плагины на дотнете пишут, например NodeXL

Плагины это не то Одно дело MMC, где они решают, и совсем другое дело браузер.

I> Читай сам:

I> H>

H>What you shouldn't expect:

I> H>Exact DOM mapping between IE and Mozilla. The IE wrapper control uses the Mozilla (and therefore W3C DOM level 1 standard) for its element hierarchy and not the IE one.
I> H>Implementation of complicated methods. By complicated I mean ones where there is no direct mapping between the IE method and the Mozilla equivalent.

Дык я это читал, потому и говорю:

Разумеется, полного соответствия никто не мог гарантировать. Тут же мы говорим о МС, которая, и кодом владеет, и вообще всей информацией о собственном движке.

I> Потому что два продукта будут конкурировать между собой, внутривидовая борьба так сказать.

Так не будет никаких двух продуктов Будет новый, передовой IE и оставленный для совместимости, замороженный, старый трайдент.

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

A>это из каких соображений???

за павла не скажу, но, по моему, соображения два: скорость и простота разработки. да, о пользователях не подумали, но такой стиль приносит деньги в индустрии софта и железа. а это означает их развитие.

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

A>>это из каких соображений???
_R_>за павла не скажу, но, по моему, соображения два: скорость и простота разработки. да, о пользователях не подумали, но такой стиль приносит деньги в индустрии софта и железа. а это означает их развитие.
да это понятно, но Павел-то, говоря что "должно увеличиваться пропорционально", имеет в виду что сейчас потребности программ растут быстрее чем мощность железа, а не "как должно быть"

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

A>да это понятно, но Павел-то, говоря что "должно увеличиваться пропорционально", имеет в виду что сейчас потребности программ растут быстрее чем мощность железа, а не "как должно быть"

и говорит это с ужасом

не сейчас. всегда так было, иначе откуда устойчивое выражение "xxx тормозит"? из тех самых времен за которые он ратует. еще вспоминается прикол, что производители железа доплачивали гейтсу/производителю игрушки (по вкусу).

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

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

A>>да это понятно, но Павел-то, говоря что "должно увеличиваться пропорционально", имеет в виду что сейчас потребности программ растут быстрее чем мощность железа, а не "как должно быть"
_R_>и говорит это с ужасом
я бы сказал "с полным непониманием о чём говорит", да вот Кочетков тут недовольство проявляет

_R_>а вот сейчас ситуация изменилась. правильно он говорит, что видимый функционал не далеко шагнул, но ведь и бсод уже не притча все языцех?
и ты туда же? расскажи, что ты считаешь "видимым" функционалом для компилятора и прочей коммандлайнщины

а вот это — "Я (как пользователь) их на экране вижу" — простите, несерьёзно

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

A>я бы сказал "с полным непониманием о чём говорит", да вот Кочетков тут недовольство проявляет

Ну он добрый папа

A>и ты туда же? расскажи, что ты считаешь "видимым" функционалом для компилятора и прочей коммандлайнщины

Я говорил про фичалист, а не про гуй. По сути ведь не далеко ушли от тех времен. Всего то 3.2 -> 4. Но я не склонен драматизировать ситуацию — в стандартах бардак полный, да, но вот память и гигагерцы меня мало волнуют. Павел, похоже, за идею, а меня и так устраивает.

A>а вот это — "Я (как пользователь) их на экране вижу" — простите, несерьёзно

А вот это самое серьезное и есть. Именно по тому какой отклик того что на экране и складывается впечатление о продукте.

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

A>>и ты туда же? расскажи, что ты считаешь "видимым" функционалом для компилятора и прочей коммандлайнщины
_R_>Я говорил про фичалист, а не про гуй. По сути ведь не далеко ушли от тех времен.
о как. вообще-то, фич добавилось чуть более чем дофига, просто было объявлено что все фичи что не были в 96ом — идут лесом. с таким подходом конечно недалеко

A>>а вот это — "Я (как пользователь) их на экране вижу" — простите, несерьёзно
_R_>А вот это самое серьезное и есть. Именно по тому какой отклик того что на экране и складывается впечатление о продукте.
какие пользователи, какой отклик, на каком экране. вовсю обсуждаются компиляторы и IDE, на которые пользователям покласть, а для разработки экономить на спичках просто нечестно хотя бы по отношению к тому же пользователю.

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

A>о как. вообще-то, фич добавилось чуть более чем дофига, просто было объявлено что все фичи что не были в 96ом — идут лесом. с таким подходом конечно недалеко

да не фичи это, а юзабилити. прорывов не припомню.

A>какие пользователи, какой отклик, на каком экране. вовсю обсуждаются компиляторы и IDE, на которые пользователям покласть, а для разработки экономить на спичках просто нечестно хотя бы по отношению к тому же пользователю.

вот об этом я и говорю. не честно, но выгодно