VMware Workstation 7 in Windows 7: Error Moving File or Folder

I had just started using Windows XP SP3 as a guest in VMware Workstation 7.1 on a Windows 7 host.  It seemed that I was getting a certain error every time I tried to move files from one folder to another.  Both the target and source drives were on network drives, in the VMware sense:  they were local drives on that computer, but they were not part of the actual virtual machine (VM) as drive C was, so Workstation considered them network drives.  When I attempted to paste these files into a folder on that other drive, I got this error message:

Error Moving File or Folder

Cannot move [filename]: It is being used by another person or program.

Close any programs that might be using the file and try again.

These files were not in use anywhere, as far as I could tell.  I was using a utility called Unlocker.  When this kind of error would occur, Unlocker would pop up, provide relevant information, and offer to help.  In this case, Unlocker's message was, "No locking handle found."  This was not absolutely the last word on the subject, but I had found Unlocker to be pretty reliable.

This was happening every time I tried to move files.  It was not a problem with one particular troublesome file.  It happened with moving files, not with deleting them.  I was able to delete files, and copy files; I just couldn't move files.  I had done a global change of file properties so that none were read-only.  This inability to move files occurred on all network drives.

I did a search on this error.  Very few results turned up.  I posted a question on it in a VMware forum.  One of the results from the search led to a lot of instances where people were getting the same or a similar error message in non-VM contexts.  Some of the advice offered in those kinds of situations involved one-off solutions, where there was a particularly troublesome file.  Someone suggested trying to do this as administrator, but I was already running as administrator.

That last person remarked that the errors s/he was experiencing may have resulted from changing the host name on the computer.  This was not a newly created VM.  I had used it in Workstation for Linux, to run WinXP on an Ubuntu host on a separate computer.  When I brought it over to this computer and fired it up, Workstation asked whether I had copied or moved it.  I said I moved it.  So possibly what was happening was that Workstation remained confused about some aspect of the machine due to the fact that it was not a virgin WinXP creation.

To explore this possibility, I closed down this VM and started up another.  I didn't want to spend the time to create a whole new WinXP installation in a VM.  What I did instead was to choose a preexisting VM that had different origins.  So now I felt that I should clarify the genealogy of this thing.  This troublesome VM was not actually created in Workstation.  It was created by VMware Converter.  I had used Converter to convert a native WinXP installation into a VM that I then used in Workstation for Linux.

I did have another WinXP VM that I had created in Workstation for Linux -- installing Windows XP from scratch inside a virtual machine, that is, rather than installing it on a regular computer and then converting it.  So that was the one I tried using now.  The problem did not occur there.  These differences in origins may have explained the difference in behavior.  It may also have had something to do with the differences in size.  The converted native machine was twice the size of the born-in-virtual machine.  Its size itself may have been an issue, or there may have been a problem with some program that I had installed within that larger machine.

Windows XP: Additional Tweaks

I had installed a tweaked version of Windows XP in a dual boot setup with Ubuntu 10.04, and also in a virtual machine in VMware Workstation 7.1 running on Ubuntu.  The processes of setting up and using those installations led to problems and adjustments that I had not described in my previous post.  This post describes those items.

In the native (as distinct from virtual) installation, I had some hardware issues.  I have addressed those in another post.  When those issues were resolved, I began by completing the Ubuntu part of this dual-boot system.  It would not have any impact upon the Windows installation per se, but it would provide some convenient tools in case of trouble.  For the Ubuntu portion, I followed the steps described in a separate post.

Another problem was that, when I selected File > Save within a program, I saw the files in a given folder presented in list view, whereas Windows Explorer was set to show things in detail view.  To present the items in the File Save dialog in detail view, I followed advice to change the dialog to the view I wanted and then hold Ctrl and click on Cancel.  This did not work.  Nor did it work to use Ctrl-Save or Shift-Save.  In lieu of buying File-Ex, which another person there recommended, I went with the majority and downloaded and ran FileOpenPatcher.  But after installing, it warned me that running System File Checker (SFC) would undo the changes made by the program.  I uninstalled it and tried another search.  In the meantime, I ran SFC just to be sure, and it was partly true:  the undesirably large size of the File Save dialog set by default in FileOpenPatcher was gone -- I was back to a normal-sized File Save dialog -- but now it was defaulting to details view.  So the problem appeared to be solved by a temporary installation of FileOpenPatcher.  Unfortunately, that fix did not last.  Doing a Ctrl-click on the detail view selection also failed to make a difference.  Open Wide looked like it would do the job; but that fix, too, did not persist.

Another problem:  I noticed that Windows Explorer was sometimes very slow to display the contents of folders.  A search for this led to a plethora of solutions, including a thread that itself contained a number of suggestions.  I considered the suggestion to disable thumbnail caching, but my system was already set that way:  Control Panel > Folder Options > View > Do not cache thumbnails.  Although the folders in question did not have many zip files, as a future precaution I also took the suggestion to do Start > Run > "regsvr32 /u zipfldr.dll."  As I played with it some more, I noticed that the problem occurred especially on the first use of Windows Explorer.  This raised a couple of possibilities.  One was that the virtual machine (VM) in which I was running Windows had not yet finished loading onto the host (Ubuntu) system.  Another was that, on this installation for some reason, Windows Explorer would not load or otherwise sort itself out until I actually used it.  A third possibility was that I had a program running in the background.  At this particular time, I did, in fact, have two different programs running in the background, and they raised two different kinds of concerns.  In the Ubuntu host, I was letting BOINC use my computer, when it was idle, for public service computing.  I went into BOINC and severely reduced the amount of swap space, memory, CPU time, and other resources available to that program.  I did not run a test to see whether that, by itself, solved the problem.  The other program running in the background, at this point, was Copernic Desktop Search.  I had just installed it, and it was doing its initial indexing of my drives.  It was supposed to do this when the computer was idle, and perhaps it was.  Whatever the culprit, ultimately it went away without my having to uninstall either of these programs.

I belatedly discovered Dial-a-Fix but did not try it.  Perhaps it would have contributed solutions to some problems I had encountered.  I found that Mozilla software -- especially Thunderbird and Firefox -- did not work consistently in the portable versions, so I wound up using installed versions of those programs.

To disable the question, "Do you want to allow this webpage to access your clipboard?", I followed the advice to go into Control Panel > Internet Options > Security tab > Custom Level > Scripting section > Allow programmatic clipboard access > Enable.

This was the end of this post.  Other tasks intervened.  By the time I returned to this, I had decided to upgrade to Windows 7.

Microsoft Word 2003: "Saving the Autorecovery File is Postponed"

