%temp% points to %systemroot%temp instead of %userprofile%..

[Guest]

Archived from groups: microsoft.public.windowsxp.security_admin,microsoft.public.windowsxp.setup_deployment (More info?)

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.

--
PGP key (0x0AFA039E): <http://www.pan-am.ca/consulting@pan-am.ca.asc>
Prevent problems before they happen and help others avoid bad design.
<http://www.pan-am.ca/antiwindowscatalog/>

 

[Guest]

Archived from groups: microsoft.public.windowsxp.security_admin,microsoft.public.windowsxp.setup_deployment (More info?)

"Gordon Fecyk" <gordonf@pan-am.ca> wrote in message
news:ewBdozjMFHA.2680@TK2MSFTNGP09.phx.gbl...
> 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.
>
> --
> PGP key (0x0AFA039E): <http://www.pan-am.ca/consulting@pan-am.ca.asc>
> Prevent problems before they happen and help others avoid bad design.
> <http://www.pan-am.ca/antiwindowscatalog/>
>
>

You write "You can change the environment variable". How exactly did
you change it?

 

[Guest]

Archived from groups: microsoft.public.windowsxp.security_admin,microsoft.public.windowsxp.setup_deployment (More info?)

> You write "You can change the environment variable". How exactly did
> you change it?

Editing either config.nt or autoexec.nt, which is the startup environment
for 16-bit apps. For example, you can add "set
temp=%userprofile%\locals~1\temp" to autoexec.nt.

It doesn't take hold, though. As mentioned, 16-bit apps still write
temporary files to %systemroot%\temp, as do 32-bit apps launched from 16-bit
apps. The only thing I know that works is KB840214, but that's for Win2K
only.

--
PGP key (0x0AFA039E): <http://www.pan-am.ca/consulting@pan-am.ca.asc>
Prevent problems before they happen and help others avoid bad design.
<http://www.pan-am.ca/antiwindowscatalog/>

 

[Guest]

Archived from groups: microsoft.public.windowsxp.security_admin,microsoft.public.windowsxp.setup_deployment (More info?)

This is not the correct way to set environmental variables
under Windows 2000. Click Start / Help / Search tab, then
type environment , then double-click "Setting environment
variables" to find out how to do it properly.

Post again if you still have problems.


"Gordon Fecyk" <gordonf@pan-am.ca> wrote in message
news:eB9Ix1oMFHA.3380@TK2MSFTNGP15.phx.gbl...
> > You write "You can change the environment variable". How exactly did
> > you change it?
>
> Editing either config.nt or autoexec.nt, which is the startup environment
> for 16-bit apps. For example, you can add "set
> temp=%userprofile%\locals~1\temp" to autoexec.nt.
>
> It doesn't take hold, though. As mentioned, 16-bit apps still write
> temporary files to %systemroot%\temp, as do 32-bit apps launched from
16-bit
> apps. The only thing I know that works is KB840214, but that's for Win2K
> only.
>
> --
> PGP key (0x0AFA039E): <http://www.pan-am.ca/consulting@pan-am.ca.asc>
> Prevent problems before they happen and help others avoid bad design.
> <http://www.pan-am.ca/antiwindowscatalog/>
>
>

 

[Guest]

Archived from groups: microsoft.public.windowsxp.security_admin,microsoft.public.windowsxp.setup_deployment (More info?)

> This is not the correct way to set environmental variables
> under Windows 2000.

We're talking about XP. KB840214 fixes this problem in Win2K.

We're also talking about the 16-bit environment (NTVDM) which, for reasons
unknown to me, uses a different environment from the rest of the system.

The 16-bit environment ignores %temp% and %tmp% set in the per-user
environment variable settings (control panel / system) and instead uses the
per-system environment for that. You can alter the 16-bit environment
separately from the 32-bit environment by manipulating autoexec.nt, which is
not covered anywhere in Help. In fact, it's covered in KB314495:

"Any environment variables required by the [16-bit] Windows-based program
should be located in the Autoexec.nt file; if they are, Windows will use
them appropriately."

Any environment variables except for %temp% and %tmp%, apparently.

