TheWatcher писал(а):Но приведенные Вами выше примеры c COM и BSTR — это не "межправительственные соглашения", а "условия использования" этих технологий, выдвигаемые их монопольным разработчиком и потребителем — Microsoft Windows. Так что хочешь-не хочешь, а как автор сказал...
Ну какая разница, монополист установил соглашение или огромный консорциум? В данном случае — никакой, речь о том, что все моменты, где порядок обращения с сущностями может быть или такой, или другой, или третий, этот порядок должен быть четко закреплён во избежание путаницы, несовместимости и хаоса.
TheWatcher писал(а):Для взаимодействия ассемблерных процедур вообще не существует понятий STDCALL, CDECL, FASTCALL и прочих соглашений: где и как автор параметры передать захотел (хошь — в регистрах, хошь — в стеке, а хошь — и где-нить в выделенной памяти), там и так их и принял, или не принял, или вообще местами поменял.
Ну... зачем писать здесь эти очевидные вещи? Или есть подозрение, то я «не в курсе», что при написании кода на ассемблере можно не следовать никаким соглашениям, и придумывать свои собственные хоть для каждого отдельного вызова какой-то процедуры? Я сам недавно писал при отладке драйвера принтера про процедуру
cblt, которая единственный аргумент принимает через регистр EDI:
viewtopic.php?f=9&t=56110&p=6790391#cblt_callconv_revealedTheWatcher писал(а):А в Си — да, соглашения есть, и в VB они есть, ибо на Си написан, и в Си транслирует, и пограничные соглашения вроде соблюдает.
Это неправильный взгляд на мир, абсолютно. Соглашения есть не в Си или в VB. Соглашения есть вообще, в отрыве от каких-то языков. Они будут актуальны для любого языка, и для ассемблера в том числе, если код пишут хотя бы два человека (а как правило — две команды), и один другому должен как-то сообщить правила игры, по которым один участок кода будет взаимодействовать с другим.
Да даже если один человек пишет код, и даже если он его пишет на ассемблере, всё равно, если у него там есть вызов, хотя бы один, есть и соглашение о вызове. Оно может быть самодельным, оно может быть одноразовым, но это всё равно соглашение — пусть и с самим собой, что человек сам с собой договорился следовать четко определённым правилам игры, когда будет свою же собственную функцию вызывать, чтобы не получилось путаницы.
TheWatcher писал(а): ибо на Си написан, и в Си транслирует
Первое правда, а второе — абсолютная неправда.
TheWatcher писал(а):Вот оно ровно так и тикает, как в весьма конкретный кодогенератор VC весьма конкретные авторы всё напридумали и заложили, да от постороннего взгпяда обфусцировали и антиотладочных мин понаставили, и погоняли и пофиксили, и на бумажку себе записали, чтоб в ногу себе не стрелять при дальнейшей поддержке, а бумажку ту в сейф аккуратно положили, и Билл тот сейф тщательно запер. Ибо нефиг, потому как цена вопроса — миллиарды.
Глупость какая-то. Да и вы теперь сами себе противоречите.
VB написан на C и C++ (хотя куски написаны на ассемблере — к сведению!), скомпилирован MS-овским компилятором VC. Так. Рантайм, вернее функция rtcGetTimer написана на Си, её код был скомпилирован компилятором VC.
Вопрос: VC следует стандартам? Или же генерируемый им код
в вопросах правил передачи аргументов и возврата значений придерживается засекреченных? Если вы убеждены во втором, то я даже не буду продолжать этот разговор: я не занимаюсь развенчанием теорий заговора.
TheWatcher писал(а):VB — это всего лишь слегка "подфуфыренный" VC. И что?
Откуда ноги растут у этого заблуждения? Ничего подобного нет в реальности.
VB, который мы знаем, зародился в отделе, который занимался разработкой Excel.
В момент своего, так сказать, рождения он назывался
Excel Basic (сокращённо
EB).500-страничную спефикацию этого будущего
EB написал ни кто иной как Джоэль Спольски, о чём он
рассказывает в своём блоге. Как ни странно, продукт под названием Visual Basic 1.0 к тому моменту уже существовал. Но это был по сути тот же досовский QuickBASIC с приделанной возможностью рисовать окошечки с помощью псевдографики:
И вот команда разработки Excel связалась с командой разработки того VB 1.0 с инициативой, что команде Excel нужен «Бейсик для Excel». Об этом пишет Джоэль и рассказывает, что именно ему лично мы должны быть благодарны за то, что в современном VB есть 4 характерных штуки:
- Переменные, которые могут хранить значения любого типа ( = вариант).
- Позднее связывание ( = IDispatch)
- Конструкция For Each, подсмотренная в csh.
- Конструкция With, подсмотренная в Паскале.
Joel писал(а):The Excel team convinced the Basic team that what we really needed was some kind of Visual Basic for Excel. I managed to get four pet features added to Basic. I got them to add Variants, a union data type that could hold any other type, because otherwise you couldn’t store the contents of a spreadsheet cell in a variable without a switch statement. I got them to add late binding, which became known as IDispatch, a.k.a. COM Automation, because the original design for Silver required a deep understanding of type systems that the kinds of people who program macros don’t care about. And I got two pet syntactic features into the language: For Each, stolen from csh, and With, stolen from Pascal.
Тогда этот будущий объектно-ориентированный язык со всеми фишками, присущими современному языку, назывался Excel Basic (EB):
Joel писал(а):Then I sat down to write the Excel Basic spec, a huge document that grew to hundreds of pages. I think it was 500 pages by the time it was done.
Именно оттуда растут ноги у префикса «Eb» в функциях EbLoadRuntime, EbExecuteLine, EbInitHost, EbDoIdle, EbMode и куче других, которые экспортируются MSVBVM60.DLL и VBA6.DLL.
Потом рабочее название «Excel Basic» поменяли на «Visual Basic for Application» («со всеми этими ™ и ®):
Joel писал(а):Oh well. The party has moved elsewhere. Excel Basic became Microsoft Visual Basic for Applications for Microsoft Excel, with so many (TM)’s and (R)’s I don’t know where to put them all.
VBA не был основан на VC, это была совершенно самостоятельная среда со своей виртуальной машиной, со своим псевдокодом, которая не умела производить EXE и компилировать в Native-код.
И потом уже на фоне этого VBA и изначальной идее (известной внутри MS как «Ruby» — идея визуального проектирования интерфейса и его неразрывной связи этого интерфейса с неким кодом) был создан VB, который уже умел делать EXE.
Но опять таки, откуда повод говорить, что VB это доделанный Си? VB это доделанный VBA. А VBA это не доделанный Си.
VB6.EXE слинкован их скомпилированных исходников из папки
ruby.
VBA6.DLL слинкован их скомпилированных исходников из папки
vbadev.
MSVBVM60.DLL слинкован из смеси obj-файлов, полученных компилированием исходников из папок
ruby и
vbadev (я даже могу рассказать, что за что отвечает).
DLL-шки, которые используются Вордом, Экселем, Аксесом для обеспечения работы VBA скомпилированы из всё той же папки
vbadev.
Все эти вещи скомпилированы из одних и тех же исходников, и по сути являются слиянием двух проектов: Ruby + Excel Basic. (Не путать концепцию Ruby Алана Купера с языком Ruby!).
Идёт ещё рядом с VB6 линкер: но линкер не является частью Visual C++. Линкер языконезависим, он слинкует всё, что ему подсунут, на каком бы языке оно ни было написано изначально.
И есть ещё рядом с VB6 некий
C2.EXE, который занимается конвертацией промежуточного кода (IL) в Native-код. Этот компонентик VB6 с самой большой натяжкой может называться «отпрыском Visual C++».
Дело в том, что компилятор MSVC — вещь модульная. Она состоит из фронтенда и бэканда. Фронтенд занимается трансляцией входного кода (в виде текста) в некоторый промужуточный языко-независимый код. А бэкенд занимается трансляцией языко-независимого IL в Native-код.
CL.EXE, который вызывают, чтобы скомпилировать сишный исходник, всего лишь дёргает сначала фронтенд, а затем бэкенд. Причём для каждого языка в этой модульной архитектуре существует свой фронтенд.
Для Си без плюсов используется фронтенд «C1.DLL».
Для Си++ используется фроентенд «C1XX.DLL».
Результат работы обоих фронтендов транслируется в x86-машинный код бэкендом «C2.DLL».
Стыкует между собой фронтенд и бэкенд исполняемый файл «CL.EXE».
- msvc_cl_modules.png (6.25 Кб) Просмотров: 10161
Будь у MS желание, они бы вдобавок к C1.DLL и C1XX.DLL могли бы написать ещё и P1.DLL, L1.DLL и хз1.DLL, и тогда CL мог бы компилировать вдобавок ещё и Паскаль, Лисп и ХЗ что ещё.
Мораль и вывод отсюда: C2.DLL (то есть бэкенд) к Си/Си++ привязан мало. Для языков специфичны фроентенды, а для машинных архитектур — бэкенды. (Кстати, у CL есть недокументированные ключи, которые позволяют подменить фроентенд и бэкенд своей собственной DLL-шкой).
Так вот, что сделали MS в отношении VB: они взяли бэкенд C2.DLL, который, напоминаю, не привязан к языку C/C++, обернули его в самостоятельный исполняемый модуль (C2.EXE) и включили его в состав VB как продукта.
Мало того, что этот x86-бэкенд не специфичен (а абстрагирован) от конкретно языков C/C++, так он ещё и используется VB только тогда, когда проект компилируется в Native-код, а при компиляции в P-код он вообще не использует.
Из всего, что это, это наибольшее, что связывает VB6 с Microsoft Visual C++. И после этого кто-то говорит, что VB это слегка допиленный Visual C++?
Дальнейшие пассажи с перечислением неких авторитетов и упоминанием некий JIT-компиляторов Си и ассемблера я вообще не понял, к чему тут.
