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

V>Я не могу понять, чего ты бегаешь от простых аргументов, прямых вопросов и той самой конструктивной критики, когда не озвучиваешь собственные предложения по критикуемым вещам.
Я как раз не бегаю. "Аргументы" у вас к теме дискуссии не относятся, и построены в стиле ботов из поддержки Микрософта. Это которые мне пересказывают мой же вопрос другими словами.
Я говорю "архитектура UI — отвратительная, использовать её невозможно, приходится полностью реализовывать свой UI вместо расширения коробочного". Вы мне в ответ "да там вообще весь UI можно самому переписать".
А вот вы бегаете от прямых вопросов, в трудных местах отделываясь намёками. Вы уже придумали способ задетектировать версию кастом-компонента, который не представлен дисковым файлом?

S>>Мы говорим не о времени начала дискуссии. А о моменте, когда Installer Team была сформирована и ей была поставлена задача разработать архитектуру Windows Installer.
S>>Я думаю, что это эпохальное событие произошло когда-то в девяностых.
V>Это эпохальное событие произошло одновременно с выпуском MS Office 2000, когда в папке с пререквизитами к нему впервые засветился WI и его надо было самому ручками устанавливать перед установкой офиса.
То есть вы думаете, что они сначала выпустили офис 2000, а потом была разработана архитектура WI? Выделенное болдом перечитайте.

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


V>Конечно есть — это официальный пресс-релиз Ms Office-2000, где впервые упоминается новый инсталлятор.
Вот этот пресс-релиз: https://news.microsoft.com/1999/06/07/microsoft-office-2000-an-essential-tool-for-all-knowledge-workers-is-available-this-week/#sm.0000k2gfry19ipcx7ycv15b09qwvy
Никаких описаний инсталлятора, естественно, нету.
V>Неверующие могут скачать с MSDN-подписки (ну или с торрентов) оригинальный образ дисков этой версии офиса и дополнительно лично убедиться.
Муа-ха-ха. Ждём от вас цитату в студию. На всякий случай напомню, что речь не о том, что офис ставился через Windows Installer — это, конечно же, правда.
А о том, что он проектировался для офиса, и решение его использовать для чего-то ещё было принято потом.

V>Ну вот я так и думал, что полезных предложений не будет.
V>Во-первых, давно существуют дизайнеры диалогов WI, они ничуть не уступает дизайнеру диалогов Dialog Templates.
Да что за бред-то! Я же вам на этот аргумент уже отвечал трижды! Повторю ещё раз: это сейчас существуют дизайнеры диалогов. А мы говорим о решениях, принятых 1997 году, когда изобреталась технология WI.
Не было никаких дизайнеров! Была Visual Studio 6.0.

V>А если ты рассуждал о неких "массовых продуктах", то можно было вообще взять что-нить типа этого:
V>http://www.advancedinstaller.com/download.html
Вы полностью подтверждаете мою точку зрения. Я вам говорю — архитектура говённая. А вы мне перечисляете коммерческие средства по замазыванию проблем этой архитектуры.
Ога, типа "самсунги взрываются" — "а вы его в портативном сейфе носите".

V>Во-вторых, о совместимости говорить нелепо хотя бы потому, что к контролам в WI можно привязывать некие стандартные действия, а в случае Dialog Templates — нельзя.
Это всё равно не оправдывает реляционную базу данных для контролов.
Для сравнения можете изучить архитектуру Delphi — как устроен DFM, как привязываются действия, как описываются контролы, стандартные и нестандартные. Чисто для справки — на момент начала проектирования WI Delphi уже был третьей версии.
V>Ну и набор контролов чуть другой, местами пересекается, местами нет.
Ну так в том-то и дело, что набор контролов WI прошит гвоздями, а в Dialog Template можно указывать любые контролы.

V>В-третьих, сама попытка утверждать, что загвоздка в дизайнере диалогов — это заведомо слить спор. ))
V>Их было более одного сразу же.
"Сразу же" их было ровно 0. Загвоздка — не в дизайнере. Загвоздка — в попытке хранить описание UI в реляционных таблицах. Через это проходят все начинающие разработчики — лично я этим занимался в 1991 году. На клиппере.

