G
Gordon Fecyk
32-bit programs launched from Explorer (or from a child process launched
from Explorer) have %temp% set to %userprofile%\LocalS~1\Temp, which is the
preferred behaviour for all applications.
Win2K SP3/SP4 US English, XP Home Gold/SP1/SP2 US English and XP Pro
Gold/SP1/SP2 US English all set %temp% to %systemroot%\temp for 16-bit apps.
Since %systemroot%\temp has different file system ACLs than %userprofile%
does, 16-bit apps that use %temp% have a hard time running as a limited
user, notably if more than one limited user uses the same app and it leaves
temp files behind.
The incorrect environment also causes trouble with Internet Explorer when
launched from within a 16-bit app, because IE gets the 16-bit environment
along with the incorrect TEMP setting. This breaks web page printing among
other things, when running as a limited user.
Win2K SP4 has a fix that changes %temp% back to %userprofile%\locals~1\temp
for 16-bit apps - that fix is available by request from Microsoft and is
covered in KB840214. The fix actually works in Win2K Professional as well
as Win2K Terminal Server. However, I don't know of a corresponding fix for
XP.
Changing the environment through autoexec.nt and config.nt have no effect.
You can change the environment variable, but something changes it back.
Even if you force-change it before launching an app, apps that use the
Windows APIs to create temporary file handles end up creating their files in
%systemroot%\temp anyway.
Others told me before that non-US versions of Win2K and XP don't do this,
instead using %userprofile%\locals~1\temp.
To reproduce the problem, hit Start / Run... and type "command.com" to bring
up a 16-bit command.com prompt. Type "set" and observe the %temp% and %tmp%
values. Repeat with cmd.exe and observe the difference. Also, try
launching cmd.exe from command.com and observe the (incorrect) environment
passed to it.
from Explorer) have %temp% set to %userprofile%\LocalS~1\Temp, which is the
preferred behaviour for all applications.
Win2K SP3/SP4 US English, XP Home Gold/SP1/SP2 US English and XP Pro
Gold/SP1/SP2 US English all set %temp% to %systemroot%\temp for 16-bit apps.
Since %systemroot%\temp has different file system ACLs than %userprofile%
does, 16-bit apps that use %temp% have a hard time running as a limited
user, notably if more than one limited user uses the same app and it leaves
temp files behind.
The incorrect environment also causes trouble with Internet Explorer when
launched from within a 16-bit app, because IE gets the 16-bit environment
along with the incorrect TEMP setting. This breaks web page printing among
other things, when running as a limited user.
Win2K SP4 has a fix that changes %temp% back to %userprofile%\locals~1\temp
for 16-bit apps - that fix is available by request from Microsoft and is
covered in KB840214. The fix actually works in Win2K Professional as well
as Win2K Terminal Server. However, I don't know of a corresponding fix for
XP.
Changing the environment through autoexec.nt and config.nt have no effect.
You can change the environment variable, but something changes it back.
Even if you force-change it before launching an app, apps that use the
Windows APIs to create temporary file handles end up creating their files in
%systemroot%\temp anyway.
Others told me before that non-US versions of Win2K and XP don't do this,
instead using %userprofile%\locals~1\temp.
To reproduce the problem, hit Start / Run... and type "command.com" to bring
up a 16-bit command.com prompt. Type "set" and observe the %temp% and %tmp%
values. Repeat with cmd.exe and observe the difference. Also, try
launching cmd.exe from command.com and observe the (incorrect) environment
passed to it.