We bought a new 160 GB Western Digital Scorpio Blue and a 2.5″ SATA -> USB enclosure. I put Norton Ghost on her machine and set off the image, expanding both the C and D drives which were on the disk from their original 40 and 20 GB sizes to 120 and 40 GB respectively.

This took a good few hours as the imager had to re-read all the bad sectors multiple times. After it completed, I swapped out the disks and rebooted. Windows started to boot but NTLDR immediately blue-screened with UNMOUNTABLE BOOT VOLUME.

I re-imaged the disk with Partition Magic, thinking Ghost had messed up, but had the same result.

Now having a disk I was sure had imaged correctly, I booted with Kubuntu Live and ran fdisk. This showed that the disk was showing as 58 GB big, with an invalid partition table.

After using HDAT2 to get low-level info on the disk, it turns out that HPA was active on the disk. HPA – Host Protected Area – is a way of changing the apparent size of a hard disk in order to ‘hide’ a partition at the end of the disk.

I used HDAT2 to remove the HPA flag, and the disk returned to its full size of 160GB.

On the next boot, the problem returned.  Before I explain what happened, the layout of the disk is as follows:

• Partition 0 is a small Dell utility partition
• Partition 1 is Windows XP, NTFS,  C:
• Partition 2 is NTFS D:
• Partition 3 is beyond the HPA, i.e. hidden (normally), containing Dell MediaDirect.

Dell MediaDirect is triggered off a hardware button which we have never pressed, and we assume boots something used to play CDs, MP3s etc.

So the boot sequence for a normal (non MediaDirect) boot on a Dell notebook seems to be:

1. Power on via Power button.
2. MBR/Partition table designates partition 0 (P0) as the boot partition.
3. P0 boots.
4. MediaDirect button is not pressed.
5. Dell loader hides P3 – i.e. sets HPA  active and set to 58 BG to hide it.
6. Dell loader chain boots P1 (Windows XP).

With MediaDirect active:

1. Power on via MediaDirect button.
2. MBR/Partition table designates P0 as the boot partition.
3. P0 boots.
4. MediaDirect is pressed (or has been pressed and flagged in the BIOS).
5. Dell loader unhides P3 by removing HPA (and copies a valid partition table containing P3 in), making the apparent size of the disk the full size (60 GB).
6. Dell loader chain boots P3 (MediaDirect).

When we transplanted the disk, step 5 from the Normal sequence above re-set the disk size to 58 GB, which was in the middle of the new C:, causing the UNMOUNTABLE BOOT VOLUME from Windows – which was correct:  the partition was far too short — it should have been 120 GB.  The truncated partition was (naturally) not a valid NTFS filesystem.

We don’t need MediaDirect at all, so here’s how I solved it:

1. Use HDAT2 to remove the HPA, making the disk appear 160 GB on the next boot.
2. Boot Kubuntu Live from CD immediately.  This is important because if you allow the hard disk boot sequence to commence, it will reset HPA to 58 GB (step 5 from the normal sequence).  If you don’t catch the boot menu in time, and start a boot from disk, reboot and go back to step 1.
3. Use fdisk in linux to delete P0 (Dell utility) and P3 (Dell MediaDirect),  then nominate P1 as the boot partition. Rewrite the partition table.  You can enlarge partitions later using Partition Magic.
4. Boot Windows Repair Mode and run bootcfg /scan to ensure Windows knows about all the Windows installations and fixboot to fix up NTLDR.  I can’t remember if I had to run fixmbr or not – try it without first.
5. Reboot, and Windows should boot from P1.

The problem is, if you don’t know HPA is active (or like me, you didn’t know HPA even existed) you’ll never come up with google search terms to even start to solve the problems.

dd if=/dev/zero of=test.bin bs=1024\*1024 count=4

… creates a file called test.bin (output file) by copying from /dev/zero (input file). Blocksize is 1 MB (1024*1024 bytes), and the count is 4, giving a 4 MB file. Substitute your own values for blocksize and count, and create test files of any length.

