Windows 7: The INSTALL Partition

For a long time, probably since the 1980s, I had kept my Windows installation on drive C and my data on drive D.  (Drives, or partitions of drives, can be readily created within Windows 7 and also by partition manager programs.  GParted, included in the downloadable Ubuntu CD, has been the most reliable partitioning programs for my purposes in recent years.)

Having the data on drive D had several advantages.  One was that I could back up drives C and D on different schedules.  Once I got a good Windows installation set up on drive C, I didn't need to back it up very often.  I'd just make a drive image (using Acronis True Image in the past few years), and I'd make an updated image backup just when I had done some significant new program installation or adjustment.  By contrast, I would want to back up my data on drive D on at least a daily basis.  Of course, when I made the image of drive C, I would need someplace to put it other than drive C.  An external drive was a possibility, assuming the bootable CD would recognize it, but it would tend to be slower, and this would be complete downtime, when it would not be possible to do other work.  It worked the other way, too:  having the data on a separate partition meant that I could completely reinstall Windows without affecting or even worrying about my data.

There were exceptions to that last statement.  Some program configurations were so detailed, time-consuming, and/or oft-changing as to constitute a sort of data.  Not the kind of data I was supposed to be working on, but data nonetheless.  An example:  Firefox add-ons.  It could take a half-hour or more to find, install, and configure my Firefox add-ons after doing a new Windows installation.  Some add-ons allowed me to export my saved settings, but obviously I would not want to store those on drive C; they'd be wiped out if I reinstalled Windows sometime down the line.

I also found it was handy to keep a local copy of the programs that I would install in Windows, after installing the Windows operating system itself.  I did not want to have to re-download all those programs and re-invent all of the things I had previously figured out about installing them.  So instead I had folders containing the programs to install, with installation notes in accompanying text files, and I named the folders in such a way as to guide me in the installation sequence that worked best (e.g., "01 Motherboard Drivers").  There were also quite a few program installers that I tried and uninstalled, or hadn't gotten around to installing.  Also, some ISOs -- ready-to-burn CD images that I had downloaded but hadn't burned to CD, or wanted to keep because it was a hassle to re-download a 700MB image.  I had collected these sorts of things, not only for Windows, but also for Ubuntu.

I accumulated about 75GB of this stuff.  Keeping it all on drive D meant that my daily data backups were swelling up with all this material that didn't need to be backed up every day.  So at some point I moved a bunch of it over to its own partition, with occasional backups.  What I kept on drive D was mostly stuff that I was actually using in my current installation.  One example:  those Firefox settings files.

Sometime in the late 1990s, I discovered that I could move my Start Menu to drive D.  This would have the advantages mentioned above, including especially the fact that my custom-arranged Start Menu (top-level folders:  Productivity, Online, Multimedia, Tools, Startup, Miscellany) would not have to be rearranged each time I installed Windows.  As long as I installed everything in its default installation location, the shortcuts in the Start Menu would come back to life as soon as I reinstalled the target program where the shortcut expected to find it.

A few months before writing this post, I came to realize that, of course, I could also install my portable applications in the Start Menu.  This would be ungainly in the sense that a bottom-level folder in the Start Menu might contain a slew of program files instead of a nice, orderly collection of shortcuts.  But it was handy for keeping everything that ran in one place, where I could copy it to a jump drive and use considerable parts of it on any other Windows machine.  The Start Menu, wherever located, could also be accessed and synchronized on a network, so that I only needed to configure the Start Menu once and would then have it available for any computer I would attach to my home network.  (Making it available did require a registry tweak.)

Putting the portable applications in the Start Menu had an unwanted side effect.  Many portable apps (especially those coordinated by PortableApps.com) used many of the same program files.  That was a problem because I liked to use DoubleKiller to delete duplicate files on drive D.  I couldn't do that anymore, at this point, because it would detect tons of duplicative portable program files that were supposed to be there.  I looked for a different duplicate remover, one that would allow me to exclude folders like the Start Menu folder, but ultimately decided to stay with DoubleKiller for now.  The reason was that I did not want to risk that, one fine day, I would forget to exclude the Start Menu from a DoubleKiller sweep, and (although this was unlikely) would punch the wrong button and delete that Start Menu from my hard drive.

What I decided to do, instead, was to move the Start Menu so that it would join those other program files -- programs to be installed, etc. -- in their own partition.  I called it INSTALL and gave it a letter of W, so that its location would not be affected by the connecting and disconnecting of various USB drives and whatnot.  So then hopefully the shortcuts in it would stay in place, and would require no further adjustment forever and ever.

