Croquet VM issues

[David T. Lewis]

On Thu, Mar 16, 2006 at 02:10:08PM -0800, Andreas Raab wrote:
> 
> Questions:
> * On Mac and Unix, do we implement getSystemAttribute: -1 to return the 
> full path to the executable?

Did you mean system attribute 0, which corresponds to argv[0]? But no,
this would not necessarily return "the" full path to the executable,
nor does it necessarily return *any* full path to the executable.
It's just the name that some arbitrary shell program used to
locate an executable file after having consulted with the $PATH and
following various symbolic links and so forth. Once the executable
file was located, the shell did a fork() and exec(), after which
all was forgotten. As far as I know there is no reliable way to
determine the actual identity of the file system artifact from
which the VM was loaded.

> * On Mac and Unix, can one read the executable while running Squeak? I 
> need this to checksum the VM proper.

Yes, you can do what the shell would have done with argv[0], and you
can find the executable file that most probably might have been used
to provide the bytes that got loaded to produce the VM that is currently
running, and you can read that file once you have located it. But this
sounds like a rather shakey foundation for a security system.

By way of illustrating the general awfulness of this approach, the
following works on my system to get a file stream on the image file:

  (FileStream readOnlyFileNamed:
    (OSProcess accessor realpath:
      (ShellSyntax new
          findExecutablePathFor: (Smalltalk getSystemAttribute: 0)
          inDirectoryPath: nil)))

Seriously, this seems likely to attract crackers who might be
entertained by the challenge of breaking the "security", and it is
almost certain to be a source of annoyance to ordinary folks who will
not understand why their system does not work after it was installed
on whatever whacky network setup has been provided in their school
system.

> Besides the above three, I have one additional question: What is the 
> general status of the 64bit work right now? Do we consider this complete 
> or work in progress or experimental? Can we rule out any ill effects for 
> the 32bit VMs?

In my experience, the 64 bit changes have no negative impact for a 32
bit VM. In general, they represent a tidying up of the system, and are
all for the good. There is a a small amount of added complexity for
address decoding, but it is quite localized in the source code. The
compiler warnings resulting from the 64 bit changes tend to be either
harmless, or to identify things that really do need to be cleaned up.

Clearly the 64 bit changes are a work in progress, and I am not in
a position to say if they will be "finished". But the work to date
is fundamentally sound, and I cannot think of any reason that it
should not move forward. FWIW, I'll help where I can.

Dave