You can even try changing %temp% after the fact, for example in command.com
(set temp=whatever), and the change will appear to take (the changed setting
appears if you type 'set' by itself). But apps launched from there still
ignore it, writing temp files to %systemroot%\temp.

--
PGP key (0x0AFA039E): <http://www.pan-am.ca/consulting@pan-am.ca.asc>
Prevent problems before they happen and help others avoid bad design.
<http://www.pan-am.ca/antiwindowscatalog/>

 

[Guest]

Archived from groups: microsoft.public.windowsxp.security_admin,microsoft.public.windowsxp.setup_deployment (More info?)

What you write sounds fine but is at variance with
my own WinXP Professional installation.

When I use the recommended method of setting the
user's %temp% variable to c:\ABCXYZ (i.e. via Control
Panel / System etc), and when I then invoke a 16-bit
application (e.g. command.com) then the temp variable is
set to c:\ABCXYZ. This happens without me touching
autoexecec.nt. The value of the System %temp% variable
was set to c:\Temp.


"Gordon Fecyk" <gordonf@pan-am.ca> wrote in message
news:eEPZsuxMFHA.2420@TK2MSFTNGP12.phx.gbl...
> > This is not the correct way to set environmental variables
> > under Windows 2000.
>
> We're talking about XP. KB840214 fixes this problem in Win2K.
>
> We're also talking about the 16-bit environment (NTVDM) which, for reasons
> unknown to me, uses a different environment from the rest of the system.
>
> The 16-bit environment ignores %temp% and %tmp% set in the per-user
> environment variable settings (control panel / system) and instead uses
the
> per-system environment for that. You can alter the 16-bit environment
> separately from the 32-bit environment by manipulating autoexec.nt, which
is
> not covered anywhere in Help. In fact, it's covered in KB314495:
>
> "Any environment variables required by the [16-bit] Windows-based program
> should be located in the Autoexec.nt file; if they are, Windows will use
> them appropriately."
>
> Any environment variables except for %temp% and %tmp%, apparently.
>
> You can even try changing %temp% after the fact, for example in
command.com
> (set temp=whatever), and the change will appear to take (the changed
setting
> appears if you type 'set' by itself). But apps launched from there still
> ignore it, writing temp files to %systemroot%\temp.
>
> --
> PGP key (0x0AFA039E): <http://www.pan-am.ca/consulting@pan-am.ca.asc>
> Prevent problems before they happen and help others avoid bad design.
> <http://www.pan-am.ca/antiwindowscatalog/>
>
>

 

[Guest]

Archived from groups: microsoft.public.windowsxp.security_admin,microsoft.public.windowsxp.setup_deployment (More info?)

> When I use the recommended method of setting the
> user's %temp% variable to c:\ABCXYZ (i.e. via Control
> Panel / System etc), and when I then invoke a 16-bit
> application (e.g. command.com) then the temp variable is
> set to c:\ABCXYZ. This happens without me touching
> autoexecec.nt. The value of the System %temp% variable
> was set to c:\Temp.

The problem with this is there's no guarantee the user has write access to
whatever %temp% points to. At least for 16-bit apps.

The problem described in KB840214 (16-bit applications slow down) is one
symptom of a larger problem related to temporary files and 16-bit apps -
only the creator of a temporary file has write access to it - and this is a
problem with more than one limited user (or one admin and one limited) uses
the same 16-bit app.

I much prefer the method of pointing %temp% to a folder in the user's
profile folder, which is the default for 32-bit apps and for 16-bit apps
under Win2K prior to SP3. The fix from KB840214 restores that functionality
to Win2K SP3 and SP4 and eliminates the problems with limited users not
having enough access to write temporary files.

However, Windows XP behaves like Win2K SP3 and SP4 do, pointing %temp% to
the same place for all users for 16-bit apps. I want this corrected or
worked around somehow.

--
PGP key (0x0AFA039E): <http://www.pan-am.ca/consulting@pan-am.ca.asc>
Prevent problems before they happen and help others avoid bad design.
<http://www.pan-am.ca/antiwindowscatalog/>