V>Сам не видишь разве, что такие рассуждения попахивают тем, что ты "сабклассил" ручками уникально каждый диалог в нейтивных приложениях, т.е. перехватывал события на стороне parent, без reflection? Не, пару раз и я таким макаром упал-отжался, но исключительно для удовлетворения собственного любопытства.
Всё наоборот — reflection отражает евенты на сторону parent, и делается для того, чтобы можно было обойтись без сабклассинга контролов для привязки обработчиков. Вижу, что с темой разработки гуя на чистой нативной винде вы тоже знакомы только по разговорам в курилке.

V>А если по-делу, то некий GUI-контрол пишется один раз и затем многократно используется.
Совершенно верно. И именно это невозможно сделать в WI — нет возможности импортировать сторонний GUI-контрол, разработанный не в рамках этого проекта. Приходится полностью подменять весь UI.

V>Но и этого НЕ надо. Когда тебе кажется, что гуйный визард установщика листает некие "вложенные" страницы внутри одного "объемлющего" окошка верхнего уровня — это подлый обман зрения. Каждый диалог создаётся абсолютно с 0-ля, это новый оконный хендл, т.е. новое независимое окно. Общего у них — только хендл текущей инсталляхи.
Конечно, совершенно верно. Более того, половина, а то две трети инсталляций изображают "листание" вообще выводя отдельный диалог поверх текущего — запуская отдельный екзешник.
Не знаю, с чего вы взяли, что мне что-то кажется. Я прекрасно знаю, как устроены вот эти "страницы".
V>А суть этой простой вещи в том, что возьми, создай свой любой диалог на любой знакомой тебе технологии и дёргай АПИ инсталлера.
Вы произносите слова, смысла которых не понимаете. Ну вот нарисовал я, допустим, "диалог". Для простоты предположим, что это форма на Delphi — то есть там у нас есть бинарное описание структуры, плюс все нужные обработчики скомпилированы. Всё это лежит у меня в .bpl — то есть скомпилированное и готовое к работе. Пусть это будет развесистая форма terms and conditions, которая в конце устраивает устанавливаюшему экзамен на предмет того, правильно ли он прочёл EULA. Её надо показать между стандартным component selection и progress dialog.
Что мне нужно сделать, чтобы "дёргать API инсталлера"?
Там объём работы будет такой, что мне проще вообще всё переписать на PowerShell скрипт, и не трахаться с WI вообще.

V>В наличии есть даже упрощенный вариант COM-библиотеки инсталлера, которую можно юзать из VBScript, основной объект — Session. Вот прямо из этого объекта можно читать некие property, устанавливать их (по результатам работы своих диалогов) и т.д. А эти property потом уже используют последующие custom actions. Т.е. важно отделять действия, которые можно охарактеризовать как install/commit/rollback от действий, которые являются просто "collect some data".

V>Я как-то просто из VB-скрипта рисовал кастомные диалоги через стандартную ActiveX-библиотеку Microsoft Forms 2.0.
Это не имеет отношения к делу.

V>Там одна проблема в том, что твои диалоги должны рисоваться уже неким установленным кодом, т.е. нельзя на них "вытащить самого себя за волосы". ))
Это тоже заблуждение — можно рисовать диалоги безо всякого установленного кода.
V>Ну, дык, уж как минимум один диалог (приветственный) можно сваять на предоставляемой технологии.
То есть её ценность равна примерно 0. А себестоимость — как у авианосца.

V>Фишка в том, повторюсь — а откуда должен исполняться этот твой кастомный код? Где в этот момент будет располагаться та программа, которая исполняет этот код? Причем, "сабклассить" ограничивает нас нейтивом, пральна?
Программа будет располагаться там же, где располагается код custom actions. Вы не замечаете, как противоречите сами себе? То у вас "да пиши любой GUI и исполняй в процессе установки", то "ой, нет, кастомный код в UI взять неоткуда".

V>Именно через написание своих скриптовых утилит я потом перегонял в WiX и обратно понравившиеся куски других пакетов инсталляций, рефакторил и мёржил их, как тырил когда-то на сайтах клиентский скриптинг, тоже рефакторил и допиливал напильником.
А можно было просто открыть пакет оркой.
V>Я ничего не путал. Я говорил о сетевых принципах работы Skype. Ты можешь заходить в конференцию Skype For Business с обычного скайпа. Сюрпрайз? Не знал?
Нет, не можешь. Сетевые принципы у этих двух скайпов совершенно разные. for Business — это SIP/RTP, которые кое-кто в том топике ругал как непригодные для жизни. А обычный скайп использует тот самый proprietary протокол, который кое-кто превозносил до небес.
Даже если к обычному скайпу прикрутить SIP, то это никак ему не поможет — свою архитектуру супернод он не сможет использовать. С вашими претензиями на знание сетевых технологий писать такую чушь должо быть стыдно.

