![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
singalenКогда-то давно потерял этот текст, кажется, 2000-го года. Чтобы не потерялся, запишу сюда.
Автор, увы, неизвестен.
История программных революций от Microsoft, вкратце:
Сначала были Windows API и DLL Hell. Революцией №1 было DDE - помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток - его писали не они! Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием "по месту", при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.
Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда - и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток - его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через броузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).
Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции "System File Protection", исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java - её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие. Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно - недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили "COM" или "Active" или "X" или "+" - они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про "Windows DNA" (почему не DINA) и "Windows Washboard", и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.
К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как "doughnut (пончик по-нашему)", но по-другому), похожей на Интернет, но с большим количеством пресс-релизов. Главное, что нужно очень четко понимать - .NET исключает DLL Hell.
В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.
Автор, увы, неизвестен.
История программных революций от Microsoft, вкратце:
Сначала были Windows API и DLL Hell. Революцией №1 было DDE - помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток - его писали не они! Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием "по месту", при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.
Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда - и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток - его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через броузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).
Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции "System File Protection", исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java - её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие. Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно - недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили "COM" или "Active" или "X" или "+" - они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про "Windows DNA" (почему не DINA) и "Windows Washboard", и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.
К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как "doughnut (пончик по-нашему)", но по-другому), похожей на Интернет, но с большим количеством пресс-релизов. Главное, что нужно очень четко понимать - .NET исключает DLL Hell.
В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.
Tags:
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
13/2/09 15:08 (UTC)"И слава Богу - если несколько разных объектов разных производителей вместе считают ссылки на один объект, и могут гадить в адресном пространстве друг друга - мама..."
ты сам по понимаешь что написал?
"Повторяю, разрешать чужому коду работать в твоём адресном пространстве - плохая идея." тогда вообще не используй никакие DLL библиотеки сторонних производителей... так как COM (inproc server) это так же dll с выставленной наружу vtbl... от dll слабо отличается с точки зрения нагадить в чужую память
"и в КАКОЙ-ЛИБО версии нём где-то есть ошибки работы с указателями — а в C++ и unmanaged code вообще это практически неизбежно — то у тебя большие проблемы"
да... да, в конечных продуктах, а вот если они появляются в компонентных - это уже руки крюки.. суть в том, что компоненты обычно не такие уж и большие и все указатели там нормально можно отследить, если их нормально (boost::shared_ptr, boost::weak_ptr) юзать... в большом проекте с кучей ламеров это конечно на порядок сложнее
"У внепроцессного сервера своя проблема - производительность"
оно то и предназначение у них децл другое
"2. Я в теме. Я прекрасно понимаю, что именно поэтому эта половина винды так тормозит. А вторая половина без первой, увы, не поедет." бред как он есть..
еще раз: по большей части COM - это dll с выставленным vtbl, выставь просто свои функции и почти COM
"опулярность С++ - отдельная тема. Для меня очевидно, что есть языки более простые и более высокого уровня, и более пригодные к программмированию, чем, скажем, C++ и Java в момент их создания"
это спор вечен, но то, что нет более выразительного языка чем С++- факт :)
(no subject)
13/2/09 15:53 (UTC)Не пишите в мой журнал больше, пожалуйста.
(no subject)
13/2/09 16:01 (UTC)(no subject)
13/2/09 18:15 (UTC)(no subject)
13/2/09 18:16 (UTC)(no subject)
13/2/09 18:23 (UTC)Это неправда.
(no subject)
13/2/09 18:37 (UTC)"И слава Богу - если несколько разных объектов разных производителей вместе считают ссылки на один объект, и могут гадить в адресном пространстве друг друга - мама..."
ты сам по понимаешь что написал?
не совсем культурная форма, конечно, но тут я попытался объяснить, что то, что кто-то считает чью-то ссылки вовсе не означает, что гадят память, ибо с таким же успехом можно предположить что память гадят CStringT, _bstr_t, shared_ptr, shared_array, auto_ptr и так далее... они тоже считают ссылки... inproc COM сервер мало чем отличается от dll, которая экспортирует функции.
"Повторяю, разрешать чужому коду работать в твоём адресном пространстве - плохая идея." тогда вообще не используй никакие DLL библиотеки сторонних производителей... так как COM (inproc server) это так же dll с выставленной наружу vtbl... от dll слабо отличается с точки зрения нагадить в чужую память
тут я попытался объснить, что следуя этой идее, т.е. запрещать чужому коду лазить в собственное пространство, нужно вообще не использовать сторонних библиотек (dll), да и обычных типа MFC тоже (по хорошему). а это является полностью impossible
"и в КАКОЙ-ЛИБО версии нём где-то есть ошибки работы с указателями — а в C++ и unmanaged code вообще это практически неизбежно — то у тебя большие проблемы"
да... да, в конечных продуктах, а вот если они появляются в компонентных - это уже руки крюки.. суть в том, что компоненты обычно не такие уж и большие и все указатели там нормально можно отследить, если их нормально (boost::shared_ptr, boost::weak_ptr) юзать... в большом проекте с кучей ламеров это конечно на порядок сложнее
тут я попытался объяснить, что идиома RAII (shared_ptr, auto_ptr и так далее) позволяет для небольших проектов избежать вообще проблем с указателями... для больших неудается, так как чем больше проект тем больше людей которые только думают, что знают цепп... а в очень больших проектах - такие ошибки просто есть... но они уже лежат на другом логическом уровне, чем просто неверная работа с указателями
ну и так далее...
если вам все еще было непонятно о чем речь = не понятны отдельные тезисы или их связь с вашим комментом, то можно было задать вопрос
(no subject)
14/2/09 10:51 (UTC)Дважды говорите нонсенсы.
Первый - когда говорите, что задали вопрос. Вы об этом только подумали. Телепаты в отпуске, помните?
Второй - что из замечания "сделайте это культурно" следует, что мне непонятна техническая сторона вопроса. Правильным выводом было бы - понять, что в таком тоне я разговаривать не буду.
Человек, знающий хоть что-то о культуре дискуссии, допустил бы как гипотезу, что собеседник может понимать что-то, чего не понимаешь сам. Для этого надо, правда, умерить своё эго. Сложная задача, но большинство с ней справляется.
Теперь прошу вас сделать одну из двух вещей: перечитать свои слова и извиниться, после чего мы можем перейти к обсуждению технической части. Можно в четверг за пивом, если вы ещё в Днепре и не стесняетесь показать лицо.
Или таки-прекратить сюда писать.
(no subject)
14/2/09 11:05 (UTC)(no subject)
14/2/09 11:08 (UTC)Прощайте.