There are many different causes of software update issues and it’s often quicker to abandon the update and reinstall. Sometimes I’m chasing milestone revisions, which I prefer to install fresh to avoid any preference store problems.

This procedure below is how I generally bootstrap a new Eclipse install on an existing workspace.

1. Backup your workspace. Make a zip or a 7z file of everything that’s in there, .svn folders and all.  Put this somewhere safe.
2. Backup your Eclipse settings:
   1. File -> Export, then General -> Preferences.
      …to a file on your desktop called eclipse.xml
   2. Check “Export All“
3. Make a note of all the plugins and addons you have installed.
4. Shut down the old Eclipse.
5. Download and unzip the new version of Eclipse to a new folder somewhere.
6. Start up the new Eclipse
   • Do not allow the new eclipse to use your production workspace. Pick a new, empty one.
7. In the new Eclipse, install all the plugins and addons you need. Do a Help -> Check For Updates and let it install any updates.
   • You’ve doing Check For Updates on a weekly basis anyway, right?
8. When you’ve got everything installed, do File -> Import, then General -> Preferences, giving it the eclipse.xml file created in step 2.2.
9. Now restart Eclipse, allowing it to start on your production workspace.
10. You may need to re-apply preferences but generally it should be ok.

This procedure might seem rather long, but in reality it’s very quick and you can usually get back to a productive state in half an hour or less (depending on how many plugins and addons you have installed).

To cut a long story short, there doesn’t seem to be a developer tool in OS X or XCode to spy on these UI events, but you can enable them on individual applications by supplying the -NSTraceEvents YES flag to the binary, which you must start from Terminal.

For example, here’s how you’d start TextEdit and spy on its events.

/Applications/TextEdit.app/Contents/MacOS/TextEdit -NSTraceEvents YES

In my case, I actually only wanted to have the mouse-up events which would trigger the refresh. Here’s how I did it:

/Applications/TextEdit.app/Contents/MacOS/TextEdit -NSTraceEvents YES 2>&1 | grep "Received event.*LMouseUp"

NSTraceEvents outputs the trace to the stderr stream, which is ignored by grep, so the 2>&1 is there to redirect stderr to stdout. The “Received event.*LMouseUp” regular expression selects the mouse-up events from the complete stream.

Result:

2009-10-11 16:56:13.291 TextEdit[29990:903]
Received event: LMouseUp at: 320.0,243.0 time: 199375872740000 flags: 0x100 win: 1832 ctxt: f0df data: 2531,1


The Java 1.5 installation is actually a symbolic link to the Java 1.6 installation. There is a fix available, which essentially entails copying the Java 1.5 installation from a Leopard install, and fixing up the symlinks. It’s available here.

I found this because we have a product which must be linked against Java 1.5, or rather, the JDBC version 3 specification. We don’t yet support all the extended functionality of JDBC 4.

In Eclipse, I had selected Java 5 (= JDBC 3) as the JRE, but was still getting lots of “method unimplemented” errors for JDBC 4 (= Java 6) signatures. These aren’t present in Java 5, so they should not have appeared.

After unfolding the JRE Library node in the Eclipse Package Explorer, it was clear that, although the JRE was reporting itself as Java 5, the jars within were clearly coming from Java 6.

I applied the fix and the compiler errors disappeared – Java 5/JDBC 3 was in use again.

For (my) future reference, here are the JDK / JDBC versions:

• JDK 1.1 → JDBC 1.2
• JDK 1.2 → JDBC 2.1
• JDK 1.4 → JDBC 3
• JDK 1.5 → JDBC 3
• JDK 1.6 → JDBC 4

• Eclipse Visual Studio Presentation – changes the presentation of Eclipse to require rather less height and width and a lot more besides
• Eclipse FullScreen Plugin – adds a context menu and keyboard shortcut (CTRL-ALT-Z) to full-screen Eclipse (covering any menu/taskbars).

Also to consider:

• Is your editor font too big? Can you make it smaller and still be comfortable working with it?
• Look at your window layout – do you have a view docked to the right of the editor – probably Outline? Do you really ever use outline?  Get rid of it if not, or make it a tab in the dock on the left.

