§ 10. Ruby + EB = Visual Basic

Внутренний мир Visual Basic. Раскрываем тайны глубин VB, секреты устройства, недокументированные возможности и сведения.

Модератор: Хакер

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16230
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

§ 10. Ruby + EB = Visual Basic

Сообщение Хакер » 10.06.2019 (Пн) 14:01

До моего серьёзного погружения в исследование внутреннего мира и устройства VB6 я, как наверное и многие, имел в голове примерно такое представление: VB — это основной продукт, в то время как VBA — это побочный продукт, результат урезания основного продукта по функциональности и приделывания к приложениям из состава Office, таким как Excel, Word. Но часто бывает, что представление обывателя о структуре вещей, построенное на основе попыток предугадать эту структуру, может кардинально отличаться от истинной структуры. И в данном случае это как раз наш случай: на поверку всё оказалось совсем наоборот, и не VBA является побочным продуктом от создания VB, а скорее VB является побочным продуктом появления VBA.

Эта статья немного прольёт свет на то, из каких двух больших частей состоит Visual Basic, какая идейная подоплёка и какие люди стоят за появлением каждой из них на свет.

Изображение

Как уже можно было догадаться из вышесказанного, есть два больших компонента. Это Ruby и EB. Пожалуй, наиболее удачное высказывание обо всём этом: Visual Basic является результатом «женитьбы» Ruby и EB — двух технологий, появившихся независимо друг от друга, и очень удачно подходивших друг к другу.

Ruby
Очень важное замечание, которое нужно сделать, прежде чем мы пойдём дальше: здесь и далее слово «Ruby» не имеет ничего общего с языком программирования Ruby и фреймворком Ruby on Rails. В конце концов, слово «ruby» переводится просто как «рубин».

Изображение
(На фотографии: Алан Купер (Alan Couper))
Если вы когда-нибудь искали информацию о том, как появился на свет Visual Basic, то наверняка натыкались в википедии или где-то ещё на подобные слова:
май 1991 — выпущен Visual Basic 1.0 для Microsoft Windows. За основу языка был взят синтаксис QBasic, а новшеством, принесшим затем языку огромную популярность, явился принцип связи языка и графического интерфейса. Этот принцип был разработан Аланом Купером (Alan Cooper) и реализован в прототипе Tripod (также известном как Ruby). Первый Visual Basic был интерпретатором.

Из статьи о самом Алане Купере можно узнать, что он, в частности, известен как «отец Visual Basic». Англоязычная версия статьи немного более информативна.

На самом деле Алан Купер не работал в Microsoft, не состоял в команде по разработке VB — его заслуга в другом. Алан Купер придумал концепцию лёгкого создания визуальных оболочек и совместно с коллегами создал инструмент для построения визуальных оболочек. Напомню, что речь идёт о 80-х годах и времени, когда ОС с графическими интерфейсами только-только набирали популярность, а мейнстримом был DOS и другие ОС с текстовым интерфейсом.

Продукт, который сделала команда Алана Купера, как раз и назывался Ruby, и самое интересное, что это не был инструмент для программистов — это был инструмент для обычных пользователей без специальных навыков, дававший им, по замыслу Купера, возможность быстро слепить визуальную оболочку, которая бы облегчала какую-то работу. Эдакий конструктор визуальных интерфейсов для широкого круга лиц. Ох это время романтиков, считавших, что стоит дать людям компьютер — и каждый научится и станет собственноручно писать программы, чтобы заставить компьютер делать именно то, что нужно владельцу. Ruby не был ни языком программирования, ни интегрированной средой разработки (IDE) в современном понимании.

По рассказу Купера, когда он увидел Windows 1.0, он понял, что у этой платформы огромное будущее. Его приятно поразили две вещи: графический интерфейс и концепция DLL, позволяющая делать динамически конфигурируемые расширяемые системы, но одновременно с этим тогдашняя оболочка Windows (проводника и рабочего стола в современном понимании ещё не существовало) показалась ему просто ужасной. И тогда он решил написать свой идеальный shell для Windows. Общаясь со своими клиентами и пытаясь понять, каким должен быть идеальный shell, Алан Купер понял, что идеальной оболочки не существует. И что нужно дать пользователям инструмент, который позволит каждому из них сконструировать свой shell, заточенный под их потребности и их задачи, а не пытаться протолкнуть им некий идеальный shell, пытаясь при этом объяснить им, в чем его идеальность. Этот конструктор пользовательских оболочек изначально назывался Tripod, но позже был переименовал в Ruby, поскольку название «Tripod» много кем использовалось.

Позже Алан Купер показал свою разработку Биллу Гейтсу. Гейтсу концепция, что пользователь может рисовать визуальные элементы управления, размещать их где угодно на рабочем поле, перетаскивать, менять размеры и, главное, с элементами управления связывать какие-то действия, понравилась настолько, что он решил купить Ruby. Отныне Microsoft стала владелицей Ruby и определяла дальнейшую судьбу продукта.

