§ 10. Ruby + EB = Visual Basic

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

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

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16473
Зарегистрирован: 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.

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16473
Зарегистрирован: 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
Постоялец
Постоялец
 
Сообщения: 386
Зарегистрирован: 18.03.2006 (Сб) 1:16

Re: Ruby + EB = Visual Basic

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

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

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

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

Re: Ruby + EB = Visual Basic

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

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

Класс!

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

Re: Ruby + EB = Visual Basic

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

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

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1957
Зарегистрирован: 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
Бывалый
Бывалый
Аватара пользователя
 
Сообщения: 219
Зарегистрирован: 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
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1957
Зарегистрирован: 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
Бывалый
Бывалый
Аватара пользователя
 
Сообщения: 219
Зарегистрирован: 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
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1957
Зарегистрирован: 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
Бороться и искать, найти и перепрятать

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16473
Зарегистрирован: 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
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1957
Зарегистрирован: 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 также присутствует?
Бороться и искать, найти и перепрятать

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16473
Зарегистрирован: 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
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1957
Зарегистрирован: 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
Википедик
Википедик
Аватара пользователя
 
Сообщения: 3013
Зарегистрирован: 03.06.2005 (Пт) 12:02
Откуда: Нидерланды

Re: § 10. Ruby + EB = Visual Basic

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

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

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16473
Зарегистрирован: 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.

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

Re: § 10. Ruby + EB = Visual Basic

Сообщение Teranas » 10.12.2019 (Вт) 13:19

Приветствую всех!
Ну, и где обещанное продолжение?
С уважением, Андрей.

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

Re: § 10. Ruby + EB = Visual Basic

Сообщение jangle » 11.12.2019 (Ср) 21:59

Видимо запал прошел

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

Re: § 10. Ruby + EB = Visual Basic

Сообщение Debugger » 11.12.2019 (Ср) 23:53

