Windows Explorer Has Stopped Working: FreeCommander and Other Alternatives to Windows Explorer

I was using Windows 7. I installed a new EVGA video card. Immediately, I began getting "Windows Explorer has stopped working" error messages, especially when I would right-click on a file or folder and try to move it somewhere else. A search led to a Microsoft webpage that identified the video driver as the first culprit. I had also had problems with the previous video card (also an EVGA), but had partially resolved those by rolling back to an earlier driver. That solution did not work this time. While awaiting EVGA's reply to a service request, I decided to look into Windows Explorer replacements.

This was not the first time I'd had problems with Windows Explorer. As far back as the late 1990s, I had found PowerDesk 98 to be a superior alternative to Windows Explorer in Windows 95 and 98. I had grown so attached to it that I was still occasionally looking, years later, to see whether they had come out with an update. It just offered a lot of features and advantages that I hadn't found in Windows Explorer.

To me and to at least some other users, Windows Explorer in Windows 7 had seemed like a step backwards from Windows Explorer under Windows XP. Some functionality was lost; some new problems appeared. For example, not long before this latest "stopped working" issue, I started getting the unwanted reminder that "This folder is shared with other people," which would come up when I tried to move or delete a folder. Despite some effort, I hadn't been able to get rid of that.

FreeCommander

In the past year or so, after repeated albeit superficial looks at various Windows Explorer alternatives, I had started using FreeCommander for some tasks. One thing pushing me in that direction was that, in Win7, Windows Explorer seemed eager to forget file selections. That is, I could go through a list of files and select some; but then Windows Explorer would de-select them if I (or anything else) changed the file list. In FreeCommander, unlike Windows Explorer, I could select files, and they would tend to stay selected -- even if I deleted one entry from the list (from within another program, for example, or another Windows Explorer session) or if I re-sorted the list by file size rather than file name. FreeCommander wasn't perfect about this. At this writing, a quick test revealed that it, too, would lose selections if I sorted by file type. Nonetheless, FreeCommander was much better than the current version of Windows Explorer in this regard, in my ordinary usage. FreeCommander was also not crashing, at present, during these instances when I was getting these "Windows Explorer has stopped working" messages.

FreeCommander also did a better job of putting me where I wanted to be. It would remember my last location, and would never put me in a pseudo-folder under Ray (my user name in the navigation pane), as Windows Explorer insisted on doing, when I actually wanted to be in Computer > Drive D > Folder X. I also liked that FreeCommander did not lard down my navigation pane with all sorts of Libraries and other top-level folders (which, to some degree, I had been able to eliminate from Windows Explorer by using registry tweaks).

