I was working with a quite old inherited virtual machine today (VMs have a nasty habit of getting old and unpatched), and I needed to have SP2 (actually XP SP3 is out now) on it (to install SQL Express, among other things).

The problem was, this VM had a installation of XP, no service packs, using a product key who’s ancestry was, shall we say, questionable, at best.

Of course, I have several valid product keys from MSDN subscriptions, so I’m completely legit. But I needed to get this VM squared up so I could get products installed on it.

In the past, I’ve used a technique I found online whereby you edit a registry entry to invalidate your current activation (and thus force Windows to want to reactivate itself), then you run the msoobe.exe application with a certain command line to relaunch the activation process. Not to hard, but it didn’t work with my legitimate WinXP product keys. I have no idea why not, and there was nothing in any of the messages to indicate what was wrong.

Then I happened across a link to the Windows Product Key Update Tool.

A quick download and it worked perfectly. It properly accepted the product key for XP from my MSDN subscription, updated Windows and reactivated it straight away.

Certainly, a very handy tool to have in the stable!

One thing that has definitely taken some getting used to (for me anyway) in VB.NET is the whole concept of streams.

I like the idea, generally, but I was working through some code to stream debugging info into a resource in an already compiled EXE file when I ran into a problem with decompressing the resource data.

It just wouldn’t decompress properly.

After backtracking and puzzling over it, I discovered that the problem was actually in the compression phase.

   Private Function pCompressStream(ByVal UncompressedStream As MemoryStream) As MemoryStream
      Dim CompressedStream As New System.IO.MemoryStream()
      Using GZip As New System.IO.Compression.GZipStream(CompressedStream, System.IO.Compression.CompressionMode.Compress)
         GZip.Write(UncompressedStream.ToArray, 0, UncompressedStream.Length)
      End Using
      Return CompressedStream
   End Function

Note the Dim GZip line? If you look at the overloads, there’s a possible 3’rd option, LeaveOpen. It defaults to false.

From what I can tell, if you connect a GZipStream up to a FileStream, there’s no need for this parameter. When the GZip closes, the file is closed and on you go.

But, with MemoryStreams, it’s quite unlikely that you’d want to close the resulting output memory stream after zipping data into it.

But that’s exactly what happens if you don’t set LeaveOpen to True.

What’s worse. You need to Close the GZipStream before reading that MemoryStream(either by using a USING block as I have, or by calling Close directly). If you don’t, garbage collection might not happen for some time and the final data in the internal GZip buffers won’t get written to your memory stream, resulting in only partial compressed data, which definitely won’t decompress properly!

All this is likely old hat to grizzled .NET heads, but if you’re like me and coming from an extensive VB6/assembler background, it can certainly causing some headscratching for a bit.

I talked about fixed the IsNullOrEmpty method on the string object here.

But another aspect of the string object that has irritated me for a while is the Length property.

Obviously, the Length property returns the length of the current instance of a string variable.

However, because it’s an instance property, it can only be invoked against variables that have actually already been initialized to some value.

If you try and run this code, you’ll get an Object Not Set error when you execute the second line:

dim s as string
debug.print s.Length

Now, anybody that’s coded in VB intuitively knows that an unitialized string has a length of 0, and such a request should certainly  not result in throwing an error. It doesn’t matter one whit whether this is technically incorrect or not. I my book, those issues are for the compiler to work out, NOT the programmer.

Since the string class is an intrinsic type and we really can’t inherit from it or extend it in any traditional way, is there any way to correct this gaff?

With VB 2008, there is.

I blogged a bit about extension methods in the previous mentioned post and that’s what I’ll use to fix the Length property as well.

Unfortunately, as I also mentioned in my previous post, Length is a property  and not a method, so you can’t create an extension method for it directly, which is a shame.

However, long time VB programmers don’t think to use “Length” anyway, you always retrieved the length of  string via LEN(stringname), and LEN is not a member of the string object.

So, just add the following to a module to your application:

Imports System.Runtime.CompilerServices

Module StringExtensions

    ''' <summary>
    ''' Returns length of the string or 0 if the string is empty or has never been assigned (is nothing)
    ''' </summary>
    ''' <param name="aString"></param>
    ''' <returns></returns>
    <Extension()> _
    Public Function Len(ByVal aString As String) As Integer
        Return Microsoft.VisualBasic.String.Len(aString)
    End Function
End Module

and you’ll have a LEN function available directly from any string variable that will work regardless of whether the variable is initialized or not.

Also, note the <summary> comment. This will be displayed by Intellisense in the IDE, which can be quite handy.

And finally, you can’t use Return Len(aString) in the function, because doing so would be treated as a recursive call to the Len Extension method itself! Thus, I fully qualify the call to the Microsoft.VisualBasic.Strings LEN function.

All of this begets the obvious next question, “Why not just use Len(stringvar)“?

To which, I have no good answer.

Maybe it’s just a .NET thing<g>

Ok. Yet one more reason to dislike Vista.

Granted, I don’t regularly use HyperTerminal, but when you need to hack at some AT commands, well, it sure was handy to have around.

And it’s been there ever since, what, Windows -1?

But alas, no more.

So, off on the hunt I go. Now, I’ve known about puTTY for quite some time, but I always thought it was a telnet/TTY client. But much to my surprise, it just relatively recently got an upgrade with direct serial access under Windows.

I gotta say, for dinking around with your typical modem setup, this new puTTY honestly seems to work far smoother than HyperTerminal ever did.

C’est la vie, HyperTerminal. May you rest in peace.

Microsoft has just recently (as of Feb 15) released the full specs on the various Office file formats (including Word DOC files, Excel XLS files and Powerpoint PPT files, in particular).

The specs are available here.

If you’re a file format geek, or your job actually revolves around manipulating these types of files, this is surely a welcome addition to your arsenal.

Some of this information has been available, more or less, for quite some time. Most everyone who’s interested knows, for instance, that these files are actually OLE structured storage files, essentially entire “mini file systems” unto themselves.

But much of the detail has been sketchy at best, till now.

One word of warning though. Don’t expect these to be simple, cookbook recipes on rolling your own version of Word or Excel. The specs are huge and the formats unbelievably complex, having evolved over the course of 10 or more years. Further, these are not Web 2.0, nice, friendly XML/HTML/Text/human readable files by any stretch. They’re tangled, binary, pointer-ridden globs of structures that take a good deal of code just to render somewhat intelligible.

That said, official documentation is far better than none, and surely beats reverse-engineering the formats, as has been done up to this point.

I know I’ll be digging into this more in the coming weeks.

Happy hacking!