I was using Microsoft Word 2003 in Windows XP.  In Tools > Options > Save, I had checked the box next to "Save AutoRecover info" and had set it to save every 1 minute.  I got a dialog that said, "Saving the AutoRecovery file is postponed for '[filename].'"  I clicked OK on that.  A minute later, it was back.  I clicked OK on it again.  I was able to use File > Save to save the document.  The dialog kept coming back.

I did a search for that message.  The first thread advised me to uncheck the "Save AutoRecover info" box, exit Word, search for all files beginning with ~$ or ending with .tmp, and delete them.  In Windows XP's classic mode, I went into Start > Search > For Files or Folders and searched on the Windows XP program partition (i.e., drive C, where Word 2003 was installed, as distinct from the separate partition where I stored my data) for ~$*.* .  I selected all of the files found.  I held down the Shift key and pressed the Delete key.  I re-ran the search and Shift-Del until there were no ~$*.* files left.  I did the same search and deletion process for *.tmp.  I confirmed file deletion even when I got a message indicating that one of the files being deleted was a system file.  There was one file I was not able to delete because it was "being used by another person or program."  I restarted Word and turned AutoRecover back on.  A minute later, the "AutoRecovery is postponed" message was back.  So that fix had not worked for me.

I had had this problem on a previous installation, so I did not try the advice of uninstalling and reinstalling Word.  The same thread advised me that perhaps Adobe Acrobat Pro 9.0 was the problem.  I closed Word and went into Acrobat > Help > Check for Updates.  It said the updater was already running, so I looked at the system tray (bottom right corner of the screen), right-clicked on the Adobe icon, and told it to install the update.  When that was done, I didn't restart Acrobat, lest it be the problem; I just closed it.  I restarted Word.  A minute later, the "AutoRecovery is postponed" message was back.

Another possibility suggested by that thread was that Word could be thrown off-balance by a change of drive letters or removing a hard drive.  I did not remember if I had changed anything of that nature since installing Word, and thus did not know how to go about fixing it if this was the problem.  In other WinXP problems related to drive letter errors, I had sometimes plugged in a USB drive and, using Start > Run > drivemgmt.msc, had relettered the USB drive to replace the offending or missing drive letter, and then rebooted, and that had solved the problem.  Possibly I could have resolved the problem in this case by working my way through the alphabet of drive letter possibilities until the problem went away.

I noticed another possibility mentioned in that same thread.  I had used Control Panel > System > Advanced tab > Performance Settings > Advanced tab > Virtual memory > Change to put my paging file on a partition other than drive C.  I had done this in the impression that this would make WinXP run faster and would also spare me from having to include several gigabytes' worth of paging file in my backups of drive C.  I decided to leave the paging file on that other partition, but I changed it from a fixed size to the "System managed size" option.  That required a reboot.  After the reboot, the problem was still there, so I tried putting the paging file back on C as system-managed, and rebooted again.  That didn't fix it either; the "AutoRecovery is postponed" message was back again.

I wondered if I had erred in deleting the *.tmp and ~$*.* files only from drive C.  My AutoRecover location was on a different partition.  I killed Word and, this time, just in case, hit Ctrl-Alt-Del and made sure that no Word processes were running. I re-ran the search, this time including that other partition.  But there were none of those kinds of files on that partition.  I ran the searches again, this time searching My Computer entirely.

It occurred to me, about this time, that the problem might be that I was putting my AutoRecover files on a drive other than C.  It wasn't a network drive -- but then, actually, it was:  I was doing this within a VMware virtual machine (VM), and VMware Workstation treated even a local hard drive as a network drive.  This, I thought, would explain why I was getting all those ~*.* files in the folder where I was saving my Word documents:  the "network" location was not being accepted.  I went into Word > Tools > Options > File Locations and changed the location to a folder on drive C, and then restarted Word.  That seemed to do it.  Ten minutes later, the error message had not returned.

Ubuntu 10.04 and Windows XP Dual-Boot: GRUB2 Woes

I was installing Windows XP SP3 and Ubuntu.  I encountered some error messages early in the process.  This post describes the steps I took in an attempt to resolve those problems.

First, I got this error:

Setup did not find any hard disk drives installed in your computer.

In my search for a solution, I found a thread offering a number of suggestions.  The one that worked for me was to go into the BIOS (hit Del at startup) and make sure the SATA controller was set to ATA, not AHCI.  Mine had started out as ATA, but a notice had popped up when I was first booting it, offering to change it to the AHCI, and I had accepted.  After I fixed this, the next bootup problem was this message:

Windows could not start because the following file is missing or corrupt:

\system32\hal.dll
Please re-install a copy of the above file.

My search on that led to a page offering a number of suggestions.  I started with just rebooting.  That didn't fix it.  suggesting that I go into the BIOS and switch the order in which the BIOS would try to boot my hard drives.  This led to a new message:

error: no such device: [UUID number]

grub rescue>

This apparently happened because I had previously installed Ubuntu on that hard drive.  For this one, I took the advice to boot from the WinXP installation CD, choose R to repair an existing installation, choose the existing installation (no administrator password), and type this sequence of commands:

D:\WINDOWS> C:

C:\> CD \

C:\> FIXBOOT C:

C:\> FIXMBR

C:\> BOOTCFG /rebuild

The last one led to an offer to add D:\WINDOWS to the boot list.  I took that offer.  But then it asked "Enter Load Identifier" and "Enter OS Load Options."  I didn't know what to add, so I just hit Enter for each.  This led to a new error message:

Error: Failed to add the selected boot entry to the boot list.

I guessed that the system was seeing the Windows installation on drive D because I had reversed the boot order in the BIOS.  I did think I had cabled them correctly, with the Windows drive going to SATA0 (i.e., the first SATA connector) on the motherboard.  I looked into Load Identifier and found a Microsoft page with information on that and other parts of this situation.  It told me to type the name of my operating system:  Microsoft Windows XP Professional, though apparently anything would do.  For OS Load Options, it said, type /fastdetect.  Unfortunately, this was not satisfactory.  I got the "failed" error again.

The responses to this seemed to lean in the direction of editing the boot.ini file.  A thread on that gave me the idea of just copying my boot.ini file from another computer.  A Microsoft page gave information on editing it if I was already in WinXP, which I wasn't.  A webpage devoted to boot.ini said it should be possible to just delete the boot.ini file in order to boot the system.  The webpage also gave some sample boot.ini files.  I typed "help" at the prompt and got a list of options.  There didn't seem to be an editor in the Repair Console.  I typed "dir" to verify that boot.ini was there, and then typed "type boot.ini" to see what was in it.  It didn't look very complicated.  What's more, it looked like my XP Pro entry was already there, which could explain why my BOOTCFG command didn't work.  I pressed the up arrow to retrieve my BOOTCFG command and hit Enter to run that again, just in case.  It failed again.