V>Компонент имеет версию...
А вы как думали? Всё имеет версию.

V>Я же говорил тебе — курить, что есть component.
Булшит поскипан.

V>Да, файл может быть частью компонента, но может и не быть. Важно, что у компонента НЕТ версий. Вот нет и всё. Любая твоя "версия" — это чисто прикладная хрень. И если ты способен хоть каким-либо образом закодировать/представить эту "версию" — ну так представь.
V>И почему именно как файл? А что мешает в виде сетевого запроса твоего сертификата?
Архитектура WI. Курить, что есть component.
V>Прикручивать версию к единице транзакции — ну это сильно, ИМХО. ))
Ну, авторы WI это сделали.
V>Компонент же может быть сугубо виртуальный, т.е. не существующий в каком-нить реальном воплощении (по крайней мере в таком воплощении, о котором знает WI), т.к. install, commit и rollback могут быть какими-нить сетевыми запросами или запросами в БД.
Я по прежнему жду каких-то подтверждений этого смелого тезиса. Что нужно написать в табличке Component для того, чтобы install, commit и rollback были "какими-нить сетевыми запросами или запросами в БД.". Хрен с ним с версией — хотя бы пусть детектирование наличия компонента при repair было кастомным кодом, а?

V>Но лучше пользоваться встроенными сущностями инсталлера по-делу, а именно — там, где речь идёт о версиях/апгрейдах и кодах совместимости, использовать сущность Продукт, потому что у него есть ProductCode, в рамках которого уже можно организовать произвольную версионность. Да, иногда удобно, в случае когда один и тот же файл входит в разные продукты, пользоваться понятием версионности этого файла. Но тут сразу твои доводы превращаются в маразм, уж извини — если у нас такой сценарий возможен только для файла, то не стоило пенять на то, что для такого сценария обязательно нужен файл. Тем самым ты показываешь, что ты не программист. Логика того-с. :xz;
В разные продукты может входить не только "файл". Произвольный компонент может входить.

V>Или ты заламывал руки, что вот "а там, ПРЕДСТАВЛЯЕТЕ, несколько ключей продуктов зашито". ))
V>Это, надо понимать, проявление "продуктофобии"? Да какая тебе разница, сколько ключей продукта зашито?
Простая разница — бывает прямая архитектура, которая предлагает прямые решения прямых задач. А бывает — наркоманская архитектура, в которой Hello World пишется за 10 минут, а Hello Vdimas требует 160 часов девелопмента и 80 часов QA.

V>Ты ты сообщил вслух (и очень зря), что SSL-сертификат у тебя "компонент".
V>А с какой радости ты, как разработчик, вдруг решил рассматривать его как "компонент"?
А как что мне его рассматривать, стесняюсь спросить? Есть иерархия — продукт/фича/компонент.

V>"Я гарантирую" что ты подошел к инсталлеру вообще не с той стороны. НЕ понял ни его философии, ни для чего нужны основные сущности инсталлера.
Да я всё прекрасно понял. Философия — претенциозная, основные сущности — выделены криво. Предположения, на которые опирались авторы, — неверны. Реализация — неудобная ни для чего. Что я забыл?

V>В большинстве случаев задачей custom actions не является копирование чего-то куда-то или установкой флагов в реестре и проч — это даже вредно, потому что в таком случае "чистота" транзакционности инсталлера ложится на плечи автора этих действий.
Рекомендую почитать документацию на custom actions из WiX. Ну, чтобы просто иметь представление о том, что является их задачей "в большинстве случаев".

V>В большинстве случаев тебе надо породить и установить значение некоего текстового property для сессии, продукта, фичи и т.д., которое (значение св-ва) невозможно породить встроенными ср-вами инсталлера. Ну вот, строку подключения к какому-нить кастомному приложению или к БД, например.
Да, это ровно один из случаев. Как правило решаемый как раз в Custom UI. Потому что в процессе инсталляции свойство уже есть — а в админской инсталляции все connection strings и server urls уже прошиты, там не надо никакой код исполнять. А речь идёт про custom install actions — внесение изменений в систему, не сводящихся к хардкодным "скопировать файл", "записать значение в реестр", или "зарегистрировать сервис".

