RESUBMISSION, see '*****' for revisions.  Using javaw, when starting from a Windows shortcut, (does not occur when running from a command line prompt), a console window opens when Runtime exec creates a native process even though all output streams are connected to the parent process.  This console remains blank as the process runs.  

The description of class Process says: "The created subprocess does not have its own terminal or console. All its standard io (i.e. stdin, stdout, stderr) operations will be redirected to the parent process through three streams ..."

This did not occur using jrew under jdk 1.x.  This problem has been seen on Win 95 and Win NT 4.0.

java version "1.2.1"
Classic VM (build JDK-1.2.1-A, native threads)
java full version "JDK-1.2.1-A"


To demonstrate the problem use the source code supplied below and follow these steps (modify per your configuration),


***** Create a Windows shortcut with the Target:
	c:\jdk1.2.1\bin\javaw.exe ProcessRunWindow find \"doesn't matter\" c:\*

and the Start In:
 	(the location of ProcessRunWindow.java)

***** Perform the test with the run option kept "Normal window".  This test shows the problem seen in a much larger application.  It is not possible to run this application minimized.  

Compile ProcessRunWindow then click on the shortcut.

The program runs showing the output of the "find" command in the window, but an MSDOS console window also opens, with the title "...find.exe", and displays nothing.  This console window should not open.  ***** Depending on your machine, the dosbox may flash by pretty quickly, you may miss it the first time.  To see it better change the command to search a more populated directory.


SOURCE CODE:

import java.awt.*;
import java.io.*;
import java.util.*;

/**
 * ProcessRunWindow
 * @version	
 * @author	
 * Demonstrates Java 1.2.1 problem on Windows
 * Create a shortcut with the Target:
 * 	\jdk1.2.1\bin\javaw.exe -cp . ProcessRunWindow find \"thread\" *.java
 * Set the Start In:
 * 	(the location of ProcessRunWindow.java)
 * Compile ProcessRunWindow the click on the shortcut.
 * The program runs showing the output of the "find" command in the window,
 * but an MSDOS console window opens, with the title " ...find.exe", and displays 
 * nothing.  This console window should not open.
 */
class ProcessRunWindow extends Frame {
TextArea output;



/**
 * 
 * @param	
 */
ProcessRunWindow (String cmd) {
	output = new TextArea(5,40);
	add(output);
	command(cmd);
	}
/**
 * ProcessRunWindow find \"thread\" \jd\work\*.java
 * @param	
 * @return	
 */
public static void main(String[] args) throws Exception {

    if (args.length < 1) {
        System.err.println("Usage:  java ProcessRun cmd");
        System.exit(1);
        }
    String cmd = "";
    for (int i=0;i<args.length;i++) cmd += args[i] + " ";

    ProcessRunWindow prw = new ProcessRunWindow(cmd);
    prw.pack();
    prw.show();

    }
/**
 * 
 * @param	
 * @return	
 */
void command (String cmd) {
    Process p=null;
    Runtime rt = Runtime.getRuntime();
    try {
        p = rt.exec(cmd);
        } catch (IOException ex) {
        System.err.println("Error on command: "+cmd+"; "+ex);
        return;
        }
    final DataInputStream dis = new DataInputStream(p.getInputStream());
    final DataInputStream des = new DataInputStream(p.getErrorStream());

    Thread thread = new Thread("input stream") {
        public void run() {
            try {
                String line=null;
                while ((line = dis.readLine()) != null) {
                    if (output==null) System.out.println(line); 
                    else output.appendText(line+"\n");
                    }
                }
            catch (IOException e) {
                System.err.println(e);
                }
            }
        };
    thread.start();

    Thread thread2 = new Thread("error stream") {
        public void run() {
            try {
                String line=null;
                while ((line = des.readLine()) != null) {
                    if (output==null) System.out.println(line); 
                    else output.appendText(line+"\n");
                    }
                }
            catch (IOException e) {
                System.err.println(e);
                }
            }
        };
    thread2.start();

    }
/**
 * 
 * @param	
 * @return	
 */

public boolean handleEvent(Event event) {
	if (event.id == Event.WINDOW_DESTROY) {
		System.exit(0);
		}
	return super.handleEvent(event);
	}
}
(Review ID: 84039) 
======================================================================

