Microsoft поможет разработчикам Mono/Moonlight

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

Ты вообще понимаешь, что такое COM? Или тебе пингвины все мозги съели? Какого хрена ты сравниваешь COM (систему межпрограммного взаимодействия объектов) и архивы?

Примеры элементарного использования COM: Windows сама по себе построена на COM. Пощупай реестр. Сколько там COM обьектов? Человеку нужно в программе, пишущейся в системе, поддерживающей COM (VBA, VB6, VB.Net, VC++, VBScript, Delphi,1C...) использовать другой объект, написанный сторонним разработчиком.

Когда я пишу приложение для MSO, AutoCAD, CorelDRAW,... - я использую COM.

Переводчик Лингво предоставляет COM - интерфейс. А еще есть драйверы для торгового оборудования (Атол). Они тоже предоставляют COM-интерфейс. Чтобы с ТО можно было работать из VBA, 1C, VB6, VBScript, Delphi,...

COM непопулярна среди простых разработчиков лишь только потому, что она требует нехилых знаний Visual C++. .Net- решение этой проблемы. Опять же межязыковое.

Все профессиональные приложения для Win32 используют COM. А теперь вопрос: есть ли такое под Линукс?

А пингвины вообще в школу ходили? COM - говно, ссылки, а смысла технологии - не понимаем. С архивами сравниваем.

>Эта херня началась когда инсталляторы разных программ срали в 'C:\Windows\' и 'C:\Windows\System' устанавливая туда разные несовместимые DLL библиотеки.

Это все твои познания COM? А Windows причем тут? Это разработчиков программ винить надо. А кстати по поводу куда совать - это очень долгий спор.

>В конце концов MS спохватились и ввела такую систему что dll библиотеки ставятся в отдельные директории, регистрируются в реестре и впоследствии запрашиваются по guid, при этом доступ к функциям осуществляется посредством массивов указателей на функции.

ГУИД - был всегда основой COM. MS в чем спохватилась? Если ты имеешь в виду "Не срать лишнего в C:\Windows\System", то МС тут не причем.

COM не идеален. У него есть альтернатива (но не замена - заменить COM нечем). Он работает. Его используют повсюду.

> Все профессиональные приложения для Win32 используют COM. А теперь вопрос: есть ли такое под Линукс?

А которые не используют, те любительские, что ли? :)

Была когда-то в моде CORBA, на неё давно все разумные люди забили, даже GNOME. :) Да и M$ давным-давно официально забила на свой COM, так что и ты забудь.

>А которые не используют, те любительские, что ли? :) Про это я не говорил. У вас с логикой что-то не то. >Да и M$ давным-давно официально забила на свой COM

Ты будешь оцень удивлен, но МСО и Windows 98/ME/2000/XP/Vista построены на COM/COM+. И активно ее используют. МС на COM не забивала и не забьет. 90% коммерческого софта использует COM.

До ОС на базе .Net (Singularity) еще далеко. http://www.habrahabr.ru/blog/os/12859.html

"ОС Виндовс .... стала еще более надежней, чем раньше. Новые возможности, которых ранее не было и т.д."

Знаем, читали при установке 98, 2000, ХР, 2003, Vista и, думаю, будем читать дальше.

Служба маркетинга в МS работает отлично. Продажи, проценты от продаж, перспективы роста и все такое.

Вообще-то, создавать отличную ОС Майкрософту не очень выгодно. В противном случае, кто будет покупать еще более навороченную и еще более отличную систему?

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

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

>Ты вообще понимаешь, что такое COM? Или тебе пингвины все мозги съели? Какого хрена ты сравниваешь COM (систему межпрограммного взаимодействия объектов) и архивы?

В Unix программы вообще традиционно всегда взаимодействовали намного плотнее. И C API для этого всегда хватало выше крыши. Зависимостями между С/C++ библиотеками занимается пакетный менеджер.

[рекламные слоганы Microsoft поскипаны.]

> Когда я пишу приложение для MSO, AutoCAD, CorelDRAW,... - я использую COM.

Вот ты скорее всего не пишешь, а я пишу. Еще пишу на Java и на С++ под Салярез и Линух. Знаю ее поведение в практике, знаю альтернативы и поэтому не люблю. Я эту технологию осилил в отличие от тебя. Ты в лучшем случае являешься студентам старших курсов/недавним выпускником универа, в худшем - быломенеджер, для которого каждая цацка от MS на UML диаграмме это очередной быдлооткат.

