Word Shoot is reminiscent of Crimsonland's typing mode. Enemies advance at you and, in order to shoot them down, you have the type in the wordsthat show up below them. It's an excellent exercise for fast typing, not to mention a great way to get RSI.

Something's really screwed up with the high score system though; I scored 69,700 on my second game (hard difficulty, 9 missed words - at least 3 of which were because of overlapping enemies). I'm a fairly fast typist, and while I have no problem accepting the concept of people typing faster and/or more accurately than I do, still - 358,620 does not seem to me like an attainable score. I'll give it a couple more tries before I get back to work (we have a regularly scheduled flame throwing every Sunday. And no, I can't remember where that joke comes from).

I just reinstalled my laptop (a long and annoying story which I shall tell some other time), and this time opted for the Intel PROSet/Wireless drivers along with the PROSet/Wireless software suite (the one that replaces the crappy Windows wireless network management applet). It installed fine, the wireless card seemed to work fine but when I tried to start up the Intel application I was horrified.

It was in Hebrew.

Now, I realize that language preferences are a very personal issue, which is exactly why this pisses me off so much: why have ATi, nVidia and Intel all decided that my language of preference is Hebrew? The fact that my Windows is configured for Hebrew support in non-Unicode applications is no bloody excuse - it's that way because a lot legacy (and even new!) Hebrew applications require this setting to work properly. But my Windows is completely in English. Had I wanted localized UIs, I would've installed a localized version of Windows.

In Intel's defense, the translation was very comprehensive and even the RTL issues were sorted out; usually, however, software that supports localized menus have a language option where you can change the default language. The PROSet/Wireless software suite does not, and this time I was pissy enough to do something about it. Solution? Either download and import this registry hack, or do it manually:

