From: CLOUD::SHIRRON "Stephen F. Shirron, 223-3198" 18-JUL-1996 09:44:48.50 To: WASTED::SMART,WASTED::FLEMING,STAR::COUGHLAN,STAR::EVERHART,LANDO::MAZUR CC: SHIRRON Subj: "extension" to GET/SET environment variable callbacks The current interface for GET_ENV is: R16 = GET_ENV (0x22) R17 = ID of environment variable R18 = VA of buffer to hold value R19 = Size of buffer in bytes R0 on return holds the count of bytes returned and status GET_ENV causes the value of the environment variable specified by the ID in R17 to be returned in the byte stream specified by the virtual address in R18. The size in bytes of the input buffer is contained in R19. The current interface for SET_ENV is: R16 = SET_ENV (0x20) R17 = ID of environment variable R18 = VA of buffer holding value R19 = Size of buffer in bytes R0 on return holds status SET_ENV causes the environment variable specified by the ID in R17 to have the value specified by the byte stream value pointed to by the virtual address in R18. The size in bytes of the input buffer is contained in R19. My extension regards R17. R17 is first treated as a numerical index; if R17 contains the index of one of the known environment variables, then that environment variable is chosen for manipulation. However, if R17 does NOT contain the index of one of the known environment variables, then the console checks to see if R17 contains a valid virtual address, and if so, a string is read from that address until either the address becomes invalid or a 0 byte is found -- either case terminates the string. The string is then used as the name of a environment variable, and if such a named environment variable exists, then that environment variable is chosen for manipulation. If R17 is neither a valid index nor a valid name, then no environment variable is chosen for manipulation, and R0 reports this error. Note that my extension remains in the spirit of the current SRM text, which talks about the environment variable "specified by the ID in R17". A VA which points to a string seems to me to be a perfectly valid ID. Due to this, it's not clear that the SRM needs any changes; opinions? stephen