As suggested by Reinier van Loon, I changed some methods in SystemDictionary, with the result that sources and changes files are now looked for in the same dictionary as the image file (methods sourcesName and changesName). Opening the image with a VM on another platform now works better, as the sources file is now found (with readonly access). However, the changes file (with write-access) can not be opened: more precisely, the primitive (in StandardFileStream) primOpen: fileName writable: true returns nil, while the file definitely does exist. I vaguely remember a thread about this behavior. Is this a bug with a workaround, or am I doing something wrong?
Hans
BAVECO writes:
I tried to run my image from another computer on the network (with the VM copied to this other computer). It works OK, except that sources and
changes
files are not available: Squeak looks for these files on the machine where
the
VM is (more or less hard-coded by appending imagename.changes to "SystemDictionary vmFile"). Wouldn't it be reasonable to take the location
of
the image file as the default location to look for changes and sources
files,
instead of the location of the VM? How hard would it be to change to current setting?
This is actually how it works, at least on Unix:
$ mkdir empty $ cd empty/ $ ls $ type Squeak Squeak is hashed (/b3/home/lex/bin/Squeak) $ Squeak /home/lex/squeak/lex.image
There is no warning about missing changes files, so it seems okay (I don't know how to check for what exact changes file is being used).
I will point out, though, that we had some trouble here with Windows NT sometimes changing long filenames into mangled 8.3 filenames. Something to do with SMB filesystems perhaps. We ended up having people copy things over to a local drive and running from there. Are you running off a network drive?
Lex