Pin Netbeans 6.9 to Windows 7 x64 Taskbar

netbeans-x64-bugIf you try to pin Netbeans 6.9 to the Windows 7 x64 taskbar and have the x64 JDK running, you get a new icon every time Netbeans runs. This is Netbeans bug 178273. The gist is that the netbeans.exe and nbexec.dll which bootstrap netbeans startup are 32-bit native binaries. Netbeans.exe can’t host the 64-bit Java so it copes by launching a child javaw process with a huge list of arguments.


A possible solution would be to create a shortcut to Javaw with all the arguments for Netbeans and pin that to the Taskbar. Unfortunately, the list of arguments is so large that it isn’t possible to create a shortcut directly to javaw passing everything in. The list gets truncated and the shortcut doesn’t work.

A workable solution is to install the 32-bit JDK and make that the default platform for Netbeans. This works but you have to override the installer which prefers to put Netbeans into the x64 Program Files tree and use the x64 JDK if it is detected.


This does solve the problem but it’s not that pretty. The downside here is you have to maintain a second 32-bit JDK. You can still build applications with the x64 JDK but you have to fiddle around with registering the extra x64 platform in Netbeans and you have to reference the correct platform in each project.

SevenBeans Plug-In Does it Better

Jump ListSevenBeans is a Netbeans plugin that improves Netbeans Windows 7 taskbar integration. It adds jumplists, icon overlays and taskbar progress bar for background processes in Netbeans such as updating plugins. It fixes the taskbar integration whether you use the x64 or the x86 JDK

SevenBeans uses a native J7Goodies native DLL for integrating with the Windows 7 taskbar which it extracts  J7G<random-number>.tmp in your Temp directory and dynamically loads. If you are using AppLocker DLL rules, you need to create a per-user white list for C:\Users\<username>\AppData\Local\Temp\J7G*.tmp

Once SevenBeans is installed, launch Netbeans and then pin icon you have after Netbeans is up and running to the taskbar.

SevenBeans is cool and it is much nicer than dealing with an extra JDK installation that I didn’t want.


Boot Camp 3.1.3: Cirrus Audio Update

The Boot Camp update for MacBook Pro (13-inch, Mid 2010) (BootCamp_3.1.3_64-bit.exe) contains Cirrus Audio driver 6.6001.1.25 from 4/28/2010 which is newer than the 6.6001.1.21 version from Boot Camp 3.1. This driver works fine in a 2009 MacBook Pro 15-inch except that the package is set up to refuse to install on anything except the aforementioned new MacBook.

I’ve been having a problem with intermittent pops and crackles on my external speakers that seems to be a software/driver issue, so I wanted to give this update a whirl. So far, it seems like 6.6001.1.25 has fixed my pops and crackles problem.

7-Zip can extract the driver from the packaging. It’s just a matter of digging it out. Inside of Boot Camp_3.1.3_64-bit.exe is BootCampUpdate64.msp (a windows installer patch file). 7-Zip can unpack that into some cryptically named directories. Buried in there is a file called Binary.Cirrus_Audio_Bin which is actually some form of archive. Inside of that thing are the driver files.

Once you have Binary.Cirrus_Audio_Bin unpacked, you can point Device Manager at the unpacked location to update your Cirrus Audio driver.

I’m scratching my head a bit, wondering why Apple didn’t generally release this driver to all compatible hardware.


Fix: “Edit with GIMP” context menu in Windows 7 x64

I can’t remember when it happened but at some point, I lost the “Edit with GIMP” context menu for image files after I started using Windows 7 about a year ago. I just installed the GIMP 2.6.10 x64 version and I noticed that the issue wasn’t fixed. (I had a further problem because the Open With shell magic was broken because the 2.6.10 installer uses a different directory than the 2.6.9 x64 installer did.)

With my context menus thoroughly busted for images, I had a look in the registry. For every sort of image file, there were shell verbs configured. For example, here’s jpeg:

jpegfile\shell\Edit with GIMP]
@="Edit with GIMP"

[HKEY_CLASSES_ROOT\jpegfile\shell\Edit with GIMP\command]
@="\"C:\\Program Files\\GIMP 2\\bin\\gimp-2.6.exe\" \"%1\""

This all looks fine. It’s a custom shell verb called “Edit with GIMP” with the menu label “Edit with GIMP” that invokes the gimp-2.6.1.exe executable, passing the argument of the file name.

Except it doesn’t do anything in Windows 7.

I channeled Mark Russinovich and fired up Sysinternals ProcMon and had a look at what the explorer.exe process is accessing in the registry when I right-click on a jpeg.


It turns out that Explorer isn’t looking at jpegfile or pngfile or giffile et al. It is looking at “image files" as a class via HKCR\SystemFileAssociations\image. Therefore, the solution is to add a custom shell verb there:

[HKEY_CLASSES_ROOT\SystemFileAssociations\image\shell\Edit with GIMP]
@="Edit with GIMP"

[HKEY_CLASSES_ROOT\SystemFileAssociations\image\shell\Edit with GIMP\command]
@="\"C:\\Program Files\\GIMP 2\\bin\\gimp-2.6.exe\" \"%1\""

And success.


%d bloggers like this: