On Sun, May 20, 2012 at 6:52 PM, Igor Stasenko <siguctua@gmail.com> wrote:
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.

If you can figure out how to suppress the annoying console window then I'd use a single executable.

> �- use GetStdHandle() for reliable results.
>
> --
> Best regards,
> Igor Stasenko.



--
Best regards,
Igor Stasenko.




--
best,
Eliot