BUG: ShellExecute - Ex: Win7 Xcopy

Test Plugin can be found here:
Lancelot Reply #195
http://theoven.org/index.php?topic=2271.msg25318#msg25318

APT log with Win7 Host do not produce Xcopy [Standard Output] on log
APT Reply #197

for reference Reply #198 of Lancelot log

*
Maybe Win7 Xcopy behaviour is different than other Xcopy and this not related to PEBakery.
....



Edit:
For reference:
New title:
BUG: ShellExecute - Ex: Win7 Xcopy
Old title:
BUG: or ? - Win7 Xcopy [Standard Output] bug or xcopy difference ?

Hi ied206,

Literally, %1500 this is a PEBakery ShellExecute bug.

whatever changed with ShellExecute after PEBakery_20171213.7z cause this bug.

I do not see ShellExecute behavior change on PEBakery Release topic.
http://theoven.org/index.php?topic=2324
Still maybe there is a reason behind.....


Easily reproducible by APT on Win7 x64 Host


*
This is something we are familiar with.
We are around since XP x86 - PE1

Highly probably wb caused projects for UAC dependency at Win7 times for very similar ShellExecute failure.
(
which seems nobody remembers 
 or maybe do not want to remember 
 and regular users not aware at all. 
)


Problem has a workaround.

"cmd.exe /c" AND "cmd.exe Start" %90 fix this kind of failures.
At the point they can not, there is one more way....
Only 1 remained not having a workaround, but no need to mention that anymore, we have PEBakery.

That is the reason there is
Call,Start
Call,StartDoc
etc.
That starts cmd.exe to execute documents and some executables.
That is the same reason ExtractAndRun etc. also deprecated from plugins.
And That is the reason there are some workarounds on plugins to get executables work fine for everybody.
 (--> implemented after chasing bugs for a long time on topics... ex: like APT post series taking days, sometimes weeks.... )

(
ps: Although some people blame me for such commands,
 I have not seen same some people come with a solution. 
   They are only unhappy for seeing workarounds on logs,
      ignoring all working smooth for everybody, not only for them.
)



*
I do not want to workaround this with cmd, PEBakery is active development unlike wb.
ex:
for APT (Win7 x64 host) this workaround works for APT on test plugin.

Code: [Select]

ShellExecute,Open,cmd.exe,"/c xcopy.exe #$q%ProjectTemp%\1\*.*#$q #$q%ProjectTemp%\2\#$q /i /s /e /r /v /k /f /c /h /y"

It is better we have PEBakery have ShellExecute works same with cmd.exe Start
This way all troubles related to ShellExecute will be solved for a very long time
 (maybe forever till Windows comes with something NEW )
And workarounds on plugins and some Macro Commands can be deprecated in some future (after we get rid of wb)
(
 I am sure at passing period (after getting rid of wb and start cleaning plugins),
   very same people will intentionally forget these commands created to get stable projects at wb times saying:
      "all work with PEBakery , why there is such bad commands etc.
         A small price to be payed by me even when updating other plugins not written by me.
          If I wrote a project with compiled executable, noone would notice workarounds or blame anyway. 
)




Shortly:
ShellExecute BUG , on your hands now.

Regarding ShellExecute, I also noticed similar issue, reported by Homes32.
That problem also appeared on Windows 7 host, and I fixed this problem in plugin edit button.

Original Code:

Code: [Select]

ProcessStartInfo procInfo = new ProcessStartInfo()
{
Verb = "open",
FileName = curMainTree.Plugin.FullPath,
UseShellExecute = true
};
Process.Start(procInfo);

Fixed Code:

Code: [Select]

ProcessStartInfo procInfo = new ProcessStartInfo(curMainTree.Plugin.FullPath)
{
UseShellExecute = true
};
Process.Start(procInfo);

I cannot figure why original code only works on Windows 10, but I guess this bug is quite similar.

