» VMware ThinApp (formerly Thinstall) 3

007Alex007
Собственно, вам уже ответили. Я тоже не силён в написании скриптов, да и занимался Thinstall'ом последнее время n-лет назад. Просто подбирал в своё время под себя - тоже столкнулся с подобной проблемой. У меня вообще сложилось впечатление, по поводу этих scripting.dll, что ф-ции содержащиеся в них весьма вольно "плавают" от версии к версии. И - недокументируются. Возможно, где-нибудь на западных форумах...

Подмена scripting.dll в ThinApp 5.1 не сработала. Зато оказалось, что скрипт работает во всех версиях ThinApp (в том числе и в 5.01) кроме версии 5.1. Для себя понял что если не нужны функции x64, то лучше пользоваться версией 4.73.

coherent

Цитата:

лучше используя функцию OnLastProcessExit

В моем случае срабатывает именно OnFirstParentExit, а с OnLastProcessExit скрипт почему то вообще не запускается.

NickOnToluca
Это не про релинк, а про обычную компрессию в 5.1, много раз сталкивался с тем, что после компрессии (даже с обычной Fast) сборка запускается с ошибками, например FontExpert.

Добрый день. Решил сделать для себя портабельные версии используемых программ. Начал с программы WinDjView. Протестировал созданную сборку с помощью VMware ThinApp - она показывает, что изменения произошли только в песочнице. Поставил сканер реестра RegChange - он обнаруживает 29 новых записей в реестре после запуска, открытия файла и закрытия WinDjView. Поскольку я в реестре ничего не понимаю, не могу понять, относится ли эти ключи к программе или нет. Отсюда вопрос: стоит ли зацикливаться на этом, или отчета ThinApp будет достаточно? Заранее спасибо за ответы.

orion885
WinDjView - по сути своей портабельная программа, нет смысла её заталкивать в контейнер Thinstall. Её влияние на реестр минимально, если вообще это можно назвать влиянием .

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

orion885
Если Вы специально не предпринимали шаги для того, чтобы сборка делала записи в системный реестр, тогда программа ничего и не запишет туда. Поскольку по умолчанию глобальная изоляция WriteCopy, а изоляция на записи в реестре собственно портируемой программы - Full. Хотя, строго говоря, любой ехе-файл, в том числе и ехе-контейнер портативной сборки, оставляют при работе следы в реестре, что не есть крамолой.

Цитата:

Поставил сканер реестра RegChange - он обнаруживает 29 новых записей в реестре после запуска, открытия файла и закрытия WinDjView.

Он Вам отследил все, что в этот момент было запущено в системе.

Цитата:

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

А просто извлечь из инсталлятора только то, что нужно, а всякое г..., типа Яндекс-бара, там оставить, не проще?

Как заставить pdf-файл (как правило, руководство пользователя) запускаться в песочнице, при рабочей опции ChildProcessEnvironmentDefault=External ? Для запуска внутри контейнера (при рабочей ChildProcessEnvironmentDefault=External) справки или документов Micrоsoft Оffice добавляется ChildProcessEnvironmentExceptions=hh.exe;WINWORD.EXE;EXCEL.EXE;POWERPNT.EXE;OUTLOOK.EXE. Что нужно прописать для PDF ?

bumburbia
PDF-файл открывается программой по умолчанию, которая ассоциирована с расширением .pdf. Нужно ее добавить в ChildProcessEnvironmentExceptions= . Если я правильно понял вопрос.

coherent
Всё правильно, но программы по умолчанию для открытия PDF-файлов у всех разные, у меня, к примеру, Foxit Reader, у других - другие. Хотелось бы универсального решения.

bumburbia

Цитата:

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

А у меня PDF-XChange Viewer. И как объединить Foxit Reader и PDF-XChange Viewer? Единственное, что с ходу приходит на ум - это добавлять в сборку какой-то мини PDF-просмотрщик, типа Sumatra PDF, который будет ассоциирован с pdf в виртуальном реестре и который и будет собственно запускаться.
А что, если тот же Foxit Reader запуститься не в виртуальном контейнере, это не устраивает чем-то?

Добавлено:
Конечно все зависит от конкретной сборки. Но, в принципе, можно задать наоборот, ChildProcessEnvironmentDefault=Virtual, а в исключениях (ChildProcessEnvironmentExceptions=) задать те процессы, которые будут запускаться в системе. И поскольку Foxit Reader, PDF-XChange Viewer и др. не будут в исключениях, то они будут запускаться в виртуальном контейнере.

coherent

Цитата:

А что, если тот же Foxit Reader запуститься не в виртуальном контейнере, это не устраивает чем-то?

В сборке мне нужен работающий ChildProcessEnvironmentDefault=External и если не делать исключения для запуска PDF в контейнере, то сборка запускает Foxit Reader во внешней среде и FR ищет файл во внешней среде и, разумеется, не находит.

bumburbia

Цитата:

сборка запускает Foxit Reader во внешней среде и FR ищет файл во внешней среде и, разумеется, не находит

Не включил мозги в эту сторону.
В предыдущий свой пост добавил еще вариант.

Подскажите пожалуйста, как лучше сделать нужно в один portable файл засунуть 2 программы. Если конкретно cisco anyconnect и vmware view client, чтобы при старте запускались обе.

coherent
Этот вариант известен, неизвестны заранее те процессы, для которых нужно будет делать исключение, так сказать, придётся повозиться , но за пояснения - спасибо .
Ещё такой момент: дочерний процесс при запуске в контейнере ищет WINWORD.EXE, не находит и пытается установить со всякими предупреждающими окошками, вобщем, неприемлемый вариант. Если этот процесс запускать вне контейнера, то нужное окно открывается, а в диспетчере задач появляется ненужный WINWORD.EXE, который после закрытия и дочернего процесса и всей портативки остаётся висеть. Как бы от него (и подобных ему) избавиться ?

