MS-DOS 2.0 does not use any special environment variable to locate a temp-directory nor does it use such at all. Temporary files for piping will be created in the root directory (*1) of the current drive (*2) and named
with x being
2 used consecutive, as shown in the now public code for DOS 2.0.
The file name templates can be found in the source file RDATA.ASM at line 173 and 174. They are used within TCODE.ASM. TCODE contains, as the name tells (TransientCODE), the transient parts of COMMAND.COM, i.e. the parts that may be purged during a filter (program) run and reloaded after.
These names were the only temporary files MS-DOS - or more exact COMMAND.COM used. After all, it wasn't a function of DOS, but of the shell that executed all programs in sequence and redirected in-/output accordingly.
Environment Variable Usage
it seems that %TEMP% was introduced in MS-DOS 2.0.
Not really, Mr. Chen might need to check again. As mentioned, MS-DOS 2 - and AFAIK at least until 3.3 - did not use a temp-directory or either of the variables (*3).
The attribution might come due the behaviour of MS-DOS 5.0 and later setting TEMP in the AUTOEXEC.BAT created by the installer — pointing not at a temporary directory, but at the DOS installation directory, as Stephen Kitt checked.
What version of MS-DOS or Windows introduced %TMP%?
TMP was used by the Microsoft C compiler, as early as 3.0 (*4). Windows 3.0 might have been the first OS to use TEMP - at least does the Microsoft Windows User's Guide mention setting this variable p.538. It can be speculated that the different name was used to avoid any conflict with language tools using TMP (*5).
GetTempFileName function to create their temporary files, in which case they will prefer to use TMP
Not really, as GetTempFileName only cares about creating the file name, not looking up any drive, path or directory from any environment setting.
It wasn't until DOS 3.0 that a function to create temporary name was introduced. Int 21h Function 5Ah CreateTempFile created a file in a given directory (path must be provided by the caller) using date and time as file name (*6).
GetTempFileName on the other hand is a Windows function that works much like the DOS function, but will not open that file. The name will be composed of a user supplied 3 character prefix and a 4 character unique number (16 bit as HEX) as
<path>\<pre><uuuu>.TMP. If the unique number is supplied by the windows runtime it will be guaranteed to not exist.
Another Windows function would be GetTempDrive which returns the drive used for temporary files as a single character (*7).
Both functions are present since Windows 2.03. Together they provided a way for Windows programs to create temporary files in the root directory of a given drive - much the same way DOS did for pipes.
It wasn't until WIN32 that GetTempDrive got superseded with GetTempPath, which now implements the search sequence Mr. Chen talks about:
- The path specified by the TMP environment variable.
- The path specified by the TEMP environment variable.
- The path specified by the USERPROFILE environment variable.
- The Windows directory.
MS offers some documentation how to Create and Use a Temporary File. Except, it's outdated already, as GetTempPath got with Win10, a little brother GetTempPath2, which is to be used instead. It will consider as well privileges to pick the final location.
*1 - Somehow I remembered it to be the current directory on that drive as well, but looking at the code shows it's always in the root directory.
*2 - I bet every creator of a non trivial filter did at least once run into the bug screwing a pipe by changing the default drive, but not changing it back before exiting :))
*3 - The only environment variables used by DOS or COMMAND.COM with MS-DOS 2.0 are
And only the first two of them are set by default by COMMAND.COM under DOS 2.x/3.x. PROMPT will be observed, but needs to be added by user commands. In fact, DOS 2.0 even added a build in
PROMPT command, a thin veil for
*4 - I'm not sure if the Lattice C based Versions before 3.0 did already use TMP as well.
*5 - I could imagine screwing an installation when compiling and testing on the same machine with compilers and Windows assuming the temp dir being theirs :)
*6 - Which had it's own pitfall as that file wasn't cleaned up by DOS after a program exited - or been aborted - leading to the first case of dead-file-hording under DOS/Windows :)
*7 - In reality it returns not just a char (in AL) but a 16 bit int - or better two char - in AX with AH always containing a colon (
:), so calling functions could store both with a single machine instruction at the start of the path they are building. Yeah, early DOS and Windows was really build with code path saving in mind.