[clean-list] console program

[John van Groningen]

Sven Eric wrote:
>I have a clean program, which reads the program arguments 
>and makes some file I/O. I want to call this clean program from a
>java program using the java exec method. However, when I compile
>the clean program with the no console option, a new command line
>window pops up during execution. I do not whant this behaviour. 
>On the other hand, if I compile the clean program without the no console
>option, then it only exists after I pressed return.  How can I avoid this?
>Even bader is, that if the clean program aborts with an error, then 
>it always seems to need the return key to be pressed, in order to exit.
>
>Has anyone a tip for me, or any experiences with this?
>
>My environment is the windows version of clean.

If you compile a clean program with the no console option enabled, the
runtime system of clean will only create a console if something is written
to standard out or standard error. Because the result of the Start function
of the program is not written to standard out in this case, a console window
is only created if it writes to a standard file using functions in StdFile, or
when the runtime system has to print something, for example to display an
error (if you use abort for example), or the execution time or heap or stack
size.

If you do not enable the no console option, the console is always created
by windows, not by the clean runtime system. You can prevent this by
changing the byte at offset 0x9c in the executable from 3 (window CUI
subsystem) to 2 (windows GUI subsystem). I used a hex editor to this.
The clean program will always wait for a key press if the no console option
is disabled, but if windows does not create a console, this read functions
seems to return immediately.

We have added a "-con" flag to tell the clean runtime system not to create
a console and not to wait until a key is pressed. Unfortunately this has
not been tested yet, but if you want try this, I will send you the modified
object files of the runtime system.

Regards,
John van Groningen