I typed "exit" and shut down the computer and swapped cables so that maybe this drive would show up as C rather than D.  That merely resurrected the "no such device" GRUB error.  I decided to explore that one for a while.  A search led to some commands that I could have entered, but then I saw a suggestion that maybe I could fix it by just installing Ubuntu, which I had planned to do anyway, and let it sort itself out.  So I went ahead with that, following the Ubuntu installation approach I had worked out previously.  But at this point I only did the initial installation from the CD, and then rebooted to see what the Windows situation was now.  Sadly, I still had the "no such device" error.

I guessed that the problem was that I was using two drives.  One of them had perfectly reasonable Windows and Ubuntu installations on it.  The other had leftovers from some previous Ubuntu installation.  I didn't know for sure, but on that hunch I unplugged the second drive and rebooted.  But no, that gave me the "no such device" error either way, no matter which disk I plugged in.  I plugged in both drives, rebooted with the live CD, and ran System > Administration > GParted to take a look.  Interestingly, it showed that a partition on the second drive was marked as a boot drive, when it should not have been.  I changed that.  It didn't make a difference.

Ultimately, I plugged in a USB drive while booted with the Ubuntu live CD, copied over the data files, wiped both of the drives in the machine, and reinstalled WinXP and Ubuntu, in that order.  That solved the problem.

Installing RAID 0 in Ubuntu 10.04 (Lucid Lynx)

In a previous post, I was working toward having a dual-boot Windows XP and Ubuntu 10.04 system, with a RAID 0 array for at least the Ubuntu installation.  Here, I describe the process I went through to set up that array.  I had previously had a WinXP/Ubuntu dual-boot system on a single Western Digital Velociraptor drive; the main change here is adapting that to the RAID scenario, and seeing whether this would be faster.

I started with a very helpful video by amzertech.  (Actually, two videos.)  I have provided a detailed description of the process (below).  To summarize, I had to boot the alternate Ubuntu CD and use it to install root ("/") and swap partitions on each drive in a RAID format, along with a /boot partition on one drive.

Troubleshooting

It all seemed to go pretty smoothly, and certainly other people seemed to have had good luck with that video.  But when I was done and I tried to boot the system without the CD, I got "error:  no such disk" and then a "grub rescue" prompt.  And in the FastBuild Utility discussed in the previous post, I was no longer seeing two drives configured into one logical disk set; they were back to being two separate JBOD ("just a bunch (or a box) of disks") drives.  So it seemed that what I had done previously was not necessary.

After digging around in a search, I found a post where they said the problem got solved for them by undoing the BIOS edits I described in the previous post.  So I rebooted, hit Del, went into the BIOS > Integrated Peripherals and set the OnChip SATA Controller to Disabled.  This greyed out the other two items that I had changed and put them back into their previous settings.  I saved and rebooted.

This time, I got "DISK BOOT FAILURE, INSERT SYSTEM DISK AND PRESS ENTER."  A search led to a Tom's Hardware thread where they advised, among other things, adjusting the boot order in the BIOS.  So I tried setting the hard drive to boot first, instead of the CDROM drive.  But I got the same error again on reboot.  That thread contained many other suggestions:  update your motherboard's BIOS, make sure all cables are firmly connected, disconnect all other drives, use other software (e.g., Disk Boot Manager), check that the jumpers on your hard drives are set correctly (at least if you're using PATA drives, which I wasn't), fiddle with BIOS settings, etc.

