» VMware ThinApp (formerly Thinstall) 3

Выдает такую ошибку. Где копать? Оперативки 16 Гб
Not enough physical memory is available to power on this virtual machine with its configured settings.

To fix this problem, decrease the memory size of this virtual machine to 2028 MB, increase the amount of physical memory for all virtual machines to 1218 MB, or adjust the additional memory settings to allow more virtual machine memory to be swapped.

It is possible that native applications and/or services have locked down memory which could be preventing the virtual machine from launching. Shutting down unnecessary applications or services may free enough memory to launch this virtual machine.

If you were able to power on this virtual machine on this host computer in the past, try rebooting the host computer. Rebooting may allow you to use slightly more host memory to run virtual machines.

popugai
http://forum.ru-board.com/topic.cgi?forum=5&topic=33901&start=4520#1

Поскольку один вопросик повис в воздухе http://forum.ru-board.com/topic.cgi?forum=2&topic=5252&start=200#14 да, и если честно, надо было бы изначально задать его здесь, решил его дополнить и поинтересоваться о следующем:

Друзья, кто сталкивался с такими вот параметрами Package.ini:
UACRequestedPrivilegesLevel=highestAvailable
UACRequestedPrivilegesUiAccess=true
AllowExternalProcessModifications=1

Параметры из разных областей применения. Попробую описать мои вопросы более детальнее:

- По параметру
UACRequestedPrivilegesLevel=highestAvailable
Какой приоритет он даёт относительно UAC на Win7

- По параметру
UACRequestedPrivilegesUiAccess=true

Цитата:

Параметру UACRequestedPrivilegesUIAccess ThinApp присваивает начальное значение, блокирующее доступ к защищённым элементам.

Какие это могут быть защищённые элементы? (желательно пример, чтобы это можно было проверить)

- По параметру
AllowExternalProcessModifications=1
Допустим такой пример - в сборку я нечаянно, или специально (не суть важно) внедряю вирус, а папки системы закрыты под WriteCopy реестр так же закрыт под WriteCopy. Казалось бы, у вируса нет шанса заразить систему или повлиять на неё, но в Package.ini ставлю параметр, позволяющий вести запись в системные процессы. Вопрос: Могут ли вирусы вести запись в системные процессы (например, с целью маскировки)? Если да, то, что помешает вирусу изменить системный процесс так, чтобы тот создал (скопировал) и запустил уже в реальной системе, а не в виртуальном контейнере вирусный код, который повлияет на реальную (хостовую) систему? Или, обозначенный параметр работает как-то иначе?

Поработал над модификацией одной программки, точнее над улучшением своей версии:
Explorer++ v1_3_5_531 Portable ДСП by AVanti_473 R2
Думаю, знатокам пригодиться для исследования всего и вся в плане портабелизации. На сей раз в виртуальный контейнер удалось без проблем поставить и запустить (что не было полностью возможно в прошлой версии):
Adobe After Effects CC 2014 64-бит
Adobe Flash Professional CC 201 64-бит
Adobe Media Encoder CC 2014 64-бит
Adobe Premiere Professional CC 2014 64-бит
Adobe Dreamweaver CC 2014
Smith Micro Poser Pro 2014 64-бит
Традиционно встаёт без проблем в этот контейнер
SONY SpectraLayers Pro v2
и много другой мелочи вроде скайпа, браузера хрома и т.д и т.п.
Конечно же, это далеко не весь список, что можно было бы пробовать ставить в таком контейнере, но, учитывая, какие программы туда уже устанавливаются без особых проблем - даже меня впечатляет. Всё благодаря ThinApp!

[more=Для обычных юзверей]Этот продукт побочный, для узкого круга пользователей, которые хотели бы изучить аспекты портабелизации на примере наглядного пособия. Что-то типа инструмента для лабораторных работ. Так же, продукт для тех, кто не желает засорять свою систему морем инсталляционного софта, а портабельных аналогов необходимых программ не имеет. Данный контейнер можно клонировать на компе сколь угодно раз и устанавливать в него определённые категории программ, которые будут максимально изолированны от реальной системы, но вполне функциональны для достижения и сохранения необходимого результата работы.

