.net – Is it possible to build a Console app that does not display a console Window when double-clicked

consoleconsole-applicationnetwindows

Related:
Should I include a command line mode in my applications?
How to grab parent process standard output?
Can a console application detect if it has been run from Explorer?

I want to build a console app, that is normally run from the command line.

But, when it is double clicked from within Explorer (as opposed to being run from a cmd.exe prompt) then I'd like the program to NOT display a console window.

I want to avoid this:

Is it possible?

EDIT I guess another way to ask it is, is it possible for a program to know how it was invoked – whether by double-click or by command line ?

I'm working in .NET, on Windows.

EDIT 2: From this Old New Thing blog post I learned some good stuff. Here's what I know now…

In Windows, EXE files are marked as either GUI or non-GUI. With csc.exe, this is selected with /target:winexe or /target:exe. Before the first instruction in the process executes, the Windows kernel sets up the execution environment. At that moment, if the EXE is marked GUI, the kernel sets the stdin/stdout for the process to NULL, and if non-GUI (command-line) the kernel creates a console and sets the stdin/stdout for the process to that console.

When launching the process, if there is no stdin/stdout (== /target:winexe), then the call immediately returns. So, launching a gui app from a cmd.exe, you will immediately get your cmd prompt back. If there is a stdin/stdout, and if run from cmd.exe, then the parent cmd.exe waits for process exit.

The "immediate return" is important because if you code a GUI app to attach to its parent's console, you will be able to do console.writeline, etc. But the cmd.exe prompt is active. The user can type new commands, start a new process, and so on. In other words, from a winexe, simply attaching to the parent console with AttachConsole(-1) will not "turn it into" a console app.

At this point I think the only way to allow an app to use the console if it is invoked from cmd.exe, and NOT use it if it is double-clicked, is to define the exe as a regular console exe (/target:exe), and hide the window on startup if appropriate. You still get a console window appearing briefly.

I still haven't figured how to know whether it was launched from explorer or cmd.exe, but I'm getting closer..

ANSWERS

It is not possible to build a console app that does not display a console window.

It is possible to build a console app that hides its window very quickly, but not so quickly that it is as if the window never appears.

