STDIO on Win
Locked
 
|
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? Thx T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de |
|
|
Hi Torsten,
On Sun, May 20, 2012 at 11:51 AM, Torsten Bergmann <[hidden email]> wrote: -- Hi, 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".
best, Eliot |
|
|
On 20 May 2012 21:34, Eliot Miranda <[hidden email]> wrote:
> Hi Torsten, > > On Sun, May 20, 2012 at 11:51 AM, Torsten Bergmann <[hidden email]> 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". > *** 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 Sun, May 20, 2012 at 4:59 PM, Igor Stasenko <[hidden email]> wrote:
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.
best, Eliot |
|
|
On 21 May 2012 02:16, Eliot Miranda <[hidden email]> wrote:
> > > On Sun, May 20, 2012 at 4:59 PM, Igor Stasenko <[hidden email]> wrote: >> >> On 20 May 2012 21:34, Eliot Miranda <[hidden email]> wrote: >> > Hi Torsten, >> > >> > On Sun, May 20, 2012 at 11:51 AM, Torsten Bergmann <[hidden email]> >> > 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 21 May 2012 03:29, Igor Stasenko <[hidden email]> wrote:
> On 21 May 2012 02:16, Eliot Miranda <[hidden email]> wrote: >> >> >> On Sun, May 20, 2012 at 4:59 PM, Igor Stasenko <[hidden email]> wrote: >>> >>> On 20 May 2012 21:34, Eliot Miranda <[hidden email]> wrote: >>> > Hi Torsten, >>> > >>> > On Sun, May 20, 2012 at 11:51 AM, Torsten Bergmann <[hidden email]> >>> > 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. |
|
|
On Sun, May 20, 2012 at 6:52 PM, Igor Stasenko <[hidden email]> wrote:
If you can figure out how to suppress the annoying console window then I'd use a single executable.
best, Eliot |
|
|
On 21 May 2012 19:01, Eliot Miranda <[hidden email]> wrote:
> > > On Sun, May 20, 2012 at 6:52 PM, Igor Stasenko <[hidden email]> wrote: >> >> On 21 May 2012 03:29, Igor Stasenko <[hidden email]> wrote: >> > On 21 May 2012 02:16, Eliot Miranda <[hidden email]> wrote: >> >> >> >> >> >> On Sun, May 20, 2012 at 4:59 PM, Igor Stasenko <[hidden email]> >> >> wrote: >> >>> >> >>> On 20 May 2012 21:34, Eliot Miranda <[hidden email]> wrote: >> >>> > Hi Torsten, >> >>> > >> >>> > On Sun, May 20, 2012 at 11:51 AM, Torsten Bergmann <[hidden email]> >> >>> > 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. > 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) -- Best regards, Igor Stasenko. |
|
|
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 <[hidden email]> wrote: > >> On Sun, May 20, 2012 at 6:52 PM, Igor Stasenko <[hidden email]> wrote: >> >>> On 21 May 2012 03:29, Igor Stasenko <[hidden email]> wrote: >>> >>>> On 21 May 2012 02:16, Eliot Miranda <[hidden email]> wrote: >>>> >>>>> On Sun, May 20, 2012 at 4:59 PM, Igor Stasenko <[hidden email]> >>>>> wrote: >>>>> >>>>>> On 20 May 2012 21:34, Eliot Miranda <[hidden email]> wrote: >>>>>> >>>>>>> Hi Torsten, >>>>>>> >>>>>>> On Sun, May 20, 2012 at 11:51 AM, Torsten Bergmann <[hidden email]> >>>>>>> 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) > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |