It should be noted that some actions documented herein will likely require elevated privileges. I am always Administrator, so do not typically run into difficulties. If you do not operate as Administrator, you may need to do so in order to successfully accomplish tasks listed in this article.

[ Keep 'Em Separated ]

While developing a Shell Extension, I like to set up a folder that will contain all the files that will ultimately be included in the distributed product. This is never the Visual Studio project’s debug or release folder. Aside from having issues compiling if you have a Shell Extension active in Explorer, you run the risk of having the files deleted by a project “Clean” or just by hand-deleting those folders.

You can place the folder to contain these files anywhere you like, but I like to create one under the target folder (e.g., “C:\Program Files (x86)\…”). This lets me see how the code will behave in its live folder as I develop it.

As I’m developing, I manually copy the build product (the Shell Extension DLL) into the target folder and install it into the running Explorer process from there. This, of course, requires command-line actions, but having a UN*X background, I almost always have a DOS window open all the time.

In any case, you should not use your project debug or release folder as your working folders. You will often find that you will want the in-development Shell Extension active and usable in Explorer while you are also tweaking and re-compiling the project. If you have the Shell Extension found in the project’s debug or release folders installed and active in Explore, your build process will be unable to overwrite it, and you will find yourself performing addition uninstalls each time you want to build again.

[ Adding Your Extension ]

Once you’ve built your working Shell Extension DLL, you’ll need to register it into the Explorer process. Registration is performed using the regsvr32 command-line utility.

regsvr32 /s Associated_x64.dll

This call registers the Shell Extension with Explorer. The “/s” option merely suppresses the GUI confirmation dialog. It may be useful to call regsvr32 without this switch just to confirm that your Extension registered successfully.

It should be noted that this call does not immediately load the Extension DLL into Explorer. Not until the Extension is used does the DLL actually get loaded and locked into Explorer’s process space. For example, a Context Menu Shell Extension would be loaded only when a right-click context menu is activated in Explorer. So, until the DLL is actually loaded for use by Explorer, it can be freely removed by another call to regsvr32 which will unregister it:

regsvr32 /s /u Associated_x64.dll

If your Extension DLL is locked into Explorer’s process space, however, this call to unregister will not completely detach the shared library. It will remain locked in Explorer’s process space. Explorer must be restarted to completely release the shared library. Usually, this is done using a reboot; you’ll often see program installers do this when you uninstall applications that have Extensions locked in Explorer’s process space. With elevated privileges, however, you needn’t be that drastic.

[ Debugging the Bugger ]

Of course, you’ll only be able to actually debug an active Extension if you have a debug build capable of loading into Explorer. This means the shared library can find all of its dependent files, either in it’s working folder, or somewhere along the PATH. How this is configured is left as an exercise for the reader, but your Extension will fail to load into Explorer if any of its dependent files are not locatable by one of these methods.

After a successful registration of your debug build with Explorer, you’ll want to start the process of debugging it. This is accomplished by loading up the Extension project in Visual Studio (it probably already is), and setting break points within the code where you wish the Extension to stop during its execution. With the debug environment prepared, debugging begins when you attach your Visual Studio debugging session to the running Explorer process. This is done by selecting “Attach to Process…” from the Debug menu:

This opens a dialog that lists all the current processes, sorted alphabetically. Locate the “explorer.exe” process, and select “Attach”:

Your debug session is now active. You may now interact with your Extension in the active Explorer, and your breakpoints will hit just as though you were running the Extension as a stand-alone process.

When you are finished, you can simply detach from the running process (terminating your debug session will also work, but may kill the host process.)

[ Reset ]

As I’ve mentioned, once your Extension is loaded into Explorer’s process space, Explorer itself must be terminated in order to release the shared library. Rebooting Windows accomplishes this, but this sort of solution is horribly disruptive to the development work flow. Instead, you can manually terminate and restart Explorer, and in between, unregister your Shell Extension.

I use the following simple batch file to accomplish all these steps in one call:

@echo off
taskkill /F /IM explorer.exe
regsvr32 /s /u %1
start C:\Windows\explorer.exe

The steps simply terminate the running Explorer process, unregister the indicated Shell Extension file, and then restart Explorer. Of course, you will need elevated privileges in order to kill Explorer, so if you do not run with these by default, you may need to modify certain calls (like “taskkill”) with the “runas” option in order to request elevated privileges.

Once the shared library has been removed from Explorer, you are free to overwrite the Extension file with your updated build, and then re-register to star the fun all over again.

Necessity is indeed the mother of invention. Most things you see around you in life are there because somebody one day had a need that the current crop of available tools could not satisfy. Seeing the need, a tool maker then created (and eventually refined) a tool so everybody could get the job done. Of course, one of the really cool things about being a tool maker is that you never have to wait for somebody else to solve your problem.

My “necessity” began with VMware. I tend to use this software often, and I have many associated virtual machines that I maintain. From its GUI, the software provides a menu (called “Windows”) that lists all the recent VMs that you have run. However, the menu seems to be limited to about 10 entries. In addition, in the version I’m using, when you hit that limit, instead of dropping some unused entry to make room, it seems to just forget the VM the next time you run the application instead of adding it to the menu. These two shortcomings alone are enough to drive me crazy, and so came the inspiration for Associated.

[ An Improved MRU List ]

Such menus as VMware’s “Windows” are called MRUs, which stands for “Most Recently Used”. While they are dynamic, adding entries implicitly, they can lack some nicer — or even some sane — features. So, I decided to create an MRU that could be applied to any program that I have installed, not just one that would address the shortcomings in VMware’s interface. To do this, I have created a Windows Shell Extension. A Shell Extension is designed to extend the functionality of the Windows Shell (i.e., Explorer). By utilizing this, I can create MRU functionality that can be provided to any application.

As the name implies, Associated is a Windows Shell Extension that adds a context menu entry that will maintain a list of “associated” elements for any given application. In terms of VMware, this would be a list of associated virtual machines much like that provided by the “Windows” menu within the application. However, as a Shell Extension, I don’t even need to run the application before I select a VM to run from a list. The same can be applied to other applications.

The drawback to this approach, however, is that you must explicitly add entries to your MRU for each application (whereas, within the context of the running application, such features can be implicit). I’ve tried to make this task as easy as possible, and have added some value to the Associated MRU that most application-based MRUs don’t offer.

[ Install The Extension ]

Download the installer for the extension that matches your Windows flavor (32-bit or 64-bit):

• Associated_Win32_installer.exe (1.0)
• Associated_Win64_installer.exe (1.0)

Associated requires at least Windows Vista.

After you’ve installed the extension, your Windows context menu will have a new entry when you right-click on an executable file (or a link object that represents one):

This entry is your new Associated MRU menu. It will present a varying list of associated documents, depending upon the file/link context selected. Of course, immediately after installation, you’ll have yet to add any associations to the database, so your Associated sub-menu will contain only common actions.

The most important of these common actions is the “Settings” action.

[ Filling Your Database ]

You can open the settings for Associated by selecting it from the context menu (or by running it from the Start Menu entry for Associated). When opened for the first time, it will be pretty sparse:

Everything in the settings dialog is managed from context menus. Right-clicking on the blank area of the list will give you the option to add a new application to the database:

You can then use the file-selection dialog to navigate to the application you wish to add, and then select it. As an example, I use the “vmrun.exe” application provided with VMware to launch my virtual machines, so I locate that and select it:

This adds the first entry to the Associated database:

Alternatively, you can quickly add new entries to the database from the context menu. If you select an application that is not already registered, you are given the option to do so by the Associated context menu:

This will open the Settings dialog with the application already added and ready to be configured.

By itself, the application entry will do us little good. We must now add a list of associated files to this application. However, before doing so, we might want to edit default settings for this entry.

[ Adding Some Defaults ]

Right-clicking on the application entry provides a context menu where “Edit Defaults” can be selected:

Default settings allow us to apply values to each associated entry as we add them, to cut down on the amount of typing needed. In the case of my virtual machines, I want to select a folder where they reside (they needn’t all reside there, but in my case, they do), so that each time I add a new association for “vmrun.exe”, it will start me off in that folder.

Additionally, I can add common “Options” that will be filled in for each association (described in more detail later):

With some default values established, we can start adding associations for this application.

[ Adding Associations ]

Select “Add Association” from the application context menu to start selecting associations for your new entry.

This will give you a file-selection dialog box. If you set a path in the defaults for this application entry, then the dialog box should start you in that location (otherwise, it will place you back in the last location where you selected a file). For my example, I navigate to the folder that contains a VM that I want to add as an association, and select it:

This then opens a settings dialog (identical to the “Defaults” for the application) where you can edit information about the association. If you have defaults set for “Name” and/or “Options”, those fields will be filled in automatically. If not, then the base name of the file will be used as the name.

When you are happy with the settings, press “Ok” to add the association to your application entry:

Once you’ve pressed “Ok” on the Settings dialog, the database will be updated, and you will now have an association available to your application when you right-click on it within the Shell:

[ Popularity ]

When your MRU list only contains two or three entries, those entries are all quickly accessible, no matter how often you select them. However, as an MRU list gets rather large, it can be handy to have those entries that are used more frequently than the rest filter to the top so they are the quickest to access and launch. This mechanism is known as “popularity sorting,” or “popularity filtering”.

Associated provides this type of quick-selection mechanism. For example, I’ve completely populated my list of associated VMs, giving me a list of 16 entries:

Notice in the image above that most entries have a popularity rating of zero. There are four entries, however, that have popularity values greater than zero. This represents the number of times those entries have been selected for launching from the Shell context menu. With popularity enabled on the application, context menu entries are presented in descending popularity order.

For example, this same list (shown above in the order they were added) would appear like this on the context menu when popularity is enabled:

You can disable popularity sorting, and the order presented on the context menu will exactly match the order in the settings dialog. In addition, you can reset an individual entry’s popularity rating to zero, or you can reset to zero the entire popularity rating of an application’s association list.

Of course, there are also times when you might not want popularity sorting on your list. For example, Visual Studio uses popularity sorting for its “Recent Projects” list (available on the “Start Page”). This would be a case where I would not want popularity sorting enabled, because I like to keep related solutions grouped together. Since this is a behavior I cannot control from within Visual Studio, I can of course control it from the Associated context menu:

So, no matter how many times I select entries from this menu, they will always remain in this order on the context menu for Visual Studio. Take that, Microsoft!

[ Constructing Options ]

As shown in the “Edit Defaults” image, the “Options” entry can have some odd-looking tokens. These letter tokens represent specific elements of specific values, and are used as placeholders for these values. Each letter token is signaled with a dollar sight (“$”) and is surrounded by a pair of braces (“{}”).

Each letter represents an element of a path, where lower-case letters refer to the path to the associated file, and upper-case letters refer to the path to the application file. Here is the complete list of substitution tokens:

• ${f}…The entire associated path (including file and extension)
• ${F}…The entire application path (including file and extension)
• ${p}…The path to the associated file
• ${P}…The path to the application file
• ${b}…The base associated file name
• ${B}…The base application file name
• ${x}…The associated file extension
• ${X}…The application file extension

In the defaults for “vmrun.exe”, I entered text into the “Options” field that looked like:

The literal text “start” in this example above is an application-defined value; “vmrun.exe” requires and expects it to be the first value it encounters if we are asking it to run a VM. Following that, I’ve added a substitution token that will provide me with the full path to the association file. Note that I’ve enclosed this token in quotation marks in case the path contains things like spaces that would cause the shell to choke.

When editing individual association values, the “Test” button to the right of the “Options” field is enabled. Pressing this button will cause the value in the “Options” field to be interpreted (i.e., tokens will be substituted from currently defined values), and it will display the results so you can ensure that you’ve properly formatted the values. For example:

In most cases, if you need substitution, you’ll be using just the ${f} token surrounded by quotation marks in your “Options”. However, if you leave the “Options” field empty, or there are no substitution tokens detected in the value entered into this field, Associated will automatically append the full path to the associated file to the end of the “Options” value (or as the “Options” value if it is empty).

[ The Rest of the Settings ]

Let’s quickly look at the remainder of the options in “Settings.”

At the top level, right-clicking on an empty area of the list will give you a context menu with these entries:

“Add Application” adds a new application entry to the list. Application entries must be unique; duplicates are not allowed.

“Paste” will appear on this top-level context menu if you have copied an application to the internal clipboard. See below for more detail about copying and pasting.

“Clear List” will clear the entire list of your defined applications (and associations). Be careful with this: It cannot be undone once you press “Ok” on the dialog.

For applications, you’ll get this context menu:

“Add Association” has been covered. You use this to add new file associations to your application.

“Update” is used to change the application to which the entry points. This allows you to switch the application without having to rebuild your list of associations.

“Edit Defaults” has been covered. These defaults help you when adding associations.

“Reset Popularity Rating” will reset the popularity rating values to zero for all currently defined associations of this application.

“Elevated Privileges” should be enabled if the application requires elevated privileges to run. This executes the process with a “runas” verb. If enabled, you may be prompted to enter Administrator credentials in order to successfully launch the application.

“Launch Minimized” will launch the application so that it minimizes to the task bar. Turn this off to launch in a normal window.

“Enable Popularity” turns popularity sorting on or off for the selected application. Popularity counting continues even if popularity sorting is turned off.

“Copy” and “Paste” provide clipboard-like functions for the application. Copying the application makes it available for pasting to a new application entry. Pasting an application will require you to select a new application for the entry (no two entries can point at the same application) and all associated file entries will be copied to the new entry.

“Delete” will delete the application entry, along with all associated files.

For associations, this context menu is available:

“Edit” allows you to edit the settings for this individual association.

“Reset Popularity Rating” is identical to the action for the application, except it will only apply to this association.

“Copy” and “Paste” are also identical to the application, except they only work with the selected association. Pasting the association will add it to the current application context (whether an application is explicitly selected, or an association within an application is selected). Since associations can be duplicated, you can quickly duplicate an association entry for an application by copying and pasting within the same application context. You can also hold down the Ctrl key while dragging an association to make a copy of it.

“Delete” will delete the individual association.

[ Legal ]

Associated uses the Qt Toolkit, which is Copyright © 2011 Nokia
Associated uses icons that are Copyright © 2010-2011 *Remitrom73

All else is Copyright © 2011 Bob Hood

Simply put: Associated is free software. You may use it in any environment you wish, whether commercial or personal, as long as you do so at your own risk. I accept no responsibility, real or imagined, for any damages caused by your usage of my software.

Enjoy.

Recently, I set up a new machine with Windows 7 designed explicitly for use by multiple people. I was tired of my son installing something that ended up on my wife’s desktop, cluttering it to the point where she couldn’t find her software. Of course, this is the result of everybody being an Administrator–installed software gets installed for “All Users” by default. I wanted each user to have the ability to install their own software, separate from anybody else who uses the machine, and only those things that I installed from the actual “Administrator” account to be available to everybody (e.g., printers).

Well, Microsoft’s notion of account control is overly simplified out of the box. There are only two options given to you when you set an account type: Administrator or Standard user. “Administrator” is, of course, the ruler of the machine. There’s pretty much nothing an Administrator cannot do. Of course, it’s a bad account-type choice when you’re letting non-technical people use the machine.

The other option is “Standard.” This would seem like the correct choice for the typical user, someone to whom you could give some control over their own environment without allowing them to affect or damage anybody else’s. However, after much frustration, I discovered this not to be the case. A “Standard” user is intended only to be able to use installed software, not to be able to customize their own environment by installing software. Not acceptable: I needed something with a bit more granularity.

As usual, the functionality I needed was buried a bit deeper. This is what I did to solve this particular problem. If there’s a better solution that I’ve missed, I’d love to hear about it.

[ Microsoft Management Console ]

To configure the permissions in greater detail, you need to access the Microsoft Management Console. You get to this by running the command “mmc” from the Start menu in Windows 7. This will open the Management Console window. For me, it looked like this on the initial run:

In this state, there isn’t much you can do in terms of permissions. From the File menu, select “Add/Remove Snap-in…” (or press Ctrl-M). This brings up another window where the permission settings that will need to be manipulated can be selected and added to the Console. From the Snap-in window, select the “Local Users and Groups” option, and “Add” it.

This will open another window so you can “Choose Target Machine.” It should have the “Local Computer” option selected by default. If not, then make sure that option is selected, press the “Finish” button, and then press “Ok”.

Back at the MMC window, you should now have both “Users” and “Groups” options available that enumerate the accounts and groups that currently reside on your machine.

Selecting the “Groups” tab, you’ll then want to double-click on the “Power Users” option in the list on the right.

This will open the “Power Users Properties” window.

From this window, press the “Add” button. This will open yet another window for adding users to the “Power Users” group.

Hold on. We need to go yet deeper into the oubliette by pressing the “Advanced” button on this panel. This will open the last (I promise) window we’ll need to access, the “Select Users” window. On this window, you’ll want to press the “Find Now” button. This button will cause the list at the bottom of the panel to be filled will all the current Users known to your system.

As pictured, when the list is populated, you’ll want to find the “Everyone” entry, select it, and then press “Ok.” This will take you back to the “Select Users” window, with the object name field filled in with the “Everyone” user.

Again, press “Ok” to return to the “Power User Properties” panel, which will then have the “Everyone” entry in its “Members” list. From here, you can press a final “Ok” to return to the Management Console window with your settings applied.

At this point, you have just added “Everyone” on the machine to the “Power Users” account. This gives them some of the abilities of the Administrator, and in particular, the elevated ability to install software. This does not, however, provide them with the capacity to install software into the privileged directories (e.g., “C:\Program Files (x86)”, and “C:\Program Files” under 64-bit Windows). This is intended behavior in this particular tutorial. I wanted the users to have Administrator-like installation privileges, but don’t want them cluttering up common areas and other users’ desktops. When installing software, each non-Administrator user will need to select an area within which they have read-write permissions (either somewhere under “C:\Users\<login>”, or on some secondary partition, if one is available). This will keep their software modifications only within the domain of their account.

Finally, you will need to save the changes you’ve made to the Management Console session. If you do not do this explicitly from the File menu, closing the window will prompt you to save.

You will need to save this console session in order for your changes to be applied to all the other accounts.

First, I’m not going to cover taking your machine apart and putting it back together — there are plenty of easily found tutorials out there that cover that aspect. Nor will I be covering the removal of the X clamps — again, there are plenty of tutorials out there that provide you with that information. I’m only going to cover the work required on the motherboard, and the final step of super-heating after the machine has been re-assembled. As a pre-cursor, however, in case the tutorials don’t cover it, you will need a Torx screwdriver set in order to fully disassemble the console. I personally use this one from Husky.

Second, if your machine is still under warranty, DO NOT REPAIR IT YOURSELF! You can get your Red Ring of Death fixed for free by Microsoft, and keep your machine’s warranty intact. Contact your Microsoft dealer, or log into your XBox Live account to get the information. If you proceed with opening the case on your XBox 360 while it is under warranty, you will void that warranty.

Please fully read through this entire article before you begin anything, and be aware that I assume no responsibility for any damages or voided warranties that you may cause as a result of following my instructions. You proceed with any instructions contained herein at your own risk.

[ Preparing The Motherboard ]

If you have disassembled your case, removed your motherboard, and removed the heat sinks (having first removed the X clamps), you should be looking at something like this:

In addition, you’ll have your two heat sinks set aside, like this:

You’ll note that the clamp connectors have been removed (arrows). These will be discarded (along with the X clamps), so be sure to remove them from your heat sinks.

Next, you’ll need to clean both the chips (GPU and CPU) and the heat sinks. In the photo above, you can see that I’ve already done the cleaning on the heat sinks. The chips also need to be cleaned as much as possible. I’d recommend you concentrate your cleaning attentions mostly on the top of the chips. You want them to look as clean and polished as possible. There will likely be excess thermal paste around the outside of the chip (this gets squeezed out by the heat sink), and you should try to get as much as you can, but DO NOT ATTEMPT TO FORCE the excess paste off the chip board. There is additional circuitry surrounding the chips, and you don’t want to risk damaging them by trying to remove all the paste.

Here’s a shot of the cleaned chips, ready for re-assembly:

When I clean chips that have had prior thermal paste applied, I first use a strip of hard plastic (cut from something like an old credit or ID card) and scrape as much of the excess paste from the top of the chip, and from the surrounding area (being careful not to use too much force), as I can get. Do not use anything metal to scrape thermal paste. Hard plastic is the best thing to use as it will not scratch the top of the chip, nor do damage to the surrounding circuitry unless you’re really trying to.

I then use a Q-Tip and apply a citrus-based remover (like GOO Gone) to one end of the tip. This I gently rub around the top of the chip, being extra careful not to let any of it get off the top and onto the surrounding area. Letting a citrus-based removal agent interact with the circuit board is probably a really bad idea.

Once I have dislodged/dissolved as much paste as I can, I turn the Q-Tip around and use the dry end to pick up as much from the top of the chip as possible. I won’t get everything, but I want to make sure I don’t have a lake of GOO remover sitting on top of the chip. I then get a cotton ball and put some Isopropyl (“rubbing”) alcohol onto it, the purer, the better (I use 91%, but there are higher ones out there). Using the cotton ball, I rub the top of the chip until I have removed all the remaining solvent and paste. I then let it all dry until there’s no wetness left anywhere.

[ Modifying The Case ]

Because we are going to be replacing the fasteners for the heat sinks, we’re going to need a little more space in the place where the motherboard sits. The holes where the X clamps were secured to the metal case will need to be drilled out so that the heads of the fasteners (see the Re-assembly section below) will rest comfortably without applying any pressure to, or warping, the motherboard.

Using a 23/64″ metal drill bit (a 3/8″ would probably also work, but would make slightly larger holes that might overlap in the center cuts; you can see in the photo below how close those holes are with the 23/64″ bit), I drill out the 8 screw holes that are used to anchor the motherboard (via the X clamps) to the metal case. I typically place the case on top of a wood 2×4, aligning the holes to make sure they are over the wood, and then drill each. After all 8 are done, I use cable cutters and/or a Dremel to reduce any sharp burs or edges.

[ Re-assembly ]

I use the following supplies to re-assemble the heat sinks onto the motherboard. I get all of the hardware from Home Depot for a total cost of around $4US:

• 8x #10-32 x 1/2″ machine screws (round head)

  

• 8x 5/32″ neoprene rubber washers (since they only come in packages of 4, you’ll need two packages)

  

• 12x 5/32″ metal washers

  

• Thermal paste (any good-quality will do)

Apply thermal paste to each of the three chips. Place a dab on each, about the size of a grain of rice, sized appropriately for the chip (e.g., on the smaller GPU chip, place a smaller grain of rice than the larger chips). This is only one of two schools of thought on applying thermal compound. The other advocates spreading the paste as thinly across the top of the chip as you can before applying the heat sink. I used to do this; I don’t anymore. It is far better to let the heat sink spread the paste and fill in any gaps than to have you do it by hand and try (impossibly) to get the paste thin and level.

This next step is a bit tricky, and it has taken me a bit to get it down. You’ll need to align the heat sink on one side of the motherboard while threading the bolts through the motherboard and into the holes on the heat sink, all while keeping the surface of the heat sink as much away from the thermal paste as possible. I tend to situate the motherboard on its edge, holding the heat sink approximately in place with one hand on the chip side while just starting the threading of the fasteners with the other from the bottom. Once each of the fasteners has been started, the heat sink will be properly aligned, and you can then press it down onto the chip, spreading the thermal paste.

While holding the heat sink in place, gradually thread each fastener a little further into place (one or two turns), rotating around to each fastener such that the thermal paste will spread evenly and from the center. As each fastener gets closer to maximum, you want to be sure that you do not over tighten. Let me re-iterate that: DO NOT OVER-TIGHTEN THE FASTENERS. You want the heat sink held securely and evenly in place (the failing of the X clamps), but you don’t want to apply so much tension via the fasteners that you do any warping of the chip or the motherboard. Imagine your goal is to be able to pick up the motherboard by just the heat sink, without it moving at all, and without the fasteners being clamped down to where they will tighten no farther.

Attaching the CPU Heat Sink

Attaching the GPU Heat Sink

Once the heat sinks are securely in place, you are ready to re-assemble your XBox 360. When placing the motherboard back in the case, make sure the heads of the machine screws fit nicely into the holes you drilled in the case. They will not protrude very far, but rather will just have a place for their heads to rest comfortably without pressing on any part of the case.

[ Cook It! ]

With your XBox 360 re-assembled, you are ready for the final phase: Super-heating. This is the so-called “towel trick”, and entails the following:

• Connect power to the XBox 360.
• Using a number of large towels (I use four), wrap the 360 such that all of its ventilation holes are covered.
• Reach inside without dislodging any towels, and power on the 360.
• Leave the machine wrapped and powered for at least 20 minutes.

Yes, this sounds scary. I was apprehensive the first time I did it, keeping my eye on the machine the whole time just to make sure it didn’t burst into flames (or if it did, that I could get the hell outta there fast). But, it does work, with no adverse affects on the machine or the towels.

Once the machine has super heated for at least 20 minutes, you can unwrap it, power it off, and put away the towels. If all has gone well, and the Computer Gods are smiling down upon thee, you can fully connect your console, power it on, and have a working XBox 360 once again.

[ And Finally... ]

The machine pictured in this article was being repaired in real time (while I was writing it). Here it is after being powered on:

Admittedly, this article is targeted to a comparatively small segment of people who own the Zenithink ZT-180, but those who do own one find that its firmware doesn’t automatically come with the Android Market. This issue has been resolved by others (whom I will entirely credit herein). I am writing this article to fill in some gaps that I had to work through on my own through trial-and-error. This will hopefully leave you, the ZT-180 owner, with a clear guide to enabling the Android Market on your device. (And it will leave me with a reminder of what I need to do after I flash the next update. )

Setup

NOTE: Please read the entire article before taking any action. There may be updates you should be aware of appended to the end.

First, if you don’t already have it, download the current Android SDK and unzip it to a location of your choosing. You will also need a current version of the Java JDK installed on your machine. Then, download the RPMScript0.9 (courtesy of rpmccormick’s work [post #604]). This file should be copied into the tools folder of your Android SDK (e.g., [install-path]\android-sdk-windows\tools) and extracted there. This will create a sub-folder called “RPM-addon” that you will use later on.

Next, you’re going to need a Market id for your device. This guide provides details on using an Android 1.6 AVD from the Android SDK to generate a unique Market id for use with your ZT-180. Follow the steps, and write down the id that your AVD generates. You’ll need to provide it in a later step.

Updating the ZT-180

You should flash your ZT-180 device to 0818 (mine was 0803 when it arrived). This archive (courtesy of www.iBeau.net) will provide you with all the files you need to accomplish this, including instructions.

Some notes about the flashing process:

• This will only work with 32-bit Windows systems (I performed my flashing under XP, because it was the only machine I had that was 32-bit).
• Flashing from a 32-bit Windows VM will not work. The first element flashed (uboot) will cause the device to be disconnected, and then subsequent attempts by the flasher to find the device in order to continue the flash will fail. It must be performed from a stand-alone operating system installation.
• You may end up flashing several times while you are working on this, so keep your 32-bit machine handy until you’re satisfied with the results.

Off To Market

Once you’ve flashed your device to 0818, you need to install a couple of files. They are: UniversalAndroot.apk, which gives you the ability to provide root access to applciations; adbWireless.apk, which will allow you to interact with your ZT-180 over your wireless connection using the Android SDK’s adb command.

• Install both applications (from a TF/microSD card, from a USB drive, or by selecting the links above directly from your ZT-180).
• Run the Universal Androot application, and “root” your device. Rooting the device must succeed for you to be able to continue.
• Once you’ve “rooted” your device, reboot (you may not have to do this, but I found that I had to in order to get the next application to run).
• Go into “Settings -> Sound & Display -> Screen Timeout” and change your screen timeout to 10 minutes. This prevents the Android setup screen from timing out while you’re waiting. You can set it back to whatever value you like after you have completed the Android Market setup.
• Make sure your WiFi is connected to the same network as the machine where the Android SDK resides, and then run the adbWireless application.
  • The adbWireless application will start in an active state, but don’t be fooled: it is not really active. You need to turn it off (press the Red button) and then turn it back on again (press the Green button) in order to actually get the adbWireless to function.

Once your device is ready and waiting on the WiFi, open a shell window (command prompt under Windows) and navigate to the location where you extracted the RPMScript0.9 files (e.g., [install-path]\android-sdk-windows\tools\RPM-addon). At this point, you should run the “RPMScript.bat” file found in that folder, and follow the instructions (to the letter) found in rpmccormick’s post for version 0.9 of his script.

Some things to note:

• Your ZT-180 is showing you the IP address of the device while the adbWireless is running. Be sure to use that.
• Typically, I connect to the device before running the script using the command “adb connect <IP>:5555″ command shown by adbWireless, but it is probably not necessary. The RPMScript will connect as one of its steps. How you do it is up to you.
• The RPMScript is broken into two steps. Follow them, along with rpmccormick’s instructions in his post. The first action in each step will likely result in an “error: device not found” message, but you can safely ignore that and move onto the next steps.
• After each reboot, you’ll need to hard reset the device by holding down the power button for 10 seconds to cycle the device off. This is noted in the instructions of the RPMScript after you reboot, but it bears repeating here.
• Since you set your screen time out to 10 minutes, the Android setup screen should not time out, and after the 5 minute wait, you should continue with the instructions.

Sub-step #3 of step #1 of the RPMScript (“Delete unessasary [sic] files…”) will run through your freshly flashed 0818 device and remove currently installed applications. You may or may not want to remove everything it suggests. I chose only to remove a subset of items. Here’s how my step ended up:

Let’s Go Shopping!

After you complete the two-step process, the Market should be available on your device. You need only start it, log into or set up your account, let it synchronize, and then run it again, accepting the terms of service, before you have full access to the Android Market on your Zenithink ZT-180!

UPDATE 9/2/2010: New firmware released for the ZT-180, 0827:

• Improved 1080p video support
• Added support for evdo 3G device

Haven’t flashed this yet, nor attempted a new activation of the market. I will post an update when I do.

There is also an update to RPMScript, RPMScript1.2. As with the new firmware, I have yet to use this, and will include info any differences it may have from 0.9 after I flash the new firmware.

UPDATE 9/4/2010: I flashed my ZT-180 with 0827 using the RPMScript1.2. All went well until I attempted to use the Market. Using the Market gave me an error message “Server unavailable. Please try again later.”. I tried over and over to get it to work, even going so far as to generate a new androidID, thinking that might be the issue, but got the same error when I tried to bring up the market.

However, it turns out not to be an issue with the firmware, but rather a synchronization issue with the Market. Since it had all worked immediately with 0818, I expected the same thing with this firmware, and interpreted this error message as a failure in the process. However, posts from the great guys over at xda-developers (thanks, notsaw!) made me realize that I had to let the tablet sit for a while and the Market would eventually enable itself. I now have the Market working under 0827!

UPDATE 10/31/2010
Here are links to various firmware downloads from my personal server:

0827
0818
0929 System Image (“Christian Buchner” version)
1013 1024×600
1013 1024×576

Credit Where It’s Due

I actually did very little experimentation/exploration this time. I did some cherry picking of steps from a number of places (most notably, the Insanely Mac forums). I give particular credit to Talyn’s post in that forum for giving me the clue to use the ISO image instead of the DMG, and for the Ensoniq audio driver link.

Part 1: Baking the Cake

Here We Go…

Before you begin making any modifications, please read through these instructions at least once, just to make all the steps are clear and that you haven’t missed anything.

Let’s get started:

1. First, get yourself the retail version of Mac OS X 10.6 (Snow Leopard). This will only work with the retail version of the operating system DMG. Use your favorite search site to find the DMG. Since you’ll need to use the ISO version for this tutorial, you might want to find that instead, allowing you to skip the next step.
2. Next, convert the DMG file into an ISO. I used dmg2iso to convert my retail DMG to ISO. If you plan to use a converter other than the one I’m recommending, beware of converters that create ISOs that are considerably smaller than the original DMG. They probably won’t work.
3. Download darwin-wks7.zip and extract its single file, “darwin.iso”. You’ll be using this in a couple of places, so remember where you saved it.
4. Grab vmware-darwin-200.zip, and extract its contents. This will create a folder called “vmware-darwin-200/” that contains all the archive’s files. This distribution will need to be installed into your VMware Workstation 7 directory. Although instructions for installing this are included with the archive, it simply takes a “setup.cmd install” from within the extracted folder to complete. However, before you actually perform the install, you need to copy the “darwin.iso” file you extracted from darwin-wks7.zip into the “vmware-darwin-200/” folder, replacing the file with the same name that is already there. Once the new “darwin.iso” is in place, you may proceed with the install.
5. In VMware Workstation 7, create a new virtual machine. You should use the same settings as those documented in Mac OS X 10.5.6 under VMware 6.5.2. The interface has changed a bit in VMware Workstation 7, so some screen shots will not be exact. However, it doesn’t have to be an exact match, since in this tutorial, instead of altering one or two lines of the resulting VMX file as we did in the Leopard tutorial, we’ll be replacing the contents of the entire file as well.
6. At this point, close Workstation 7. Locate the VMX file that was newly created for your VM; for example, if you named your VM “Mac OS X 10.6″, then the file you’ll want to locate is called “Mac OS X 10.6.vmx”. Open this file in your favorite text editor (not a word processor!), and replace the entire contents of the file with the following text:
   

   .encoding = "windows-1252" config.version = "8" virtualHW.version = "7" maxvcpus = "4" scsi0.present = "TRUE" scsi0.virtualDev = "lsilogic" memsize = "1024" scsi0:0.present = "TRUE" scsi0:0.fileName = "Mac OS X 10.6.vmdk" ide1:0.present = "TRUE" ide1:0.fileName = "M:\SL.iso" ide1:0.deviceType = "cdrom-image" floppy0.startConnected = "FALSE" floppy0.fileName = "" floppy0.autodetect = "TRUE" ethernet0.present = "TRUE" ethernet0.connectionType = "bridged" ethernet0.virtualDev = "e1000" ethernet0.wakeOnPcktRcv = "FALSE" ethernet0.addressType = "generated" usb.present = "TRUE" ehci.present = "TRUE" sound.present = "TRUE" sound.fileName = "-1" sound.autodetect = "TRUE" pciBridge0.present = "TRUE" pciBridge4.present = "TRUE" pciBridge4.virtualDev = "pcieRootPort" pciBridge4.functions = "8" pciBridge5.present = "TRUE" pciBridge5.virtualDev = "pcieRootPort" pciBridge5.functions = "8" pciBridge6.present = "TRUE" pciBridge6.virtualDev = "pcieRootPort" pciBridge6.functions = "8" pciBridge7.present = "TRUE" pciBridge7.virtualDev = "pcieRootPort" pciBridge7.functions = "8" vmci0.present = "TRUE" roamingVM.exitBehavior = "go" displayName = "Mac OS X 10.6" guestOS = "darwin10-64" nvram = "FreeBSD 64-bit.nvram" virtualHW.productCompatibility = "hosted" extendedConfigFile = "FreeBSD 64-bit.vmxf" ethernet0.generatedAddress = "00:0c:29:bd:20:0f" tools.syncTime = "FALSE" uuid.location = "56 4d 88 b8 b2 24 d5 cc-10 76 a6 69 9f cb f9 46" uuid.bios = "56 4d 7d f0 84 2d 67 43-25 a6 19 4f 14 bd 20 0f" cleanShutdown = "FALSE" replay.supported = "TRUE" replay.filename = "" scsi0:0.redo = "" pciBridge0.pciSlotNumber = "17" pciBridge4.pciSlotNumber = "21" pciBridge5.pciSlotNumber = "22" pciBridge6.pciSlotNumber = "23" pciBridge7.pciSlotNumber = "24" scsi0.pciSlotNumber = "16" usb.pciSlotNumber = "32" ethernet0.pciSlotNumber = "33" sound.pciSlotNumber = "34" ehci.pciSlotNumber = "35" vmci0.pciSlotNumber = "36" vmotion.checkpointFBSize = "16777216" ethernet0.generatedAddressOffset = "0" vmci0.id = "347938831" tools.remindInstall = "FALSE" ich7m.present = "TRUE" keyboard.vusb.enable = "TRUE" mouse.vusb.enable = "TRUE" usb:0.present = "TRUE" usb:1.present = "TRUE" usb:1.deviceType = "hub" usb:0.deviceType = "mouse" monitor.virtual_exec = "hardware" monitor.virtual_mmu = "software" ide1:0.startConnected = "TRUE" disable_acceleration = "FALSE" checkpoint.vmState = "" ide1:0.autodetect = "TRUE" vmi.present = "FALSE" smc.present = "FALSE"

   Alter the lines italicized above to match the name you gave to your VM. As you can see in this example, I used the name “Mac OS X 10.6″.

7. Restart Workstation 7, and select the VMX file you just modified. Mount your converted ISO file (the one you converted from the DMG) into the VM using “Use ISO image file” (you’ll see that it is currently pointing to something called “M:\SL.iso“).  Note that this differs from the Leopard tutorial, where we used a logical drive where the iDeneb ISO had been mounted.
8. Check the settings of the VM, and adjust those things that you want. For example, increase or decrease the amount a RAM allocated, the processors accessed, etc. In most cases, you should leave the settings as they are.
9. Power on the VM. If everything went well, you should find yourself prompted to hit “F8″ to enter boot options. Do NOT enter the “Graphics Mode” trick suggested in the Leopard tutorial. Leave the VM to use the resolution it wants for now. The reason for this is that we will be installing the VMware tools into this VM, and setting a Graphics Mode explicitly (either from the boot prompt, or using the /Library/Preferences/SystemConfiguration/com.apple.Boot.plist modification) will hose your VM to the point of making it unusable once the VMware tools are activated. You can enter the “-v” flag it you like (I always do).
10. Once you reach the install screen, follow the same partitioning steps as found in the Leopard tutorial, with this exception: The “Master Boot Record” format must be “GUID Partition Table” for Snow Leopard to function.
11. Apply your partition formatting, and proceed with the installation.

Part 2: Adding the Icing

Now that you’ve gotten Snow Leopard installed (you do have it installed, right?), you’ll want to get some final touches applied. Leave the retail ISO mounted in the VM, and you should be able to reboot at will with no issues.

Here are a few final things to do:

1. Perform an Apple software update; e.g., my retail ISO installed 10.6, but there was an update to 10.6.2 available. Reboot after updates are applied.
2. Download and install the Ensoniq Audio Driver for Snow Leopard. This package will enable audio in the Snow Leopard VM (yay!).
3. Finally, install the VMware Tools distribution. Installing this will give you, among other things, the ability to change the VM’s screen resolution via the OS X System Preferences.
   1. “Eject” the Mac OS X Install CD ROM from within Snow Leopard. This will disconnect the device from the operating system.
   2. While the VM is running, right-click on the CD ROM widget at the bottom-right of the VMware window, opening its pop-up menu:

      

   3. In the “Settings…” panel, mount the “darwin.iso” file (remember where you saved it?) in place of the retail ISO image you used to install Snow Leopard, and press “Ok”.
   4. From the CD ROM pop-up menu once again, select the “Connect” option to connect the device back to the VM. This will mount the “darwin.iso” image into the running Snow Leopard VM:

      

   5. Open the mounted image, and drag the “Install VWware Tools” package to your Snow Leopard desktop to make a copy of it:

      

   6. Unmount the “darwin.iso” image within Snow Leopard, and reverse the process you performed to make it available. Re-select the retail ISO image, and re-connect it.
   7. Install the VMware Tools package, and reboot your Snow Leopard VM.

Part 3: Having a Piece

I must say, compared to the hassle of getting Leopard running in VMware, this was streamlined and painless. The “Holy Grail” now appears to be comfortably situated in the cabinet, along side the other drinking glasses. Running OS X in a virtual machine is no longer a “new frontier.” Now, instead of focusing on the process, you are free to focus on using the product.

Have fun!

I’m currently managing the automated build/test system for my project (the most recent of many hats that I’ve been required to wear during my tenure). We are using Buildbot to manage the builds for three platforms (Windows, Linux, Mac OS X), two architectures (32-bit and 64-bit), and four branches of development (one new product, two branches of a legacy product, and N-number of growing private developer branches). Doing the numbers, and trying to apply the result to six available machines for performing automated builds and test cases, it becomes clear that some level of priority management is needed to ensure the higher-priority builds complete before the lower-priority are serviced.

Buildbot 0.7.10 includes prioritizations based upon the submission time of a build request (Buildbot 0.7.9, the version currently in use on my Buildbot master, doesn’t even provide this). Unfortunately, this level of prioritizing is insufficient to my needs. I need to prioritize the builders themselves, not just the build requests across all builders, so that certain builds will be serviced on the same build slave prior to others. For this reason, I’ve made some slight modifications to the Buildbot 0.7.10 sources in order to add this capability. Herein, I document the changes I’ve made in case you need this ability as well (or care to suggest improvements).

The Master Config

In my Buildbot master.cfg file, I have added a new dictionary item called ‘priority’ to each builder definition.  Priorities of zero (0) have the highest serviceability, with all other positive integers being inversely proportional to their priority (i.e., the larger the number, the increasingly lower its priority).  For example, my builder definitions now look something like this:

b1 = {'name': "TOP_Win32",
      'slavename': "Pyramid_8Core",
      'builddir': "win_32",
      'factory': f1,
      'priority': 0,
     }

b_bob_win = {'name': "TOP_Win64_bob",
             'slavename': "Pyramid_8Core",
             'builddir': "win_64_bob",
             'factory': f_bob_win,
             'priority': 3,
            }

Buildbot Modifications

To accommodate this approach, several small changes need to be made to a number of the Buildbot 0.7.10 files. You’ll need to find these files within your Buildbot 0.7.10 installation. For example, given Python 2.4 under Linux, you might find these files in:

All file references made below will be relative to your active Buildbot installation location.

[ process/builder.py ]

We modify the Builder class in this file to contain priorities set in the builder definition of the master.cfg file. The __init__() method receives this new code (placed anywhere within):

self.priority = 0
if setup.has_key('priority'):
    self.priority = int(setup['priority'])

Further down, in the compareToSetup() method, code is added to deal with changes in the priority setting (for example, when executing “buildbot reconfig master”):

if setup.has_key('priority'):
    if int(setup['priority']) != self.priority:
        diffs.append('priority changed from %d to %d' \
                     % (self.priority, int(setup['priority'])))

The Builder class also requires this simple new method, used in sorting builders by priority:

def getPriority(self):
    return self.priority

[ master.py ]

This file will contain the largest modifications of the two. We are going to enhance the sorting function found in the maybeStartAllBuilds() method. Following the definition of the _sort() function within that method, remove these trailing lines:

builders.sort(cmp=_sortfunc)
for b in builders:
    b.maybeStartBuild()

and replace them with the following code:

builders.sort(key=lambda b: b.getPriority())

priority_high = builders[0].getPriority()
priority_low = builders[-1].getPriority()

sorted_builders = []
while priority_high <= priority_low:
    priority_builders = [b for b in builders if b.getPriority() == priority_high]
    priority_builders.sort(cmp=_sortfunc)
    sorted_builders += priority_builders
    priority_high += 1

for b in sorted_builders:
    b.maybeStartBuild()

Briefly, the replacement code does the following:

• First, the local builders[] list is sorted into priority order, with the highest priority builders at the front, and the lowest priority builders bringing up the rear.
• Next, the priority boundaries are gathered into local variables priority_high and priority_low, and these priorities are used to iterate over the builders[] list.
• Each priority iteration sorts the specific priorities based upon the submission times of their build requests (if any). When complete, the effect is that the builder list is now sorted on two key values, builder priority and build request submission time.
• Finally, the resulting two-key list is iterated over, with the highest-priority builder having the oldest build request at the top of the list, and the lowest-priority builder with the newest build request at the bottom. It should be noted that, regardless of whether or not a builder contains pending build requests, the maybeStartBuild() method needs to be called. This method updates the status display, and failing to call it can leave the Web interface displaying inaccurate information (e.g., the Waterfall can display a “building” status for an “idle” slave).

Wrapping Up

These changes do not go so far as to “abort” active builds based upon priority — in other words, killing builds in progress so that higher-priority builds can use the slave. Such actions can get messy if they are not handled correctly (e.g., the aborted build needs to be re-queued with the same submission time). These changes I’ve provided here only affect “pending” builds, making sure priorities give the next available slave to the more-critical builder with waiting build requests. If a “pending” priority queuing mechanism is too tame for your needs, it shouldn’t take much to modify these changes to make an “abort” priority queue.

So far, these modifications to Buildbot 0.7.10 appear to be working well for my specific situation. They may work as well for you, or you may need something slightly different. In any case, I hope these changes can serve as a starting point for achieving your specific needs. Good luck.

I’m documenting here the steps I followed (many times, just to make sure they worked for me) to achieve a successful Mac OS X 10.5.x install in a VMware Workstation 6.5.2 machine.  There is no sound, but there is networking, which is far more important to me.  If you find a way to get audio working, you might post it here.

Be aware that these steps worked for me, but YMMV.  If you are not successful using them, there’s not much I can do to help you out.  I had to experiment over and over to find these working steps; you will probably have to do the same to overcome your problems.  For the purposes of this tutorial, I’ll be using the file “iDeneb_v1.4_10.5.6.iso”.

Here We Go

1. First, of course, you need to grab the iDeneb 1.4 distribution (Mac OS X 10.5.6).  Google it, or use your favorite torrent search engine.
2. Mount the iDeneb ISO as a drive (using something like UltraISO or Virtual CloneDrive).  Note the drive letter of the DVD.
3. Create a new virtual machine in VMware.  The following sequence of screen grabs should show you all the settings you need to create for the new environment:

	Tell VMware that you will install the operating system later:
	For operating system type, Select “Other”, and then “FreeBSD 64-bit”:
	I named it “10.5″ because I will upgrade from the 10.5.6 on the iDeneb 1.4 image to 10.5.7. You can call it whatever you like, of course:
	Choose the number of processors to let the OS use:
	Allocate an amount of memory to use:
	Unless you know what you’re doing, select “Bridged networking”:
	Drive-type settings:
	Set the space available on the disc. The installation will consume 6-7GB, and the update will consume even more. If you need to do more on the drive, increase that size here:
	Don’t power on the machine yet:

4. Edit the machine settings, and set the CD/DVD drive to use the one that you noted earlier where the iDeneb 1.4 image is mounted:

5. Power on the machine. You’ll want to be sure you click in the window immediately so it captures the mouse/keyboard focus. When prompted to press “F8″ for startup options, press it. Then, at the “boot:” prompt, you can enter options you want for starting the installer. I use the following (‘-v’ means show diagnostic messages; I recommend entering at least that):

6. Now, if you’re lucky, at this point you should boot into the iDeneb installer. When you get to the installation prompt, you’ll want to go to the “Utilities” menu, and launch “Disk Utility”. From this interface, select the VM disc, and then select the “Partition” tab:

7. Create a single-partition layout, leaving the volume type as “Mac OS Extended (Journaled)”. This volume type is important: I was unable to get the VM to boot with any other type:

8. Select the “Options” button, and change the disc to use a “Master Boot Record” partition. The other types failed to work for me:

9. “Apply” your partition settings, and exit the “Disk Utility”.
10. Proceed with the installation, selecting your VM disc as the target partition (it will be the only one, if you followed these instructions).
11. When the installation completes, you’ll be prompted to restart. Do so, but when the machine gets back to the boot prompt, “Stop” it immediately (don’t worry, this won’t harm anything) so that you are back to the VMware desktop and the VM is powered off.
12. Change the “CD/DVD” settings of the VM from the specific iDeneb drive back to “Auto”. DO NOT UNMOUNT THE DVD. You’ll want to leave the iDeneb DVD mounted in the operating system, because it seems to be the only way to allow the VM to actually boot correctly.
13. Shut down VMware.
14. Open the .vmx file of the new iDeneb machine (e.g., “Mac OS X 10.5.vmx”), and find the line that starts with “guestOS”. It should contain the entry “freebsd-64″. Change this to “darwin-64″, and save the file.
15. Re-start VMware, and power on the Mac OS X VM. Let the boot screen time out, and if the gods are smiling down upon you, you will boot into Mac OS X 10.5.6.

Post-installation Booting

Of course, things did not go this smoothly for me.  It took me a couple of boot attempts to get the operating system to come up (boot-hang-kill-repeat).  When it did, I did all the set up stuff, and it took me into the OS X desktop. Once I get everything set up that is boot dependent (like updates and screen resolution), I plan to simply suspend the VM so that I can unmount the iDeneb DVD, and then simply power on the VM whenever I need it.

Screen Resolution

There are two ways to control the screen resolution.  You can enter it at the boot prompt (see the previous image), but this is cumbersome, and can typically lead to a failed boot.  Or, you can change the com.apple.Boot.plist file to make the resolution permament (my preferred approach).  Both approaches require a boot up sequence in order to be successful.  You can read about implementing both approaches here.

Good Luck

If you’ve been looking for a successful way to create a portable Macintosh, I hope this approach works for you. Being a software engineer, it’s really fantastic to be able to carry Linux, Mac OS X, and Vista along with me on a single machine when I’m away from home.

Western Digital My Book Studio Edition II

This little gem is a 2TB external storage system that sports a quadruple interface (including eSATA, which was one of the the reasons I purchased it), and a RAID0 or RAID1 configuration (which is the other reason).  It was my intention to employ the eSATA interface, which is the fastest external interface available, to allow me to seemlessly move between my desktop and notebook environments.  I envisioned accomplishing this by moving all my “volatile” file data, including files in use by running applications, onto the SEII in a RAID1 configuration, having both my desktop and notebook pointing at these files via their local discs using Windows Vista’s new symbolic link support.  In this fashion, I could simply disconnect the SEII from one machine, connect it to the other, and have all my most recent file changes instantly available.

Well, this ambitious undertaking came to fruition.  Running in RAID1, the SEII mirrors my files from one 1TB drive onto the second for safety.  I substituted the application data files and folders (Skype, Firefox, Thunderbird, etc.) on the local HDD with Vista symlinks which redirect to the files on the SEII.  My applications don’t even know that their data files are not where they are being found.  For example, here’s a portion of my application data folder as it looks today:

...
 8/25/2008  21:22         <DIR>    Forte
 4/26/2009  19:14    <SYMLINKD>    G7PS [W:\Users\Administrator\AppData\G7PS]
12/12/2008  10:44         <DIR>    GnuPG
 2/12/2009  12:34         <DIR>    gtk-2.0
 2/22/2009  15:16         <DIR>    HP
 3/20/2008  19:52         <DIR>    Media Center Programs
10/18/2008  16:31         <DIR>    mIRC
 4/11/2009  10:47    <SYMLINKD>    Mozilla [W:\Users\Administrator\AppData\Mozilla]
 2/08/2008  20:04         <DIR>    Nero
 4/11/2009  10:47    <SYMLINKD>    Skype [W:\Users\Administrator\AppData\Skype]
...

Both machines contain the same symlinks pointing at the same locations, so, as long as the external drive is connected and powered on, my environment follows me.

However, a problem surfaced:  The SEII was narcoleptic!  If left too long without any kind of activity, it falls asleep, and if it is asleep for too long, its assigned drive drops off of Windows’ radar.  Now, I’m all for being “green”, but when I have open files on the drive and it decides to take a permanent nap (as far as Windows is concerned), not only do my applications complain loudly, there’s a real likelihood of damaging the file system on the SEII.  This latter disaster has already happened to me once, and I had to run through the resulting “found.000″ folder to try and figure out what files went to the right location.  Of course, I went to the Western Digital site, looking for a solution to this sleeping sickness.  Unfortunately, the impression I got from Western Digital is that it is a programmed behavior, and they are not at all interested in changing it.

Can nothing ever go smoothly?

As I’m fond of telling others, you have to be smarter than the hardware.  Obviously, the firmware in the device is programmed to sleep after a predefined amount of time passes without disc activity.  As long as I’m getting IM’s, or mail is arriving, or I’m browsing the Interwebs, the drive is busy changing files.  However, if some passage of time occurs where nothing happens on the drive (perhaps it’s the weekend and I’m playing an MMO), I can say ‘goodnight’ to my SEII, and the integrity of its file system.  The solution is to keep the device “busy”, even when those things using it are not.  Luckily, I’m a software engineer, and know how to outsmart the hardware.

After trying a few approaches, I lit upon one that so far appears to work.  The device has not fallen asleep on me for nearly a week now, even after letting it sit idle for a few hours while I went to the movies.  The solution is simple enough:  keep it “busy”, without impacting its performance.  The solution I devised takes the form of a Python script:

#!/usr/local/bin/python

import os
import time
import random
import binascii

file_list = []

def path_visitor((files, max),thisdir,nameshere):
    if len(files) >= max:
        # remove all sub-folders from the list to stop any further search
        for name in nameshere:
            full_path = os.path.join(thisdir,name)
            if os.path.isdir(full_path):
                nameshere.remove(name)
        return

    for name in nameshere:
        full_path = os.path.join(thisdir,name)
        if not os.path.isdir(full_path):
            value = random.randint(0, 200000)
            if value >= 199000:
                files.append(full_path)

def calculate_crc32(file):
    crc = 0
    f = open(file, 'rb')
    data = 'bob'

    while len(data) != 0:
        data = f.read(1024*512)
        crc = binascii.crc32(data, crc)

    f.close()

    open('w:\\crc32.txt', 'w').write('0x%08x\n' % (crc & 0xffffffff))

def construct_file_list():
    global file_list

    file_list = []
    os.path.walk('w:\\',path_visitor,(file_list, 1440))

random.seed()

while True:
    if (len(file_list) == 0) or (not os.path.exists(file_list[-1])):
        construct_file_list()

    time.sleep(60)

    calculate_crc32(file_list[-1])
    file_list.pop()

The script initially gathers a list of random files on the device up to a maximum value (I use 1440, because there are that many minutes in 24 hours), and then, at intervals of 1 minute, processes each file, reading it to calculate a CRC32 value, and then writing this value to a small file on the drive’s root partition.  When it runs out of files to process, or when it encounters a file that is now missing from the device, it refreshes its random file cache, and starts again. You can see that I have hard-coded some things (like the drive path, the maximum number of files to cache, etc.), but this is typical for a special-purpose tool like this. Also, the scanning code assumes something about the population of the device (I currently have over 400,000 files on it), so the numbers I use to randomly select files are tuned to give me the 1440 files I want across as wide a sampling of the files on the devices as possible. You’ll likely need to tweak these numbers for your specific situation.

You can run this script manually from a command prompt, and then minimize it to the task bar.  However, I opted to install the script as a Windows service (using srvany).  Once installed, I set the service to run manually, and then created a batch file in my Startup folder that simply calls ‘net start KeepWDS2Alive’ to start the new service whenever I log into my Windows account.  This way, the service (and, thus, the script) is only running when I actually have applications dependent upon the alertness of the SEII.

It is a shame that Western Digital decided that they know what is best for the person who wishes to use their hardware.  If it wasn’t simply arrogance on their part, they could at least explain the hardware requirements that made them decide to hamper this otherwise fine device.  However, software is always the brains of the beast, and if you know how, you can always be smarter than the hardware.

After searching for a solution on other sites, I tried the ‘blacklist’ solution.  This basically involves adding the ‘pcspkr’ kernel module to the blacklist file found in /etc/modprobe.d/blacklist.  This solution did not appear to work for me:  The obnoxiously loud BEEP continued to ring at the login prompt and attract unwanted attention.

If this blacklist solution doesn’t work for you, you can try mine.  My solution?  Simply remove the module manually at boot time.  To accomplish this, edit (as root) your /etc/rc.d/rc.local file and add the following line somewhere within:

modprobe -r pcspkr

It’s just that simple.  This command will remove (-r) the PC Speaker module (pcspkr) from the kernel during boot up, and you will no longer be bothered with the annoying login BEEP!