[ya158]

Ж.Д.А.Л.К.Е.Р., Victor_Man,
Некоторые размышления по-поводу
1. Предотвращения повторного запуска инсталлятора. Создание какого-либа файла типа z1_KillTask.cmd вообще не требуется. Строка типа

Код:

ExecuteOnLoad="hidcon:cmd /c FOR /F \"Tokens=1,2\" %I IN ('\"TASKLIST|FINDSTR /BILC:\"%%M\"\"') DO SET /A N+=1&Set PID=%~J&FOR /F \"Tokens=*\" %k IN ('cmd /v:on /C IF !N! GTR 1 ECHO !PID!') DO TASKKILL /F /T /PID \"%k\""

поможет в нелегком деле предотвращения поторного запуска. Также можно добавить выскакиваюшее оклшко с информацией о том, что инсталятор запущен дважды и вторая копия сейчас тасккиллится. У меня такая строка добавляется автоматичеки. Как это делается можно посмотреть здесь.

2. Хорошая идея проверять и удалять инсталляцию, которая по какой-то причине покрашилась. Но что-то не хочется для этого перезагружаться (я по поводу ключа в RunOnce) - ведь инсталляция может прерваться не только из-за вольной или невольной перезагрузки компьютера. Также лично мне не нравится создание в архиве с программой каких-либо дополнительных файлов (я имею в виду z3_Stop.cmd). Помимо этого в этот файл (z3_Stop.cmd) надо занести всю информацию для полной деинсталляции приложения, хотя инсталляция может быть прервана задолго до конца и полная деинсталляция может оказаться избыточной. Но и не это так важно (влиять должно только на время деинсталляции), как, например, то, что при инсталляции ключи реестра могут не просто добавляться/удаляться, а изменяться. В этом случае заранее не известно какое значение ключа реестра было до инсталляции, и, соответственно, что должно быть в реестре после деинсталляции.
Отсюда вывод - данные для инсталляции необходимо создавать динамически в самом процессе инсталляции. Причем эти данные можно использовать не только для восстановления системы после неудачной инсталляции, а и просто для обычной деинсталляции впоследствии.

Чтобы не быть голословным опять же приведу в пример свой Конструктор инсталляторов на основе 7z SFX. Инсталляторы, созданные с его помощью, в процессе установки формируют файл UnCom.~ в папке с программой. В этот файл записывается все, что делает инсталлятор, в том числе и изменяемые параметры реестра. После установки в реестре создается ветка для деинсталляции программы с помощью стандартного апплета Установка и удаления программ, а команда для деинсталляции использует данные из UnCom.~, которые записываются в реестр, сам файл UnCom.~ после этого удаляется. Так вот, если перед распаковкой программы UnCom.~ будет находится в папке, в которую должна будет установиться программа, то после окна предупреждения команды для деинсталляции из него будут выполнены, удалена папка с программой и процесс инсталляции таксккиллится.

[sov44]

Можно чуть сократить код

Код:

ExecuteOnLoad="hidcon:cmd /c FOR /F \"Tokens=1,2\" %I IN ('\"TASKLIST|FINDSTR /BILC:\"%%M\"\"') DO SET /A N+=1& cmd /v/c IF !N! GTR 1 TASKKILL /F /T /PID \"%J\""

[ya158]

sov44,
Я знаю. Просто я ещё добавляю окно с информацией и там приходится городить второй цикл For. Я привел код в качестве того, что можно не создавать доп файл.

[Victor_Man]

Цитата Ж.Д.А.Л.К.Е.Р.:
В справке по модифицированному модулю смотрим раздел "Файл конфигурации": »
Ну, это то я все знаю прекрасно...но оно проблемы не решает.
В ДЕЙСТВИТЕЛЬНОСТИ ВСЕ НЕ ТАК, КАК НА САМОМ ДЕЛЕ
Слэш то в переменной и с ним ничего нельзя сделать.

Вот пример.
У разных юзеров назначен %TEM% так:
%TEMP%=C:\Temp - вариант 1
%TEMP%=C:\Temp\ - вариант 2 (т.е. с концевым флэшем - такое встречается, хотя и не слишком часто)
и в конфигурационном файле 7zSFX записано:
InstallPath="%TEMP%\\PathProg"
RunProgram="Program.exe"
В варианте 1 7zSFX будет искать программу здесь: %TEMP%\PathProg\Program.exe - он успешно ее найдет и запустит
В варианте 2 7zSFX будет искать программу здесь: %TEMP%\PathProg\\Program.exe - и он ее не найдет (!)
А вот если доверить вопрос поиска cmd.exe, то все в порядке:
RunProgram="cmd /c Program.exe"
Также отработает правильно и такая строка:
RunProgram="waitall:Program.exe" (видимо потому, что в этом случае используется вызов через cmd.exe)
====================================
Короче, дольше писать - вот сделал за три минуты три примера.
https://www.upload.ee/files/6659834/...lPath.rar.html
Запустите в каждом zz_Start.CMD и посмотрите результат.
Я писал именно об этом. О том, что мы не можем всех заставить поубирать слэши из TEMP.
Ну, остается вариант сказать сами виноваты...либо писать cmd /c или waitall.
====================================================
Разбираться стал, когда стали сообщать: Сборка не работает, не запускается даже!!! Одна, другая...- совершенно разные.
После разборок - вот она причина, %TEMP% со слешем.
Кстати, этим грешат "старые волки", которые DOS еще помнят, а там %TEMP% со слешем был почти за правило.
Видимо, с тех пор Windows и обрабатывает эту ситуацию, чтобы не было коллизий.