1. Start up your favourite registry editor;
2. Go to HKLM\Software\Intel\Wireless;
3. Change the value of InstalledLangId from whatever it is to 0x409 (or 1033 if you're decimal) -- that's the LangId for English;
4. Change the value of InstalledLangShortString to "ENG";
5. Kill the iFramewrk.exe process and restart it (or restart your machine if you're lazy)

All done. I really wish applications would stop deciding for me the language I want to work with.

... from Alex Feinman. Don't ask me why.

In other news, the .NET Compact Framework doesn't decode alpha channels even in bitmaps that has them (well, it might decode the alpha channel, but it doesn't survive a Bitmap.LockBits call - maybe because there's no ImageFormat with alpha...) Still working around that.

Amazon used to be all about simplicity and usability - at least that's what I remember from my last order there, maybe 4 years ago. Now it seems my account is long-since deleted, and I figured I'll just go ahead and create a new one.

To make a long story short, there is absolutely no obvious way of knowing whether or not you're logged on, whether or not your account is active, or anything of the sort. I clicked on "Your Account," got a million different account management options and not even one "You're not logged in, click here to register" or somesuch option.

That, in my book, is very stupid.

You might want to take a look at this post from Omar Shahine. His explanation (excuse? call it whatever you want) for why Windows Mobile will probably never be as good as Blackberry in some respects is honest to the point of being uncanny.

I've often remarked how much I appreciate Raymond Chen's ramblings about the decisions behind some of the more peculiar aspects of Windows. However, where Raymond is uncompromising and unapollogetic (to the point where readers sometimes comment that he is a "douchebag"), Omar is brutally honest but not grounded to the point of being cynical.

I reckon that top management cannot usually afford this sort of uncompromising honesty, but given what is often seen in this industry such an attitude is refreshing even coming from lower rings in the leadership ladder.

To make a long story short, I'm building a trivial query engine over a dataset using XPath; for expressiveness purposes, I've allowed the users of said engine to query for attributes, and assumed that I can simply go up the hierarchy from there and access the elements directly.

I was somewhat dumbfounded to find that each node in the resulting node set had its parentNode property set to null; at first I was sure this has to do with an implementation detail of MSXML3 (perhaps it returns copies of the attributes for... I have no idea what possible gain could be derived from this.) A little more digging proved that, and I quote from MSDN:

In C/C++, IXMLDOMAttribute inherits IXMLDOMNode but are not actually child nodes of the element and are not considered part of the document tree. Attributes are considered members of their associated elements rather than independent and separate. Thus IXMLDOMAttributeparentNode, previousSibling, and nextSibling members have the value Null.

Working under the assumption that this is an MSXML3-only problem, I digged a bit into the W3C DOM specification only to find that it is, in fact, a specification issue:

Attr objects inherit the Node interface, but since they are not actually child nodes of the element they describe, the DOM does not consider them part of the document tree. Thus, the Node attributes parentNode, previousSibling, and nextSibling have a null value for Attr objects. The DOM takes the view that attributes are properties of elements rather than having a separate identity from the elements they are associated with; this should make it more efficient to implement such features as default attributes associated with all elements of a given type.

This seems to me a completely arbitrary design decision. It makes absolutely no sense to inherit from what at first glance is an interface for first-class citizens in the document (Node) and then castrate the interface with useless implementations. If, contractually speaking, attributes never have siblings or parents, then they shouldn't have those properties at all, otherwise this just frustrates the developers wishing to make use of those properties, and wastes their time by forcing them to dig through documentation to figure out what's wrong.

And on top of it all, the decision doesn't even make sense in light of the "efficiency" claim - how is it more efficient to partially implement an interface, instead of defining a new one that's more contractually sound?

Quick link: To download the wrapper classes click here

While working on a large application targetting the .NET Compact Framework 2.0 I realized that I'll need to feed some native code (specifically, the XSLT processor in MSXML 3.0 SP1) with an IStream implementation.

Articles about interoperating with unmanaged code in the CF are not exactly abundant; to save you the time I spent on incorrect and/or conflicting research, here's the bottom line:

• There is no Managed C/C++ for .NET Compact Framework 2.0. To some this may be old news, but you should really pay attention to this point if you're going to do any serious development against CF. 2.0 adds support for managed COM/ActiveX interop, but otherwise you're completely stuck with P/Invoke.
• Although it's not immediately obvious, CF 2.0 does support exposing managed classes via COM.
• The CF is missing some usually-minor classes from the BCL; in this case I was missing System.Runtime.InteropServices.ComTypes.IStream. Annoying but easy to work around.
• Finally, as an aside, MSXML 3.0 SP1 for Windows Mobile does not support the IXslTemplate and IXslProcessor interfaces, meaning that MSXML 3.0's already lackluster performance in XSLT transformations is further hindered by not being able to cache the interpreted stylesheets. This means that, if you use XSLT, your application will not scale. I was not initially aware of this issue, so I hope our data sets are small enough to handle this, or I may yet come to regret the decision to use XSLT in this project.

I managed to save quite a bit of time by leveraging Oliver Sturm's work, which was originally intended for the desktop. Since the CF is missing a whole bunch of minor classes, the managed definition of IStream included, I originally mucked about with midl trying to generate these definitions from the .IDL files. After this proved to be a genuine chore, I just ripped the definitions straight out of the .NET Framework 2.0 assemblies with the ever-useful Reflector.

You can download the class file here. If you use this it would really be cool if you could drop me an e-mail, and I bet Oliver would be equally appreciative. Enjoy!

God knows I give the guys at JetBrains a lot of credit, but I didn't see this coming: according tot he Omea News feed, Omea Pro is being open sourced!

For those of you not in the know, Omea Reader is JetBrains' RSS, newsgroup, e-mail etc. aggregator. It's a pretty amibitious application that I've been using for quite a while now instead of RSSOwl (Omea's interface is smoother, although RSSOwl definitely has its moments), although in reality I only use about 10% of its capabilities - newsgroups and RSS feeds.

I was about to buy Omea Pro this week and am now feeling really awkward that I can download it for free instead; the least I can do is spread the word. I suggest you take a serious look at it, because the non-Pro Omea Reader is already a very formidable product.

Update: Seems to work fine now, please let me know by e-mail if there are any problems (tomer at tomergabel dot com).

Apparently there is some sort of problem with the comment system, and it breaks in at least one case. I'm working on the problem, in the meantime feel free to use any of the other methods of contacting me if you need to.

As I mentioned before, I've had well over 300 trackback/pingback spam notifications from dasBlog. Since this was well beyond what I was willing to mess with by hand, I whipped up a quick Outlook macro to do the work for me:

Sub DeleteTrackback()
    Dim oSel As Outlook.Selection
    Dim oItem As Outlook.MailItem
    
    Dim oShell
    Set oShell = CreateObject("Shell.Application")

    Set oSel = Application.ActiveExplorer.Selection
    For x = 1 To oSel.Count
        Set oItem = oSel.Item(x)
        
        If (Left(oItem.Subject, 19) = "Weblog trackback by") Or _
           (Left(oItem.Subject, 18) = "Weblog pingback by") Then
            Index = InStr(1, oItem.Body, "Delete Trackback:")
            If (Index <> 0) Then
                URL = Mid(oItem.Body, Index + 18)
                URL = Left(URL, Len(URL) - 1)
                
                oShell.ShellExecute URL, "", "", "open", 1
            End If
        End If
        
    Next
End Sub

To use this macro, create a new macro and paste the source code; then select all the "Trackback/Pingback" notifications messages and run the macro. It could obviously be customized to work on entire folders or whatever, but that I leave to you. One final suggestion: if you (like me) keep a 15-tab Firefox window open at all times, you may want to open a new window (not tab, window!) so that you can then close all the URLs at once.