16-bit %TEMP% is broken in XP, still

[Gordon Fecyk]

I just spent the past week with some tier 1 tech at Microsoft assisted
support. He believes I'm insane.

16-bit apps use the System settings for TEMP and TMP, which points to
%systemroot%temp, which don't work with limited user accounts.[1] Only the
user that created certain temporary files can change or erase them, and
other users won't be able to use those apps.

By comparison, Win2K SP3 and earlier make 16-bit apps use the User settings
for TEMP and TMP, which points to %userprofile%\Local Settings\Temp.
Starting with Win2K SP4, this was broken like XP is, but a patch supplied
under KB 840214 changed that behaviour back.

Now XP's used the wrong 16-bit TEMP behaviour since its release. At least
US English versions have. I can't seem to convince this tech at Microsoft
that this is a problem that needs fixing.

[1] Yes, there's no guarantee 16-bit apps can work with limited accounts -
that's my problem and it's usually fixed by granting Modify access to Users
to the app's installation folder. I don't want to do this to
%systemroot%\temp because it will expose that to abuse - system processes
and services store their temp files here and it's possible to break them by
messing with temporary files here.

 

[Roger Abell]

Disclaimer: I do not do or use 16 bit apps - never have
(or 8 bit for that matter) and hopefully never will.

If what you are saying is:
Nt 4 had really poor design
W2k introduced some changes to default NTFS permissions
and introduced per-user application data storage area including
a user specific temp
WOW in W2k used the user env vars %temp% and %tmp% so
that limited accounts would access their private temp area.
MS introduced a KB fix for those needing back compat so that
WOW would use system env vars.
WOW in XP, and now W2k3 use the system env vars for these
and ignore fact that the user temp area exists

If that is the case, then yes, I totally agree with you.
That behavior is wrong, wrong, wrong !