If there is no programming environment in place, there is an obvious choice for installing Perl: "Strawberry Perl" comes with a working compiled version, but also includes the GNU C compiler for backup. The easiest installation uses a Windows installed (.msi) file. Download the .msi file from its website. Clicking on its icon will unpack start a "wizard" to do the entire installation, including adding the location of the executable Perl files to the PATH environment variable, so the commands like "perl", "gcc", "make", etc. are available from a command-prompt window. The package is also available as a .zip file, whose installation is more complicated, but described in its included README file.
The GNUPlot page at SourceForge has many forms and releases of the code, including source (which you could compile using your shiny new gcc compiler). It is easiest to use a precompiled binary package, available as a ".zip" file. The file names indicate the version (e.g., "gp443" for version 4.4.3), with "win32" appended, so this version would be downloaded as "gp443win32.zip". (Unless you want the extra complication of installing an X11 windowing package, avoid the files containing "x11".) Clicking on the .zip icon will unpack it; choose directory "C:" for the files; they will unpack into "C:\gnuplot". (Windows may not like you looking at directories in "C:"...) To make the program available at a command prompt requires a change to the PATH environment variable. Start with "control panel" -> "system", "advanced" tab, click "environment variables", find "Path" in the list, and edit it by adding ";C:\gnuplot\binary" to its string. While you are at it, it is also necessary to insert ".;" at the beginning of the "path" string. (See below.) If you have difficulty, use the "help", but just in "control panel".
Once Perl and GNUPlot have been properly set up and the environment variable edited, the "path" command should show that programs will be searched for in directories "." and starting with "C:\strawberry" and "C:\gnuplot". It may be necessary to close and reopen the command-prompt window to see the changes in "path".
The SYN tools must be used through a "command prompt" window, where the facilities and documentation fall short of what a UNIX user would call command "support," so it will usually be necessary to work in tandem with MS GUI file tools in one window and SYN tools through another "command prompt" window. In particular, although "/" is supposed to be a legitimate alternative to "\" as a file-path separator, frequently it isn't. When unpacking or copying files, use the Windows click and drag commands in windows started through "my computer", then change to a command prompt to run SYN. It may sometimes be necessary to close and reopen one or the other window to keep the two in sync.
Under MS Windows Perl scripts cannot be executed directly. Windows has no equivalent of the "shebang" (#!) convention that labels a file as to be executed by giving it to a program (like Perl). The SYN tools themselves are not greatly inconvenienced by this, since they can be run (and can run each other) as "Perl XXX" instead of "XXX". But when executable components are coded in Perl, SYN needs to execute them in some way that is language independent. (Other scripting languages have the same difficulty, but compiled code -- say from C -- does not.) Perl developers have a trick that should work for other cases: a Perl script "runperl.bat" is provided that when executed finds the name under which it was run, and runs Perl on a source with that name. So making file "XXX.bat" a copy of "runperl.bat" and then typing "XXX" will have the same effect as typing "Perl XXX". But one must remember to make this copy when a Perl program is created, sort of like "compiling" the source code. (Of course, this "compiling" can take place before such a Perl program exists -- that's real magic! -- and need not be repeated if the program should change without changing its name.) As a part of the SYN tools, the script "perlxx" performs this operation, and has been run on itself (to make "perlxx.bat") so that "perlxx XXX" will "compile" Perl script "XXX" for use. Most of the SYN scripts have been "perlxx"-ed, so they can be run using their names. However, to force the system to look for these files, and look for them before any others, requires that "." be the first item in the "path" environment variable, as arranged above. Executability of component code comes up in using the "COMP" script to approximate a component. "COMP" creates a ".bat" file for any Perl source, and tries to execute code and report any difficulties, but it can't do a very good job across platforms.
A word about Windows file names. The underlying OS (that is, DOS!) is happiest when all names are upper case and limited to eight characters (of which only six come from the real name if it's longer than eight) with an optional extension set off by a ".". To go outside this convention invites obscure file problems, although the SYN tools try to keep to the so-called "long" names to avoid trouble. The "DIR /X" command lists both names. Since Windows uses the extension to determine which program gets the file by double-clicking, and may create those extensions (which are difficult to remove!) without cause, and may refuse to access files with some extensions (e.g., ".bin"), it is a good idea to avoid all extensions other than ".ccf" in creating files, and for executable code files there must not be an extension. This means that one must be very careful how a file is created, since most editors add their own extentions. From the command prompt, the "EDIT" program is an exception: it does what it's told to do.
A word about file format. One of the most important insights that the UNIX designers had is that all files are strings of characters, perhaps broken into lines. Any program may read or write any UNIX file without concern for special format. (Not that perverse programs cannot create formatting, but unless they are truly evil they do so using printable characters so that the format is visible on a screen or printer, and may be examined or adjusted with a simple editor.) The design (to use the term loosely) of Windows turned this UNIX insight on its head. It is almost as if the MS designers knew the truth of the matter and made a conscious decision to pervert it. They created special formats for everything, formats that are proprietary secrets and which change frequently with the express purpose of creating downward incompatability (with the express purpose of selling latest versions of software). This philosophy is very hard on a tool developer outside MS, because few MS utilities can be used with outside tools. Each utility program will put files into its proprietary format silently, and only it can undo the mess it has made (but why should it?!). So tools must include excess functionality to avoid MS software. The SYN tools were developed on a shoestring budget for UNIX, where the system utilities are trustworthy, so SYN includes no utilities. This makes file editing a nightmare. A compromise is to make use of MS utilities and put everything in "text" format (".txt"). Then when SYN tools need to look at the files they can adjust the names (and they don't have to adjust the format). There are then two choices: (1) Use "EDIT" from a command line, and avoid extensions except where SYN requires them (notably in ".ccf" files). (2) Use editors (e.g., "wordpad") and other programs that do not adjust the format of files of type ".txt" and stick to this type. Once a file is ready, change its name from "XXX.txt" to what's wanted (say "XXX.ccf") with a "rename" command. "perlxx" makes a file "XXX.BAT" from "XXX.ANY", which is not a bad compromise.
SYN scripts must know whether or not they are executing on a Microsoft Windows platform. The tests for this are in the script "setup.pm", where Perl expects to see "MSWin32" in its "$^O" variable. Check this if you have catastrophic errors when running SYN.