Right now, unfortunately, they did require adjustment.  I modified the registry tweak to point toward drive W:\Start Menu rather than D:\Installation\Start Menu.  This caused almost no problems.  The main issue was just that a bunch of shortcuts were now dysfunctional, in that they pointed at executable files on D that were now on W.  I ran Glary Registry Repair 3.3.  It identified 165 new registry errors.  As I scrolled down the list, I noticed that a huge number of the problems identified by Glary were links to IrfanView on D.  I considered doing a global registry search and replace for the IrfanView location -- or, indeed, for all references, changing them from D to W, perhaps with the aid of a global registry search-and-replace tool like Registry Toolkit ($25) or Registry Replacer ($15) or Replace Registry Values (free).  But then I decided it might be safer to let Glary fix those dud links and then do a search in a registry editor for any remaining references to D:\Installation|Start Menu.  I used O&O RegEditor to do that search.  I was now down to a total of just 29 registry references to D:\Installation\Start Menu.  I was going to edit them in O&O, but then decided not to.  As long as they weren't hurting me, I was better off just leaving them alone.  One ill-advised registry edit could cost me an hour or more for recover or restoration.

So this was pretty much the end of the project, aside from some continuing cleanup, correction of shortcuts, etc.  I now had an INSTALL partition, labeled as drive W, containing my customized, shared Start Menu and installers for various programs.  I could now run DoubleKiller on drive D without worrying that it might knock out program files, and without having to do manual exclusions to focus it on the data duplicates that I was seeking.

Using Ubuntu Linux Tools on a Windows Machine

I was using Windows XP SP3 on one machine and Ubuntu 10.04 (Lucid Lynx) on another.  There were times when I found that Ubuntu (my preferred version of the Linux operating system) could do things that Windows could not.  For example, Ubuntu was much faster and cleaner at moving large numbers of files from one folder to another.  It could also delete files and folders that Windows said could not be deleted.  So I wondered if there was a way to use Ubuntu tools on a Windows installation.  This post discusses that question.

One solution that I already knew about was to set up a dual-boot machine, with Windows XP and Ubuntu coexisting side-by-side.  If you wanted to do something in Ubuntu, you could just shut down Windows and reboot into Ubunt.  This wasn't always the world's most convenient approach.

Another solution that I was currently using was to use both of them together via virtualization.  The virtualization tool I had been using was VMware Workstation.  The way it worked for me was that I installed Ubuntu as my base layer, installed VMware Workstation in Ubuntu, and then installed Windows XP in a virtual (i.e., make-believe) "computer" inside Workstation.  So if I was working in Windows and had something I wanted to do in Ubuntu, I could just go out of the Windows virtual machine for a moment, do my thing in Ubuntu, and then resume work in Windows.  I have written lots of posts on this combination.

A different approach, for those who didn't mind rebooting and didn't want to install Ubuntu or VMware on their Windows machines, was to use an Ubuntu Live CD.  In this approach, you wouldn't reboot into an Ubuntu installation that was already present on your hard drive; you would reboot into an Ubuntu installation that was self-contained on a CD.  The CD image was free, and could easily be downloaded and burned to a CD.  It would be necessary to adjust the BIOS settings (typically, by hitting Del or perhaps F2 while the computer was booting) so as to set the CD (or DVD) drive to be the first in the boot sequence, so that the computer would try to boot from a CD (if you had inserted one into the computer) before moving on to the option of booting from your Windows installation on the hard drive.  Assuming your computer supported it (and most did, by this point), it was also possible to boot Ubuntu from a USB drive instead of a CD.

Those approaches were all familiar to me.  Two other approaches or variations were not.  The first was to use an Ubuntu live CD or USB stick, but to customize it to include Ubuntu programs that were not included on the standard Live CD.  Among the various ways of doing this, two that seemed to draw frequent attention were Reconstructor and Remastersys.  A recent post made it sound like Reconstructor was especially easy to use.  Among other possibilities, these tools would apparently allow the user to create a bootable CD or USB stick that would contain the user's own customized Ubuntu installation.

There seemed to be an endless number of variations and possibilities, some of which would require a lot of work and/or would not work well.  The last one mentioned here involved running Ubuntu, or something like it, on a Windows installation.  In essence, Ubuntu in this approach would function like just another Windows application.  As such, it would tend to be limited by the things that Windows could do.  Portable Ubuntu Tres was a recent example of this approach.

These possible approaches suggested two steps I could take, as described in more detail in separate posts.  One was to update my knowledge of virtualization alternatives to VMware Workstation.  It had been a year since I had last reviewed that topic, and I did not know whether there had perhaps been developments that would give me a superior alternative to VMware.  The other was to try my hand at burning a custom live Ubuntu DVD via Reconstructor or Remastersys.