Не забывайте, что чем меньше символов в пути к папке с моей программкой, тем больше вероятность успешной установки тестируемого вами софта.
Пример:
Оригинальный путь до файла моей программки может быть таким
C:\Users\Имя_текущего_юзера\Desktop\Explorer++ v1_3_5_531 Portable ДСП by AVanti_473 R2\Explorer++x64.exe
Это уже очень длинный путь, а с учётом папки песочницы, куда будет устанавливаться программа, он станет просто нереальным для системы.
Гораздо проще переименовать папочку с моей программкой в, например, название той программы, которую вы туда будете ставить, скажем, вместо:
Explorer++ v1_3_5_531 Portable ДСП by AVanti_473 R2
назовём её (допустим):
++Skype
и отправим в корень диска С:\ Тогда путь до исполнительного файла моей программки будет таким:
С:\++Skype\Explorer++x64.exe
Что вполне приемлемо.
Для мелких программ длинный путь может быть не критичен, но для громоздких монстров вроде Adobe, данная рекоммендация более чем актуальна![/more]

[more=Для спецов]Этот продукт побочный, для узкого круга пользователей! Все мы знаем как относительно легко конвертировать файлы виртуального реестра .rw.tvr в файлы с содержимым для оригинального реестра. С помощью данного контейнера исследование виртуализируемого софта можно вести без нудного запуска виртуальных машин с чистой системой, делания снапшотов и потери времени на их сравнение до создания проекта. Так же, разумеется, в песочнице сразу видны все папки, которые задействует программа при своей работе.
Конечно же, у многих знатоков имеются свои собственные файловые менеджеры для подобных целей. Но уверен, что не каждый имеет возможность тестировать на старых вариантах портабелизированных файлменеджеров, при помощи старых версий ThinApp, х64-битные приложения. Это маленький, но тоже плюс моей сборочки.[/more]

Цитата:

- По параметру
AllowExternalProcessModifications=1

Пока ответ никто не дал, но в результате тестов имеется интересное наблюдение, а именно, изменение в ветке реестра реальной системы при установке в вышеупомянутый контейнер обыкновенного Google Chrome:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules]
"{60BE4E73-7A47-43C6-8A2B-D8F574274655}"="v2.10|Action=Allow|Active=TRUE|Dir=In|Protocol=17|LPort=5353|App=C:\\Users\\AVanti_473\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe|Name=Google Chrome (mDNS-In)|Desc=Разрешить в Google Chrome передачу входящего трафика по протоколу mDNS|EmbedCtxt=Google Chrome|"

Если весь реестр закрыт под WriteCopy, для чего специально в сборку внесён параметр:
RegistryIsolationMode=WriteCopy
который и так должен работать по умолчанию. То каким же образом в реальную систему просочилась такая запись, как не благодаря параметру:
AllowExternalProcessModifications=1
?
Разумеется, более никаких следов программа не оставила в системе да и не могла бы, но ведь смогла таки получить для себя больше привилегий, а значит, в теории, может вполне комфортно шпионить, даже не меняя системные файлы...

Не то, чтобы это критично, да и без этого параметра явление данного ключа в реестре я не проверял, это лишь моё предположение (что повлиял какой-то параметр сборки), но, всё же, повод лишний раз подумать, что, для чего, и зачем...

AVanti473
Подскажите плиз,чем отличаются :Explorer++ v1_3_5_531 Portable ДСП by AVanti_473 R2 от
Pablo Commander,кроме того что оба не умеют работать с МСИ пакетами..спасибо.

svb777

Цитата:

чем отличаются :Explorer++ v1_3_5_531 Portable ДСП by AVanti_473 R2 от Pablo Commander

