[ANN] OSWinSubprocess a library to spawn Windows System processes
Hi, Pharo Launcher had stability problems to spawn new processes (launch Pharo images) on Windows as well as limitations (paths could only contain ASCII characters). To solve this problem, we developed a new library: OSWinSubprocess (https://github.com/pharo-contributions/OSWinSubprocess <https://github.com/pharo-contributions/OSWinSubprocess>) and decided to make it a standalone library so that people can use it if they need to. We tried to use the same API as OSSubprocess when possible. This library uses the Windows API to create process from both 32-bit and 64-bit Pharo images. It also supports Unicode characters. Here are some examples on how to use it: process := OSWSWinProcess new command: 'C:\Windows\notepad.exe'; run. ... process terminate. OSWSWinProcess new command: 'C:\Windows\notepad.exe'; arguments: #('notepad.exe' 'C:\foo.txt'); runAndWait. Important note: As of now, this library does not yet support standard streams (stdin, stdout and stderr). It could be done by setting the appropriate information in the STARTUPINFO structutre. You can check the README for more information. Regards, Christophe.
Hi, Really nice Christophe. I wonder then if OSSubProcess shroud be « renamed » OSUnixSubProcess ? A related question is the the limitation of LibC, iow. When to use LibC or the couple OSSubProcess/OSWinSubProcess ? Cheers, Cédrik
Le 8 juil. 2019 à 12:13, Christophe Demarey <christophe.demarey@inria.fr> a écrit :
Hi,
Pharo Launcher had stability problems to spawn new processes (launch Pharo images) on Windows as well as limitations (paths could only contain ASCII characters). To solve this problem, we developed a new library: OSWinSubprocess (https://github.com/pharo-contributions/OSWinSubprocess <https://github.com/pharo-contributions/OSWinSubprocess>) and decided to make it a standalone library so that people can use it if they need to. We tried to use the same API as OSSubprocess when possible. This library uses the Windows API to create process from both 32-bit and 64-bit Pharo images. It also supports Unicode characters.
Here are some examples on how to use it: process := OSWSWinProcess new command: 'C:\Windows\notepad.exe'; run. ... process terminate.
OSWSWinProcess new command: 'C:\Windows\notepad.exe'; arguments: #('notepad.exe' 'C:\foo.txt'); runAndWait. Important note: As of now, this library does not yet support standard streams (stdin, stdout and stderr). It could be done by setting the appropriate information in the STARTUPINFO structutre.
You can check the README for more information.
Regards, Christophe.
Hi Cédric,
Le 8 juil. 2019 à 12:39, Cédrick Béler <cdrick65@gmail.com> a écrit :
Hi,
Really nice Christophe.
I wonder then if OSSubProcess shroud be « renamed » OSUnixSubProcess ?
In my vision, I would like to see OsWinSubprocess merged into OSSubprocess once we have full support (e.g. std input/outputs).
A related question is the the limitation of LibC, iow. When to use LibC or the couple OSSubProcess/OSWinSubProcess ?
Basically, OSSubprocess uses LibC and OSWinSubprocess uses the windows equivalent of LibC (Kernel32 and msvcrt). I would say it is easier to use a more high level library like OSSubprocess or OSWinSubprocess but it is still possible to use LibC directly. They can be used independently. On Windows, to workaround std input/output support you could just make the launched program write into a file and read it afterwards from Pharo. Also I think OSWinSubprocess is the only process library working on 64-bit images. HTH, Christophe.
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)
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)
Done. https://github.com/pharo-open-documentation/awesome-pharo/pull/89 <https://github.com/pharo-open-documentation/awesome-pharo/pull/89> Julien --- Julien Delplanque Doctorant à lâUniversité de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40
Le 9 juil. 2019 à 08:43, ducasse <stepharo@netcourrier.com> a écrit :
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:
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.
Hi Christophe, First of all, THANK YOU a lot for putting together this great work. This was long overdue and I never had the available time for doing it. We can discuss implementation details of OSSubprocess as much as we want, but I was personally quite satisfied with the API. So if you could come up with a similar API for Windows, I very much welcome that. And you can see even in OSSubprocess github issues that it has been asked a few times. As for the pipes...one short term solution you may want to try is to use files. If you see the whole API of OSSubprocess is polymorphic to the type of the underlying streams used for standard streams. So, for stdout, stderr, stdin etc... you can choose to either use pipes or ... regular files. In fact, in the tests, you can see 2 subclasses...one that tests all the tests with pipes and the other one with files. Finally, it explained here the differences: https://github.com/pharo-contributions/OSSubprocess#regular-files-vs-pipes Anyway, just thought I could throw my 2 cents. Congratulations, -- Mariano Martinez Peck Email: marianopeck@gmail.com Twitter: @MartinezPeck LinkedIn: www.linkedin.com/in/mariano-martinez-peck <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/> Blog: https://marianopeck.wordpress.com/
Thanks Christophe! This thread opens a lot of interesting questions, and as most of them are all subjective and I will only add my opinion that is so wrong (or right) as all the other opinions. First, I consider that having options to do the same tasks with different considerations is good for the community, as it enlarges the options when using Pharo professionally. I always consider that a good engineer takes all the options and decide the best one depending on the existent requirement and restrictions. Sometimes we require to have tools that only fit for a single scenario and others that are general but mostly fit for all scenarios. I also consider good that Christophe, that fixes something for the Pharo Launcher (but it could have been any other project) and releases to the community so anyone else can fix the same problem. I ask everybody else before taking opinions to read the motivations behind the library / framework / couple of classes of Christophe. He required to have something that was working with correctly with UTF8 paths and it is polymorphic with OSSubprocess (as it is used in the other 2 platforms). I don't see any other solution that fulfills these requirements, so he has done an ad-hoc solution. Thankfully he has released it and now whoever cames later can have another option to use or even to copy and spawn a completely new solution. Finally, I share the good point of Torsten that we require to have a better way of publishing all the tools / libraries / pieces of code that we share, so the newcomers can find them easily. But even with the perfect documenting-sharing tool, it will be nice to have different solutions with different constraints and different improvements. Also, it will be nice to have more communication and focussing on pushing to the same targets. But how we can do that without cutting down the innovation, the reception of new ideas and the enjoy of implementing new things. One interesting case we have to accept as an open community is the reimplementation of something because is funny. I know this is not the case with Christophe, because I have seen him. This is also important and should not be cut down. It is not good to reinvent the wheel every time, but if we don't do it when it is required we will not have anything. I will really like to see more contributions of any kind, I invite to reimplement any of the things I did / do with new approaches and vision so everyone can grow. And one that will be really nice to have is a replacement for the catalog, so we can compare all the solutions that we have for a single problem!!! Thanks for reading me!! On Mon, Jul 8, 2019 at 12:13 PM Christophe Demarey <christophe.demarey@inria.fr> wrote:
Hi,
Pharo Launcher had stability problems to spawn new processes (launch Pharo images) on Windows as well as limitations (paths could only contain ASCII characters). To solve this problem, we developed a new library: OSWinSubprocess (https://github.com/pharo-contributions/OSWinSubprocess) and decided to make it a standalone library so that people can use it if they need to. We tried to use the same API as OSSubprocess when possible. This library uses the Windows API to create process from both 32-bit and 64-bit Pharo images. It also supports Unicode characters.
Here are some examples on how to use it:
process := OSWSWinProcess new command: 'C:\Windows\notepad.exe'; run. ... process terminate.
OSWSWinProcess new command: 'C:\Windows\notepad.exe'; arguments: #('notepad.exe' 'C:\foo.txt'); runAndWait.
Important note: As of now, this library does not yet support standard streams (stdin, stdout and stderr). It could be done by setting the appropriate information in the STARTUPINFO structutre.
You can check the README for more information.
Regards, Christophe.
-- Pablo Tesone. tesonep@gmail.com
participants (7)
-
Christophe Demarey -
Cédrick Béler -
ducasse -
Julien -
Mariano Martinez Peck -
tesonep＠gmail.com -
Torsten Bergmann