>Все профессиональные приложения для Win32 используют COM. А теперь вопрос: есть ли такое под Линукс?

А как теперь эти профессиональные приложения на 64 бита спортировать? Зная типичный железобетонный комовский код, я думаю это мучительно тяжело будет сделать.

>А пингвины вообще в школу ходили? COM - говно, ссылки, а смысла технологии - не понимаем. С архивами сравниваем.

Это вы высасываете смысл из пальца. Я помню писание кипятком о С++ в середине 90-х, о Джаве и COM/DCOM/COM+ в конце 90-х, теперь о .NET. Каждый раз - революция вселенского масштаба, которая избавит от всех проблем раз и навсегда.

>Еще пишу на Java и на С++ под Салярез и Линух Приложения для MSOffice, AutoCAD и проч. Приведи мне пример объектно-ориентированной технологии взаимодействия с существующим кодом под твой Солярис. Причем из любого языка. Я привожу тебе конкретный пример: у меня есть COM-объект, им можно пользоваться из C++, Visual Basic, Delphi, VBScript, JScript и проч. Есть ли такое под Линукс. В Линукс интеграция только на уровне С-фунцкий. Это архаично. Для 80-годов это было нормально, а сейчас нужно что-то высокоуровневое. В 98-м году я разрабатывал программу на ВБ6, работающую с АutoCAD и ADO посредством СОМ. Скажи, можно ли было делать что-то подобное в Линуксе тогда, сейчас. Приведи мне список технологий, которые можно использовать в Линукс. Я добиваюсь этого уже целый день. Может их просто нет, потому что Линукс не рассматривается серьезным бизнесом как ОС. А между прочим спецификация СОМ кроссплатформенна. МС ее реализовала.

ПС. Только не предлагайте мне напрямую использовать технологию RPC. Это не смешно.

>Зависимостями между С/C++ библиотеками занимается пакетный менеджер

Можно ли использовать объекты из этих библиотек в PHP, Perl, Python, Gambas, FreePascal, Java, Ruby, многочисленных Shell-ax (скриптовые языки под Windows поддерживают СОМ). А создавать библиотеку можно только на С++ или для этого подходят PHP, Python, Ruby, FreePascal, Java, Gambas и многочисленные Shell-ы (в Windows СОМ-объект можно написать даже на VBScript (WSC)).

> Приведи мне пример объектно-ориентированной технологии взаимодействия с существующим кодом под твой Солярис.

Меня всякий синтаксический сахар не интересует. Могу так: ll_add_node(h_list, new_node). Могу так: list.addNode(newNode). Я вообще не вижу принципиальной разницы между т.н. процедурными языками и ООП. ООП - это скорее всего бренд такой для впаривания. Скотт Мейерс довольно убедительно доказывал что в С++ нужно придерживаться процедурного стиля a-la STL, и делать иерархии классов только тогда когда действительно нужно полиморфное поведение. При этом интерфейс из виртуальных функций должен быть минимальным но достаточным. Позже в таком же ключе высказались Г. Саттер и А. Александреску в "Стандартах кодирования С++". Правило "не городите сложных иерархий, делайте обобщенные статические функции - утилиты" во многом применимо и к Java. COM придерживается диаметрально противоположного принципа.

А вот мэйтенанс, управление зависимостями, предсказуемость поведения используемого стороннего кода меня вот как раз интересует очень сильно. И unix системы всегда в этом плане обгоняли решения ms. Откуда пошел тот же cvs, *.deb и *.rpm пакеты? Microsoft в конце концов пришел к версионной архитектуре "сборок" и автоматическому управлению ресурсами в .NET . Это конечно замечательно, но мы обсуждаем COM. А ком во всех трех аспектах это кошмар.

>В Линукс интеграция только на уровне С-фунцкий.

Рядом с любой серьезной библиотекой идут биндинги для python, ruby и пр.

>В 98-м году я разрабатывал программу на ВБ6, работающую с АutoCAD и ADO посредством СОМ. Скажи, можно ли было делать что-то подобное в Линуксе тогда, сейчас. Приведи мне список технологий, которые можно использовать в Линукс.

В плане приделать с помошью скриптинга к CAD системе какую-то соплю проблем думаю нет.

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

