For Windows NT (or 2K, or XP), you need to put this line in ..\SYSTEM32\CONFIG.NT:

SHELL=%SYSTEMROOT%\SYSTEM32\COMMAND.COM /E:4096

Make sure you use a text editor, such as DOS Edit, TextPad, DEdit (included in this package). Do not use a word processor like MS-WORD (unless you use the option to save as "DOS text" or "plain text." Windows Wordpad is all right too, provided you save all files as "DOS Text." And if you want to use Windows Notepad, be sure that the Edit | Word Wrap option is off.

The second web page looks like this (jsm_Ex1B.Txt is the same as the first line below):

<P>Happy birthday to: <BR>
(Name and photo of person with birthday goes here)

Instead of manually changing both web pages, we'd like to set up a process that allows both to simultaneously set the name and photo of the contest winner/birthday-person on the days when they're the same person.

So we'll set up the following "make file," and put the person's name in the file jsm_Ex1.Inc.

The goal here is to make sure that every time there's a change to any of the three files, we'll build the corresponding HTML file.

For the contest winner, the HTML file will be jsm_Ex1A.Htm.

For the birthday announcement, the HTML file will be jsm_Ex1B.Htm.

So let's think about what we need to do here, in order to keep both pages updated.

First, if the "include" file (the name of the person, i.e. jsm_Ex1.Inc) gets updated, then we have a new birthday person/contest winner.

At that point, both the contest winner HTML file (jsm_Ex1A.Htm) and the birthday announcement HTML file (jsm_Ex1B.Htm) have to be updated.

What if jsm_Ex1A.Txt gets updated?  That's the file containing the first line of the contest winner announcement.

In that case, then the corresponding HTML file (jsm_Ex1A.Htm) needs to be updated.

What if jsm_Ex1B.Txt gets updated?  That's the file containing the first line of the birthday announcement.

In that case, then the corresponding HTML file (jsm_Ex1B.Htm) needs to be updated.

The following "make file" does precisely that: however there's just a little bit of "overhead" needed to ensure that everything gets updated properly.  You should find it in JSM_Ex.Zip under the name: jsm_Ex1.Mak.

1.  .PHONY:  all 2. 3.   all: jsm_Ex1A.Htm  jsm_Ex1B.Htm 4. 5.  jsm_Ex1A.Htm: jsm_Ex1A.txt  jsm_Ex1.inc 6.  <tab> Cat.Exe  jsm_Ex1A.txt  jsm_Ex1.inc  >  jsm_Ex1A.Htm 7. 8.  jsm_Ex1B.Htm: jsm_Ex1B.txt  jsm_Ex1.inc 9.  <tab> Cat.Exe  jsm_Ex1B.txt  jsm_Ex1.inc  >  jsm_Ex1B.Htm

Lines 5-6 are the two lines that tell us how to keep the contest winner file updated.

Let's focus on Line 5.

On the left of line 5, (preceeding the colon), we see the name of the final contest winner HTML file.  On the right, we see the two files that can "trigger" a change to it on the left.  As you recall, jsm_Ex1A.Txt contains the "core" of the file (i.e. without the name of the contest winner); whereas jsm_Ex1.Inc contains the contest winner's name.

In the language of "make files," the thing on the left is called the "target" . . . it's what needs to be "made" (or "built").  The items on the right of the colon are the "dependencies"--they're the files on which the target "depends."

"actions??"  What are those?

Take a look at line 6, in context:

5.  jsm_Ex1A.Htm: jsm_Ex1A.txt  jsm_Ex1.inc 6.  <tab> Cat.Exe  jsm_Ex1A.txt  jsm_Ex1.inc  >  jsm_Ex1A.Htm 7.

This is the sole "action" line that corresponds to line 5.

(If there were other "actions," they would follow line 6, until a blank line was encountered.)

The "action" in this case amounts to calling the program "Cat.Exe", and telling it to copy the contents of jsm_Ex1A.Txt and jsm_Ex1.inc to jsm_Ex1A.Htm.

If you're not a Unix user, you may not be familiar with Cat. This program simply takes one or more files, and concatensates them to the standard output.  In this case, these three files are simply merged together, and copied to the file on the end of that line.  (It's not important that you understand how to use Cat: it just happens to make this example a little simpler; and we'll be dispensing with it later.)

As you may recall, jsm_Ex1A.Txt is the main part of the contest winner announcement HTML file:

<P>And the winner is: <BR>

Whereas jsm_Ex1.Inc contains the actual name (and photo) of the person who won the contest, e.g.:

<table cellpadding=5>
<tr><td align=center>
<img src="jsm_al_e.jpg"></td></tr>
<tr><td align=center>
<nobr>Alfred E. Neumann</nobr>
</td></tr>
</table>

What happens when you put jsm_Ex1A.Txt together with jsm_Ex1.Inc (respectively) to form jsm_Ex1A.Htm?

Of course, we get the required:

<P>And the winner is: <BR>
<table cellpadding=5>
<tr><td align=center>
<img src="jsm_ex_al.jpg"></td></tr>
<tr><td align=center>
<nobr>Alfred E. Neumann</nobr>
</td></tr>
</table>

Before we go on, I should clarify a few points about the syntax for "actions:"

What's a "hard tab?"

It's a specific binary character (decimal 9), and if your word processor doesn't allow you to put it in, you'll need to consider getting one that does.  WordPerfect has a specific option designed for "hard tabs."  Windows Notepad will put one in if you hold down the left alt key and press a "0", followed by a "9" in the numeric keypad (of course you'll have to first make sure that the "num lock" is off).  Regrettably, DOS Edit won't let you put in hard tabs, so you'll have to choose between having line numbers (which DOS Edit will give you), and having hard tabs (which Notepad will give you).