On the downside, unlike Windows Explorer, FreeCommander did not preserve a memory of multiple sessions after a reboot. That is, if I had three Windows Explorer sessions and three FreeCommander sessions open before a crash, all focused on different folders, I would wind up with those same three Windows Explorer sessions after the crash, but only one FreeCommander session (or pair of sessions, if I was using FreeCommander's split-window feature). (I think I had to enable an option somewhere in Windows, or in a tweaking program, to get this functionality from Windows Explorer.) Then again, FreeCommander's option to open or close tabs (via View > New Folder Tab or else Ctrl-T and Ctrl-W) had the potential to make it unnecessary to have so many Windows Explorer sessions open at once.

At first, I did not realize that I could turn FreeCommander's split-window feature off. There were times when it was convenient to be able to view two separate lists of files -- from, say, two different drives -- within one FreeCommander session (and to split the screen either horizontally or vertically). The options to split the window or to view just the left or right sides were available through the menu (View > Split Window) or by shortcuts (Ctrl-Shift F1, F2, and F3). If I had multiple tabs open on one side, it would remember them, even if it was currently displaying only the other side.

I didn't like that FreeCommander wouldn't show me a full navigation tree (in the left-hand pane) for all drives: instead, it was focused on just one drive. To switch drives, I had to go to the top of the screen and select another drive from a list or combo box (configurable via Extras > Settings > View > Drives). That seemed inconvenient, and that top bar took up screen space. One workaround might be to have a different tab open for each drive, and just navigate within that tab whenever I wanted to work in a different drive.

I had some batch files that would open various Windows Explorer sessions automatically, on certain dates or at certain times of day. There was a simple command format to specify which folder a Windows Explorer session should display: start explorer.exe /e,"D:\Folder Name\File Name.doc." I wondered if I could do something similar with FreeCommander. It would let me specify a pair of starting folders (via Extras > Settings > Start Program), but could I go further than that? It appeared that, to match what I was doing with Windows Explorer in this regard, I would have to set up a relatively complicated arrangement with alternative .ini files in FreeCommander. (I wasn't entirely sure whether this was what the program's author meant when he said that "several layouts can be saved.") I probably wouldn't go to that trouble for the most part, though I could imagine setting up a couple of really complicated sets of tabs and linking to them with shortcuts on my semi-portable customized Start Menu.

One feature of FreeCommander that I liked immediately was its more condensed display. Windows Explorer had seemed to add more space between lines, going from Windows XP to Windows 7. I wasn't sure why. The result was that Windows Explorer would display 38 items at a time (or a few more, if the top menu and bottom status bar were turned off) while FreeCommander would display 45 -- and those 45 would be presented in a larger, more readable font. FreeCommander's status bar was also more informative, telling me that I had selected 45 out of 110 items within a folder, and such information would remain visible in the status bar, whereas for some reason Windows Explorer would sometimes replace it with the date when a folder was created.

One thing I didn't like about the FreeCommander interface was that it didn't have an address bar into which I could paste an address for a quick switch to a different directory. In FreeCommander, I had to use the Edit menu to get a folder's address for pasting elsewhere, and the Folder > Go to Folder menu pick to paste an address from elsewhere into FreeCommander. These steps were inconvenient because (a) they required more steps and (b) they were in two different locations, which made things a little more confusing. On the other hand, FreeCommander offered the option (via Alt-Ins or Edit > Copy Full Name as Text) of copying both the path and the file name in one step, which Windows Explorer did not do.

I felt that FreeCommander needed some reorganization and clarification. There was apparently a new XE version in the works; it appeared that the present version dated from 2009. On the other hand, I wasn't sure how much I could complain about the program's offerings. Quite aside from the fact that it was free, FreeCommander had all kinds of features not available in Windows Explorer, and there didn't seem to be much that WinEx could do that FreeCommander couldn't. I figured that, with or without reorganization, I would become familiar with FreeCommander's menus and possibilities if I began using it more extensively.

One particular area that I did not explore, within FreeCommander, was its offering of various built-in utilities. These included file viewing (e.g., hex, image, binary formats), zipping, searching, wiping, checksums, listing, renaming, and splitting; multiple file renaming; directory comparison and synchronization; and the option to add more tools to the list. I didn't look into this because I was not sure how much I would use these tools. As indicated in other posts in this blog, a lot of problems and questions could arise when you really got into the details of these sorts of functions. For example, I had paid some attention, in recent years, to GoodSync and alternatives for synchronization between computers, and to Beyond Compare and rsync for comparing a computer's files against backups. I was hesitant to replace those sorts of dedicated tools with what might be a simplistic form of file comparison that could make a mess.

In terms of other conveniences, there was quite a list of hotkeys. FreeCommander was available in both installed and portable versions. There were user forums with a total of maybe 10,000 posts. It was definitely a stable and worthy program. Given my previous searches and my experiences to date with FreeCommander, the question for me at this point was whether there was some other Windows Explorer alternative that was even better.

Other Windows Explorer Alternatives

Along with various ways to customize Windows Explorer (which did not presently appeal to me, given the fact that it was crashing every time I looked at it sideways), there were various lists of Windows Explorer alternatives. For example, a PCTIPS 3000 webpage briefly listed FreeCommander as one of the best (free) Windows Explorer replacements, along with Q-Dir, Explorer XP, NexusFile, and CubicExplorer.

A potentially manipulable poll suggested that users of one forum were using Total Commander, Directory Opus, XYplorer, Explorer++, Q-Dir, and FreeCommander, in approximately that (descending) order. A SuperUser thread ranked the leading Windows Explorer alternatives as being (in this order) Total Commander, QTTabBar, FreeCommander, FarManager, XYplorer, Directory Opus, the command line, xyplorer2 (?), Q-Dir, TeraCopy (!), CubicExplorer, SpeedCommander, Altap Salamander, Xplorer2, muCommander, and others recommended by at least one person. Another webpage listed at least 30 free and paid alternatives to Windows Explorer. TechRepublic listed these as its preferred free Windows Explorer replacements: CubicExplorer, Explorer++, Xplorer2, NexusFile, and Q-Dir.

Wikipedia provided a comparison of many such programs. It appeared that they could first be divided into free and nonfree categories. Since I was not likely to pay for something that FreeCommander (not to mention Windows Explorer) could already do for free, I focused on the free ones. This removed Total Commander ($40) from consideration -- a perennial favorite that I had tried briefly but hadn't found that terribly impressive. The nonfree group also included some other popular entries from the lists cited above: Directory Opus ($85!), XYplorer ($43), SpeedCommander (~$55), Xplorer2 ($30), and Salamander ($30) -- assuming the lite versions available for some of these programs would fail to match a competitive freeware alternative like FreeCommander. It was not clear how recently the Wikipedia page had been updated -- it didn't include any reference to some of the programs listed above, and therefore might not reflect pricing changes (including decisions to offer a given program for free, or to stop doing so). Then again, I guessed that any developer who was on top of the game would know of this Wikipedia page and would be updating the pricing information pretty quickly.

ExplorerXP did not appear to have been updated for Windows 7. I had encountered other programs, great in Windows XP, that had stumbled at one point or another in Win7. Given the number of competing programs, I tentatively ruled out those that were not clearly Windows 7 compatible. I was also inclined to exclude those whose screenshots provided a clunky interface and/or limited information -- notably, Far Manager.

The leading free Windows Explorer alternatives, other than FreeCommander, thus appeared to include Q-Dir, NexusFile, CubicExplorer, Explorer++, QTTabBar, and muCommander. The Wikipedia comparison page provided a table indicating the kinds of views that each such program offered. I considered a Details view option essential. Evidently no such view was available in CubicExplorer. I was not sure if a twin-panel or tab options were essential, but CubicExplorer seemed to lack those features too. As noted above, I was not especially interested in the utilities (e.g., file compression) that such programs might offer, so I did not examine the Wikipedia tables on those matters.

I looked at the webpages for the ones that remained on my list: Q-Dir, NexusFile, Explorer++, QTTabBar, and muCommander. I had previously glanced at QTTabBar but, for reasons I did not recall, had not gone far with it. On this review, I was not too impressed. Its forums seemed to be lonely places; there was an indication that it was still in "public beta"; and there were remarks of instability and Windows 7 incompatibility.

Q-Dir's screenshots seemed to offer the potential to divide up the screen in a number of interesting ways. They did not seem to display a tabbed browsing option, but I gathered that tabbing was an option somehow. There did not appear to be a forum, but the author did provide an array of FAQs, with perhaps some English-language limitations. My principal reaction at this point was that, having glanced ahead at Explorer++, I thought it might be a little more of what I was looking for.

NexusFile had a snazzy webpage, especially for people who like black, but I wasn't so sure about its content. Forum posts didn't seem to be categorized, and there didn't seem to be a way of searching them. Generally, as with most of the other programs noted here, the information provided on the webpages did not seem responsive to the detailed concerns noted in my review of FreeCommander (above). That might have been alleviated in some cases if I had plunged into their FAQs in detail. It would not have been alleviated in the case of NexusFile, whose FAQs page had a total of six questions.

Between muCommander and Explorer++, a comparison of forum posts suggested that muCommander was more of a cross-platform option, with many of its posts coming from Linux users. There also seemed to be somewhat more recent activity in the Explorer++ forums. MuCommander, not listed on the Wikipedia comparison page (above) at this point, apparently did not yet have tab support. Between the two, then, I was inclined toward Explorer++.

The thing is, I wasn't seeing anything in any of these alternatives that FreeCommander lacked. At present, the best course of action seemed to be to focus on FreeCommander, to the extent that it performed more stably and functionally than Windows Explorer. I decided that I would return to these alternatives if, at some point, neither Windows Explorer nor FreeCommander seemed to be working well for me.

Suggestion

It seemed, in particular, that while these various programs were trying to compete to be the best Swiss Army knife, doing everything fairly well, there might actually be some merit in taking more of a niche approach. For example, I tended to use a few folders very frequently. I had not really worked out the whole thing of using Favorites, links, Send To, Move To, Copy To, and other ways of moving and sorting my attention, or my files, among these key folders. It would have been very helpful if, for instance, I could have just punched a function key or other hotkey to move a file to any of a number of previously designated folders. I often found myself sorting files; this would have been very useful.

In that particular example -- and that was obviously not the only specialized way in which people might use Windows Explorer -- there seemed to be a lot of room for people to develop tools that would help me navigate across my computer adequately, while providing a really special experience among key locations. In that case, I could easily imagine running this other program along with (not "instead of") Windows Explorer or FreeCommander.

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!

A Backup Arrangement with Beyond Compare

I had been using Beyond Compare (BC) for a year or two.  Over that period, I had settled into what seemed like a decent backup arrangement.  This post describes that arrangement.

For a while, I had a spare internal partition to which I would make backups.  The original concept there was that I would use rsync or some other program to make backups on an hourly basis.  That setup had fallen into disrepair, mostly because I didn't quite like how it was working.  So I didn't have an hourly backup at this point.  The arrangement described here is more on the longer-term (e.g., daily, weekly, monthly) level.

My backup took place on external drives.  I had an external enclosure that I would have to open up (removing several screws) to swap drives, and I also had an inexpensive dock that I could just plug an internal SATA drive into.  Both seemed to work equally well.  The enclosure was handy for unplugging the drive and taking it with me.  Now and then -- especially when the tornado alarms sounded -- I visualized myself grabbing it and running for the basement.  I wondered if that would be one of those fateful delays that would cost me my life.

The external enclosure had an eSATA connector, but my previous motherboard had not been able to accommodate eSATA on a hot-swappable basis.  In other words, I had to reboot in order to get the system to recognize it.  It also had a USB connector.  The external dock (i.e., not the enclosure) was also a USB device.  USB was slower but very adaptable.  That was almost always what I used.  Some partitions on the external drive were compressed, to save space.  I had the impression that this did not help with the USB connection -- that the CPU would unpack the file before shipping it across the slow USB cable to the computer, resulting in at least as much data moving along the wire -- but I hadn't verified that.

For my purposes, Beyond Compare offered two key concepts.  First was the workspace.  If I plugged in the external drive that I used for daily backups, then I would open up the DAILY workspace in BC.  If I plugged in a drive that I used for weekly backups, then I would choose the WEEKLY workspace.  I also had a SIMPLE COMPARE workspace that I would use for random tasks -- say, comparing two folders on a one-shot basis.  And I had a NETBOOK workspace that I would use to synchronize my laptop.  GoodSync might have been better for that if I had been using the laptop frequently, but at this point it was mostly a case of keeping the data on the laptop current with the desktop.  That is, I was mostly doing one-way updates, from desktop to laptop.

My workspaces differed in the tabs they made available.  In the DAILY workspace, I had a tab for each day of the week, plus whatever other comparisons I would want BC to make on a daily basis.  Likewise for the WEEKLY and the other workspaces.  In other words, I used a workspace as a place where I would be able to see tabs for each comparison that I wanted BC to make, whenever I plugged in the weekly drive or the laptop or whatever.

I found that the best approach was to start BC first, let the workspace load, and only then turn on or connect the external USB drive.  That way, BC would not try to do complete comparisons for all of the open tabs.  It would do its calculations for the relevant folders on the drives inside the computer, which were already available to it, but on the external drive it would have to wait until I gave it the go-ahead within a particular tab.

Focusing on the DAILY workspace, I was writing these notes on a Friday.  So to guide my remarks, I opened BC at this point.  Somehow, I had arranged for the DAILY workspace to come up by default; or maybe BC just defaulted to the last open workspace.  I wasn't sure how I had arranged that.  When BC was up and running, I turned on the USB drive.  It took that drive a moment to become available.  (I found that AntiRun was useful, not only for protecting my system from autorun malware and such, but also for telling me when a drive really was online or offline, and for giving me a functional way of taking external drives offline.)

I went to the Friday tab.  BC had stalled because the Friday folder on the external drive had been unavailable.  I told it to retry; and now that the USB drive was connected, BC ran its comparison.  (Details on the kinds of comparisons available, and other program capabilities, are available at Beyond Compare's website.  Their forums and other tech support had been very responsive, the few times I had contacted them.)

I had modified my BC toolbar to present the red Mirror button.  This said, basically, just overwrite whatever is in the backup space (in this case, the Friday folder on the USB drive) with whatever is on drive D in the computer.  Drive D was the one that I backed up daily.  So in this case, a number of files had changed since the previous Friday.  Sometimes I would take a look at them; sometimes not.  Usually not.  It seemed pretty rare that a file would be accidentally deleted.  Daily examination of all changing files had seemed to be overkill.

When I say that I would take a look, I mean that BC showed me two panes, one for each of the folders being compared.  To keep things organized, the left-hand pane was almost always the authoritative one.  The left-hand pane would correspond, that is, to a partition inside the computer.  So I was looking at the right-hand pane, corresponding to the backup device.  If I saw a file listed in the right-hand pane, but not in the left-hand pane, that would mean that it was on the system when I made my backup a week ago, but now it was no longer on the system.  BC would also alert me, with a red font, if the file in the right-hand pane was newer.  Generally speaking, that wasn't supposed to happen.

I had an alternating weekly folder on this backup drive.  I used that one on Saturdays.  That's the one I examined more closely.  If I found that something was missing on Saturday, and I didn't think it should be missing, I could then click on the tabs for the other days of the week until I found the last backed-up version, and I could restore it from there.

Drive D contained the things that were in more active use.  I also had a separate partition, drive E, for things that took up a lot of space and didn't change very often.  Videos were the main example.  Because there were so few changes there, it was easier to look at the differences identified in BC, and verify that additions and deletions were desired.

In net terms, I liked this arrangement because it gave me some flexibility to combine automated and manual processes.  I wasn't vulnerable to one of those black-box backup solutions that would seem like they were working just fine until the moment of crisis, when I would painfully discover that I had failed to adjust some essential setting, or that the drive was malfunctioning, or whatever.

In this arrangement, if I was worried that files were missing, I could look down through lists of what was being added and deleted.  If I was confident that everything was fine, I could just click the Mirror button and the backup would happen.  I could also combine both approaches within a single tab, by telling BC to mirror only the selected folder(s).  This would gradually reduce the number of things remaining on the screen (assuming I had BC set, as usual, to Show Differences rather than Show All).  When confronted with what looked like a mess, I could thus eliminate the parts that seemed OK, and focus on the files and folders that didn't seem like they should have been getting added or deleted.

Like most other computer-related matters, my backup approach continued to evolve.  But as I say, I had been using BC for a while, at this point, and I was pretty much satisfied with the combination outlined here.

File Naming Conventions

I had a bunch of files. I was looking at ways to sort them. It seemed that it might help if they were all named according to file naming conventions, so that files of a certain type would be named in certain standard ways.

It was not immediately clear if there was any scholarly consensus as to what approach would be best. Along with general advice, there seemed to be at least two fundamentally different philosophies. On one hand, sources like the National Technology Assistance Project (NTAP) recommended using a folder hierarchy and relatively plain-English filenames. For instance, a file named "2009-05-15 Letter to Smith, R P" might be found in the 2009 > Correspondence subfolder; or in a different scheme, it might be in the Completed Projects > Waterway subfolder. On the other hand, Vincent Santaguida recommended putting the information into the filename itself and avoiding folder hierarchies. (I found that document and others on an Exadox webpage.) Santaguida's first example said this:

Do: Z:\Prod\QA\AssL7_WO_Suzuki_L3688_20090725.xls

Don't: Z:\Production \Quality Control\Assembly Line7\Work Orders\Clients\Suzuki Motors\ LOT3688_July‐25‐2009.xls

Depending on who was using the files and how much they knew about the variety of filenames in the archive, it seemed that Santaguida's approach might benefit from a formal, elaborate naming scheme -- with, for instance, a reference work where users could look up "Quality Control" or "Assembling Line 7" (and other variations) and find the proper rules for naming documents related to those topics, and a list or guidance system leading to relevant documents already filed. I could see where such a system might be valuable in some settings. I had a couple of concerns about it, though. One was, what happens if you lose the reference list, or if the specialized database management system creating such filenames goes on the fritz?

It seemed that, for most purposes, PC Magazine had the better idea: make your filenames indicative of what the file contained, in terms that potential users could understand -- and, I would add, within a scheme that would not require more maintenance than users or database managers would devote to it. For instance, aside from special projects like this one, I was not generally going to invest the time to create a highly precise file naming arrangement. It did seem that Santaguida's approach could help reduce file duplication, but I felt that DoubleKiller gave me an adequate solution for that. The other thing was that I didn't actually know how life was going to turn out yet. File arrangements grew up on the fly, as new situations emerged. I wasn't positioned to put it all into a rigid structure.

In other words, while adopting some principles recommended in the Best Practice for File-Naming produced by the Government Records Branch of North Carolina, I was concerned that "Records will be moved from their original location" -- that, in other words, I might have to re-sort things that I had already sorted once -- but I didn't see an easy way around that. Building their location into the filename would have been a bad idea because, in many cases, I *wanted* to be able to re-sort things at random.

Within the individual filename, Santaguida's second principle seemed right: "Put sufficient elements in the structure [particularly in the filename] for easy retrieval and identification but do not overdo it." I had been working toward a couple of basic formats:

2009-05-04 13.59 Message from X to Y re Z.pdf
Shakespeare--Romeo and Juliet.pdf
Shakespeare--Romeo and Juliet - with notes.pdf
Garfunkel--Bridge Over Troubled Water.mp3

The present project, I decided, was one in which I could mostly tend toward the first example: Year-Mo-Da Hr.Mn DocType from Sender to Recipient re Subject.ext. I would use periods and hyphens (-)for some limited purposes, but would tend not to use other punctuation. This tended to agree with Santaguida's third rule: Do not use characters such as ! # $ % & ' @ ^ ` ~ + , . ; =)]([. Santaguida said don't use spaces, but I had rejected that in opting for plain-English filenames. He also said to use the underscore (_) to separate filename elements, but that was unnecessary in my approach. It also had the potential to confuse things. I noticed that some naming and conversion programs used the underscore in place of the space, giving me "File_name.exe" instead of "File name.exe." In Santaguida's approach, that would falsely suggest that "File" and "name" were two different elements. I planned to scout out and remove underscores. The intention to minimize punctuation also seemed generally consistent with various uses of special punctuation in Windows.

I also had to think about Santaguida's seventh principle. He recommended putting surname first, first name second: "Smith, Roger" rather than "Roger Smith." Actually, in his approach, it was "Smith-Roger." It seemed to me that there were some reasons not to do it that way, at least in my system. One was that I would have to sweep filenames (at least new filenames) for consistency occasionally at any rate, to catch and rename those newly created documents where some variation appeared (e.g., "Smith, R.P.," "Smith, R P," 'R Smith"). There didn't seem to be any difference between one approach and the other in that sense. What seemed more practical was to use whatever name I actually tended to use for someone, so that I would be most likely to name it correctly the first time, when I was thinking about something other than my file naming scheme. Typically, this would be along the lines of "Roger Smith" -- which would also have the advantage of eliminating extra hyphens and commas.

Once I had such ideas in mind, I went through the list of files, using Excel to generate batch commands to rename many files at once. Where the files had one of the structures shown above, I was able to use FIND and other text functions to segregate certain elements (e.g., Author, Date) into separate columns, and then use unique filters and other tools to eliminate variations (in e.g., personal names).

Converting Scattered WMA Files to MP3

I had .WMA files scattered around my hard drive.  I wanted to convert them to .MP3.  I could search for *.WMA, using a file finder or search tool like Everything, thereby seeing that those files were in many different folders.  Having already sorted them, I didn't want to move them anywhere for the format conversion.  I wanted to convert them right where they were.  A command-line tool would do this.  The general form of the command would be like this:  PROGRAM SOURCE TARGET OPTIONS.  For PROGRAM, I would enter the name of the command-line conversion program that I was going to be using.  For SOURCE and TARGET, I would enter the full pathname (i.e., the name of the folder plus the name of the file, like "D:\Folder\File to Convert.wma," where the target would end in mp3 rather than wma).  OPTIONS would be specified by the conversion program.  For instance, there might be an option allowing me to indicate that I wanted the resulting MP3 file to be 64bps.

The problem was, I didn't have a command-line WMA to MP3 conversion tool.  I ran a search and wound up trying the free Boxoft WMA to MP3 Converter.  (They also had lots of other free and paid conversion and file manipulation programs.)  When I ran their converter, it steered me to an instruction file that inspired me to compose the following command (all on one line):

AlltoMp3Cmd "D:\Folder\Filename.wma" "D:\Folder\Filename.mp3" -B56

I had to use quotation marks around the source and target names in some cases (though not in this particular example) because some of the path or file names contained spaces.  The -B56 option was supposed to tell it to produce a 56-bit MP3.  (I also tried it with a space:  "-B 56".)  I was able to produce similar commands en masse, for all of the WMAs that I wanted to convert, by exporting the results of the *.WMA search from Everything to a text file called wmalist.txt, making sure to remove entries for files that I did not wnat to convert.  (At the root of each drive containing files of interest, I could also have used this command, assuming wmalist.txt did not already exist:  dir *.wma /b /s >> D:\wmalist.txt.)  I then massaged the contents of wmalist.txt using Microsoft Excel.  So now I had all of these AlltoMp3Cmd commands ready to run.  I copied them all into a Notepad file named Renamer.bat.  All I had to do was double-click on it in Windows Explorer and it would run.

I decided to try Renamer.bat with just one WMA file.  So I created another file, X.bat, with just one line in it, like the line shown above.  To run X.bat from the command line, so that I could see what it was doing, I would need a command window that was ready to execute commands in the folder where X.bat was located.  Problem:  X.bat was not in the same folder as Boxoft's AlltoMp3Cmd.exe executable program, so X.bat would fail.  If I didn't want to get into changing the computer's PATH, I could either put X.bat in the Boxoft program folder or I could copy AlltoMp3Cmd.exe to the folder where X.bat was located.

Either way, I needed to open a command window in one of those two folders, so as to run X.bat.  I could start from scratch (Start > Run > cmd) and use commands (e.g., "D:" would take me to drive D and "cd \Folder" would take me to the folder where Filename.wma was located), or I could use Ultimate Windows Tweaker to install a right-click option to open a command window in any folder.  I had already done the latter, so this step was easy.

Once I had sorted out all that, I was ready to try running X.bat.  But when I did, it crashed the AlltoMp3Cmd.exe program.  If I clicked on Cancel when I got the crash dialog, the command window said this:

Exception Exception in module AlltoMp3Cmd.exe at 0005B4E1.
Installation file incorrect. Please re-install it!.

But reinstalling the Boxoft program didn't help.  I sent them a note to let them know of this problem and decided to try other approaches.  One possibility was that their program was suitable for Windows XP but not Windows 7, which I was using.  It didn't seem to be a question of how the main program was installed, since the error message was referring specifically to the AlltoMp3Cmd.exe command-line executable (which presumably would be the same on any Windows system).

I decided to try running it in a Windows XP virtual machine (VM).  I had already installed Microsoft's Windows Virtual PC, which came with a WinXP VM, so I fired it up to try the same command line in the same folder.  To move quickly to the proper folder in the WinXP command window, I ran my trusty old RegTweak2.reg file, created in Notepad, to install a right-click option to open a command window in any folder in Windows Explorer.  But when I tried to use it, I got an error:

'\\tsclient\D\Folder Name\Subfolder Name'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
'\\tsclient\D\Folder Name\Subfolder Name'
CMD does not support UNC paths as current directories.

A bit more playing around persuaded me that what this message meant was that command-line work in the VM would have to be done on what the VM considered a "real" (actually a virtual) drive -- in other words, drive C.  So I put copies of X.bat and AlltoMp3Cmd.exe into the VM's drive C, in a new folder I called Workspace, and I tried running X.bat from the command line there.  But again I got an error:  "AlltoMp3Cmd.exe has encountered a problem and needs to close."  Maybe the program wasn't built to handle paths.  For whatever reason, it looked like the Boxoft AlltoMp3Cmd command-line utility was not going to work for me.

A search in CNET brought up some other possibilities.  One was IrfanView, reminding me that I had used that program to work partway through a somewhat similar problem months earlier.  Using IrfanView version 4.28 and various insights described more fully in that other writeup (and in a recent thread), I went back to my original list of files in wmalist.txt and prepared this command:

i_view32.exe /filelist=D:\wmalist.txt /convert=$D$N.mp3

This command was supposed to use the file names ($N) and directories (i.e., folders, $D) specified in wmalist.txt to produce MP3 files with those same names, in those same directories.  Before trying it out, I made a copy of wmalist.txt and changed the original so that it contained only two lines, referring to WMA files on two different drives.  I ran the command shown above in a CMD window.  I got an error:

'i_view32.exe' is not recognized as an internal or external command, operable program or batch file.

In other words, Windows 7 did not know where to look to find IrfanView.  I could have taken the steps mentioned above, moving the .txt file to wherever i_view32.exe was located; but since I used IrfanView often, I wanted to add it to the PATH variable so that Windows would permanently recognize it.  The solution was to go to Start > Run > SystemPropertiesAdvanced.exe (also available through Control Panel > System > Advanced System Settings) and then click on Environment Variables > System Variables > highlight Path > Edit.  To see clearly what I was doing, I cut the existing Variable Value out of the dialog and doctored it in Notepad.  The basic idea was to add, to the end of the existing value, a semicolon and then (without adding a space after the semicolon) paste the location of i_view32.exe (found easily enough via an Everything search > right-click > Copy path to clipboard).  I made sure to add a final backslash ("\") after the path to i_view32.exe.  I pasted that back into the dialog, OKed my way out of System Properties, went back into the command window, pressed the Up arrow key to repeat the command ... and it still didn't work.  I thought that possibly I would have to reboot to have the new PATH definition take effect.  That was the answer to that particular problem.  After rebooting, in a command window, I ran the command shown above, and there were no errors.  IrfanView was open, but nothing was in it.  I ran searches in Everything for the two files in my test WMAlist.txt file, with wildcard extensions (i.e., I searched for Filename.*).  No joy:  there were no MP3 versions of those files.  I tried a modified version of the command:

i_view32.exe /filelist=D:\wmalist.txt /convert=D:\*.mp3

but that produced no output in D.  The IrfanView command was not working.  I tried yet another variation, as above but without "D:\" but that wasn't it either.  I tried the original command without using the filelist option:

i_view32.exe "D:\File Path\File Name.wma" /convert=$D$N.mp3

This produced an error:

Error!  Can't load 'D:\File Path\File Name.wma'

Did that mean that the /convert option was not being recognized?  Everything indicated that no MP3 file had been created.  And why would IrfanView be unable to load the existing WMA file?  It could load it easily enough from Windows Explorer or Everything.  I tried again:

i_view32.exe "D:\File Path\File Name.wma"

That worked:  IrfanView played the file.  So the convert option was the problem.  Another variation:

i_view32.exe "D:\File Path\File Name.wma" /convert="File Name.mp3"

If that did work, I wasn't sure where the output file would turn up.  No worries there:  it didn't work.  I got the "Can't Load" error again.  IrfanView's help file said that it did support wildcards for /convert, so that was presumably not the problem.  I had seen an indication that IrfanView would not batch-convert certain kinds of files, but WMA was not on the list I saw.  I was going to post a question in the relevant IrfanView forum, but at this point they weren't letting me in, for some reason.  Eventually it occurred to me to look in IrfanView's File > Batch Conversion/Rename area, where it appeared that the program would support only image conversions, not audio.

It seemed I would need to continue searching for a command-line option.  Back at that CNET search, I looked at the Koyota Free Mp3 WMA Converter -- from another company that offered multiple free conversion products -- but saw no indications that it had command-line options.  Likewise for Power MP3 WMA Converter and others.

I finally opted for a kludge solution.  Using an Excel spreadsheet, I created a batch file (again, using techniques described in the other post referenced above and elsewhere) to rename each file in WMAlist.txt to a unique name (example:  ZZZ_00001.wma) -- after making sure I did not already have any files with that kind of name.  The unique names would help to insure that all WMA files would get the treatment, even if two of them had the same original name.  This produced 386 files.  Then, using Everything, I selected and moved all ZZZ_*.wma files to D:\Workspace.  Somehow, only 375 files made it to that folder.  It turned out that I had inadvertently included WMA program files from drive C after all, which I had not wanted to do, and for some reason a few of those were not moved to D:\Workspace -- probably for insufficient rights.  So now I would have to undo that damage.

After taking care of that, in D:\Workspace, I tried the Boxoft program again, this time using its Batch Convert mode.  It took a while.  Spot checks suggested that the conversion quality was good.  I wasn't sure what bitrate to use to convert the files.  It seems that, at 56 kbps for what appeared to be a bunch of voice (not music) files, I erred on the high side.  I started with 353 WMA files occupying a total of 237MB, and I ended up with 353 MP3 files occupying 405MB.  Those files were converted at what appeared, at quick glance, to be a rate of about 6MB per minute.  I then revised the spreadsheet to produce batch file command lines that would move those MP3s back to the folders where the similarly named WMA files had been and rename them back to their original names (but with MP3 extensions).

Windows Explorer Fails to Retain Multiple File Selection

I was installing Windows XP SP3.  I had just installed some basic utilities, mostly related to the user interface.  After doing so, I noticed that Windows Explorer would allow me to highlight files and folders, but when I right-clicked and hit Cut (or when I used Ctrl-X), the folder icons would fade for a second, as they would typically do when files were being cut and pasted; but then the fading effect would end.  And if I went to another folder and tried to paste, there was no right-click (context menu) paste option.  I could move them only by dragging them to that other folder.  The choice of view (e.g., Detail view, Icon view) did not seem to make a difference.  The problem occurred in a variety of folders.

I went back to a previous backup of this Windows installation and started over, installing those same programs again.  This time, the fading effect ended as before, but now cutting and pasting did work properly.

I did a search, initially, on the problem of being unable to select multiple files.  That led to a post discussing some solutions.  It looked like Vista users were having this problem too.  But when the problem recurred in the different form just described, I opted to try a different search.  There were no obvious solutions on the first several pages of that.  So I decided to work back through the programs I had recently installed, to see if one of them was responsible.

What I found was that the effect of the offending program was not immediate.  The problem didn't appear until after I had rebooted.  This was why I did not notice it right away, and just kept on installing other stuff.  So I installed them one at a time, rebooting and testing after each one.  This procedure established that the problem was due to the M8 Free Clipboard program.  I proceeded with installing my other programs.  The problem did not recur.

Windows XP in VMware Workstation 7.1: Windows Explorer Keeps Refreshing

I was running Windows XP SP3 as a guest in a virtual machine (VM) in VMware Workstation 7.1.1 on an Ubuntu 10.04 (Lucid Lynx) host.  I had just installed a couple of freeware utilities when suddenly Windows Explorer began refreshing itself about every two seconds.  More specifically, it was refreshing the right-hand pane, showing files and folders, but not the left pane, showing the folder tree.

I thought at first it was a virus, but I was running antivirus software, and a scan with a different antivirus program turned up nothing.  Besides, I had just downloaded those programs from reputable sources (e.g., CNET) that supposedly certified them to be virus-free.

A search suggested this was a relatively common problem.  Several posts made me think it had to do with network drives, which in this case would mean the link between Windows and VMware.  I killed the VM, reverted to a previous snapshot, and started that, but the same thing was happening there as well.  I powered up a different VM in a different session of Workstation.  The problem was not occurring there.  I closed all sessions of Workstation and powered up the misbehaving VM in a new session of Workstation.  The problem recurred -- but then, after a minute or two, it stopped.  But then, after I used Windows Explorer some more, it resumed; but then it stopped again.

I downloaded the "Prevent Automatic Folder and Icon Refresh" registry edit from Kelly's Korner and ran that, and then rebooted Windows within the VM.  The problem was still there.  I took this to mean that *automatic* refresh was not the problem -- that, presumably, something was manually refreshing Explorer.

I tried displaying different drives' contents in Explorer, on the theory that maybe this was happening in connection with just one particular network drive.  That was not the case; it happened on all of them.

I wondered if a program installation was responsible for the problem.  But it was not clear to me how any of these would have been responsible for the fact that the flashing occurred within a snapshot that I had taken before installing them.

Then I came closer to what seemed like a possible answer.  I tried again to install the Microsoft Task Switch Powertoy.  I had tried before, and it had given me an error message, and the same thing happened again.  The error message was "Error 1606.  Could not access network location [gibberish]."  The gibberish was actually just a set of five squares with no characters in them.  It appeared that the installer was trying to access a network location whose name did not consist of valid characters.  Following advice, I checked the following registry keys for incorrect addresses:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

I did find several bad entries in the second of those five locations.  I corrected those and rebooted the VM.  I was now able to install the PowerToy.  Unfortunately, the flashing was still going on.  I went into VM > Settings > Options > Shared Folders and switched that to Disabled > Save.  The flashing stopped.  In Windows Explorer, I tried to go to another network drive, but got the message that it "is not accessible.  The network path was not found."  I went to drive C (not a network drive).  Its contents displayed OK.  No flashing.  I set Shared Folders back to Always Enabled.  No flashing on drive C.  Flashing on drive D.  I tried C again.  The folders there would refresh once, immediately after being selected, but then not again.  In Windows Explorer's menu, I went to Tools > Disconnect Network Drive and disconnected drive D.  Drive E was still flashing.  I went to Tools > Map Network Drive and mapped D again.  It was flashing.

A Microsoft Knowledgebase webpage said that a somewhat related problem (flickering in the left-hand pane of Windows Explorer) could be repaired at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer.  I had only a lowercase "policies" (not "Policies") key at that location.  Regedit would not let me create the uppercase version.  So I went into the lowercase "policies" key.  It did have an Explorer subkey.  I went in there and created a new key, NoRemoteRecursiveEvents, of REG_DWORD type, and gave it a value of 1.  I exited regedit and rebooted.  This step did not solve the problem.

I closed this VM and went back to the previous version, the one that did not flash.  I corrected the incorrect registry addresses (above) first.  Then I started reinstalling the programs that I had been installing when the problem began.  I went down the list and, what do you know, the flickering started when I installed FolderSize, and it stopped when I uninstalled it.  FolderSize calculates the size of folders, and apparently refreshes the screen while it does so.  After I uninstalled it, the problem went away.

Organizing Portable Applications in Windows XP

In a previous post, I have noted what I felt were several advantages of portable software, but have also mentioned one or two problems with my attempt to use the PortableApps.com framework.  This post describes my progress toward another approach to using portable applications in Windows XP.

For quite a few years, I had used drive D to hold portable applications.  These were programs, links, and other materials that I would not have to reinstall, if Windows itself needed to be reinstalled on drive C.  So now it was pretty easy to set up a folder called D:\Installation\Portable Apps.  Under that folder, I set up a subfolder called _Menu.  (With the beginning underscore, Windows Explorer would put it at the top of the list of folders.)  In _Menu, I arranged shortcuts to each of the programs I had brought together into the Portable Apps folder.

This approach had its own advantages and problems.  On the positive side, it could be much faster to run programs from the hard drive than from a USB drive.  So treating drive D as the authoritative source, to be backed up and copied from, made sense.  Then, if I took the USB drive off to some other location and made changes on it and/or on drive D, I would want synchronization software that would let me reconcile those two drives in their changed form.

On the negative side, this rigid file structure, which worked well enough on the hard drive, might not work so well with a USB drive.  Imagine copying a program from drive D to a USB drive that would be plugged into some other computer, where drive D would not be available.  The jump drive would take some other letter -- say, G.  At this point, all of my menu shortcuts to portable files stored somewhere on drive D would fail.  Worse, every reference to drive D within my portable programs would fail.  For instance, if the program kept its settings in D:\Installation\Portable Apps\CoolProgram\coolprogram.ini, it would now be unable to find those settings.  (Fortunately, portable programs usually seemed to refer to other files within the same folder, so this might not be too much of a problem.)

To avoid problems with references to drive D, I went looking for another approach.  In the Portable Freeware Collection (PFC) website, I found a list of portable program launchers, ranked in terms of popularity.  At the top of that list, I found a program called PStart.  Its webpage said, "Unlike Windows shortcuts, PStart uses relative paths, when installed as a portable application. If your USB key drive gets another drive letter when you insert it into another computer, your portable applications still can be started properly" -- as long as those applications were on the same drive as PStart.  This appeared to be an improvement on PortableApps.com, where there was some indication that relative addresses might not work for programs other than the .paf files you would get through PortableApps.com itself.

So I downloaded PStart and ran it.  It acted like a normal installer, with advice to close all other programs before continuing.  It seemed that it might not let me install it as a portable application.  I went to the PStart FAQs page for guidance.  It seemed to say I could just go ahead.  Sure enough, I came to a screen that gave me a choice between local and portable installation.  But the portable one was not seeing any portable drive -- because, of course, I had not plugged one in.  That is, it was not going to let me do a portable installation directly to D:\Installation\Portable Apps.  I plugged in a USB drive, backed up, and tried again.  But it was still just saying "other drive" -- that is, it was not recognizing the USB device.  So, OK, I canceled the installation and tried again.  This time, it found the USB drive.  I noticed that, now, it did offer me a Browse button, and that led to any drive on the system.  So perhaps I could have installed it directly to somewhere on D after all.  But it was OK; I went with the approach of putting it in the default location, which was the root of the USB stick.

When installation was done, I accepted the option of starting PStart now.  It gave me a little pop-up window that said, "Rightclick to add items."  I didn't want it to add items to the USB drive, so I killed it, went to the root of the USB drive in Windows Explorer, and moved PStart.exe (the only thing I found there) to D:\Installation\Portable Apps.  Then I double-clicked on it and it ran.  But now I noticed I had two PStart icons in my system tray, so I killed this newly started session, right-clicked on one of those tray icons and selected Exit, and then right-clicked on the other one to show the pop-up window again.

Since I had already accumulated a boatload of portable apps in D:\Installation\Portable Apps, I didn't want to right-click and add each of them manually.  I didn't find guidance on the webpage, but in the program itself, File > Search for Executables seemed to be just what the doctor ordered.  This placed a single top-level item in the Items tab, called simply D:\Installation\Portable Apps, with an indication that it had found 429 items.  I opened that item, dragged the corners of the little window to make it bigger and easier to read, and started down the list.  There were a lot of items to delete.  For example, in the case of 7-Zip, it found 7-Zip Portable, 7-Zip Console, 7-Zip File Manager, and 7-Zip GUI.  I had to decide which ones to delete, and then select and delete them one at a time.  Sometimes I had to try them out; sometimes I had to consult D:\Installation\Portable Apps to see which ones I would actually want to run.  In this way, I reduced the list to 102 programs.

Now there was the question of organizing them.  In my _Menu folder, I could create subfolders for various categories of programs -- web browsers, for example.  PStart's list of 102 programs was not the easiest thing to sort through and find what you were looking for.  I sent PStart's makers a question about that.  In the meantime, I planned to keep both organizing approaches.  I would use PStart for its dynamic ability to start a program regardless of the drive letter assigned to the USB drive; but I would use my menu and its submenus of shortcuts, when copying the Portable Apps folder to another hard drive, because I had long been running portable apps from the same place (i.e., D:\Installation) on my various virtual and native Windows installations.

Before long, I found that I was not using PStart very much.  One reason was that it was just more familiar to use the menu of shortcuts.  I wasn't doing very much work in situations where I actually needed a portable drive.  When I did need to run an app from the jump drive, I could just navigate to its folder and click directly on its .exe to run it.  I wanted portable apps primarily so that I could reduce the number of program complexities and reasons for a system crash in Windows XP.  I wasn't sure if portable apps would actually help in that, but that was the nature of the investigation in process.  So I was just using shortcuts to run my portable apps from their own menu, with the idea of adding that menu to my regular Start Menu at some point.

If I had tried to depend more heavily on PStart, it seemed that I would have had some problems.  First, it was not easy to keep its menu updated.  If I brought in a batch of a dozen new portable apps that I had just downloaded from some website, there didn't appear to be any way to detect just the newcomers.  If I ran PStart's regular "Scan for executables" menu option, I would get the list of 400+ executables again, and would have to go picking among them.  I didn't have that kind of time to devote to this.  In some future iteration, I hoped, the program would remember what it had found previously, and would present me only with the newcomers.

A second problem was that PStart did not provide a way to categorize shortcuts.  I was just stuck with this list of 102 programs.  The office software, video software, file utility software -- it was all just lumped in together.  The Edit > Add Folder option didn't mean that I could add a folder to the PStart file list; it meant that I could add a folder that I wanted to list along with all these applications.  If I knew I needed a video program, but couldn't remember its name or just wanted to see which ones I had available, I couldn't go to a subfolder entitled "Video," within the PStart panel, and choose the most suitable app from there; I'd have to just go down the list of 102 programs, one at a time.  Even then, I'd be limited to those whose names made sense.  If a killer new video program called itself XPQ, it just might not occur to me that this was what I was looking for.  I'd have to edit its name, in the list, to make sure I could recognize it -- thereby increasing the amount of reading I'd have to do when I went searching for a program.

Instead of PStart -- indeed, instead of a menu that I would have to maintain -- I decided to try something different.  It occurred to me that I could just arrange the portable app folders themselves in a menu structure.  So under my Multimedia top-level folder, I would have an Audio subfolder; and in there, I would put the actual program folders for each program that I thought of as being primarily audio-related.  I made a copy of my Portable Apps folder and experimented with this.  Along the way I noticed that I (or whoever I got the idea from) had been mistaken:  shortcuts did seem to keep track of their targets, even when they were copied to another drive -- at least as long as they were all copied together.

This hierarchical arrangement seemed to work pretty well, and I decided to make it my approach, at least for the time being.  The next question was how to integrate that hierarchy into my regular Start Menu, with its shortcuts to installed programs.