The BIOS update was a possible solution, but I began instead by rearranging cables a couple of times.  My goal there was to match up the hard drive on which I had installed the /boot sector (I didn't know which of the two it was) with the lowest-numbered SATA connector on my motherboard (i.e., SATAII0 as distinct from SATAII1, SATAII2, etc.).  But that didn't do it either; still the DISK BOOT FAILURE message.  I also tried going back into the BIOS and setting Hard Drive as the first, second, and third boot options.

Following some other suggestions, I went back into BIOS and enabled the OnChip SATA Controller as Native IDE type (even though they were SATA drives).  This gave me a new error:  "MBR Error 1.  Press any key to boot from floppy."  I tried reversing the cables, in case I had the drives in the wrong order.  And that did it.  Success!  Ubuntu booted.  I restarted the computer, set the BIOS back to boot first from USB, second from CDROM, and third from hard drive (as it had been previously), and thus verified that the solution seemed to be as follows:  set BIOS to Native IDE type, and make sure the drive with the /boot partition is connected to the first SATA connector on the motherboard.

Assessment

In Ubuntu, I went into Synaptic and installed GParted.  I took a look at what had happened.  I had used two 640GB drives for my RAID 0 array.  In an earlier time, this would have been extravagant.  By now, however, prices on such drives were in the basement.  But I did still wonder if I could use the rest of these drives for some other purpose.  I had allocated an absurdly large 100GB space (50GB per drive) for my root partition -- leaving a total of more than 1TB unused!

So now, in GParted, I saw three drives:  md0, sda, and sdb.  md0 was a net 93GB, with no further information.  sda essentially had the partitions I had set up in the RAID setup process:  the root partition, the /boot partition, the swap partition, and about 540GB left over.  sdb had its own matching root and swap partitions, though they were labeled as having an "unknown" file system, and a matching 540GB unallocated.

More RAID Partitions

Could I use that 1TB of unused space?  I wouldn't have put my data there -- RAID 0 had twice the risk of data loss, in the sense that either drive's failure would take down the array -- but there were some other possibilities.  In particular, I could store my VMware virtual machines (VMs) there, as long as I kept backup copies elsewhere; they would run faster on the RAID array.  And I also wanted to set up a separate /home partition.  But should I have created these partitions while I was going through the initial RAID setup?  And could I store anything on just one hard drive or the other, or did everything on these two drives have to be set up in a RAID format now?

I decided not to research the option of storing things on just one drive or the other at this point.  Apparently it was possible, and could even be done after the fact from within Windows XP.  Since there would be a lot of completely unneeded empty room left over after this RAID installation, I would just let it sit on the drives as unformatted space for the time being.  But for the VMs and anything else (video editing files?) that might call for the performance of RAID 0, I decided that I did want to make use of some of that space.  And I wanted it to be in separate partitions, for backup purposes, not part of the Ubuntu RAID installation mentioned above.  I figured the contents of these partitions would change more frequently and would require a different backup schedule than what the root program installation would need.

RAID 0 Setup:  Detailed Description

So now that I had my BIOS and my drives and everything else in order (above), I restarted the process of setting up the RAID 0 array, and this time I took notes.  I booted the alternate CD and went into Install Ubuntu.  I went through the initial setup options (language, keyboard, etc.).  When it got to the partitioning screen, I chose Manual.  Now I saw that, actually, I didn't have to undo what I had already done.  The 100GB RAID 0 device I had already set up would be just fine.  I could just arrow down to the FREE SPACE items and add stuff there.

So I did that.  For each of the two drives (sda and sdb, on my system), I selected FREE SPACE and hit Enter > Create a new partition > 50 GB (giving me 100GB total) > Continue > Logical > Beginning > "Use as" > "physical volume for RAID."  Then I chose "Done setting up the partition."  Then, back in the Partition Disks screen, arrow up and hit Enter at "Configure software RAID" > Yes.  Next, Create MD device > select the two items shown as 49999MB (i.e., about 50GB) > Continue > Finish.  This put me back at the Partition Disks screen again, but this time I had a new RAID 0 device of 100GB.  I selected that device, hit Enter > Use as > Ext3 (more reliable than Ext4) > Enter.  I set the mount point to /home and the mount options to relatime and labeled it UHOME.  Then I selected and hit Enter on "Done setting up the partition."  I repeated this process, starting by selecting FREE SPACE, and created another pair of 200GB logical partitions that I labeled as RAIDSPACE and set it to mount as /media/RAIDSPACE.  My VMs would go on a folder in this partition.  I still had 700GB left over, but at least I had made a stab at converting some of that unallocated space to a useful form.

I noticed, in this process, that my previous root partition was no longer set as root.  I configured it again.  Now, when I went to Configure software RAID, it seemed that Ubuntu was going to be reinstalled there.  I went ahead with that.  With those changes made in the Partition Disks screen, I arrowed down and selected "Finish partitioning and write changes to disk" and hit Enter.  It gave me an option of formatting the root partition, but since I had already installed Ubuntu there, I didn't want to do that.  This put me into an empty blue screen for a while, but then it began installing the base system.  So maybe I should have let it format the root partition after all.  It went through the installation process and then told me that this seemed to be the only operating system on this computer and asked if it was OK to install the GRUB boot loader to the master boot record.  I said yes.

When it was done, it went into Ubuntu.  I reinstalled GParted and took another look.  It looked like I might have done something wrong.  The only md device was md0, the 93GB partition from before.  It did show the UHOME and RAIDSPACE partitions on sda, with matching Unknown partitions on sdb, all with RAID flags next to them.  Nautilus showed RAIDSPACE as a legitimate partition with 348GB free (19 GB used already!).  But no, everything seemed OK.

Bringing Stuff Over to the New Installation

I shut down the machine, connected a disk containing files from my previous system drive, booted with a live CD, and copied some things over. Specifically, I installed a third hard drive and, while booted with the live CD, used GParted and Nautilus to prepare a partition on it and then copy over all of the files from my previous machine's Windows XP installation.  I tried to copy the /home partition from my previous installation, to replace the contents of the /home partition in the RAID array, but the array was not accessible from a live CD boot.  So I copied the previous /home folder to that newly installed third hard drive.  (I knew that the previous system drive was bootable, so I would not start the system from a hard drive (i.e., without a live CD) while that one was connected, lest it screw up my new installation.)  I got an error message for just one file, a Google Earth file:  "Can't copy special file."  A "special file," according to Andreas Henriksson, was something like a pipe, device node, or socket.  I would be reinstalling Google Earth anyway, so this was no problem.

When those copy operations were done, I disconnected the previous drive and rebooted from the hard drive, this time with an external USB drive connected.  The external drive contained my previous fstab and some other materials that I needed now, as I began to work through the Ubuntu post-installation adjustment process described in another post.

The first step of that process required some adjustment for the RAID situation.  The /home partition in the RAID array wasn't available via live CD.  So I tried the technique of commenting out the regular fstab line for /home and replacing it with a reference to /dev/md2 (where the home partition was to be) and /home_tmp (instead of home).  I typed "sudo mkdir /home_tmp" and then rebooted.  Now, if all went well, the system would think its /home folder was in /home_tmp.  On reboot, I typed "sudo Nautilus," went into /home (not /home_tmp), deleted its "ray" folder (my username), and replaced it with a copy of the "ray" folder from my previous installation.  Then I typed "sudo gedit /etc/fstab," deleted the line referring to /home_tmp, and rebooted.  Then, in sudo Nautilus I deleted /home_tmp and rebooted once more.  All was good:  my settings from the previous setup were back.

I proceeded through the remaining steps to configure my new Ubuntu installation, as described in that other post.  The RAIDSPACE partition was not available to me as a normal user, but I wanted it to be, so I typed "sudo nautilus," right-clicked on RAIDSPACE, and changed its permissions.  Then I copied my VMS from the external drive to a VMS folder in RAIDSPACE.  I was getting an error message on reboot, "Ubuntu is running in low-graphics mode," when it did not seem to be.  Also, I noticed that the GRUB menu was no longer remembering the operating system that it had last used; it was defaulting to Ubuntu in every case.  I was not the only one who had this problem in RAID.  But otherwise, the previous post pretty much covered the adjustments required to get my system back to normal.

As mentioned above, I had copied over the Windows XP files from what used to be my system drive to the third hard drive now installed in this computer.  When I ran "sudo update-grub" to consolidate the changes I had made to the GRUB2 menu while making those adjustments, it said, "Found Microsoft Windows XP Professional on /dev/sdc1."  GParted said that sdc1 was the right place -- it was the NTFS partition to which I had copied those files.  I wondered if just copying WinXP files from one drive to another in Ubuntu was sufficient to create a working WinXP installation in the new location.  So now I rebooted and, in the GRUB2 menu, I chose Windows XP.  And, what do you know, it worked!  Just like that.  No GRUB errors or anything.  I had to adjust a few settings in WinXP, but for the most part things were in good shape.

The Acid Test

So that seemed to pretty much wrap up the process of converting my dual-boot WinXP/Ubuntu system from a single hard drive to a RAID 0 array.  I was sure there would be other changes to come, but it was time for the acid test:  I wanted to see how VMware Workstation performed in the RAID 0 environment.  It had been dragging, functioning very slowly for a long time, in the computer that this one was going to replace.  It had run more quickly on this replacement computer in the single hard drive setup.  No doubt the Velociraptor helped.  But how did it do in the dual drive array?

Let me say, first of all, that the general startup process in Ubuntu was darn snappy.  I noticed it right away.  Boom! my startup programs all came to life pretty smartly.  Inside VMware Workstation, likewise, performance seemed faster than it had been in native WinXP on the Velociraptor.  I was sure there would be much additional learning, but this had been a real step forward.

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.

Windows XP: Unspecified Potential Security Risk Dialog

In Windows XP SP3, I was encountering this message when I right-clicked on a .zip archive file:

Internet Explorer
This page has an unspecified potential security risk.
Would you like to continue? 

It took several tries before I found an approach that worked for me.

One approach:  in Control Panel > Internet Options > Security tab > Local Intranet > Sites > Advanced, add "file://[computername]" using the name of the computer found at Control Panel > System > Computer Name > Change.  So, for example, if your computer was named COMP, you would add file://COMP.  This did not work.

Another approach:  go into the Trusted Sites rather than the Local Intranet, click Default Level, set Allowed Levels to Low, click Sites, and type "\\[computername]" in the Add box.  (Note that you could also get to Internet Options via Start > Run > inetcpl.cpl.")  But this gave me an error:  "Sites added to this zone must use the https:// prefix.  This prefix assures a secure connection."

A third approach:  Start > Run > services.msc > scroll down and double click on Security Center > Startup Type.  Make it Disabled > Stop > Apply > OK.  This did not work.

A fourth approach:  Control Panel > Internet Options > Security tab > Local intranet > Sites > uncheck Automatic and check all three "Include all" boxes.  This worked!

Still another approach, which I didn't try, would involve using the domain name.

Windows XP in VMware Workstation: Default Host Application Error

I was running a Windows XP SP3 guest in VMware Workstation 7.1 on an Ubuntu 10.04 (Lucid Lynx) host.  When I tried to open a PDF file in the VM, I got a Default Host Application error message:

Default Host Application
Make sure the virtual machine's configuration allows the guest to open host applications.

A search for that sentence turned up no hits.  A modified search turned up only a few.  One thread led me to right-click on the PDF and select Open With.  There, for the first time ever, I saw the VMware icon and "Default Host Application" at the top of the list, labeled as the Recommended Program.  I clicked OK, but this put me back to the Default Host Application error message.  I guessed that maybe the problem was that I had already told Ubuntu to use Adobe Reader for Ubuntu (or maybe some other program) to be the default application for PDF files.  I had meant that to apply only when I was in Ubuntu, not when I was in a WinXP VM.  I checked VM > Settings > Options tab > Guest Isolation, and it did not have the box checked to "Enable VM communication interface (VMCI)."  So that seemed to be prohibiting the host (Ubuntu) from using its own default program to open the PDF when I was in the guest (WinXP).

The VMware Workstation 7.1 User's Manual made me wonder whether I had slipped into Unity mode, but I checked Workstation's View menu pick and, no, the setting was Autofit Guest.  I tried Open With again, but this time I browsed to the program that I wanted to use to read PDFs.  At this point, that program was Sumatra PDF.  But after I clicked on the Sumatra PDF .exe file, I was back at the Open With, and it had not remembered what I had just done.  I did it again; same result.  I tried WordPad instead.  It rendered the PDF as what looked like an XML file.  I closed that, went back to right-click > Open With, and this time the VM Default Host Application and WordPad were the only two programs listed.  Still no luck with Sumatra.  Another post made me think this was actually intended behavior, under the concept of "application sharing."  I didn't pursue that at this point.

In Windows Explorer, I went to Tools > Folder Options > File Types, scrolled down to the PDF file type, clicked Change, navigated to Sumatra . . . but still the same result:  it didn't remember what I had selected.  Following a tip, I went to Start > Run > CMD and typed "assoc .pdf."  This told me that the PDF file type was associated with pdf_auto_file.  A corresponding search led to the suggestion to go back into the File Types list, down to PDF, and click on Restore to reset it to the Windows default program for PDFs.  Now it wasn't set to run with anything.  I clicked on Change and navigated to Sumatra again, but it still didn't remember it.

The Microsoft Support page didn't seem to address this situation.  Ramesh, however, did provide an OpenWithAdd utility that added Sumatra to the Open With list.  After that, double-clicking on the PDF file opened the Open With list, with Sumatra PDF highlighted.  I clicked on the "Always use the selected program to open this kind of file" box and then OK.  I killed Sumatra, double-clicked on the PDF again, and this time Sumatra opened right up.  Problem solved!  Another way of doing it, if I hadn't wanted to run the OpenWithAdd utility, was apparently to use this registry edit:

[HKEY_CLASSES_ROOT\.pdf]
@="AcroExch.Document"

When I went to that location in my registry, I saw that it was still set to pdf_auto_file, so I made that change.  I wasn't sure whether that would have eliminated the need for the OpenWithAdd utility.

Windows XP: Integrating the Start Menu with a Portable Apps Tree

I had come up with a tentative list of portable applications to use in Windows XP, and had arranged the program folders for those apps in a tree structure under five main categories:  Multimedia, Online, Productivity, Tools, and Miscellany.  The question for me was, how do I combine that hierarchy with the similar hierarchy that I used for the shortcuts in my Windows XP Start Menu?

That question arose because, if the two weren't combined, I would have to search in two separate places for a program that I wanted to run.  First, I would search my Start Menu; and then, I would search my set of portable apps.  Portable apps were, almost by definition, not ordinarily installed on the computer, and therefore did not tend to create their own shortcuts in the Start Menu.  So unless I created shortcuts for my portable apps (and went through the hassle of keeping the shortcuts up to date with the actual portable apps that I was finding and using), I would have the set of shortcuts installed in the Start Menu by the installed programs, and then I would have the separate set of portable apps.

(There were alternatives.  I had recently seen a program that would let me list the programs that I wanted to run, regardless of where they might be.  But that program hadn't looked very appealing to me.  Even if I didn't absolutely have to have a single set of programs and shortcuts, that was what made sense to me at this point.)

The concept, here, was that I would wind up with a single hierarchical Start Menu that would contain all of the shortcuts to my installed programs, plus all of the program folders for my portable apps.  Obviously, I would not want this to reside on drive C, where all my portable apps would be wiped out whenever I reinstalled Windows.  I had already moved my Start Menu to drive D.

The simple answer, of course, was just do it -- just combine the two, there on drive D.  The result would be relatively portable, as long as the machines where I used it would all use the default locations for program installation.  That is, the portable apps would run wherever -- I would be clicking directly on their executables -- and the shortcuts to installed programs would run too, as long as they were always installed in the same places, so that the shortcuts on my Start Menu could find them.  On machines where some programs weren't installed, or weren't installed in the right places, the shortcuts would simply fail to run.

With this plan in mind, I organized the combined set of portable app program folders and shortcuts into a single tree.  To get the system to see them, I added this to the registry:

; Set locations for Start Menu and special folders
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]
"Start Menu"="D:\\Installation\\Start Menu" 
"Programs"="D:\\Installation\\Start Menu\\Programs"
"Startup"="D:\\Installation\\Start Menu\\Programs\\Startup"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders]
"Start Menu"="D:\\Installation\\Start Menu" 
"Programs"="D:\\Installation\\Start Menu\\Programs"
"Startup"="D:\\Installation\\Start Menu\\Programs\\Startup"
"Administrative Tools"="D:\\Installation\\Start Menu\\Programs\\Miscellany\\Administrative Tools" 