Я бы рад был пересказать всё то, что дал в описании к программе (есть в архиве), но это уже будет оф.топ, так как совершенно некорректно, на мой взгляд, сравнивать программы, нацеленные на абсолютно разные задачи. Кто-то делал портабельный Pablo Commander, чтобы пользоваться им как полноценным файловым менеджером в целевой системе и это одна задача. А я делал портабельный вариант Explorer++ совсем для других целей! Продукт получился побочный, но полезный. А почему я выбрал для своей задачи Explorer++, а не Pablo Commander, или более продвинутый файловый менеджер - это более близкий к теме вопрос. Всё потому, что Explorer++ для своей работы использует три файла:
Explorer++RU.dll
config.xml
и собственно сам
Explorer++.exe
Ни один другой, попадавшийся мне на глаза файловый менеджер не использует столь мало файлов и ресурсов. К тому же, Explorer++ хранит все свои настройки в config.xml, а не в реестре (разумеется если ему это указать в настройках, что и сделано), и таким образом, он лучший кандидат на более чистое исследование установленного в контейнер софта, так как совсем не следит в контейнере, в котором сам работает. Приятным дополнением является его дружелюбный (привычный пользователю) фейс, очень схожий с фейсом проводника виндовс.
Собственно вот и ответ

P.S. Понимаю, что подобного никто не любит, но я пересобрал и перезалил сборочку. На сей раз песочница будет именоваться не:
Explorer++ v1_3_5_531 ДСП by AVanti_473
а просто
E++
(ссылка обновлена, двумя постами выше)
Думаю всем понятно, что это сделано дабы путь установки некоторых файлов не вылетал с ошибкой из-за слишком большого набора символов в названии пути. Простите меня за это, сразу не увидел, а во время тестов понял, что хоть длинный путь мне лично ни разу особо не помешал (так как стартую сборку почти с корня диска), но ведь может же в теории К данному времени 21 пользователь обзавёлся моей сборочкой, но в принципе и тот вариант и этот вполне рабочие, просто, если будут проблемы, то лучше этот, с коротким именем песочницы. Всё повторно обкатал и перепроверил, так что проблем быть не должно. И, пользуясь случаем - спасибо всем пользователям, что тестят подобный софт.

AVanti473

Цитата:

спасибо всем пользователям, что тестят подобный софт

Это тебе Спасибо (пробовал что-то подобное сделать, не получилось, множество программ не запускалось). Практически твоя сборка это Shadow Defender или Sandboxie (но над этими прогами трудятся команды программистов).

Подсобите решить такую, казалось бы, тривиальную задачу.

Есть папка с установленной программой, в которой пусковой .exe, библиотеки и другие необходимые для её работы файлы. Нужно сделать так, чтобы программа запускалась в реальной системе со своей папки, но данные реестра и некоторые другие файлы брала с портабельного формата *.dat (или другого) находящегося возле .exe программы. Т.е. тут нужна частичная портабелизация, но неясно как назначить обращение программы к портабельному файлу. Насколько понимаю, тут необходима скриптовая комбинация с ThinApp, так как должна оставаться возможность подключения портабельных плагинов.
Если кто-то разбирается в этом вопросе, просьба пояснить подробнее.