Note that I've supplied two editors with this package that do allow you to put in hard tabs: Breeze (which won't work with a 32-bit file allocation table), and DEdit.  In both cases, you simply use the tab key.

What happens if a target file depends on a file that doesn't exist?  How does make determine whether the target is "older" than the target's "dependencies?"

The answer is that make will look for another target/dependency pair in which the file is the target.

If that file isn't found, then make will "complain" (i.e.: you'll get an error message.)

In short, make builds targets "recursively" (if that word means nothing to you, just take it for granted that make "does the needful").

We are ready for yet another "rule:"

For simplicity, let's start by pretending that lines 1-2 weren't there.

Given what we know so far, lines 3-4 appear to be a fairly straightforward case of a target (all), and two "dependencies" (i.e. files on which the target depends).

But there is no file named "all", is there?

This appears to violate the golden rule of dependencies, right?

(Gotcha!  ;-)

Well . . . maybe not.  The golden rule of dependencies refers to nonexistent files that are listed on the right, not the left.

So-o, in fact, there's no problem here.  Make will simply assume that the nonexistent file "all" is "newer" than the two files listed on the right of line 3, and then go about its business.

In fact, if there is no file named "all," and you simply remove line 1, nothing will change.

What if there is a file named "all"?

Ah.  Then we have a problem.  If the file called "all" is "newer" (more recently modified) than either of jsm_Ex1A.Htm or jsm_Ex1B.Htm, then nothing would happen.

That's not what we want.

Line #1's sole purpose in life is to declare that "all" is a "phony" target, i.e. a target that doesn't actually correspond to a bona fide file.

Hold it.

The analysis I just provided is insufficient: why have lines 1-4 at all?  What's wrong with just having lines 5-10?

This is because:

Note that you don't always have to type something quite as elaborate to invoke make.  You could create a DOS batch file called "mk.bat" which looked like this:

fmake -f %1.mak

At that point, you could then run the make process by typing:

mk jsm_ex1

