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

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

PE>>>>>Теоретически это возможно. Но Микрософт страется по максимуму оставить совместимость операционных систем.
PE>>>>>До сих пор выполняются 16битные аппликации, аппликации для OS/2 1.1 и тд. Море примеров.
R_M>>>>Есть и обратные примеры. Когда M$ хотел, чтобы народ начал писать под Win32 они добавляли функции в Win16, но об этом не слишком распространялись. Если M$ захочет толкать что-то другое вместо COM, то, наверняка, будут всячески неспособствовать использованию COM в новых проектах.
PE>>>А ты будешь значит по другому делать ? Вот мой новый продукт, но не смейте его использовать. Используйте только старые продукты. Так чтоль ?
R_M>>Что, про что, совсем не понятно.
PE>Ты перечитай выделенное жирным.

Перечитал, но так и не понял откуда следует "Вот мой новый продукт, но не смейте его использовать". Обычно, когда появляется продукция никто не говорит, что старая умерла, пока та еще в ходу (используется). Если вышел новый Windows, то это не значит, что старый умер. Хотя в случае M$ часто имеет место "драматизирование" необходимости переходы на новые технологии и новые версии.

PE>>>А то, что функции добавляются в Win16 — это проще простого.
PE>>>Представь. Тебе нужно зафиксить баг. Нужно вызвать функцию оконную. Ее можно сэмулировать. Но можно и добавить в модуль User, мало ли понадобится потом ?
PE>>>Только зачем ее документировать ?
R_M>>Функции (и не только) были включены в заголовочнык файлы в составе SDK, но в хэлпе их вроде не было, или же где отдельно находились. Это совсем не тоже самое, что и другие недокументированные функции, которых н было хэдерах и либах.
PE>Недокументированная функция — функция, к которой нет документации.
PE>Не опубликованные — которые есть в длл, но нет в SDK.
PE>Микрософт постоянно опубликовывает новые SDK.

Функции были включены в SDK, в документацию толи не включили, толи включили не туда. Суть в том, что, теоретически, это были общедоступные функции в отличии от таких функций как, например, Death(). То, что не "опубликовано", обычно вполне доступно через GetProcAddress().

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

Для лучшей совместимости нужно внимательно читать секции "Remarks" и проверять "Requirements", иначе совместимости не будет. Одних только Win32 API функций типа GetThreadTimes() хватит для успешной организации несовместимости, не говоря уж о разном реагировании на параметры (нередко бывает с использованием NULL вместо указателя) функций в разных версиях Windows, что присутствует во многих функциях.

PE>Есть скрытое АПИ — это совсем не то, что одна функция. За это Микрософт получила по рукам.
PE>А новые функции в Win16 — это издержки суппорта и бинарного распространения.

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

PE>>>>>COM была передовой технологией еще недавно. На ней строили новые технологии и решали основные задачи.
PE>>>>>Сам дотнет под виндой одной ногой в COM стоит.
PE>>>>>Чтобы отказаться от COM нужно переписать все, что на сей момент написано.
R_M>>>>То что, написано работать будет, но писать что-то новое может стать проблематично или неудобно.
PE>>>Я же говорю — для нативных аппликаций учше не придумаешь.
PE>>>Подсисмтему COM никто не соирается выдирать. Естественно ты не сможешь юзать дотнет из COM и тд.
PE>>>Не надо из этого паники делать.
PE>>>Так деают все. Асолютно все. В жаве, например, с переходом на новую версию появляется список deprecated методов.
R_M>>Вот как раз в COM никакие методы из существующих интерфейсов исчезать (или меняться) не должны. И панику из этого делаю не я. Это со стороны M$ исходят всякие настораживающие заявления. Кстати, интересно, будут ли приложения написанные на .net нормально поддерживать автоматизацию, причем со стороны нативных приложений.
PE>Никакие интерфейсы меняться не будут. Как ты это представляешь ? Преписать модули, чтобы выдрать десяток интерфейсов ?

Я не представляю, но вот некоторые, похоже, как-то умудряются. Похоже, что пытаются прикрутить код старых интерфейсов к новым, и, в результате, измениют код старых интерфейсов.

PE>>>Они не вымерли. Появились олее лучшие.
R_M>>Кто появился, скажем так, вместо tasm ?
PE>Напиши драйвер на тасме, прогу оконную, клиент комовский, сервер и тд и ты сам поймешь.

Драйвера (VxD) под Win9x я именно на tasm'е очень часто писал. Написать оконную прогу тоже можно без проблем, только не очень понятно зачем это нужно, я когда-то так делал пару раз, но потом стал просто писать на C без подключения CRT и прочих библиотек. Так что "не очень понятно" получается, хотя безусловно потребностей использовать ассемблер стало значительно меньше.

PE>TASM рулил в DOS неплохо.

В DOS у меня рулил WASM, потому что на ассемблере, как и сейчас, традиционно писал только отдельные модули для C++ програм. Разница только в том, что сейчас их писать приходится реже. TASM, кстати, для 32-битных програм не очень хорош.