My goal is to have it so when the executable is just double clicked no console spawns but also have it able to print to the console when the user launches it from the command line.
I have the following Windows-specific code set to not spawn a console:
#![windows_subsystem = "windows"]
fn main() {
println!("Hello world");
}
Unfortunately, it never hooks stdout/stderr to anything since its set to not create a console on startup. Is there any way to achieve my goal despite this?
This is not really specific to Rust, but instead is the way Windows works: you either write for the "console" subsystem and your program opens a console if it is started without one, or you write for the "windows" subsystem and your program detaches itself from the console if it is started from the command line.
The PATHEXT environment variable — which CLI shells use for the file extensions to add when searching PATH for a command — normally includes ".COM" before ".EXE", in which case one can create a console version of the application with a ".com" file extension (e.g. "app.com"). This can be a standalone version or just a launcher that spawns the main executable (e.g. "app.exe", a GUI app). A launcher can pass a command-line option that allows the main application to attach back to the console via AttachConsole.
Without a launcher, it's a bad idea to attach back to the console since the parent application (e.g. a CLI shell or a full TUI app) normally will not wait for a GUI application to exit, in which case the result is chaotic interleaved I/O with two applications competing for access.
Related
I am writing a service program which is expected to run in background. On Windows it will open a console window when run. I want it to go to background directly without that console window, so I used the -ldconf "-H=windowsgui" option, which worked as expected.
However, there is a catch. The program has a command line option -help, which output command line usage in the console. If I use -H=windowsgui, the help text is NOT printed even I start it in cmd.exe prompt.
It seems that the windowsgui option is not what I want. Is there anyway that the -help still works at commant line, and the console window will not persist if the program runs normally. I do not care if there is a console window pops up, provided that it disappears shortly without user intervention. i.e. I want a way on windows which is similar to the & operator on Linux.
P.S. if provided solution uses any other tools, I want that tool to be a Windows component, not any 3rd-party program. Thanks.
My goal is to have it so when the executable is just double clicked no console spawns but also have it able to print to the console when the user launches it from the command line.
I have the following Windows-specific code set to not spawn a console:
#![windows_subsystem = "windows"]
fn main() {
println!("Hello world");
}
Unfortunately, it never hooks stdout/stderr to anything since its set to not create a console on startup. Is there any way to achieve my goal despite this?
This is not really specific to Rust, but instead is the way Windows works: you either write for the "console" subsystem and your program opens a console if it is started without one, or you write for the "windows" subsystem and your program detaches itself from the console if it is started from the command line.
The PATHEXT environment variable — which CLI shells use for the file extensions to add when searching PATH for a command — normally includes ".COM" before ".EXE", in which case one can create a console version of the application with a ".com" file extension (e.g. "app.com"). This can be a standalone version or just a launcher that spawns the main executable (e.g. "app.exe", a GUI app). A launcher can pass a command-line option that allows the main application to attach back to the console via AttachConsole.
Without a launcher, it's a bad idea to attach back to the console since the parent application (e.g. a CLI shell or a full TUI app) normally will not wait for a GUI application to exit, in which case the result is chaotic interleaved I/O with two applications competing for access.
I have a Windows application application that is normally GUI-only and declares the WINDOWS subsystem. It doesn't open a console window when launched.
Alas, I would like to offer additional console output when the application happens to be started from console window (say, from interactive cmd.exe).
Is there a way of detecting if some process "up the chain" has an open console, and to attach to that console?
The closest I've found is a way to explicitly open a console for a gui application, but I don't want to open a console if there isn't one already there.
At first glance it seems like the AttachConsole() function will let you attach to the console of your parent process:
AttachConsole(ATTACH_PARENT_PROCESS);
If the process doesn't actually have a console the function will fail with ERROR_INVALID_HANDLE. The function will also fail if your parent process no longer exists. If it fails you can then call AllocConsole() to create your own.
I've never tried this so don't actually know if it will work or not :)
If a win32 GUI app is run from the command line
e.g gfxexe.exe
first what is the simplest way to detect that it has been run from a command line
(cmd32.exe and possible other 3rd part command line apps).
second, and most importantly, if the app has been launched from the command line, how
can i print something to it.. e.g , this app can't be run from a command line.
Simplest Method I could come up with is. First, Create a console application, then Have your console application spawn your Window application, and Finally, Use Mapped Memory or some other form of Inter-Process Communication.
What is the difference between cscript and wscript? Which is best for doing Telnet and FTP automation in Windows?
In Windows, an executable is either a console application or a Windows application (or a SFU or Native application, but that doesn't matter here).
The kernel checks a flag in the executable to determine which.
When starting using CreateProcess WinAPI function, if it is a console application, the kernel will create a console window for it if the parent process doesn't have one, and attach the STDIN, STDOUT and STDERR streams to the console.
If it is a Windows application, no console will be created and STDIN, STDOUT and STDERR will be closed by default.
WSCRIPT.EXE and CSCRIPT.EXE are almost exactly identical, except that one is flagged as a windows application and the other is flagged as a console application (Guess which way around!).
So the answer is: If you want your script to have a console window, use CSCRIPT.EXE. If you want it to NOT have a console window, use WSCRIPT.EXE.
This also affects some behaviors, such as the WScript.Echo command. In a CSCRIPT.EXE this writes a line to the console window. In WSCRIPT.EXE it shows a messagebox.
For your application I suggest CSCRIPT.EXE. I think you should also look at PuTTY and PLink, and you should also see this here:
Capturing output from WshShell.Exec using Windows Script Host