[ANN] OSWinSubprocess a library to spawn Windows System processes

Hi,

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.

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)

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:


--
Pablo Tesone.
[hidden email]

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

Stef