?s about Process Class

java-programmer, ?s about Process Class I have a DOS program I am trying to supply input to using Java.
Reading from The Java Class Libraries, 2nd Ed. java.lang.Process class -
the material presented seems to imply that I will be able to do
this.

The program most definately uses just stdio... (in) being the keyboard and
(out) being the consol.

Well I can't get it to work and being the presistant bugger that i am I have
switch tactics so I can more up the learning curve.
I have resorted to just trying to display the output of mem.exe.

here is the source ::: test.java

import java.io.*;
import java.lang.*;

public class test
{ public static void main(String[] args)
{
int ch;
int status;

try
{
Process process = Runtime.getRuntime().exec("mem.exe");
InputStream in = process.getInputStream();
BufferedInputStream buf = new BufferedInputStream(in);

//try
//{
//status = process.waitFor();
//}
//catch (InterruptedException e) {status = -1;}

try
{
while((ch = buf.read()) != -1)
{
System.out.print((char)ch);
}

}
catch (IOException e) {System.out.println(e);}
//in.close();
//buf.close();
//process.destroy();
//Runtime.getRuntime().gc();
//Runtime.getRuntime().exit(-1);
//System.out.print('\n');
}
catch (IOException e) {System.out.println(e);}
}
}

It works the first time I run the class file with java test.
However, the next attempt hangs and requires a system restart inorder to get
the code to display the results.

The commented code in test.java are my attempts to do various things to
clean up this issue of not displaying the results.

Does anyone have a clue or suggestion...

thanks,
publius36

java-programmer >> ?s about Process Class publius36 wrote:
> Well I can't get it to work and being the presistant bugger that i am I have
> switch tactics so I can more up the learning curve.
> I have resorted to just trying to display the output of mem.exe.

Okay. I have a number of comments. Many of them are not necessarily
related to the specific problem you've got, but here they are anyway.

First,

> while((ch = buf.read()) != -1)
> {
> System.out.print((char)ch);
> }

BufferedInputStream reads bytes. System.out writes characters (it's a
rather confused case, actually, but if you call its "print" method that
it writes characters.) Bytes and characters are *not* the same thing.
The right way to do this is to use an InputStreamReader to convert from
bytes to characters.

InputStream in = process.getInputStream();
BufferedInputStream buf = new BufferedInputStream(in);
InputStreamReader r = new InputStreamReader(buf);

then

while ((ch = r.read()) != -1)
{
System.out.print((char) ch);
}

then

r.close();

The way you've written your code only happens to work because your
system default character encoding matches the byte-truncation of unicode
for all characters that you read. As the system's default encoding
changes, or as you start working with programs that output different
characters such as accented or non-latin characters, the code will
suddenly break. InputStreamReader solves that problem.

> It works the first time I run the class file with java test.
> However, the next attempt hangs and requires a system restart inorder to get
> the code to display the results.

Actually, it probably requires killing the runaway NTVDM process on
Windows. There is a bug in modern 32-bit Windows operating systems
running a 16-bit process in a way that doesn't attach it to a physical
console, and this causes NTVDM to become confused. Since mem.exe is
just a test program for you, the answer is to choose a different program
to test with. Try "ipconfig.exe" instead.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

java-programmer >> ?s about Process Class understood the things you stated, was very much aware of the need for using
a reader
i choose not to in test, trying to trouble shoot and much hair pulling
later stated paring down the code...
i know i'm not reading characters, hence

int ch;