oplrox [more=Я как-то так понял...]Ничего себе тривиальная задачка... Упрощая Ваше высказывание, можно перефразировать так: Установленная программа должна в полной мере пользоваться ресурсами портабельной. Но это, на мой взгляд, невозможно. Во всяком случае в разделе по ThinApp. Дело в особенностях портабельной сборки. Портабельная программа взаимодействует с системой по своим правилам. Только в случае, если портабельной программе разрешено менять значения реального реестра, установленная программа увидит эти значения в реальном, системном реестре. В случае, когда портабельная программа пользуется виртуальным, изолированным реестром, обычная установленная программа никак не сможет получить в него доступ, так как читает только системный реестр. Соответственно, установленная на компьютере программа не сможет использовать и портабельные плагины. Хотя, если Вы программист, можете написать какой-то онлайнконвертер значений реестра из портабельного контейнера (файлы типа Registry.rw.tvr) в обычные ветки реестра (тем более алгоритм много раз описан и известен), ну и то условие, при котором нужный вам установленный софт увидит эти значения...
Допускаю комбинацию скрипта, конвертирующего периодически значения Registry.rw.tvr в ветки реального реестра, запись этих веток в реальный реестр с последующим отслеживанием и удалением записываемых данных, но тут как минимум ещё две проблемы:
1) Реестр иногда просто меняется, а удалять изменённые данные означает удалять и прежние значения, что приведёт к такой котовасе в системе... Значит нужны будут бекапы - ещё одна головная боль.
2) Пути записанные в реестр из портабельного приложения не будут совпадать с настоящими путями того самого портабельного приложения. То есть отконвертированные значения реестра будут утверждать, что портабельное приложение находится в программ файлс, тогда как разумеется оно стартует из своей собственной папки, а его положение в програм файлс виртуально - в реальности его там нет. Вот и посыпется ещё один ворох ошибок.
А вы говорите тривиальная задачка...
Кстати, oplrox а зачем вам такой подход? Приложения ведь всё равно по большей части взаимодействуют на уровне ассоциаций файлов, если конечно они не плагины...
[/more]

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

последняя версия проги стабильно работает? не глюкавая?
никто ничего случайно не заметел?

oplrox

Цитата:

Стараюсь добить этот вопрос, в ту или другую сторону.

Вы всё правильно поняли из моего ответа. Про вышеуказанный способ я уже читал ранее, так как переодически читаю содержимое этих страничек. Ваша задача в способе была противоположна поставленной сегодня задаче. Там был вынос плагина в реальную систему, когда сам Reaper портабельный. Данная задача выполнима, но по описанным Вами причинам не совсем удобна... Нынешняя задача, поставленная Вами увы не нова. Если поворошить странички данной темы, я думаю Вы найдёте подобный вопрос, затрагиваемый мною в отношении плагинов PSPaudioware к SONAR X2. Тогда, я даже пытался использовать штатную функцию создания .msi в ThinApp, но плагины всё равно остаются как бы в виртуале и SONAR их физически не видит. Ранее, я сам не совсем точно представлял себе процесс происходящего и его причины. Детальнее всё изучив, я пришёл к такому же выводу:


Цитата:

вижу что способа реализовать это нет

Но, тем не менее. Всё же это не значит, что об этом не надо думать! Мне кажется надо! Хотя бы в теории представить себе как это могло бы происходить, и что для этого необходимо. А необходим некий хаб, который бы обеспечивал соединение (взаимодействие) именно между реальным приложением и виртуальным, когда реальное является доминантным, а виртуальное плагином к реальному. Как реализовать такой "хаб" - вопрос?

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

Добавлено:
rooleg

Цитата:

последняя версия проги стабильно работает? не глюкавая?
никто ничего случайно не заметел?

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

Добавлено:
oplrox

Я решил Вашу задачку!

Сейчас вместе посмеёмся, но решение было практически под носом девятью постами выше. Всегда хорошо, когда задумываешься над последовательностью. Значит нужен был некий "хаб", который бы видел портабельный контейнер, а кто сказал, что он сам не может быть портабельным приложением? Вот собственно и ответ. Единственное требование, запускать хостовую (установленную на компе) студию через этот хаб и всё. Делайте к нему плагины VST-шек, подключайте, а если лень, просто инсталлируйте их сразу в этот "хаб" и вот вам вся частичная портабелизация. Поскольку все прелести псевдомоей разработки (виртуального контейнера для установки приложений) я ещё и сам не полностью успел опробовать, поэтому и ответ Вам смог дать не сразу, а только когда задумался о применении своей разработки к Вашей задачке.

P.S. Гы-гы, и сам теперь буду пользоваться - спасибо за полезный вопрос!

oplrox
Гляньте в сторону X-Launcher.

AVanti473
Не тратьте свое время. Тыц, тыц, тыц. Особенно умиляет "заметел".

coherent

Цитата:

