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