Is OSProcess usable in Squeak 3.9 on Windows/XP yet?

Hi,

I'm trying to use OSProcess on Windows/XP with Squeak 3.9, and am now
chaining back up the list of other things I need in place to do that.

Apparently I need OSProcessPlugin (for new VM primitives to provide
access to OS facilities not available in the base VM).

To install OSProcessPlugin, I need VMMaker.

Apparently VMMaker is not yet ready for Squeak 3.9 on Windows.

Does this mean I need to go back to Squeak 3.8 for now?

cheers,
Simon

Simon Guest a écrit :
Hi,

I can give you the dll  for win32(work on windows xp) if you want

        Math

On 30-Sep-06, at 11:13 AM, Simon Guest wrote:

> Hi,
>
> I'm trying to use OSProcess on Windows/XP with Squeak 3.9, and am now
> chaining back up the list of other things I need in place to do that.
>
> Apparently I need OSProcessPlugin (for new VM primitives to provide
> access to OS facilities not available in the base VM).
>
> To install OSProcessPlugin, I need VMMaker.

I think ( or more precsiely, I *hope*) that you mean you need vmmaker  
to build osplugin; I've never heard of needing vmmaker to simply make  
use of a plugin.

>
> Apparently VMMaker is not yet ready for Squeak 3.9 on Windows.

Really? It should be ok. There's not been extensive testing as yet  
(difficult to always be on top of a moving target) nor is there  
(IIRC) a neatly packaged up bundle of all you need for windows. You  
ought to find that using the latest vmmaker on SM (vmmaker3.8b6) plus  
the latest trunk from SVN on www.squeakvm.org works.

But if there is a built OSPlugin available for windows you should  
just need to install it, no messing with vmmaker at all.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Manual Writer's Creed:  Garbage in, gospel out.

tim Rowledge a écrit :

>
> But if there is a built OSPlugin available for windows you should just
> need to install it, no messing with vmmaker at all.
>

Yes but the latest  OSPlugin lake of console servises on windows

        Math


> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Manual Writer's Creed:  Garbage in, gospel out.

At Mon, 02 Oct 2006 17:27:44 +0200,
Mathieu  wrote:
>
> tim Rowledge a écrit :
>
> >
> > But if there is a built OSPlugin available for windows you should just
> > need to install it, no messing with vmmaker at all.
> >
>
> Yes but the latest  OSPlugin lake of console servises on windows

All I really want is a version of OSProcessPlugin that runs on Windows.  I
have not seen anywhere I can get one from, without building my own.
Perhaps I could take up Mathieu's generous offer of a DLL, if this is
all I need.

Is the intention that there are some binary downloads available
somewhere, so that someone like me who just wants to use the OSPlugin,
say, can do so without building one's own infrastructure?

cheers,
Simon

On Mon, Oct 02, 2006 at 05:59:53PM +0100, Simon Guest wrote:
Hi Simon,

A very out-of-date DLL is included with the OSProcess package, but
this is obsolete and no longer works with current VMs.

In order to have a current version of OSPP for Windows, you will
need to build the plugin *and* a new VM using VMMaker. You will
also need to disable (or otherwise work around) the functions in
/platforms/win32/vm/sqWin32HandleTable.h in order for OSPP to work
properly. You need to have both the OSPP plugin and the modified VM
with the handle table disabled in order to have a working OSPP for
Windows.

This will void the warranty on your Windows VM, but aside from that
it should work fine. Unfortunately, just using a pre-compiled plugin
will not work, because the handle table security features of the
standard Windows VM will prevent a number OSPP primitives from
functioning.

Dave

p.s. This is not meant as a knock against the additional security
features in the Windows VM. It's just that I have not thought of
a reasonable way to make OSPP work with them. It's also not a problem
that I'm spending any time on, so if anyone has a creative solution,
that would be quite welcome.

On 2-Oct-06, at 4:30 PM, David T. Lewis wrote:

