请教 Runtime.getRuntime().exec()本地执行的奇怪问题！

Question

程序是两个计算机通过建立socket通讯，client发命令给server来执行本地的一个install.bat命令，命令中为调用一个java命令行形式来copy安装文件。别用两个线程来处理process.getErrorStream()和process.getInputStream()执行已经可以了，可以输出执行的信息。但是用exec()执行的结果与直接在命令行运行run.bat的结果不一直。总是有几个文件遗漏拷贝，奇怪了怎么回事？观察两种执行时，发现输出的顺序不是全部一样，为什么？
还望赐教！！

Answer 1

为什么直接在命令行允许可以成功，而用exec允许不行呢？exec是运行在windows2000上。
exec执行的install.bat里面是用命令行启动一个java的copy安装程序。还望赐教 ！

Answer 2

为什么直接在命令行运行可以成功，而用exec运行有问题呢？exec是运行在windows2000上，是不是exec执行的程序对错误比较敏感？
exec执行的install.bat里面是用命令行启动一个java的copy安装程序。还望赐教 ！

Answer 3

昨天定位了一下，辅助大家帮忙定位：
1、process.getErrorStream()和process.getInputStream()两个线程运行输出不同步，两个线程分别把信息显示出来，我把直接命令运行和Runime执行的输出结果对比，发现顺序不全相同！！
2、process.getErrorStream()和process.getInputStream()两个输出信息是直接放入到TextArea里的，没有使用ConsoleTextArea！
3、没有处理process.getOutputStream()
4、工存在线程1）接收socket 2）处理Error流线程、3）处理Input线程
5、点击x关闭窗口，线程没有正常推出。

Answer 4

JDK1.4.2中对Runtime.exec的解释，may not work well for special processes ，我可能要放弃这种方式了，准备用JNI的方式了。The Runtime.exec methods may not work well for special processes on certain native platforms, such as native windowing processes, daemon processes, Win16/DOS processes on Microsoft Windows, or shell scripts. 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 (Process.getOutputStream(), Process.getInputStream(), Process.getErrorStream()). The parent process uses these streams to feed input to and get output from the subprocess. Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, and even deadlock. The subprocess is not killed when there are no more references to the Process object, but rather the subprocess continues executing asynchronously. There is no requirement that a process represented by a Process object execute asynchronously or concurrently with respect to the Java process that owns the Process object.