N/A

We can use flag CREATE_NO_WINDOW with CreateProcess to workaround this problem. However, it does not work well on Win9X.

  xxxxx@xxxxx   2000-06-29

We are investigating to see if we can have this bug fixed in Merlin (1.4) beta3.

  xxxxx@xxxxx   2001-10-02

Fixed in Merlin beta3.  --   xxxxx@xxxxx   2001/10/2

Unfortunately, un-fixed for Merlin beta3.  The code snippet on the JDC is indeed interesting.  However, it hides everything launched by Runtime.exec(), including native Windows applications.  While acceptable for some console applications, and in particular, the code snippet in this bug, it's unacceptable for just about everything else.

We continue to ponder this bug.  The Runtime API is not rich enough to indicate when, on win32, the developer intends to hide the window that results from spawning a process.

  xxxxx@xxxxx   2001-10-18

We use CREATE_NO_WINDOW on NT. Win9X uses the DETACHED_PROCESS flag
if a 32 bit windows application is invoked, otherwise the null
flag is used as in 1.2. The console window may still flash by for
win9X users if they invoke a 16-bit application but we do not
know how to work around that.
  xxxxx@xxxxx   2001-10-24

The state of this bug is confusing on the JDC bug database, and that is due
to the scripts and processes that display those pages.

This bug was indeed fixed for Merlin, and should appear in the release that will
be available after 1.4 Beta 3.  The fix is not in beta 3.  Due to compatibility
concerns, we strongly suggest that those interested in thus bug download what
will probably be 1.4 RC1 and test the functionality that we have fixed.

Any issues arising post 1.4 Beta 3 should be brought to our attention quickly.  I've set up an alias that can be used.  It is: bug4244515(at)sun.com.  Replace the "(at)" with a '@' as appropriate.

  xxxxx@xxxxx   2001-11-19

still broken in 1.3 rc1

I am *SO* disappointed with the latest offering from Sun.  
JSDK 1.3 RC1 still does not address this problem.  It is not
a hard problem to fix.

For any of those who are interested, I have written a small 
C program that I use as a loader to spawn console 
applications from Java without the console window appearing.  
I am happy to forward the code to any who are interested.  
I would be *VERY* happy if Sun had a look at it - it isn't that 
difficult to use CreateProcess to do this (and have pipes 
re-directed under NT, 98, 95).

i have a work-around. don't use java.

still broken in 1.3rc3

SUN, you're killing me!  Customer does not like the dos flash window, or the window that just stays there.
How can we make professional looking apps?

Still not fixed in released 1.3.0.  Ugh.

The following windows program works around the problem.  
Rather than executing "cmd" execute "launcher cmd".

#include <windows.h>
#include <process.h>

int WINAPI WinMain(HINSTANCE hInst, HINSTANCE 
hPrevInstance, LPSTR lpCmdLine, int cmdShow)
{
    PROCESS_INFORMATION pi;
    STARTUPINFO         si;

    memset( &si, 0, sizeof( si ) );
    si.cb = sizeof(si);
    si.dwFillAttribute = 0;
    si.dwFlags = STARTF_USESHOWWINDOW | 
STARTF_USESTDHANDLES;
    si.wShowWindow = SW_HIDE;
    si.hStdInput = ::GetStdHandle( STD_INPUT_HANDLE );
    si.hStdOutput = ::GetStdHandle( STD_OUTPUT_HANDLE );
    si.hStdError = ::GetStdHandle( STD_ERROR_HANDLE );
    BOOL ok = ::CreateProcess( NULL, lpCmdLine, NULL, NULL, 
TRUE, 0, NULL, NULL, &si, &pi );

    if( !ok ) return -1;
    DWORD result = ::WaitForSingleObject
(pi.hProcess,INFINITE);
    switch( result ) {
    case WAIT_FAILED:
    case WAIT_ABANDONED:
    case WAIT_TIMEOUT:
        return -1;
    default:
        GetExitCodeProcess( pi.hProcess, &result );
        return result;
    }
}

