*GO ;environment incorrect
Jon Abbott (1421) 2651 posts |
I believe *GO doesn’t set the Environment string correctly. For example:
This should set the environment to “<my$Dir>.!RunImage”, but it’s being set to “GO <my$Dir>.!RunImage” – note there’s two spaces between GO and the string, which is also odd. I’ve tested all versions of RISCOS back to 2.0 and they all behave the same, but prepending "GO " on the front doesn’t match the documentation, or seem logical. The main reason for setting the environment with *GO is to call code with an environment that matches if it had been *RUN. ie The example above should set the same environment string as:
|
nemo (145) 2554 posts |
I don’t agree. The “GO 8000” bit is equivalent to the “RUN <$Dir>.!RunImage” in the second example – the second example has no parameters, the first example has one. Consider OS_ReadArgs: The syntax string will start with an element to absorb the executable’s filename (normally) – the method by which the code was run. The rest of the syntax string describes the parameters. There should be very little difference (from the executable’s point of view) between *Run Executable foo bar baz and *Load Executable 8000 The semicolon has always been optional. |
Jon Abbott (1421) 2651 posts |
The PRM doesn’t state that and it also doesn’t mention what happens with parameters after the address. We’ve presumed that anything after the address becomes appended to the environment string. The semicolon I’ve taken as a special case that sets the environment string, as that’s what it states on PRM1-329 “environment string to pass to machine code” I expect the issue is the documentation in the PRM is incorrect and the use of the word “environment” throughout is ambiguous. In some cases “environment” refers to the complete commandline and in others it’s referring to the parameters on the commandline, as appears to be the case for *GO Now that’s cleared up, I guess I need to implement something that does allow the complete environment string to be set when calling code. |
nemo (145) 2554 posts |
The reason the semicolon exists at all is because the address is optional – If you wanted to omit the address (which defaults to &8000) but you still wanted to have parameters that start with something looks like an address, the semicolon is necessary. Otherwise it’s superfluous. |
Steve Pampling (1551) 8172 posts |
Sounds more like a conditional status, i.e. required under certain conditions. You named two such conditions. |
Jon Abbott (1421) 2651 posts |
I’ve updated the *GO documentation to clarify what actually happens. Having looked at the source code its setting the environment via OS_FSControl 2 so the parameter is actually the command tail with the command being "GO ". |