It’s not entirely clear what the name is for Windows’ batch file language – it might be called “Command Line”, or “MS-DOS”, or Batch. But this language is one of a class called “shells”. What distinguishes a shell language from a regular scripting language is that it is considered to be a “shell” around the OS kernel, with direct access to OS services like file and directory services.
Most shells operate with a current directory context. So the Windows shell input line tells you what directory you are in. It also has an environment variable context – it inherits whatever environment variables are permanently set in Windows, then others can be added. But when you exit from the shell, environment variables usually revert to the default setting.
Any program called from the shell or from a batch file will inherit its current environment variables. This means that you can set-up multiple environments for working on different projects in (say) Visual Studio. One trick we use is to never start Visual Studio directly, but always launch it from a batch file,
VisualStudio2005.bat:
set VSDIR=%PROGRAM_FILES32%\Microsoft Visual Studio 8
call "%VSDIR%\VC\vcvarsall.bat" x86
SET MASM_32_OR_64=%VSDIR%\VC\Bin\ml.exe
set INCLUDE=%DXSDK_DIR%\include;%INCLUDE%
set LIB=%DXSDK_DIR%\lib\x86;%LIB%
start "Visual Studio 2005" "%VSDIR%\Common7\IDE\devenv.exe" /useenv
This sets up a few env variables – the INCLUDE and LIB variables are particularly useful because this is what Visual Studio uses to determine the default include and library directories for compiling. So with this batch, we make sure that the current DirectX can be found.
Then we launch the Visual Studio IDE, using not the usual “call”, but “start”. If we used call, the batch file window would remain open, waiting for Visual Studio to quit. But “start” means “launch and forget”, so as soon as Visual Studio has been launched, the batch window will end and close – much cleaner.