>>>>Your understanding is correct. Environment variables are part of the COMMAND.COM/CMD.EXE shells starting with PC/MS-DOS, designed to enhance batch file programming. GETENV() was (if memory serves) introduced in one of the DOS-based Foxen (FoxBASE+ or FPD).
>>>>
>>>>As your code illustrates, there's no protection for environment variables. Windows distinguishes between "System" and "User" environment variables, but neither are protected. The former are present and set when the system boots, and the latter are set when a user logs on.
>>>
>>>I think is worth mentioning that the change will only be valid for the command.com/cmd.exe session where the change was applied, if you start your program from a different command/cmd session or by running the exe, the change in the environment will not apply, but if you think (I mean OP) that is not enough, you can use Win32API
>>>
>>>

>>>local lcUserName, lnBufferLen
>>>declare GetUserNameA in win32api as GetUserName string   @lpBuffer, integer @pcbBuffer
>>>
>>>lcUserName			= SPACE(255)
>>>lnBufferLen			= 255
>>>
>>>GetUserName(@lcUserName, @lnBufferLen)
>>>
>>>? lcUserName, lnBufferLen
>>>
>>>

>>
>>Thanks, GetUserName seems to be a good alternative.
>
>Christian, getting the information from SYS(0) is probably the simplest way to get the user name and it is not subject to the user tampering the environment variable.
>
>

>STREXTRACT(SYS(0), " # ", "")
>

I do vaguely recall *one* situation many years ago where I ran into a problem using SYS(0) to identify the workstation and user names -- it was one of those situations where "#" turned out to be a substring within the workstation name. Not that it's likely to occur nowadays -- this particular situation involved some Windows 95 or 98 workstations (Win95/98 did warn you about certain characters appearing in workstation name, but you could choose to ignore it).