V>Для твоей задачи одно кастомное действие должно было сравнить некую "прикладную версию" SSL сертификата (предположим, его expiration date) с неким встроенным в инсталляху св-вом и в кач-ве результата установить еще какое-нить прикладное св-во, типа "NeedToUpgradeSertificate", по которому далее ветвиться в других шагах инсталляции.
А кто будет регистрировать сам сертификат? Кто будет настраивать правила Windows Firewall? Кто будет загружать репорты в SSRS? Кто будет биндинг веб-сайта править? Где вы собрались ветвиться?

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

V>>Конечно есть — это официальный пресс-релиз Ms Office-2000, где впервые упоминается новый инсталлятор.
S>Вот этот пресс-релиз: https://news.microsoft.com/1999/06/07/microsoft-office-2000-an-essential-tool-for-all-knowledge-workers-is-available-this-week/#sm.0000k2gfry19ipcx7ycv15b09qwvy

Нет, не этот.


S>Никаких описаний инсталлятора, естественно, нету.

Кто бы сомневался, что простейшие вещи вызовут у тебя трудности.
Неужели сложно было поискать по ключевым словам?


V>>Неверующие могут скачать с MSDN-подписки (ну или с торрентов) оригинальный образ дисков этой версии офиса и дополнительно лично убедиться.
S>Муа-ха-ха. Ждём от вас цитату в студию. На всякий случай напомню, что речь не о том, что офис ставился через Windows Installer — это, конечно же, правда.

Офис был первой программой и долгое время единственной, которая ставилась через инсталлер.


S>А о том, что он проектировался для офиса, и решение его использовать для чего-то ещё было принято потом.

Ожидаемо простейшие вещи снова вызывают трудности.
Когда появилась первая ДРУГАЯ программа, использующая инсталлер?


V>>Ну вот я так и думал, что полезных предложений не будет.
V>>Во-первых, давно существуют дизайнеры диалогов WI, они ничуть не уступает дизайнеру диалогов Dialog Templates.
S>Да что за бред-то! Я же вам на этот аргумент уже отвечал трижды! Повторю ещё раз: это сейчас существуют дизайнеры диалогов. А мы говорим о решениях, принятых 1997 году, когда изобреталась технология WI.

Нет, мы говорим о том времени, когда эту технологию открыли для разработчиков, предоставив к ней SDK.


S>Не было никаких дизайнеров! Была Visual Studio 6.0.


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


V>>А если ты рассуждал о неких "массовых продуктах", то можно было вообще взять что-нить типа этого:
V>>http://www.advancedinstaller.com/download.html
S>Вы полностью подтверждаете мою точку зрения.

Влажные фантазии. Я цинично высмеиваю твою точку зрения.


S>Я вам говорю — архитектура говённая.

Мнение. К тому же НЕ конструктивное, т.к. от конструктива ты упорно бегаешь.
Человека с техническим складом ума должен больше интересовать список возможностей технологии, а не тонкости её реализации.


S>А вы мне перечисляете коммерческие средства по замазыванию проблем этой архитектуры.

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


S>Ога, типа "самсунги взрываются" — "а вы его в портативном сейфе носите".

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

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


V>>Во-вторых, о совместимости говорить нелепо хотя бы потому, что к контролам в WI можно привязывать некие стандартные действия, а в случае Dialog Templates — нельзя.
S> Это всё равно не оправдывает реляционную базу данных для контролов.

Да ты издеваешься? Вместо ответа на КОНКРЕТНЫЙ аргумент выдаёшь "а у вас негров линчуют!".
Мы можем обсудить тонкости представления диалогов отдельно. Здесь пока речь шла о том, можно некий редактор GUI использовать для другого сценария или нельзя.


S>Для сравнения можете изучить архитектуру Delphi

Хамишь.
Ладно бы твой оппонент утверждал нечто, на что можно возразить отсылом к хелпу по некоей технологии или к аналогичной статье. Ты посылаешь людей в ровно противоположных случаях — когда сам оказываешься в беспомощной ситуации.
Эдакое правило: "первым делом всех посылай, потом разбирайся!".