still broken in 1.3 rc-3

If you read and agree with the evaluation of the bug id 4321955, there is one question : why there is no 
DOS window when we use the method exec() with the JDK version 1.1.8M (with the JDK1.1.8_003 the DOS 
window appears) ?
I will be very interested by the answer ...

I'd certainly add my feelings to this - what a pain! 
I spent ages trying to get op sys commands to work from 
Runtime.exec() until I finally found a few choice articles 
in forums and the like. (I needed to run XCOPY and 
DELTREE). Got it all working on Win 95 under JRE 1.2, moved 
it to Win NT and - bang! Irritating little windows popping 
up all over the place, or the system hanging as it tries to 
do readLine() method. Trying to find a solution that is 
guaranteed to work on both 95 and NT has been dreadful - 
and it shouldn't be like that, JavaSoft. A developer should 
be able to look at a class spec and know what it is going 
to do if Java claims to be Write Once Run Anywhere.
In the end, I had to borrow a Visual Basic EXE written by a 
friend which spawns a BAT file nice & quietly in the 
background - and it works fine on both 95 and NT. I'm sure 
it can't be that difficult to fix this bug.......

Try using a .bat file in windows or a script file for unix to run your java app.  That is what I did.  

Hey, gb071037.  

I guess "Write Once, Run Anywhere" != "Write Once, Run 
CONSISTENTLY Anywhere".  Hehehe.

-- Rick

had the same problem with a project spawning a program 
hundrends of times during just some minutes to run some 
external color calibration executable. You can imagine what 
was happening on the display with all those consoles 
opening and closing after a while, causing repaints to the 
Java/QTJava graphics on my app

only solution was to use java.exe instead of javaw.exe, it 
doesn't open any extra consoles per exec. Then I have to 
hide that first console using some shorcut settings to show 
it minimized or something like that

The Console window problems should be fixed in this way:

Runtime.exec() needs another parameter to spezify the
child process focus (gained or not) and window size
(maximize/minimize/hidden)

If hidden, the the child process's stdout/stdin must 
redirected
to the parent process. In all other cases there should be no
redirection

We solved this problem by using a Visual Basic EXE:
id = shell(C:\myprogram.exe,vbHide)
or
id = shell(C:\myprogram.exe,vbMinimizedNoFocus)

I just put my stuff (including images, sounds, and all class files) in an executable .jar file... Just double click 
that file and the program runs without an annoying pop up window. Looks great. Make sure to put a meta 
file in the .jar that tells java the name of the main class (the class with the main() method). 

#include <windows.h>
jdahms' fix works well for programs I run, but it does not let me
kill the ultimate target program I ran using Process.destroy() 
from Java (it just kills his little program).

Fortunately, the one I need to kill is an app I wrote. I simply
used that same WinMain entry point instead of 
the normal c/c++ main() and it does not come
up with a DOS window. This is all I used:

#include <process.h>

...

int WINAPI WinMain(HINSTANCE hInst, HINSTANCE 
  hPrevInstance, LPSTR lpCmdLine, int cmdShow)

and then compiled with MS Visual C++.

To all people citing Write Once, Run Anywhere: realize that by using Runtime.exec () you yourself 
compromise portability. I'm not saying this bug is lame, but I do think you wanna check if you really need 
that native process.

Good grief, PLEASE fix this in 1.4.

zenyata: I agree, but this is a particularly crushing bug 
for some environments. For instance, I'm on the development 
team for a Java IDE. IDEs need to invoke external tools a 
lot (e.g. source control tools such as CVS, compilers 
etc.). It's completely unforgivable for a console window to 
pop up each time you want to do this.

So many little bugs.  No wonder C++ still the tool of 
choice for standalone apps.  No wonder even new programs 
like Napster are not written in java.

Interestingly enough, oldjavaw does *not* have this problem.  Why is it so difficult to make javaw work in a 
similar manner?  oldjavaw (contrary to what the name implies) is not a backversion - it's 1.3 with hotspot 
support and all.  Just some differences in bootstrap classes and such.  C'mon Sun!!!  This one should be 
easy.

jdk 1.4 beta version is going to be release i hope so sun 
will fix this problem

