Compatibility.txt

Compatibility with Windows NT 3.x and 4.0

Windows NT 3.x and 4.0 do support IniFileMapping registry key. So the AutoRun
IniFileMapping hack can work there.

However, several limitations of batch scripting in Windows NT 4 Command
Processor and below make it difficult to write scripts compatible with those
platforms while making the script secure as well.

So, 'usb_vaccine.cmd' is coded to only work with Windows 2000 or later.
(With Windows 2000 you need reg.exe from Support Tools. Unlike in XP it's not
available pre-installed.)

Here are limitations known in Windows NT 4 Command Processor environment:
(Syntax features and built-in commands)
- "SETLOCAL EnableDelayedExpansion" does not work, which is required for secure
  "SET /P" (or "FOR /F") user input processing. Expansion syntax like "%VAR%"
  is vulnerable to command injection.
  (<http://www.robvanderwoude.com/local.php>)
  (<http://www.robvanderwoude.com/battech_inputvalidation_setp.php>)
- "SET /P" does not work, and choice.exe is available only in Resource Kit, and
  so there's no way to write interactive scripts.
  (<http://www.robvanderwoude.com/ntset.php>)
- Negative number in substring expansion (like "%VAR:~0,-5%") does not work.
- "%~1" does not work.
  (<http://www.robvanderwoude.com/ntcall.php>)
- "EXIT /B" does not work, which is required for return codes in subroutines.
  (<http://www.robvanderwoude.com/exit.php>)
- 'FOR /F "usebackq"' does not work.
  (<http://www.robvanderwoude.com/ntfor.php>)
- No dynamic variable %CMDEXTVERSION%. (For checking Win NT 4 environment you
  should use "IF CMDEXTVERSION 1", not "IF %CMDEXTVERSION% GEQ 1". Note that
  "GEQ" compare operator already requires command extensions.)
(External tools)
- reg.exe 1.00 (in Win NT 4) has a different syntax than later versions. It's
  "reg query KeyName\ValueName" rather than "reg query KeyName /v ValueName".
  The latter syntax can distinguish between a subkey and value of the same name
  (which is possible in Win NT 4 registry).
  (<http://www.robvanderwoude.com/ntregquery.php>)

Note: A quick list of reg.exe versions:
version 1.00 - available in Windows NT 4.0 Resource Kit
version 2.0 - available in Windows 2000 Support Tools
version 3.0 - available in Windows XP as a native tool; the "File version" of
              the executable is 5.1.2600.0+ instead of 3.0.*.
reg.exe in Windows 2003 and later (including Windows XP x64 Edition) are no
longer designated with a version number in the program messages. Their "File
versions" have major, minor and build numbers matching the version of the
corresponding Windows releases (5.2.3790.0+).

'usb_vaccine.cmd' contains code that checks whether the Command Processor
environment is okay. The code is copied below, with annotations:

    @REM Note: "@" prefix is supported only since IBM PC DOS / MS-DOS 3.3. In
    @REM DOS 2 or 3 you may use "ECHO OFF" but it's a waste of one line for the
    @REM stub code here.
    @ECHO OFF
    @REM The CMDEXTVERSION check may be available only after cmd extensions are
    @REM enabled. Expect a "Bad command" error for DOS or Win9x COMMAND.COM.
    @REM Note: Redirecting stderr ("2>") is impossible in DOS or Win9x.
    SETLOCAL EnableExtensions
    @REM OS/2 and Win NT 3.x will halt upon syntax "IF CMDEXTVERSION 2 ...".
    @REM Using "==" as delimiter makes syntax backward compatible to those not
    @REM supporting cmd extensions (treating that like string comparison which
    @REM always evaluates to false). (The valid parameter delimiters documented
    @REM ever since PC DOS 1 are tab, space, ",", ";" and "=".)
    IF CMDEXTVERSION==2 GOTO cmd_ext_ok
    @REM " ;" is inserted after ENDLOCAL word and 'exit' line below to prevent
    @REM '\r' (CR) from being interpreted as part of command name or argument
    @REM in Unix shells. ("exit\r" or "exit 1\r" would fail to tell shells to
    @REM exit. ";" is recognized as a command delimiter in many shells, and a
    @REM character that begins comment in 'tclsh' and 'wish'. I didn't see any
    @REM side effect when using ";" this way.)
    ENDLOCAL ;
    @REM Error message. No ">&2" redirection because DOS COMMAND.COM doesn't
    @REM recognize it and will instead write to a file named "&2".
    echo Requires Windows 2000 or later.
    @REM The EXIT command doesn't always terminate batch execution - it does
    @REM nothing when the batch is run on the topmost shell (in real DOS), or
    @REM it kills the current layer of the shell (command interpreter).
    @REM It's more reliable to GOTO an end label, but we keep EXIT command as a
    @REM fallback. Unix shells expect a lowercase 'exit' while letter case
    @REM doesn't matter in DOS command shells.
    GOTO EOF
    exit 1;
    @REM IBM PC DOS / MS-DOS 1.x doesn't support ECHO, EXIT, GOTO or SET.
    @REM Fallback using a (user-visible) REM and a non-loop hanger ("COPY CON:
    @REM NUL:"). It won't protect against Ctrl-C and then N (which effectively
    @REM skips the command), or a Ctrl-Z (simulating an EOF), though.
    REM Press Ctrl-C and answer Y to terminate.
    COPY CON: NUL:
    @REM Re-exec this to force a loop. Note that we cannot detect if user swaps
    @REM the diskettes (physically, in a drive) so that %0 points to something
    @REM else with same file name. (Such would be an intentional attack and is
    @REM not what batch language can handle.)
    @REM If user swaps to a disk in which $0 doesn't exist, then, at reading
    @REM phase, COMMAND.COM will display "Insert disk with batch file" and
    @REM pause, but if disk changing happen at execution phase it won't pause
    @REM (displays "Bad command" and skips instead). The latter case is rare
    @REM and harder than the swap-to-different-file attack, so we won't bother.
    %0
    :cmd_ext_ok
    ENDLOCAL
    ... main code here ...
    :EOF

Note also for ReactOS and Wine:
ReactOS supports %CMDEXTVERSION% variable (=2) in v0.2.7 (SVN commit #16495).
ReactOS supports "IF /I" and "IF CMDEXTVERSION" checks in v0.3.8 (SVN commit
#38280).
Wine does not yet support %CMDEXTVERSION% or "IF CMDEXTVERSION" as of June
2015. (See <https://bugs.winehq.org/show_bug.cgi?id=32680>)