Croquet VM issues

[Bert Freudenberg]

Am 17.03.2006 um 05:35 schrieb Andreas Raab:

> Hi Dave -
>
>> 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.
>
> That's too bad, but I guess it cannot be helped. Windows has the  
> ability to tell you the name of the binary that it loaded (be that  
> an .exe or a .dll) and that's what I was really hoping for.

Well, under most circumstances it *will* be the path to the  
executable. Like, if you run Croquet using the shell script that is  
in the Croquet distribution, which we could adapt to provide the  
whole path (or maybe it already does, haven't actually looked into it  
for a while).

>>> * 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.
>
> It's not for security. It's really so that we know whether a VM has  
> ever been put to the test or not. In other words when the image  
> starts, it would check whether it has been started with an  
> "unknown" VM and if so, runs its VM tests and reports to the user  
> if there are any issues. The thing is that some of these tests take  
> some time and rather than running them anew upon each start of the  
> image I'd like to be able to checksum the VM and run them only when  
> we detect that the VM has changed.

Right. So if a user chooses some non-canonical way to run the VM that  
screws up system attribute 0, he just will have to wait longer.

OTOH, if you're building a new VM anyways using the new math lib,  
what's the problem with adding a primitive for checking? There are  
several ways in which the checksumming by the image could fail, or be  
slow. Like, the VM might be executable but not readable. Or it might  
sit on a slow network drive. And, are you sure check-summing the VM  
is sufficient, and you do not need to verify some external modules,  
too? There are people having all modules external.

- Bert -