Hmm. This bug is still marked as "not yet investigated" 
even though it was submitted nearly two years ago, and is 
the number one bug in the top 25. Argh.

  Happy Birthday Bug 4244515

Some bugs come and some bugs go.
  When's this bug going to be fixed? 
  That's what I'd like to know.

You're number six of 25 it's true.
  We thought you might be gone by now,
  but today you turn age two.

We all still use the work around,
  now that is just a shame.

Will you be there when Java's in the ground?
  And Sun will be to blame.  

----

Java Lover's Unite: vote often and early for this one!

2 years old, and 478 votes so far, and still no fix?

Sun, please try not to suck so very hard, you'll turn 
inside out.

Hurry!!!!! Please!!!!! Pretty Please!!!!!!!

Anybody know if this was fixed in the 1.4 advance?

The code offered by jdahms (what I call "launch.exe") works 
great, especially since I have zero experience with win32 
(I was blown away by how broken the win32 process model 
is!!! Could it be any more twisted?). Thanks jdahms!

One problem however is the killing of the process. When you 
call Process.destroy() it kills the "launch.exe" wrapper 
program, but the kill does not propogate to the program you 
originally wanted to launch. I tried to figure out a way to 
register some callback to receive notification in 
the "launch.exe" program that a termintate (SIGTERM in Unix 
parlance) has been requested so that it can be propogated 
to the child process. None of the callback routines seem to 
get called (they appear to be for window executables, not 
console ones). Nor does win32 propogate the terminate 
request/signal to the child process (like it would under 
Windows). The result is that calling Process.destroy() 
causes the Java to think the process has been killed, but 
in reality you've just orphaned the process.

Anyone had any luck here? At this point I'm tempted to 
implement my own .dll for the process class so that 
Process.destroy() kills the right process.

It's been over a year since the last update... and users 
are using native code to work around the problem.  It's the 
highest rated bug in the pile.

What's up sun?

Get it done already.

If java.exe works and javaw.exe does not, this is a choice 
Sun has made.  Who can say why? It seems a very ignorant 
one.

What is meant by CREATE_ON_WINDOW does not work well on 
win9x?  Is that a cop out, or will you expound?

Please, what else is it that you do?  Fix this. I agree its 
so hard making programs have some level of professionalism 
with Java...

It seems clear to me that Sun are no longer paying 
attention to Java developers. This bug has been around for 
2.5 years and has been the number one voted bug for several 
months, and yet the dev status in the licensee bug database 
still has it marked as "not yet investigated". Presumably 
this means Sun have no intention of fixing this problem in 
1.4, so we're going to have to wait at least another year 
or more until a JDK ships that has a fix for this problem.

Please fix this!  This is causing a big problem for us.

This is such an annoying problem, please fix it.

As well, I think that this is a ridiculous bug and the fact 
that it is over 2 years old is shameful !!!!

The C++ code that jdahms [see comment posted THU MAY 11 
06:22 A.M. 2000] supplied is a godsend. It works really 
well and is the best workaround that I could find.

A word to the wise. I used Microsoft VC++ 6.0 to build it. 
Make sure that the Link tab on Project>Settings 
has /subsystem:windows and not /subsystem:console in the 
Project Settings area [this took me a little while to 
figure out, me not being too bright with C++]

FYI: I was able to compile jadams code using cygwin's gcc, 
which is great for those of use that don't have the MS 
tools.

