Batch Converting Multiple Word DOC Files to PDF in Scattered Folders

I had a large number of .doc files produced by Microsoft Word.  These files were in assorted folders.  I wanted to convert some or all of these files to PDF format.  This post describes the steps I took.

I had already tackled similar problems in several other posts, including these:

• Batch Merging Many Scattered JPGs into Many Multipage PDFs - Clarified
• Batch Converting Many Microsoft Word (.doc) or WordPerfect (.wpd) Files to PDF - Streamlined
• Batch Converting Many Text Files to PDF

This post does not detail all of the steps described in those other posts.  If a step described here is not clear, perhaps one of those posts expresses it more lucidly.

I started by getting a list of the DOC files to be converted.  For this, I opened a command window and typed "DIR /s /b /a-d > doclist.txt."  It was OK if this DOC list included files that I did not want to convert:  I could go through the list manually at this point, deleting those that I did not want to convert, or I could do that in the next step.  The next step was to copy and paste the list of files from doclist.txt into Microsoft Excel or some other spreadsheet.  This gave me a list of file and path names that looked like this:

D:\Folder3\Subfolder 8\Filename Z.doc

Since some paths and/or filenames contained spaces, I would tend to use quotation marks in commands relating to them, in both Excel and the command window.  In Excel, I used the REVERSE function and other spreadsheet commands to extract the path (e.g., "D:\Folder3\Subfolder 8\") from the filename (e.g., "Filename Z.doc").  So now I had separate columns showing the paths and the filenames for each entry in doclist.txt.  This would be a good point for using formulas to identify groups of DOC files that I did not presently wish to convert to PDF.

The next step in the spreadsheet was to identify the filename without the extension, and to add PDF instead of DOC to that rump filename.  In other words, in this step I went from having Filename Z.doc to having Filename Z.pdf.  This gave me the essential ingredients for the batch commands that I would assemble on each line of the spreadsheet and would then paste into Notepad and save as a .bat file, so as to automate the conversion.

There were two ways to proceed at this point.  One was to leave the DOCs in place, in their home folders, and do the conversion and replacement right there.  I didn't like that approach.  It was too hard to be sure of what had happened in all those scattered folders.  The approach I preferred was to bring all those .DOC files together in one central folder, do the conversion, and then use the spreadsheet to construct batch files that would put those PDFs back where they belonged and, optionally, delete the DOCs from which they had come.

Bringing the DOC files to a central folder could be done very easily with a search program like Everything, searching for *.doc.  It could also be done with batch commands constructed in the spreadsheet.  An Excel formula producing a command of the latter nature would be something like ="move /-y "&char(34)&[cell containing filename including .doc extension]&char(34)&" D:\CentralFolder").  It would be important not to take this step -- that is, not to move the files away from their home folders to the central folder -- until I already had a list of where the files came from originally.  Without that, I'd have a big collection of DOC files and no idea of where they belonged.  Note that files bearing identical names, coming from different folders into one, could require some advance manual renaming to avoid overwriting.  In that case, after renaming but before moving, it would probably be advisable to re-run DIR, so as to get the current filenames.

Once the files were all in a central location (in this case, D:\Conversion), it was time to work up the batch conversion process.  For this, first, I set the General and Options tabs in Bullzip (my free PDF printer) so that it would operate without asking questions or opening PDFs, and would save the PDFs to a designated folder (D:\Conversion\PDFs).  Then I saved this command into a batch file that I called Converter.bat:

FOR /F "usebackq delims=" %%g IN (`dir /b "*.doc"`) DO "C:\Program Files (x86)\Microsoft Office\Office11\winword.exe" "%%g" /q /n /mFilePrintDefault /mFileExit && TASKKILL /f /im winword.exe

I saved Converter.bat in the folder containing the DOC files (in this case, D:\Conversion) and ran it.  It worked away for a while, at the speed of one document every few seconds, until it had produced one PDF for each of my DOC files.  Several times during the process, Word or Bullzip stalled with error messages (e.g., "Word cannot start the converter Rftdca32.cnv").  This seemed to result primarily from corrupted Word docs.  There seemed to be little alternative but to delete those files except where I could find a backup.

Now I had a set of DOCs and a set of PDFs.  One easy way to make sure that I had a copy of PDF for each DOC was to view the folders using a Windows Explorer alternative like FreeCommander.  In FreeCommander, I could combine the DOCs and PDFs together, sort by file type, select all DOCs, re-sort by file name, and look for instances in which alternating lines were not regularly highlighted.  (In Windows 7, Windows Explorer had lost the ability to retain highlighting after files were re-sorted.)  At this point or later, one could then just delete all DOCs that did have a corresponding PDF.  DoubleKiller Pro would provide a similar approach.  Another method, more suitable for large numbers of files, was to use the DIR and spreadsheet approach outlined above, writing formulas to check for identical filenames (not counting extensions).  Of course, there was no need to actually delete the DOCs if I wanted to keep both the PDF and the DOC.

I postponed that step to verify, first, that I would not be needing any of the DOCs anymore.  I had previously worked on ways to check PDFs by converting them to JPGs and seeing which ones converted successfully.  In that previous effort, IrfanView (my preferred tool) had not behaved as expected, so I had grappled with other approaches.  This time, however, the quick IrfanView batch conversion went smoothly.  This gave me a JPG displaying the first page of each PDF.  My decision there was that, in the interests of speed (and to avoid having to go through every page of every PDF),  I was content to look just at the first page.  There could still be errors on later pages of a PDF, but that would be rare.  If the first page came through OK, I could be fairly confident that most docs converted successfully.  So now, using IrfanView, I flipped through those JPGs quickly.

With these steps out of the way -- PDFs checked, superannuated DOCs deleted -- I went back to my Excel spreadsheet and worked up batch commands to move the new PDFs back to where the DOCs had been.  I had changed a couple of names along the way, so I had to move those manually, but the rest went automatically.  Project done!

Batch Merging Many Scattered JPGs into Many Multipage PDFs - Second Try

I had previously looked for a way to combine multiple JPG files into a single PDF.  As explained in more detail in that previous post, the specific problem was that I might have sets of several JPGs in a single folder that should be merged into several different PDFs, and there might be multiple folders at various places that would have such PDF sets.  Hence, if I wanted to automate this project across dozens of folders containing hundreds of JPGs, it seemed that I would need a command-line solution rather than a GUI.  This post updates that previous attempt.

There were commercial programs that seemed to offer the necessary command-line capabilities, such as PDF Merger Deluxe ($30) and ParmisPDF Enterprise Edition ($300).  A search suggested, however, that PDFsam might offer a freeware alternative.

Assembling the List of JPGs to Be Converted