Я варюсь с каком-то unix соку где каждая тайская девочка в Скайпе знает как выстроить vpn туннелинг в их офис сотовой телефонии и настроить environment посредством bash комманд, вы очевидно в win, так что все наши наблюдения относительно "серьезного бизнеса" будут субъективны.

>В плане приделать с помошью скриптинга к CAD системе какую-то соплю проблем думаю нет.

Значит, нельзя. Приведите мне пример CAD-системы под Линукс и расскажите как там автоматизировать.

>Рядом с любой серьезной библиотекой идут биндинги для python, ruby и пр.

Это что ж получается, что для каждого языка нужно писать свой Binding? Очень продуктивно. И Binding - это не СОМ. СОМ-объект можно использовать из любого языка с поддержкой СОМ. А это все языки для Win32, которые не являются быдло-портированием всяких OpenSource пидонов, GCC, перловок и прочей геронтофилии.

Касательно STL. Такого уродства я еще не видел. От всех этих быдло-шаблонных функций отказались в Ява и .НЕТ. Все внешние и внутренние итераторы только пудрить мозги разработчикам, если они, конечно, не dynamic-cast-быдлокодеры, которые называют себя ценителями языка C++, a на самом деле извращенцы-садомазохисты, программирующие ради С++, а не ради задачи. Мне попадались многие быдлокодеры, которые ничего кроме Страуса не читали (ну разве, что книжку по пидону). Я их всех из своей фирмы, руководителем которой я являюсь, посылал на три буквы.

>>В плане приделать с помошью скриптинга к CAD системе какую-то соплю проблем думаю нет.

>Значит, нельзя. Приведите мне пример CAD-системы под Линукс и расскажите как там автоматизировать.

Портируйте мне winNT4/2000 на 64 бита безо всякого быдлоговнища из ХР и Виста типа trusted computing, drm и активации которая слетает когда я ковыряюсь дебагером в ядре. И больше не развивайте - только драйвера пишите. И быдлоком уберите чтобы реестр не засирать. Для компонентных систем можно чего и получше придумать. И перестаньте новые версии оффиса выпускать, чтобы их могли нормально отреверсить и выдемпинговать МС нах@й c рынка.

>Это что ж получается, что для каждого языка нужно писать свой Binding? Очень продуктивно. И Binding - это не СОМ. СОМ-объект можно использовать из любого языка с поддержкой СОМ.

Содание поноценной ole automation компоненты enterprise уровня по моей прикидке в ~10 раз более трудозатратно чем написание надежной plain С библиотеки. А биндинги пишут в мире UNIX другие люди - те которые вынуждены пользоваться этой библиотекой из своего скриптового языка.

> Касательно STL. Такого уродства я еще не видел. От всех этих быдло-шаблонных функций отказались в Ява и .НЕТ.

Ну, в СОМ коде все так засрано быдломакросами что быдлошаблоны может даже лучше.

>Содание поноценной ole automation компоненты enterprise уровня по моей прикидке в ~10 раз более трудозатратно чем написание надежной plain С библиотеки.

Конечно сраную функцию экпортировать легко. Это и в Win32 элементартно делается (DLL). А вы сможете потом на этой "виртуальной" С-библиотеке уехать при автоматизации офисного приложения (MSO), AutoCAD, CorelDRAW,...

>Могу так: ll_add_node(h_list, new_node). Могу так: list.addNode(newNode). Попробуй переписать все приложения таким макаром с ОО-стиля на процедурный. MFC, QT, WinForms, VCL, ADO, ADO.Net, огромное кол-во COM-объектов (MSO, ) и т.д. А ты знаешь, что разработчикам ОО пришлось самим разрабатывать UNO, т.к. никаких COM в Линукс нет. К сожалению обьектная модель ОО получилась намного хуже МСО. Почитай на форумах.

>Я вообще не вижу принципиальной разницы между т.н. процедурными языками и ООП. В 1-й класс! Вообще программирование не учил, а уже в Линух лезет.

В очередной раз убеждаюсь, что лоботомия ЛОРовцам не грозит ввиду отсутствия объекта для операции.

>Ну, в СОМ коде все так засрано быдломакросами что быдлошаблоны может даже лучше

А шаблоны в с++ это в сущности те же макросы. А ты попробуй на VB6, VBScript.

>А вы сможете потом на этой "виртуальной" С-библиотеке уехать при автоматизации офисного приложения (MSO), AutoCAD, CorelDRAW,...