I use the netbeans IDE, and noticed that it doesn't have 
the same problem when it launch sub-processes. I looked at 
their source code, and I speculate that this is because the 
IDE is started via a custom "runide.exe" executable that 
sets some of the flags that jadams' work-around uses. So 
one work-around option would be to modify the "runide.exe" 
code (it's open source, www.netbeans.org) for your own 
application and have it started via the executable rather 
than Java directly.

tnx for fixing this.

Since this one took Sun so long to look at, I'm guessing 
Win32 is not their strong suit.  

Someone needs to verify that the fix is correct - of the 
form used in the example provided by jdahms@rim.net (I have 
used very similar code in a number of my applications).

Is the fixed code available for review?

Yippee!!! Thanks for fixing this! When is beta3 available?

I've reviewed the fixed code in a pre-beta3 build. I don't 
know whether our license allows me to post a diff, but the 
fix was very trivial (~2 lines), and is very similar to the 
suggested fix in the workaround by jdahms. Yay!

From the 2001-10-18 comment it appears that fix was backed 
out.  While I understand the reason for backing out the 
fix.  The ideal would be an API that exposed both 
behaviors.  I would suggest that the "don't show the 
window" default is preferable.

First there is currently *no* clean workaround for starting 
another process "quietly" (i.e. with no annoying unneeded 
console windows).  I believe there is a workaround for 
launching GUI applications - simply use a small platform-
specific "helper" program.

Second the "quiet" default is more in line with the goal of 
writing portable applications using Java.  In my 
application I may need to write small platform specific 
native code helper applications, with the majority of the 
application in Java.  If I cannot cleanly and quietly 
launch these helpers (shipped with my application) from 
Java, then you've made my job a lot more difficult.

I believe the "quiet" launch is the more appropriate and 
preferable default behavior.

This behavior is unacceptable. Add to the API.

Why not hide it if it is a console app, and show it if it 
is a GUI app (native Win32 app)? The Runtime API doesn't 
need to expose this - I think it is safe to assume 
developers want GUI apps visible and console apps invisible.

You can peek at the EXEheader Subsystem field of the on-
disk EXE to determine if it is a console or GUI app.
See MS KB article Q90493
http://support.microsoft.com/support/kb/articles/Q90/4/93.AS
P

See Q190351 for how to hide it if it is console (set 
STARTUPINFO.wShowWindow=SW_HIDE)
http://support.microsoft.com/support/kb/articles/Q190/3/51.A
SP

I got so fed up about this that I decided to write Scott 
McNealy directly. My email to him is below, followed by the 
nice response I received. 

However, I think the real solution is not in changes to the 
Runtime.exec code, but in the way that javaw is launched. 
javaw should be launched just like java, but with the 
console hidden (not removed), as shown in the jadams hack. 
I believe this is how netbeans is launched so that all the 
subprocesses don't show consoles.

Anyway, here's the mail.

--------------------------

Mr. McNealy,

I'm writing you on behalf of the Java developer community 
asking that JavaSoft 
provide more information on the most highly voted bug on 
the Java Bug Parade, 
#4244515. This bug has been in the system for over 2.5 
years, has been the #1 
voted for bug for months, and currently has 738 votes 
(almost 300 more votes 
than the next highest bug). A bug related to this, 
#4109888, has 182 votes.

http://developer.java.sun.com/developer/bugParade/bugs/42445
15.html

I am writing directly to you because the developer 
community has repeatedly
requested more information from JavaSoft on the fix-status 
of this bug,
and has not received any (at least public) response. 
Frustration with this
issue is very high, as it affects the professional quality 
of many Java
applications.

My request is that you have a production manager or other 
senior person at
JavaSoft write up a short article on JavaSoft's analysis of 
the bug,
it's plans for fixing it, and an approximate release 
schedule for the bug,
and post this article somewhere on the Developer's
connection. Not only would this help the developer 
community plan their own
release schedules around JavaSoft's approach to this bug, 
but would also
calm a lot of frustration due to the lack of dialog.

Thank you for your time.

Respectfully,

Simeon Fitch

-------------------

Simeon,

Thank you for writing Scott.  Let me introduce myself.  I'm 
the Engineering 
Manager responsible for most of java.lang, java.io, 
java.nio, java.util, 
java.math, Serialization, Reflection, javac, javadoc, 
javah, and javap.  As you 
can see, my team is one of the core teams for the Java 
platform, and the areas 
we are responsible for are far reaching.

My team inherited portions of java.lang that the Classic VM 
team had been 
maintaining.  Runtime was one of those classes.  We are 
ramping up our expertise 
in this area, but Windows is difficult to master in this 
regards.

I did get this email, passed down from Scott.  My team has 
been swamped fixing 
last minute bugs in new features, and we haven't given high 
JDC vote count bugs 
adequate time in our engineering cycle.  Sorry about that.

We quickly began looking into this bug, and applied a fix 
very similiar to code 
posted in the JDC comments to hide the console window.  
Indeed, it does hide the 
window.  Unfortunately, if a native Windows application is 
launched, such as 
calc.exe, the calculator runs, yet runs hidden.  Not 
effective at all, and 
definitely a regression.

We think at this time that command-line applications on 
Windows must start a 
console.  We are investigating that fact, and if there is a 
way to determine if 
an application is a console application or a native GUI 
application, and doing 
the right thing.

At this time, we are preparing to pull the fix out of what 
will shortly be 
released as Merlin Beta 3.  We will continue to investigate 
the issue, in hopes 
that we can determine a proper fix for Merlin RC or Merlin 
FCS.  We will be 
updating the evaluation in the coming days in an effort to 
keep the JDC 
community updated with our progress.

Any questions, please let me know.


Andrew
--
  Andrew Bennett
  andrew.bennett@sun.com
  Tools & Core Libraries Engineering Manager, Core Java, 
J2SE
  

:)