oplrox
Гляньте в сторону X-Launcher

А смысл? Он всё равно не даст взаимодействовать с портабельным контейнером, его содержимым и виртуальным реестром... Впрочем, решение уже найдено, и даже опробовано, о чём я выше написал. X-Launcher конечно и есть частичная портабелизация на основе других принципов, но надо ещё уметь собирать на нём плагины. К тому же, VST-плагины не имеют точки запуска, а следовательно встанет вопрос о том, как в систему при помощи X-Launcher будут попадать звуковые VST плагины, а так же, когда именно они будут выгружаться из неё...


Цитата:

Особенно умиляет "заметел".

Понятно - спамбот, который позже (спустя пару страничек) рассчитывает отредачить пост заменив всё на ссылки каких-нить порносайтов для пущей индексации в поисковиках... Спасибо за подсказку.

Цитата:

Я решил Вашу задачку!

AVanti473, эх, какая бы радость была, но увы. Дело в том, что когда такой плагин запускается с виртуальной среды, неважно, будь то портабельный хост, проводник или какой-нибудь другой вход, вступают в силу ограничения виртуальной оболочки. Я этот способ проверил еще давно, причем много раз, на разных версиях ThinApp, и через разные проводники. К сожалению, не проходит.
По логике, вижу три выхода:
1. переписывать функции обращения в самих exe и dll, которые отправляют запросы в реестр и другие файлы, но вместо них это все будет перенаправляться в контейнер. Даже при наличии опыта программирования с каждой сборкой так мурыжиться - совсем нездраво.
2. возможно когда-то в новых версиях ThinApp, такой случай будет предусмотрен и станет доступно более расширенное взаимодействие виртуальной среды с реальной памятью. Будет ли? И когда? - Риторика.
3. и наконец)) появится новая версия плагина, которая будет нормально работать при обычной портабелизации (а такое уже было с несколькими). И опять - риторика.

