I finally have converted to XBox-360 and picked up a copy of Halo3 about a month ago. I was looking forward to playing this game since the first Halo, which was one of the greatest games I played. I didn't buy the first one, renting it at Blockbuster again and again, so when second one came out, I decided save some money and buy the game.

A couple of days ago I got an email from Human Resources. No company name. The subject suggested phishing - RIM: Important information about your application at Research in Motion. I looked at the SMTP source before opening the message and saw the usual phishing email - your account has been updated, please go ahead and reset the password, etc, etc.

The return address was RIM_Do_Not_Reply@invalidemail.com, which is not RIM's domain name and further confirmed the nature of this email. The email addressed me by name and provided a link to rim.taleo.net to reset the password. Temporary numeric user name and password were provided and there was a base64-encoded HTML file named current_email_in_html.html. A text-book phishing email.

A few users notified me that SSW won't run on some of the AMD and Intel processors. After looking at the crash dump submitted by one user, I figured that the culprit was one of the SSE2 instructions, like this one:

movsd   xmm0,mmword ptr [webalizer!_real (0045e290)]

I decided to make a special build, so that people can run SSW on older architectures and spent some time last weekend creating new build configurations. Once I was done, I wanted to check how much slower SSW would run with SSE2 disabled and ran a small test.

Build configuration in Visual C++ offers a great deal of control over what is being built and how. Some of the greatest things, just to name a few, include separate configurations for 32-bit and 64-bit platforms, property sheets allowing dozens of configurations to be updated in one place, the UI that allows one to select multiple projects by holding down the Ctrl key and set common properties for a bunch of projects, separate solution and project configurations, etc, etc, etc.

One would think that having such elaborate build system, C# would actually build on it and make it even better. After all, it's a new language designed without the backward compatibility baggage. In reality, though, it is no so much so. It's as if the Visual Basic team was reoriented and designed the C# build system.

Well, it happened again - the hard drive in my good old RedHat machine got corrupted. Strangely enough, previous failures also ocurred around this time in the previous few years. One of the failures was so bad that I had to buy hard drive recovery software to salvage my CVS repository. This time it seems there are 220+ bad blocks (about 1MB, at 4K/block), but most of the content is still accessible, although I still don't know the extent of the damage.

I have to say that I miss Windows' chkdsk, which not only reports bad blocks, but also the names of files or directories affected by the damaged blocks. e2fsck, on the other hand, comes up with pretty cryptic messages, such as "Attempt to read block from filesystem resulted in short read" or "...Force rewrite(y)?". I'm also more careful this time and so far haven't allowed e2fsck to auto-fix the partition - the last time I did this, it cost me the entire hard drive.

Long time ago, somebody at Microsoft gazed into the future and they saw that some day we will have the need for a 64-bit OS. They were smart people and they thought that it would be easier if the system directory would reflect the kind of system binaries it would keep and created a directory called c:\windows\system32\. You know, for the 32-bit binaries. The new subsystem was called appropriately - Win32 and so were some of the system files - regsvr32.exe, kernel32.dll, user32.dll, etc, etc, etc.

Years flew by and that future they saw has arrived on the wings of Intel and AMD architecture and it was the time to reap the benefits of the smart choice made long ago. Right?