» VMware ThinApp (formerly Thinstall) 3

Цитата:

Ведь можно же как-то побороть эту проблему?

Юзайте VHD-динамический+VHD-дифференциальный. Все изменения будут сохраняться в дифференциальном, а основной VHD изменяться не будет. Или я не понял о какой вы проблеме?

Цитата:

Юзайте VHD-динамический

Мне год назад на одном форуме дали ещё такой полезный совет:


Цитата:

насчёт VHD наберите в Гугле Stea VHD, там хватает ресурсов, где они выложены и всё подробно растолковано

по поводу:


Цитата:

UWF присутствует в линейке Windows Embedded с возможностью использовать не только оперативку, но и запись в файл UWFSWAP.sys.

Вообще-то я имел в виду: EWF

А в целом, много информации здесь: Windows на USB HDD

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

Пытаюсь собрать сборку одной программы, там есть кнопка для перезапуска программы от имени админа. Для запуска с повышенными привилегиями используется метод перезапуска приложения посредством ShellExecuteEx с глаголом runas. Для получения имени исполняемого файла используется функция GetModuleFileName, которая должна возвращать настоящее имя файла. В непортативной версии она возвращает корректное имя - и это имя передается в ShellExecuteEx. В портативке она возвращает путь к файлу, где он лежит виртуальной среде (то есть тот путь, где он лежал будь программа штатно инсталлированная). А так как для физической среды этот путь является несуществующим поэтому ShellExecuteEx не отрабатывает. Это можно как-нибудь исправить настройками проекта?

regist123
Глава 9 справочника по параметрам Package.ini. Может, это поможет.

pavlaf если вы о принудительном запросе на повышение прав при запуске сборки (параметр UACRequestedPrivilegesUIAccess ), то это не то. Программа отлично в общем-то работает и без прав админа, но в ней есть кнопка для перезапуска от имени админа. Вот хочется заставить работать и эту кнопку и заодно и для себя лучше разобраться в ThinApp.
А если вы имели что-то другое, то пожалуйста, поясните что именно.

Подскажите, плиз, как решить.

Ставлю ПО, которое вносит изменения в файл "hosts" Windows.
Как сделать правильно так, чтобы при запуске портированной программы этот файл брался из нее (исправленный), а нет тот что находится на реальной системе?
В файле "hosts" прописывается блокировка определенных сайтов, куда портированной программе лезть нельзя.

Спасибо.

Цитата:

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

1) Есть проверенный вариант полного отключения портабельной программы от инета. (но он не подходит для блокировки отдельных сайтов).

Цитата:

В фаил HKEY_LOCAL_MACHINE.txt внести запись:
isolation_full HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip

Автор решения Meoow (May 1, 2010)
2) В виртуальном реестре сообщить портабельной сборке искать фаил "hosts" в другом месте (в другой папке), где будет лежать исправленный. (но этого я не тестировал, знаю лишь по советам).

AVanti473
Полное отключение устроит. Щас проверю. Спасибо.

Lovec
Этот уже давно проверенный способ

С выходом в Инет вроде все норм. Не лезет.
Теперь борюсь с подзависшими процессами после закрытия портативной программы. Точнее с одним.

Создал файл vbs, в нем код:

Код: Function OnFirstParentExit
ExecuteExternalProcess("cmd.exe /c taskkill /F /IM " & chr(34) & "Adobe Dreamweaver CC.exe" & chr(34) & " /T")
End Function

Lovec

http://forum.ru-board.com/topic.cgi?forum=5&topic=31117&start=3440#14

Цитата:

из чего понятно, что выставляя full на пустую ветку с tcpip, любой процесс виртуализированного приложения окажется один на один с не сконфигурированным tcpip, т.е. без сети

fram
Я понял, понял что так портативка сети не получит. Спасибо, еще раз

По убиению процесса, что описал выше, никто не подскажет? Что он у меня не убивается? ...

Цитата:

По убиению процесса, что описал выше, никто не подскажет?

Чтобы видеть в диспетчере задач реальные процессы, а не процесс точки входа нужно добавить в package.ini в раздел [BuildOptions] следующую запись:
ProcessExternalNameBehavior=Original

Чтобы определить зависший процесс, понадобиться программа Sysinternals Process Explorer в поиске которой "Find -> Find Handle or DLL (Ctrl+F)" нужно ввести:
.rw
Таким образом, будут найдены все процессы, блокирующие программу.

И, в заключении, скрипты для убийства процесса:


Код: Function OnFirstParentExit
Dim objWMIService, objProcess, colProcess
Dim strComputer, strProcessKill
strComputer = "."
strProcessKill = "’ieuser.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

