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 :) *** One of the common misconceptions surrounding Win32 programming is that you must decide early in the design process whether your application will be a console or GUI application. In reality, console applications can create windows and have a message loop just like a GUI application (see "Adding Graphics to Console Applications" by Michael Covington, Visual Developer, June/July 1997). Alternatively, graphical applications can create and use a console. Although Win32 provides functions for communicating with a console, they are a little clumsy to use and require parameters that are unnecessary for simple text I/O. This article shows how to use standard C/C++ I/O with consoles, and how to work around specific problems in the Visual C++ I/O library. *** http://dslweb.nwnexus.com/~ast/dload/guicon.htm

-- best, Eliot

-- Best regards, Igor Stasenko.

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 - use GetStdHandle() for reliable results. -- Best regards, Igor Stasenko.

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

Not sure if this is applicable but I bumped into an article [1] which seems to provide a way to get StdIn/StdOut working. The requirement for WSH 5.6 would seems to be covered as [2] is dated 2000 and talks about 5.6 being preinstalled in Whistler, which was development codename for XP - which should cover pretty much everyone. I had got annoyed at Pharo-1.4-one-click.bat leaving a console window open when starting Pharo 1.4, so I re-implemented this as Pharo-1.4-one-click.vbs using Pharo-1.4-one-click.sh as a template. I have attached this to Issue #6020 [3]. [1] http://technet.microsoft.com/en-us/library/ee156605.aspx [2] http://msdn.microsoft.com/en-us/library/ms974613.aspx [3] http://code.google.com/p/pharo/issues/detail?id=6020 Igor Stasenko wrote:

On 21 May 2012 19:01, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

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.

please read my post again. i said that binary compiled with -mwindows can be used both for console and explorer interaction(s). all you need is to rebind std handles to C .. btw there's actually already parts of code which using GetStdHandle():

void SetupStderr() { TCHAR tmpName[MAX_PATH+1];

*stderrName = *stdoutName = 0; /* re-open stdout && stderr */ GetTempPath(MAX_PATH,tmpName); if(GetStdHandle(STD_ERROR_HANDLE) == INVALID_HANDLE_VALUE) { GetTempFileName(tmpName,TEXT("sq"),0,stderrName); freopen(stderrName,"w+t",stderr); } else *stderrName = 0;

if(GetStdHandle(STD_OUTPUT_HANDLE) == INVALID_HANDLE_VALUE) { GetTempFileName(tmpName,TEXT("sq"),0,stdoutName); freopen(stdoutName,"w+t",stdout); } else *stdoutName = 0; }

---- but it looks like there is no callers and it does redirection if handles are invalid.

if they are valid, i think they should be already set up correctly and if not, in the link which i put first in this topic, it is clear how to do it:

(http://dslweb.nwnexus.com/~ast/dload/guicon.htm)

// redirect unbuffered STDOUT to the console

lStdHandle = (long)GetStdHandle(STD_OUTPUT_HANDLE);

hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);

fp = _fdopen( hConHandle, "w" );

*stdout = *fp;

setvbuf( stdout, NULL, _IONBF, 0 ); ------------- so, if VM runs from console, there should be an access to its stdin/out/err as you normally expect from posix environment.

if VM started from explorer -> there will be no stdin/out/err handles bound to process, then we can simply redirect all to /dev/null or to some file, like SetupStderr() function does. (http://stackoverflow.com/questions/313111/dev-null-in-windows)