With that registry change, right-clicking on the Start button and choosing Explore would open a copy of Windows Explorer in the new Start Menu location on D.  It did not work that way with right-clicking Start > Explore All Users, though.  That just put me in the traditional Start Menu location (C:\Documents and Settings\All Users\Start Menu).  I also found that additional program installations would put their Start Menu icons in the traditional location, and I would have to move them over to the new location by hand.  So apparently there were still some rough edges to smooth out.

Generally, though, I had the result I wanted.  I had a Start Menu that would not only be preserved on drive D when I reinstalled Windows, but would also be portable.  The programs on it would run on any machine, as long as either (a) they were genuinely portable apps (i.e., I was clicking on their executables) or (b) they were installed in the default locations on the computer where I was using this Start Menu.

Move the Start Menu to a Different Folder

I was using Windows XP.  I had a customized Start Menu.  I didn't want to lose my customizations.  For one thing, I had rearranged shortcuts into categories that made more sense to me (e.g., Multimedia, with subcategories for video, audio, and images).  Also, I had shortcuts to portable programs (i.e., programs that didn't need to be reinstalled, every time I reinstalled Windows).  I had a folder on drive D that was dedicated to portable programs, and each had a link on my Start Menu.  I could wipe out drive C and reinstall Windows, and those programs would still be already installed.  I would just need to create another link to it; and that is one of the steps I wanted to avoid having to re-do.  I wanted to have that link, and its place in my customized Start Menu, already saved.