I will try quick fix in next release.
In case of the bug persist after the fix the bug, then I can use 'cmd /C' workaround.

That problem also appeared on Windows 7 host, and I fixed this problem in plugin edit button.

I guess it is reverse.
I feel what you fix for Edit button cause APT failure.

+
Since I add
Call,StartDoc to plugins, no more related bug with none executables anymore around.
(mostly help files .txt .html .pdf .html etc.)

+
So I advice,
revert back ShellExecute
and
"Edit" button use "cmd.exe /C start...."
->

Code: [Select]

ShellExecuteex,Hide,cmd.exe,"/C #$q%ScriptFile$q",%ScriptDir%

or

Code: [Select]

Echo,"Edit Plugin - Close Editor to Continue."
ShellExecute,Hide,cmd.exe,"/C #$q%ScriptFile$q",%ScriptDir%
System,Load,%ScriptFile%

I am not sure about 2nd since I only use notepad (windows) and notepad2.
 (tabbed behavior of other editors like notepad++ not tested)
Still keep this as an idea when you implement an internal editor.
 (probably notepad++ with settings that will fit above and containing your highlighter)

+
Above is quick and working solution that will fit PEBakery
Still you can debug how cmd.exe works with Start in future.

+
ah homes32 ....

That problem also appeared on Windows 7 host, and I fixed this problem in plugin edit button.

I guess it is reverse.
I feel what you fix for Edit button cause APT failure.

ShellExecute behavior didn't change with that fix. That fix was specific to the PluginEditButton_Click() function in MainWindow.xaml.cs
https://github.com/ied206/PEBakery/blob/a81b63c36c0108e76c7c9d4c1604d5d53e04c3f2/PEBakery/WPF/MainWindow.xaml.cs#L894
I'm guessing you confused PEBakerys ShellExecute plugin/script command with the internal windows ShellExecute = True directive in ied206's code snipit. They are not related.

Edit:
after comparing CommandSystem.cs from the master branch on 12-12-2017 to 12-23-2017 the only changes made to ShellExecute were the addition of the Min parameter, the ShellExecuteSlow command was added, and the StdOut capture was added.

I'm guessing you confused PEBakerys ShellExecute plugin/script command with the internal windows ShellExecute = True directive in ied206's code snipit. They are not related.

Regarding ShellExecute, I also noticed similar issue, reported by Homes32.
That problem also appeared on Windows 7 host, and I fixed this problem in plugin edit button.

Following link ied206 wrote:

In code side, EditButton uses ShellExecute internally,

so I naturally think,
EditButton uses ShellExecute internally, and APT bug appears after that fix.

Well If I knew there are development on ShellExecute things,
 I would have previous post earlier saying "be careful we lived ShellExecute troubles before".
    So I decide to write my previous post also a summary to be careful with reasons behind. ( 1 circle )

This bug is caused by redirection of stdout / stderr in ShellExectue,Hide syntax.
PEBakery uses CreateProcess API instead of ShellExectue API in ShellExectue,Hide syntax.
Need more research about CreateProcess()'s behavior in Windows 7 when its stdout/stderr is redirected.

Hi ied206,

If next release is ready with new features and only this waiting.
And since you can easily test with Win7 with test plugin now
http://theoven.org/index.php?topic=2271.msg25454#msg25454

Can revert back ShellExectue,Hide and share a new release of PEBakery
 so we can benefit and test other fixes and updates.

How about disabling ShellExecute console redirect only in Windows 7, or turning on in only Windows 10?

I found an StackOverflow page describing similar issue with XCOPY.
https://stackoverflow.com/questions/14218642/xcopy-does-not-work-with-useshellexecute-false

And adding one line fixed this issue:

Code: [Select]

proc.StartInfo.RedirectStandardInput = true;

So the culprit is Windows 7's xcopy.exe, demanding stdin where it should not be required.
The fix will be applied in next release.

Good News.
 

As I said it is always better we have reliable ShellExecute.

More ShellExecute things later ......