Windows BATCH Scripting Overview

Table of Contents

Windows BATCH Files ..................................................................................................................... 2

Notices ............................................................................................................................................ 9

Page 1 of 9
Windows BATCH Files

Windows BATCH Files

BATCH files provide an always available, immediately accessible,

and simple method of interacting with the Windows OS
They are useful for:
• Automation
• Performing complex tasks
• Making your life easier!

Beyond the standard constructs, BATCH provides several ways to

customize, expand, or otherwise enhance what you can do.
• Advanced syntax • Delayed Expansion

• “Subroutines” • Calling external programs

• Manipulating Input/Output • Accessing VBS

**003 So Windows BATCH files.

Just as a quick review, Windows
BATCH files provide an immediately
available, always accessible way for
you to interact with the operating
system, and a way for you to
automate a whole bunch of stuff that
you can do from the command line.

So they're useful for automation.

They're useful for doing complex
tasks that you want to make sure you
get right every single time you do it,
so that repeatable process.

If you are perhaps auditing certain

functions, it makes sure that you do

Page 2 of 9
that audit the same way every single
time you do it.

If you're doing system administration,

and don't want to have to do
individual tasks over and over again,
create a script for it. You'll have the
same way to run it every single time
you do it.

And generally, what BATCH scripting

was created for was to make your life
easier as a system administrator, as
an auditor, as a compliance person,
as a pen tester.

A lot of different roles look at

scripting as a way to automate
things, a way to make things easier,
make your life easier. It's not about
being I'm lazy so I wrote a script
about it. We joke about that sort of
thing, but scripting really gives you a
nice way to automate things, and
make sure you do things on a
recurring basis the exact same way.
So it really does make your life
easier.

Beyond the basic constructs which

like conditionals IF, THEN, ELSE
statements, FOR and NEXT loops,
and that sort of thing, there are
several ways to actually customize or
expand what you can do with BATCH
scripting.

So there's a bunch of stuff that's built

into Windows BATCH that you can
use. We'll talk about this through
advanced syntax. The subroutine
functions, if you will, we'll talk about
those. We'll talk about how to

Page 3 of 9
manipulate input and output streams
so that you can get output from one
command into the input for another
program. We'll talk about delayed
expansion, how to access external
programs, and then how to access
visual basic scripts from a BATCH
script.

So when you put that all together,

what you end up with is this form of
Windows BATCH files, or Windows
BATCH scripting, that gives you a
nice framework to work in, but it is
kind of limited. So there are other
things that you can add to it, not
Windows BATCH per se, but things
that are accessible from it that give
you a whole bunch more power and
flexibility.

Again, the nice thing about Windows

BATCH files is where does a Windows
BATCH file work? Where can you run
it? Everywhere. Every single
Windows computer since, you know,
Windows, or sorry, DOS 3 days,
pretty much, has these commands
built into it.

You can do this from Windows XP,

Windows 7, Windows 8. All of this
functionality is built into it. So if you
write a script you're pretty much
guaranteed to have it work. There
are a couple of different problems
with that because command syntax
changes over the years of Windows,
but generally speaking, if you're on a
Windows box you have access to
Windows BATCH. You have the
ability to write these scripts and just
have it work anywhere.

Page 4 of 9
I guess while we're on the subject of
it, an important point here is that if
you wrote a script for certain versions
of, let's say, Windows XP or earlier,
those may or may not work on
Windows 7 and later.

So somewhere between the

migration from XP to Windows ME,
which nobody talks about anymore,
to Windows Vista, things kind of
changed from a command line
perspective. Some of the basic
constructs in Windows BATCH
scripting changed. Some of the ways
that you call programs changed, and
probably even more frustrating, some
of the returns, so like return codes,
error codes, and even the output
from some programs changed.

So what that means is if you built a

script for, let's say, Windows XP or
earlier, and you were dependent on
the output of a command, or that
particular command returning a
certain error code, that may have
changed in later versions of
Windows.

So what this means is if you're in a

mixed environment where you've got
boxes running XP, and boxes running
Windows 7 or later, just be cognizant
of the fact that there are some
differences between commands on
an XP box and commands on a
Windows 7 box.

So what this means is that you have

to test things. You've got to check
things out and make sure that it's
going to work.