В рот я 2.71@ал MSO. АффтаКад afaik автоматизировался и в ДОС времена при помощи встроенного Лиспа. Касательно corelDRAW и прочей издательсокой хренотени - мне как человеку немного знающему полиграфию больше бы понравилось если бы графическое ядро ОС было основано на PostScript. NeXTStep была именно такой ОС.

>>Я вообще не вижу принципиальной разницы между т.н. процедурными языками и ООП. >В 1-й класс! Вообще программирование не учил, а уже в Линух лезет. В очередной раз убеждаюсь, что лоботомия ЛОРовцам не грозит ввиду отсутствия объекта для операции.

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

>>Ну, в СОМ коде все так засрано быдломакросами что быдлошаблоны может даже лучше

>А шаблоны в с++ это в сущности те же макросы. А ты попробуй на VB6, VBScript.

Нет, быдломакросы находятся вообще вне рамок С++. Это какая-то херня которая обрабатывает исходный текст файла теред тем как за нее берется компилятор. Ей все контексты, зависимости, scopes по барабану. По бенчмарку "Аутизм аффтараъ" ATL/MFC бьет C++ standard library в разы. Красноглазые гондоны - фанаты Страуса может быть даже более вменяемы чем архитекторы ком.

Пидон намного лучше быдлобейсика, и OLE Automation виндовый портинг умел вызывать всегда. В swing в отличие от vb6 есть pluggable look and feel c 97 года.

btw, Я пересмотрел ветку и не понял кого я послала в быдлореактор относительно ООП. Был ли там один анонимус или было их там два, (послеледний вменяемый) не понятно.

Только не надо писдеть, что эта быдло-уродская малафня Пидон лучше Бейсика. Эта быдло-пародия на язык, созданная быдло-студентом - кастрат по природе. Охуенные тормоза, отсутствие вменяемой среды разработки (только не предлагать какой-то быдло-плагинчегг для онанистической хуйни Eclispe). Для не имеющих ни малейшего представление об ООП, предлагаем открыть букварь http://en.wikipedia.org/wiki/Object-oriented_programming и убить себя об стенку.

А красноглазики-строусофилы пусть идут делать миньет своему папочке. Этих быдло-ублюдков я однажды послал на хуй после очередного ихенного пиздежа о константных указателях на константы и множественном наследовании. Эти бляди только пиздели и ничего реального не сделали.

>Только не надо писдеть, что эта быдло-уродская малафня Пидон лучше Бейсика.

Да ну нах? Написание любого более-менее серьезного приложения на этом отстое (vb6) упирается в необходимость ручного импорта половины kernel32.dll и user32.dll. А теперь это все надо переписывать к е@ням - у ms новая революционная технология .NET .

> Эта быдло-пародия на язык, созданная быдло-студентом - кастрат по природе.

Зато в нем есть разная непрактическая фигня типа лямбды чтобы е@ать быдломенеджеров.

> Отсутствие вменяемой среды разработки (только не предлагать какой-то быдло-плагинчегг для онанистической хуйни Eclispe).

А msvs - значит крутая система? То работающие то неработающие Watch и Брейкпоинты, долбаный ncb, который протухает максимум через две недели серьезной работы над проектом, после удаления ncb перестают работать комплишены и как их починить непонятно. Но даже работающие комплишены работают через жопу. При наличии IsWindow() в пяти строчках выше этот урод тебе предложит чего-то типа IsWOW64.

> Для не имеющих ни малейшего представление об ООП, предлагаем открыть букварь http://en.wikipedia.org/wiki/Object-oriented_programming и убить себя об стенку.

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

>А красноглазики-строусофилы пусть идут делать миньет своему папочке. Этих быдло-ублюдков я однажды послал на хуй после очередного ихенного пиздежа о константных указателях на константы и множественном наследовании. Эти бляди только пиздели и ничего реального не сделали.

Ну в ATL применяется по2.71ень с множественным наследованием от шаблонов для того чтобы имплементировать несколько быдлоком интерфейсов в одном классе. Значит главный рассадник 3.14здящих блядей все-таки в Микрософте находится.

>> В Линухе сохраняется принцип KISS (Keep it simple, sucker), там просто использутся архивы с метаинформацией.

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

... а время COM действительно на исходе, и куча его недостатков давно понятна разработчикам из МС, и Рихтер прямо говорит что .Net разработана в т.ч. чтобы устранить эти недостатки, и один только факт наличия по дефолту в висте .Net Framework 3.0 говорит о многом...