[Victor_Man]

ya158
Ну, чем больше вариантов - тем лучше, есть из чего выбрать
Без командного файла - это хороший вариант, в принципе.
Я не делаю сложных проектов, поэтому стараюсь делать из простых элементов.
Ну, и также размышления:
Я остался на варианте с файлом, который вторая копия запускает из разархивированной первой.
Соответственно, при запуске первой копии такого файла нет вообще (т.к. не было еще разархивации).
Дело в том, что я вдруг сделал SFX на AusLogic Disk Defrag, а он при запуске загружает систему до 100%.
И...с удивлением обнаружил, что при такой нагрузке бывают сбои в TaskKill - и второй процесс тоже запускается!
Особенно, если кликнуть еще пару раз для тестирования. Я стал тестировать, запуская сборки из .cmd по 5 штук
Понятно, что такого не может быть реально, но захотелось "разобраться досконально".
Вспомнил молодость с отладкой задач в реальном времени, с логами.
Выяснил, что иногда последний PID не свой, т.е. задачи убивают друг друга, вот тут и могут быть проблемы.
А вот если запрашивать не последний процесс, а PID родителя через WMIC, то там получается всегда свой PID.
Но там что-то все так медленно ворочается - я от варианта c WMIC отказался.
Одним словом, самый устойчивый оказался именно вариант с файлом, который вторая копия запускает из разархивированной первой.
Но еще раз - это все для запредельных вариантов, которые в жизни не встретятся...
===================================================
Добавил альтернативный вариант z1_KillTask.cmd (на WMIC/TaskKill вместо TaskList/TaskKill) - в принципе то он рабочий.
http://forum.oszone.net/post-2688624.html#post2688624

[CryptoNick]

Victor_Man, Со сторонними утилитами, выложенными в теме ранее, не хотите попробовать продолжить эксперименты?

[Victor_Man]

CryptoNick, какие имеются в виду?
А, tasktool...ну, гляну, может.
С убиванием непонятки были - на каждое нормальное завершение taskkill (0) приходилось аж 3 ошибочных (128)...
=======
Хотя, для нашего случая (единичный повторный запуск) все описанные решения через taskkill вполне рабочие, так что это уже не в тему, пожалуй.

[CryptoNick]

Еще как в тему... Как я писал, в WinPE может и не быть taskkill и tasklist

[ya158]

Я не делаю сложных проектов, поэтому стараюсь делать из простых элементов. »

Я и не говорю, что SFX 7-zip предназначен для сложных проектов. Например, установить AkelPad с нормальной заменой Блокнота гораздо проще с помощью nsis.
Я сделал свой Конструктор для упрощения составления файла конфигурации (чтобы не акцентировать свое внимание на правильности синтаксиса файла конфигурации - там слеш не задвоил, тут кавычки не заэкранировал) и для наиболее корректной деинсталляции, т.к. сам модуль SFX в явном виде не дает инструментов деинсталляции. Предотвращение повторного запуска удаление прерванной установки лично для меня не столь интересны, как, например, закрепление программы на панели задач с правами администратора или даже просто присвоение прав администратора ярлыку, созданному с помощью модуля.

Выяснил, что иногда последний PID не свой »

А чей же тогда PID? У двух процессов одинаковый PID?

А вот если запрашивать не последний процесс, а PID родителя через WMIC »

Недопонял - PID какого родителя?

Еще как в тему... Как я писал, в WinPE может и не быть taskkill и tasklist »

Ну ради таких WinPE таскать в дистрибутиве дополнительный файл - это как-то.... Если я не ошибаюсь, то taskkill/tasklist просто файлы. Тогда проще на той же флешке, где находятся инсталляторы иметь taskkill/tasklist, а в инсталляторах для этого случая организовать добавку пути к taskkill/tasklist в Path. А еще проще вставить в такой WinPE taskkill/tasklist.... Да и вообще - представим очень маловероятный сценарий: Запустили WinPE и обнаружили, что в оси нет необходимой, уже проинсталлированной, программы - решили установить и случайно запустили установку дважды. Ещё более маловероятно, что такая двойная установка что-то накосячит в WinPE или в самой программме, но и в этом случае можно просто перезагрузиться и снова аккуратно проинсталлировать нужную программу...

[CryptoNick]

ya158,

Я сделал свой Конструктор для упрощения составления файла конфигурации

Ну не знаю, как упрощение.... Я в нем так и не разобрался... Как и в кнопке gora
И таких как я много...
Как альтернативу, всему мудреному, заумному, написал свою программу...

Ну ради таких WinPE таскать в дистрибутиве дополнительный файл - это как-то....

Одна утилита весит два килобайта, другая 8 килобайт.
Можно использовать первую... А вес у нее почти такой же как у батника-убийцы дубликата.

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

Если извлекать в определенную папку, и потом, после окончания работы, само удалять данную папку...
При повторном запуске проекта и его закрытии, все не заблокированные файлы первого проекта, удаляются.
И если первому, они понадобятся, то будет ошибка...