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