Unfortunately you are right, thru system() call, there's no way to avoid the window popping up AFAIK. The library you are using, whatever it is, should invoke lower level API.
The one from Levente (as indicated by Guile) souds OK from a rapid scan of source code. https://github.com/astares/Pharo-OS-Windows is not very far either with some little modifications, and is FFI based. so it's just a matter of picking code from here and there until libraries are powerful enough... IMO, there's no point in maintaining N different libraries, each with own flaw. I've always seen such fragmentation as a weakness (IOW it's a failure of core library to provide standard useful feature). I can understand that one alternative is FFI based, the other plugin based. But at the end, each should do the right thing or die. Le jeu. 13 déc. 2018 à 17:44, Christopher Fuhrman < christopher.fuhr...@inria.fr> a écrit : > > On Wed, 12 Dec 2018 at 11:55, Guillermo Polito <guillermopol...@gmail.com> > wrote: > >> Hi all, >> >> I think that Christopher and Peter are talking about ProcessWrapper and >> not OSProcess, >> > > Thanks to all who answered. I'm primarily interested in staying with LibC > because of its simplicity, robustness and its cross-platform compatibility > (although I have yet to run some of my code on Linux). From what I > understand after talking with Esteban, the ffi call to system() > in msvcrt.dll doesn't have any way to specify the Windows' option for the > CMD.EXE window, e.g., SW_HIDE. > > I have other ideas that maybe a future VM could implementation could > consider (if that's where the change would need to go), including > specifying a SETENV variable that is pharo-LibC-specific for turning on/off > the CMD.exe window. > > Christopher > > >> which is fetched from here: >> >> http://leves.web.elte.hu/ProcessWrapper/ >> >> I think this was originally Levente's work? >> The source code is stored in a zip next to the dll in the same server, no >> history attached to it. >> >> Guille >> >> On Wed, Dec 12, 2018 at 12:30 AM Eliot Miranda <eliot.mira...@gmail.com> >> wrote: >> >>> >>> Hi Nicolas, >>> >>> On Tue, Dec 11, 2018 at 5:43 AM Nicolas Cellier < >>> nicolas.cellier.aka.n...@gmail.com> wrote: >>> >>>> >>>> I've checked: it's a one liner to be changed in >>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/Win32OSProcessPlugin/Win32OSProcessPlugin.c >>>> near line 826 >>>> >>> >>> So what changes do you want exactly? I'm happy to do the >>> Smalltalk/Slang writing (adding the parameter, etc) but I don't know what >>> result you'd like to see. Can you post the body of the function as you'd >>> like to see it or the lines around line 826? >>> >>> >>>> Since this is generated code from VMMaker, the code has to be changed >>>> in slang. >>>> IMO, there should be a boolean argument (optional) telling if we want >>>> to open the console or not. >>>> IMO false by default would be a good thing, though true for backward >>>> compatibility is also a possible alternative... >>>> >>>> Le mar. 11 déc. 2018 à 12:56, Nicolas Cellier < >>>> nicolas.cellier.aka.n...@gmail.com> a écrit : >>>> >>>>> It is possible, ask stack overflow >>>>> >>>>> https://stackoverflow.com/questions/4743559/how-to-execute-child-console-programs-without-showing-the-console-window-from-th >>>>> >>>>> https://stackoverflow.com/questions/18841971/hide-console-window-while-running-a-command-through-c?r=SearchResults >>>>> >>>>> I've recently "fixed" my own script in Visualworks so as to use these >>>>> low level API (already procided by VW) >>>>> >>>>> BOOL CreateProcessW( >>>>> LPCWSTR imageName, >>>>> LPCWSTR commandLine, >>>>> struct SECURITY_ATTRIBUTES *pSecurity, >>>>> struct SECURITY_ATTRIBUTES *tSecurity, >>>>> BOOL inheritHandles, >>>>> DWORD creationFlags, >>>>> LPVOID environment, >>>>> LPWSTR currentDirectoryName, >>>>> struct STARTUPINFO *startupInfo, >>>>> struct PROCESS_INFORMATION *processInfo) >>>>> >>>>> First argument is fullpath to cmd.exe (take it from environment >>>>> variable 'ComSpec') >>>>> Second argument is '/u /c ' , 'your command here encoded in utf16' >>>>> Security arguments are nil and nil >>>>> inheritHandles is true >>>>> creationFlags is zero >>>>> environment is nil >>>>> currentDirectoryName is nil >>>>> >>>>> startupInfo is more involved: it must be used to pass the pair of >>>>> pipes (handles) for input/output: >>>>> struct STARTUPINFO { >>>>> DWORD cb; >>>>> LPTSTR lpReserved; >>>>> LPTSTR lpDesktop; >>>>> LPTSTR lpTitle; >>>>> DWORD dwX; >>>>> DWORD dwY; >>>>> DWORD dwXSize; >>>>> DWORD dwYSize; >>>>> DWORD dwXCountChars; >>>>> DWORD dwYCountChars; >>>>> DWORD dwFillAttribute; >>>>> DWORD dwFlags; >>>>> WORD wShowWindow; >>>>> WORD cbReserved2; >>>>> LPBYTE lpReserved2; >>>>> HANDLE hStdInput; >>>>> HANDLE hStdOutput; >>>>> HANDLE hStdError; >>>>> } >>>>> >>>>> You initialize it with void GetStartupInfoW(LPSTARTUPINFO >>>>> lpStartupInfo) >>>>> IMPORTANT: set wShowWindow to 0, >>>>> and then pass the input/output/error handles in last three fields. >>>>> >>>>> processInfo will contain information on output and must be allocated >>>>> struct PROCESS_INFORMATION { >>>>> HANDLE hProcess; >>>>> HANDLE hThread; >>>>> DWORD dwProcessId; >>>>> DWORD dwThreadId; >>>>> } >>>>> >>>>> you can then get exit status thru BOOL GetExitCodeProcess call, close >>>>> the pipes, etc... >>>>> >>>>> >>>>> Le mar. 11 déc. 2018 à 10:08, Christopher Fuhrman < >>>>> christopher.fuhr...@inria.fr> a écrit : >>>>> >>>>>> Thanks Peter. That looks like a cool package. I guess I will live >>>>>> with it for now, because I don't want to code too much of a >>>>>> platform-specific solution (yet). >>>>>> >>>>>> On Mon, 10 Dec 2018 at 21:16, Peter Uhnak <i.uh...@gmail.com> wrote: >>>>>> >>>>>>> This is normal (and much lamented) behavior of cmd. There's >>>>>>> https://github.com/astares/Pharo-OS-Windows which implements parts >>>>>>> of the WinAPI... with which one can create headless windows. (I think it >>>>>>> should be also available in the catalog). >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> On Mon, Dec 10, 2018 at 11:47 AM Christopher Fuhrman < >>>>>>> christopher.fuhr...@inria.fr> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> My Git data mining API in Pharo 6.1 uses "LibC uniqueInstance >>>>>>>> system: 'some commands'" which has an annoying side effect of popping >>>>>>>> up a >>>>>>>> window (which steals the GUI focus in Windows 10). Maybe it's the same >>>>>>>> on >>>>>>>> MacOS and Linux? >>>>>>>> >>>>>>>> As such, I can't use my Windows PC to do anything else when the >>>>>>>> mining process is running (it can take several minutes). I'm not able >>>>>>>> to >>>>>>>> use Pharo's OSProcess or OSSubprocess because they don't support >>>>>>>> Windows >>>>>>>> (yet?). >>>>>>>> >>>>>>>> I tried creating a separate Windows Desktop (feature of Windows >>>>>>>> 10), but the CMD.EXE window manages to pop up there, too - almost seems >>>>>>>> like a windows bug. >>>>>>>> >>>>>>>> Does anyone know of a way to have the LibC window not pop up? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Christopher >>>>>>>> >>>>>>> >>> _,,,^..^,,,_ >>> best, Eliot >>> >> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 >> >