Page 5 of 9
Yes, sir?

Student: As I remember, there was

a version command in the DOS then,
and you could test for what version
you're working with. You can then
take the result from that and tailor
something to whatever your target is.

Instructor: Absolutely. So ver is

the command, and it will spit out the
version of Windows that you're on,
and so you can test for that. You can
also test for like some of the
executable names actually changed,
so you can test based on executable
name.

There are a lot of different ways of

going about seeing what version of
Windows you're on, and what
programs or executables you have
available to you.

Interestingly enough, I'm glad you

brought it up. Does anybody know
what happened to Windows 9?
We've gone from Windows 8 to
Windows 10, you know?

Student: As I understood 7, 8, 9,
Windows 7, 8, 9.

Student: No.

Student: No.

Instructor: No. There is no

Windows 9.

Student: I heard they were worried

about collisions with 95, 98 with
certain testing scripts.

Page 6 of 9
Instructor: Yep, and it's back to
the version command. So
apparently, there's a whole bunch of
probably scripts, programs, things
that look for Windows version, and
what they're looking for is Windows 9
something. So they're doing that
check to see if it's a Windows 95, 98
machine.

The problem is, when you come out

with a new version of Windows,
Windows 9, now all those checks are
going to think that it's Windows 95,
or Windows 98. So Microsoft saw
this from a backwards compatibility
standpoint and said, "Oh, boy. Well,
we're just going to skip Windows 9
because so many people are
checking for the presence of the
string Windows 9 whatever in
versioning to determine whether
they're on 95, 98, or something prior
to XP. So they just skipped Windows
9 and went straight to 10.

That should tell you--that's a good

indication of how the installed base
of Windows is, and what people are
actually writing programs for, and the
fact that there's so much Legacy stuff
out there that Microsoft actually
skipped a whole version number just
to accommodate all of that. It all
stems from bad programming
practices, maybe. Who knows?

Yes, Sir?

Student: That's what I was going to

get into, the programming practice.
Has Microsoft put together some kind

Page 7 of 9
of standard for programming with the
scripts and that?

Instructor: No. There is best

practices that are available to you.
There is a site out there called
Scripting Guys. It's actually run by
some guys from Microsoft, the MSDN
team. And so there's best practices
out there, but to my knowledge,
there's no, "This is how you write a
script officially," like you might see in
a formal programming language like
C or something like that. That's the
Wild West of scripting.

Student: Because that kills you

when you take over someone's work.
I set up an ID department. I went in
and the person before me did all kind
of nonstandard ways of
programming, and it would have
been real nice if he would have had
some kind of guide that says instead
of look for 9 look for 95 or something
like that.

Instructor: Yep. Not to my

knowledge. There are probably
individual best practices that cover
that, that you'll find throughout the
various MSDN documentation, but
there's no like central repository of
this is how you should do it that I
know of.

Page 8 of 9
Notices

Notices
© 2015 Carnegie Mellon University
This material is distributed by the Software Engineering Institute (SEI) only to course attendees for their
own individual study.
Except for the U.S. government purposes described below, this material SHALL NOT be reproduced or
used in any other manner without requesting formal permission from the Software Engineering Institute at
permission@sei.cmu.edu.
This material was created in the performance of Federal Government Contract Number FA8721-05-C-
0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally
funded research and development center. The U.S. government's rights to use, modify, reproduce,
release, perform, display, or disclose this material are restricted by the Rights in Technical Data-
Noncommercial Items clauses (DFAR 252-227.7013 and DFAR 252-227.7013 Alternate I) contained in
the above identified contract. Any reproduction of this material or portions thereof marked with this
legend must also reproduce the disclaimers contained on this slide.

Although the rights granted by contract do not require course attendance to use this material for U.S.
government purposes, the SEI recommends attendance to ensure proper understanding.

THE MATERIAL IS PROVIDED ON AN “AS IS” BASIS, AND CARNEGIE MELLON DISCLAIMS ANY
AND ALL WARRANTIES, IMPLIED OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO,
WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, RESULTS OBTAINED FROM USE OF
THE MATERIAL, MERCHANTABILITY, AND/OR NON-INFRINGEMENT).

CERT ® is a registered mark owned by Carnegie Mellon University.

Page 9 of 9