>>> В Линухе сохраняется принцип KISS (Keep it simple, sucker), там просто использутся архивы с метаинформацией.

>в управляемых модулях для .Net тоже все внешние зависимости от других модулей (сборок) описаны в метаданных.

Я и пишу : В конце концов MC пришла к версионной архитектуре т.н "сборок".

Но это означает что та идея которую раскручивают другие анонимусы - "все в Линуксе украдено с Windows" это 3.1416здеж: пакетные менеджеры к примеру были разработаны и хорошо обкатаны в рамках бранчей RedHat и Debian.

>>>> В Линухе сохраняется принцип KISS (Keep it simple, sucker), там просто использутся архивы с метаинформацией.

>>в управляемых модулях для .Net тоже все внешние зависимости от других модулей (сборок) описаны в метаданных.

> Я и пишу : В конце концов MC пришла к версионной архитектуре т.н "сборок".

Кстати, от засирания системы сборки не спасают, так как операция удаления ненужных не предусмотрена. На смену DLL Hell пришёл DLL Overflow :)

> Но это означает что та идея которую раскручивают другие анонимусы - "все в Линуксе украдено с Windows" это 3.1416здеж: пакетные менеджеры к примеру были разработаны и хорошо обкатаны в рамках бранчей RedHat и Debian.

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

>>в управляемых модулях для .Net тоже все внешние зависимости от других модулей (сборок) описаны в метаданных.

> Я и пишу : В конце концов MC пришла к версионной архитектуре т.н "сборок".

>Кстати, от засирания системы сборки не спасают, так как операция удаления ненужных не предусмотрена. На смену DLL Hell пришёл DLL Overflow :)

Ну, придумают какой-нибудь быдлотвикер и будут продавать за 100$

>> Но это означает что та идея которую раскручивают другие анонимусы - "все в Линуксе украдено с Windows" это 3.1416здеж: пакетные менеджеры к примеру были разработаны и хорошо обкатаны в рамках бранчей RedHat и Debian.

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

Последние резизы Windows особенно враждебны для "позитивного" крыла хакеров (студентов универов с левоанархистскими взглядами как правило), которые просто хотят харкорно настроить свой аггрегат. Теперь и драйвера могут походу писать только специальные люди со специальной лицензией, а ведь написание VxD драйвера для W95 было под силу студенту старших курсов. Моя интуиция мне подсказывает что в перспективе побеждает та система, в которой больше хакеров.

> Теперь и драйвера могут походу писать только специальные люди со специальной лицензией, а ведь написание VxD драйвера для W95 было под силу студенту старших курсов. Моя интуиция мне подсказывает что в перспективе побеждает та система, в которой больше хакеров.

А много ли осталось людей, воспитанных на GC(не путать с gcc), Visual * .NET и ООП, которые способны написать драйвера? Мозги старшекурсников уже отравлены сборщиками мусора.

Стоит учитывать то, что (виндовые) драйвера, написанные самоучкой, работают несколько криво. Опенсурс спасает тем, что можно как посмотреть пример правильного кода, так и получить фидбэк с указанием, где что надо поправить.

А самоучки в проприетарщине - зло. Достаточно вспомнить невыгружаемый Spider Guard от DrWeb.

Доступность низкоуровнего программирования зачастую способствует разгулу вирусописания. Раньше и девятиклассник(не каждый, конечно), мог написать свой злобный саморазмножающийся вирь. Теперь не могут, из-за возросших возможностей самообороны винды(я других платформ для вирусов не знаю :) ). Так что подавляющее число вирусов стало менее опасными червями, ведь гораздо хуже потерять все данные из-за низкоуровнего форматирования винта, чем из-за загадившего весь диск своими копиями "червя".

>> Теперь и драйвера могут походу писать только специальные люди со специальной лицензией, а ведь написание VxD драйвера для W95 было под силу студенту старших курсов. Моя интуиция мне подсказывает что в перспективе побеждает та система, в которой больше хакеров.

> А много ли осталось людей, воспитанных на GC(не путать с gcc), Visual * .NET и ООП, которые способны написать драйвера? Мозги старшекурсников уже отравлены сборщиками мусора.

