It would be good to add this in the awesome documentation. Stef

On 8 Jul 2019, at 20:44, Torsten Bergmann <astares@gmx.de> wrote:

Without having a deeper look I guess what was done for Windows now is wrapping the usual STARTUPINFO, CreateProcess() functions and friends yet again ...

Such wrappers and many other native friends were created from my side already years ago with my "OS-XXX" series of projects for different platforms:

- http://smalltalkhub.com/#!/~OS/OS-Windows - http://smalltalkhub.com/#!/~OS/OS-OSX - http://smalltalkhub.com/#!/~OS/OS-Unix - http://smalltalkhub.com/#!/~OS/OS-Linux-CentOS - http://smalltalkhub.com/#!/~OS/OS-Linux-Ubuntu - http://smalltalkhub.com/#!/~OS/OS-Raspbian

So for instance on Windows you could easily use

WinProcess createProcess: 'explorer.exe'

or

WinProcess createAndWaitForProcess: 'cmd.exe'.

The projects are available on Github now since 2018 and kept up to date for recent Pharo versions.

- https://github.com/astares/Pharo-OS-Windows - https://github.com/astares/Pharo-OS-OSX - https://github.com/astares/Pharo-OS-Unix - https://github.com/astares/Pharo-OS-Linux-Ubuntu - https://github.com/astares/Pharo-OS-Raspbian

All of them are available in Catalog.

I have no problem with more and more implementations and the double efforts. But for Pharo users I have the feeling that it gets more and more confusing in the area of OSProcess, OSSubProcess, OSWinSubprocess, .... and more wrappers for basically the same thing ...

Bye Torsten (aka astares)

Hi Torsten,

Le 8 juil. 2019 à 20:44, Torsten Bergmann <astares@gmx.de> a écrit :

Without having a deeper look I guess what was done for Windows now is wrapping the usual STARTUPINFO, CreateProcess() functions and friends yet again …

Indeed. A subtle difference is that we use the Unicode version of this API.

Such wrappers and many other native friends were created from my side already years ago with my "OS-XXX" series of projects for different platforms:

- http://smalltalkhub.com/#!/~OS/OS-Windows

I know this library as doing a lot of cool things for the integration with the OS but I was not aware there was an implementation of processes forking. I thought it used one of the existing library to do that.

- http://smalltalkhub.com/#!/~OS/OS-OSX - http://smalltalkhub.com/#!/~OS/OS-Unix - http://smalltalkhub.com/#!/~OS/OS-Linux-CentOS - http://smalltalkhub.com/#!/~OS/OS-Linux-Ubuntu - http://smalltalkhub.com/#!/~OS/OS-Raspbian

So for instance on Windows you could easily use

WinProcess createProcess: 'explorer.exe'

or

WinProcess createAndWaitForProcess: 'cmd.exe'.

The projects are available on Github now since 2018 and kept up to date for recent Pharo versions.

- https://github.com/astares/Pharo-OS-Windows - https://github.com/astares/Pharo-OS-OSX - https://github.com/astares/Pharo-OS-Unix - https://github.com/astares/Pharo-OS-Linux-Ubuntu - https://github.com/astares/Pharo-OS-Raspbian

All of them are available in Catalog.

I have no problem with more and more implementations and the double efforts. But for Pharo users I have the feeling that it gets more and more confusing in the area of OSProcess, OSSubProcess, OSWinSubprocess, .... and more wrappers for basically the same thing …

I think you are right on this point. I have the same feeling. Also, OSSubprocess is now the recommended way to fork processes on Linux like systems, and there is no support yet for Windows, I took the opportunity to create the OSWinSubprocess project that could be easily merged into OSSubprocess once it gets all required features. I based my work on a PR done on Pharo Launcher by Keldon Alleyne. If I knew about the process support in OS-Windows, I would for sure, at least, had a look at it and possibly re-use it. I see you have some support for pipes / streams. If you are willing to we could work together to merge both implementation. The only thing is that we should keep the OSSubprocess API when possible to allow a merge with it in a future. WDYT? Christophe.