On 21 May 2012 03:29, Igor Stasenko <siguctua@gmail.com> wrote:
On 21 May 2012 02:16, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Sun, May 20, 2012 at 4:59 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 20 May 2012 21:34, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Torsten,
On Sun, May 20, 2012 at 11:51 AM, Torsten Bergmann <astares@gmx.de> wrote:
Hi,
havent yet played with the latest stdin/stdout stuff. Does this already work on Windows?
At least I tried
FileStream stdout nextPutAll: 'Yopla'
in the latest 2.0 after starting Pharo-2.0-one-click.bat. Gives an error (write failed).
Any comments?
It works in my console VMs.  If you download e.g. http://www.mirandabanda.org/files/Cog/VM/VM.r2550/cogwin.zip you need to run CroquetConsole.exe in a DOS or Cygwin window.  Using the normal VM does *not* work, since that's the way Windows is "designed".
Nope. It just requires some work :)
Come on :) Â The program opening up a completely different console isn't what I'd call working. Â And if the program is in a pipe ist must stay in a pipe. Â Its an easy thing to have a console VM, e.g. run from a script.
Here, what i found (windoze 7/ gcc 4.6.1).
Test code (test.c) - note the entry point is WinMain() , not main() : --------------------- #include <windows.h> #include <stdio.h>
int APIENTRY Â WinMain( Â HINSTANCE hInstance, Â Â HINSTANCE hPrevInstance, Â Â LPSTR lpCmdLine, Â Â int nCmdShow ) { Â Â Â Â FILE *f; Â Â Â Â STARTUPINFO info; Â Â Â Â GetStartupInfo( &info);
    f = fopen("test.out","w");
    fprintf(f, "stdin: %d stdout: %d stderr: %d\n", info.hStdInput , info.hStdOutput, info.hStdError);
    fprintf(f, "STD handles: stdin: %d stdout: %d stderr: %d\n", GetStdHandle(STD_INPUT_HANDLE) , GetStdHandle(STD_OUTPUT_HANDLE) ,         GetStdHandle(STD_ERROR_HANDLE));
    fclose(f);  return 0; } ---------------------
gcc test.c
Running from mingw bash shell:
a.exe
stdin: 11 stdout: 23 stderr: 27 STD handles: stdin: 11 stdout: 23 stderr: 27
a.exe < test.c
stdin: 168 stdout: 23 stderr: 27 STD handles: stdin: 168 stdout: 23 stderr: 27
a.exe | less
stdin: 11 stdout: 328 stderr: 27 STD handles: stdin: 11 stdout: 328 stderr: 27
Running from cmd shell:
a.exe
stdin: -1 stdout: -1 stderr: -1 STD handles: stdin: 3 stdout: 39 stderr: 15
a.exe < test.c
stdin: -1 stdout: -1 stderr: -1 STD handles: stdin: 80 stdout: 39 stderr: 15
a.exe | more
stdin: -1 stdout: -1 stderr: -1 STD handles: stdin: 3 stdout: 108 stderr: 15
Running from explorer:
stdin: -1 stdout: -1 stderr: -1 STD handles: stdin: 3 stdout: 7 stderr: 11
***** Â Now, if i compile with:
gcc test.c -mwindows
under bash :
a.exe
stdin: 11 stdout: 23 stderr: 27 STD handles: stdin: 11 stdout: 23 stderr: 27
under cmd
stdin: -1 stdout: -1 stderr: -1 STD handles: stdin: 3 stdout: 39 stderr: 15
from explorer:
stdin: 0 stdout: 65537 stderr: 0 STD handles: stdin: 0 stdout: 0 stderr: 0
Conclusion: Â - do not use -mwindows
ehh.. if not used, it will open annoying console window, since -mconsole is default... however, as you can see, if you run exe from shell, the handles are there. So, you can use single binary (compiled with -mwindows) for both shell/explorer interaction, and you can actually detect where it runs from by checking contents of STARTUPINFO struct.
 - use GetStdHandle() for reliable results.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.