HTTP standard (RFC 2616) defines that when a web browser requests something from a website, it should accompany requests with a string, called User-Agent, describing browser components. Each component is expected to have a name, a version and optional comments. The purpose of the user agent string is to allow websites tailor responses for particular browser versions and for statistical analysis of web traffic.
So, most browser publishers came up with user agent strings that identify the browser type, its major components, operating system and user's language.
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.
I always liked Intel's hardware design and documentation. I learned a lot reading 8086, 80286 and 80386 manuals back when they were new and shiny packages of raw power. Even some of the failed Intel's technologies, such as iAPX 432, were a great inspiration for me those days.
Application performance was always a very important topic for me, so I was always interested in software profilers. Microsoft ships a command line profiler with Visual Studio, but it's a very awkward tool and it doesn't work well in multi-threaded environment. I used a few other titles, such as DEC's HiProf or NuMega's TrueTime, but application profilers always suffered from lack of interest from the development crowd and most of them didn't do well.
Naturally, when I got my hands on the Intel's performance analyzer (VTune) in the summer of 2007, I was looking forward to work with another example of Intel's great work.
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?