Re: [RFA] patch for run.exe -- ATTN: ago

[Alexander Gottwald <Alexander dot Gottwald at s1999 dot tu-chemnitz dot de>]

On Thu, 2006-05-18 at 02:45 -0400, Charles Wilson wrote:

> run.exe currently launches clients without any stdio handles and without 
> any console at all.  That's over-ambitious: what run REALLY should do is 
> launch the client with a *hidden* console and *working* stdio handles.
>
> Since run.exe is a GUI app, it has no console at all -- and therefore
> GetStdHandle() returns INVALID_HANDLE_VALUE, which isn't a very nice
> thing to initialize start.hStdInput and friends to.

Actually GetStdHandle seems to work with pipes.

run cat foo | less 
cat foo | run cat | less 

but this does exit immediatly
run cat | less 

> Run is a console-hider, not a daemonizer -- and some apps (like, err, 
> rxvt-unicode), even tho they are GUIs, don't behave well when launched 
> without working stdio (even if those handles point to an invisible 
> console, and really shouldn't be used by the app anyway!)

So the invisible console should provide stdin, stdout and stderr where
stdout and stderr will discard any written data and stdin should never
return data on read.

creating a pipe for stdin could be useful. maybe creating one for stdout
and stderr which is always read too.


   start.hStdInput = GetStdHandle(STD_INPUT_HANDLE);
   start.hStdOutput = GetStdHandle(STD_OUTPUT_HANDLE);
   start.hStdError = GetStdHandle(STD_ERROR_HANDLE);

   HANDLE hpStdInput[2] = {INVALID_HANDLE_VALUE, INVALID_HANDLE_VALUE};
   HANDLE hpStdOut[2] = {INVALID_HANDLE_VALUE, INVALID_HANDLE_VALUE};

   if (start.hStdInput == INVALID_HANDLE_VALUE)
   {
     CreatePipe(&hpStdInput[0], &hpStdInput[1], NULL, 0);
     start.hStdInput = hpStdInput[0];
   }
   if (start.hStdOutput == INVALID_HANDLE_VALUE || start.hStdError == INVALID_HANDLE_VALUE)
   {
     CreatePipe(&hpStdOutput[0], &hpStdOutput[1], NULL, 0);
     if (start.hStdOutput == INVALID_HANDLE_VALUE)
       start.hStdOutput = hpStdOutput[1];
     if (start.hStdError == INVALID_HANDLE_VALUE)
       start.hStdError = hpStdOutput[1];     
   }
      
   sec_attrs.nLength = sizeof (sec_attrs);
   sec_attrs.lpSecurityDescriptor = NULL;
   sec_attrs.bInheritHandle = FALSE;

   if (CreateProcess (NULL, cmdline, &sec_attrs, NULL, TRUE, 0,
                      NULL, NULL, &start, &child))
   {
      if (wait_for_child)
      {
         if (hpStdOutput[0] != INVALID_HANDLE_VALUE)
         {
           HANDLE handles[2] = { child.hProcess, hpStdOutput[0] };
           while (WaitForMultipleObjects (2, handles, FALSE, INFINITE) == WAIT_OBJECT_0 + 1)
           {
             char buffer[1024];
	     DWORD dwRead;
             ReadFile (hpStdOutput[0], buffer, 1024, &dwRead, NULL);
           }
         } else {
           WaitForSingleObject (child.hProcess, INFINITE);
         }
         GetExitCodeProcess (child.hProcess, &retval);
      }
      CloseHandle (child.hThread);
      CloseHandle (child.hProcess);
   }


> The attached patch adapts code from cygwin's fhandler_init, using 
> NT/2K/XP-only APIs to enable AllocConsole() to initialize the stdio 
> handles *without* that console ever becoming visible, not even for a 
> brief flash.  Because these APIs are only available on some of the 
> supported OSes, I use LoadLibrary/GetProcAddress and function pointers, 
> so that on the older OSes the behavior should be unchanged from 1.1.9-1.
> 
> With this patch, rxvt-unicode-X is happy and no longer sucks 100% CPU 
> when launched by run.exe with loginShell=true, as is the case with 
> run-1.1.9-1.  (At least, on NT/2K/XP.  On 95/98/Me, I expect 
> rxvt-unicode-X will be just as unhappy with this patch as without.  Half 
>   loaves and baby steps...)

Anyway, if the allocated hidden console does not interfere with the
pipes i'm going to add it.

Is it possible to create a console on win9x and hide it again. This will
flash, but at least it does work.

bye
	ago




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/