i'm reading bytes from the BufferInputStream hence the type cast to (char)
in the statement
System.out.print((char)ch

was trying to answer the question do i have the inputstream from the
sub-process
plugged into a buffer created by main that i can dump.

it is the second observation :

>
> Actually, it probably requires killing the runaway NTVDM process on
> Windows. There is a bug in modern 32-bit Windows operating systems
> running a 16-bit process in a way that doesn't attach it to a physical
> console, and this causes NTVDM to become confused. Since mem.exe is
> just a test program for you, the answer is to choose a different program
> to test with. Try "ipconfig.exe" instead.
>
it never ceases with billybob's MS OS's crap
anyway, thanks for the help...
since my program is definately a legacy 16-bit program
i could be barking up a tree here.
still i'll try using ipconfig.exe, just to learn a little bit more and do as
you say
get the readers and writers in place.

thanks for your timely help
sincerely, pub

"Chris Smith" <email***@***.com> wrote in message
news:email***@***.com...
> publius36 wrote:
> > Well I can't get it to work and being the presistant bugger that i am I
have
> > switch tactics so I can more up the learning curve.
> > I have resorted to just trying to display the output of mem.exe.
>
> Okay. I have a number of comments. Many of them are not necessarily
> related to the specific problem you've got, but here they are anyway.
>
> First,
>
> > while((ch = buf.read()) != -1)
> > {
> > System.out.print((char)ch);
> > }
>
> BufferedInputStream reads bytes. System.out writes characters (it's a
> rather confused case, actually, but if you call its "print" method that
> it writes characters.) Bytes and characters are *not* the same thing.
> The right way to do this is to use an InputStreamReader to convert from
> bytes to characters.
>
> InputStream in = process.getInputStream();
> BufferedInputStream buf = new BufferedInputStream(in);
> InputStreamReader r = new InputStreamReader(buf);
>
> then
>
> while ((ch = r.read()) != -1)
> {
> System.out.print((char) ch);
> }
>
> then
>
> r.close();
>
> The way you've written your code only happens to work because your
> system default character encoding matches the byte-truncation of unicode
> for all characters that you read. As the system's default encoding
> changes, or as you start working with programs that output different
> characters such as accented or non-latin characters, the code will
> suddenly break. InputStreamReader solves that problem.
>
> > It works the first time I run the class file with java test.
> > However, the next attempt hangs and requires a system restart inorder to
get
> > the code to display the results.
>
> Actually, it probably requires killing the runaway NTVDM process on
> Windows. There is a bug in modern 32-bit Windows operating systems
> running a 16-bit process in a way that doesn't attach it to a physical
> console, and this causes NTVDM to become confused. Since mem.exe is
> just a test program for you, the answer is to choose a different program
> to test with. Try "ipconfig.exe" instead.
>
> --
> www.designacourse.com
> The Easiest Way to Train Anyone... Anywhere.
>
> Chris Smith - Lead Software Developer/Technical Trainer
> MindIQ Corporation

java-programmer >> ?s about Process Class ipconfig is work well for test purposes..

however the code frag you gave...

> InputStream in = process.getInputStream();
> BufferedInputStream buf = new BufferedInputStream(in);
> InputStreamReader r = new InputStreamReader(buf);

won't work : syntax ---> public InputStreamReader(InputStream in)
you are supplying a BufferedInputStream object and not the required
InputStream object

the correct code frag should be :

InputStream in = nhProcess.getInputStream();
InputStreamReader r = new InputStreamReader(in);
BufferedReader buf = new BufferedReader(r);

to achieve what you intended.
even though the syntax for BufferedReader is
public BufferedReader(Reader obj)
I think it works because the Reader object is the superclass
of all readers, and why it can handle the InputStreamReader object.

"Chris Smith" <email***@***.com> wrote in message
news:email***@***.com...
> publius36 wrote:
> > Well I can't get it to work and being the presistant bugger that i am I
have
> > switch tactics so I can more up the learning curve.
> > I have resorted to just trying to display the output of mem.exe.
>
> Okay. I have a number of comments. Many of them are not necessarily
> related to the specific problem you've got, but here they are anyway.
>
> First,
>
> > while((ch = buf.read()) != -1)
> > {
> > System.out.print((char)ch);
> > }
>
> BufferedInputStream reads bytes. System.out writes characters (it's a
> rather confused case, actually, but if you call its "print" method that
> it writes characters.) Bytes and characters are *not* the same thing.
> The right way to do this is to use an InputStreamReader to convert from
> bytes to characters.
>
> InputStream in = process.getInputStream();
> BufferedInputStream buf = new BufferedInputStream(in);
> InputStreamReader r = new InputStreamReader(buf);
>
> then
>
> while ((ch = r.read()) != -1)
> {
> System.out.print((char) ch);
> }
>
> then
>
> r.close();
>
> The way you've written your code only happens to work because your
> system default character encoding matches the byte-truncation of unicode
> for all characters that you read. As the system's default encoding
> changes, or as you start working with programs that output different
> characters such as accented or non-latin characters, the code will
> suddenly break. InputStreamReader solves that problem.
>
> > It works the first time I run the class file with java test.
> > However, the next attempt hangs and requires a system restart inorder to
get
> > the code to display the results.
>
> Actually, it probably requires killing the runaway NTVDM process on
> Windows. There is a bug in modern 32-bit Windows operating systems
> running a 16-bit process in a way that doesn't attach it to a physical
> console, and this causes NTVDM to become confused. Since mem.exe is
> just a test program for you, the answer is to choose a different program
> to test with. Try "ipconfig.exe" instead.
>
> --
> www.designacourse.com
> The Easiest Way to Train Anyone... Anywhere.
>
> Chris Smith - Lead Software Developer/Technical Trainer
> MindIQ Corporation

java-programmer >> ?s about Process Class publius36 wrote:

[Chris Smith wrote:]
>> InputStream in = process.getInputStream();
>> BufferedInputStream buf = new BufferedInputStream(in);
>> InputStreamReader r = new InputStreamReader(buf);
>
>
> won't work : syntax ---> public InputStreamReader(InputStream in)
> you are supplying a BufferedInputStream object and not the required
> InputStream object

A BufferedInputStream *is* an InputStream. Chris' code fragment will
work just fine.

John Bollinger
email***@***.com