У вас неверное представление об ООП. То что есть в Delphi называется RAD. Об ООП надо попучать представление по книге Эриха Гаммы & GOF. По поводу уборщиков мусора вам бы лучше объяснил Луговский. Разработчикам сторонних компонент доверять нельзя. Это как правило "более дешевый вариант", который правильно память не может освободить в принципе. Никак.

> Стоит учитывать то, что (виндовые) драйвера, написанные самоучкой, работают несколько криво. Опенсурс спасает тем, что можно как посмотреть пример правильного кода, так и получить фидбэк с указанием, где что надо поправить.

Мы в институте писали VxD драйвер для одной нашей специализированной железяки по книжке Диалог-МИФИ. Сейчас будь я студентом я бы не взялся писать драйвер под Висту. Вообще, я вижу причину смерти Советского IT в административно - командном давлении на академическую среду, которая давала доступ к компьютерам специальным людям и требовала отчеты по использованию маш. времени. В это время в США всякие гики делали inodes чтобы записывать на диск сохраненки в своей любимой компьютерной игре. Сейчас Микрософт пытается внести в Виндовс быдломенеджерскую административно - коммандную культуру. Возможно, с аналогичным результатом. Правда, MS покрепче будет.

> А самоучки в проприетарщине - зло. Достаточно вспомнить невыгружаемый Spider Guard от DrWeb.

Без бекграунда не возьмут системным программистом. А откуда берется этот бекграунд?

> Доступность низкоуровнего программирования зачастую способствует разгулу вирусописания. Раньше и девятиклассник(не каждый, конечно), мог написать свой злобный саморазмножающийся вирь.

Да ну, я на NT4 нормально жил несколько лет без глюков и вирусов. Хотя всякой быдлоактивации, WGA и DRM там не было.

>> А много ли осталось людей, воспитанных на GC(не путать с gcc), Visual * .NET и ООП, которые способны написать драйвера? Мозги старшекурсников уже отравлены сборщиками мусора.

> У вас неверное представление об ООП. То что есть в Delphi <skipped />

Monseur, а я говорил про Delphi? Соответственно, всё, следовавшее далее скипаю.

Для написания драйверов ооп не нужно и даже вредно тем, что затуманивает низкоуровневый код.

>> Доступность низкоуровнего программирования зачастую способствует разгулу вирусописания. Раньше и девятиклассник(не каждый, конечно), мог написать свой злобный саморазмножающийся вирь.

> Да ну, я на NT4 нормально жил несколько лет без глюков и вирусов. Хотя всякой быдлоактивации, WGA и DRM там не было.

Кстати, наряду с NT существовали ещё очень распространённые версии оффтопика для домохозяек(95,98,меее), в которых "технология NT", как это называют микрософтовцы, не применялась.

>> А много ли осталось людей, воспитанных на GC(не путать с gcc), Visual * .NET и ООП, которые способны написать драйвера? Мозги старшекурсников уже отравлены сборщиками мусора.

> У вас неверное представление об ООП. То что есть в Delphi <skipped />

> Для написания драйверов ооп не нужно и даже вредно тем, что затуманивает низкоуровневый код.

Интерфейс на С пишут внутрь *.h файлов, а реализацию - внутрь *.c файлов. Вполне себе инкапсюляция. Можно элементарно реализовать еще и полиморфизм с помошью стандарта кодирования / API - под оффтопегом это Driver Chain. Прицепил драйвер шифрования на вход драйвера диска - типа унаследовал.

>> Да ну, я на NT4 нормально жил несколько лет без глюков и вирусов. Хотя всякой быдлоактивации, WGA и DRM там не было.

>Кстати, наряду с NT существовали ещё очень распространённые версии оффтопика для домохозяек(95,98,меее), в которых "технология NT", как это называют микрософтовцы, не применялась.

И теперь честных пользователей NT надо за них наказывать? Хотя мне с MS все равно было не по пути.

> Интерфейс на С пишут внутрь *.h файлов, а реализацию - внутрь *.c файлов. Вполне себе инкапсюляция.

Это модульность, а не ООП. Если не верите, вот вопрос "на засыпку": как инстанциировать несколько объектов одного и того же модуля? С классами это тривиальная операция.

> Можно элементарно реализовать еще и полиморфизм с помошью стандарта кодирования / API - под оффтопегом это Driver Chain. Прицепил драйвер шифрования на вход драйвера диска - типа унаследовал.

Можно ещё до Парижа через Владивосток добираться.

