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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Cellier
 
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 <[hidden email]> a écrit :
It is possible, ask stack overflow

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Cellier
 
And if you are using https://github.com/astares/Pharo-OS-Windows/blob/master/src/OS-Windows-Environment/WinProcess.class.st rather than the OSProcess plugin, then it's a bit more involved to make the changes, because you must also redirect the I/O thru a pipe, but it's doable too.

Le mar. 11 déc. 2018 à 14:43, Nicolas Cellier <[hidden email]> a écrit :
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 <[hidden email]> a écrit :
It is possible, ask stack overflow

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by Nicolas Cellier
 
Hi Nicolas,

On Tue, Dec 11, 2018 at 5:43 AM Nicolas Cellier <[hidden email]> wrote:
 

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 <[hidden email]> a écrit :
It is possible, ask stack overflow

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Guillermo Polito
 
Hi all,

I think that Christopher and Peter are talking about ProcessWrapper and not OSProcess, which is fetched from here:


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 <[hidden email]> wrote:
 
Hi Nicolas,

On Tue, Dec 11, 2018 at 5:43 AM Nicolas Cellier <[hidden email]> wrote:
 

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 <[hidden email]> a écrit :
It is possible, ask stack overflow

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

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

Nicolas Cellier
In reply to this post by Eliot Miranda-2
 
Hi Eliot,
Sorry for not answering.
I wanted to test whether a change were really necessary or not, but got distracted... I've never used OSProcess, so I must learn first, but the Debugger did not help. I will try again.

Le mer. 12 déc. 2018 à 00:30, Eliot Miranda <[hidden email]> a écrit :
 
Hi Nicolas,

On Tue, Dec 11, 2018 at 5:43 AM Nicolas Cellier <[hidden email]> wrote:
 

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 <[hidden email]> a écrit :
It is possible, ask stack overflow

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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