On Sun, May 11, 2003 at 01:47:46AM +0900, Simon Strandgaard wrote:
> >> The first 4 of them seems OK.. the rest of them is where I see 
> >> that windows requirs special attention. Windows is wierd.
> > 
> > It is, but Ruby has coded around those things, so you don't have to worry
> > about them. To me that's one of the big advantages of a high-level platform
> > like Ruby: one person solves the problem once and then your code works the
> > same.
> 
> Remember im living in a zone between Ruby and C++.. I am a little worried 
> about supporting windows myself.

There's no need to. When you run a standalone Ruby script, it's just the
same as a trivial embedded app: main() calls the initialisation functions,
runs your script, then exits.

If you want your C++ program directly to open pipes and fork() and exec()
children, then of course you will get into OS-specific issues, especially
where Windows doesn't follow POSIX. But that's a C++ programming problem.
Presumably one of the advantages of embedding Ruby is that you can delegate
those sort of tasks to it.

> > In general, if I wanted to run some program which interacted over
> > stdin/stdout, but I wanted that interaction to occur inside a GUI window, I
> > would create a window, fork and exec a child, and talk to it over pipes, so
> > that I could capture keystrokes and send them down stdin, and capture stdout
> > and stick it on the screen as it was generated.
> 
> Remember that im sharing classes with those programs (c++ <=> ruby),
> marshalling it over a pipe would be slow (but I have no evidence here). 
> What you talking about is a ruby-jail ;-)

It's two different execution models:

  - interactive stdin/stdout (e.g. Test::Unit running in its console
    mode): you just run it like any other program, as a child process with
    stdin/stdout communicating over pipes

  - genuine embedded app: you call its methods. If you didn't want it
    to write to stdout or read from stdin, then you wouldn't write it
    in such a way that it did. (For example you wouldn't call 'gets'
    to receive input; you'd wait for C++ to pass you the next string)

Regards,

Brian.