>> Кстати, наряду с NT существовали ещё очень распространённые версии оффтопика для домохозяек(95,98,меее), в которых "технология NT", как это называют микрософтовцы, не применялась.

> И теперь честных пользователей NT надо за них наказывать? Хотя мне с MS все равно было не по пути.

Не уследил за мыслью: кто чем их наказывает?

>> Интерфейс на С пишут внутрь *.h файлов, а реализацию - внутрь *.c файлов. Вполне себе инкапсюляция.

>Это модульность, а не ООП. Если не верите, вот вопрос "на засыпку": как инстанциировать несколько объектов одного и того же модуля? С классами это тривиальная операция.

object* obj1 = object_create(); object* obj2 = object_create(); object* obj3 = object_create(); object_method(obl1, "some parameter"); object_method(obl2, "some parameter"); object_method(obl3, "some parameter");

>>> Кстати, наряду с NT существовали ещё очень распространённые версии оффтопика для домохозяек(95,98,меее), в которых "технология NT", как это называют микрософтовцы, не применялась.

>> И теперь честных пользователей NT надо за них наказывать? Хотя мне с MS все равно было не по пути.

>Не уследил за мыслью: кто чем их наказывает?

А я не уследил за мыслью относительно факта наличия всяких быдлорелизов типа 95, 98 и ME. Были такие релизы. Кто-то даже пытался на них работать. Ну и что?

>>> Интерфейс на С пишут внутрь *.h файлов, а реализацию - внутрь *.c файлов. Вполне себе инкапсюляция.

>>Это модульность, а не ООП. Если не верите, вот вопрос "на засыпку": как инстанциировать несколько объектов одного и того же модуля? С классами это тривиальная операция.

> object* obj1 = object_create(); object* obj2 = object_create(); object* obj3 = object_create(); object_method(obl1, "some parameter"); object_method(obl2, "some parameter"); object_method(obl3, "some parameter");

ужас. боюсь спрашивать про то, как в таком виде будет смотреться множественное наследование :)

>> Не уследил за мыслью: кто чем их наказывает?

> А я не уследил за мыслью относительно факта наличия всяких быдлорелизов типа 95, 98 и ME. Были такие релизы. Кто-то даже пытался на них работать. Ну и что?

А то, что быдлорелизы были просто вирусным заповедником. Ведь выше в дискуссии говорилось, что любой студент мог написать драйвер под win95.

>>>Это модульность, а не ООП.
Если не верите, вот вопрос "на засыпку": как инстанциировать
несколько объектов одного и того же модуля?
С классами это тривиальная операция.

>> object* obj1 = object_create();
object* obj2 = object_create();
object* obj3 = object_create();
object_method(obj1, "some parameter");
object_method(obj2, "some parameter");
object_method(obj3, "some parameter");

>ужас. боюсь спрашивать про то, как в таком виде
будет смотреться множественное наследование :)


object* obj = factory_object_create("cool_object_666");
interface1* if1 = (interface1*) narrow (obj, interface1_proto);
interface2* if2 = (interface1*) narrow (obj, interface2_proto);
interface2* if3 = (interface1*) narrow (obj, interface3_proto);
interface1_method(if1, "param");
interface2_method(if2, "param");
interface3_method(if3, "param");

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

object* obj = factory_object_create("cool_object_666");
interface1* if1 = (interface1*) narrow (obj, interface1_proto);
interface2* if2 = (interface2*) narrow (obj, interface2_proto);
interface3* if3 = (interface3*) narrow (obj, interface3_proto);
if1->method(if1, "param");
if2->method(if2, "param");
if3->method(if3, "param");

Если поменять строчку "cool_object_666" на guid, factory_object_create - на CoCreateInstance, а narrow - на Queryinterface, то получится COM,
труъ ООП фреймворк.

> быдлорелизы были просто вирусным заповедником. Ведь выше в
дискуссии говорилось, что любой студент мог написать драйвер под
win95.

Я хотел под NT, но однокурсник покритиковал мой перфекционизм и отговорил.
Вообще, в такой ситуации нынешний студент возьмет Линух, и тогда
получится то, к чему я клоню - сейчас Линух больше подходит для
студентов.

>COM непопулярна среди простых разработчиков лишь только потому, что она требует нехилых знаний Visual C++. .Net- решение этой проблемы. Опять же межязыковое.

А COM слизано с Java RMI