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; tim@rowledge.org; http://www.rowledge.org/tim Manual Writer's Creed: Garbage in, gospel out.

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

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?

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 Mon, Oct 02, 2006 at 05:22:12PM -0700, tim Rowledge wrote:

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.

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

On Tue, Oct 03, 2006 at 08:14:37PM +0100, Simon Guest wrote:

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.

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