On Wed, Jan 04, 2006 at 07:22:43AM -0500, David T. Lewis wrote:
On Tue, Jan 03, 2006 at 10:41:29PM -0800, Andreas Raab wrote:
And now that we got this done ;-) we can start talking about how to expose the functionality that you need in a nice and cross-platform way. Like, accessing standard file handles: What's wrong with a primitiveGetStdFileHandle that takes an integer argument for the kind of standard handle to retrieve (0 - stdin, 1 - stdout, 2 - stderr)? Sounds simple enough to me. Any others you'd need?
I don't really like the 0, 1, 2 convention, because it's an ancient Unix convention, and really they are supposed to be treated as opaque handles (seriously). It's probably OK to implement primitiveGetStdOut, primitiveGetStdErr, and primitiveGetStdErr in the FilePlugin as long as they are optional primitives and fail in reasonable ways. that these are really still unix conventions that have been adopted elsewhere, and may be rather platform-dependent. They behave differently on Win32 and unix, and I don't know what RiscOS does about them. Tim?
Pipe handles are definitely needed, and given Squeak's current approach to files and sockets, these should be treated as file handles. Anonymous pipes don't have path names, so the process of opening them is of course different. Pipes are very platform-dependent, and I'm not sure this belongs in the core plugins. I'll see if I can think of a way to do this that is not too "evil" ;)
After giving this a little more thought, I can see two feasible ways to expose the required functionality while still allowing OSPP to exist as as optional external plugin.
1) Move primitiveCreatePipe, primitiveGetStdIn, primitiveGetStdOut, and primitiveGetStdErr out of the OSPP plugins and into FilePlugin, and sort out the platform differences in the support code.
2) Have FilePlugin provide a primitiveOpenHandle that could be invoked in a manner similar to the current StandardFileStream>>primOpen:writable:, except that the supplied parameter would be something representing a (HANDLE) or (FILE *), e.g. "primOpenHandle: aByteArray ofLength: 4 writable: true".
Option #1 is undesirable because both the concepts and the implementations are quite platform-specific. But it is workable as long as the VM maintainers don't mind, and as long as at least the Unix and Win32 implementations actually get done.
Option #2 would work well, but does not address the security concern. If spoofing a fileID is a security concern, then spoofing a HANDLE would presumably be equally bad. But it does at least get rid of the outside manipulation of private data structures.
In either case it would be helpful to add a primitiveFileHandle that answers the platform-specific (HANDLE) or (FILE *) corresponding to the certified, non-fake fileID. This would be used by platform-specific extensions (e.g. file locking, fcntl functions) and would eliminate the need for knowledge of the SQFile struct in other plugins. Ditto for the SocketPlugin, if only for the sake of uniformity.
From my own point of view, either of these would be OK. I also have no
objection to leaving things as they are, although I would prefer that the various FilePlugin implementations use the same sessionIdentifier. The workaround I've had to use for the last few years is truly awful.
Dave