Скоро ещё не наступило :(

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

Re: § 10. Ruby + EB = Visual Basic

Сообщение Хакер » 12.12.2019 (Чт) 21:05

Не запал кончился, а здоровье кончилось. Серьёзно, вопрос, который меня занимает в последние месяцы если не каждый день, то через день, это вопрос о том, вызывать ли в очередной раз скорую, или перетерпеть на этот раз.

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

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

Re: § 10. Ruby + EB = Visual Basic

Сообщение Adam Smith » 23.12.2019 (Пн) 9:23

:( выздоравливай давай

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

Re: § 10. Ruby + EB = Visual Basic

Сообщение Teranas » 24.12.2019 (Вт) 15:44

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

Old_Maple
Обычный пользователь
Обычный пользователь
 
Сообщения: 54
Зарегистрирован: 25.10.2016 (Вт) 12:03

Re: § 10. Ruby + EB = Visual Basic

Сообщение Old_Maple » 11.09.2022 (Вс) 13:42

Безусловно, очень интересная статья! Спасибо автору!
Но у меня есть вопрос, может быть не совсем по теме. Но не хочется его выносить в отдельный топик. Тем более, что здесь присутствующих умных голов предостаточно. :D
Многие, присутствующие здесь на форуме отличные программисты, очень хорошо относятся к VB6 и хотели бы, чтобы MS развивал его дальше - типа VBx64. Но, друзья мои, а что вам мешает самим реализовать эту идею? Часть кода уже реализована самим MS в VBA для x64 MS Office. Я понимаю, что процесс нелёгкий, но, как говорится: "Путь одолеет идущий". Хороший тому пример - QB64, созданный энтузиастами. К сожалению, QB64 не так хорош, как VB, но он поддерживает 64-разрядность, а это немало!
Как думаете, сможете осилить такой проект?
Veritas est aeterna!

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

Re: § 10. Ruby + EB = Visual Basic

Сообщение Хакер » 11.09.2022 (Вс) 13:52

Следующая парочка параграфов этого цикла, которая дописана на 99% уже давно, как раз посвящена оценки объёма исходного кода VB/VBA, откуда может быть сделана оценка трудоёмкости всего мероприятия.

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

Old_Maple
Обычный пользователь
Обычный пользователь
 
Сообщения: 54
Зарегистрирован: 25.10.2016 (Вт) 12:03

Re: § 10. Ruby + EB = Visual Basic

Сообщение Old_Maple » 12.09.2022 (Пн) 18:49

Все статьи, написанные Вами, разумеется,были мной прочитаны. За что Вам безмерно благодарен! Но тут есть огромное множество инициативных программистов, имеющие системное мышление. Думаю, им это будет сделать по силам. Ну а Вы, Хакер, могли бы выступать в этом титаническом проекте в роли аналитика и куратора, чтобы излишне инициативных останавливать и наставлять. Мне думается, Вам бы это было по силам. Попробуйте кинуть клич и посмотрим, будут ли энтузиасты. Ну, как-то так.
P.s. Вопрос чисто теоретический: Можно ли на VB6 написать VB64 не прибегая к другим языкам пpограммирования x32 или x64?
Veritas est aeterna!

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

Re: § 10. Ruby + EB = Visual Basic

Сообщение Хакер » 13.09.2022 (Вт) 8:15

Old_Maple писал(а):P.s. Вопрос чисто теоретический: Можно ли на VB6 написать VB64 не прибегая к другим языкам пpограммирования x32 или x64?

До ответа на этот вопрос хотелось бы задать другой вопрос.

Что мы понимаем под 64-битным VB? Что мы хотим от 64-битного VB?

64-битный VB это в первую очередь то, что даёт на выходе 64-битные бинарники (EXE и DLL)?
Если так, то для чего нам это нужно? 32-битные бинарники и так успешно запускаются под 64-битными ОС. А вот наоборот не работает: 64-битный бинарник не заведётся под 32-битной ОС. Так что в этом плане игра не стоит свеч, цель не оправдывает средства, 32-битные бинарники оказываются более универсальными.

А может быть мы хотим воспользоваться преимуществом 64-битной архитектуры в виде огромного адресного пространства, не ограниченного номинальными 4G и фактическими 2G (или 3G в режиме /3GB) адресов?

Или нас в первую очередь интересует 64-битная арифметика и возможность манипулирования огромными числами без заморочек?

И в первом и втором случае серьёзнейший вопрос, который автоматически возникает из-за указанных новшеств: это как поступить с системой типов VB?

Готовность оказаться в 64-битном окружении с 64-битным диапазоном адресов виртуального адресного пространства автоматически означает необходимость перехода на 64-битные указатели и на увеличение размеров всех указательных типов. Размеры типов As String, As Object вырастут с 4 байтов до 8.

В какой-то мере это уже ломает обратную совместимость и работоспособность массы уже существующего VB-кода, который полагался на то, что размер этих типов составляет 4 байта, и работал с такими переменными используя CopyMemory, GetMem4, PutMem4. Самое коварное состоит в том, что было бы хорошо, если бы старый код под новым 64-битным VB просто отказывался бы запускаться и компилироваться, подсвечивался бы красным, но в нашем случае он будет компилироваться и запускаться на ура, только вот работать будет непредсказуемым образом — причём с некоторой долей вероятности он может даже продолжать правильно работать, но это будет вопросом везения. И не все ветки исполнения в коде исполняются всегда, некоторые ветки в коде выполняются только в очень редких случаях, поэтому отыскивать такие места будет не так-то тривиально.

Изменение размера типов As String, As Object страшно ещё и тем, что от этого автоматически увеличиваются размеры структур (User Defiend типов), в которых есть поля подобных типов, причём происходит смещение всех остальных полей.

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

И это пока что от того, что мы согласились на само существование в виде 64-битного процесса с 64-битной адресацией, но сделали вид, что целочисленные типы у нас остались как и прежде. Но мы не можем оставить целочисленные типы в том виде, в каком они были.

Ведь у нас есть функции VarPtr, StrPtr, ObjPtr, которые все имеют тип возврата Long. Если мы в целях обратной совместимости оставили Long четырёхбайтным, то в новом окружении мы получаем неработоспособные функции VarPtr/StrPtr/ObjPtr, потому что теперь не любой адрес нового размера уложится в тип Long старого размера.

Если мы увеличиваем тип Long до размера 64 бит, то мы ломаем обратную совместимость с феерическими объёмами уже существующего VB-кода. В частности весь код, который записывал какие-то данные в файлы или наоборот загружал их из файлов, поломается, потому что при записи структуры
Код: Выделить всё
Type FOO
    xxx as long
    yyy as long
    zzz as long
End Type

в файл или чтении из файла будет прочитано/записано не 12 байт, а 24 байта.

Так что по умолчанию менять размер тип Long — явно никудышная идея.

Тогда нужно будет ввести новый тип для 64-битных чисел. Long64? Или LongLong?

Тогда VarPtr должен быть иметь тип возврата не Long, а Long64, чтобы весь диапазон потенциальных адресов в него вмещался. Но тогда логичным будет вообще ликвидировать старые VarPtr/StrPtr/ObjPtr, а вместо них ввести VarPtr64, StrPtr64, ObjPtr64 с типом возврата Long64, для того чтобы намеренно поломать старый код вида

Код: Выделить всё
Dim address As Long
address = VarPtr(foo)


чтобы он перестал запускаться. Потому что только это вынудит человека добраться до этих строчек и поменять VarPtr на VarPtr64, а Long в объявлении переменной на Long64. Иначе возврат от непереименованной VarPtr будет присваиваться переменным типа Long, а это грозит ошибкой Overflow, которая будет отлавливаться только во время работы (и не всегда), а не на этапе компиляции.

Хорошо, мы вводим новые типы вроде Long64.

Но есть одна проблема. Точнее не одна проблема, а целая группа проблем, опять же связанных с совместимостью.

Есть такой тип Variant, он же VARIANT в COM. Это не какая-то вещь, ограниченная рамками VB, это вещь из технологии COM и OLE Automation — это вещь, которая позволяет VB-приложениям взаимодействовать с не VB-шными приложениями и наоборот. Объектом, написанным на VB, можно воспользоваться из C++-приложения, и с тем же успехом можно воспользоваться из VBScript-а, где вообще нет никаких типов. А можно объектом, написанным на VB, пользоваться из PHP-скрипта, потому что для PHP существуте расширение для работы с COM-объектами, и если PHP-среда работает под Windows и имеет включенное COM-расширение, то всё получится. Хотя в PHP тоже нет типов.

И это будет работать благодаря Variant-типу, который может вместить в себя любое значение любого типа, из тех типов, которые есть в системе типов VB6 (и даже больше: потому что в VB нет такого типа как Decimal, а в Variant-е он есть).

Мы ведь в VB можем объявить переменную без указания тип, и тогда она будет иметь тип Variant (если в модуле нет фишки типа DefLng), и мы можем присвоить значение ЛЮБОЙ нашей переменной с типом

Код: Выделить всё
Dim x
Dim y as Long
Dim z As Double
Dim k As Date
Dim j As String

x = y
x = z
x = k
x = j


Но если мы вводим в систему типов VB совершенно новые типы, то как быть с тем, что Variant не поддержвиает эти новые типы?

И что вообще поддерживает тип Variant? Это хороший вопрос. Потому что есть два набора подтипов типа Variant, которые официально поддерживаются.

Одно маленькое подмножество соответствует всем тем типам, которые есть в VB в виде встроенны типов, плюс тип Decimal. Это подмножество типов ещё называется множеством типов, совместимых с технологией OLE Automation. Так вот этом подмножестве нет типа, который бы олицетворял нововведённый Long64.

Есть другое множество: более широкое, разработанное для технологии COM. В нём есть полходящий тип для олицетворения Long64. Однако если такое VARIANT-значение «доплывёт» до старого VB6-кода или до VBScript-а, всё поломается, потому что официально такие значения не поддерживаются.

Вернее, тут всё даже несколько сложнее: VARIANT-контейнеры в принципе спосоны хранить значения типа Long64, но вот конвертация таких значений в переменные привичных типов (например Long) могут с некоторой вероятностью генерировать ошибки переполнения, а с другой стороны операции с такими значениями (например сложение одного Variant-а с другим Variant-ом) могут либо работать идеально, либо работать неправильно, потому что операции над Variant-ами выполняет не сам VB (или VBScript, или кто-нибудь ещё), а системная библиотека OLEAUT32.DLL, которая в в разных версиях ОС делает это по разному. Вот очень интересный топик на эту тему.

Так что это очень сложная тема и острая проблема. Подходить к ней нужно крайне взвешенно.

С одной стороны нам хочется появления в VB новых типов: и беззнаковых типов, и типов для 64-битных чисел. С другой стороны, тип Variant сдерживает нас теми типами, которые почти 30-лет назад объявили «поддерживаемыми». Другие типы поддерживаются полуофициально: на практике они работают, де юро же мы вступаем на серую территорию, где если что-то вдруг начинает сбоить, непонятно, кто виноват в неправильном поведении и на ком лежит обязанность чинить свой компонент.



Теперь возвращаемся к изначальному вопросу:
Old_Maple писал(а):Можно ли на VB6 написать VB64 не прибегая к другим языкам пpограммирования x32 или x64?


Ну, во-первых, нет такого понятия как «языки программирования x32» или «языки программирования x64».
Тут всё зависит от того, какие требования мы предъявляем или что мы ожидаем от гипотетического нового VB64. Несколько он должен быть идентичен и похож на VB6.0 по архитектуре, по поведению, по модели работы?

Существующая архитектура VB6 такова, что пока проект не скомпилирован, пока он отлаживается под средой разработки — всё выполнение кода происходит внутри процесса среды разработки. Не скомпилированный в бинарник, но запускаемый на исполнение проект — всё равно, что ребёнок в утробе матери.

И в этом смысле, если мы представляем себе гипотетический VB64, то и код в режиме отладки должен работать в рамках 64-битного процесса, а значит исполняемый файл IDE должен быть 64-битным исполняемым файлом. А существующий VB6 не можем породить на свет 64-битный исполняемый файл. И исходя из такой логики, написать VB64 на VB6 невозможно.

Другое дело, если мы не ставим себе требования повторить то же архитектурное решение, что и в VB6. Если отладка проекта, его запуск проект в режиме отладке не обязан осуществляться как выполнение P-кода в рамках родительского процесса среды разработки, если мы разрешаем себе для отладочных запусков VB64-проекта порождать новый 64-битный дочерний процесс из 32-битного процесса VB64 IDE, то вышеописанного ограчения у нас нет, и такой VB64 IDE написать на VB6 мы можем без каких либо ограничений. Другой вопрос, что это будет на удобным и оптимальным выбором, но вопрос ведь был чисто теоретическим.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

Old_Maple
Обычный пользователь
Обычный пользователь
 
Сообщения: 54
Зарегистрирован: 25.10.2016 (Вт) 12:03

Re: § 10. Ruby + EB = Visual Basic

Сообщение Old_Maple » 13.09.2022 (Вт) 21:41

Большое спасибо за очень содержательный развернутый ответ!
Итак, из вышесказанного следует, что чисто теоретически, все-таки, возможно, с некоторыми условиями.
Теперь, касаемо x64. Разумеется, что имеется в виду обращение ко всему адресному пространству более 2Гб. Потому как даже графические карты имеют его на порядок больше. Любые ограничения сковывают немного программистов.
Ну а если серьезно, то хочется уже наконец-то иметь что-то свое родное, не хуже супостатовского. И что бы оно непременно работало лучше, чем их коммерческие продукты.
Еще раз спасибо за ответ!
Veritas est aeterna!

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

Re: § 10. Ruby + EB = Visual Basic

Сообщение Хакер » 14.09.2022 (Ср) 9:59

Old_Maple писал(а):Разумеется, что имеется в виду обращение ко всему адресному пространству более 2Гб. Потому как даже графические карты имеют его на порядок больше.

Специфика обязывает. Им нужно хранить текстуры, вертексные и индексные буферы, объёмы которых достаточно велики (должны быть велики, чтобы удовлетворять требованиям и хотелкам к современным играм).

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

С виртуальным адресным пространством наличие большого объёма не даёт никаких преимуществ в плане производительности, потому что количество по быстрому доступных страниц определяется объёмом физической памяти. Всё, что не находится в данный момент в физической памяти, будет находиться на диске в файле подкачки. Обращение к этим страницам будут настолько же медленные, насколько медленными будут операции чтения/записи с диска.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

The trick
Постоялец
Постоялец
 
Сообщения: 774
Зарегистрирован: 26.06.2010 (Сб) 23:08

Re: § 10. Ruby + EB = Visual Basic

Сообщение The trick » 14.09.2022 (Ср) 12:50

В 64-битном окружении все процессы являются 64 битными, даже 32-битные, просто они работают через прослойку WOW64 (к слову там очень много интересных и недокументированных возможностей). Есть очень мало моментов (вроде ETW и еще что-то было не помню) где система предоставляет нормальный доступ только для 64 битных процессов, но это так или иначе обходится. Если нужен доступ к новым инструкциям для более быстрого просчета какой-либо тяжелой операции - можно написать 64 битную DLL и загрузить в свой процесс. А если нужен большой регион памяти - как и раньше используйте файл-маппинги. Для большинства прикладных программистов 64 битное окружение в большинстве случаев вообще не нужно.
Кстати есть TwinBasic у него вроде как есть 64 битный компиль, но я не "щупал" его, ничего не могу сказать по поводу него.
UA6527P

Old_Maple
Обычный пользователь
Обычный пользователь
 
Сообщения: 54
Зарегистрирован: 25.10.2016 (Вт) 12:03

Re: § 10. Ruby + EB = Visual Basic

Сообщение Old_Maple » 15.09.2022 (Чт) 20:23

И, все же, что-то мне подсказывает, что поддержка операционными системами 32-разрядных приложерий вскоре прекратиться и VB6.0, всеми нами любимый, отомрет. Рано или поздно перекрестное лицерзирование таких гигантов как MS и Intel к этому приведет. Их инженеры и программисты не должны сидеть без дела, иначе форму потеряют. Ну и обертки все эти с 64 на 32 тоже хорошего мало дают, в том числе по части производительности. Впрочем, если идея создать свой VB64 вам не по душе, то я не настаиваю. Будем супостатовским (теперь уже контрафактным) довольствоваться, увы.
Veritas est aeterna!


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

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

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

    TopList