[ANN] OSWinSubprocess a library to spawn Windows System processes

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

[ANN] OSWinSubprocess a library to spawn Windows System processes

demarey
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.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] OSWinSubprocess a library to spawn Windows System processes

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

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] OSWinSubprocess a library to spawn Windows System processes

demarey
Hi Cédric,

> Le 8 juil. 2019 à 12:39, Cédrick Béler <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] OSWinSubprocess a library to spawn Windows System processes

Torsten Bergmann
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)


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] OSWinSubprocess a library to spawn Windows System processes

tesonep@gmail.com
In reply to this post by demarey
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
<[hidden email]> 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.
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] [ANN] OSWinSubprocess a library to spawn Windows System processes

ducasse
In reply to this post by Torsten Bergmann
It would be good to add this in the awesome documentation.

Stef

> On 8 Jul 2019, at 20:44, Torsten Bergmann <[hidden email]> 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)
>
>