Type mismatch: cannot convert from Object to ILocationService.

when it should really have read something like:

Type mismatch: return type of TypeLoader is generic – this project is not.

Here’s what happened to trigger this error.

The type TypeLoader contains a generic method with the following signature:

    public static <T> T loadType( String name, Class<T> forType ) throws TypeLoaderException

My call – which was not in a generic project – looks like this:

        ILocationService ls = TypeLoader.loadType( locationServiceClass, ILocationService.class );

Eclipse’s exception – Cannot convert from Object to ILocationService – is a bit misleading, since there is no cast there: the generic type parameter is defined by ILocationService.class which is of type Class<ILocationService>, and in fact the TypeLoader passes all its JUnit tests.

The solution was that I’d upated the master POM for the project containing the call, but not updated the project in Eclipse (using m2eclipse’s menu Maven > Update Project Configuration. Once I’d done this, m2eclipse updated the source version from 1.4 to 1.6 – and the exception went away.

The general workaround of using OS X defaulting to change that didn’t work with previous versions of Eclipse because the SWT (IBM’s excellent widget set) was built on Carbon, OS X’s “UI Compatibility Library”, which ignored the default.  Eclipse is now available for Mac in a native Cocoa version, which does take the defaulting into account.

Here’s how to change the global OS X tooltip delay (in Terminal):

defaults write -g NSInitialToolTipDelay -int 100

I personally want to keep the 2-second delay for everything except Eclipse, so I applied the default just to Eclipse using the Eclipse bundle name:

defaults write org.eclipse.eclipse NSInitialToolTipDelay -int 100

The delay time is in milliseconds. You might have to log out and back in again to make the default take, but usually restarting Eclipse does the trick.

Nice work IBM!

Eclipse is one of those pieces of software which is rather difficult to explain accurately:  it’s a platform for building GUI applications, it’s written in Java.  It provides lots of services to make writing applications easier.  It’s a pretty good choice for building cross-platform GUI apps.  If you are a Java programmer, chances are that you either work inside Eclipse’s Java Development Tools (JDT) plugins or you’ve at least evaluated the platform.

One of our products runs as a plugin within Eclipse, and overall we’re very happy with the platform.  Lately, though, we’ve been through a refactoring process to split out the core of our product and some of the dependencies.  Coupled with some other fixes, we’ve managed to obtain quite a significant speed increase in how our backend works.

When we came to stress-test the application in order to check it performed under load, we found that instead of an overall increase in speed, we were seeing quite a significant decrease.

To explain this we had to look at the Eclipse job system.  Internally, the Eclipse platform schedules events from the UI (button presses, pending window updates etc.) as jobs.  Corresponding updates to UI elements are also scheduled in the same way.  When a worker thread becomes free, the job manager selects a suitable job (based on priority) and allows it to run.  Ordinarily there are a handfull of jobs in the job queue and they are cleared quickly, and the UI remains responsive.

Our refactoring had produced such a large increase in speed, that the resulting update jobs were flooding the job manager.  After a two-minute stress test, it would take the platform somewhere in the region of 20 seconds (depending on the CPU cycles available) to clear the job queue and return to a responsive state.

We added debugging to show us the size of the job queue, and figures upwards of 3,000 pending jobs were not uncommon.  A single (non-stress) command event telling our backend to do something would generate around 9 internal Eclipse update jobs to update various parts of the UI.  With a suitably high injection speed (which the new code was handling fine), the number of corresponding UI update jobs quickly went through the roof.

The solution, in the end, was uncomplicated:  we throttled the incoming command events (by abandoning some) if the job queue started to get too large. With a suitable throttle value, the backend could be kept busy (but not too busy) without overloading the job manager.

Kudos to my teammate Peter Bailey for doing excellent work on this problem.

This is obviously bad when you have more than a single developer who must sign code.  After beginning the process I found an article at Thawte which says ‘don’t do this on Vista!’, but I also found the Jailbreak util from iSec.  This was able to export the private key with the CSR into a PFX file.  As a test I also re-imported it from the export file and that worked fine.