Before investigating PDFsam, I decided to get a more specific sense of what I needed to accomplish.  In a command window (Start > Run > Cmd), I navigated to the root of the drive I wanted to search (using commands like D: and "cd \").  (The root was the folder whose command prompt looked like C:\ or D:\, as distinct from e.g., C:\FolderZ.)  Being at the root folder meant that my command would apply to all subfolders on that drive.  Once I was there, I ran this command:

DIR *.jpg /s /b /a-d > jpgslist.txt

That gave me a list of files (but not directories, /a-d) in all subdirectories (/s), listed in bare (i.e., simple, /b) format, saved in a new file called jpgslist.txt.  (For more information on DIR or any other DOS-like command, type DIR /? at the command prompt, or search for informational webpages.)  If I'd had files with a .jpeg (as distinct from .jpg) extension, I would have added a second line, referring to *.jpeg and using a double-arrow (>>) to tell the program to add these to the existing jpgslist.txt, rather than creating a new jpgslist.txt (which was what the single arrow (>) would do).

Now I wanted to see which folders had more than one JPG.  I would use Microsoft Excel to help me with this.  I could either open jpgslist.txt and copy its contents into an Excel spreadsheet, or import it into Excel.  In Excel, I did a reverse text search to find the last backslash in each text line, so as to distinguish file names from the directories holding them.  I sorted the spreadsheet by folder name and file name.  I set up a column to detect folders containing more than one JPG, and deleted the rows of folders not containing more than one JPG.  I might still want to do another search and conversion for isolated JPGs at some point, but that would be a different project.

Next, I wanted to see if I could eliminate some folders.  For instance, I might not want to PDF and combine JPGs that were awaiting image editing, or important photos whose quality might get degraded in the PDF conversion.  In other words, I decided that this particular project was just for those JPGs that I was going to combine into a single PDF and then delete.  To get a concise list of folders containing multiple JPGs, I went into Data > Filter > Advanced Filter.  (That's Excel 2003.)  I moved the output into another worksheet.  I could then do a VLOOKUP to automatically mark rows to be deleted.  So that gave me the folders to work on.

Now it was time to decide which files to combine, and in what order.  In some cases, I had named files very similarly -- usually with just an ending digit change (e.g., Photo 01, Photo 02 ...).  So I set up a couple of columns to find the filename's length, subtract a half-dozen characters, and decide whether those first X characters were the same as in the preceding row.  If so, and if both were in the same folder, we had a match.  I discovered, at this point, that one or two folders contained large numbers of files.  I decided to combine those manually.  With those out of the way, it seemed that the next step was to decide the names of the resulting multi-image PDFs (e.g., Medieval Churches.pdf), and to put those names on the spreadsheet rows, next to the individual JPGs that would go into them.

At this point, as described in another post, I learned how to use PDFsam to combine several PDFs into one PDF.  So I had a rough idea of the start of my project (i.e., identify the JPGs that I would want to merge into a single output PDF), and I also had a basic sense of the end of my project (i.e., use PDFsam to merge multiple PDFs into that single output PDF).  I was missing the middle part, where I would convert the original JPGs into single-page PDFs and would get them into a form where PDFsam could work on them.

Converting Individual JPGs to Individual PDFs

I had originally assumed that I would start by converting the JPGs to PDFs within the various folders where they were originally located.  So if I had File1.jpg in E:\Folder1, and if I had File2.jpg in E:\Folder2, my conversion would result in two files in each of those folders:  File1.jpg and File1.pdf in Folder1, and File2.jpg and File2.pdf in Folder2.  Then I would use PDFsam to merge the PDFs (i.e., File1.pdf and File2.pdf) from those locations; delete the original JPGs and PDFs; and move Output.pdf to an appropriate location.

I didn't entirely like that scenario.  It seemed like it could make a mess.  As I reviewed another post in which I had worked through similar issues, I decided that a better approach might (1) make a list of original JPG file locations, (2) move those JPGs to a single folder where I could convert them to individual PDFs, (3) merge the individual PDFs into concatenated PDFs, (4) delete the individual JPGs and PDFs, and (5) move the concatenated PDFs to the desired locations.  I decided to try this approach.

One problem with moving files from many folders to one folder was that there might be two files with the same name.  They would coexist peacefully as long as they were in separate folders; but when they converged into one target folder, something would get overwritten or left behind.  It seemed that a first step, then, was to rename the source JPGs, so that each one would have a unique name -- preferably a short name without spaces, potentially making it easier to write commands for them as needed.  In this step, as in others, it would be important to keep a list indicating how various files were changed.  To rename the files where they were, I returned to my spreadsheet and used various formulas to produce a bunch of rename commands of this type:

ren "D:\Folder Name\File Name.jpg" "D:\Folder Name\ZZZ_00001.jpg"

after doing a search to make sure that my computer did not already have any files with names resembling ZZZ_?????.jpg.  The spreadsheet gave me one REN command for each JPG.  I copied those commands into a Notepad file, named it Renamer.bat, and double-clicked to run that batch file.  (A slower and more cautious approach would have been to run it in a command window, perhaps with Pause commands among its renaming lines, so that I could monitor what it was doing.)  A search in a file-finding program like Everything now confirmed that the number of files on my computer with ZZZ_?????.jpg names was equal to the number of files listed in my spreadsheet.  I cut and pasted all those ZZZ_?????.jpg files from Everything to a single folder, D:\Workspace.  (I could also have used the spreadsheet to generate Move commands to run in a batch file for the same purpose.)

Now I had a spreadsheet telling me what the original names of these ZZZ_?????.jpg files were, and I had all those ZZZ files together in D:\Workspace.  My spreadsheet also told me which of them were supposed to be put together into which merged output PDFs.  But they weren't ready to be merged by PDFsam, because they were still JPGs, not PDFs.

To convert the JPGs to PDFs, I could have prepared another batch file, using IrfanView commands to do the conversion, like those that I had previously played with in another project.  But I figured it would be easier to use IrfanView's File > Batch Conversion/Rename.  There, I told IrfanView to Add All of the ZZZ files to its list.  I specified PDF as the Batch Conversion Settings output format, and set its Options > General tab to indicate that Preview was not needed (and adjusted other settings as desired).  I told it to Use Current ("Look In") Directory as the Output Directory for Result Files (adding "Output" as the name of the output subfolder to be created).  Then I clicked Start Batch.

That produced one PDF, in the Output subfolder, for each original JPG.  I hadn't done anything to change their filenames, so ZZZ_00001.jpg had been converted to ZZZ_00001.pdf.  Spot checks indicated that the resulting single-page PDFs were good.  I deleted the original ZZZ*.jpg files, moved the output PDFs up into D:\Workspace, made a backup, and turned to the project of merging those single-page PDFs into multipage PDFs.

Preparing XML Files to Concatenate PDFs

In my spreadsheet, I had already decided which ZZZ files would be merged together, and what the resulting multipage PDFs would be called.  Now -- referring, again, to the other post in which I worked through the process of using PDFsam -- I needed that information to create File Value lines for a set of ConcatList.xml files that PDFsam would then merge into a set of output PDFs.

In other words, I would have a batch file that would run PDFsam, and I would have a data file, in XML format, to specify the single-page PDFs that PDFsam would combine into the multipage output PDF.  I would have a pair of such files (i.e., a batch file and an XML data file) for each resulting multipage PDF.  In my particular project, there were 65 single-page PDFs, and they would be combined into a total of eight multipage PDFs.  So I would have eight pairs of .bat + .xml files, and the eight XML files would contain a total of 65 File Value lines.

To the extent possible, I would want to automate the creation of these batch and data files.  Sorting 65 data lines into eight different XMLs would be tedious and easily confused.  Things would get much worse if I wanted, in some later project, to use these procedures for hundreds or thousands of JPGs or other files.

I began by adding a column to my spreadsheet that contained the exact text of the appropriate File Value line.  Example:  for ZZZ_00001.pdf, the line would read like this:

<file value="D:\Workspace\ZZZ_00001.pdf"/>

To produce that result, if the Excel spreadsheet's cell D2 contained ZZZ_00001.pdf, its cell E2 would contain this formula:

="<file value="&CHAR(34)&"D:\Workspace\"&D2&CHAR(34)&"/>"

(Note the use of CHAR(34) to add quotation marks where they would otherwise be misunderstood.)  Next, I wanted to assign those File Value lines to the appropriate batch files.  A search confirmed that I didn't have any files on my data drives with YYY_????? names, so I decided that my first multipage output PDF would be called YYY_00001.pdf, and that the pair of files used to produce it would be YYY_00001.bat and YYY_00001.xml.  In other words, the File Value line for ZZZ_00001.pdf (above) would have to be one of the File Value lines appearing in YYY_00001.xml.  But the next File Value line in YYY_00001.xml could be a ZZZ file out of sequence (e.g., ZZZ_00027.pdf), if that happened to be the next original file that I wanted to put into YYY_00001.pdf.

Since YYY_00001.pdf was going to be the temporary working name of the multipage PDF that I would ultimately be calling "Short Letters to Mother," I sorted the spreadsheet (making sure to first use Edit > Copy, Edit > Paste Special to convert formulas to values) by the column containing my those ultimate desired filenames, and worked up a column indicating the corresponding YYY filename.  In other words, each cell in that column contained one of eight different labels, from YYY_00001.pdf to YYY_00008.pdf.

With that in place, I was ready to generate some batch commands.  Each batch command would use the ECHO command to send the contents of spreadsheet cells to YYY*.xml files.  My first attempt looked like this:

echo <file value="D:\Workspace\ZZZ_00001.pdf"/> >> YYY_00001.xml

The double greater-than signs (">>") indicated that YYY_00001.xml would be created, if it didn't already exist, and that the File Value line (above) would be added to it.  This first try produced an error, as I feared it might:  ">> was unexpected at this time."  The less-than and greater-than symbols were confusing Windows.  I had to modify the formula in my spreadsheet (or use Ctrl-H) to add carets (^) before them, like this:

^<file value="D:\Workspace\ZZZ_00001.pdf"/^>

That worked.  Now YYY_00001.xml contained that line.  With commands like that for each of the 65 single-page PDFs, my spreadsheet now had cells like these:

echo ^<file value="D:\Workspace\ZZZ_00051.pdf"/^> >> YYY_00004.xml
echo ^<file value="D:\Workspace\ZZZ_00025.pdf"/^> >> YYY_00006.xml

I sorted the rows in my spreadsheet by the appropriate column to make sure the single-page PDFs would get added to their multipage PDFs in the proper order.  (If necessary, I would have added another column containing numbers that I could manipulate to insure the desired order.)  Then I copied all those cells over to Notepad and saved it as a new batch file that I called Sorter.bat.  I ran Sorter.bat and got eight XMLs, as hoped.  Spot checks seemed to indicate that the process had worked correctly.

My eight XML files were not complete for purposes of PDFsam.  Each of them would need lines of code preceding and following the File Value lines.  As described in the other post, those files would begin with

<?xml version="1.0" encoding="UTF-8"?>
<filelist>

and would end with

</filelist>

I saved those two beginning lines into a text file called Header.txt, and I saved that ending line into another text file called Tailer.txt.  Now I needed to combine them with the XML files that Sorter.bat had just created.  For that purpose, it seemed that my spreadsheet could benefit from a separate page dedicated to XML file manipulation.  I added that page, filtered my existing page for unique values in the YYY*.pdf column, and placed the results on that new page. 

I could now see that I was too early in adding .xml extensions to the eight files.  I went back into the spreadsheet and changed it to produce files without extensions (e.g., YYY_00001 instead of YYY_00001.xml), and then I deleted the XML files and re-ran Sorter.bat (as modified) to verify that it was all still working.

With that change, I returned to the spreadsheet's XML Files page.  Next to each of the eight XML filenames, I added columns to produce commands of this type:

copy Header.txt+YYY_00001+Tailer.txt YYY_00001.xml

I put those eight commands into a batch file and ran it.  It worked:  I had eight XML files with everything that PDFsam needed.  There was just one small glitch:  at the end of each resulting XML file, there was a little arrow, pointing to the right.  Searches didn't yield any obvious explanations.  I wasn't sure if it would make a difference; I thought it might just be a symbol representing end-of-file or line feed.  I decided to forge ahead and see what happened.  Except for that little character, I had exactly what I needed for my XML files.

Preparing Batch Files to Use the XMLs

The next step was to create a matching YYY_?????.bat file for each YYY_?????.xml file.  This batch file would run the commands necessary to merge the single-page PDFs listed in the XML file.  I would use the same techniques as in the XML files.  There would be no Tailer.txt file this time; the line that would need to change, in each BAT file, was the very last line.  So my COPY command (above) would just have Header.txt plus the variable line to produce the YYY_?????.bat file.  The variable (last) line of the batch file had to look like this:

%JAVA% %JAVA_OPTS% -jar %CONSOLE_JAR% -l D:\Workspace\YYY_00001.xml -o D:\Workspace\Merged\YYY_00001.pdf concat

In other words, it would have two variables:  the name of the XML file providing the input, and the name of the PDF file containing the output, saved in a Merged subfolder.  It was pretty straightforward, by now, to use the spreadsheet to generate the necessary commands and to run them in another Sorter.bat file (see above).  I just had to remember to delete my previous YYY_????? files (without extension), so that their contents would not get thrown into the mix.  I did wish that PDFsam's -l option were expressed as -L, so that nobody would think it was the number one, but I wasn't yet ready to experiment and find out whether -L would work just as well.  Anyway, to produce a line like the one shown immediately above, my Excel formula looked like this:

="echo %%JAVA%% %%JAVA_OPTS%% -jar %%CONSOLE_JAR%% -l D:\Workspace\"&A2&".xml -o D:\Workspace\Merged\"&A2&".pdf concat >> "&A2 

where cell A2 contained the filename without extension (e.g., YYY_00001).  I had to use double percentage symbols to get a single one to come through.  I put the resulting eight lines into Sorter.bat, and it produced eight YYY_????? files, as before.  I ran another batch file to combine Header.txt plus the YYY_????? files to produce YYY_?????.bat -- again, same as above, but without Tailer.bat and making sure to produce .bat files, not .xml files. 

These steps gave me eight pairs of .bat and .xml files.  The batch files looked good, except for the little arrow at the end (above).  Now, if all went well, the batch files would run, would consult the XML files for the lists of single-page PDFs to merge, and would produce eight YYY_?????.pdf output files in the Merged subfolder.  I would not want to run the batch files manually, if I were producing a large number of merged PDFs, so I wrote a batch file to run the batch files.  The commands in this file looked like this:

@echo off
call YYY_00001.bat
call YYY_00002.bat

and so forth.  I ran this batch file.  It gave me error messages.  I opened a command window and typed just its first action line:  call YYY_00001.bat.  The error was:

FATAL  Error executing ConsoleClient
java.lang.Exception: org.pdfsam.console.exceptions.console.ParseException: PRS001 - Parse error. Invalid name (D:\Workspace\YYY_00001.xml) specified for <l>, must be an existing, readable, file.

Oh.  Dumb mistake.  The XML files weren't in D:\Workspace.  I moved them and tried again on the command line.  Another error:

Error on line 5 of document file:///D:/Workspace/YYY_00001.xml : Content is not allowed in trailing section.

That little arrow was on line 5.  I moved it to line 6 and tried again.  Same error, except now it said the problem was on line 6.  I deleted the little arrow and tried again.  That solved that problem.  Now a different error:  "The system cannot find the path specified."  That was probably because I had not yet created the Merged subfolder.  Apparently PDFsam was not going to create a folder that did not already exist.  I created it and tried again.  Success!  YYY_00001.pdf was created in the Merged folder with the desired single-page PDFs in it.

Now I just had to figure out how to prevent that little arrow from appearing in the XML files. It came at the end of both the XML and the BAT files, and it got there when I used the COPY command to combine the header, the command, and the tailer text files.  The solution was to add the /b switch:

copy /b Header.txt+YYY_00001+Tailer.txt YYY_00001.xml

With that change, I went back through the process of creating the XML files.  Then I tried running YYY_00001.bat again.  I got an error:  "Cannot overwrite output file (overwrite is false)."  Oops.  I had forgotten to get rid of the previously produced YYY_00001.pdf in the Merged folder.  This time I was successful without having to manually remove the little arrow -- it wasn't there anymore in the new YYY_00001.xml.  I ran the batch file that called the eight YYY_?????.bat files.  It ran and produced eight multipage PDFs.  Those eight contained a total of 65 pages.  I combined them all in Acrobat, just to take a quick look.  They were all good.

Putting the Multipage PDFs Back Where They Belong

Now I needed to decide where to put the multipage PDFs.  In this case, the individual PDFs that went into each of the multipage PDFs had all come from the same folder.  That is, I did not have Folder1\PDF1 plus Folder73\PDF2 going into BigPDF-A.  So I could use the spreadsheet to determine semi-automatically the path and filename for a rename command.  I wound up with Rename commands like this:

ren YYY_00004.pdf "Medieval Craft Workers.pdf"

followed by Move commands like this:

move /y "Medieval Craft Workers.pdf" "E:\IMAGES\Medieval Craftsmanship\"

I verified that the multipage PDFs had returned to the folders whence the single-page PDFs had originated.  This project was finished.

Combining PDFs with PDFsam: Introductory Syntax

I was using Windows 7.  I had a project that would benefit from automated merging of multiple PDFs into a single PDF.  It looked like PDFsam would be useful for this purpose.

PDFsam had GUI and Console options.  In other words, it could be accessed through a user-friendly interface, like most Windows programs, and it could also be used on the command line.  My project had certain complexities, such that the GUI approach would not be ideal.  This post describes the steps I took to learn how to use the Console.

I began with the Console section of the PDFsam wiki.  It led to a page providing information on console parameters and commands.  The explanation was too thin, so I did a search for more guidance. This led to a 33-page Tutorial (installed with the program files). It also led to a thread that reminded me not to forget the PDFsam Forums.

The Tutorial (p. 18) seemed to say that, in PDFsam-speak, what I wanted to do was to Merge files, and for this I would use the Concat option. Other options, not of interest here, included Split and Encrypt. It appeared that PDFsam syntax would call for very long commands. Looking for examples, I went to a forum thread, but that pointed me back toward the wiki page (above).

The Tutorial said that, to make PDFsam run from the command line (i.e., Console), I could either type a certain command or just use one of the scripts in the bin folder where the program was installed (e.g., C:\Program Files\pdfsam\bin).  In that bin folder, it appeared I had my pick from two scripts, provided in Linux (.sh) and Windows batch (.bat) versions.  Since I wanted the Console, not the GUI, I focused on run-console.bat.  Its contents seemed to address various details that I didn't clearly understand, and didn't necessarily want to study; it just looked like the thing I would need to use.  So I created a shortcut to it and put that in my Start Menu. I also edited the Tutorial, adding bookmarks to the various sections, and moved it to the Start Menu too.  (My customized Start Menu would survive any subsequent Windows reinstallation, so I probably wouldn't need to do this housekeeping again, if I had to install PDFsam in a new Windows installation sometime down the line.)

Unfortunately, the run-console.bat batch file didn't work for me.  It gave me an endlessly scrolling set of messages. They were ripping past too quickly to read.  I hit PrintScreen, opened IrfanView (any image editor would do, as would Microsoft Word or Wordpad), and pasted the screenshot (Ctrl-V).  (I could have just hit Ctrl-C, or possibly the Pause key.)  Now I could see that it was just the same error message, repeating over and over:

java is not recognized as an internal or external command, operable program or batch file

Why wasn't my system recognizing java?  I right-clicked on run-console.bat, chose Edit, and looked for the line that referred to java. I couldn't quite figure out where the problem was, so I stuck in a "pause" command somewhere, saved the batch file, and, this time, ran it from the command line instead of from the shortcut. That way, the error statements would stay onscreen instead of scrolling past too quickly or disappearing when the batch file finished running. (This was another instance where it was handy to have the right-click option, "Open command window here," provided by Ultimate Windows Tweaker.)

Running the batch command meant just typing its name and hitting Enter. It paused where I had put the pause command, without any obvious errors, so I moved the pause command further down, saved, and repeated the cycle. (Running run-console.bat again required just hitting the Up key to repeat the command.) That's where the problem was: now I had the endless scrolling again. I hit Ctrl-C a couple of times to abort the batch file.

I played around with the batch file for a while, and eventually realized that maybe the problem was that the JAVA_HOME variable had not yet been assigned a value on my system. It appeared that the batch file was supposed to tell me this; if so, it wasn't working right. I went into Start > Run > SystemPropertiesAdvanced.exe > Environment Variables and, sure enough, no JAVA_HOME variable. I had already installed the Java Runtime Environment, and I almost always used the default installation paths when installing programs, so the advice seemed to be that the JAVA_HOME variable should point to C:\Program Files\Java\jre6. Since this folder name ("Program Files") had a space in it, apparently I would need to use the shortened, DOS-style name for it -- known as an "8.3" filename because it would have eight characters before the dot and three afterwards (e.g., yourfile.txt).

I knew the shortened name of that folder would probably contain Progra~1 (instead of "Program Files"), and I could have just experimented with that, but I had seen instances where it would be Progra~2 or something else, and anyway I wanted to know how to get the 8.3 name. Microsoft advised using the GetShortPathName function to figure it out, but that seemed to involve programming, and programming is a lot of work. Instead, I ran a search that took me to ShortPath by Marcello Zaniboni. To get ShortPath to work from the command line, I tried the C:\Windows shortcut trick, but it didn't work. I didn't want to add ShortPath to my PATH yet, so I just opened a command window in the folder where ShortPath.exe was located, typed "ShortPath " (with an ending space) but didn't hit Enter, and then dragged the C:\Program Files\Java\jre6 folder into that command window from Windows Explorer. (I think this worked because I had installed DropCommand. Otherwise I might have had to type it out, with quotation marks.)

ShortPath told me that, actually, the short path to that folder was C:\PROGRA~2\JAVA\JRE6. So I went back into SystemPropertiesAdvanced.exe > Environment Variables > System Variables > New > Variable Name = JAVA_HOME, Variable Value = C:\PROGRA~2\JAVA\JRE6. I OKed out of there and rebooted.

After doing that, I still had to play with the batch file for a long time, in a quest to learn, remember, get lucky, or otherwise do what I needed to make it work. By the time I was done, I almost thought that I would have been further ahead just using the command given in the wiki:

java -Dlog4j.configuration=console-log4j.xml -jar pdfsam-console-2.1.1e.jar

except that that didn't work either because, as I soon realized, it was a Linux command. I also did not fare too well with the advice to type "run-console.bat -h concat" for information on the syntax for the Concat option, because the run-console.bat file itself was not yet working.

The Tutorial (pp. 19-20) said that I had three ways to indicate which files I wanted to merge. Instead of entering one parameter to indicate a directory and then entering another parameter to indicate one or more files in that directory, it seemed I would want the option that would allow me to specify a file (including its path) on a single line. Evidently I could list a number of PDF files in a separate XML file, and invoke that file (with its list of PDFs) by using the -l (that's an L, not a one) option. But it wasn't working right. Ultimately, I posted a question on it. Andrea (a guy from the Netherlands), creator of PDFsam, posted a reply within 36 hours. And that got me where I needed to go. I was able to get a test run to work, with a run-console.bat file whose contents (viewed in something like Notepad, of course, not in a word processor like Word that would add all kinds of invisible junk) were as follows:

@echo off

set JAVA=%JAVA_HOME%\BIN\JAVA

set JAVA_OPTS=-Xmx256m -Dlog4j.configuration=console-log4j.xml

set CONSOLE_JAR="C:\Program Files (x86)\pdfsam\lib\pdfsam-console-
2.3.1e.jar"

@echo on

%JAVA% %JAVA_OPTS% -jar %CONSOLE_JAR% -l D:\Current\ConcatList.xml -o
D:\Current\PDFsamOut\Merged.pdf concat

While I wasn't entirely clear on what all those lines did, the basic idea seemed to be that the first lines would define JAVA, JAVA_OPTS, and CONSOLE_JAR, and then the last line would combine them all into one big command. That command seemed to say, "Run Java with these options, using this jar file for specific instructions; take your input from the PDF files listed in ConcatList.xml; and output a single PDF file, Merged.pdf, containing all of those PDF files." To make that work, I needed to know the format of the ConcatList.xml file. Here's the one that worked for me in this test run:

<?xml version="1.0" encoding="UTF-8"?>
<filelist>
<file value="D:\Current\TestDir1\x1.pdf"/>
<file value="D:\Current\TestDir2\x2.pdf"/>
</filelist>

I just needed a File Value line for each PDF to be merged, using the syntax shown.  To summarize, then, I used Notepad to create two files.  One, called run-console.bat, contained the first half-dozen lines of code shown above, beginning with @echo off.  The other, ConcatList.xml, contained these last five lines of code, beginning with the "xml version" line.  ConcatList.xml would contain File Value lines, each designating a PDF to be merged into the larger output PDF (and there were other options for ConcatList.xml; I just didn't need them for my project), and run-concat.bat would read those lines and do the actual concatenation into a single output PDF.

Windows 7 Cannot Find Acrobat.exe

I was working in Windows 7.  I had installed Adobe Acrobat 9 Pro.  In Windows Explorer, I selected two PDFs, right-clicked, and chose the option to "Combine supported files in Acrobat."  I got an error message:

Windows cannot find 'Acrobat.exe'.  Make sure you typed the name correctly, and then try again.

I clicked OK to get rid of the dialog.  I noticed that I got this error only if Acrobat was not currently running.  If I had Acrobat open, I would not get the error; instead, I would get the expected Combine Supported Files dialog, and I would be able to go ahead and combine the PDFs.

Of course, I didn't want to have to open Acrobat in order to combine files, although doing so would give me the alternative option of combining the files from within Acrobat, instead of starting from Windows Explorer.  In Acrobat 9, the menu picks for that approach were File > Create PDF > Merge Files into a Single PDF.  And that approach did have the advantage, in at least some Acrobat installations, of not crashing Acrobat (or worse) when I would be trying to merge a large number of PDFs.

I wanted to recover ordinary functionality, so that I could right-click a selected group of PDFs in Windows Explorer and merge them using the "Combine supported files" option.  A search led to a thread that suggested adjusting Windows so that it would open PDFs in a slightly different way.  The instructions there were for Windows XP and Acrobat 6.0.  They suggested adding a certain command-line switch (a/k/a option, parameter, or flag) when Acrobat (or Adobe Reader) would open files.  A search led to an Adobe page that listed six switches:  /n (to start a new instance of Acrobat), /s (to suppress the splash screen), /o (to suppress the open-file dialog box), /h (to start Acrobat minimized), /p (to start Acrobat and open the Print dialog), and /t (to start Acrobat and print a specified file).  (One source seemed to indicate that there might be quite a few other switches as well, controlling such things as the document page that would open and the zoom factor.)

The suggestion that I had found was to add the /n switch to the command that opened Acrobat.  That suggestion seemed to have something in common with the discovery (above) that the Combine right-click option would work when Acrobat was already open.   The problem was that Windows 7 no longer made it possible for users to add switches as they could in Windows XP.  The Tools > Folder Options > File Types tab was no longer available in Windows Explorer.  It would have been possible to run Acrobat by adding the /n switch to the properties of a shortcut, but that didn't seem relevant for this Combine Supported Files project.  A better possibility was to use the Run with Arguments option in FileMenu Tools, but it would require a couple of steps every time, assuming I could get it to work.

I just wanted to restore, in Windows 7, the old ability to specify command-line switches for programs like Acrobat.  Some utilities seemed to offer that possibility.  A closer look at Types suggested that it wasn't right for the job, but it seemed that NirSoft's FileTypesMan might be.  FileTypesMan turned out to be a portable:  I just double-clicked on its .exe and it ran without any need for installation.  I did a Ctrl-F to search repeatedly for PDF file types.  I right-clicked on the line for the PDF extension and got a good number of choices.  A somewhat similar list of options dropped down when I clicked on the menu bar's Edit pick.  It looked like I would need to use the "Open file type in RegEdit" option.  That opened up the Windows 7 registry editor and took me directly to what looked like an appropriate place for Acrobat.

But now what?  I wasn't sure what to do there, so I ran a search.  It led to a few hints, but nothing clear.  I decided to search the registry, to see if I could find the location of the "Combine supported files in Acrobat" option.  A Ctrl-F for that phrase turned up nothing.  Nirsoft's ShellMenuView didn't indicate where that option came from either.

When I double-clicked on the .pdf file type in PC Magazine's old ContextEdit utility, it took me to an Adobe Acrobat Document entry.  On closer examination, I saw that this was actually the second of two such entries.  The first one seemed to indicate that the default program for such documents was Adobe Reader, not Acrobat.  Was that why Acrobat was acting funny -- had Reader screwed up my right-click context menu action?  I wasn't sure when Reader had joined the party.  I hadn't consciously intended to install it.  But now that I thought of it, I guessed that this was why the icons for my PDFs had changed slightly.

So, OK, in Windows Explorer, I right-clicked on a random PDF and went into Open With > Choose Default Program.  Reader was highlighted.  I highlighted Acrobat instead, made sure the checkbox at the bottom was checked ("Always use the selected program to open this kind of file"), and exited.  I selected two PDFs and tried the right-click Combine option.  No joy.  I wasn't sure whether a reboot would make a difference, but I rebooted just in case and tried again.  Still no go.  But, bizarrely, Reader was still highlighted in the Open With dialog.  I didn't need Adobe Reader, so I went into Control Panel > Programs and Features and uninstalled it.  I did the Open With thing again, and now Reader was gone.  I highlighted Acrobat once more in the Open With dialog -- and, yes, back in Windows Explorer, my PDF file icons returned to their old familiar Acrobat form.

I tried Combine Supported Files again, but I still got the error.  I started to go into Acrobat, with the intention of running its Help > Repair Acrobat Installation option.  But for some reason, the Windows Installer started up before Acrobat ran.  I guessed that the departure of Reader had left a gap, and now Acrobat was going to reconfigure itself to take up the slack.  After it was done, it called for another reboot.  I tried Combine Supported Files with two PDFs, but still got the error.  Apparently Reader wasn't the cause of the problem, or at least Reader's removal wasn't the cure.

Another change that I had noticed recently:  when Acrobat was updating, I commonly got errors referring to Error 1310, involving C:\Config.msi.  That had not happened previously.  I did not know whether this was related to Reader, or to the Combine Supported Files error.

Anyway, I went back into ContextEdit, to that second Adobe Acrobat Document entry.  I double-clicked on its Open option.  This opened a command line edit dialog.  The command line was the same as the one that people in that thread (above) had been revising.  Following their advice, I changed the command line so that it looked like this:

"C:\Program Files (x86)\Adobe\Acrobat 9.0\Acrobat\Acrobat.exe" /n "%1"

This just involved inserting that /n before the "%1" variable.  In the dialog's Menu Text box, I added "Open in New Acrobat Session," and then exited.  Sadly, no such option appeared in my right-click menu.  I rebooted, but that made no difference.  It seemed that ContextEdit must still be thinking in terms of the Windows 98 registry.  I went back in and removed that /n switch from its dialog box.

In case Acrobat hadn't fully repaired itself, I now went into its Help menu and ran a repair.  After another reboot, I tried Combine Supported Files again.  I still got the error.  I uninstalled Acrobat (via Control Panel > Programs and Features), rebooted, and reinstalled it.  (Note that Acrobat may have to be deactivated via Acrobat's Help menu before uninstallation, so as to avoid a hassle when activating after reinstallation.)  When it was reinstalled, there was no Combine Supported Files option.  I rebooted.  Still no such option.  It developed that I had made an error during the installation:  it was OK if the custom option to install the Create Adobe PDF was installed fully (white) or without some or all of its subfeatures (grey), but it could not be completely noninstalled (red X).  The red X would mean that the Combine option would not be available.  It occurrred to me that another possible way to fix the problem, short of completely uninstalling and reinstalling Acrobat, would have been to turn off that particular Create Adobe PDF option, reboot, and then turn it back on.

Uninstalling and reinstalling turned out to be the solution, at least with Reader out of the picture and with the other tinkering described above.  With the Create Adobe PDF option installed, the Combine option was there, without requiring a reboot.  And when I used it, it worked without an error.

Data Nightmare: Reconciling Two Hard Drives

I was using Windows 7.  I had an old hard drive with files on it.  I wanted to see whether its files also existed on a newer drive.  My concern was that some of the old files might not have made it in good condition to the new drive.  This post describes the somewhat haphazard steps I took in this project. 

This is an incomplete account.  Ultimately, I was able to proceed only partway, with steps like those described here.  These steps got rid of half of the old files; I was able to see, fairly quickly, that at least half of them were duplicative or superseded.  When I closed this post, I was still not sure how I would be able to decide what to make of the other half of those files, other than through a long, manual file comparison process.
One first step, I thought, might have been to keep a complete directory listing from the old drive.  There were some scenarios where that might have been useful, and it was easy to make.  There were freeware utilities that would do it.  I would have just used the DIR command.  The commands I would have used would have been something like this:

F:
cd \
DIR *.* /s > D:\F-LIST.TXT

where F was the old drive, "cd \" started me in the root of F, and DIR put the names of all files, including those in subdirectories, in a file called D:\F-LIST.TXT.

Anyway, I decided to reduce the size of the problem by eliminating files on F that seemed very likely to have made a successful transition to the new drive (drive E).  Ideally, I would have made a backup copy of F before doing this, just in case some of my steps erred.

To delete those files that had successfully transitioned from F to E, I used DoubleKiller, though there were other duplicate remover programs that would have done the job too.  The criteria I used at this point were to check both the file sizes and the CRC32 checksums.  (Not all duplicate remover programs had these options, but some others did have something similar.)  The concept here was that a file's size could be the same and yet its contents could have changed, so it would pass a size-only test; and it was conceivable that two very different files could have the same CRC32 checksums; but it was virtually certain that if both the size and the CRC32 checksum were identical, they were in fact identical files, in which case one could safely be deleted.  I searched drive E for duplicates within itself, and resolved all of those.  Then I did likewise on F.  With that done, I could now check on both E and F.  DoubleKiller would display the duplicates in pairs, with E coming first and F coming second, so I could then do a bulk check-and-delete process (after some additional eyeballing) to remove the duplicates from F that had almost certainly made it to E successfully.

While doing all that, I noticed that a lot of files had changed format.  They had been .doc or .txt files, but I had converted them to .pdf.  This process would result in a file that had a different size, checksum, and filename.  But experience with the newer files, supplemented now by some random checking of these .pdfs, convinced me that most if not all with the new (*.pdf) filenames did reflect the same content.  So I could also delete the old .doc and .txt (and other extension) files on the old F drive whose content appeared to have made the transition to .pdf on the new E drive.  Space and time permitting, I could have played with that question some more and probably improved the accuracy of this comparison.

I could delete the old files (with .txt, .doc, etc. extensions) in favor of the new PDFs, that is, if I could figure out which ones had been so converted.  Consider these two filenames:

Letter to John Doe Containing Information.doc
Letter to John Doe Containing Information.pdf

If they were in the same folder, I could just sort them by file type in Windows Explorer, select the ones of the old type (.doc, in this example), then sort by name, and eyeball to make sure I had alternating selected and unselected files.  The problem in my case was that some of these, after being converted to .pdf, had also been moved to other folders.

To address that, I knew of two solutions.  One was the easy solution.  This apparently involved using Beyond Compare, or something like it, in its Professional version, and figuring out how to ignore filetypes so that I would have a straight-across comparison on two columns.  I had the Standard version, so I didn't have that option and, at this point, didn't even know that option existed.  What I was seeing in my Standard version of Beyond Compare was a more alternating layout that, when other files were added to the mix, could be hard to decipher, especially when dealing with large numbers of files that I did not care to scrutinize one-by-one.

As I say, that was the easy solution, so of course the solution I took was, instead, to produce a list of files on drive F, using the DIR command (above), and compare it against a list of files on drive E.  Since there were more than 65,000 files altogether, I could not simply copy these resulting E-LIST.TXT and F-LIST.TXT files into Microsoft Excel; its maximum was about 65,000 rows.  I discovered that OpenOffice.org (OOo) Calc had a similar limit, but a variant version of OOo Calc had a maximum of one million rows.  This version, called Go-OO, was delighted to accept my long E-LIST.TXT and F-LIST.TXT file listings, and it went right to work on them, crashing every couple of minutes.  After spending hours paring down the files to a somewhat smaller size, and converting formulas to simple text and numeric data (using Edit-Copy, Edit-Paste Special) as soon as I didn't need the formulas anymore, I was able to reduce the crashing.  By using text analysis functions (especially FIND and MID) within Go-OO, I was able to extract the filenames without extensions.  Now the problem was just getting Go-OO to copy and paste the lookup formula that I was using to search for the F filenames without extensions against the derived list of E filenames without extensions.  Go-OO was unwilling to copy and paste those formulas en masse; the very idea would cause it to freeze in fear.  Since I did not want to paste the formula manually down tens of thousands of rows, a few at a time, I wound up using AutoHotKey to automate the copying of those formulas.  AutoHotKey was useful if somewhat childlike.  I found, for instance, that if I absentmindedly switched the focus on that computer away from the copying process underway in Go-OO, AutoHotKey would blithely continue copying and pasting things into whatever random windows happened to be opened.  Fortunately, there were no delete commands in my AutoHotKey script, else it would have been an unpleasant morning.  Sometimes AutoHotKey would also decide to just start working away in some other part of the spreadsheet.  Should anyone care, the AutoHotKey macro that I prepared for this project went like this:

!x::

; Copies a cell in OOo Calc to the next one down
Send ^c{down}{Enter}{down}{up}

At this point, I wrote up these additional notes, which did not actually turn out to describe what happened next, but which may be useful for someone else who shares my indulgence in fantasy.  First, I said, "When the lookups were done and I was finally working with fewer than 65,000 files, I saved in an Excel-compatible format and resumed work there."  I also wrote, "Eventually, I noticed that some files that had previously been .jpgs were probably combined into .pdfs as well.  Since .jpg format did not accommodate multipage documents, what we had there was a bunch of files named file01.jpg, file02.jpg, file03.jpg, and so forth, and the resulting file.pdf.  So here I had to modify the spreadsheet formula somewhat to seek out those filenames ending in two or three digits, and search for equivalents along those lines."

Those additional notes did not turn into anything real because what happened instead was that Go-OO -- whether of its own volition, or as persuaded by AutoHotKey, I cannot say -- decided not to reopen the file anymore, nor any of its last several versions comprising hours of work on the spreadsheet.  After trying various angles on two different machines, I gave up and waited for news from the Beyond Compare people on what it would cost to upgrade from Standard to Pro version, so maybe they would provide a workable solution to this project.  It turned out that a previous version of Beyond Compare had a way of comparing that might be useful, so I looked into that but, unfortunately, I would have needed some of the features of the latest version to make it work.  Another Beyond Compare approach involved their Alignment Overrides option.  They had a way to experiment with this feature, which was in the Pro version.  This did not really help me much.

I wound up using Beyond Compare 3, using folder-by-folder comparisons and also comparisons regardless of folder.  I simply deleted, from the old drive, the files that were matched on the new one.  This left a bunch of empty folders.  I had always gotten rid of those using a batch file in a sequence of several steps, but I had never memorized exactly what those steps were, and what I was finding now wasn't working right.  I heard that Glary Utilities had a tool for this purpose, so I installed that freeware and went into its Modules tab > Files & Folders > Empty Folders Finder.  It found a boatload of them. Once that was out of the way, I ran the DOS command "DIR *.* /s > D:\DIRLIST.TXT."  This created DIRLIST.TXT, a list of the files left on the drive.  I imported that list into Excel -- it was now short enough to fit within the 65,000-record limit -- and sliced and diced it.  I started by using commands like MID and FIND to extract the file extensions.  Example:  =MID(F1,1,LEN(F1)-LEN(K1)), with F1 containing the imported filename and K1 containing the extension (e.g., .html), would give me the filename without extension.  (To get the extension, I did several columns of =FIND(".",F1,G1+1), where G1 contained the rightmost dot yet discovered in the filename, sorting and identifying and then excluding from further sorts.  Then I used ="DIR /S "&CHAR(34)&I2&"*.*"&CHAR(34)&" >> D:\FOUND_IT.TXT" to create a cell containing a DOS command that would look like this:  DIR /S "Letter to Joe*.*" >> D:\FOUND_IT.TXT.  This command would search for that filename and export its results to FOUND_IT.TXT.  Excel generated similar commands for each of the files I was looking for.  I copied and pasted the lot of them into a text file called Finder.bat.  At the start of Finder.bat, I added two lines:

D:
CD \

to make sure that the search would occur on the proper drive and would begin from its root.  I ran this overnight, and awoke to find that FOUND_IT.TXT had vanished.  No idea why.  So I ran it again, and this time simulataneously ran another batch file:

:: WAITER.BAT
:: Copies FOUND_IT.TXT to another folder
@echo off

:REPEET
copy FOUND_IT.TXT D:\Current
TIMEOUT /T 30 /NOBREAK
goto REPEET

Ultimately, this gave me a complete FOUND_IT.TXT, with lots of hits and misses.  I opened it in Word.  It was a 9,193-page document.  I did a bunch of search and replaces to get rid of useless lines, using search and replace terms like ^p (for line breaks) and ^t (for tabs).  At this point, I did not continue with the process of examining drive contents and logging my steps, deciding instead to defer this process until the next point when I would want to devote some time to this enterprise.

A Two-Computers-Per-User Desktop Arrangement

I was spending a lot of time at my desk, doing word processing and other typical desktop work.  For this purpose I was using a customized Windows 7 installation on two networked computers for maximum productivity.  This post describes that setup.

I had previously thought that, ideally, I would have four computers:  one laptop; one test machine to hook up the occasional hard drive or other component for wiping, testing, etc.; and two desktop machines running side-by-side.  Since then, however, I had switched from Ubuntu back to Windows and had found this to be a good move.  So now I was doing very little testing and tinkering with hardware.  Therefore, I dismantled and sold the parts from the fourth computer.

With almost all of my work happening on just two computers, and with a stable Win7 installation on each, the focus now was on getting the most out of them.  I was using two desktop computers instead of one because there were still many occasions when a computer would experience downtime.  I would be doing drive maintenance or imaging, or would still have to reboot Windows now and then to clear its head or to complete a program installation or upgrade, or Win7 would be running just fine but there would be some scanning or something else going on that would tend to monopolize the machine for practical purposes.  I was not yet very impressed with multiple desktop software and was considering a return to VMware or some other virtual machine software, perhaps in a virtual appliance, though I wasn't sure I wanted to get back into the performance issues that had prompted me to try to use a native and/or bootable virtual hard disk or RAID array to improve the really bad performance I had started getting in VMware.  So the second computer was also useful as a simple way of having a pretty solid alternate desktop.  I could start up a project or leave a set of folders open there and just visit it occasionally, when the primary computer was doing its own maintenance or was otherwise unavailable for a while.

The starting point for this two-computer arrangement was to set up two machines that were almost identical in terms of hardware and software.  In previous years, I had thought it was best to have dissimilar machines, so as to maximize resources.  One machine or the other would have the right hardware or software to deal with almost any kind of system problem.  That belief was probably justified for some purposes.  Now, however, I was less patient with that, and it also seemed less necessary.  A lot of the old problems had gone away.  Meanwhile, it was much easier to learn how to maintain and troubleshoot just one set of problems, rather than have to learn the whys and wherefores of divergent sets of hardware and software.  For purposes of getting my work done, Windows 7 was a significant improvement over operating systems I had used previously, including Windows XP and Ubuntu 10.10, in terms of networking and other capabilities.

The customized Win7 installation (see link above) was not as easy as a canned, plain-vanilla installation, but once I had it set up, it had some advantages.  One important step was to make my work files available on both computers.  My first attempt in this regard was to use a Synology network-attached storage (NAS) unit as a simplified file server, but that hadn't worked so well for me.  In the second attempt, I used my home network (basically, just a router and cables to the two computers, though possibly a crossover cable would have sufficed even without the router).  After some contemplation, I went with GoodSync to keep the two computers directly synchronized with one another.  This was an important development.  When combined with appropriate program settings (e.g., setting Microsoft Word to AutoRecover files every minute), it meant that, if the computer I was working on suddenly crashed or otherwise became unavailable, I could usually switch over to the other machine and pick up right where I left off.

I used GoodSync to synchronize my data partition (drive D), not the program partition (drive C).  I also used it to synchronize parts of the INSTALL partition, including particularly the funky but advantageous shared Start menu.  GoodSync did not need to be running on both computers, so I installed it on computer A.  As the installation evolved, I found that computer A was handling most of my computer maintenance and other functions, while I did more of my moment-by-moment productivity stuff on computer B.  In particular, computer A was becoming my backup hub.  I would save a file on computer B; GoodSync would copy it to computer A; and then my backup software would copy it to other drives.  After a variety of unpleasant backup surprises, I had evolved to two distinct backup systems running on computer A.  In the first backup system, I was using Robocopy, as part of my customized installation (above), to make frequent, incremental backups to a separate partition on computer A.  This was one of the few regards in which computer A differed from computer B in terms of hardware:  it had three hard drives rather than two, so as to speed this internal copying (since it was faster to copy from one hard drive to another, rather than between partitions on the same drive) and make it safer (since a failure of one drive would usually not affect the other).  In the second backup system, I was using Beyond Compare to do daily manual backups to an external drive that I could carry or store offsite as needed.  These were manual in the sense that I had to click things to make them happen, and could therefore examine or at least spot-check what was going to be changed, if I wanted to.

Again, I could still use either computer to do my work, since they both had the same synchronized files and nearly identical software installations.  Nonetheless, as the functions of the two computers diverged, I found that I was not really utilizing both monitors most of the time.  On computer B, I tended to be opening PDFs, Word docs, Excel spreadsheets, Windows Explorer sessions, and webpages, among which I would copy text, links, and other materials.  I could open some of that stuff on computer A instead, but it was cumbersome to have this happening on two different computers, and for the most part it actually was not happening on computer A.  That computer, and its associated monitor, were mostly just sitting there, working up a file comparison in Beyond Compare or otherwise doing things that did not really need to be watched constantly.

What I really wanted was to make monitor A available for computer A, when I wanted to see what was happening on computer A, but to have monitor A also available for computer B, when I was doing my ongoing work on computer B.  This called for a keyboard-video-mouse (KVM) switch.  The PS/2 type of KVM was better for purposes of providing keyboard and mouse input during BIOS setup and in programs that would boot from a CD (e.g., Acronis Drive Image) and would therefore be at least partly unresponsive to a USB mouse and/or keyboard.  Unfortunately, I did not realize that the type of motherboard I had installed in both computers did not have two PS/2 ports, so I had to use a USB KVM.  It also seemed that I might have to spring for a more expensive DVI-compatible KVM, since I'd gotten some poor video performance when I had connected the monitor to the computer using the older D-Sub rather than the newer DVI kind of cable.  In recent months I had been using the KVM only for the keyboard, while leaving each monitor dedicated to one computer and experimenting with having a separate mouse for each computer, so that I could click without having to transfer keyboard (and, optionally, monitor) focus between computers.  It had lately occurred to me, though, that the D-Sub video quality problems might just be due to the quality of the video circuits on the motherboard.  So at this point I was planning to get a dedicated video card for each computer and see whether its D-Sub connection would work acceptably, in which case I could use the USB/D-Sub KVM for the keyboard and for D-Sub video with monitor A.  In other words, monitor B would continue to be dedicated to computer B, but monitor A would run to the KVM and could thus toggle between computers A and B.

This left the problem that, as I had discovered, when I was not seeing events on computer A, I tended not to use that computer.  That was not terrible -- it would still be there as a running backup, ready to jump into service when I needed it, unless it hibernated itself in the meantime -- but experience suggested that, if I could not just glance to see what was happening on computer A, I would tend not to toggle over there on the KVM and take a peek.  I thought of two solutions to this.  One was to set up a reminder that would prompt me, every hour or two, to interrupt what I was doing on computer B, toggle the KVM, and look at events on computer A as displayed on monitor A.  I suspected I might tend to disregard that kind of reminder, but I decided to give it a try.  An alternative was to get a small, dedicated monitor that would just always be displaying events on computer A, though I realized its tiny resolution would not very well display all the stuff that would tend to appear on my widescreen monitor A.  It looked like I could get a monochrome 10-inch Miracle Business MT209A CRT on eBay for $25 including shipping, but I didn't want the clutter or the extra power consumption.  What seemed like a more practical option was rather to go with a full-sized monitor dedicated to computer A.

That's where this matter rested for the time being.

Windows 7: KVM in a Multimonitor Setup

I was using two monitors with two computers.  After reflecting on multiple monitor possibilities, I installed an ASUS EN210 video card in each computer.  This allowed me to connect dual displays.  I decided that monitor A would be available to both computers, and monitor B would be available only to computer B.  To make this happen, I connected monitor A to a keyboard-video-mouse (KVM) switch.  So computer A was visible only on monitor A, whereas computer B was visible across the two monitors (assuming that's where I had the KVM set).

Problem:  every time I switched back to computer B on the KVM, monitor A would go blank.  This was not a problem when I was using the KVM only to switch the mouse and keyboard, leaving each monitor dedicated to one computer.  It arose only in the dual-monitor setup.  It seemed that the computer was not remembering the dual-monitor settings for monitor A on computer B.  Each time, I had to go back into Control Panel > Display > Change Display Settings > Detect.  (This KVM problem also seemed responsible for screwing up Adobe Acrobat 9. It was no longer remembering my toolbar settings the way I had previously set them. This seemed to be fixed by going into Acrobat's Help > Repair Acrobat installation.)

A search led to the suggestion that the problem I was having with monitor A was with the KVM:

It is a problem found with those KVM switches which did not pass the console display's EDID and DDC information to all the systems connected to the KVM switch. ...
Windows 7 checks display and display card constantly different from what XP and other operating systems did.
To solve this issue, just replace the KVM switch with those KVM switches supporting FULL TIME Active DDC function.
Please check ConnectPRO new UR or PR serial KVM switches which support Active DDC function to all the ports.

That post pointed me toward a Microsoft webpage with more technical information.  I did another search and saw references to ConnectPRO there too.  A different search suggested that lots of users were running into this problem.  Newegg's Power Search didn't offer an operating system selection, and they didn't seem to carry ConnectPRO KVMs.  A Google Shopping search led to two ConnectPRO KVMs, each costing at least $130.  I ran across a workaround suggestion to hit Win-D before and after switching with the KVM, but apparently that worked only with XBOXes, or anyway it didn't work for me.  There was another workaround, too technical for my blood.  Another thread prompted me to check for the most current driver for my ASUS EN210 graphics card.  As I recalled, the usual advice was to look for the latest drivers on the chipset manufacturer's webpage, so after consulting the details on the EN210, I went to the NVIDIA website and searched for GeForce 210 drivers.  I went with the most recent WHQL-certified driver.  After reboot, I saw that this did not solve the problem.  Note:  the machine had all current Windows updates at this point.

It seemed I had a choice.  I could go back to using one monitor per computer, or I could look for a hardware multimonitor solution.  Going back would mean waiting for Microsoft to fix this problem with Win7.  There was no guarantee that that would ever happen.  Basically, if I wanted multimonitor support for KVM-type functionality for two computers running Win7 (as distinct from one Win7 and one WinXP), it seemed I would either have to buy an expensive KVM or maybe come up with some other kind of funky plugging and switching.  For instance, I wondered whether I could make a go of it with two keyboards, two mice, and a switch just to flip monitor A from one computer to the other.  But this wouldn't circumvent the problem that Windows 7 was constantly polling the monitor, and that was the only thing that counted.  I found a device called the Geffen DVI Detective, which for $80 would remember the EDID and therefore defeat the problem (but only for monitors using DVI connectors).

Then I saw that Amazon carried a bunch of ConnectPRO KVMs, and some were far less expensive.  They did not carry the PR-12, which was the one PS/2 (as distinct from USB) KVM that ConnectPRO offered for my humble purposes:  two computers, one keyboard, one monitor, one mouse.  USB did not work reliably for both keyboard and mouse when Win7 was not running -- when, for instance, I was booting from a CD, or was adjusting the BIOS settings before the operating system booted.  But then I remembered that my new motherboards had only one PS/2 port, and the PR-12 would definitely require two (one each for keyboard and mouse).  I did have the option of using USB mice, one dedicated to each computer, and in fact had been doing that for a while, partly for the reason of pre-boot capability just mentioned and partly to reduce the strain on either wrist.  Another option was to use an adapter or some other gizmo to give me a second PS/2 port.

From ConnectPRO's product comparison page, it seemed there were several options to consider.  One was the choice between VGA and DVI.  DVI provided superior video, but VGA (using D-Sub connectors) was functioning well for me at the moment.  (DVI achieved using DVI-VGA adapters had, in my impression, the same risk of video problems as plain old VGA.)  It seemed that a couple of inexpensive video cards had eliminated problems of ghosting that I was getting when I had the monitors connected directly to the motherboards.  There was also the choice of two- or four-computer KVMs.  I needed only two.  Switching via hotkey was preferable to having to reach up and punch a button on the KVM in order to switch between computers.  All of the relevant ConnectPRO KVMs had All-time Full DDC, which was evidently the core need behind this KVM search.  ConnectPRO's Pro line of KVMs apparently did not have the Dynamic Device Mapping (DDM) technology that would remember attached USB peripherals (e.g., speakers, mice) and would thus eliminate lag time required for the switched computer to re-detect the devices.  It was confusing, shopping among these devices on Amazon, because there were various "kit" options that were described as "new" and yet did not appear on ConnectPRO's website, and also because now it started to look like some of these products did not have Full DDC and/or DDM.  What I came up with was a choice, for me, between the UR-12 PRO, with VGA and DDC but not DDM and no hotkey option ($102 with shipping from ConnectPRO through Amazon); the UR-12 PLUS, with VGA, DDC, DDM, and a hotkey option ($176); and the UD-12 PLUS, which was the same as the UR-12 PLUS but with DVI (and therefore with VGA as an option, via adapter) ($191 from a couple of sellers).

Since I was having no video issues at the moment, and might not have any again for some time, I decided to go with VGA rather than DVI, all other things being equal.  If I did get video problems, I could sell one KVM and upgrade to another later.  So then it was a question of whether I was willing to pay an extra $74 for DDM and a hotkey option.  DDM was nice -- I had noticed the lag in responsiveness at some point, hard to recall at the moment but apparently when I had upgraded from Windows XP to Windows 7 -- but that was not really bothering me much at present.  Those delays, and the hotkey, were especially important when I was doing a lot of switching between computers, which happened primarily when I was testing or tinkering with hardware or software on one machine and logging the developments on the other.  I was not presently doing much of that, and didn't plan to be doing much of it anytime soon.  It occurred to me that, if the DDM lags did bother me at such times, I could always dedicate one mouse, one monitor, and one keyboard to each computer at those times.  I could arrange that on my desk, and then the only lag would be the time needed to reorient my hands on the other keyboard.  Indeed, for purposes of working with the BIOS and such, I could simply keep a PS/2 keyboard always plugged in and standing off to the side of each computer, in addition to the USB keyboard connected to the KVM.  (PS/2 was not hot-swappable; it would be necessary to reboot to have the keyboard be recognized if it were not plugged in at time of bootup.)  Looking at the choice again, I reconsidered that the price difference between the UR-12 PLUS and the UD-12-PLUS was only $15.  From that perspective, I would choose the latter over the former, so as to wrap up the best product at not much additional cost; and in that case, the price difference between the solution with or without DDM, hotkey, and DVI was substantial:  the UD was almost twice the price of the UR.

As long as I was sure I did want to use dual monitors on computer B, sometimes swapping monitor A between computers A and B, I would need Full DDC, and it seemed the choice was then to spend $102 on a ConnectPRO UR-12 PRO KVM.  If I hadn't gotten the video cards for only $18 each, the decision to add dual monitor capability (with KVM and video cards) would then have cost me more than $150.  It was worth it -- dual monitor capability added a lot to a workspace -- but it was turning into more hassle and expense than it should have been.  I belatedly realized that perhaps I should have looked for a motherboard with dual monitor capability and with enough video memory so that the computer would not struggle to switch between windows on the same monitor, as computer A had been doing before I added the video card.  Desk space permitting, that kind of expense also raised the question of perhaps having three dedicated monitors -- one for computer A and two for computer B, and recabling one of the latter to computer A if a multimonitor need arose there -- thereby reducing the KVM need to a simple $20-30 device that would swap keyboards and mice, assuming those were not likewise dedicated to single machines.  The temptation to just get a third monitor and forget about the Full DDC KVM would be even stronger if I were looking at the nearly $200 price tag for a ConnectPRO UD-12 PLUS KVM.  But even without that, as I considered the time I had devoted to screwing around with KVMs, on this and on previous occasions, I did think that possibly the best approach would be to go with the third monitor, wait for someone to compete with ConnectPRO and/or for Microsoft to get its act together -- to buy a third monitor as an interim solution, in other words, and to sell it when and if a superior KVM alternative emerged.