shell peculiarities between Windows 9X/NT/2K/XP January 7, 2003 (as amended)
Running programs in a shell under Windows may be problematic, for a number of reasons, which I outline below:
The name and location of the command shell have changed. Scripts written to call C:\COMMAND.COM must now call C:\WINNT\SYSTEM32\CMD.EXE
The START command has a number of inconsistencies between versions:
NT does not include the START command, which is bundled with 9X and 2K. This could cause some functions to fail, as they might use START to run a program. Programs must explicitly check for this condition ("am I under NT?") each time they use a START command.
The START command in 2K and XP (an internal command, not a separate EXE as in 9X) doesn't support the /M switch supported by 9X; the /MIN switch must be used instead. Fortunately, 9X's START.EXE supports /MIN as well as /M.
2K prevents START being called by other programs - it's only available to the user and to batch files executed at the command prompt. For example under 2K, clicking Start.. Run.. and typing START CMD and pressing enter produces an error "cannot find the file 'start'... "; going to the command prompt and then typing START CMD produces a new command shell window. In contrast, on 9X, typing START COMMAND into the Start.. Run.. dialog box produces a new command shell window. 9X programs written to use START must be changed to run the program directly on 2K and above; a program that once executed "START NOTEPAD MYFILE.TXT", for instance will need to be changed to execute "NOTEPAD MYFILE.TXT" instead.
NT and 2K support the PATH command, subject to the following (XP untested):
both use the AUTOEXEC and also the System section of Control Panel to define the path
changes to the Control Panel screen don't take effect until after a reboot (for both NT and 2K); changes to AUTOEXEC are not used until after a reboot either (under both systems)
under both NT and 2K, the directories defined in Control Panel appear first in the PATH, while directories defined in AUTOEXEC appear next in the PATH
NT, 2K and XP report system information differently to 16-bit DOS programs than they do to a user at a 32-bit command prompt:
under NT/2K/XP, the TEMP variable returns a path to %SYSTEMROOT%\TEMP to a 16-bit program, while a 32-bit program under NT/2K/XP sees %USERPROFILE%\TEMP. Under 9X, either a 16- or 32-bit program sees %WINDIR%\TEMP.
under NT4, typing VER at the command prompt returns "Windows NT Version 4.0", yet programatically executing this command from a SHELL and redirecting to a file, returns "MS-DOS Version 5.00.500". Under 2K, typing VER at the command prompt produces "Microsoft Windows 2000 [Version 5.00.2195]" on the test system, while obtaining that information programattically in a DOS box (using the same technique as for NT) also produces "MS-DOS Version 5.00.500". The same is true for Windows XP. *
under both systems, the SET command fails to return some variables, including the WINDIR variable, if called from a SHELL.
The DIR command produces results formatted differently under 9X, NT or 2K (XP untested). In particular, a 16-bit program under NT/2K/XP sees a DOS 6-style directory listing with no LFNs. Under NT/2K/XP a 32-bit program sees an NT-style listing. Under 9X, either a 16- or a 32-bit program both see a FAT32-style listing. Code ported from 16- to 32-bits and run under NT/2K/XP will see a listing different to what it was expecting, and will need to be rewritten or it will fail. Sample listings:
NT and 2K do not support DELTREE command, unlike 9X. Use RMDIR /S under NT and 2K. However, the RMDIR command that comes with 9X does not support /S, so a script which must run under both systems must detect which system it's running under, and use the correct command. Use code similar to the below:
rem --- detecting operating system
ver | find "Version 4.1" > nul
if errorlevel 1 goto 98notfound
set TREEDELCMD=DELTREE /Y
goto oscheckok
:98notfound
set TREEDELCMD=RMDIR /S /Q
:oscheckok
%TREEDELCMD% \directory\to\delete
NT and 2K do not include the CHOICE utility, unlike 9X. It is in the NT/2K resource kit, however (on 2K, it's in SCRIPTS.CAB). On 2003 it's reportedly an internal command. Scripts executed on NT/2K without CHOICE.EXE from the resource kit will show a "command not found" error before immediately continuing to execute, which may be a problem, depending upon how the script is written.
Under 9X, XCOPY supports copying to the NUL device, while under 2K, it does not (NT/XP untested).
The REGEDIT command produces a text file when exporting under NT or 9X, however under 2K it produces a text file with every second character being ASCII zero (NULL) (XP untested).
16-bit programs may not start at all, depending on their location in the directory tree. If the full path to the 16-bit executable file is more than 64 characters in length, Windows NT/XP/2K will not execute it. This is by design, apparently.
Long Filename support is not available to 16-bit programs under NT and 2K (XP untested).
9X's Recycle Bin uses the RECYCLED directory. NT/2K/XP uses a directory called RECYCLER if the drive is formatted as NTFS, or it uses RECYCLED if the drive is formatted as FAT. Software expecting to find the RECYCLED directory will only continue to function after moving to NT/2K/XP if NTFS is not used. If NTFS is used, software will need to be changed, but only for the drives that use NTFS.
NT and 2K do not set the %WINBOOTDIR% environment variable, unlike 9X. Use %WINDIR% instead, as it's supported by both systems (batch files or 32-bit programs only - the %WINDIR% variable is not available to 16-bit programs under either system (see above)). A quick way to have a script support both:
if "%WINBOOTDIR%" == "" SET WINBOOTDIR=%WINDIR%
* Note: to differentiate between NT, 2K and XP with a 16-bit DOS-based program, and work around the identical results problem noted with the VER command, search for the APPDATA environment variable, which, by default, is not found under NT but is found under 2K. A similar technique can be used to differentiate between XP and 2K. XP also has the APPDATA variable where NT does not, however XP has two new variables - CLIENTNAME and SESSIONNAME (both of which reported "Console" on the test system). 2K is missing those two variables, so if your program can't find them, but does find APPDATA you know you're under XP and not 2K. XP is also *missing* the environment variable OS2LIBPATH which was present under 2K.
also on this site:
search: