New VMMaker/svn release

David T. Lewis lewis at
Wed Jan 4 03:02:35 UTC 2006

On Tue, Jan 03, 2006 at 02:21:29PM -0800, Andreas Raab wrote:
> tim Rowledge wrote:
> > On 29-Dec-05, at 12:00 PM, David T. Lewis wrote:
> >> Attachments (in zip file):
> >>
> >> platforms-win32-plugins-FilePlugin-sqWin32FilePrims.c.diff - Change  
> >> Win32
> >>     FilePlugin to use session ID from the interpreter rather than  
> >> generate its
> >>     own value (for consistency, and also so as not to break OSPP  for 
> >> Win32).
> > 
> > OK, that is up to andreas - I couldn't commit it if I wanted to.
> Now that's interesting. I can fix that easy enough but I'm curious as to 
> the reason for having a "global" session ID instead of a local one. I 
> always found it advantageous that (in all likelyhood) you couldn't use 
> the session ID for a file interchangeably with the session ID of a 
> socket. And I must say that I find the idea of exposing what essentially 
> amounts to a "VM secret" to other plugins quite peculiar.
> Can somebody remind what the intent of that change was? I'm sure there 
> must've been some reason for it but I think I've missed the discussion 
> of that feature.

There are are probably lots of reasons why you might want to identify
the current "squeak session" for some particular image. My specific
reason for wanting to do this was that, in WindowsOSProcessAccessor, I
want to associate the squeak session identifier with the Win32 HANDLE
of the input/output/error console streams. There is no point in asking
the FilePlugin for its current session identifier if the Interpreter
can provide it.

The fileID is an opaque value that just happens to correspond to some
data structure that we are not supposed to know about, but it is easier
to handle the issue in the Win32OSProcessPlugin that to try to design a 
platform independent solution that can be incorporated into FilePlugin for
all supported platforms. The same argument applies to UnixOSProcessPlugin,
and of course to RiscOSProcessPlugin, although the former is at a somewhat
more advanced stage of implementation.

Thus in WindowsOSProcessAccessor>>primGetStdOutputForSession, 

primGetStdOutputForSession: sessionIdentifierByteArray
    "Answer a two element array containing the sqFile data structure representing
    standard output stream for my OS process, and a flag (true or false) to indicate
    whether the sqFile data structure contains a valid HANDLE. If no standard output
    stream is available for this OS process, the sqFile data structure will contain an
    invalid HANDLE value, which will result in failures on subsequent accesses."

    "OSProcess accessor primGetStdOutput"

    <primitive: 'primitiveGetStdOutput' module: 'Win32OSProcessPlugin'>
    ^ nil

More information about the Vm-dev mailing list