At first, I tried the approach of just copying my Start Menu from drive C to a backup location on drive D.  My Start Menu was already simplified:  I was the only user of my computer, so I had moved everything from C:\Documents and Settings\[username]\Start Menu to C:\Documents and Settings\All Users\Start Menu.  So I would just copy the consolidated Start Menu from C:\Documents and Settings\All Users\Start Menu to someplace on D.  Then, as soon as I reinstalled Windows, I would copy that start menu back to C.  I would then reinstall my programs (the ones that weren't standalones, already installed and ready to go on D) and would re-sort the start menu shortcuts into my preferred categories.  But now I wanted to go one step further and have those shortcuts already pre-installed too, so basically I would just delete the newly re-created start menu on C and instruct the registry to look automatically to the backup location on D.  So now it wouldn't be a backup anymore; that location on D would be my actual start menu.

I found an indication that the default locations of the Start Menu were specified by Start Menu registry entries at [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\] and at [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\].  Changing these would supposedly change the default location of the Start Menu folder, so that "all subsequent data will be saved at the new location by default."  That was fine, as far as it went, but my registry already had other entries pointing to the old location.  So I thought I would try doing a global search-and-replace.  WinXP's built-in Regedit wouldn't do this, so I needed an alternative.  I started by reading a rather lengthy discussion of freeware registry editors.  Based on that discussion, I decided to try RegEditX.  It seemed I didn't really need the optional (and shareware) Registry Crawler add-in.  I also downloaded RegAlyzer as an alternative.  Other recommended freeware alternatives that I didn't explore or download included RegScanner, Vilma Software Registry Explorer, Regseeker, Resplendent Registrar Registry Manager Lite, and Registrar.

RegEditX's help file described the program as an add-in to Windows's basic Regedit.  It really was Regedit with a few things added.  The first thing I did, in RegEditX, was to export a full copy of the registry, as a backup.  But then I didn't see a global search-and-replace option, or a nifty export-changes option, so I thought I might try RegAlyzer.  It didn't have global search-and-replace either.  But when I did a Find (looking for "\Start Menu"), it ran four hours and still didn't seem to have found anything, whereas Regedit found hits within a few seconds.  I ran it again.  This time it started finding stuff right away; but after the first 15 hits (which it found within a minute or so), it froze at HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\xmlprov.  And there it stayed for another couple of hours.  I verified, in plain old Regedit, that there were indeed occurrences of "\Start Menu" in later registry branches.

Ultimately, I found a simple solution for this problem and incorporated it into a registry script called Mega.reg that I used to make a number of registry changes all at once, as part of a tweaked Windos XP installation.

Ubuntu 10.04 vs. Windows XP: Can't Delete a File

Many Windows users have encountered files that they cannot delete.  I had been able to handle most of those problems pretty easily.  The tools I used were Unlocker, to delete the problem file from within Windows conveniently, and Ubuntu Linux, when Unlocker failed.

I was able to switch to Ubuntu pretty quickly, if necessary.  I was using Ubuntu 10.04 on a dual-boot system.  I had installed VMware Workstation 7.1 in Ubuntu, and had created a virtual machine (VM) running Windows XP SP3 in Workstation.

But in this case, I wasn't having file deletion problems in Windows; I was having file deletion problems in Ubuntu.  Specifically, I was running into difficulties when trying to use an external USB hard drive.  For instance, when I tried to delete a file from the external hard drive, I first got this message:

Cannot move file to trash, do you want to delete immediately?

No problem there, to my knowledge; it was a 2.2GB .avi (i.e., video) file, so maybe it was too big for the trash.  So I clicked Delete.  This gave me "Error while deleting," and when I clicked on "Show more details," I got this:  "Error removing file:  Input/output error."  Similarly, when I tried to move some .avi files manually from the internal hard drive to the external USB drive, I got "Error while copying" and, in the details, "Error opening file [filename]:  Input/output error."

Through a relevant search, I came across a post that made me think I should try to approach this from the Windows side.  That seemed ironic at first, but then I reflected that the target drive was NTFS.  That is, it was formatted for use by Windows.  I wasn't having this problem with my Ubuntu ext3-formatted drives.

So I went into Windows and tried to do the same maneuvers I had just tried in Ubuntu:  connect to the USB drive; delete one file from the external (NTFS) USB drive; move files from an internal (ext3) drive to that external USB drive.  I didn't get too far.  Windows said the folder on the USB drive "is not accessible.  The file or directory is corrupted and unreadable."  Was that what "input/output error" in Ubuntu meant?

I ran Disk Management (Start > Run > diskmgmt.msc), right-clicked on the USB drive > Properties > Tools > Error-checking > click both boxes > Start.  I clicked on out of there and rebooted so that the error check would run.  But this did not repair the drive.  On a second try, I watched more closely.  The VM did reboot, but it did not run a disk check.  Apparently the problem was that the external USB drive did not become connected to the VM until after the operating system had already restarted, by which time it was too late for a disk check.  So I rebooted the VM again, this time with a WinXP installation CD in the CD/DVD drive, and ran CHKDSK /R from the Recovery Console.

CHKDSK ran for a while and then said, "The volume appears to contain one or more unrecoverable problems."  This particular external drive consisted of a hard drive in an external enclosure.  I took the drive out of the enclosure and put it directly in the computer.  This time, CHKDSK ran successfully.  I repeated CHKDSK until it reported no more errors, and then put the drive back in its enclosure.  Now I was able to delete the file.  Problem solved!

VMware Workstation 7.1: No Bootable Device Was Detected

I was using VMware Workstation 7.1 in an Ubuntu 10.04 host.  I had two Windows XP virtual machines (VMs).  One of them would start up and run without a problem.  The other one had done so previously, but was now failing to do so.  Both were pretty basic Windows installations.  There had been some hardware crashes and freezes, due to other system components, and apparently that had screwed up the one that was not starting.

Or so I thought.  I deleted the VM that was not working and recreated it from scratch, with a new WinXP installation in it.  But the problem was still there.  So, OK, I thought, the problem must be with Workstation.  So even though Workstation was still running the other VM without a problem, I uninstalled Workstation.  To do that, I used this command:  "sudo sh /usr/bin/vmware-installer --uninstall-product=vmware-workstation."  Then I reinstalled Workstation, using the same downloaded .bundle file that I had used for previous successful installations.  I opted to keep my configuration files.  Then I opened the two VMs.  Once again, the one VM ran fine; the other did not.

The one that was not functioning properly was proceeding as follows:  first, it would start in a nearly black screen with the VMware logo, as VMs typically did.  But then, instead of starting WinXP, it would take me to a screen that said "Network boot from AMD [number]" and "No boot filename received" and "Operating system not found."  It also flashed a message at the bottom right corner of the screen that said, "No bootable device was detected."

What caused this, I think, was that I was running a disk check from the WinXP CD on the other (working) VM, and then I attempted to start this (nonworking) VM without disabling its access to the CD drive.  So it latched onto the CD and started wanting to do its own disk check too, or something like that, and I killed it in a most awkward fashion, and now it was among the undead.

By process of elimination, the steps taken above seemed to suggest that Workstation's configuration files were holding a grudge against the nonworking VM, or anything bearing its name.  (I had created the new VM from scratch, but had given it the same name as the one that was previously nonworking.)  To test this, I could see what would happen with a new VM with a different name, or I could delete the VMware configuration files when I was reinstalling it.  Taking the easiest step first, I tried just right-clicking on the dud, in Workstation, to rename it.  That didn't work, so since Workstation had been nagging me to upgrade from 7.1.0 to 7.1.1 anyway, I shut down and uninstalled Workstation again, this time including the config files.  I ran "sudo vmware" and configured the program as root, and then I tried to start the nonfunctioning VM.  No dice.  And the other VM still ran.

But now I was aware of an additional difference.  I had saved the other VM in suspended mode, whereas I had shut down the nonworking one altogether.  What would happen if I tried to reboot the one that was still on its feet?  I tried it.  It rebooted fine.  Being in a suspended mode had somehow protected it, maybe.

Trying the other option, I created a new WinXP VM from scratch, but this time I gave it a different name, before deleting the other new (nonworking) one.  But I couldn't.  I got as far as the installation screen that says, "Install operating system from," and it wouldn't let me go any further.  The Next button was greyed out.  But then, duh, I thought maybe that was because I had set the system to not recognize the CD at bootup, not that that quite sense.  Or, I thought, maybe I screwed up the CD drive, or maybe I should do a cold restart.  So, OK, I shut down the computer altogether for 30 seconds, and then fired it back up.  That didn't work.  I killed Workstation.

It occurred to me to insert the WinXP CD back in the drive, setting the CD-ROM to connect at power on, and then start the VM.  That looked like it may have been the solution.  I got the Windows Setup screen, leading to WinXP's Recovery Console.  Evidently something in Ubuntu or Workstation or the VM got the idea that life was not going to be complete until it could lovingly caress that Windows installation CD one last time.  So when Windows Setup was done singing its song, it rebooted on its own and tried restarting the previously nonworking VM.

At this point, I realized I had made a dreadfully stupid mistake.  Although I knew better from previous experience, somehow I had assumed that WinXP was already installed on the VM.  It wasn't, and I think if I hadn't been so bored and burned out on computer stuff by this point, I would have realized that immediately.  What was actually going on was that I was trying to start a VM that did not yet have an operating system loaded on it.  Problems and solutions don't get much more obvious than this.  So anyway, now it was in the process of installing WinXP, as it would have done some time earlier if I'd had the WinXP CD in the drive and had enabled the drive in Workstation before those various reboots.

Portable Applications in Windows XP: Which Ones to Use

I was assembling a list of preferred Windows XP applications.  Part of my goal was to replace installed apps with portable apps where possible.  Doing so had the advantages of getting back up and running much more quickly, whenever I would have to reinstall Windows; reducing system problems due to misbehaving applications; and having my favorite tools available, in my preferred configuration, when I had to use someone else's computer.  With the emergence of cloud computing, among other things, there had been a trend toward the virtualization of applications -- toward, that is, making apps less dependent upon a single piece of hardware.
So now I was engaged in a search for applications that would replace some of those I had traditionally installed on my Windows XP systems.  In my search, I found there were many sources of portable apps, including the categorized and somewhat ranked set in Andrew Lee's Portable Freeware Collection.  I used these sources to supplement and revise the set that I had started with, from PortableApps.com.  It seemed likely that I would continue to add preferred portable apps from various sources indefinitely.  In that sense, this post can only be a step along the way.  Even so, by this time I had accumulated enough applications to say a few things on the subject.

Microsoft Office and Alternatives 

Perhaps the single most important thing to say was that there were substitutes for Microsoft Office.  This was important because it permitted some freedom from dependence upon Microsoft programs.  I had already achieved some such freedom by switching to Ubuntu as my operating system and by running Windows XP within VMware virtual machines (VMs) on Ubuntu/WinXP dual-boot machines.  Through that step, I had multiple alternatives, whenever Microsoft Windows and/or Office failed me:  I could run Microsoft Office, or the freeware OpenOffice alternative, on either Windows or Ubuntu, either natively or virtually.  After that, there were very few times when I was substantially unable to get work done because of some software failure arising from Microsoft software.

The next step in that regard was to move away from treating either Microsoft Windows or Microsoft Office as my primary operating or office system.  Where Windows was concerned, I had recently concluded that the computing world, and I, had not yet come up with a superior end-user alternative for PC-based (as distinct from e.g., Apple) systems.  There were far more, and far more useful, software applications available on Windows than on Ubuntu or other varieties of Linux.  But in the case of Office, it did increasingly appear that there were superior alternatives -- notably OpenOffice.  Then, too, I was among those keyboard-oriented users who were put off by the mouse-oriented ribbon that debuted in Office 2007.  In any event, I had had too many experiences with malfunctioning computer installations that desperately needed to be reinstalled, but that I was currently unable to reinstall because it would take too many hours to install and adjust Office and other heavyweight programs.

The current search for portable apps pushed me further in the direction of seeking an alternative to Microsoft Office.  As described in a separate post, people were struggling with the non-portability of Office 2003 and 2007.  Some pursued the option of downloading a presumably bootleg copy of Microsoft Office that was somehow converted into portable format.  That option (as noted in that other post) entailed considerable risk of viral infection, instability, and inflexibility.  Another option, which I did pursue, was to create my own portable version from my own copy of Office.  That, too, did not turn out well, primarily because the software capable of doing it properly was still too expensive.  Since I considered portability a real benefit, I was thus even more motivated to take seriously the OpenOffice alternative, which was freely available in Windows-based portable form.

Other Top Portable Apps 

Of course, there is more to the world than office productivity software.  A complete set of portable apps must depend on the needs of the individual user.  But it may be possible to select some, from among the estimated 150 categories displayed in the Portable Freeware Collection, from which a typical user might want to draw at least one portable app.

In preparing this list, I excluded many categories that did not interest me and/or in which I was not knowledgeable.  Among these excluded categories (to name a few) were those having to do with iPods, mp3 tags, games, and IM.  Also, in some instances, I took more than one example from a category (especially from categories with grab-bag names like "miscellaneous"), or took something other than the top-ranked program.  I have also used my own category headings, rather those supplied by the PFC website.  In short, this list is offered for purposes of interest, not precision.

Audio and Video

XMedia Recode
Audacity
IrfanView
Duplicate Music Files Finder
VirtualDub Portable
VLC
XBlender

Images, Graphics, Scanning

Photoscape
Dia
Softi FreeOCR

CD/DVD

ImgBurn
Virtual CDRom Control Panel
WinToFlash
Folder2Iso
BonkEnc

Files and Folders

Multi File Tool
7-Zip
TreeSize
Duplicate File Finder
ICE ECC
FreeCommander
FileCommander 
Undelete Plus
Bulk Rename Utility
Index Your Files
Unlocker

Backup and Synchronization

Toucan
FastCopy
ozSync

Downloading, FTP

Free Download Manager
FileZilla
WinHTTrack
uTorrent
VDownloader

Security & Privacy

PortableTor
Blowfish Advanced CS
ClamWin Portable
KeePass
CCleaner
Magical Jelly Bean Keyfinder

Web Browsers

Firefox
Opera
FireTune
Opera Settings Import & Export Tool

PDF

Scan2PDF
Foxit Reader
Swift PDF

Registry Editing

Registry Commander
Regshot
RegFromApp
RegScanner

Remote Collaboration

ShowMyPC
TeamViewer

Bookmarks

TrayURL
AM-DeadLink

Fun & Entertainment

Raindrop
Sumotori Dreams
Wallpaper Randomizer

System Information

SIW 
PC Wizard 
Autoruns

Calendar & Time

Sunbird
TimeSync

General Reference

Convert
WeatherMate

HTML & Text Editing

KompoZer
HTML Portable Editor
Notepad++

Onscreen

ClipX
PNotes
SysExporter
Virtual Magnifying Glass

Phone & Email

Thunderbird
Skype

Math & Statistics

SpeedCrunch
R

Productivity & Desktop Layout

OpenOffice
WinTabber
VirtuaWin

Other

RamBooster
Stalled Printer Repair
EjectUSB
JkDefrag
AutoIt
Don't Sleep
PStart
Scribus
DSpeech

Portable Apps: OpenOffice as an Alternative to Microsoft Office

I was in the process of assembling a set of portable applications to run in Windows XP.  After some investigation and experimentation, I concluded that there was not presently a solid, affordable way of making a portable version of my copy of Microsoft Office 2003.  Since I did want office-type programs in my set of portable apps, I decided to look into alternatives to Office.

One alternative, of course, was to upgrade to a more recent version of Microsoft Office.  In the case of Office 2010, there were (as with Office 2003) various offers of free downloads of a portable version.  Some of these offers seemed to be related to an offer of a free trial that Microsoft had floated in 2009.  Others were apparently pirated versions, typically with little explanation of how the portability had been achieved.  I did not investigate the question of how well these copies would work.

Since acquiring Softricity, Microsoft itself had moved toward developing application virtualization for purposes of facilitating enterprise software installation.  Of course, that was a long way from setting up Office to run from a USB stick.  At this writing, Microsoft's concept of portability was oriented toward portable devices (e.g., phones, laptops).  Office 2010 did come with "portable device rights" in this sense.  There did seem to be one way to install Office 2010 on a USB drive with Microsoft's blessing, more or less:  obtain and install Office 2010 Starter Edition, and then install Starter Edition on a USB drive.  Starter Edition was adware; it replaced Microsoft Works; it consisted solely of limited versions of Word 2010 and Excel 2010; and it was officially available only a preloaded software on purchased computers.  There were ways to download it otherwise.

I had several reasons for not choosing the Microsoft option.  Those reasons included a need for some advanced features, a need for the ability to work with other kinds of files, especially via PowerPoint and Access, a desire to avoid the distraction of adware, and a preference for not being dependent upon Microsoft.  This was not to say that I would avoid using Office 2010 altogether.  I just wanted something that would work effectively on a USB drive.

Another alternative to Office 2010 was to move away from Microsoft altogether, to the extent possible.  There were several apparently significant alternatives to choose from.  The most popular still seemed to be OpenOffice.  The OpenOffice suite continued to have the advantage of being usable on multiple platforms -- so that, for instance, I could still get into a file, via Ubuntu Live CD (or dual boot, or virtual underlayer), even when Microsoft Windows or Office became completely nonfunctional.  OpenOffice also included programs that would work with those varieties of files just mentioned (i.e., Access databases, PowerPoint presentations).

One question, for me, was whether OpenOffice would display the relatively unrefined kind of interface and functionality that had recently prompted me, despite myself, to lean back toward using Windows rather than Ubuntu applications (even if I was doing so primarily in Windows running within a VMware virtual machine on Ubuntu).  If I had ever used OpenOffice in Windows, it had been a long time ago; in recent years I had only used it in Ubuntu, and very infrequently at that.  So now I took another look.  I did a brief trial run of OpenOffice Writer Portable for Windows, running from a hard drive, just to sample its look and feel.  Preliminarily, it looked and felt good -- noticeably better and more familiar than the Ubuntu version, though no doubt the two actually functioned pretty much the same.  On this basis, I decided to go ahead with some efforts toward using OOo (as they call it, short for OpenOffice.org) Writer more frequently.

Portability, another question, was a no-brainer.  The version that I had just sampled was part of the PortableApps.com standard suite.  The concept was that I would set up my full portable suite on the hard drive, so as to avoid having to install programs whenever I set up a new computer or virtual machine, and then I would copy that folder of portable apps to the USB flash drive when I needed to take those tools on the road -- with my laptop or to someone else's computer.  With this concept in mind, I returned to my effort to come up with a good set of portable applications for Windows XP.