(Don't forget to press the enter key afterwards.  Alternatively, you could make this command into a shortcut).

What if you decide that you need to override what GNU make ("FMake") normally does?  That is, you want to "force" it to update certain files.

The solution is to use the utility "FTouch". FTouch will alter the update-date of any file ... and change it to the current date.

You need only type this from the DOS prompt (or the Cmd prompt, if you're running NT, 2K, or XP):

ftouch filename

If you wish to include multiple file names on the command line, you can do so.  E.g.:

ftouch filename1 filename2

As with all GNU utilities, you can type the name of the executable, followed by a space, and --help to get more information.  I.e.:

ftouch --help

Let's get down to business ... here's jsm_Ex2.mak:

1.  .PHONY:  all 2. 3.   all: h\\jsm_Ex2A.Htm  \ 4.     h\\jsm_Ex2A.Htm  \ 5.     h\\jsm_Ex2A.Htm 6. 7.  h\\jsm_Ex2A.Htm: jsm_Ex2A.txt  \ 8.  h\\jsm_Ex2A.htm: jsm_Ex2.inc 9.  <tab> JSM.Bat  jsm_Ex2A  jsm_Ex2B 10. 11.  h\\jsm_Ex2B.Htm: jsm_Ex2B.txt  jsm_Ex2.inc 12.  <tab> JSM.Bat  jsm_Ex2B  jsm_Ex2B

But backslashes aren't just being ballyhooed for that reason: there's another justification for using them.

Take a look at line 7 of jsm_Ex2.mak:

1.  .PHONY:  all 2. 3.   all: h\\jsm_Ex2A.Htm  \ 4.     h\\jsm_Ex2A.Htm  \ 5.     h\\jsm_Ex2B.Htm 6. 7.  h\\jsm_Ex2A.Htm: jsm_Ex2A.txt  \ 8.  h\\jsm_Ex2A.htm: jsm_Ex2.inc 9.  <tab> JSM.Bat  jsm_Ex2A  jsm_Ex2B

Line 7 says that the target ("h\\jsm_Ex2aA.htm") is depending on two files: jsm_Ex2A.txt, and jsm_Ex2.inc.

What if you had a target that depended on a whole lot of files, say 5, 6, or even a dozen?

The backslash can be used to list these files in a way that limits the length of each line.  Why is this important?

Because we're not working with typical "word processors" here.  Physical lines matter to GNU make.  This is why I've been so careful to recommend that you use editors that recognize "DOS text."  By using backslashes in this context, you can keep all your lines relatively short, so that the files can be edited without horizontal scrolling.

Good things come in threes, or so they say.  (Maybe things that are merely annoying come in twos.)

So the backslash appears again, yet, this time in a pair.  Twins, so-to-speak.

In simple terms: the double-backslashes simply say "this is a subfolder".  Normally, in Windows, one would use a single backslash to reference a subfolder.  But GNU Make ("fmake.exe") is special: because it's designed for Unix programmers, the backslash has to occur twice, in order to satisfy Windows.

We'll return to the Golden Rule Of Subfolders again, after we examine JSM_Bat more closely ... in order to lay bare the hidden truth about the H and U subfolders, for all the world to see!

JSM.Bat is used in lines 9 and 12 of this example:

7.  h\\jsm_Ex2A.Htm: jsm_Ex2A.txt  \ 8.  h\\jsm_Ex2A.htm: jsm_Ex2.inc 9.  <tab> JSM.Bat  jsm_Ex2A  jsm_Ex2A 10. 11.  h\\jsm_Ex2B.Htm: jsm_Ex2B.txt  jsm_Ex2.inc 12.  <tab> JSM.Bat  jsm_Ex2B  jsm_Ex2B

It's important to understand what lines 9 and 12 actually do:

• The first file name listed after JSM.Bat is the input.

  It's presumed to be a text file (i.e., it ends in ".txt" - but you don't actually write the ".txt" portion) ... and it must exist on the current folder.  (The current folder is what the DOS or Cmd prompt shows you.)

• The second file name listed after JSM.Bat is the output.

  It's an .html file name, which will be created on the U folder (remember "U" is a short hand for "upload").  "Long" file names are allowed here, but don't actually write the ".html" part.  You must also not include a folder name.

• Why are the last portions of the file names (".txt" and ".inc") shown on lines 7-8 and 11, but not on lines 9 and 12?

  This is a critical question to ask.  The reason has a lot to do with the fundamental nature of "actions" and "targets/dependencies":

  The (golden) distinction between actions and targets/dependencies: Action lines follow the line(s) that specify targets and dependencies: each action line consists of a "call" to a program or DOS batch file.  The rules for each action line depend on the nature of the program or DOS batch file that you're calling.  So, if that program or DOS batch file assumes a certain ending portion of a file name (such as ".txt"), you shouldn't include it.  In contrast, targets and dependencies are processed by "fmake" itself.  The ending part of the file name is always required.

• JSM.Bat expands the INC@filename@ specifications.

  Let's take a look at JSM_Ex2a.Txt:

  
  <P>And the winner is:<BR>
  INC@jsm_Ex2.inc@  *** Name/photo of the winner ***
  <P>Congratulations!!</P>
  

  If you compare this with JSM_Ex1a.Txt, you'll notice that we actually added the last line after the table that shows the winner's name and photo (this table is contained in the "include" file, jsm_Ex2.Inc).

  You can have as many include files as you like, the only restriction is that they must have DOS ("8 and 3") file names.  The INC@ prefix must begin in the leftmost column of the line, and the file name must be immediately followed by an @-sign.  You can type whatever you like after the second @-sign  (it's a really good idea to put a comment there!).  You can even put include files on a different folder, but the folder name must be a DOS ("8 and 3") name.

  You can even have include files that are inside other include files!  But be careful: the system will not automatically detect a "loop" (for example, if you include a file within itself.)

• JSM.Bat also creates a "marker" file on the H subfolder.  The name of the marker file is the same as the name of the input file, plus a ".htm" on the end.

  A "marker" file is a special kind of file that has no data in it.  This is a very efficient way of setting a "flag," and/or specifying a time+date.  Why do this?

  Well, remember that the "fmake" program will only update the files that it believes it must update.  Remember the golden rule of make files?

  The golden rule of make files: If a target is "older" than any of the files on which it depends, then "make" the target by performing the "actions" required to build it.

  Now in this case, jsm_Ex2a.html is going to be created on the U subfolder.  It will be the complete birthday announcement file.  And presumably, you're going to upload it to another site.

  Suppose you have hundreds of such files ... but perhaps only a few will change at any one time.  For efficiency, you'll probably want to remove those files after you've uploaded them, right?  After all, if only three or four files have changed (out of a system with hundreds of files), why upload the whole system every time?  This is certainly the case if you have a telephone modem, or the server is slow.  (Or if you get charged for "bandwidth".)

  So the "marker" files tell the program fmake which files need to be updated.  This point deserves a bit more emphasis.

Take a look at the file dates and times on the U subfolder.  Observe that only jsm_Ex2a.html got rebuilt.

Now look at the H subfolder.  The file update time for jsm_Ex2a.htm is the same as the update time for jsm_Ex2a.html ... but it's after the update time for jsm_Ex2b.htm.

So what's really going on here is that the "marker" file preserves a record of which HTML files were built, and when.  You can FTP the files on the U folder to your web site, and delete them afterwards.

This makes it particularly easy and efficient to maintain a web site with hundreds, or even thousands of HTML files that depend on one another.  You rebuild and upload only the HTML files what you need.  At the same time, the "marker" files don't take up any space on your computer.

What if some hacker attacks your web site, and you need to rebuild all the files?

Easy: just delete the "marker" files on the H subfolder, and everything will be rebuilt!  

All these benefits arise because the marker files are the "targets" for the golden rule of make files:

(For the curious: the reason why I need to call DOS batch files to do simple operations such as a move, copy, or delete is that Windows NT "hobbled" the DOS command processor: you can't manipulate "long" file names from command.com - instead, you have to use the Cmd prompt.  Unfortunately, GNU make automatically invokes the DOS command processor to perform its "actions."  So these extra DOS batch files ensure that everything will work properly on all Windows operating systems.)

A word of warning about FEcho: it behaves rather oddly if you use certain special characters, such as the asterisk, the backslash, the less-than or greater-than signs, and the bar ("pipe").  I recommend that you avoid all characters that aren't used in normal punctuation.  Also, if you need to use a double-quote, put a backslash immediately in front of it, e.g.:

FEcho \"this is a quote\"

Notice that the invocations of FEcho in lines 13 and 14 are preceeded by an @-sign.  In simple terms, the @-sign prevents the command from appearing on your screen.

(In not-so-simple terms: the program fmake calls an instance of the DOS command processor to execute every action.  The @-sign tells DOS not to print the command on the screen, just as it would in a DOS batch file.)

Why would you want to prevent an action from being printed on the screen?  The answer depends on what you want the person running the make file to see.  Since the purpose of the FEcho commands are to tell the user something: we want to print what FEcho echos, not the entire command itself.

In general, I don't use an @-sign on any action that could possibly fail.  This is because I want the user to see precisely which action actually failed, so that they can diagnose the problem as quickly as possible.  However, if you prefer to conceal the complexity of the processing from the user, then you should put an @-sign before each action.  Don't forget that the first character of any action line must still be a hard tab.

I can't overstate the benefits here: the DOS batch file actually controls the processing!  I.e., to update the web site, all you need to do is to change the DOS batch file.  This will alter the person's name and their photo JPEG in both HTML files!

All we really have is an announcement line (the first one), a JavaScript code section, and a closing line.

Remember example 3?  We included the file jsm_Ex3.inc there, and the contest winner name/photo name were "hard coded" in that example.

So every time a new contest winner/birthday person was announced, you had to update that file.  Furthermore, you had to update the "make" file (jsm_Ex3.mak), in order to make sure that the image file was copied to the proper folder - so it could be uploaded.

In this case, we're doing the whole thing with JavaScript and DOS batch files.

That would be interesting enough, but there's quite a bit more.

Go ahead and run the batch file.  Simply go to the DOS prompt (use the "Cmd" prompt if you're on NT, 2K, or XP), and type jsm_Ex4  (Don't forget to press enter afterwards.)

Here's what you should see:

Set IMAGE=jsm_ex_N.jpg
Set NAME=Nancy
fmake -f jsm_Ex4.mak
JSM_Chk is done ... everything's okay, if you see no error messages!
DEST is u\special, IMAGE IS jsm_ex_N.jpg, and NAME is Nancy
If these are the last lines you see, (aside from
the termination announcement), then all files were
up-to-date).
jsm_Ex4.Mak is finished!!
jsm_Ex4.Bat is finished!

Note that the first three lines come from the batch file, as does the last one.  The fourth line comes from JSM_Chk.Bat, and it lets you know that all the prerequisites are satisfied for the JSM system.

You'll find the remaining lines in sections C and B of the make file (jsm_Ex4.mak).

Now, take a look at the file h\jsm_ex4.tmp.  Compare it with jsm_Ex4.js.

What you should notice is that the JavaScript has been "compressed": remarks have been removed, and macro replacements (as specified in JSM_Ex4.Ma1) have been done.  The lines are very long: this is due to the fact that the default line length for NoComJ is 240.

What's this file doing on the H subfolder?  One would think that this folder is for the "marker" files that I described earlier.

Well, that's right: but like many things in the JSM system, the H subfolder serves a dual purpose: it also holds the compressed JavaScript files that are part of your systems.

The goal here is to use the "Golden Rule of Make Files" in a way that lets you minimize the execution time of a cycle: JavaScript files are "compressed," only if they've changed since the last time a system was "made" (i.e. built with a make file).

In fact, if JSM_Bat doesn't find included files on the current folder, it will include files from the H subfolder  (the current folder is what the DOS prompt shows).

This leaves us with two questions.

Why put compressed JavaScript files on the H subfolder?

The answer's easy: we don't want them cluttering up the files on our main folder.  We don't want to be editing the compressed JavaScript files ... we don't even want to know that they exist!

But there's a deeper question: how did jsm_Ex4.js get compressed into jsm_Ex4.tmp on the h subfolder?

First, line 2 calls JSM_Chk, to make sure that the required conditions are present, in order to run the system.

The next "@FEcho"  (line 3)  actually informs the user about the status of the variables: note that IMAGE and NAME were set by the DOS batch file  (jsm_Ex4.Bat)  whereas DEST was set in the make file  (jsm_Ex4.Mak).

Lines 4 through 6 make sure that all the relevant subfolders are created.  Note that if you provide this system to a user, they need not actually create these subfolders before running the system.

Lines 8-10 provide the announcement; this may be important, if you're running the program fmake from a DOS batch file.  They'll inform the user about the beginning and end of the "make file" processing.

So far, I haven't said anything about line 7.  This line calls my program FileStat.

Section B has an FEcho command as its only action line.  This informs the user that the make file has completed execution ... this nessage can often be helpful for debugging.

Section E demonstrates how to produce an output file name with a space  (or other special characters)  in it.

If you want the best possible level of "browser compatibility," I recommend that you avoid such file names.

If it finds that a line begins with a percent sign, and the remainder of the line contains at least one character following the initial percent sign, followed by an equals sign, one more character, and a second percent sign ... then it will then check to see whether VARNAME is a defined (DOS) variable, with the value of "X" (only single-character values will be recognized).

If VARNAME doesn't exist, or it isn't equal to "X", then the rest of the line will be ignored.  Otherwise, the rest of the line (after the second percent sign) will be included.  Both VARNAME and the value will be converted to upper case, prior to any comparison.

This method is a primitive substitute for "conditional inclusion."

This feature has been incorporated into JSM.Bat: if JSM.Bat is called with a third operand, it will assume that this is the name of a DOS variable, which should be set to 1.

For example, if I want a file to be used in two different systems, I'll use this sort of make file syntax:

1.  h\\SYS2_f.Htm: SYS1_f.txt 2.  <tab> JSM  SYS1_f  SYS1_f  SYS2  SYS2_f

The third operand to JSM.Bat tells it to set the variable SYS2 to a value of 1.  The fourth operand tells it to create the "marker" file Sys2_F.htm on the H subfolder (note that this is the "target" for the make action.

Within the source file, SYS1_f.txt, I could have lines like this:

%SYS1=1%This line appears IFF the DOS variable SYS1 is 1
%SYS2=1%This line appears IFF the DOS variable SYS2 is 1

Either or both of these lines could specify file inclusions; so in effect I get two versions of the resulting file: one will be "instantiated" if the DOS variable SYS1 is 1, and the other if the DOS variable SYS2 is 1.

The third and fourth operands to JSM.Bat are optional.