Now, to determine whether a console app was launched from explorer, some have suggested to look at the console it is running in
(from mgb's answer, and KB article 99115) :

  int left = Console.CursorLeft;
  int top = Console.CursorTop;
  bool ProcessWasRunFromExplorer = (left==0 && top==0);

This tells you if the process was launched in its own console, but not whether it was explorer. A double click in explorer would do this, but also a Start.Process() from within an app would do the same thing.

If you want to treat those situations differently, use this to learn the name of the parent process:

  System.Console.WriteLine("Process id: {0}", Process.GetCurrentProcess().Id);
  string name = Process.GetCurrentProcess().ProcessName ;
  System.Console.WriteLine("Process name: {0}", name);
  PerformanceCounter pc = new PerformanceCounter("Process", "Creating Process Id", name);
  Process p = Process.GetProcessById((int)pc.RawValue);
  System.Console.WriteLine("Parent Process id: {0}", p.Id);
  System.Console.WriteLine("Parent Process name: {0}", p.ProcessName);

  // p.ProcessName == "cmd" or "Explorer" etc

To hide the window quickly after the process is launched, use this:

  private static readonly int SW_HIDE= 0;

  [System.Runtime.InteropServices.DllImport("user32.dll")]
  private static extern Boolean ShowWindow(IntPtr hWnd, Int32 nCmdShow);

  ....
  {
    IntPtr myHandle = Process.GetCurrentProcess().MainWindowHandle;
    ShowWindow(myHandle, SW_HIDE);
  }

If you produce a winexe (a WinForms app), and optionally attach to the parent console when appropriate with AttachConsole(-1), you do not get the equivalent of a regular console app. For a winexe, the parent process (like cmd.exe) will return to the command prompt immediately after starting a GUI application. In other words, the command prompt is active and ready for input while the just-launched process may be emitting output. This is confusing and is probably useful only for debugging winforms apps.

This worked for me.

Best Answer

So, I've written tools with both a GUI and a CLI. The hard part was figuring out which one to open - in our case, though, the CLI version had required parameters, so I just opened the GUI if there weren't any parameters. Then, if they did want a console, call a function that looks something like:

private const int ATTACH_PARENT_PROCESS = -1;
private const int ERROR_INVALID_HANDLE = 6;
[DllImport("kernel32.dll", SetLastError = true)]
static extern bool AttachConsole(int dwProcessId);
[DllImport("kernel32.dll")]
static extern bool AllocConsole();
[DllImport("kernel32.dll")]
static extern bool FreeConsole();

private static bool StartConsole()
{
  if (!AttachConsole(ATTACH_PARENT_PROCESS)) // try connecting to an existing console  
  {  
      if (Marshal.GetLastWin32Error() == ERROR_INVALID_HANDLE) // we don't have a console yet  
      {  
          if (!AllocConsole()) // couldn't create a new console, either  
              return false;  
      }
      else
          return false; // some other error
  }
  return true;
}

Returns whether the console was created. Don't forget to FreeConsole() when you're done!

In our case, of course, if we don't create a console, we create a GUI. It'd be just as easy to create either a console or no UI, though.

EDIT: That totally didn't answer the question in the edit that wasn't there when I started writing that, of course. Other than that our hack was just checking whether it was called with command-line parameters or not.

Related Solutions

Windows – win32 GUI app that writes usage text to stdout when invoked as “app.exe –help”

Microsoft designed console and GUI apps to be mutually exclusive. This bit of short-sightedness means that there is no perfect solution. The most popular approach is to have two executables (eg. cscript / wscript, java / javaw, devenv.com / devenv.exe etc) however you've indicated that you consider this "cheating".

You've got two options - to make a "console executable" or a "gui executable", and then use code to try to provide the other behaviour.

GUI executable:

cmd.exe will assume that your program does no console I/O so won't wait for it to terminate before continuing, which in interactive mode (ie not a batch) means displaying the next ("C:\>") prompt and reading from the keyboard. So even if you use AttachConsole your output will be mixed with cmd's output, and the situation gets worse if you try to do input. This is basically a non-starter.

Console executable:

Contrary to belief, there is nothing to stop a console executable from displaying a GUI, but there are two problems.

The first is that if you run it from the command line with no arguments (so you want the GUI), cmd will still wait for it to terminate before continuing, so that particular console will be unusable for the duration. This can be overcome by launching a second process of the same executable (do you consider this cheating?), passing the DETACHED_PROCESS flag to CreateProcess() and immediately exiting. The new process can then detect that it has no console and display the GUI.

Here's C code to illustrate this approach:

#include <stdio.h>
#include <windows.h>

int main(int argc, char *argv[])
{
    if (GetStdHandle(STD_OUTPUT_HANDLE) == 0) // no console, we must be the child process
    {
        MessageBox(0, "Hello GUI world!", "", 0);
    }
    else if (argc > 1) // we have command line args
    {
        printf("Hello console world!\n");
    }
    else // no command line args but a console - launch child process
    {
        DWORD dwCreationFlags = CREATE_DEFAULT_ERROR_MODE | DETACHED_PROCESS;
        STARTUPINFO startinfo;
        PROCESS_INFORMATION procinfo;
        ZeroMemory(&startinfo, sizeof(startinfo));
        startinfo.cb = sizeof(startinfo);
        if (!CreateProcess(NULL, argv[0], NULL, NULL, FALSE, dwCreationFlags, NULL, NULL, &startinfo, &procinfo))
            MessageBox(0, "CreateProcess() failed :(", "", 0);
    }
    exit(0);
}

I compiled it with cygwin's gcc - YMMV with MSVC.

The second problem is that when run from Explorer, your program will for a split second display a console window. There's no programmatic way around this because the console is created by Windows when the app is launched, before it starts executing. The only thing you can do is, in your installer, make the shortcut to your program with a "show command" of SW_HIDE (ie. 0). This will only affect the console unless you deliberately honour the wShowWindow field of STARTUPINFO in your program, so don't do that.

I've tested this by hacking cygwin's "mkshortcut.exe". How you accomplish it in your install program of choice is up to you.

The user can still of course run your program by finding the executable in Explorer and double-clicking it, bypassing the console-hiding shortcut and seeing the brief black flash of a console window. There's nothing you can do about it.

C# – Elevating process privilege programmatically

You can indicate the new process should be started with elevated permissions by setting the Verb property of your startInfo object to 'runas', as follows:

startInfo.Verb = "runas";

This will cause Windows to behave as if the process has been started from Explorer with the "Run as Administrator" menu command.

This does mean the UAC prompt will come up and will need to be acknowledged by the user: if this is undesirable (for example because it would happen in the middle of a lengthy process), you'll need to run your entire host process with elevated permissions by Create and Embed an Application Manifest (UAC) to require the 'highestAvailable' execution level: this will cause the UAC prompt to appear as soon as your app is started, and cause all child processes to run with elevated permissions without additional prompting.

Edit: I see you just edited your question to state that "runas" didn't work for you. That's really strange, as it should (and does for me in several production apps). Requiring the parent process to run with elevated rights by embedding the manifest should definitely work, though.

Best Answer

Related Solutions

Windows – win32 GUI app that writes usage text to stdout when invoked as “app.exe –help”

C# – Elevating process privilege programmatically

Related Topic