А насчет хаба-моста тоже была мысль, но он должен сам быть не виртуальным, и уметь разговаривать на ты с ThinApp`овскими чадами. И тут все пути ведут к разработчикам.

coherent, с X-Launcher не доводилось иметь дело, вот разбираюсь что это.


Цитата:

Но, тем не менее. Всё же это не значит, что об этом не надо думать!

Хорошие слова, всеми и всями - ЗА, нерешаемые задачи чем не тренировка для ума, особенно если он в этом не уверен)

oplrox


Цитата:

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

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


Цитата:

Нужно сделать так, чтобы программа запускалась в реальной системе со своей папки, но данные реестра и некоторые другие файлы брала с портабельного формата *.dat (или другого) находящегося возле .exe программы. Т.е. тут нужна частичная портабелизация

Если не так, то я немного запутался и прошу прощения.
Что касается Вашего выбора VST плагина реверберации Acon Digital Verberate, то подобных ему море, и на мой взгляд даже более качественных.
MAGIX - Variverb
OverLoud - Brverb
Wave Arts - MasterVerb
Из последних неплохой 2CAudio - Aether
и т. д. и т. п. от лёгкого рефлектора до эха и хоруса. Всегда есть из чего выбрать, главное, чтобы это подключалось к оригинальной программе

AVanti473, верно, VST хватает, но если у вас будет время и желание, попробуйте запортабелить Lennar Digital - Sylenth1, любую версию начиная со 2-ой. Если возьметесь, могу скинуть портабельный хост (если нет в наличии), чтоб сэкономить время. Этот случай не единичный (уверен что у остальных такой же принцип), если получится, вопрос портабелизации VST можно считать решенным, насколько это вообще возможно.
PS. Acon Digitals брал вобщем для примера, а для ревера использую 2CAudio - Aether (очень хорош, но и аппетитный на ресурсы), плюс парочку простых - AriesVerb, RVB500, RoomVerb 2M2.

Цитата:

но если у вас будет время и желание, попробуйте запортабелить Lennar Digital - Sylenth1, любую версию начиная со 2-ой

Самое интересное в том, что Вы же уже решили вопрос портабелизации подобных плагинов с выносом их файлов скриптом в реальную систему, а затем удалением их следов тем же скриптом. Так что мешает уже готовый такой портабельный плагин по моей схеме (через портабельный "хаб") подключить к установленному хосту? (учитываем, что настройки изоляции плагина всегда приоритетней настроек портабельного приложения, в данном случае "хаба") Создавайте папку plugins рядом с екзешником портабельного "хаба", кидайте туда свой плагин, запускайте "хаб", через "хаб" хост, и ищите в хосте ваш плагин, он болжен быть там и работать в реальной системе...
Но, возможно я что-то не учёл. И, уж ради интереса, скинте в личку ссылку на указанные вами плагины, просто хочется взглянуть на них и попробовать в виртуальном контейнере. В свободное время конечно (надеюсь, такое найдётся)

Скинул в личку... В любом случае, спасибо.

Есть портированное в версии 5.0.1 приложение (x32), работает начиная с Windows 7, можно ли переделать порт этого приложения под Windows XP? Когда-то на оборот переделывал.

PRomanS

Цитата:

Есть портированное в версии 5.0.1 приложение (x32), работает начиная с Windows 7, можно ли переделать порт этого приложения под Windows XP?

Все зависит от конкретного приложения. Если снимок изначально делался в 7-ке и собранное приложение в ХР не работает, то проще всего сделать снимок в ХР и собрать по-новой. Сталкивался с таким. Легче сделать по-новой, чем искать, что ему не хватает для полноценной работы. Если, конечно, само приложение предназначено для работы в ХР.

coherent
Спасибо, я имел в виду нет ли каких либо штатных средств у ThinApp, для преобразования сборки из XP в 7 была команда для ThinApp. Пересобрать не могу, поскольку не я собирал.

PRomanS

Цитата:

для преобразования сборки из XP в 7 была команда для ThinApp

Здесь речь идет просто о перекомпиляции в более старших версиях ThinApp, которые поддерживают 7-ку. А то, что Вы хотите, это совсем другое.

coherent
Спасибо.

Люди, версия 5.1 не может сделать релинк с компрессией?

Поясню. Кажется, на данный момент релинк делается с учетом того, что параметры в исходнике называются так же и располагаются в тех же секциях, что и для версии релинка. Поэтому старые пакеты релинкаются, но без сжатия.

Пожалуйста помогите разобраться.

Делаю портативку RealPlayer 16 в ThinApp 5.1. После запуска портативки появляются зависшие процессы (realplay.exe, realsched.exe, rndlresolversvc.exe, RealUpgrade.exe). Добавляю в сборку скрипт для удаления зависших процессов:

Function OnFirstParentExit
ProcKill1 = ExecuteExternalProcess("cmd.exe /c taskkill /F /IM realplay.exe /IM realsched.exe /IM rndlresolversvc.exe /IM RealUpgrade.exe /T")
WaitForProcess ProcKill1, 0
End Function

В ThinApp 5.1 скрипт не работает, в ThinApp 4.73 работает.

Как переделать скрипт под ThinApp 5.1?

007Alex007

Цитата:

В ThinApp 5.1 скрипт не работает, в ThinApp 4.73 работает.

Давным-давно, когда все здесь ещё были маленькими (старожилы помнят), я подбирал для версии 4.0.0-2200 требуемый scripting.dll и всё работало. 100 лет уже этим не занимался (другие дела, другие проблемы), но можете попробовать...

Leon_Ko

Цитата:

подбирал для версии 4.0.0-2200 требуемый scripting.dll

Спасибо, что откликнулись на проблему, но можно по подробнее, как это сделать.
Я в составлении скриптов не силен (выше представленный скрипт добыт из просторов этого форума), а тем более в создании или написании scripting.dll.

007Alex007
Имелось в виду попробовать scripting.dll от других версий, например, от той же 4.7.3.
И убивать процессы, наверное, лучше используя функцию OnLastProcessExit.