Bug 816

wine start example.bat

Вопрос в том, что нельзя в консоли сделать wine example.msi, а в винде в cmd можно.

В виндовом cmd (и наверняка через CreateProcess тоже?) можно запустить напрямую файлы с расширением bat, cmd, msi:
C> test.msi

В вайне так не работает и приходится запускать через start (то есть ShellExec используется для вызова обработчика файла).

Вообще в wine есть код, который проверяет расширение у файла и если это .exe, .com  , то идёт одна обработка, а все другие отваливаются. 

Наверное проще всего будет сделать хак, который при получении .bat и .msi перезапускал этот код, но с программой start, посылая ей на вход имя пакета.

Возможно в Windows обработка bat/cmd/msi сделана на той же основе, что и com/exe, поэтому надо сделать аналогично, и это будет не хаком.
Проверяется просто - в винде эти файлы должны исполняться с использованием cmd.exe (или указанным в COMSPEC интерпретатором?), вне зависимости от ассоциации расширения с программой (используемого в ShellExec).

Как я понял из msdn, напрямую из CreateProcess() незная тип файла всё-таки запускать нельзя.
Чтобы через CreateProcess() запустить .bat файл нужно в lpApplicationName передать  cmd.exe, а в lpCommandLine передать /с плюс имя файла

т.е по сути мы вызываем комманду cmd.exe x.bat

Проблема в том, что в Wine в cmd.exe не работает передача параметров через коммандную строку.
Т.е при выхове "wine cmd.exe x.bat" просто открывается сmd, но имя файла в качестве параметра ему не передаётся