AVanti473
Спасибо за исчерпывающий ответ. Не все понял, но возьму на заметку.

Сегодня моя программа уже как-то по другому ведет себя.
Вчера реагировала на оба события - и на OnLastProcessExit и на OnFirstParentExit.
Т.е. в скрипте у меня была всего одна строчка на тест:
msgbox "!!!"
Когда вставлял ее в Function OnFirstParentExit - скрипт срабатывал кучу раз, начиная от запуска, заканчивая выходом из программы.
Когда вставлял ее в Function OnLastProcessExit - срабатывал один раз, при выходе.

Сегодня на OnLastProcessExit вообще не реагирует, на OnFirstParentExit срабатывает один раз при выходе.
Что за бред??

Ладно. Пробую использовать для убийства процесса пример на WMI что вы дали выше и запихиваю такой код в OnFirstParentExit:

Код: Function OnFirstParentExit
strComputer = "."
msgbox "1"
strProcessKill = "'Adobe Dreamweaver CC.exe'"
msgbox "2"
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
msgbox "3"
Set colProcess = objWMIService.ExecQuery ("Select * from Win32_Process Where Name = " & strProcessKill )
msgbox "4"
For Each objProcess in colProcess
objProcess.Terminate()
    msgbox "!!!"
Next
msgbox "готово"
End Function

Цитата:

В общем я четко знаю какой процесс мне надо убить, знаю как это сделать на VBS, но скрестить VBS и ThinApp - никак...

Бегло прочитал, тороплюсь, тоже не всё понял. Давайте ещё раз попробуем так:
Ставьте в package.ini в раздел [BuildOptions] следующую запись:
ProcessExternalNameBehavior=Original
Временно, поместите в сборку такой скрипт:

Код: Function OnFirstSandboxOwner

strMessage = "OnFirstSandboxOwner: " & GetCurrentProcessName
MsgBox(strMessage)

End Function

Function OnFirstParentStart

strMessage = "OnFirstParentStart: " & GetCurrentProcessName
MsgBox(strMessage)

End Function

Function OnFirstParentExit

strMessage = "OnFirstParentExit: " & GetCurrentProcessName
MsgBox(strMessage)

End Function

Function OnLastProcessExit

strMessage = "OnLastProcessExit: " & GetCurrentProcessName
MsgBox(strMessage)

End Function

strMessage = "OnEveryProcess: " & GetCurrentProcessName
MsgBox(strMessage)

coherent


Цитата:

У Вас в скрипте ошибка. Похоже должно быть так:

Вы не правы. Тут формируется и передается строка, а вы внутрь строки запихали переменную - т.е. она не будет использоваться как переменная, а просто пойдет как часть строки " = strProcessKill".
Кроме того скрипт проверен не раз простым запуском - он работает и выполняет свою функцию - убивает указанный процесс.


Цитата:

Путь к Adobe Dreamweaver CC.exe должен быть полным.

Снова ваша неправда. Стоит посмотреть справку по этой команде. Так четко написано "имя образа процесса". И примеры есть.



Добавлено:
AVanti473
Сделал как вы написали. Добавил строчку "ProcessExternalNameBehavior=Original".
Какие процессы блокирует папку с портативной программой я контролирую прогой Unlocker.
До внесения изменений после закрытия программы она показывает следующие открытые процессы:

После добавления вашей строки уже другие процессы:


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

Lovec
Это не мои посты!!!
У нас тут есть умелец, которого никак не вычислим и который развлекается, заходя под чьим-то логином на форумы. И это не первый раз. Люди из-за этого имели уже большие проблемы.

По сути. Естественно, как с taskkill, так и с WMI - это стандартные рабочие скрипты. И в теме они уже не раз выкладывались Лично я чаще использую taskkill, т.к. консольное окно для меня не проблема. И пока ни разу не сталкивался, чтобы процес не удавалось убить, что одним, что вторым способом.

Таки повезло, что "мои" посты были без ругательств и оскорблений!

Lovec

В первом, представленном Вами скриншоте (без строки "ProcessExternalNameBehavior=Original") все процессы программы маскируются под процессы портабельного контейнера.
После добавления строчки, мы видим оригинальные процессы программы так, как будто она не находится в портабельном контейнере, а работает как установленная на компе. Разумеется мы видим и процесс екзешника портабельной сборки, наверняка он чуть выше места, заснятого во втором скрине, но он нам уже не нужен. Я не супер специалист в этом деле, но предположил бы, что нужно вписать в скрипты убиваемых процессов:
adobe_licutil.exe
CEPServiceManaqer. exe
LogTransport2.exe
Если конечно именно они остаются висеть, после завершения портабельной программы. Смущает:
svchost.exe
Но, может быть, при закрытии вышеперечисленных процессов, он сам отомрёт?...