Кароч, я хорошо в курсе, как оно в Дельфи.
И заодно хорошо в курсе, как оно в виндовых DialogTemplates.
И там и там имеем некое текстовое представление + парсер сверху.
Очевидно, что реляционное представление имеет шанс обойтись вовсе без парсера, а значит, там может быть простейший код по построению такого UI, который (код) можно реализовать даже на коленках на каком-нить скриптовом языке.
Более того, АПИ, работающее с базой, автоматически достаточно и для GUI.
Более того, связь диалогов и стадий инсталляхи (или способов инсталляхи — административная, например) выражается через реляционное отношение самым естественным образом.


V>>Ну и набор контролов чуть другой, местами пересекается, местами нет.
S>Ну так в том-то и дело, что набор контролов WI прошит гвоздями, а в Dialog Template можно указывать любые контролы.

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


V>>В-третьих, сама попытка утверждать, что загвоздка в дизайнере диалогов — это заведомо слить спор. ))
V>>Их было более одного сразу же.
S>"Сразу же" их было ровно 0.

С выходом SDK их появилось сразу несколько. "Сразу" — это примерно 2-3 месяца.
Я и сам простейший визуальный редактор как-то накидал за пару вечеров на дотнете.
Правда, генерил из него XML-WiX, но для генерацию в базу надо было бы еще буквально пару вечеров сверху.

Я НАСТОЯТЕЛЬНО тебе рекомендую хотя бы раз в жизни попробовать накидать такой дизайнер самому, чтобы ты ОСОЗНАЛ всю сложность проблемы, ы-ы-ы. Вернее, увидел отсутствие всяких сложностей.

Порядок работы такой:
— берешь какую-нить библиотеку дизайнера из Сети (я их сразу три штуки нарыл тогда);
— допилил 4 нужных мне на тот момент контрола (кнопку, чек-бок, радиобокс, текстовое поле)
— сделал код сериализации "формы" в XML.
На сегодня это заняло бы у меня один вечер, а не два.

Это как решают проблемы профи из реальной жизни.
Если бы мне было надо что-то совсем серьезное, я бы купил готовый тул, ес-но. (Они стоят обычно 300-500 уе, т.е. порядка двух/трехдневного заработка программиста, т.е. если работы больше, чем на ~3 дня, то надо брать готовый инструмент, а не изобретать свой).


S>Загвоздка — не в дизайнере. Загвоздка — в попытке хранить описание UI в реляционных таблицах.

Э, нет. Загвоздка — это использовать всей индустрией x86-й морально устаревший код. Вот это действительно проблема. А ты о какой-то фигне говоришь.

То, что НЕ создаёт проблем, не является помехой/загвоздкой и прочим.


S>Через это проходят все начинающие разработчики — лично я этим занимался в 1991 году. На клиппере.

Да у тебя на лбу написана "тяга к прекрасному". ))
И я даже одобряю такой перфекционизм, потому что программист и должен быть перфекционистом. Где-то там, глубоко внутри. Особенно на этапе обучения ремеслу. Но после 20-тилетнего стажа даже просто пытаться обсуждать такие вещи — это расписываться в профнепригодности.


V>>Сам не видишь разве, что такие рассуждения попахивают тем, что ты "сабклассил" ручками уникально каждый диалог в нейтивных приложениях, т.е. перехватывал события на стороне parent, без reflection? Не, пару раз и я таким макаром упал-отжался, но исключительно для удовлетворения собственного любопытства.
S>Всё наоборот — reflection отражает евенты на сторону parent

а-а-а-а-а-а-а (еще много раз)
"Я отражаю своё изображение в зеркало!" — примерно так это прозвучало.

(Неожиданно, прямо скажем)

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

Классный залёт. ))


========
Залёт-то — он особенный. Почему? Потому что фиг с ним даже, если ты не писал нейтивные ГУИ прямо на вынь-АПИ по характеру своей работы. Я тоже такие не писал, я писал на MFC/ATL и чуть позже на WTL. Но я, блин, более одного раза делал это (т.е. брал тупо WinAPI) сугубо в самообразовательных целях. Ведь винды были долгое время единственной вменяемой настольной операционкой. Неужели тебе было не любопытно, как оно там устроено и работает?