(In reply to comment #6)
> Как я понял из msdn, напрямую из CreateProcess()
> незная тип файла всё-таки запускать нельзя.
> Чтобы через CreateProcess() запустить .bat файл
> нужно в lpApplicationName передать  cmd.exe, а в lpCommandLine
> передать /с плюс имя файла
> 
> т.е по сути мы вызываем комманду cmd.exe x.bat
> 

Возможно стоит посмотреть SHELL_FindExecutable(..), а так же как и где она используется. Это может помочь.

(In reply to comment #7)

> Т.е при выхове "wine cmd.exe x.bat" просто
> открывается сmd, но имя файла в качестве
> параметра ему не передаётся
Только что проверил под Windows - там тоже откроется только cmd, а батник запускаться не будет.

Думаю, что не надо для таких целей использовать cmd. Надо использовать минимум start. 

А start из панели "выполнить" не работает. Зато если зайти в cmd и там сказать start 1.bat, то откроется ещё одно окно с cmd и выполниться там батник.

Работает, только там есть ещё опция /с.
Если набираешь "сmd c:/test.bat", то не работает, а если "сmd /c c:/test.bat" то уже работает. 

(In reply to comment #11)
> Работает, только там есть ещё опция /с.
> Если набираешь "сmd c:/test.bat", то не работает, а
> если "сmd /c c:/test.bat" то уже работает. 
> 

Гм, а ключ /c в Wine-ском cmd реализован? :)

В wine из коммандной строки тоже работает!
Надо ещё проверить через CreateProcess()

CreateProcess() работает наполовину.

Т.е если передавать как написано в MSDN: lpApplicationName = "cmd.exe"; lpCommandLine = "/с x.bat", то не работает. С помощью GetLastError можно можно отловить ошибку: файл не найден.

если же передавать lpApplicationName = NULL; pCommandLine = "cmd.exe /с x.bat", то всё прекрасно работает.

Проверил в WinXp
Странно, но всё работает также.
Видимо ошибка в MSDN.
Написано одно:
To run a batch file, you must start the command interpreter; set lpApplicationName to cmd.exe and set lpCommandLine to the following arguments: /c plus the name of the batch file.
А на деле получается совсем другое

(In reply to comment #15)
> Проверил в WinXp
> Странно, но всё работает также.
> Видимо ошибка в MSDN.
> Написано одно:
> To run a batch file, you must start the command interpreter; set
> lpApplicationName to cmd.exe and set lpCommandLine to the following arguments:
> /c plus the name of the batch file.
> А на деле получается совсем другое
> 
Так часто бывает. Можно написать тест и в комментарии к тесту указать, что этот тест показывает отличие реализации от того, что заявлено в документации.

1. Ну что вы говорите, у cmd должен быть специальный параметр (вроде /P), который говорит что надо запустить батник.
2. Существует переменная окружения COMSPEC, задающая действующий командный интерпретатор.
3. Безусловно, все bat- и cmd-файлы выполняются через cmd.exe, поскольку это его назначение.

Что-то я стормозил с комментарием, но тем не менее:
в нормально документации написано, что передавать надо
lpApplicationName = "cmd.exe"; lpCommandLine = "cmd.exe /с x.bat"

(командная строка должна включать в себя и название команды)
А ApplicationName - так, для справки.

(In reply to comment #18)
> Что-то я стормозил с комментарием, но тем не
> менее:
> в нормально документации написано, что
> передавать надо
> lpApplicationName = "cmd.exe"; lpCommandLine = "cmd.exe /с x.bat"
> 
> (командная строка должна включать в себя и
> название команды)
> А ApplicationName - так, для справки.
> 

Т.е получается что проблема с .bat-файлами только в MSDN документации, а в wine всё работает как и должно работать.

Осталось только проверить работает ли CreateProcess() с *.msi

wine cmd /c web.msi
Результат:
Bad format

(In reply to comment #20)
> wine cmd /c web.msi
> Результат:
> Bad format
Что логично. Никаким боком cmd не имеет отношения к исполнению msi-сценариев. Этим занимается msiexec 

(In reply to comment #21)
> (In reply to comment #20)
> > wine cmd /c web.msi
> > Результат:
> > Bad format
> Что логично. Никаким боком cmd не имеет
> отношения к исполнению msi-сценариев. Этим
> занимается msiexec 
> 

в WinXP cmd /c web.msi работает

При вызове:
CreateProcessA(NULL, "cmd /c web.msi", NULL....
Тоже Bad format

проверил в WinXp. тест для CreateProcess() нормально запускает *.msi

Можно создать тест и отправить его в Wine?

для теста нужен тестовый *.msi.
Взять готовый в данном случае не получится. Придётся создавать свой.
При этом не должно быть графического интерфейса.
Желательно чтобы он только распаковывал 1 файл в текущую или определённую директорию.
Насколько это реально пока не знаю.

Нашёл специальную программу "Advanced Installer" она не позволяет создать *.msi без оконного интерфейса. Думаю другие программы тоже этого не позволяют.

Думаю, можно создавать процесс, смотреть что возвращает CreateProcessA(), а потом сразу его убивать, пока окно не успело прорисоваться.
Только такой тест точно не понравится в официальной ветке

1. Давай с другой стороны - как можно сделать,
чтобы у нас msi обрабатывался как надо?
2. Не обязательно создавать полноценный msi для тестирования - достаточно, думаю, сделать пустышку с нужной сигнатурой в начале. Не знаю правда как проверять что он запустился - возможно коды возврата у CreateProcess будут разные?

(In reply to comment #28)
> 1. Давай с другой стороны - как можно
> сделать,
> чтобы у нас msi обрабатывался как надо?
В CreateProcessA() уже есть похожий код, отлавливающий вызов *.bat
Думаю не так сложно дописать обработку *.msi. При этом будет вызываться msiexec -i  х.msi

> 2. Не обязательно создавать полноценный msi
> для тестирования - достаточно, думаю,
> сделать пустышку с нужной сигнатурой в
> начале. Не знаю правда как проверять что он
> запустился - возможно коды возврата у
> CreateProcess будут разные?
> 
Да, нужно проверить. CreateProcessA() при этом должнен запустить msiexec в новом потоке, а сам завершится успешно. Если возникает ошибка, то она возникает уже в другом потоке.
Если *.msi будет содержать только сигнатуру, то вряд ли msi будет считать его корректным. Если передавать просто пустой файл, то думаю разницы никакой не будет.

В Wine существует 2 способа выполнения .bat файлов через CreateProcess.
В качестве имени можно передавать:
1) "cmd /c х.bat" при этом cmd вызывается напрямую
2) "x.bat" при этом внутри функции идёт определение типа по расширению, и в конечном итоге вызывается "cmd /c х.bat"

Получается, что для реализации *.msi недостаточно просто дописать CreateProcess, а нужно ещё дописывать cmd.exe

При запуске msi через CreateProcess ( комманда "cmd /c х.msi"):

1)При использовании реальных *.msi завершается успешно, но пишет "Bad format"
Здесь CreateProcess всегда завершается успешно. Получается, что тестировать надо cmd.exe 

2)При использовании пустого *.msi cmd распознаёт его как нормальный

Реализовал поддержку *.msi через cmd

работает:
$ wine cmd.exe /c x.msi
CreateProcessA(NULL,"wine cmd.exe /c x.msi", ...

пока не работает:
CreateProcessA(NULL,"x.msi", ...

ещё возможно:
$ wine x.bat
$ wine x.msi
Но это уже сложнее, лучше оставить на потом.

Послал патч в официальную ветку. Там возникли большие сомнения по поводу того реализовано ли в Windows это внутри cmd, или скорее как-то через реестр.

Как это работает в Windows - информации не нашёл. Если нет возражений я бы оставил так. Только осталось дописать поддержку CreateProcessA(NULL,"x.msi", ...
В итоге в официальную ветку скорее всего не примут, зато в нашей версии работа с *.msi будет намного удобнее.

Реализовывать надо через ShellExecute
При этом программа-обработчик должна братся из реестра.

Для начала, думаю, надо добится работы:

$wine start x.msi
или
$wine start x.html

Ошибся:
$wine start x.html работает!

$wine start x.msi тоже работает

Добавил в скрипт запуска wine проверку, и теперь реально существующие файлы,
не имеющие расширения .EXE, будут запускаться через wine start FILE

+# if file is exist in Unix or Wine notation
+if [ -n "$1" ] && [ -f $(winepath "$1") ] ; then
+       TRNAME=$(echo "$1" | tr [a-z] [A-Z])
+       # if file is not executable, run it with start
+       if [ $(basename "$TRNAME" .EXE) = $(basename "$TRNAME") ] ; then
+               run_wine start "$@"
+       fi
+fi
+
 run_wine "$@"