bumburbia

Цитата:

Если этот процесс запускать вне контейнера, то нужное окно открывается, а в диспетчере задач появляется ненужный WINWORD.EXE, который после закрытия и дочернего процесса и всей портативки остаётся висеть. Как бы от него (и подобных ему) избавиться ?

В принципе, всегда остается радикальный метод - убивать процесс (ы) скриптом при завершении работы сборки. В теме пару раз выкладывался скрипт на WMI. Если не напрягает консольное окно, то можно через taskkill.

coherent
Консольное окно - не есть хорошо ), но главное, в данном случае процесс WINWORD.EXE как бы и не является дочерним, если, к примеру, во время запуска дочернего процесса портативки открыт Word, то дочерняя программа запускается без появления дополнительного WINWORD.EXE в диспетчере задач. И ещё, сколько раз запустишь этот дочерний процесс, столько и появится WINWORD.EXE в диспетчере задач, а с открытым Word'ом не появится вовсе. Сможет скрипт убивать этот, на мой взгляд, не совсем дочерний процесс (ы) ?

bumburbia

Цитата:

Сможет скрипт убивать этот, на мой взгляд, не совсем дочерний процесс (ы) ?

Так скрипту как-бы все-равно, что убивать. Указать имя процесса и он не будет разбираться, дочерний это процесс или вообще чужой, никак не связанный со сборкой. Грохнет, и все!
А что за программа, если не секрет? Fine Reader, PDF Transformer...?

coherent
Под рукой этого скрипта нет ? А программа PROMT.

bumburbia
Попробуйте такой:

Код: Function OnFirstParentExit
Dim objWMIService, objProcess, colProcess
Dim strComputer, strProcessKill
strComputer = "."
strProcessKill = "WINWORD.EXE"
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colProcess = objWMIService.ExecQuery ("Select * from Win32_Process Where Name = " & strProcessKill)
For Each objProcess in colProcess
objProcess.Terminate()
Next
End Function

coherent
Благодарю, попробую.

Добавлено:
Скрипт, на сколько я понимаю, можно просто запустить из любого места и он убьёт этот процесс или он должен находиться внутри сборки ?

bumburbia

Цитата:

Скрипт, на сколько я понимаю, можно просто запустить из любого места и он убьёт этот процесс или он должен находиться внутри сборки ?

Такое ощущение, что вы лепя свои портаблы, до сих пор не понимаете, что делаете
Шапку хотя бы читали? Мануал от vyachko, его более поздние перепевки от Astra55?

bumburbia

Цитата:

Скрипт, на сколько я понимаю, можно просто запустить из любого места и он убьёт этот процесс или он должен находиться внутри сборки ?

В таком виде, как он приведен, скрипт помещается в сборку и автоматически запустится при завершении ее работы.

Leon_Ko
Спите спокойно, я знаю, что делаю, а если не знаю, то спрашиваю, уточняю. Мануалы из шапки не дают ответа на все вопросы и для этого существует форум.

bumburbia

Цитата:

...я знаю, что делаю

С трудом в это верится судя по вашим вопросам

Leon_Ko

Цитата:

С трудом в это верится

Это ваши проблемы, мне они не интересны.
coherent
К сожалению, скрипт не сработал, только удвоил процессы запущенной сборки.

bumburbia

Цитата:

К сожалению, скрипт не сработал, только удвоил процессы запущенной сборки.

Скрипт не может удвоить количество процессов сборки. Не думаю, что я что то напутал в скрипте, надеюсь по крайней мере, но для уверенности пройдитесь поиском в теме по какой-то фразе из скрипта, например, strComputer = ".". Для полной уверенности.
И на всякий случай, Вы весь текст скрипта скопировали в текстовый файл, сохранили его с расширением .vbs, типа kill.vbs, и положили его в корень сборки рядом с Package.ini?

coherent
Всё именно так, проглядел сначала вот это окошко при запуске, оно и дублировало запущенный процесс

bumburbia
Странно, это же рабочий скрипт. Почему он выкидывает ошибку?
На всякий случай, " Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")" - это одна строка. И "Set colProcess = objWMIService.ExecQuery ("Select * from Win32_Process Where Name = " & strProcessKill)" - это тоже одна строка. Кстати 7-я, в которой якобы ошибка.

coherent
Скрипт запускается без ошибки, если в строке strProcessKill = "WINWORD.EXE" название процесса заключить ещё в одни кавычки - "'WINWORD.EXE'", но, увы, завершает процесс при запуске сборки (если открыт Word - прибьёт), а при закрытии - молчок, тот же эффект и с этим скриптом

Код:
Function OnFirstParentExit
Dim objWMIService, objProcess, colProcessList
Dim strComputer
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" _
& strComputer & "\root\cimv2")
Set colProcessList = objWMIService.ExecQuery _
("Select * from Win32_Process Where Name = 'WINWORD.EXE'")
For Each objProcess in colProcessList
objProcess.Terminate()
Next
End Function

bumburbia

Цитата:

завершает процесс при запуске сборки

Это что-то из области фантастики! Ведь по определению функция OnFirstParentExit срабатывает при завершении родительского процесса (ов). Да и с дополнительными кавычками мне не понятно.
Для чистоты эксперимента можно добавить в скрипт вывод сообщения, типа MsgBox "Bla-bla-bla", и посмотреть, когда оно будет появляться. Потому что я не представляю, как функция OnFirstParentExit может сработать при запуске сборки!