Learn a (Non-Programming) Language

As a programmer, I pride myself on the ability to learn new programming languages in a quick and reasonably thorough manner. When it comes to human languages, I need more practice. It's hard to get immersion without being surrounded by native speakers.  ("Immersion" in programming languages simply takes a certain amount of time spent with it while solving problems).

When I ran across a link to the BBC Languages homepage, I was pretty excited. This free web site has tools, games, and more to help learn a lot of interesting languages (at least at a simple level). Check it out and give your language knowledge another dimension (if you haven't already).

Release: TortoiseSVN 1.5.0

The good ole tortoise has reached another milestone. Check out the details here.

Firefox 3: Gort! Klaau barada nikto!

Downloaded FireFox 3 yesterday and enjoyed an easter egg today:

Enter "about:robots" into your FF3 address bar.

tlbexp.exe location/path (Visual Studio 2008), or "How can I export a .tlb for my COM-Visible Assembly?"

If you are going the path of making your .NET assembly visible to COM (Just as easy as checking the "Make Assembly COM-Visible" box in "Properties"->"Application" [Tab]->"Assembly Information..." [Button]), then you will probably encounter the fact that some consumers of your COM assembly will need a Type Library (.tlb).

Much of the documentation on the web suggests that one just fires up the "tlbexp.exe" tool (reportedly housed in the "SDK" directory in your Visual Studio path). This sounds reasonable until you realize that this tool is not there in Visual Studio 2008. If you have 2005 (or perhaps earlier even), then you can find and use this tool. Otherwise, it is gone.

I asked myself "Why on earth would they DO that?", but eventually found the answer buried in MSDN. The short story is that "regasm.exe" has a "/tlb:<OUTPUT-PATH>" option that does the same thing. It would appear that at least this functionality of tlbexp is obsolete.

Regasm.exe is more easily found. Since .NET 3.0 and 3.5 are mostly additions to 2.0, its at:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\regasm.exe

and not in the 3.0 or 3.5 version directories.

Consider Yourself Warned (XP Limitations explained)

Happened upon the above screen while resuming a session on a virtual machined. I must be tired, because I thought it was hilarious to imply that two applications might be the source of a computer slowdown in XP. Now, mind you, two resource hogs COULD choke the life out of a machine, but I love the glib newbie-training tooltip. Now I wonder what it says if you only have one app running.

[Snapped the screenshot via the PrtScn button while running XP as a Guest OS in VirtualBox]

Visual Studio 6 - Backup/Transfer/Migrate your Include/Library/etc. Directory Settings

You may be asking yourself why I would post about vs6 when Visual Studio 2008 is the "latest and greatest" version of the Studio line from Microsoft. The answer is simple: It is client mandated. You guessed it, I am working with a client that does not feel the compulsive need to upgrade that I do. Their complicated code base is all set to compile in a VC++ project in Visual Studio 6.

The problem is that information on what is actually needed to compile the project is all over the place. Most irritating is the fact that there are MANY Include Directories and Library Directories that must be in place.

You know what directories I am talking about. They are the ones found at:

Tools->Options->Directories(tab)->"Show Directories for:"->"Include Files"

and

Tools->Options->Directories(tab)->"Show Directories for:"->"Library Files"

In order for this huge, complicated, 3rd party cluttered code base to compile, custom entries must be in these sections in a particular order. (Dinkumware template variations, etc.).

Now it comes time to get a new developer up to speed and compiling, or even this same 'ole developer compiling on a different (Virtual :D) Machine.

Do I REALLY want to retype 25 directory paths...Manually...One by one...correctly...into the options UI?

NO!

So instead I did a little registry spelunking and dug out the path at which these items live. Hoorah! The items we care about live at:

"HKEY_CURRENT_USER\Software\Microsoft\Devstudio\6.0\Build System\Components\Platforms\Win32 (x86)\Directories"

Using regedit, we export the keys to a .reg file on the existing configured machine, copy this file to the new machine, tweak any path variations we might care about, and load it back up.

I now take a moment to relish the obscurity of this post.

But then, maybe, someone else out there wants this information. This blip is for you.