В Microsoft решили поменять суть Ruby: оставляя концепцию лёгкого построения визуальных интерфейсов («нарисовал кнопку где нужно и быстро привязал к ней какое-то действие»), из инструмента по созданию визуальных оболочек (над уже существующими программами) с целевой аудиторией, состоящей из обычных пользователей, превратить его в инструмент по созданию новых программ с визуальными интерфейсами, целевой аудиторией которого были бы только программисты. Напомню, что исходно за Ruby помимо принципа визуального проектирования не стояло никакого языка программирования (была лишь простая система команд, набор которых был расширяем за счёт подключаемых DLL, так же как и набор элементов управления в палитре (Купер назвал их «gizmo», что в переводе на русский — «штуковина», этот термин сохранился и в VB6), который тоже расширялся за счёт сторонних DLL), и нужно было определиться, какой язык ляжет в основу нового инструмента. Но у Microsoft уже был QBASIC, и можно догадаться, какие именно планы родились в голове у Билла Гейтса, когда он принял решение купить такой перспективный актив, как Ruby.

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



EB
Вы когда-нибудь смотрели, сколько разных недокументированных функций экспортирует рантайм VB?
Изображение
Уж точно вы должны были слышать о функции EbExecuteLine, позволяющей интерпретировать и выполнить произвольную строку кода (правда лишь при работе под IDE). Вас не интересовало, что означает префикс «Eb» в именах всех этих функций? Как он расшифровывается?

Сейчас мы с этим разберёмся.

Я не уверен точно, какая именно из двух версий о двух возможных расшифровках более верная, но, очевидно, обе версии недалеки от правды. Начнём с первой версии и обратимся для этого к одной из статьей небезызвестного Джоэля Спольского.
Изображение

Статья называется «My First BillG Review» («Моя первая проверка со стороны Билла Г.», есть русский перевод).

Краткий пересказ истории:
    Летом 1991-го Джоэль устроился на работу в Microsoft в отдел по разработке Excel. Одной из актуальных проблем Excel того времени было то, что в Excel был собственный убогий язык программирования для макросов, в котором не было глобальных и локальных переменных, не было процедур, был goto, но не было меток. Язык не имел собственного названия, и условно назывался «экселевские макросы».

    Задачей Джоэля было решить эту проблему. Витало мнение, что решение проблемы должно быть как-то связано с языком Basic. В другом отделе (в составе Microsoft) уже была наработка по созданию объектно-ориентированного Бейсика под кодовым названием «Silver». Менеджер команды «Silver» видел только одно применение для своей технологии — Excel. Джоэль убедил людей из команды Бейсиков, что команде Excel нужно нечто вроде Бейсика для Excel. При этом ему удалось настоять на том, что в язык должно быть было добавлено 4 фичи:
    1. Добавить Variant-переменные, способные хранить значения любых других типов, иначе невозможно было бы в переменной сохранять значение ячейки Excel-таблицы (по крайней мере не прибегая к Select Case).
    2. Добавить позднее связывание (через IDispatch), потому что изначальная архитектура Silver требовала глубокого понимания системы типов, а в ней люди, пишущие макросы для Excel, не захотели бы разбираться.
    3. Добавить конструкцию For Each, позаимствованную из csh.
    4. Добавить конструкцию With ... End With, позаимствованную из Паскаля.

    После чего Джоэль сел и написал спецификацию на будущий язык Excel Basic, которая заняла примерно 500 страниц, которая затем была отправлена на ознакомление/проверку Биллу Гейтсу. Дальнейшая часть статьи описывает состоявшуюся после этого встречу с Б. Гейтсом, на которой тот задавал Джоэлю вопросы на основе заметок на полях, оставленных Гейтсом при прочтении спецификации.

    Финальная часть статьи говорит, что со временем положение дел сильно продвинулось, Excel Basic стал называться Visual Basic for Applications, а Гейтс однажды вспомнил, как непросто было нанять того толкового менеджера в команду Excel, который всем этим занимался.
Итак, как можно понять из текста статьи, в какой-то момент необходимость замены убогого языка макросов в составе Excel на что-то более продвинутое привела к тому, что ставка была сделана на бейсикоподобные языки, и на основе имевшихся в другом отделе наработок по созданию объектно-ориентированного бейсикоподобного языка, был создан Excel Basic (сокращённо EB) — объектно-ориентированный универсальный язык, пригодный для автоматизации почти чего угодно, а потому быстро вышедший в плане применимости за рамки чисто Excel. Поскольку язык позволял писать макросы/расширения/автомтизацию не только для Excel, а для чего угодно, технология стала применяться не только в Word/Access — Microsoft удалось продать её создателям AutoCAD, SolidWorkds, Corel Draw, ArcGIS. Понятное дело, что технология с такой широкой сферой применения больше не могла называться Excel Basic и была переименована в Visual Basic for Applications, особенно если учесть, что помимо программ в составе Office и программ сторонних разработчиков эта технология стала составной частью того, что известно как просто Visual Basic. При этом аббревиатура «EB» укоренилась в названии множества функций и структур, имеющих отношение к технологии, где остаётся и до сих пор.

