Расширение проектора: Продолжение 8. Поддержка FP10.1

---

Плеер 10.1 напрочь отказался работать с оболочкой. Симптомы: любой метод возвращает undefined. После недолгих разбирательств
я установил, что прежде хорошо работавшие перехваты ReadFile() при обращении к шаредам, в 10.1 не катят. Что-то там сильно поломали и
перехват перестал работать. Возможно, функция ReadFile() стала импортироваться в коде динамически, на что есть и косвенные подтверждения.
Покрутившись и так, и сяк, перепробовав десяток других вариантов перехвата, я расстроился, у меня ничего не вышло, и я решил окончательно отказаться от этого двига. Действительно, в следующих версиях плеера врядли что-то восстановят как было, скорее уж еще что-нибудь поломают.
Впрочем, что касается AS2-проектов, они по-прежнему успешно работают на этом движке с шаредами, но только в плеерах не старше 10.0.
Пару недель я пребывал в унынии. Растроишься тут!(: Попутно я начал искать основу для нового движка. Побочным продуктом этих поисков, например, появилась статья про asm-вставки. Но вот, наткнулся в "Хакере" на небольшую статейку про eggshunting. Это такой способ внедрения шелл-кода в адресное пространство чужого процесса. Суть не в этом. А в том, что эта статья натолкнула меня на очень простую идею (как я раньше не додумался, не представляю!).
Идея по-истине незамысловата: использовать для обмена данными между проектором и оболочкой класс ByteArray.
Итак, при старте проектор инициализирует экземпляр byte array. Дальше, в оболочке надо найти этот массив, получить указатель на область памяти, где он был размещен. Как?! Перехват VirtualAlloc() тут мучить не айс, ибо вызывается она тут и там, и отсеять мух от котлет было бы затруднительно.
Вот тут нам и помогут "яйца"! В этом контексте яйца - это заведомо уникальный в памяти процесса последовательный (или нет) набор байтов (чисел). Для того, чтобы исключить остатки случайности, берут два таких набора и размещают их друг за другом, от того и яйца.
Значит, при инициализации массива, делаем закладочку:
Почему так топорно! Да какая разница! Оно не суть.
Ну, и пинаем оболочку по LC-каналу - "давай! бери меня за яйца!". В оболочке мы быстренько шерстим память байт за байтом, и.. о! да! вот они! И элементарно запоминаем указатель на начало области размещения закладки. Отлично!
Дальше - дело техники. Вызов метода оболочки теперь выглядит так:
- формируем в проекторе объект с данными запроса (имя метода, аргументы);
- записываем объект в массив (writeObject());
- даем знать оболочке - "забирай и работай"... оппа! а как?
(ну, тут я заюзал System.setClipboard() c фейковым параметром-строкой, и поставил перехват на OpenClipboard())
- после отработки, оболочка записывает ответ-данные в тот же массив, сериализуя в AMF3, и отпускает вызов System.setClipboard();
- ну, вот, теперь делаем в проекторе readObject() и радуемся жизни!
По-дефолту, массиву задается размер 1 Мб. Оболочка следит, чтобы ответ убрался в этот размер, иначе выдается объект, в поле котрого len записан требуемый размер. Тут есть два варианта дальнеших действий: либо попытаться загрести данные по частям (например данные из файла), либо ... сделать реаллок памяти массива и загести все разом. Да! Такое тоже возможно, на что я сделал специальный метод FlrunEx.reallocMem(newSize:uint). Вобщем-то, все изменения коснулись только класса FlrunEx, весь остальной АПИ остался прежним.
Посмотрев на результаты, я остался доволен. Еще бы, скорость обмена данными увеличилась в разы. Да, и есть неплохие шансы, что
в будщих версия плеера новый движок будет работать на ура.
Обновленные сорсы, доки и длл выложил в гугл. Подчеркну, что с новой lcevt.dll (v2.0.0.5) сорсы AS2 работают так же как и раньше, но только до версии плеера 10.0, сорсы AS3 нужно обязательно обновить до текущей версии и работают они с плеерами 9.0, 10.0, 10.1.
Да пребудет с нами сила!