If the fix for merlin beta3 has been backed out why is the 
bug still marked closed/fixed?

Could someone please fix the bug system. The fact that this
bug is marked fixed is at least highly deceptive.

It appears that the Process API needs a switch depending on
which a console window is shown or hidden.

The following lines of code will be helpfull for those of 
You using Runtime.exec() to start their own apps. Add the 
following lines of code just at the beginning of Your main() 
method:

/*I use WINNT for the preprocessor*/
#ifdef WINNT
   BOOL ok;
   /*A process can use the FreeConsole function to detach      
     itself from its console*/
   ok = FreeConsole();
   /*Something went wrong*/
   if (ok == 0) {
      DWORD errormsg;
      errormsg = GetLastError();
      printf(stderr, "%s\n"errormsg);
      exit(1);
   }
#endif

I hope this will be helpfull. Good luck

still broken in j2sdk1.4.0-rc

No, it works fine now

with the code below, on 1.3, I get 10 console windows. 
With 1.4rc, they're gone. woo.

public class Class1 
{
  public static void main( String[] args )
    throws Exception
  {
    for ( int i=0; i < 10; i++ )
    {
      Runtime.getRuntime().exec( "cvs -version" );
    }
  }
}

Still borken under windows ME under 1.4.0-rc

Paul, I quote from Sun's comments above:

"The console window may still flash by for
win9X users if they invoke a 16-bit application but we do 
not know how to work around that."

Are you seeing this with 32-bit apps?

Using the javaw command in a .BAT startup file on Win9x 
works.  On the various versions of NT it doesn't, unless 
you use the "start" command to run javaw.

NT example:

  start javaw MyClass


Of course, this means your startup .BAT file will require a 
test for Win9x vs WinNT since the "start" command will 
not work on Win9x.

So? Is this bug fixed in JDK1.4 any way. I am still using 1.3.1.

Note to Sun engineering: when launching external processes 
on Windows, the Windows version of Emacs determines the 
type of the external process and hides the associated if the 
process is a character app and either shows (the default) or 
hides the the window if it's a GUI app, depending on the value 
of a Lisp variable that the user can set. The ability to hide 
the window of a GUI app was added specifically to 
accommodate use of javaw. exe to launch Java apps.  It 
would be great if Runtime.exec could follow this model. See 
the source for the Emacs create_process in process.c, 
w32proc.c, and callproc.c (readily available at gnu.org) for 
the technique that Emacs uses to determine the type of the 
process to be created and to hide the windows of the apps 
that it launches.

Can somebody from Sun actually comeout and say which 
versions of WinX this has been fixed.I am on WinNT

Thanks

This workaround will only work if you are launching a custom application, i.e. one that you can change:

Make sure the application that is being started doesn't use stdio and stderr, i.e. that it is a windows application, not a console application.  Use sockets to communicate to it.

You can have one socket to simulate stdin and one to simulate stderr.  Use Socket.getInputStream for each socket instead of Process.getErrorStream and Process.getInputStream.  The application won't have to be run in the background, and you will be able to get exit status from it.

You will also need to dedicate one port for each socket.