Таким образом, я бы попробовал бы такую нелепую конструкцию:

Конечно же оставляем строку ProcessExternalNameBehavior=Original и вставляем в сборку фаил скрипта, например такой:


Код: 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 = 'adobe_licutil.exe'")
For Each objProcess in colProcessList
objProcess.Terminate()
Next
End Function

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 = 'CEPServiceManaqer. exe'")
For Each objProcess in colProcessList
objProcess.Terminate()
Next
End Function

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 = 'LogTransport2.exe'")
For Each objProcess in colProcessList
objProcess.Terminate()
Next
End Function

Только что попробовал 5-ю версию программы. Впечатления только негативные. На одной и той же программе работала на порядок дольше чем 4.7 и образ создала на 300 МБ больше чем 4.7. (у 4.7 образ получился около 700 метров, у 5-й версии около 1ГБ - это все с включенной компрессией)

Мне интересно ваше мнение по 5-й версии.

AVanti473
Я понял насчет процессов отображаемых с помощью строки "ProcessExternalNameBehavior=Original".
Какие мы видим названия процессов - не важно. Скрытые или настоящие... Один фиг и те и другие зависают после закрытия программы. А поскольку без использования строки "ProcessExternalNameBehavior=Original" я вижу блокирующих процессов меньше (пусть и на самом деле внутри одного процесса прячутся многие), то и убивать их легче.
Поэтому раз разницы нет - "зачем платить больше".
Для себя решил - не использовать эту строку. Но за знания спасибо)

Скрипт написать для меня не проблема (в том числе объединить предложенные вами в один).
Моя то проблема в том что процессы в принципе не убиваются скриптом. Ни с использованием WMI, ни с использованием taskkill.
Щас буду читать справку по программе и продолжу эксперименты. Должно же оно как то убиваться! Наверняка какая то простая херня во всем виновата. Найдем...

Собираю портативное приложение и внутри него есть VBS, который содержит такой код:

Код: Function OnFirstParentExit

Dim WshShell
set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.Run "taskkill /F /IM " & chr(34) & "Adobe Dreamweaver CC.exe" & chr(34) & " /T"
msgbox "готово"

End Function

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

Lovec

Цитата:

При попытке запуска внешнего VBS скрипта...тоже ошибка:

Запускайте vbs-файл не напрямую, а через WScript.exe.
Хотя должно работать и напрямую. Но путь к vbs-файлу должен быть полным.
Такой скрипт:

Function OnLastProcessExit
Dim WshShell
set WshShell = CreateObject("WScript.Shell")
WshShell.run "taskkill /F /IM MyProcess.exe /T"
WshShell.run "D:\...\Proba.vbs"
End Function

отрабатывает нормально (т.е. и taskkill прибьет MyProcess.exe и запустится внешний Proba.vbs), но при условии, что задано
ChildProcessEnvironmentDefault=External

Не знаю почему, но конструкция
set WshShell = WScript.CreateObject("WScript.Shell")
под ThinApp не прокатывает.

AVanti473
Удалось ли решить проблему с "хитрым" ключем в реестре?

Цитата:

Удалось ли решить проблему с "хитрым" ключем в реестре?

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

Здравствуйте. Вопрос к знатокам и не только.
Есть такая программа, как Duplicate Cleaner, которая может работать как в Win x86 так и Win x64. Но, если собрать эту прогу через ThinApp (5.0.1, 5.1.0), то эта самая прога запускается только в версии x86 и ни в какую не хочет запускаться в x64. Устанавливал и запускал ThinApp на Win x86\x64, безрезультатно.
Пробовал параметры Package.ini по умолчанию и с изменением:
[BuildOptions]
LargeAddressAware=1
Wow64=0

В чем может быть причина?

P.S. Если собрать сборку в Spoon или даже в Cameyo то все работает.

007Alex007
На 4-й версии не пробовали собирать? Мне 5-я показалась сильно глючной и вернулся к 4-й.

А четвертая версия разве поддерживает x64?

Цитата:

А четвертая версия разве поддерживает x64?

Нет, не поддерживает виртуализацию х64 битных приложений. С другой стороны, что касается х86, возможно версия 4.7.3 самая безглючная. Если нет необходимости виртуализовывать приложения х64, то работаю исключительно на ней. Даже последнюю свою поделку на версии 4.7.3 делал.

007Alex007 вы указали виндовс, но не указали какая версия винды? Так же непонятно, программа работает в 64 битной системе, но является ли исключительно х64 битным приложением? Если программа инсталлируется в виндовс х86, то Вы вполне можете использовать ThinApp v4.7.3 для её виртуализации.