Replace scrcpy-noconsole.exe by a simple wrapper script

[rom1v]

In the Windows releases (until v1.16), there are two binaries:

• scrcpy.exe (which pauses on error to let the user a chance to see any error message before the terminal closes)
• scrcpy-noconsole.exe which does not open a terminal

They both contain the whole program, and complicate the build system.

For the next release, the idea is to have 3 files:

• scrcpy.exe the main binary, with the same behavior as on other platforms (no pause on error)
• scrcpy-console.bat a simple wrapper script to pause on error (already merged 904d470)
• scrcpy-noconsole.vbs a one-line VBS script to start scrcpy.exe without a console (this PR)

scrcpy-noconsole.vbs just contains:

CreateObject("Wscript.Shell").Run "cmd /c scrcpy.exe", 0, false

Refs #1975 (comment)

[Artur202030]

They both contain the whole program, and complicate the build system.

For those who have no building problems, do not remove the option to create a scrcpy-noconsole.exe

[rom1v]

I think there is no benefit to keep it. If it's not necessary, I prefer to remove it to simplify the Makefile and remove the ifdefs from the sources.

[Alfakennyone]

I think there is no benefit to keep it. If it's not necessary, I prefer to remove it to simplify the Makefile and remove the ifdefs from the sources.

There is, at least for me.

I like to create a shortcut (to change the icon) and pin it to my taskbar.

[jeansagi]

Sorry, but I think #1988 is bad implemented.

I was happily, BTW, using scrcpy-noconsole.exe without any problem but, after vacation, I found it just simply does not work in 1.17.

I understand the desire to have just one executable and use wrappers if the same functionality is preserved but that is not the case.

When I used a console (cmd, bash) when I invoked scrcpy.exe the console gets locked until the scrcpy window closes or if you press Ctrl-C on the console window.
If you use scrcpy-noconsole.exe instead of scrcpy.exe the console doesn't get locked and you can keep using it and even close it and the scrcpy window remains visible.

Now If I use scrcpy-noconsole.exe it just does not work. Besides if I use scrcpy-noconsole.bat the console window still remains locked!! because it just calls scrcpy.exe which locks the console while the scrcpy window remains open. That is not the previous behavior.

Sure, I can use scrcpy-noconsole.vbs but I can use it only in cmd but not in bash by default and besides, you can't pass parameters to the vbs (for example --render-driver opengles2 or any other) which you can easily do with previous version of scrcpy-noconsole.exe.

So,

The new implementation of scrcpy-noconsole, IMO, is simply wrong as it does not mimic the previous behavior.
And BTW I don't get how adding scrcpy-noconsole.exe how much complicates the build system but as long as the previous behavior isn't well implemented it is better to have the option.

Just my thoughts,

J.

[rom1v]

When I used a console (cmd, bash) when I invoked scrcpy.exe the console gets locked until the scrcpy window closes or if you press Ctrl-C on the console window.

To run in background (to get prompt immediately):

• in cmd, execute start /B scrcpy
• in bash, execute scrcpy &

You could also pass arguments.

Besides if I use scrcpy-noconsole.bat the console window still remains locked!! because it just calls scrcpy.exe which locks the console while the scrcpy window remains open. That is not the previous behavior.

The goal was not to keep the previous behavior, the fact that it was executed in background was a side-effect.
Any command could be executed in background easily from a script.

besides, you can't pass parameters to the vbs (for example --render-driver opengles2 or any other)

That's a real drawback, the vbs script should forward the arguments to scrcpy. PR welcome.

I can use scrcpy-noconsole.vbs but I can use it only in cmd but not in bash by default

The only purpose of scrcpy-noconsole when it was introduced was to provide a way for windows users to double-click without opening a visible console. If it's called from a script, it's not necessary to use a "no console" version.

[jeansagi]

When I used a console (cmd, bash) when I invoked scrcpy.exe the console gets locked until the scrcpy window closes or if you press Ctrl-C on the console window.

To run in background (to get prompt immediately):

• in cmd, execute start /B scrcpy
• in bash, execute scrcpy &

You could also pass arguments.

Do you try this yourself? In my case I have the Windows 10 Pro 20H2, BTW, and that just don't work.
Surely after executing start /B scrcpy in cmd or scrcpy & in bash the console returns but get unusable. To effectively use the console, one must close scrcpy window.

So, both options aren't really a workaround. In fact, if I create a scrcpy.bat with start /B scrcpy to use the same command on cmd/bash (hate to use different commands for the same...) it does not work... the console gets stuck. I tried this on cmd and bash on their own programs and through windows terminal and always is the same: The console gets stuck.

Besides if I use scrcpy-noconsole.bat the console window still remains locked!! because it just calls scrcpy.exe which locks the console while the scrcpy window remains open. That is not the previous behavior.

The goal was not to keep the previous behavior, the fact that it was executed in background was a side-effect.
Any command could be executed in background easily from a script.

Not so easy without getting the console stuck, as I said.

besides, you can't pass parameters to the vbs (for example --render-driver opengles2 or any other)

That's a real drawback, the vbs script should forward the arguments to scrcpy. PR welcome.

I can use scrcpy-noconsole.vbs but I can use it only in cmd but not in bash by default

The only purpose of scrcpy-noconsole when it was introduced was to provide a way for windows users to double-click without opening a visible console. If it's called from a script, it's not necessary to use a "no console" version.

Maybe, that were their original purpose but the more than I think about it the more I believe that it should be a parameter to scrcpy, not a duplicate program compiled with a special flag.

That would be indeed a useful feature for me... and it seems to others as well.

J.

[rom1v]

Do you try this yourself? In my case I have the Windows 10 Pro 20H2, BTW, and that just don't work.

Yes, that works.

Surely after executing start /B scrcpy in cmd or scrcpy & in bash the console returns but get unusable.

Because of the scrcpy output? Yes, if you don't want it, disable it (like any shell command):

start /B scrcpy >nul 2>&1

scrcpy >&/dev/null

In fact, if I create a scrcpy.bat with start /B scrcpy to use the same command on cmd/bash (hate to use different commands for the same...) it does not work... the console gets stuck. I tried this on cmd and bash on their own programs and through windows terminal and always is the same: The console gets stuck.

Yes, you need the -noconsole version (from a batch script, call scrcpy-noconsole, you don't need start /B). As you noticed, there is a temporary issue that the current scrcpy-noconsole script does not forward its arguments, but this can be fixed. Then in practice there will be no difference between executing the old scrcpy-noconsole.exe and the new scrcpy-noconsole.vbs.

the more than I think about it the more I believe that it should be a parameter to scrcpy, not a duplicate program compiled with a special flag.

Of course that would be better, but that's not possible (otherwise it would have been implemented that way): on Windows the fact that a console is opened or not is determined before executing your program code, so the program itself could not decide to not start a new window. That's the reason why you can't execute a .bat file without displaying a console.

The wanted behavior is that of Linux:

• if you run from a terminal, you get the output and you get the prompt back once scrcpy is terminated (unless you call it with &)
• if you run it without a terminal, it still works without opening a new window

On Windows, the behavior of consoles is totally broken (IMO, I might be biased):

• if you create a "Console" application:
  • from a terminal, it behaves as expected
  • with a double-click from the file manager, it opens a terminal (could not be avoided programmatically)
• if you create a "Windows" application:
  • from a terminal, there is no output and it is started in background (wtf)
  • with a double-click from the file manager, it behaves as expected

(and that's not the only thing which is broken about command-line execution on Windows)