Обнаружил странную вещь...
Есть простейший SFX на R-DriveImage (я все лишнее выкинул):
https://www.upload.ee/files/6714356/__Build_New.rar.html
Внутри:
- билдер (запускаем z_Pack_EXE.CMD, получаем .exe)
- два варианта 7zsd_LZMA.sfx (v160.3807 v161.3874)
- образ маленькой флэшки с одним файлом для монтирования
Если в билдер записать 7zsd_LZMA.sfx v161.3873 (уже там), получить .exe, запустить, выбрать монтирование - то оно происходит
очень долго
Если в билдер записать 7zsd_LZMA.sfx v160.3807, получить .exe, запустить, выбрать монтирование - оно происходит мгновенно
Ну, и все предыдущие версии до v160.3807 также работают быстро, все после v161.3873 - также медленно.
Разархивированные файлы, окружение, манифесты...все одинаково!
Дело не в данном примере...мало ли где это может выскочить.
Может, кто помнит, что там менялось при переходе с v1.60 на v1.61?
==============================================
Исходники я нашел на v160.3861 v160.3873 - проблема появилась между этими версиями.
Вот это поменялось: * Окна некоторых дочерних процессов отображались на заднем плане - проблема где-то здесь.
Но разбираться большого смысла нет, т.к. совсем не обязательно использовать ExecuteOnLoad.
Вариантов много, например, уже опробованные на R-DriveImage:
- распаковывать без InstallPath, потом все то же самое, только в RunProgram (с TaskKill).
- распаковывать с InstallPath и OverwriteMode=1 и делать флаг в виде пустого файла. Это вообще без TaskKill.
Тогда и старые версии 7zSFX можно использовать.
=============================================
Нашлось решение и для новой версии 7xSFX - запуск через start, чтобы отвязаться от "дурной" наследственности:
Код:
RunProgram="hidcon:waitall:cmd.exe /c start /wait /B /I R-DriveImage.exe"
Но...после многократного запуска проблемы опять начинаются.
Так что это проблемы больше самого R-DriveImage, как-то он хитро работает с драйверами.
Вопрос закрыт.