Кароч, программист здорового человека обязательно обладает развитым любопытством. Иначе он НЕ программист. Потому что даже в MFC, обладая знаниями о принципах работы оконной подсистемы, можно задёшево решать кучу вещей — например, накладывать стиль не на каждый контрол в отдельности, а на весь диалог. К примеру, если мы кешируем какую-нить сложную кисть и применяем её для кучи разных контролов на одной форме, то на слабой технике тех лет это давало неплохой профит в плане эффективности прорисовки. Таких примеров мильоны, ес-но, фиг с ней, с прорисовкой, но все вместе они составляют самый общий принцип — эдакий способ подхода к делу, по которому (по подходу) можно отличить профи от случайного в отрасли человека.

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

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

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

Я-то придумал. Меня удивляет, что ты еще не придумал. Ты столько раз спросил "что писать в keypath", что можно было потратить в 10 раз меньше времени и узнать, что keypath — это имя "ресурса", а "ресурс" — это не только файл.

И что определять версию файла автоматом — это лишь некая дополнительная функциональность, но не основная, потому что полноценно проверить можно лишь версию EXE или DLL-файлов, которые содержат внутри себя ресурс с типом VERSION. Т.е., даже при наличии файла, для бесконечного кол-ва типов файлов проверить его "версию" будет автоматом невозможно. И вот как раз для таких вещей чудесно работают custom actions, которые чаще всего нужны как раз для формирования значений неких св-в, участвующих затем в conditions.

И, с моей колокольни, "знания" подобного рода — это даже не знания, а уровень ноль.
Но ты этот уровень так и не прошел.


S>>>Мы говорим не о времени начала дискуссии. А о моменте, когда Installer Team была сформирована и ей была поставлена задача разработать архитектуру Windows Installer.
S>>>Я думаю, что это эпохальное событие произошло когда-то в девяностых.
V>>Это эпохальное событие произошло одновременно с выпуском MS Office 2000, когда в папке с пререквизитами к нему впервые засветился WI и его надо было самому ручками устанавливать перед установкой офиса.
S>То есть вы думаете, что они сначала выпустили офис 2000, а потом была разработана архитектура WI? Выделенное болдом перечитайте.

Я думаю, что ты несерьёзный и беспринципный.

Потому что нет ничего смертельного в том, что ты никогда до этого спора не знал историю разработки Windows Installer. Ну не знал и не знал, фиг с ним. Это не важно и вовсе не принципиально. Но то, что ты в ответ на НОВУЮ для тебя инфу реагируешь натурально неадекватно — в этом весь ты.

Я всё-равно никогда не пойму людей в подобных ситуациях — вот что тебе помешало САМОСТОЯТЕЛЬНО поинтересоваться, зачем и почему был разработан Windows Installer? Это к вопросу о серьёзности. Т.е., если ты так настойчиво возражаешь, если для тебя это (непонятно с чего) важно — ну, дык, прояви серьезность. Сделай всё по-взрослому.

И почему бы тебе не предположить очевиднейшую весчь, а именно — если оппонент утверждает нечто, то он эту инфу откуда-то взял — ну блог там программиста из MS почитал или книгу непосредственно от непосредственно автора MSI (книгу рекомендую, кста)...

Вместо этого ты предпочитаешь лить гадости на оппонента, будто тот человек виноват в твоём незнании. Это уже из области полнейшей беспринципности.

Ну и возражать тоже надо уметь, например, ЕСЛИ у тебя есть ДРУГАЯ информация, то ей принято делиться. Ты же пока поделился лишь той информацией, что никакой ДРУГОЙ информации на этот счёт у тебя НЕТ. Т.е. ты донимаешь оппонента подколками сугубо развлечения ради. Ну или проявляешь инфантильность, требуя ссылок на блюдечке. Ну молоток, чо!

Но вообще всё вместе — утомительно. Думаю, в реальной разработке обсуждать с тобой технические вопросы банально невозможно. Продвижения ноль.
Упорство ради упорства на фоне бесконечного самолюбования.

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

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

N>>>История и Unix, и Windows — история успеха того, что началось как "склёпанный быстро поток кода", превращённый в платформу, пережил несколько десятилетий.
С>>Винда срисовывалась с VMS.
C>С VAX была срисована NT. Винда к ней отношения не имела, к моменту создания NT уже был Win16 API и DOS.

Тогда следовало бы уточнить, о какой "винде" речь, прежде чем обобщать.