Вторая версия расшифровки названия EB — это не Excel Basic, а Embedded Basic. По рассказу Скотта Фергюсона (который шутливо называет себя «мамой Visual Basic'а»), на рубеже 80-х и 90-х годов в Microsoft шла работа над СУБД «Omega» — проектом, который в итоге был заброшен. В состав СУБД «Omega» входил движок Embedded Basic (EB). Разработка шла в отделе, который назывался «отделом языков программирования для бизнеса» и занимался одновременно с этим разработкой QuickBASIC'а. Но основные ресурсы отдела «языков программирования для бизнеса» были сконцентрированы над созданием нового, объектно-ориентированного, заточенного под Windows бейсикоподобного языка программирования, который назывался Silver (мы уже встречали упоминание этого названия и этого продукта в рассказе Джоэля Спольского). Билл Гейтс в какой-то момент прислал в отдел «языков программирования для бизнеса» запрос на тему того, можно ли как-то скрестить Ruby и EB. Джон Файн (менеджер проекта на тот момент) совместно с Скоттом Фергюсоном были поставлены перед задачей дать ответ на этот запрос.

Была создана команда, которая занялась очень непростой интеграцией своего EB с только что купленным со стороны Ruby:
Изображение
(Два человека на фотографии, чьи лица закрашены, были приглашены фотографом со стороны для улучшения композиции кадра, и к разработке VB никакого отношения не имеют)

Новый продукт, рождавшийся от слияния EB и Ruby, получил название Thunder (следы этого названия сохранились вплоть до VB6 в именах многих внутренних функций (например ThunderMsgLoop) или в именах оконных классов (например ThunderRT6FormDC). Скотт Фергюсон вспоминает, что ещё в январе 1989 Джон Файн написал (вероятно, начальству, возможно самому Гейтсу) предложение о создании языка программирования под названием «Visual BASIC». Это было ещё задолго до появления Ruby в Microsoft. Много позже перед самым релизом продукта Thunder это название воскресло из забытья наряду со многими другими названиями-кандидатами, рассматривавшимися в качестве официального названия продукта. И оно, на самом деле, многим не понравилось. Большинству нравилось название «Thunder» (в переводе — «Гром») с тогдашним слоганом «The Power to Crack Windows» (в переводе — «Мощь, распахивающая Окна» или, возможно, «Мощь, заставляющая дрожать Окна»).

Так или иначе, не столь важно, расшифровывать ли EB как Excel Basic или Embedded Basic. Судя по словам Джоэля о его вкладе в привнесение 4 важных нововведений в EB, которые остались в VB/VBA по сей день, его виденье истории и вклад в развитие становление VB и VBA тоже должен быть учтён.

Очевидно, что существовала технология Silver и движок EB, созданный изначально для СУБД «Omega».
EB сам по себе, не без участия Джоэля, вошёл в состав Excel и стал тем, что сейчас известно как VBA.
EB, слившись с куперовским Ruby, под влиянием идей Silver, стал тем, что сейчас известно как VB.
Проект «Omega» с имевшимся в нём EB, предположительно, реинкарнировал как Access/MS Jet, в котором EB по прежнему является значимой частью.



Современное положение дел
Вплоть до последней версии продукта — до VB6, граница между Ruby и EB не растворилась, оба этих компонента не слились до степени неразличимости. Между ними по прежнему есть отчётливая граница, каждый компонент занимается своим, имеет, так сказать, свою зону ответственности и область решаемых задач.

Разделение сохраняется даже на уровне исходников (сведения об исходниках, из которых скомпилирован VB, могут быть получены из файлов с отладочными символами). С точки зрения комплекта исходников, VB6 состоит из двух папок: ruby/ и vbadev/

В первой находятся все исходники Ruby, во второй — все исходники EB (который, как мы знаем из статьи Джоэля, в какой-то момент был переименован в VBA). У многих функций и переменных из Ruby в качесте префикса мы встретим префикс Rby, у многих функций, переменных и структур EB мы увидим префикс Eb.

EB — что включает в себя, чем занимается и за что отвечает:
  • EB/VBA в целом устроен как технология, которую можно прикрутить к чему угодно — к любому внешнему приложению (для такого приложения применяется термин «host»/«хост»). Будучи приделанным к какому-то хосту, EB/VBA позволяет писать код, который может взаимодействовать с хостом, управлять объектной моделью хоста, что в итоге даёт возможность расширять логику работы хоста как угодно и писать автоматизацию для любых приложений-хостов, к которым приделали EB/VBA.
  • EB/VBA не зависит от конкретного хоста — это хост зависит от EB/VBA, а EB/VBA может быть «прикручен» к чему угодно.
    EB + Excel даёт нам VBA в Excel.
    EB + Word даёт нам VBA в Word.
    EB + AutoCAD даёт нам VBA в AutoCAD'е.
    EB + Ruby даёт нам то, что мы знаем как «самостоятельный VB» (standalone VB, VB1—VB6).
    То есть Ruby — лишь частный случай хоста для EB. Ruby не может жить без EB, зато EB может жить с любым другим хостом.
  • Редактор кода с подсветкой синтаксиса, автодополнением и IntelliSense — это часть EB/VBA. Речь идёт именно о самом текстовом поле, в котором пишется код, не включая панели инструментов, тулбары, меню. Именно по этой причине в VBA и VB редактор кода идентичен.
  • Виртуальная машина, выполняющая P-код — часть EB/VBA.
  • Механизм парсинга VB-кода и трансляции его в P-код по принципу just-in-time-компиляции — часть EB/VBA. Поэтому и синтаксис языка это тоже часть EB, и не имеет никакого отношения к Ruby, и по этой причине во всех хостах, к которым приделан EB, язык будет одним и тем же с одними и теми же синтаксическими правилами и особенностями (например баг Not Not Arr будет проявляться везде).
  • Набор фундаментальных типов и набор поддерживаемых языком операторов (And, Xor, Like, &) — часть EB/VBA, поэтому к какому бы хосту ни был прикручен EB/VBA, всё это будет везде одинаковым. Если вы разработчик хоста и у вас есть полный контроль над исходниками хоста, но EB для вас — чёрный ящик, то вы никаким образом не сможете добиться появления поддержки нового оператора в коде (например, оператора побитового сдвига, которого исходно нет).
  • Концепция обработки ошибок — часть EB/VBA, поэтому куда бы ни был прикручен EB/VBA, всё везде будет одинаковым.
  • Концепция, что всё делится на проекты, а проекты состоят из модулей (точнее из project items — проектных элементов) проистекает из EB/VBA. При этом EB понятия не имеет ни о каких формах и UserControl-ах — с точки зрения EB модули бывают лишь двух видов (обычные и объектные). Хост может устанавливать свои подвиды для объектных модулей. В VB6 это классы, формы, юзерконтролы. В Excel это классы, юзерформы, листы (worksheet) и книги (workbook). В каких-то других хостах могут быть свои подвиды модулей. Но общая концепция проектов и модулей будет существовать в любом хосте.
  • Концепция подключения ссылок на сторонних библиотеки типов — это возможность механизма EB/VBA, а потому она есть и в VB, и во всех применениях VBA. Сама же ссылка на подключенную к проекту TLB-шку внутри EB имеет название EBREF и описывается одноимённой структурой.
  • Все функции, известные большинству как «функции рантайма», такие как MsgBox, InputBox, Rnd, Beep, CreateObject, DateDiff, RGB, StrReverse, MkDir — всё это часть EB/VBA, а потому все эти функции обязательно будут присутвовать не только в чистом VB, но и в VBA: и в Excel'е, и в Word'е, и AutoCAD'е и в любом другом хосте.
  • Классы Collection и ErrObject являются частью EB/VBA, и, аналогичным образом, могут быть найдены и в чистом VB, и в приложениях Microsoft Office и прочих хостах.
  • Такие недокументированные и поэтому мало кому известные механизмы, как сервер выражений и система мониторинга VBA-событий тоже являются частью EB.
  • Всё, что так или иначе связано с пользовательским интерфейсом и какими-то визуальными проявлениями при выполнении программы — в принципе не_является частью EB. Например, функция MsgBox, являющаяся частью EB (VBA) и показывающая диалоговое окно с сообщением, не занимается непосредственно отображением окошка — EB понятия не имеет, каким способом должно быть показано сообщение и с применением каких средств это может быть сделано. Вместо этого EB обращается к своему хосту и вызывает у хоста специальную callback-функцию, которая отвечает за визуальную часть показа сообщений. Между EB и хостом существует такой интерфейс взаимодействия, как массив указателей на callback'и, предоставляемые хостом. Когда хост инициализирует EB, он вызывает у EB функцию EbInitHost и передаёт ей этот массив. EB запоминает указатель на этот массив и, когда приходит необходимость показать сообщение, берёт соответствующий элемент массива (этот адрес соответствующий callback-функции) и вызывает нужную функцию. И именно код хоста определяет, как будет показано сообщение, будет ли это окно, какое это будет окно и какое у него будет оформление. В этом плане EB сделан настолько универсальным, что хостом для EB может послужить, например, полноэкранная игра, использующая DirectX. И в этой игре обращение к MsgBox не приведёт к появлению обычного виндового диалога, который нарушит полноэкранный режим — реализованная игровым хостом callback-функция для отображения сообщений покажет сообщение в игровой стилистике, которое отображаться будет путём отрисовки с помощью DirectX, как и весь прочий игровой UI.

Ruby — что включает в себя, чем занимается и за что отвечает:
  • В первую очередь надо сказать, что Ruby понятия не имеет (и его не волнует), какой язык стоит за кодом, который управляет инфраструктурой — той, что Ruby предоставляет. В случае VB в связке с Ruby используется EB, но чисто гипотетический там мог бы стоять и голый код на С/С++, или какой-нибудь скриптовый движок или же система визуального программирования типа Scratch, в которой код не пишут, а рисуют в виде блок-схем и диаграмм. Кстати, по изначальной задумке Алана Купера именно так Ruby и работал: когда пользователь нарисовал пару gizmo, скажем, кнопку и листбокс, то для того, чтобы сделать так, что при клике на кнопку листбокс исчезал бы, пользователь прямо мышкой рисовал стрелку, идущую от события «click» первого gizmo до метода «hide» второго gizmo. Итак...
  • Все встроенные в VB элементы управления (контролы), такие как CommandButton, ListBox, Drive, Circle, PictureBox, ScrollBar — всё это часть Ruby.
  • Объекты App, Clipboard, коллекция Forms, Printers, объект Screen, методы Load и Unload, метод LoadPicture/SavePicture — всё это часть Ruby. По этой причине, открыв VBA в Excel, у вас не получится написать там App.Path или Screen.ActiveForm — никаких App и Screen там попросту не будет, ибо это часть Ruby, а не EB.
  • Механизм форм, на основе которых создаются окна — это Ruby.
  • Вся обработка оконных сообщений, фильтрация, переадресация и превращение оконных сообщений в события у контролов — это Ruby.
  • Значительная часть того, что касается среды разработки (IDE) и способов рисования форм в design-time — это Ruby. Например дерево проекта, палитра компонентов, панель свойств, диалог свойств проекта, диалоги среды, механизм поддержки подключаемых Add-in'ов — всё это Ruby.
  • Все механизмы обеспечения, необходимые для работы самостоятельных EXE-файлов, а также работы проектов, скомпилированных с образованием DLL/OCX-файлов, а также ActiveX EXE-проектов — всё это Ruby. Например, любая ActiveX DLL обязана иметь функцию DllGetClassObject, которая возвращает фабрику класса для запрошенного класса. DllGetClassObject и фабрика классов — всё это реализовано в исходных файлах, являющихся частью Ruby.
  • Всё, что касается OLE, DDE и механизмов data-binding'а (это когда контролы на форме, например, текстовые поля, привязываются к полям рекордсета и сами меняются при переходе по строкам в рекордсете, а изменение значений в контролах приводит к изменению значений в БД — и всё это без написания доп. когда со стороны VB-программиста, а просто за счёт настраивания связи между контролами формы и базой данных) — всё это Ruby.

Вот такое получается разделение. Если предположить, что у вас на руках есть полные исходники VB, и вам надо поправить что-то в поведении кнопки или добавить новое свойство у форм — идите в исходники Ruby. Если вы хотите поправить что-то во встроенном классе Collection или замахнулись на добавление нового оператора в VB — идите в исходники EB.

Разделение на Ruby и EB видно не только на уровне исходников. Если зайти в Project→References, то мы увидим там несколько подключенных библиотек типов, которые нельзя отключить. Одна из них соответствует всему, что привносит EB, другие две — всему, что привносит Ruby:
Изображение

EB/VBA имеет свою библиотеку типов, и в ней можно найти все встроенные рантаймовые функции, а также два единственных класса — Collection и ErrObject:
Изображение
Если мы откроем Visual Basic в Excel, мы увидим ту же библиотеку типов в References и Object Browser'е — и все функции будут на месте.

Ruby имеет свою библиотеку типов, где можно найти все встроенные контролы и объекты типа App, Printers, Screen:
Изображение



Анатомия VB6.EXE, VBA6.DLL и MSVBVM60.DLL
Все знают, что скомпилированный VB-проект неминуемо будет зависеть от MSVBVM60.DLL — как только ни называют эту библиотеку (и рантаймом, и виртуальной машиной VB). Пока же проект существует в виде исходников и отлаживается под IDE, его работу обеспечивает сама IDE, состоящая главным образом из двух бинарников:
  • VB6.EXE
  • VBA6.DLL (от неё зависит VB6.EXE)

Факт, который кому-то может показаться удивительным: начинка msvbvm60.dll это наполовину начинка VB6.EXE, и наполовину начинка VBA6.DLL.

На самом деле VB6.EXE является результатом компиляции исходников Ruby, а VBA6.DLL является результатом компиляции исходников EB.
Рантайм MSVBVM60.DLL же просто состоит примерно наполовину из Ruby, и наполовину из EB.


Два комплекта исходников (ruby/ и vbadev/), олицетворяющих два основных компонента этого продукта, в результате компиляции и линковки с разными ключами и опциями дают в итоге 3 исполняемых файла.

То есть нет такого явления как «исходники MSVBVM60.DLL» и «исходники VB IDE» — и то, и другое компилируется и собирается из одних и тех же исходников! Но с разными опциями и ключами компиляции, с разными флагами условной компиляции.

Процесс сборки IDE (VB6.EXE + VBA6.DLL) получается таким:
Изображение


Процесс сборки рантайм-библиотеки MSVBVM60.DLL почти такой же: те же самые исходные файлы компилируются (с немного другими ключами компиляции) в объектные файлы (obj), а затем всё это линкуется в один итоговый DLL-файл:
Изображение

Подобно тому, как генетический код человека на 98% идентичен генетическому коду шимпанзе, подавляющая часть двоичного кода в составе msvbvm60.dll повторяет код либо из vb6.exe, либо из vba6.dll. Почти любая процедура, входящая в состав msvbvm60.dll является либо частью Ruby, либо частью EB, а потому может обнаружена в неизменном или слегка изменённом виде либо в составе vb6.exe, либо в составе vba6.dll.

Обратное не верно: суммарный размер кода vb6.exe (1.80 Мб) и vba6.dll (1.61 Мб) больше, чем размер msvbvm60.dll (1.32 Мб).

Очевидно, что в состав Ruby входит код, реализующий, например, редактор форм или диалог свойств проекта — всё это попадает в vb6.exe, но не попадает в msvbvm60.dll (оно там не нужно).
Очевидно, что в состав EB входит код, реализующий синтаксический разбор, анализ, компиляцию VB-кода в P-код — всё это попадает в vba6.dll, но не попадает в msvbvm60.dll (оно там не нужно).

Если сделать некоторые упрощения, и не ставить целью точно соблюдать масштаб, то следующая иллюстрация отлично показывает, как исполняемые файлы, образующие IDE (среду), и исполняемый файл, представляющий собой рантайм, состоят, на самом деле, из общего кода:
Изображение

Выше уже были хоть и неполные, но достаточные списки вещей, являющихся частью Ruby, и являющихся частью EB. Если ещё больше упростить, отбросить лишнее и оставить только самые выдающиеся и часто вспоминаемые компоненты VB, то можно нанести их на эту иллюстрацию. Ещё раз хочу сказать: это сильное упрощённое изображение на базе сильно упрощённого текста. Его цель — не создание полного списка субкомпонентов, из которых состоят Ruby и EB. Полный список не уместится на такой маленькой картинке, картинку пришлось бы сделать как минимум раз в 20 больше. Цель в том, чтобы просто, взглянув на иллюстрацию, понять и почувствовать саму идею, сам принцип разделения. Получить примерное представление, какие субкомпоненты (отвечающие за те или иные вещи) являются частью Ruby, а какие частью EB, и как эти субкомпоненты распределены по исполняемым файлам (VB6.EXE, VBA6.DLL и MSVBVM60.DLL). Вот эта видоизменённая иллюстрация:
Изображение

В следующих статьях мы более подробно поговорим о составе EB и Ruby, рассмотрим более полно набор компонентов, из которых складывается работоспособная среда VB IDE (ведь кроме VB6.EXE и VBA6.DLL есть ещё LINK.EXE, C2.EXE, MSO98RT.DLL и.п.).
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16230
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: Ruby + EB = Visual Basic

Сообщение Хакер » 10.06.2019 (Пн) 14:22

Текст этой статьи я написал около года назад.

Специально для этой статьи было сделано два перевода других статей, написанных людьми, стоящими за созданием VB:

Настоятельно рекомендую после прочтения этой статьи прочитать эти два перевода, чтобы окунуться в описания взгляда на те же вещи от участников событий.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

NashRus
Постоялец
Постоялец
 
Сообщения: 381
Зарегистрирован: 18.03.2006 (Сб) 1:16

Re: Ruby + EB = Visual Basic

Сообщение NashRus » 10.06.2019 (Пн) 14:56

>> и не VBA является побочным продуктом от создания VB, а скорее VB является побочным продуктом появления VBA.

да, это следует из коммерческого тренда MS. Офис всегда был рабочей лошадкой, является им и сейчас. Многие технологии для Windows мигрировали из Офиса. Это хороший пример синергии.

Debugger
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1664
Зарегистрирован: 17.06.2006 (Сб) 15:11

Re: Ruby + EB = Visual Basic

Сообщение Debugger » 10.06.2019 (Пн) 16:14

Это самое классное и необычное, что я читал про Visual Basic (да и про любой другой язык программирования, наверное).

Класс!

Teranas
Продвинутый пользователь
Продвинутый пользователь
Аватара пользователя
 
Сообщения: 166
Зарегистрирован: 13.12.2008 (Сб) 4:26
Откуда: Новосибирск

Re: Ruby + EB = Visual Basic

Сообщение Teranas » 11.06.2019 (Вт) 20:03

Отличная статья, спасибо!
Последний раз редактировалось Хакер 11.06.2019 (Вт) 21:37, всего редактировалось 1 раз.
Причина: Опечатку исправил, спасибо.
С уважением, Андрей.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1938
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: Ruby + EB = Visual Basic

Сообщение ger_kar » 11.06.2019 (Вт) 21:11

Да, интересная статья, и наводит на определенные размышления. Получается, что с развитием линейки продуктов MS Office, VBA(EB) также развивается. А вот с другой частью (Ruby) засада. И если для 64-битной платформы - VBA вполне себе адаптировали, то с Ruby дело совсем глухо.
Бороться и искать, найти и перепрятать

Adam Smith
Продвинутый пользователь
Продвинутый пользователь
Аватара пользователя
 
Сообщения: 188
Зарегистрирован: 25.04.2008 (Пт) 9:04
Откуда: ЧР. Грозный

Re: Ruby + EB = Visual Basic

Сообщение Adam Smith » 13.06.2019 (Чт) 17:35

ger_kar писал(а):Да, интересная статья, и наводит на определенные размышления. Получается, что с развитием линейки продуктов MS Office, VBA(EB) также развивается. А вот с другой частью (Ruby) засада. И если для 64-битной платформы - VBA вполне себе адаптировали, то с Ruby дело совсем глухо.

Видимо за прошедшие годя я совсем отстал. В чём развитие VBA? Где это его развивают?

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1938
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: § 10. Ruby + EB = Visual Basic

Сообщение ger_kar » 13.06.2019 (Чт) 18:41

Adam Smith писал(а):В чём развитие VBA? Где это его развивают?
Ну по крайней мере в составе продуктов MS Office. Про другие продукты, в которые раньше был интегрирован VBA, я сведениями к сожалению не располагаю, но то что в 64 битную версию MS Office интегрирован 64 битный VBA это вроде общеизвестный факт. Также в новых версиях VBA добавлено некоторое количество новых ключевых слов. Вот "The trick" на днях добавил в копилку кирпич, который помимо всего является универсальным и рассчитан под разные версии VBA и VB6. Так вот в коде этого кирпича, как раз и можно узреть некоторые изменения касаемые новых версий VBA.
Бороться и искать, найти и перепрятать

Adam Smith
Продвинутый пользователь
Продвинутый пользователь
Аватара пользователя
 
Сообщения: 188
Зарегистрирован: 25.04.2008 (Пт) 9:04
Откуда: ЧР. Грозный

Re: § 10. Ruby + EB = Visual Basic

Сообщение Adam Smith » 14.06.2019 (Пт) 6:37

Безусловно респект автору.
Извините, но я не увидел в коде ничего нового и "64х битного".
Сам таймер в 64х битной библиотеке? Ну и чего?
Совместимость в том, что нет отличий от x86?
Компиляция 64х битного exe это было бы удивительно.
Я не сужу, может просто не проснулся ещё.
До сих пор даже линкер из 2010 студии не отколупал.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1938
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: § 10. Ruby + EB = Visual Basic

Сообщение ger_kar » 14.06.2019 (Пт) 7:26

Adam Smith писал(а):Компиляция 64х битного exe это было бы удивительно.
Ну речь же о VBA, который вообще никакие исполняемые файлы на свет не производит и работает исключительно с байт кодом.

Adam Smith писал(а):Извините, но я не увидел в коде ничего нового и "64х битного".
Ну как же. Буквально в самом начале модуля идут объявления WInAPI функций и сразу же бросается в глаза следующая конструкция Private Declare PtrSafe Function в которой можно увидеть новое ключевое слово PtrSafe, про которое официальная справка сообщает следующее:
The PtrSafe keyword is used in this context: Declare statement.

Declare statements with the PtrSafe keyword is the recommended syntax. Declare statements that include PtrSafe work correctly in the VBA7 development environment on both 32-bit and 64-bit platforms only after all data types in the Declare statement (parameters and return values) that need to store 64-bit quantities are updated to use LongLong for 64-bit integrals or LongPtr for pointers and handles.

To ensure backwards compatibility with VBA version 6 and earlier, use the following construct:


Код: Выделить всё
#If VBA7 Then
Declare PtrSafe Sub...
#Else
Declare Sub...
#EndIf


When running in 64-bit versions of Office, Declare statements must include the PtrSafe keyword. The PtrSafe keyword asserts that a Declare statement is safe to run in 64-bit development environments.

Adding the PtrSafe keyword to a Declare statement only signifies that the Declare statement explicitly targets 64-bits. All data types within the statement that need to store 64-bits (including return values and parameters) must still be modified to hold 64-bit quantities by using either LongLong for 64-bit integrals or LongPtr for pointers and handles.


Перевод первого абзаца:
Ключевое слово PtrSafe используется в этом контексте:
Объявление оператора.

Объявление операторов с ключевым словом PtrSafe является рекомендуемым синтаксисом. Операторы Declare, включающие PtrSafe, корректно работают в среде разработки VBA7 как на 32-разрядных, так и на 64-разрядных платформах, только после того, как все типы данных в операторе Declare (параметры и возвращаемые значения), которые должны хранить 64-разрядные количества, обновлены для использования LongLong для 64-битных интегралов или LongPtr для указателей и дескрипторов.

Чтобы обеспечить обратную совместимость с VBA версии 6 и более ранней, используйте следующую конструкцию:
...


Погуляв по документации и перейдя на эту страницу можно увидеть, что в VBA появились новые типы данных, такие как LongLong, LongPtr
Бороться и искать, найти и перепрятать

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16230
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: § 10. Ruby + EB = Visual Basic

Сообщение Хакер » 14.06.2019 (Пт) 15:22

ger_kar писал(а):Ну речь же о VBA, который вообще никакие исполняемые файлы на свет не производит и работает исключительно с байт кодом.

И всё-таки, в терминах Ruby+VBA именно VBA занимается производством исполняемых файлов. Модифицировали ли эту часть VBA со временем, или просто выкинули — неизвестно.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1938
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: § 10. Ruby + EB = Visual Basic

Сообщение ger_kar » 14.06.2019 (Пт) 16:52

Хакер писал(а):И всё-таки, в терминах Ruby+VBA именно VBA занимается производством исполняемых файлов. Модифицировали ли эту часть VBA со временем, или просто выкинули — неизвестно.
Это да. Но я имел ввиду исключительно чистый VBA, в составе MS Office, который не имеет документированной возможности создавать исполняемые PE файлы. Может в своих недрах он и содержит некий код, отвечающий за создание таких файлов, но по факту ничего не создает. Кстати, а как быть с возможностью создавать (рисовать) формы в VBA? За это же по идее Ruby отвечает. Значит в составе VBA и Ruby также присутствует?
Бороться и искать, найти и перепрятать

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16230
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: § 10. Ruby + EB = Visual Basic

Сообщение Хакер » 14.06.2019 (Пт) 17:12

ger_kar писал(а):Кстати, а как быть с возможностью создавать (рисовать) формы в VBA? За это же по идее Ruby отвечает. Значит в составе VBA и Ruby также присутствует?

В составе офиса Ruby нет. Возможность рисовать формы там реализована независимо от Ruby, реализация контролов там совершенно другая (библиотека MS Forms — для Офиса 2003 это FM20.DLL). Набор контролов другой (такого контрола как PictureBox нет в принципе), контролы не используют WinAPI-окна. Набор свойств у всех контролов другой.

Но главное: совершенно разная анатомия внутреннего устройства этих контролов. После публикации соответствующих статей цикла об анатомии Ruby-контролов можно будет вернуться к этой теме и сравнить.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1938
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: § 10. Ruby + EB = Visual Basic

Сообщение ger_kar » 14.06.2019 (Пт) 19:23

Хакер писал(а):Но главное: совершенно разная анатомия внутреннего устройства этих контролов.
Да уж, контролы совершенно разные. В принципе контролы MS Forms вполне себе ничего, а в чем то даже и лучше стандартных контролов VB6 (в основном это касается привязки к данным), но вот отсутствие PictureBox и невозможность использовать массивы контролов, сильно осложняют процесс программирования под VBA. Особенно раздражает невозможность использовать массивы контролов. Иногда это прям бесит, когда вместо красивой и лаконичной реализации, приходится городить огород из костылей :cry:
Бороться и искать, найти и перепрятать

jangle
Википедик
Википедик
Аватара пользователя
 
Сообщения: 3001
Зарегистрирован: 03.06.2005 (Пт) 12:02
Откуда: Москва

Re: § 10. Ruby + EB = Visual Basic

Сообщение jangle » 25.06.2019 (Вт) 11:23

Интересная статья. Когда будет продолжение?

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16230
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: § 10. Ruby + EB = Visual Basic

Сообщение Хакер » 25.06.2019 (Вт) 14:32

Скоро.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.


Вернуться в VB Internals

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

    TopList