[Pharo-dev] [Vm-dev] LibC system pops up a CMD.exe window in Windows 10 (Pharo 6.1)

Christopher Fuhrman christopher.fuhrman at inria.fr
Thu Dec 13 11:43:05 EST 2018


On Wed, 12 Dec 2018 at 11:55, Guillermo Polito <guillermopolito at 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.miranda at gmail.com>
> wrote:
>
>>
>> Hi Nicolas,
>>
>> On Tue, Dec 11, 2018 at 5:43 AM Nicolas Cellier <
>> nicolas.cellier.aka.nice at 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.nice at 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.fuhrman at 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.uhnak at 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.fuhrman at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20181213/f89e0635/attachment.html>


More information about the Pharo-dev mailing list