>
> In order to have a current version of OSPP for Windows, you will
> need to build the plugin *and* a new VM using VMMaker. You will
> also need to disable (or otherwise work around) the functions in
> /platforms/win32/vm/sqWin32HandleTable.h in order for OSPP to work
> properly. You need to have both the OSPP plugin and the modified VM
> with the handle table disabled in order to have a working OSPP for
> Windows.

That's interesting and worrying. It would be nice to have all this  
nicely integrated and avoid such hassles.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"How many Outsiders does it take to change a lightbulb?" "Personal  
questions cost one trillion stars."

On Mon, Oct 02, 2006 at 05:22:12PM -0700, tim Rowledge wrote:
Well, it's a fairly limited issue. FilePlugin is platform-independent,
and OSPP is not. OSPP can create a handle for an external resource
such as an OS pipe or the stdout stream for the VM process, and
FilePlugin does not know about these things because they are
platform-specific.  OSProcess wants to take a handle created by
OSPP and pass it to FilePlugin as if it was a legitimate external
resource, and FilePlugin wants to validate the handle to ensure
that it is safe for use in a primitive.

There is no available mechanism for validating such a handle in
FilePlugin. On Windows, recent versions of the FilePlugin take a
conservative approach of "if I did not create this handle, then
it is not valid." On unix based systems, it's not an issue.

The only way I can think of to address this (aside from simply not
doing the validity check on input parameters) is to define optional,
platform-specific primitives to be supported in FilePlugin itself,
e.g. #primitiveMakePipe. This could be done in the support code,
or with platform-specific subclasses to FilePlugin, similar to
the UnixOSProcessPlugin and Win32OSProcessPlugin implementations
of OSProcessPlugin. But this would be a fair amount of effort and
coordination for a relatively small benefit, and I don't know that
it is worth the trouble.

Dave

At Mon, 2 Oct 2006 19:30:48 -0400,
David T Lewis wrote:
> In order to have a current version of OSPP for Windows, you will
> need to build the plugin *and* a new VM using VMMaker. You will
> also need to disable (or otherwise work around) the functions in
> /platforms/win32/vm/sqWin32HandleTable.h in order for OSPP to work
> properly. You need to have both the OSPP plugin and the modified VM
> with the handle table disabled in order to have a working OSPP for
> Windows.

<snip>

Dave,

Thanks for the detailed reply.  I did think I was going to have to
work this hard to get it working, but then Mathieu offered me a copy
of his Win32OSProcessPlugin.dll which works just fine with the Squeak
3.8 VM I have been using to run the Squeak 3.9 image.

So I'm up and running (thanks Mathieu), but remain a little daunted at
what I would have to do to make this myself.

cheers,
Simon

On Tue, Oct 03, 2006 at 08:14:37PM +0100, Simon Guest wrote:
Well, let me offer a word of encouragement on that front. It might seem
a bit of a hassle to set up Squeak with VMMaker, then install whatever
compilers and libraries you need for your operating system. But it's
an interesting exercise and really all that terribly difficult if you
enjoy tinkering with these things.

But the real clincher is this: Can you think of any other computing
environment in which you could do this? You can start out with EToys
and other higher level ideas, and you can drill all the way down to
the bits wiggling around in the VM. Along the way, you can run the
Squeak interpreter inside of itself (InterpreterSimulator), and you
can ask the Squeak VM to convert itself into C source code to be
compiled into an executable Squeak VM (VMMaker). You have the complete
source code for your VM (in both C and Smalltalk), and you can run
it under your favorite debugger (such as gcc) to watch the execution
of the Squeak VM which might happen to be running a Squeak debugger
that shows you the execution of your Smalltalk code in the image,
which might itself be running some EToys script.

So yes it's a hassle to get some of the lower level stuff assembled.
But it is an entertaining exercise, and it's hard for me to imagine
a more "open" environment for playing with everything from high level
abstractions all the way down to the synapses and neurons.

Dave