Joe's Random Ramblings

Earlier this year, Yahoo changed the login protocol for the Yahoo Instant Messaging service.
This resulted in Kopete, the instant messenger tool for KDE, to no longer being able to log into the Yahoo IM service. The background is explained in detail here.
There was a quick fix for KDE 4.x available, but people like me who are using KDE 3.5 and don't think KDE 4 is ready for primetime yet (or who just don't want to change an otherwise perfectly running system), were left out, essentially forcing us to use another IM client, like Pidgin.
Eventually, though, somebody created a patch for KDE 3.5 for Ubuntu, which solves the login issue.
I am using Slackware, not Ubuntu, though, so I used the Slackware build system to create a kdenetwork package for Slackware 12.2 that contains the fixed Kopete.
I used the source code from the Slackware 12.2 DVD, just adding two files in the source/kde/kdenetwork directory: a shell script which applies the patch during the build process, and the patch itself.
The final Slackware 12.2 kdenetwork package is here (12MB.) It can be installed in two steps:

1. Remove the old kdenetwork package: removepkg kdenetwork-3.5.10-i486-2.tgz
2. Install the new kdenetwork package: installpkg kdenetwork-3.5.10-i486-2-yahoo-login.tgz


Update: The ICQ protocol also is broken in the latest kopete for KDE 3.5.
Using the patch from here, I have now created a new Slackware 12.2 kdenetwork package that re-enables both the Yahoo and the ICQ protocols. It is just another patch that gets applied to the normal source package. The resulting binary package, with both patches applied, is here. Similar to the instructions above, it can be installed this way:

1. Remove the old kdenetwork package: removepkg kdenetwork-3.5.10-i486-2.tgz
2. Install the new kdenetwork package: installpkg kdenetwork-3.5.10-i486-2-yahoo-icq-login.tgz


Except where otherwise noted, this content is licensed under a Creative Commons License.

Every techie and a lot of non-techies by now know about the infamous Zune freeze on New Year's Eve, 2008. It's been all over the news, even on mainstream media.
Somebody has now posted the source code of the bug (thanks to Ars Technica for the pointer.)
It actually was a rather simple endless loop.
I think Microsoft's QA should have caught that.

Except where otherwise noted, this content is licensed under a Creative Commons License.

Apple recently seems to have taken a hint from Microsoft, and turns to be evil.
They have sent cease-and-desist letters to people who try to figure out the hash in the iTunesDB database that is part of every iPod.
I have three iPods, a 1st gen Nano, a 2nd gen Nano, and a 2nd gen Shuffle. I am using Linux, and Linux only. iTunes doesn't run on Linux, so I have been using gtkpod to put music on my iPods.
I am ready to buy a 4th gen Nano, but I need to be able to use it under Linux. Apple's strong-arming of independent developers prevents that.
So, I'll be spending my money somewhere else, until Apple comes to its senses. In these economic times, they should be happy that others try to increase the market for their devices, instead of sending in the lawyers...

Except where otherwise noted, this content is licensed under a Creative Commons License.

Some time back, I wrote about problems with the Windows ShellExecute/ShellExecuteEx functions if the filepath is longer than the predefined value of MAX_PATH.
The workaround I described was to use the short path name instead of the long path.
The Windows API has a function for that, GetShortPathName.
However, I recently found out that this function is broken, at least on Vista.
Apparently, the GetShortPathName function doesn't really get the short path by looking at the data on the disk. Instead, it seems to blindly truncate the full directory- and filenames, and appends ~1 at the end of each component. This works by accident on XP, but can result in problems on Vista.
To illustrate: Vista has directories C:\Program Files and C:\ProgramData. The short names of these directories are C:\PROGRA~1 and C:\PROGRA~2, respectively.
Using GetShortPathName on a path that starts with C:\ProgramData\..." results in "C:\PROGRA~1\...", though, as I found out during a debugging session.
This is of course completely unacceptable, and renders the GetShortPathName function unusable.
Typically, the MSDN documentation doesn't say anything about this...
And then MS wonders why they are hated by everybody...

Except where otherwise noted, this content is licensed under a Creative Commons License.

Like a lot of people, we are using VMWare in development to test our programs.
For way too long now, I have been battling with VMWare Workstation 5.5 having a clock that's running way too fast in the guest OS.
VMWare nowadays has some knowledge base articles about it, e.g., here and here.
From these articles, I understand that the problem has to do with the power management on the host machine, which in my case is Windows XP.
There are also several threads in the VMWare forums about this problem, here and here.
I have done what was suggested in these threads, in particular, I have disabled the "Cool & Quiet" setting in the BIOS. Unfortunately, the BIOS for my Dell Dimension E521 doesn't have any way to change the HPET.
Despite all of this, the guest OS still runs too fast when the host machine has been idle for some time (e.g., over night). Since I am trying to run timing tests over night, that's pretty much a killer for me...
I am really wondering why VMWare hasn't fixed this yet.

Update: AMD has what they call a "Dual-Core Optimizer" utility. That finally seems to have solved the problem. I installed it, and kept the VM running over the weekend. And lo and behold, the clock in the VM still runs fine this Monday morning.