Re: Using binary data with process.standardInput/StandardOutput

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Ah. I didn't think of that, but it makes perfect sense. I haven't solved
this problem before, but I've sure seen it.

History lesson: The notion of stdin and stdout comes from Unix. It was
adopted into DOS in its early days when C was becoming a popular way to
write programs for DOS. In Unix (of the time), stdin and stdout were simply
buffered pipes. In other words, you have a specific buffer size and, when
it is full, the process sending the data would be stopped until the process
receiving the data caught up and consumed it. DOS did its best to emulate
that. For the most part, they succeeded.

The problem is that this mechanism was designed for one app to pipe to
another, not for a controller app to pipe to a child. In other words, you
are supposed to give the command: "myapp | nextapp" at the command line, and
let DOS handle the controlling. In this context, 'myapp' is triggered and
runs until the buffer fills up. Then, 'nextapp' runs until the buffer is
largely consumed. Then 'myapp' continues until the buffer is full again...
and the dance goes on.

You haven't recreated this interaction in your app. Therefore, the buffer
fills and everything stops.

You could solve this by having a portion of your app run standalone, and use
the "pipe" notation above. Not elegant.

Alternative: write all of the data to a file and issue the command using the
"<" notation:

In other words, create a file that you intend to feed into input (I'll call
it "mytempfile.dat") and then issue the command:
"nextapp <mytempfile.dat"

Hope this helps

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Hanika" <Hanika@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A82B776A-9082-4D4C-9849-16E1D144BCF2@xxxxxxxxxxxxxxxx
> Thanks for your response.
>
> I changed my code to use binary reader and access the basestream. I have
> run into a new problem: The basestream write gets stuck when I try
> propcessing files pver aprox 60 KB. It works fine for files under that
> size.
> Here is my code:
>
<<code clipped>>



.

Relevant Pages

  • Re: Using binary data with process.standardInput/StandardOutput
    ... trying to achieve the same semantics as the command processor. ... you have a specific buffer size ... not for a controller app to pipe to a child. ...
    (microsoft.public.dotnet.framework)
  • Re: bi-directional IPC / pipes / when to close??
    ... > works if I close the pipe after the write, ... There's not a lot you can do when you're trying to interact with a command ... One very complicated solution is to make the standard input of the command ... that wants to buffer a terminal device instead of a pipe. ...
    (comp.unix.programmer)
  • Re: bi-directional IPC / pipes / when to close??
    ... >> works if I close the pipe after the write, ... > There's not a lot you can do when you're trying to interact with a command ... > that wants to buffer a terminal device instead of a pipe. ... > buffer until it gets an EOF. ...
    (comp.unix.programmer)
  • Capturing stdin/stdout for called processes
    ... For example, when calling another command line app, in C++ it's ... pretty trivial to catch the stdout with a pipe, but I can't seem to get it ...
    (alt.comp.lang.borland-delphi)
  • Capturing stdin/stdout for called processes
    ... For example, when calling another command line app, in C++ it's ... pretty trivial to catch the stdout with a pipe, but I can't seem to get it ...
    (comp.lang.pascal.delphi.misc)